QUestion about code security feature
78rpm
Posts: 264
in Propeller 2
Code security would inhibit anybody from modifying any program images. If changed, they just wouldn't work.
I started a new thread/topic as this is about security and not debug. From this original comment.
forums.parallax.com/discussion/comment/1347910/#Comment_1347910
That means the code security is completely facilitated in hardware at firmware load time?
Can it also be invoked if the product requires use of additional firmware or data (like the Prop 1 upper EEPROM data > 32KB) later in the same run, in effect an overlay, or would it have to be decoded by a routine already loaded within the firmware?
If it is available in hardware, can the binary source be other than the boot flash, eg. an encrypted image on an SD card or serial interface?
Comments
I assume the ROM will be in the address space at runtime, so it's possible to call those ROM routines during application run to authenticate overlays. The problem is that the secret key is hidden by that time, so you can't check the code with that key at runtime.
Originally we discussed making the user bootloader responsible for getting rid of the key, if that was implemented, the user bootloader would be able to keep the key around in RAM for later authentication of overlays.
The simplest way to make this work would be to authenticate the entire ram space after loading, but with 512K of ram, that could mean long boot times. Thus the idea of staged booloaders was born. The monitor would only authenticate 2K that was loaded into the COG at boot, then that program would be a secondary loader that would talk to the EEPROM or SD card, loading RAM images and authenticating them. The problem with this approach is that it leaves security up to the user and it is only as secure as their code. If an attacker figures out a way to inject code and read the key at runtime, it could compromise the chip and allow them to sign their own code.
My proposed solution to get around this and the "downrev" attack (loading old firmware on a device so to take advantage of exploits in it) is to use the other 32 or so 'user' bits. 128 bits is to be dedicated to a key, and 32 bits would be for user flags. Every time you come out with a critical update, the update makes sure one of the consecutive bits is blown.
If the monitor rom authentication uses the user bits as part of a perturberance of the hash, the hash won't match on earlier and later code, so only code that was designed for the blown bits would hash properly and run.
This "downrev attack" mitigation won't work properly without ROM monitor support for user bit perturberance if the keys is known, then again if the key is known, the attacker can generate a new firmware that is perturbed with the newer bit pattern too.
So anyway, basically if your key gets out, it's over. This is why I think it would be wise for companies to generate unique keys per lot or per device, then burn the chip with a unique key for every device produced. You would track these keys in a database and when the customer wants a firmware download, you'd take the basic firmware, then sign it with the key for that customer, all as part of the download process from the company website.
I envisioned writing a wizard tool that allows you to do a few different signing and encryption things with the chip: burn chip with same key as all chips, burn unique key to each chip, sign payloads for chip, sign and encrypt payload. For this to be useful, a reference 2nd stage bootloader would be necessary to offer authentication and decryption.
So in answer to my question about additional code or data (overlays / upper EEPROM / FLASH / SD blocks), it would be a developer action, with a private key for the extra code/data held in the originally booted firmware load which is now running, and a public key embedded within the extra code/data that is accessed from storage?
If that is correct an OBEX2 / library function would be beneficial for developers.