Shop OBEX P1 Docs P2 Docs Learn Events
A new kind of code protection — Parallax Forums

A new kind of code protection

cgraceycgracey Posts: 14,133
edited 2017-10-20 12:38 in Propeller 2
I completely removed the fuses from the Prop2 today. Even if we could have blown them reliably, 1 in 400 are known to fail, anyway. Even using them redundantly doesn't give us the level of reliability we'd need, before our key size would drop to a level that everyone would complain about. In the worst case, these fuses could cripple the chip by some accidental blowing during core brown-out, or some other unlikely, but possible, scenario. It's just too much risk. Ken and I had been going back and forth on this and we decided to jettison them today. Along with the fuses, goes the need for SHA-256 and other related measures. This simplifies the ROM and speeds up booting.

So, I've been thinking about what we could do for code protection, given that there's no secret identifier inside the chip, anymore.

Jmg has said there are 30-cent micros with 16KB of flash and their own code security. These, unto themselves, are probably 'secure'. We could use them as protected code loaders for the Prop2 by having them deliver random-looking code snippets which the Prop2 must execute very quickly, in order to unravel data, while reporting back continuously to the secure micro. To an observer, nothing would happen twice the same way. The Prop2 would be forced into a very tight dance that would be carefully checked by the cheap micro, which would be feeding the secured code with strict timeouts. Shy of having a full-chip emulator for the Prop2, I think it would be quite impractical to unravel what was going on. There'd be no time for 'faking it' with a cog on the ready. Plus, the imported code snippets would cover over and partially erase the whole cog RAM many times, leaving no room for some persistent stub code.

The cheap micro could feed the initial program in serially via P63, and then the loaded code, containing a key, would use the normal flash chip (if even needed) to decrypt much larger code. So, this would add a little to the BOM and even supplant the need for a separate flash chip, in some cases.

I know this doesn't sound "fantastic", but for people who develop applications that they want to secure, they could adopt this mechanism after the fact. It could be there for people who need it. Meanwhile, there's no potential for ugly gotcha's during development and a Prop2 can't get "bricked".
«134567

