But why? That just complicates the boot sequence for a feature that's not going to be used 99.9% of the time. Not only that, but it cannot be updated. Just stick to loading a monitor (of your choice) over serial when it's needed.
Probably true. What else could go into that space?
I'll definitely add my vote for Forth in the ROM !!!
I plan on using Forth on the P2 once it is released and if the Tachyon core is in the ROM then I get more RAM for code and data!
This could solve the security issue too !
Isn't Forth code a type of code encryption anyway !
(just kidding ;-)
Just day dreaming, but it would be kind of cool to have a BASIC interpreter in there. If no boot device is detected, and a specific pin sequence is pulled hi/lo, have it select some pins for video/audio/keyboard and boot the BASIC interpreter like an old school computer. Would be neat to have a 32-bit powered retro home computer. I know, dumb idea.
Would not all the obfuscation techniques using second mcus / secure mcus be void as the external flash chip contents can be extracted and written to a binary file for use with SpinSim? And possibly that coupled with the debug a cog from another cog?
Just day dreaming, but it would be kind of cool to have a BASIC interpreter in there. If no boot device is detected, and a specific pin sequence is pulled hi/lo, have it select some pins for video/audio/keyboard and boot the BASIC interpreter like an old school computer. Would be neat to have a 32-bit powered retro home computer. I know, dumb idea.
A Forth interpreter that fits in 16k could be a lot more powerful than a similar sized BASIC interpreter.
Maybe the Prop2 could be the first chip to really make Forth mainstream.
Zilog tried that in the '80s with their Super 8 chip -- an extension of their Z8 microcontroller. It didn't really have a Forth interpreter, but its opcode set included commands to support threaded languages, e.g. enter, exit, next, etc. They distributed a Forth for free that took advantage of those commands, but it never really caught on; and they eventually dropped the Super 8 entirely. I really liked that chip and wrote a Forth front-end for it for a three-axis mill. It was only available in NMOS, though, and ran quite hot.
A threaded language -- or, better: threaded code -- is a zero-operand, stack-based interpretive scheme that's a list of addresses (or calls) to the code that does the work. The addresses can point to assembly code or to another list of addresses, etc.
Imagine if you had the smallest, cheapest MCU acquirable (SOT23-5, $0.25) connected to one I/O pin. You have ongoing send/receive communication with it. 99.99% of activity can be for show, but the 0.01% can be some meaningful activity that validates your security status. Say the Prop2 dongle-check code is scrambled PASM in the flash image, but gets unscrambled at run time, for use. This could be a pain to unravel, and not worth the trouble. It's actually more than any likely customer would need, given that the Prop2 is bound for expensive low-run-rate products that aren't going to attract the level of interest that a $0.05 computer stamped into a smart payment card would receive.
What if the liitle MCU gets completey configured with code and a random number on each download to flash. Just click a check-box and set the pin number in a download-settings menu and it's taken care of. Tell the world that it's not totally secure, but can be tailored over time to keep the attackers busy. I wouldn't want to attempt to unravel that.
More on Dongles....
Slightly above the SOT23 one in size, are MCUs with 96 bit serial number, and I see TI have FRAM MCUs starting at ~ 36c, with 3.75k ones for ~ 54c
Ramtron used to offer 'processor companion' fram, which was serial memory plus extras, but the prices of those have climbed, and looks like FRAM MCUs can displace most of that.
FRAM MCUs allow simple not volatile fast incrementing counters, so they can change every reset for example, giving a rolling code design quite similar to garage door openers.
How big is the ROM and will it be used just for booting?
It's 16KB, but we are only using a tenth of it.
The ROM should contain secrets and the code needed for booting. Everything else can be loaded from external memory.
As has been mentioned several times, trying to protect code outside of the P2 won't work. Encrypted code has to be decrypted inside the P2. Losing the fuses doesn't mean this is impossible and public key encryption would work. The fact that 90% of the ROM is unused means there is room for at least 10 keys at a guess, allowing some of the public keys to be less public than others, i.e for use by select customers only. Only needed to encrypt an AES-128 key for main program loading.
Additionally, would it be possible to have 'soft fuses' using a 128-bit register/SRAM with battery backup?
Some FPGAs do this to store AES keys for decrypting encoded bitstreams.
Additionally, would it be possible to have 'soft fuses' using a 128-bit register/SRAM with battery backup?
There is no layout provision for a separate battery pin in the P2 design, but P2 should have some RAM retention voltage spec (like any static CMOS device), where the clock can be stopped and Vdd reduced.
As a die-wide power, that's still likely to be some energy, but I guess that just means a larger battery
>Regardless of how many keys are held in ROM, they still comprise one single secret. And once that secret gets out, ... (You get the idea.)
If somehow only P2's 1st stage bootcode can read ROM-Stored-Keys and there is absolutely no software access to them.
So say you store 100 keys, with some so rare that only one large company gets one for exclusive use.
Firmware would need a header to tell what key[x] decode with.
But if they copy the SPI-Flash content, they copy that part to, so useless.
Another problem is brute force attack using a 4Ghz PC on the dumped sourcecode as you could make it try millions of keys and if it see that first 10 longs looks like valid op-code, it stops.
It seems to me that a future member of the P2 line could be offered, where a number of pins are "blinded" to the outside world and instead connected to a stacked die internal to the package.
This stacked die could provide the NV RAM necessary for security, and possibly secure program store, depending on size.
The "blinding" could even be internally controlled, allowing standard program load and burn over the external pins, with disconnection occurring after a successful verify.
Such effort could be deferred until after initial release of standard P2s, if Parallax assess that sufficient demand for a secure version is there to justify the effort.
Equally, as board layout requirements have lead many to suggest Parallax sell modules in addition to bare chips, this secure version might be achieved by "blobbing" a standard P2 and external support chip(s) in an epoxy casing on the module.
No measure will ever be 100% proof against determined attackers; it is a matter of making it difficult enough to be not worth the required effort.
This is why most houses have locks on the doors and windows, but not armed guards in every room.
Tachyon in ROM means FAT32 and that means booting is possible from SD cards as FAT32 files sans boot chip. It is also a great hardware debug tool, that's why it was used in Sun workstations as OpenBoot/OpenFirmware etc. I might be able to squeeze an interactive assembler in there too. Chip's monitor would be handy too.
Comments
Add one command to drop out of it and into the Forth proper, and it's game on from there.
It won't take much of a dictionary to do either.
The original monitor was very high value. If it can get back into the ROM, I'm all for it.
I will do high quality docs again. Promise.
I plan on using Forth on the P2 once it is released and if the Tachyon core is in the ROM then I get more RAM for code and data!
This could solve the security issue too !
Isn't Forth code a type of code encryption anyway !
(just kidding ;-)
J
Doesn't need to be. Monitors can get finished. So can a small Forth needed to support the monitor startup word.
Grrr...
I sure hope not... :P Ugh.
This might be a trivial niggle but is it possible to remove the upper case and underscores from whatever commands the P2 understands?
Why "Prop_Txt" instead of something simpler like "prop-txt" ?
I know nobody is ever going to be typing such commands into their P2. It just niggles me.
-Phil
What do you mean by "threaded languages"?
I presume you do not mean threads of execution as in Occam or Go etc.
Or do you?
Here's a reference: https://en.wikipedia.org/wiki/Threaded_code
-Phil
Changes to the ROM are not holding up synthesis are they? If so I withdraw any suggestions I might have made about what to put in the extra ROM space.
-Phil
... but with about 14KB free ROM, there could be a lot of different serial numbers
More on Dongles....
Slightly above the SOT23 one in size, are MCUs with 96 bit serial number, and I see TI have FRAM MCUs starting at ~ 36c, with 3.75k ones for ~ 54c
Ramtron used to offer 'processor companion' fram, which was serial memory plus extras, but the prices of those have climbed, and looks like FRAM MCUs can displace most of that.
FRAM MCUs allow simple not volatile fast incrementing counters, so they can change every reset for example, giving a rolling code design quite similar to garage door openers.
The ROM should contain secrets and the code needed for booting. Everything else can be loaded from external memory.
As has been mentioned several times, trying to protect code outside of the P2 won't work. Encrypted code has to be decrypted inside the P2. Losing the fuses doesn't mean this is impossible and public key encryption would work. The fact that 90% of the ROM is unused means there is room for at least 10 keys at a guess, allowing some of the public keys to be less public than others, i.e for use by select customers only. Only needed to encrypt an AES-128 key for main program loading.
Additionally, would it be possible to have 'soft fuses' using a 128-bit register/SRAM with battery backup?
Some FPGAs do this to store AES keys for decrypting encoded bitstreams.
As a die-wide power, that's still likely to be some energy, but I guess that just means a larger battery
-Phil
If somehow only P2's 1st stage bootcode can read ROM-Stored-Keys and there is absolutely no software access to them.
So say you store 100 keys, with some so rare that only one large company gets one for exclusive use.
Firmware would need a header to tell what key[x] decode with.
But if they copy the SPI-Flash content, they copy that part to, so useless.
Another problem is brute force attack using a 4Ghz PC on the dumped sourcecode as you could make it try millions of keys and if it see that first 10 longs looks like valid op-code, it stops.
https://www.semiwiki.com/forum/content/7057-presto-engineering-outsourced-secure-provisioning-even-their-secrets-have-secrets.html
Edited to add interesting quote: “The ability to incorporate your secrets without knowing them”
This stacked die could provide the NV RAM necessary for security, and possibly secure program store, depending on size.
The "blinding" could even be internally controlled, allowing standard program load and burn over the external pins, with disconnection occurring after a successful verify.
Such effort could be deferred until after initial release of standard P2s, if Parallax assess that sufficient demand for a secure version is there to justify the effort.
Equally, as board layout requirements have lead many to suggest Parallax sell modules in addition to bare chips, this secure version might be achieved by "blobbing" a standard P2 and external support chip(s) in an epoxy casing on the module.
No measure will ever be 100% proof against determined attackers; it is a matter of making it difficult enough to be not worth the required effort.
This is why most houses have locks on the doors and windows, but not armed guards in every room.
Regards,
Anthony.
-Phil