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".