A new kind of code protection

cgraceycgracey Posts: 8,358
edited October 20 in Propeller 2 Vote Up0Vote Down
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

  • 201 Comments sorted by Date Added Votes
  • 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
  • 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.

  • Oh crap.

    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.

  • We should end whining here on what the P2 can not do. Other prominents in gol is doing enough into this direction. We should accept: if grows follows an exponential curve, the most important is, to begin as early as possible, not to grow as fast as possible too late. With the P2's features and our genius combined the P2 will be a huge success, however hardware and software will be combined. Stop distracting Chip from shipping the chip! Please. Keep hearing about "tiny" amount of money spent on Propeller ads. What about the billions of dollars of main stream processors ads?
    Always try to recycle the bad to create something good!
  • Good point, Andy. That could be a solution right there.

    To prevent cloning, it could be as simple as this:

    Before compiling the user's code, the Prop2 tool discovers the unique ID of the flash chip in the target system. That ID value is assigned to a global constant before compiling the user's program. The user's program verifies that value any number of ways within his code at run time. He doesn't operate if he discovers a problem.
  • tonyp12tonyp12 Posts: 1,870
    edited October 23 Vote Up1Vote Down
    >What about removing the flash chip and just re-running that short program?

    You would not get the short program to install and run again, unless you encrypt it with the key that only you know, nothing will ever get installed again without key encrypted firmware.
    Routine is not in ROM, Keys are not spit out because it don't see a spi flash, routine is wiped out by the actual firmware.

    It would be good if this routine survives a brownout reset though, in case you did not catch the data it uarted out (though it will repeated 6 times)
    or when blowing a fuse caused P2 in to low power reset.

  • TonyB_ wrote: »
    The fuses have gone - just let go.

    Let it go, let it go...

  • potatoheadpotatohead Posts: 8,978
    edited October 24 Vote Up1Vote Down
    Honestly, if something goes in there, a monitor and assembler/dissassembler would be my preference.

    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • The space could be filled with this image.
    CoCo3_Easter_Egg.png

    :)
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
  • 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?
    Formerly known as TonyB
  • cgraceycgracey Posts: 8,358
    edited October 20 Vote Up0Vote Down
    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.
  • 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.
    The Prisoner's Dilemma, in english - "Selfishness beats altruism within groups. Altruistic groups beat selfish groups." - Quoted part from 2007, D.S Wilson/E.O Wilson.
  • 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
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
  • 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.
    Feel the need for speed between your PC's com port and Prop?
    Try the FTDI 245 and the FullDuplexParallel Object.

    Check out my spin driver for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087
  • I think there's a lot we could do that would be quite confounding, not just a cryptography stunt.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 21,403
    edited October 20 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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: 10,637
    edited October 20 Vote Up0Vote Down
    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.
    Formerly known as TonyB
  • 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

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


  • 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: 21,403
    edited October 20 Vote Up0Vote Down
    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
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • 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.













  • 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: 166
    edited October 21 Vote Up0Vote Down
    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.
  • 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.



Sign In or Register to comment.