Comments

  • A sensible move, I think, as most people wouldn't have used the fuses anyway. A few questions:

    1. Does this free up any meaningful extra space on the chip?
    2. Does SPI booting now load 256 'ordinary' longs?
    3. What is the SPI boot clock frequency?
  • cgraceycgracey Posts: 14,133
    edited 2017-10-20 13:01
    TonyB_ wrote: »
    A sensible move, I think, as most people wouldn't have used the fuses anyway. A few questions:

    1. Does this free up any meaningful extra space on the chip?
    2. Does SPI booting now load 256 'ordinary' longs?
    3. What is the SPI boot clock frequency?

    1) If we redesigned the I/O pad layout, it could open up some area in the core. It's probably not worth doing.
    2) SPI will load 255 longs plus 1 long that must be the sum of those 255 longs XOR'd with "Prop" ($50726F70). That will be our integrity check.
    3) The SPI boot frequency is 20M/8 clocks per bit. It takes 3.3ms to load 256 longs.
  • evanhevanh Posts: 15,126
    cgracey wrote: »
    ... Shy of having a full-chip emulator for the Prop2, I think it would be quite impractical to unravel what was going on.
    An FPGA could be designed to do it. And when it's a universal solution it's likely to be commercially valuable to go to the trouble. Better to leave it up to the system designers to do their own instead.

    Refine the fuses or do the EEPROM thing or forget copy protection.
  • Code Protection: It is a nice to have. It is something that will help widen your market. It can be an up-sell feature for commercial users.

    You can circle back to code protection with Prop 2.5 :)

    --Terry
  • I'm with Chip on this decision. Regardless of the benefits [that I've also wanted for our customers] I've seen Chip go 'round and 'round on engineering issues like this one when it's best to open the capsule door and . . .jettison. Simplification and reliability have won customers every time with his designs.

    Chip is also working alone and needs this load lifted off his shoulders. Parallax is ready for test chip and synthesis.

    Ken Gracey
  • I would highly recommend while working with the On-Semi guys for synthesis, pester them as to how this *COULD* be implemented in a reliable, supportable way and use that information for the next iteration.
  • cgraceycgracey Posts: 14,133
    I think there's a lot we could do that would be quite confounding, not just a cryptography stunt.
  • Chip,
    There is nothing with this solution that is really secure. If the external chip has to put/have run-able code in the prop to start, it's already broken.

    Just drop any sort of pre-made solution for now, let end users decide what they need/want. Sure, that means some of them will bypass the P2 because of it. Not anything you can do about that in this version.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-10-20 17:46
    Roy Eltham wrote:
    There is nothing with this solution that is really secure.
    I'm with Roy on this, I'm afraid. Without some kind of secure, programmable bits internal to the P2, there's no way to effectively encrypt or obfuscate data passing over a probable pin. It's a technique that relies upon a single secret in ROM. And when that secret gets out -- and it will -- all bets are off.

    Cryptography is hard. Even the experts in the field sometimes get it wrong, and I daresay all of us here are pretty rank amateurs.
    Just drop any sort of pre-made solution for now, let end users decide what they need/want.
    +1

    -Phil
  • Heater.Heater. Posts: 21,230
    I have no idea what Chip's scheme is but historically we see that home made security systems get busted all the time.

    I would rather that not even one minute is spent thinking about this and we get the P2 in our hands ASAP.





  • jmgjmg Posts: 15,140
    edited 2017-10-20 20:04
    cgracey wrote: »
    I completely removed the fuses from the Prop2 today. Even if we could have blown them reliably, 1 in 400 are known to fail, anyway. Even using them redundantly doesn't give us the level of reliability we'd need, before our key size would drop to a level that everyone would complain about. In the worst case, these fuses could cripple the chip by some accidental blowing during core brown-out, or some other unlikely, but possible, scenario. It's just too much risk. Ken and I had been going back and forth on this and we decided to jettison them today....

    That decision make sense, but there are multiple layers here. Be careful not to throw the baby out with the bathwater.
    Removal of the fuses is sound, but because your custom fuses are gone, does not mandate that everything goes overboard too.

    Did you have a serious discussion with OnSemi, around OTP/MTP memory ?

    ie You may be able to use OTP/MTP, to reliably replace the fuse features.

    Modest OTP also allows you to include serial/unique ID and oscillator-calibrate (measured frequency at some V,T) - common in other MCUs and widely useful outside of the 'full secure' customers.

    Slightly larger OTP allows OTP for boot, which opens up more customers for P2. (eg XMOS have 8k OTP)

    You do not have to remove boot ROM entirely, you can just add a check for 'code in OTP' to read some extra boot information.

    If you do finally decide both Fuses and OTP are not possible, after talking with OnSemi, there are external Authenticate devices out there.

    Examples:
    http://www.microchip.com/design-centers/security-ics/cryptoauthentication/overview
    http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=ATAVRBLE-IOT


    cgracey wrote: »
    Jmg has said there are 30-cent micros with 16KB of flash and their own code security. These, unto themselves, are probably 'secure'. We could use them as protected code loaders for the Prop2 by having them deliver random-looking code snippets which the Prop2 must execute very quickly, in order to unravel data, while reporting back continuously to the secure micro. To an observer, nothing would happen twice the same way. The Prop2 would be forced into a very tight dance that would be carefully checked by the cheap micro, which would be feeding the secured code with strict timeouts. Shy of having a full-chip emulator for the Prop2, I think it would be quite impractical to unravel what was going on. There'd be no time for 'faking it' with a cog on the ready. Plus, the imported code snippets would cover over and partially erase the whole cog RAM many times, leaving no room for some persistent stub code.

    Yup, this works like a dongle, and gives a moderate security level.
    Such a part can also run the one-pin loader, which can simplify secure-code management into one capsule.
    However, small MCUs do have limitations, but can be very useful, at very low added cost.

    The more formal CryptoAuthentication parts linked above, are not a huge step in price (~ 50c/5k), and do take you into a 'known realm'.
    Using those may be a better idea, for the more serious levels of Authentication.

    That means you may want to keep some of the ROM code for SHA-256, just use it with such a matching external device ?

    (all of this shows why OTP boot ROM is a good idea..., it also allows such code development & testing to be done during chip tapeout )

    Addit: this is ATECCC508A feature list

    * Authentication without the need for secure storage in the host
    * No requirement for high-speed computing in client devices
    * Cryptographic accelerator with Secure Hardware-based Key Storage
    * Performs High-Speed Public Key (PKI) Algorithms
    * NIST Standard P256 Elliptic Curve Support
    * SHA-256 Hash Algorithm with HMAC Option
    * Host and Client Operations
    * 256-bit Key Length
    * Storage for up to 16 Keys
    * Two high-endurance monotonic counters
    * Guaranteed Unique 72-bit Serial Number
    * Internal High-quality FIPS Random Number Generator (RNG)
    * 10Kb EEPROM Memory for Keys, Certificates, and Data
    * Storage for up to 16 Keys
    * Multiple Options for Consumption Logging and One Time Write Information
    * Intrusion Latch for External Tamper Switch or Power-on Chip Enablement
    * Single Wire or I2C Interface
    * 2.0V to 5.5V Supply Voltage Range

    I wonder if that 10kb is enough to store a P2 stage 1 loader ? (1.25k Bytes?)
  • All of the 256 longs except the first one could be encrypted by using a "one-time pad." If the first long is zero then the other 255 are not encrypted, whereas a non-zero value is the number of a pad containing unique data used to encrypt longs 1-255 and supplied by Parallax as a computer-generated encrypted file to the end-user.

    This would not prevent the cloning of P2 systems but it should prevent or at least deter easy code copying. Obviously the boot ROM has to support it so it would not be "after the fact" in that respect. The proposed integrity check could be a bit more robust.

    If you don't like and/or trust the above, just make the first long zero and implement your own security.
  • Would this be of any use?

    http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591725

    there is a sot23-3 package available too!

    as far as I understand though, the main requirement is that signature verification must be unskippable, so implemented in ROM on the host MCU (it cannot be part of a second stage loader).

  • Righto, battery backed secure cog it is, just with a bigger battery.

    Lets get this thing made
  • jmgjmg Posts: 15,140

    Yes, see my links above, the ATSHA204 is an older, subset version of the ATECC508A.


  • Heater.Heater. Posts: 21,230
    Oh Smile.

    There goes another minute of P2 delay with Chip having to read and think about the posts above.

    I'm with Ken. "... best to open the capsule door and . . .jettison. Simplification and reliability have won customers every time with his designs."

    I also have a gut feeling that the number of potential P2 customers that require securing their "secret sauce (source?)" is approximately zero.

  • jmgjmg Posts: 15,140
    Heater. wrote: »
    I also have a gut feeling that the number of potential P2 customers that require securing their "secret sauce (source?)" is approximately zero.

    If P2 has no means whatsoever to provide security, then yes, you have limited P2 customers to those not needing any form of security.

    However, there are many levels of security, and some are less about 'securing their "secret sauce (source?)"' and more about handling production creep issues, or about giving attack protection.
    Plenty of industrial control systems these days have to worry about attacks, (but do like to give code updates too)...

    Teaching labs ? - maybe security matters less there, but tutors may be looking to teach embedded security by example...

    Given the P2 already has SHA-256 code written, it seems smarter to check if that can still be used, with external CryptoAuthentication ?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2017-10-20 23:08
    So this is only about authentication; and it's not about code protection, which the title suggests? The former seems achievable; the latter, not without non-volatile programmable bits inside the P2.

    -Phil
  • Heater.Heater. Posts: 21,230
    jmg,
    If P2 has no means whatsoever to provide security, then yes, you have limited P2 customers to those not needing any form of security.
    You can turn my assertion around like that if you like. Makes no difference. My claim is that making such a limitation will have negligible impact on the marketability of the P2.

    One is fee to disagree with my gut feeling of course.
    ...more about handling production creep issues, or about giving attack protection.
    Plenty of industrial control systems these days have to worry about attacks, (
    I have no idea what you mean by "production creep issues".

    Attack protection is a whole other can of worms. This is now the world of the "Internet of Things". The security of which seems pretty lax and an as yet unsolved problem. See for example the recent news: https://www.wired.com/story/krack-wi-fi-iot-security-broken/

    The solutions I see so far for securing things are the SIM cards in your phone and the chips in your credit cards. Far away from Propeller land.













  • jmgjmg Posts: 15,140
    Heater. wrote: »
    The solutions I see so far for securing things are the SIM cards in your phone and the chips in your credit cards. Far away from Propeller land.
    Securing MCUs is not as far away as you think.
    See my link above about the CryptoAuthentication chips, designed exactly to run alongside Microcontrollers, of which P2 is one.
    Heater. wrote: »
    I have no idea what you mean by "production creep issues".
    That's more of an issue in higher volume runs but everyone aspires to higher volumes....
    It's where your contract assembler runs some for themselves on the night shift ...

  • Phil and I agree, IT MUST ME RIGHT. :)
  • DrPopDrPop Posts: 227
    edited 2017-10-21 01:18
    As a for-profit business, you must go back to your target market Venn diagram(s). I'm sure you drew one out, maybe even several overlapping for the P2. If your target market requires built-in security, then it must be implemented somehow. If it's not required, then don't delay your product for it.

    If you can implement some helpful features that will make it easier for those who need security to add their own flavor of it to their final project, and this enables the P2 to break into other market(s) outside your original target market, doing so will be beneficial as long as it does not a. harm original features desired by the target market; b. exhaust capital (including time) beyond what is recoverable in extra sales generated.
    If adding some security or any parts of it fits a & b, then by all means add it in, as it will only increase revenue. If it doesn't fit both a & b, I can't see how it's even feasible from a company standpoint to have the discussion.

    EDIT: Quite possibly, only those privy to internal Parallax numbers could know the answer, of course, and those number do not need to be shared publicly.
  • Heater.Heater. Posts: 21,230
    OK, if said CryptoAuthentication chips can run alongside micro-controllers, including the P2, then there need not be any effort wasted on the P2 development. People can use those devices as well if they like. Good.

    I'm not sure how the "contract assembler night shift" issues are fixed by code protection. Presumably you give them all the details needed to build a thing. Including the code to blow into the devices and make a finished product.



  • jmgjmg Posts: 15,140
    edited 2017-10-21 00:45
    Heater. wrote: »
    I'm not sure how the "contract assembler night shift" issues are fixed by code protection. Presumably you give them all the details needed to build a thing. Including the code to blow into the devices and make a finished product.
    It does not even need source-code protection, just a unique device ID may be enough. ( A sub 30c MCU I'm looking at, has a 96 bit Unique ID included )

    They give a list of revealed ID numbers, and those go into your support data base. If any show up with unsupportd IDs, you have a dodgy manufacturer.

    Hence my suggestion above of using the OnSemi OTP IP to solve the Fuse problem... and this allows add of Serial Numbers and Osc Calibrate for free...


  • Heater.Heater. Posts: 21,230
    Yeah, back to the OTP/fuse thing.

    We have no time for that.

    Let's just have chips. Now !
  • Cluso99Cluso99 Posts: 18,066
    Internal OTP/FLASH/EEPROM has been so difficult to resolve.

    It's a real shame that OnSemi haven't given the right answers.... or have the right questions been asked of them ?????

    Here's a recent post of mine...
    Cluso99 wrote: »
    A simple google search has turned up these...

    May 6, 2014 - OnSemi ONC18 qualified IP: ultra-low power oscillator and very-small footprint OTP memory
    onsemi.com/PowerSolutions/newsItem.do?article=3102

    March 31, 2011 – Sidense Corp., a leading developer of Logic Non-Volatile Memory (LNVM) one-time programmable (OTP) memory IP cores, and ON Semiconductor (Nasdaq: ONNN), a premier supplier of high performance silicon solutions for energy efficient electronics, have announced that Sidense has ported its 180 nanometer (nm) OTP memory SLP product line to ONC18, ON Semiconductor’s 180 nm digital and mixed-signal technology platform.
    Single SLP macro densities ranging up to 256 kilobits (Kbits) will be available.
    "We chose Sidense's OTP intellectual property for its low power and small area and also because it doesn't require any changes or additions to our standard process flow."
    Sidense Corp. provides secure, very dense and reliable non-volatile, one-time programmable (OTP) memory IP for use in standard-logic CMOS processes with no additional masks or process steps required and no impact on product yield. The Company's innovative one-transistor 1T-Fuse™ architecture provides the industry's smallest footprint, most reliable and lowest power Logic Non-Volatile Memory (NVM) IP solution. With over 70 patents granted or pending, Sidense OTP provides a field-programmable alternative solution to Flash, mask ROM and eFuse in many OTP and MTP applications.
    https://sidense.com/sidense-1t-otp-memory-available-in-on-semiconductor-180-nm-process-technology/

    The ONC18 process is an ideal platform for developing low power and highly integrated digital and mixed-signal application-specific integrated circuit (ASIC) devices for automotive, industrial and medical applications
    FEATURES
    The ONC18-based solutions will be manufactured at ON Semiconductor's 8-inch wafer fabrication facility in Gresham, Oregon, so the process is also expected to prove attractive for designers of U.S. military applications seeking domestic production with ITAR-compliant partners
    ONC18 will allow designers in the automotive, industrial, medical and military sectors to develop integrated, low-power digital and mixed-signal ASICs quickly and cost-effectively
    The ?on-shore' nature of the fabrication will be particularly useful for US military customers, while planned developments for the process further underline ON Semiconductor's commitment to the custom foundry business
    Suitable for ASICs requiring up to 10 M gates, the ONC18 process features between four and six levels of metal and allows designers to integrate 1.8 volts (V) core voltage with 1.8 V and 3.3 V input/output (I/O)
    Components for mixed signal design include a variety of resistors and nominal [1.0 femtofarad per micron squared (fF/?m2)] and high value (2.0 fF/?m2) stackable metal-insulator-metal (MIM) capacitors
    This base process supports an extensive and modular 0.18 micron BCD, and high voltage roadmap
    ON Semiconductor's new process is supported with a design kit offering comprehensive core, I/O and memory libraries
    Gate densities and power consumptions for high density core and mixed signal core cells are 124 K gates/mm2 and 46 microwatt per megahertz per gate (?W/MHz/gate) and 120 K gates/mm2 and 28 ?W/MHz/gate, respectively
    Memory options include 1.1 M bit synchronous single port and 512K bit dual port SRAM and 1.1M bit high-density, low-leakage VIA-programmable ROM
    Future development for the ONC18 platform will enable ON Semiconductor to launch enhanced mixed signal capabilities and options for higher voltage handling
    The new process design methodology is compatible with common digital and analog/mixed signal CAD tools, including those from Cadence?, Synopsys? and Mentor Graphics?
    ON Semiconductor specialty services, such as advanced die stitching and shuttle services for prototyping, are also available for ONC18-based designs
    For more information, please contact Kirk Peterson at kirk.peterson@onsemi.com or visit http://www.onsemi.com
    embedded-computing.com/products/id/?43185

    I-FUSE OTP
    I-Fuse™ is an innovative method to logically program One-Time Programmable (OTP) memory with “Electro-migration by accelerating wear-out of logic devices”. Unlike other Non-Volatile Memory (NVM) programming methods that use “oxide rupture” or “storing charges” techniques that require high voltage for programming, I-Fuse requires no charge pump. I-Fuse has 100x reliability, 10% cell size, and 10% of programming current compared to traditional fuse. I-Fuse is scalable from 700nm to 28nm and below.
    The AT4K8O180GN0AA is organized as a 4Kx8 OTP memory with parallel programming mode. This is a kind of non-volatile memory fabricated in 0.18um standard CMOS core logic process. The OTP can be widely used in chip ID, security key, memory redundancy, parameter trimming, configuration setting, feature selection, and PROM, etc.
    * Fully compatible with standard 0.18um CMOS core logic process
    * High capacity: 4Kx8 parallel mode
    * Low voltage: 1.8V read and 3.6V program ****Note 3.6V program
    * Pure logic, no additional masks or process steps
    onsemi.com/site/pdf/ON-Semiconductor-0.18um-BCD-IP-v5.pdf

    And here are OnSemi's EEPROMs and FLASH ICs...
    EEPROMS: onsemi.com/PowerSolutions/parametrics.do?id=2311
    FLASH: onsemi.com/PowerSolutions/parametrics.do?id=2310

    23rd June 2011 - OnSemi FLASH produced on ONC18 line
    ON Semiconductor has released new EEPROM (Electrically Erasable Programmable Read-Only Memory) devices for the automotive, medical, and consumer markets. The EEPROM devices include the high density 512 kilobit (kb) CAT24C512 and 1 megabit (Mb) CAT24M01, which have a 1.8 volt (V) to 5.5 V supply voltage range. The CAT24C512 and CAT24M01 employ 256 byte and 128 byte page write buffers respectively. Both devices support Standard 100 kilohertz (kHz), Fast 400 kHz, and Fast-Plus 1 megahertz (MHz) serial I2C protocols. These devices are manufactured on a 0.18 micrometer (µm) low power CMOS process at the ON Semiconductor owned and operated Gresham, Oregon facility.
    All of the new EEPROM devices feature a 100 year data retention period and support for 1,000,000 program/erase cycles. electronicspecifier.com/memory/on-semiconductor-expands-serial-eeprom-portfolio---introduction-includes-new-high-density-devices-for-the-automotive-medical-and-consumer-markets

  • evanhevanh Posts: 15,126
    Cluso,
    Flash is not available. Flash is just as likely as MRAM.
  • I am with Phil, Roy. Nail it, or don't do it.
  • Cluso99Cluso99 Posts: 18,066
    edited 2017-10-21 05:42
    evanh wrote: »
    Cluso,
    Flash is not available. Flash is just as likely as MRAM.
    Nowhere does it say flash isn't available on the ONC18 line. But it does say there are lots of customers making micro asics on this line including all sorts of memory ip.
    And OnSemi DO MAKE their own FLASH CHIPS -did you follow the link?
    And OnSemi MAKE their own EEPROM CHIPS on the ONC18 line, including the very ones I use on my P1 boards!!!

    Specifically, OTP and EEPROM ARE AVAILABLE AS IP ON THE ONC18 LINE.
    And have been for years! It's not new!

    Furthermore, I bet that FLASH is also AVAILABLE on the ONC18 line too!
Sign In or Register to comment.