From what I understand, you will need to use a special program to blow the fuses. There will be no accidental fuse blowing like can happen on other micros. Just don't use them and there will not be any problems.
Therefore no corrections will be required. They are there for special use and encryption of code for commercial users who want to protect their code investment.
That's right, though we could do what samuell asked, as it's just a firmware matter.
Even if security fuses are blown couldn't you have the override that blows all the fuses so to speak thus completely disabling them from being used again and in this condition disables security as might be the case during development. This would not affect production and even if a production unit were taken off the line and used for development then this is what we could do.
Even if security fuses are blown couldn't you have the override that blows all the fuses so to speak thus completely disabling them from being used again and in this condition disables security as might be the case during development. This would not affect production and even if a production unit were taken off the line and used for development then this is what we could do.
The fuses are set up in hardware such that once the master fuse is blown, no more blowing is possible.
Even if security fuses are blown couldn't you have the override that blows all the fuses so to speak thus completely disabling them from being used again and in this condition disables security as might be the case during development. This would not affect production and even if a production unit were taken off the line and used for development then this is what we could do.
The fuses are set up in hardware such that once the master fuse is blown, no more blowing is possible.
Hi Chip,
What is still not clear to me is that, once all the fuses are blown (hypothetically), if one can still use the P2 without any security features.
The fuses are set up in hardware such that once the master fuse is blown, no more blowing is possible.
That's the usual path, and that means it already does what is requested ?
If someone blows only the master fuse, no other fuses can be changed accidentally.
It does mean someone cannot test the fuses, on a development board, so I'm not sure you would want to ship every board like this, but there are some use cases (like class rooms) where less risk is a better compromise.
The other way might be to treat the case "all fuses blown" the same as "none of them blown". That way you can always get back to something operable but not secure
If you allow all fuses blown =insecure, then it opens the possibility of defeating the security.
IMHO, if a user blows the master fuse, that is it! So a commercial customer who requires security blows the key and then the master. That is it! No way around it.
The problem with other micros being bricked is because those fuses are used to select options during normal programming with some of those pins being redefined by blowing the fuses (flash).
But, blowing the master fuse does not mean that the device is secure - that depends on the key being blown. This way, a P2 can be protected from being bricked without necessarily using security keys.
But the way I see it is if there is a security disable fuse which is usually set for development purposes or unbricking after testing or accidentally tripping security during development then the device is still secure, isn't it? The code in SPI Flash is encrypted and now the desecured device can't run it anymore, what's the problem? Well it might be possible to get a secure device and desecure it and on reset load in a small hub memory dump routine but not if the boot rom always cleared RAM, just as a precaution.
But the way I see it is if there is a security disable fuse which is usually set for development purposes or unbricking after testing or accidentally tripping security during development then the device is still secure, isn't it?
Yes and no, Security can mean more than just code readout.
There are many applications where designers need to prove their code cannot be replaced by other code, that emulated the device, with 'extras added'.
That means any fuse path that allows disable and code replacement, is failing full security.
This becomes a little circular - if someone wanted to prevent 'accidental' fuse blow, then adding another 'enable fuses' would avoid blowing the master, but adding such a fuse is only partial protection, a complete novice may still fumble, or a deliberate 'bored student' attack can still brick a unit.
I think what is there now, is how it has to work.
ie Blow the master, if you want fuseless debug-only.
I don't normally comment on security topics but I will say the reason not to change the finality of the master bit has nothing to do with security level, since the security is built around knowing the key rather than erasing it, but rather the opposite bricking effect of accidentally wiping a valid key in the field.
Yes, simply blowing the master bit without setting any of the key seems like a way of ensuring both no encryption and no further changes possible.
I was hoping that this was outlined somewhere, and would expect some form of authenticated encryption is used so that an attacker can't alter code. (Maybe by altering code you're able to get a foot in the door.)
It sounds like maybe they were going with an approach such as "Authenticate using a MAC (e.g., HMAC) and encrypt using a block cipher (e.g., AES-CBC)" and not something like AES-CCM or AES-GCM. (OCB is patented but it is possible to get a free license - http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm)
For the former you probably want separate keys for authentication and encryption, so I think you need more fuses. Something to think about?
You'll need to read the old docs at the very least. There was much discussion at the time, I'm pretty certain everything was tested too. I never paid it any attention myself.
So the boot loader (stored in the clear) is authenticated via HMAC-SHA-256 (parallax has a secret key buried in the chip that's used for this and it could be 512-bits), after that things are only AES-CBC decrypted and not authenticated by the boot loader with a 128-bit key stored in fuses. No tamper detection is done on the loaded code. Which is probably fine for this market.
256 programmable fuses for code security and user application
- First 128 are used for SHA256 loader signature verification
- Next 127 can be used for AES128 main code decryption or user application
- Last 1 writeprotects the rest
- Fuses can be hidden before user code executes
16KB ROM for bootup
- Flash/serial boot
- SHA256 signed loader verification
- Default serial monitor, allows simple host interface
Although, I think most of that is still just plans based on the Prop2-Hot reference.
Since it's software there should be some flexibility. Off-the-cuff I would think that authenticated-encryption could be used for the loader and main code, but maybe I'm missing something. If fuses are used for the boot loader authentication, then it sounds like customers can customize it and it can be patched in case any attacks are found.
Something seems funny but maybe I'm wrong. Hashes have security key_len/2 due to birthday attacks, so that may mean 64-bit security for the signature check. I'm not a cryptographer so maybe that's not applicable here, but I would recommend checking that out.
Also this chip development has taken so long that NIST has a SHA-3 standard, and some SHA-3 mores are in the works. e.g. MAC without needing HMAC, and authenticated encryption. e.g. see http://keccak.noekeon.org. Maybe there will be additional NIST standards before the Propeller 2 tapes out.
It would be interesting to see how the code size and speed of SHA-3 (and future modes) compares to HMAC-SHA-256 and AES128-CBC with the prop2 instruction set - is it 2X as slow?
(And if you're paranoid you can read about some of the SHA-3 conspiracy theories.)
Comments
That's right, though we could do what samuell asked, as it's just a firmware matter.
The fuses are set up in hardware such that once the master fuse is blown, no more blowing is possible.
What is still not clear to me is that, once all the fuses are blown (hypothetically), if one can still use the P2 without any security features.
Kind regards, Samuel Lourenço
That's the usual path, and that means it already does what is requested ?
If someone blows only the master fuse, no other fuses can be changed accidentally.
It does mean someone cannot test the fuses, on a development board, so I'm not sure you would want to ship every board like this, but there are some use cases (like class rooms) where less risk is a better compromise.
IMHO, if a user blows the master fuse, that is it! So a commercial customer who requires security blows the key and then the master. That is it! No way around it.
The problem with other micros being bricked is because those fuses are used to select options during normal programming with some of those pins being redefined by blowing the fuses (flash).
But, blowing the master fuse does not mean that the device is secure - that depends on the key being blown. This way, a P2 can be protected from being bricked without necessarily using security keys.
There are many applications where designers need to prove their code cannot be replaced by other code, that emulated the device, with 'extras added'.
That means any fuse path that allows disable and code replacement, is failing full security.
This becomes a little circular - if someone wanted to prevent 'accidental' fuse blow, then adding another 'enable fuses' would avoid blowing the master, but adding such a fuse is only partial protection, a complete novice may still fumble, or a deliberate 'bored student' attack can still brick a unit.
I think what is there now, is how it has to work.
ie Blow the master, if you want fuseless debug-only.
Yes, simply blowing the master bit without setting any of the key seems like a way of ensuring both no encryption and no further changes possible.
Where is the best place to look for a description of this? I thought that HMAC-SHA-256 was the plan?
Encryption is ROM feature. It was functioning in the Prop2-Hot but may not have been bought over to the current Prop2 just yet. Scan Cluso's links - http://forums.parallax.com/discussion/144199/propeller-ii-emulation-of-the-p2-on-fpga-boards-prop123-a7-a9-de0-nano-de2-115-etc/p1
It sounds like maybe they were going with an approach such as "Authenticate using a MAC (e.g., HMAC) and encrypt using a block cipher (e.g., AES-CBC)" and not something like AES-CCM or AES-GCM. (OCB is patented but it is possible to get a free license - http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm)
For the former you probably want separate keys for authentication and encryption, so I think you need more fuses. Something to think about?
http://forums.parallax.com/discussion/138403/parallax-propeller-2-code-authentication-and-protection/p1
So the boot loader (stored in the clear) is authenticated via HMAC-SHA-256 (parallax has a secret key buried in the chip that's used for this and it could be 512-bits), after that things are only AES-CBC decrypted and not authenticated by the boot loader with a 128-bit key stored in fuses. No tamper detection is done on the loaded code. Which is probably fine for this market.
It seems he was the one spearheading the work.
Although, I think most of that is still just plans based on the Prop2-Hot reference.
Also this chip development has taken so long that NIST has a SHA-3 standard, and some SHA-3 mores are in the works. e.g. MAC without needing HMAC, and authenticated encryption. e.g. see http://keccak.noekeon.org. Maybe there will be additional NIST standards before the Propeller 2 tapes out.
It would be interesting to see how the code size and speed of SHA-3 (and future modes) compares to HMAC-SHA-256 and AES128-CBC with the prop2 instruction set - is it 2X as slow?
(And if you're paranoid you can read about some of the SHA-3 conspiracy theories.)