A new kind of code protection

Comments

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.

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.

-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

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.

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.