Securing IP (Again...)
Chad George
Posts: 138
I know the issue of securing IP in the propeller has come up before, but I don't know if a definitive answer was ever given as to how to do this under the current limitations of the propeller.
After doing some thinking and research, here is the scheme that I've come up with. Of course there is some (temporary) security in just coming up with an obscure mechanism and sitting on it, but I believe a truly secure mechanism should be open to public scrutiny so I'm very interested in opinions and potential weaknesses. I realize that nothing is 100% secure, but it just seems like it should be possible to have something reasonably secure using the currently available propeller (hopefully Prop2 will have something built in to help)
Just to be clear, my objective is to obtain a mechanism where secured (encrypted) IP code in the EEPROM can be loaded into the propeller.
I'm making the assumption that good cryptographic routines can be written for both the propeller and some external micro controller that does have some level of industry accepted IP protection (such as a PIC) I believe from other threads that a good random number generator has been developed which would be critical for the propeller side of things.
The algorithm is based on what I understand is possible using symmetric key encryption, but my crypto knowledge is fair from expert, so please correct me if I'm off track. I'll use a notation of KEY() to represent a function that encrypts with some key and the inverse function to represent decrypting with the key. I'm using two different forms of encryption: one where there is a private and public key as a set and one where there is just one key which can be used for both encryption or decryption.
I'm assuming the following basic hardware is in place. Of course just one EEPROM could be used for both EEPROM functions and certainly there are other options than a PIC but that is what I'll refer to.
Propeller <- Unsecured Boot EEPROM
Propeller <- Secured Micro (PIC) <- Encrypted EEPROM
I've attached a sequence diagram showing the basic flow of the proposed algorithm, but I'll discuss the main steps briefly to try to explain what I was thinking.
First a super secret key is used to encrypt the IP protected code stored in the EEPROM. This key is only stored in the PIC and it never exists outside of the PIC.
- At bootup or reset an unsecured bootstrap program is loaded into a cog. To prevent certain attacks I believe this must be an assembly routine so that it isn't using any Shared Memory.
- the bootstrap sends a start command to the PIC, which replies with a randomly generated public/private key (K0)
- the propeller uses K0 to encrypt its own randomly generated key K1 which is sent encrypted using K0 to the PIC
Now we should have a secret key known only to the Propeller and PIC that was never sent in plain text and also should never be the same twice. In order to try to prevent an emulation attack (either external or in circuit), the next phase uses the propeller like a "security dongle" by dynamically creating some a random validation program into the RAM of the currently running cog.
The validation program is sent in encrypted chunks and should be able to establish itself arbitrarily covertly by overwriting instructions, destination and source addresses directly in the RAM of the COG. This validation program can be as complicated as the designer deems necessary, but should definitely:
- manage to stop any other running cogs (so that some clever hacker doesn't snoop on Shared Memory)
- verify within reason that its actually a real propeller being run (not some emulation) probably by using timing routines
- the original unsecured bootstrap should be entirely wiped out so that only trusted code is being run. Alternatively a hash on the boot eeprom might be sufficient for some applications, but its seems possible that a "swap" could be made to trick the PIC so its probably best to make the check in software while running the trusted "random" validation program
- establish a new private key (K2) after we know that its only our secure code that is running (the original bootstrap has been completely wiped out)
- establish a random inital state variable (S0) which can be the seed of a deterministic pseudo random sequence
Now we can trust the code running in the propeller and we have secret keys to transfer the actual IP code securely
- The PIC reads a random block of the encrypted code from the secured EEPROM and decrypts it internally using its stored secret key. Which block to transfer is determined by the current pseudo-random state variable.
- The PIC re-encrypts the block code using the K2 key and sends it to the Propeller
- The propeller uses the K2 key to decrypt the code block and its state variable S0 to decide where to put it
- Both the PIC and Propeller generate the next pseudo-random state and the processes is repeated until the entire program is loaded into RAM.
After doing some thinking and research, here is the scheme that I've come up with. Of course there is some (temporary) security in just coming up with an obscure mechanism and sitting on it, but I believe a truly secure mechanism should be open to public scrutiny so I'm very interested in opinions and potential weaknesses. I realize that nothing is 100% secure, but it just seems like it should be possible to have something reasonably secure using the currently available propeller (hopefully Prop2 will have something built in to help)
Just to be clear, my objective is to obtain a mechanism where secured (encrypted) IP code in the EEPROM can be loaded into the propeller.
I'm making the assumption that good cryptographic routines can be written for both the propeller and some external micro controller that does have some level of industry accepted IP protection (such as a PIC) I believe from other threads that a good random number generator has been developed which would be critical for the propeller side of things.
The algorithm is based on what I understand is possible using symmetric key encryption, but my crypto knowledge is fair from expert, so please correct me if I'm off track. I'll use a notation of KEY() to represent a function that encrypts with some key and the inverse function to represent decrypting with the key. I'm using two different forms of encryption: one where there is a private and public key as a set and one where there is just one key which can be used for both encryption or decryption.
I'm assuming the following basic hardware is in place. Of course just one EEPROM could be used for both EEPROM functions and certainly there are other options than a PIC but that is what I'll refer to.
Propeller <- Unsecured Boot EEPROM
Propeller <- Secured Micro (PIC) <- Encrypted EEPROM
I've attached a sequence diagram showing the basic flow of the proposed algorithm, but I'll discuss the main steps briefly to try to explain what I was thinking.
First a super secret key is used to encrypt the IP protected code stored in the EEPROM. This key is only stored in the PIC and it never exists outside of the PIC.
- At bootup or reset an unsecured bootstrap program is loaded into a cog. To prevent certain attacks I believe this must be an assembly routine so that it isn't using any Shared Memory.
- the bootstrap sends a start command to the PIC, which replies with a randomly generated public/private key (K0)
- the propeller uses K0 to encrypt its own randomly generated key K1 which is sent encrypted using K0 to the PIC
Now we should have a secret key known only to the Propeller and PIC that was never sent in plain text and also should never be the same twice. In order to try to prevent an emulation attack (either external or in circuit), the next phase uses the propeller like a "security dongle" by dynamically creating some a random validation program into the RAM of the currently running cog.
The validation program is sent in encrypted chunks and should be able to establish itself arbitrarily covertly by overwriting instructions, destination and source addresses directly in the RAM of the COG. This validation program can be as complicated as the designer deems necessary, but should definitely:
- manage to stop any other running cogs (so that some clever hacker doesn't snoop on Shared Memory)
- verify within reason that its actually a real propeller being run (not some emulation) probably by using timing routines
- the original unsecured bootstrap should be entirely wiped out so that only trusted code is being run. Alternatively a hash on the boot eeprom might be sufficient for some applications, but its seems possible that a "swap" could be made to trick the PIC so its probably best to make the check in software while running the trusted "random" validation program
- establish a new private key (K2) after we know that its only our secure code that is running (the original bootstrap has been completely wiped out)
- establish a random inital state variable (S0) which can be the seed of a deterministic pseudo random sequence
Now we can trust the code running in the propeller and we have secret keys to transfer the actual IP code securely
- The PIC reads a random block of the encrypted code from the secured EEPROM and decrypts it internally using its stored secret key. Which block to transfer is determined by the current pseudo-random state variable.
- The PIC re-encrypts the block code using the K2 key and sends it to the Propeller
- The propeller uses the K2 key to decrypt the code block and its state variable S0 to decide where to put it
- Both the PIC and Propeller generate the next pseudo-random state and the processes is repeated until the entire program is loaded into RAM.
2201 x 1701 - 57K
Comments
The issue that comes up over and over again is that any scheme is breakable given adequate resources (and incentive). It's possible to remove the potting compound from the PIC and monitor some of the signals in real time using an electron beam scanner if the need is great enough.
The trick is coming up with a scheme that's cheap and easy enough to use without pricing your own product out of the market or rendering it too unreliable or slow, yet is expensive enough to break that nobody will bother trying until your product has been out on the market long enough for you to finish your own upgrade cycle and put out a cost-effect improved version that your thief will just have to break again.
As for prop code security, Moore's dictum of misnamed objects may quite enough.
This means it can be disassembled, understood and modified.
When the second phase begins, and it begins loading the chunks of 'secure' loader, there's nothing to stop a hacked bootloader from passing the 'secure' program on through a serial link.
The 'secure' program being in chunks just means the disassembly takes a bit longer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Of course you could easily spoof the K1, but that will not directly help get to the secret key in the PIC that the EEPROM is encrypted with. The initial K0 key is a randomly generated public/private key created each time phase 1 is initiated. It is only used to encrypt the K1 key during transmission between the Propeller and the Prop, after that it is never used again. All of Phase 1 could be spoofed and I assumed that it would be, but it does setup an environment where you are forced to emulate the prop to get into Phase 2.
Yes, this is probably the weakest link, but the process can be as convoluted as the designer wants it to be. I intended on the validation program to build itself while running pieces of itself. All the while using periodic challenge/response phases that try to ensure the "real" program is running before sending anymore of the validation program. Also the validation program itself could change which challenges it creates every time it runs.
Again I agree, but this seems like it would take an immense effort. Especially if the validation program used known characteristics of both SPIN, assembly and the propeller architecture. If timing between challenges was utilized it would pretty much rule out a software emulator. So any hardware emulation would have to first break all of the secured IP that parallax has in their product. I don't have much experience in this level hacking and maybe someone who does this all the time will correct me and say this is a trivial thing to solve, but unless it is much much easier than methods required to crack other "secured" microcontrollers it seems like this still might be a competitively secure scheme.
In order for this to actually be secure we have to go one step further and release the source for the bootstrap. The entire Phase 1 process should be completely open both on the secured PIC side and the Propeller. A potential hacker has to get through the obfuscation tricks in Phase 2 in order to see any of the secured code in the EEPROM and would have to break the PIC's IP protection scheme to get at the PIC side Phase 2 algorithm.
I agree but once Phase 2 does a little verification that its not dealing with an emulator (which could be a little different every time), the validation programs will completely stop the original bootloader (and any other cogs for that matter) so by the end of phase 2 its only secure code running.
Unless someone sees an obvious way around it I think the only way to get through phase 2 is to "emulate" the propeller in hardware. And even if hardware emulation wasn't a problem there is still the issue of reversing all of the dynamic generated challenge/response scenarios.
IMHO, if the only crack is breaking the IP protection used by "everyone else" or to somehow reverse all the "IP" that Parallax already has in the chip, then maybe this is good enough.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Isn't that what·I said 4 posts prior?
"the app is on the pic, which is downloaded to the prop, through rs232, like when PC is connected to prop, could remove i2c eeprom then too unless it was required [noparse]:)[/noparse]"
But that could then be hacked, like Paul Baker·said, because they remove the pic, and emulate a prop reading it.
One possible cipher/decipher pair could be a PRBG where the key is simply a seed that is common to the fuse in the Propeller and the PC.
In the meantime, use epoxy glue. Fundamentally, anything the current Prop loads externally at boot up can be copied and studied.
Frank