A new kind of code protection
cgracey
Posts: 14,152
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".
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".
Comments
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.
Refine the fuses or do the EEPROM thing or forget copy protection.
You can circle back to code protection with Prop 2.5
--Terry
Chip is also working alone and needs this load lifted off his shoulders. Parallax is ready for test chip and synthesis.
Ken Gracey
https://arstechnica.com/gaming/2017/10/denuvos-drm-ins-now-being-cracked-within-hours-of-release/
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.
Cryptography is hard. Even the experts in the field sometimes get it wrong, and I daresay all of us here are pretty rank amateurs.
+1
-Phil
I would rather that not even one minute is spent thinking about this and we get the P2 in our hands ASAP.
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
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?)
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.
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).
Lets get this thing made
Yes, see my links above, the ATSHA204 is an older, subset version of the ATECC508A.
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.
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
One is fee to disagree with my gut feeling of course. 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.
See my link above about the CryptoAuthentication chips, designed exactly to run alongside Microcontrollers, of which P2 is one.
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 ...
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.
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.
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...
We have no time for that.
Let's just have chips. Now !
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...
Flash is not available. Flash is just as likely as MRAM.
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!