Where that equation is favorable, security will be broken, because it's worth breaking it. Where it's not, it may still be broken, but the low reward limits the scope of attacks, and or chance of attack.
There was some excellent work done by Lawson in this thread about keeping the Prop running at low voltages.
Some initial calcs ignoring self discharge for the moment... a 0.9Farad supercap supplying 1.5uA from 2.7v down to 0.9v should do so for the order of 1 week.
There was some excellent work done by Lawson in this thread about keeping the Prop running at low voltages.
Some initial calcs ignoring self discharge for the moment... a 0.9Farad supercap supplying 1.5uA from 2.7v down to 0.9v should do so for the order of 1 week.
My suggestion for this would be to just use a surface mount battery. They don't cost any more than a super-cap and store a LOT more energy. (P223-ND or P191-ND from digikey look nice, an alkaline or silver oxide battery would also work for shorter periods.) I'd use a pair of lower leakage schottky diodes to prevent the prop from back feeding power to the main power supply, or the battery. (you'd also need to be careful to avoid leaking power into the unpowered circuits surrounding the prop) Assuming a 190mAh cell and a 2uA standby draw at the battery, the prop should be able to maintain it's ram for ~95,000 hours or about 10 years.
One thing to be careful of at low voltages is triggering the power on reset circuit. I think it arms in the neighborhood of 1 volt and will reset the prop if the supply voltage is raised too fast. (within less than a second or so)
You could just have the code you care about only in COG RAM.
Then, even if there were some magic you could play with the Bootloader (which maybe only Chip would know about),
there would be no way to extract the code from a COG.
I did find a moment to bug Chip about this question at UPEW...
He doesn't see any way that the bootloader could be hacked to get the code out of RAM.
So, unless you deliberately program a back door, there's no way to get the code.
It also occurred to me that you could install cipher keys in RAM at the factory and use them to decrypt some new code in say SD card or so.
So, that way the firmware could be field programmable, but remain secure.
The only condition on all of this is that the Prop remained powered. I don't think that's really so hard. With a small LiPo pack, and the Prop powered down the RCslow and 1 cog, I bet it could go months...
Rayman your idea of pushing the really critical stuff (cipher) all the way into a cog is great. It means we can still mess with hub ram.
I wonder if it would be possible to have a combined cog that did say, the viewport conduit for access to hub ram, as well as decipher using a key stored in the cog?
I wonder whether we can come up with a design that fools the Prop Tool or BST into thinking its reloading the prop as per usual, but in reality that critical cog is left running in the background? We might need an input into the prop for "power on" - ie go from RCSLOW to XTAL1, and another input for "soft reset" to initiate the hub ram reloading...
Tubular: I would think it would be quite easy to make the prop simulate the reset for a propload. Just need a cog sitting waiting for the reset (on a prop pin instead of reset) and then to do what is required. I had this in mind for using the pro to simulate the FTDI chip and do USB (starting with Brad and Michas codes). It would not be necessary to go back to RCSLOW, just as long as the speed and protocol were correct.
Hi!
I love the idea of keeping cipher code running inside a cog- leaving the rest of the Prop for whatever you want. The ViewPort conduit has always supported writing data to HUB and starting/stopping individual cogs- so I could implement this pretty easily. Something like this:
- the ViewPort conduit supports ViewPort debugging and it provides an "unhackable" custom cipher. It periodically picks up a "question" from a fixed memory location and stores the "answer" in another. You program this into the Prop once and then keep power connected forever... From this point on, this is a "custom" Prop that noone can replicate.
- At any later point, you upload code to the Prop and "soft-restart" it.
Any interest?
Hanno
Actually, There is one issue still remaining: side channel attacks on the running code. The idea here is that if you look very carefully at current draw, a correlation can usually be made between specific current levels and durations to individual opcodes being executed.
The usual use of this type of thing is to break crypto keys - if I know you're using, say, AES-128 on a chip and can feed it nonesense, I can track what opcodes used and back out whether a specific bit in a key is a hit or miss based on how the hardware behaves. Key here is that I know your algorithm. I think that you can extend this to generating an opcode list as a program runs and infer the program. The extent to which having eight cogs running - perhaps - asynchronously makes this a living hell is a very good question. Wish I had the time to try
madrfskills, that's an interesting idea... the side channel attack...
Not sure how much use that would be on a RISC chip though where there's only a handful of opcodes.
Still, if you wanted to be diabolical, you could use Chip's "real random" code to insert some truly random code into the mix.
Also, as you point out, you could start a few dummy cogs to do fake work on the same input....
Sidechannel attacks typically rely upon differences in execution speed between fail, partial success and pass cases. Think of a password check routine which exits when the first incorrect character is found. So instead of a O(N^m) attack, you can get it down to an O(n*m) attack. (Assuming the time difference can be measured.)
However, AES (and other stream ciphers) have no knowledge whether the output is plaintext or garbage. It just runs through the translation sequence given the ciphertext, key and initialization vector. Public key crypto or digital signature validation might be more vulnerable. (Then again, the only way the Atari 7800 (6502) digital signature was broken is when disks with the original private key were found.)
Hmm... you might be able to determine some of the properties of an embedded AES private key (i.e. number of 1 bits) if you had access to the same code and could run the test cipher text with various keys. But I think the AES key expansion might make even that information difficult to determine. (I'm no cryptie, but I've known a couple and written AES for the Prop.)
Eric, did you do your AES implementation in spin or pasm? What size, approximately? ie would it fit in a cog?
Hanno, I'm certainly interested. If done right we should be able to encrypt a secure serial stream (ie viewport conduit). I have an immediate application for something like that.
Eric, did you do your AES implementation in spin or pasm? What size, approximately? ie would it fit in a cog?
It's a set of PASM routines rather than a full driver. Adding data movement (along with the steps needed to support multi-block modes) is left to the implementor. Everything but two 256 byte tables fits in one cog (with space to spare). Key Expansion ~4.4K cycles, Cipher ~16.1K cycles/16 byte block (77.6Kbyte/s at 80MHz), Inverse Cipher ~18K cycles/16 byte block (69.4Kbyte/s at 80MHz).
Hmm... looking at the code I don't see any if / else branches which could be used in a side-channel attack. Might be able to get something based on power consumption, but that's even more difficult than timing analysis.
Hi Tubular,
I've started sketching out the additions I'll have to make to conduit to make this happen. I'm still travelling and presenting so will need a bit more time. But I think the end result will be a very secure platform for the Propeller. You'll need to keep your Prop powered continually from the factory with a cheap/simple mounted battery, but that'll give you a unique Propeller that no one can replicate. And yes, you could even deliver encrypted updates to end users that are only decrypted by the conduit object into hub ram. If anyone else is interested in keeping their Propeller code secure, please let me know.
I highly, highly doubt that it's possible to gain any usable information by tracking power consumption of a Propeller running code on multiple cogs- sounds like I'll have to start another of my "I'll eat a propeller chip if someone can..." competitions.
Hanno
Hanno: Next they will be using infra-red to sense the heat on the chip to debug it. Without those sorts of anciliaries, noone is going to crack the code in the prop if it is held by a battery and not hooks are provided. So that prop for human consumption is well and truly safe from being eaten.
I've been working away on this in the background, sourcing some parts (batteries, schottky diodes, rtcs, etc). I have a few other ideas which I'll present here once I've verified that they work. Unfortunately there is a bit of r&d paperwork for getting this project up and running, so no hurry from me Hanno.
This would make a good industrial/commercial "package" - a secure prop with debugging / visualization capabilities of viewport.
Also I don't see why this can't be incorporated into a Parallax Semiconductor application note once its all proven and settled.
I think this could be defeated IF you could de-encapsulate the propeller while it's powered. (with the clock halted to avoid any dead-man switches in the code) With a de-encapsulated Propeller the state of the SRAM could be probed, or the hub could be cut free of the cogs and run manually. Flylogic's Analytic blog shows examples of de-encapsulating done to several unpowered chips. (imho, Flylogic would be a good spot to send a "secure" Propeller for testing.)
De-encapsulating a powered propeller is a significant technical hurdle. The acids usually used are likely to either short out the power rails, cause severe galvanic corrosion, scramble the chip with stray currents, or all three. A gas phase erosion technique may avoid the stray currents and galvanic corrosion but I don't know of any off hand. (a jet of Argon spiked with atomic Oxygen?)
I don't think we are talking about companies/persons with $M to spare to find out what is inside the chip. It would be cheaper to design the product.
The powered idea is probably the most foolproof methods thought of. I am pretty sure it would be more secure that anything in flash, no matter what encryption is available.
Actually the approach likely to be used would be to flash-freeze the prop with liquid nitrogen or argon, mill the cap off under cryogenic conditions (yes there are tools for this), and then directly probe the RAM array to read out the contents. You can extend RAM retention time without refresh to several minutes at cryogenic temperatures... Should be within the reach of a decent SME with access to University-level VLSI lab facilities.
Worked on a job once where we had materials under a chip die chosen such that their coefficient of thermal expansion was such that they would physically disrupt the die if flash frozen. Seemingly great idea, but the flip side is that you get a lot of mechanical strain as the chip thermal cycles in operation. Doubleplus ungood. I wonder if this works yet or if we just threw up our hands in disgust and declared success anyways.
I'd say it's pretty good security, if it'd take university level efforts to break it. The kind of hacks I was reading about for getting at flash could be done by teenagers at home without any special tools...
Universities in the USA anyway would probably be too worried about DMCA to risk a group effort on something like this...
So here's my proposed circuit diagram for supporting hardware for this. Lithium coin cell and some schottky diodes.
I'm going to try using the "open drain" SCL and SDA lines for detecting the soft reset and loss of incoming power and see how it goes. Anybody spot any glaring faults in this? I guess it might get complicated for applications where the I2C bus gets used after boot, in which case I could just use an extra prop pin instead.
Looks good. Don't really see the need for D16...
Also, I'd worry a little about the variable voltage drop on D13 and D16.
I think maybe I'd have main power at +5 V and use a 3.3 V regulator instead of D13...
Just a thought.
D16 just brings peripheral chips to around the same rail voltage as the prop. Ideally the schottky voltage drop would be low enough so that the prop's substrate diodes don't start to conduct, but there is a bit of variation amongst the shottkys, and I figured one extra diode (same part#) would do more good than harm. When I fire this circuit up I'll check what the rail mismatch is in mv at various peripheral loadings.
The parallax copyright is due to me grabbing the (open source) Quickstart schematic as a starting point for mods. I'll clean that title block up, but only had 30 mins to throw at this at lunchtime, and wanted to try and revive this sooner rather than later.
We need to come up with something like a functional design spec for what that permanent cog needs to do
1) Reside in say cog 7 where it is "most" out of the way?
2) Watch for soft resets, and simulate the prop internal boot loader for transparency with existing tools, but keep cog 7 untouched
3a) Watch for loss of incoming DC, and drop back to RCSLOW when power is lost,
3b) as well as putting IO pins into their low power state (input, output low, etc depending on what they are connected to)
4) Provide a conduit (viewport or similar to viewport) for reading/writing hub ram,
5) Optional encryption and decryption of the data streams for 2) and 4) ?
6) Optional tamper detection and key / cog 7 / hub memory erase ?
...
7) Optional RTC-like scheduler for periodic wake up
8) Optional slow recovery via resistor if the battery voltage is below 1.41v (Lawson identified need for slow rising supply voltage to avoid triggering the power-on reset)
#6 Tamper detection requires a clock source internal to the Prop. Otherwise an attacker can just stop the prop's clock to bypass any tamper detection code. The PLL modes may be acceptable too, depending on what happens if you stop the crystal. (or hi-jack the crystal and ramp it's frequency to zero smoothly)
#4 debug conduit, would have to be heavily encrypted. Otherwise it's a back-door to bypass all the work done to secure the hub image.
#2 I don't think programming wouldn't require encryption as long as hub memory was completely cleared any time a programming cycle started. At this point you'd protect the program the same way all companies protect trade secrets, don't tell anyone and carefully track all copies of the program. (encryption would still be useful for on-site maintenance where loosing the programmer is a risk)
Comments
Where that equation is favorable, security will be broken, because it's worth breaking it. Where it's not, it may still be broken, but the low reward limits the scope of attacks, and or chance of attack.
Some initial calcs ignoring self discharge for the moment... a 0.9Farad supercap supplying 1.5uA from 2.7v down to 0.9v should do so for the order of 1 week.
About .35 Yuan for a single egg...
My suggestion for this would be to just use a surface mount battery. They don't cost any more than a super-cap and store a LOT more energy. (P223-ND or P191-ND from digikey look nice, an alkaline or silver oxide battery would also work for shorter periods.) I'd use a pair of lower leakage schottky diodes to prevent the prop from back feeding power to the main power supply, or the battery. (you'd also need to be careful to avoid leaking power into the unpowered circuits surrounding the prop) Assuming a 190mAh cell and a 2uA standby draw at the battery, the prop should be able to maintain it's ram for ~95,000 hours or about 10 years.
One thing to be careful of at low voltages is triggering the power on reset circuit. I think it arms in the neighborhood of 1 volt and will reset the prop if the supply voltage is raised too fast. (within less than a second or so)
Lawson
You could just have the code you care about only in COG RAM.
Then, even if there were some magic you could play with the Bootloader (which maybe only Chip would know about),
there would be no way to extract the code from a COG.
He doesn't see any way that the bootloader could be hacked to get the code out of RAM.
So, unless you deliberately program a back door, there's no way to get the code.
It also occurred to me that you could install cipher keys in RAM at the factory and use them to decrypt some new code in say SD card or so.
So, that way the firmware could be field programmable, but remain secure.
The only condition on all of this is that the Prop remained powered. I don't think that's really so hard. With a small LiPo pack, and the Prop powered down the RCslow and 1 cog, I bet it could go months...
Rayman your idea of pushing the really critical stuff (cipher) all the way into a cog is great. It means we can still mess with hub ram.
I wonder if it would be possible to have a combined cog that did say, the viewport conduit for access to hub ram, as well as decipher using a key stored in the cog?
I wonder whether we can come up with a design that fools the Prop Tool or BST into thinking its reloading the prop as per usual, but in reality that critical cog is left running in the background? We might need an input into the prop for "power on" - ie go from RCSLOW to XTAL1, and another input for "soft reset" to initiate the hub ram reloading...
Good stuff... thanks for checking with Chip
I love the idea of keeping cipher code running inside a cog- leaving the rest of the Prop for whatever you want. The ViewPort conduit has always supported writing data to HUB and starting/stopping individual cogs- so I could implement this pretty easily. Something like this:
- the ViewPort conduit supports ViewPort debugging and it provides an "unhackable" custom cipher. It periodically picks up a "question" from a fixed memory location and stores the "answer" in another. You program this into the Prop once and then keep power connected forever... From this point on, this is a "custom" Prop that noone can replicate.
- At any later point, you upload code to the Prop and "soft-restart" it.
Any interest?
Hanno
The usual use of this type of thing is to break crypto keys - if I know you're using, say, AES-128 on a chip and can feed it nonesense, I can track what opcodes used and back out whether a specific bit in a key is a hit or miss based on how the hardware behaves. Key here is that I know your algorithm. I think that you can extend this to generating an opcode list as a program runs and infer the program. The extent to which having eight cogs running - perhaps - asynchronously makes this a living hell is a very good question. Wish I had the time to try
Not sure how much use that would be on a RISC chip though where there's only a handful of opcodes.
Still, if you wanted to be diabolical, you could use Chip's "real random" code to insert some truly random code into the mix.
Also, as you point out, you could start a few dummy cogs to do fake work on the same input....
However, AES (and other stream ciphers) have no knowledge whether the output is plaintext or garbage. It just runs through the translation sequence given the ciphertext, key and initialization vector. Public key crypto or digital signature validation might be more vulnerable. (Then again, the only way the Atari 7800 (6502) digital signature was broken is when disks with the original private key were found.)
Hmm... you might be able to determine some of the properties of an embedded AES private key (i.e. number of 1 bits) if you had access to the same code and could run the test cipher text with various keys. But I think the AES key expansion might make even that information difficult to determine. (I'm no cryptie, but I've known a couple and written AES for the Prop.)
Hanno, I'm certainly interested. If done right we should be able to encrypt a secure serial stream (ie viewport conduit). I have an immediate application for something like that.
It's a set of PASM routines rather than a full driver. Adding data movement (along with the steps needed to support multi-block modes) is left to the implementor. Everything but two 256 byte tables fits in one cog (with space to spare). Key Expansion ~4.4K cycles, Cipher ~16.1K cycles/16 byte block (77.6Kbyte/s at 80MHz), Inverse Cipher ~18K cycles/16 byte block (69.4Kbyte/s at 80MHz).
Forum
ObEx
Hmm... looking at the code I don't see any if / else branches which could be used in a side-channel attack. Might be able to get something based on power consumption, but that's even more difficult than timing analysis.
I've started sketching out the additions I'll have to make to conduit to make this happen. I'm still travelling and presenting so will need a bit more time. But I think the end result will be a very secure platform for the Propeller. You'll need to keep your Prop powered continually from the factory with a cheap/simple mounted battery, but that'll give you a unique Propeller that no one can replicate. And yes, you could even deliver encrypted updates to end users that are only decrypted by the conduit object into hub ram. If anyone else is interested in keeping their Propeller code secure, please let me know.
I highly, highly doubt that it's possible to gain any usable information by tracking power consumption of a Propeller running code on multiple cogs- sounds like I'll have to start another of my "I'll eat a propeller chip if someone can..." competitions.
Hanno
I've been working away on this in the background, sourcing some parts (batteries, schottky diodes, rtcs, etc). I have a few other ideas which I'll present here once I've verified that they work. Unfortunately there is a bit of r&d paperwork for getting this project up and running, so no hurry from me Hanno.
This would make a good industrial/commercial "package" - a secure prop with debugging / visualization capabilities of viewport.
Also I don't see why this can't be incorporated into a Parallax Semiconductor application note once its all proven and settled.
Enjoy the rest of your trip, Hanno.
cheers
Tubular
De-encapsulating a powered propeller is a significant technical hurdle. The acids usually used are likely to either short out the power rails, cause severe galvanic corrosion, scramble the chip with stray currents, or all three. A gas phase erosion technique may avoid the stray currents and galvanic corrosion but I don't know of any off hand. (a jet of Argon spiked with atomic Oxygen?)
Lawson
Would it be possible to stop the clock if its running on RCslow? Guess it might be possible once the lid is off (carefully).
The powered idea is probably the most foolproof methods thought of. I am pretty sure it would be more secure that anything in flash, no matter what encryption is available.
Worked on a job once where we had materials under a chip die chosen such that their coefficient of thermal expansion was such that they would physically disrupt the die if flash frozen. Seemingly great idea, but the flip side is that you get a lot of mechanical strain as the chip thermal cycles in operation. Doubleplus ungood. I wonder if this works yet or if we just threw up our hands in disgust and declared success anyways.
V/R
Mike
Universities in the USA anyway would probably be too worried about DMCA to risk a group effort on something like this...
I'm going to try using the "open drain" SCL and SDA lines for detecting the soft reset and loss of incoming power and see how it goes. Anybody spot any glaring faults in this? I guess it might get complicated for applications where the I2C bus gets used after boot, in which case I could just use an extra prop pin instead.
Also, I'd worry a little about the variable voltage drop on D13 and D16.
I think maybe I'd have main power at +5 V and use a 3.3 V regulator instead of D13...
Just a thought.
BTW: Why is it copyright Parallax?
The parallax copyright is due to me grabbing the (open source) Quickstart schematic as a starting point for mods. I'll clean that title block up, but only had 30 mins to throw at this at lunchtime, and wanted to try and revive this sooner rather than later.
We need to come up with something like a functional design spec for what that permanent cog needs to do
1) Reside in say cog 7 where it is "most" out of the way?
2) Watch for soft resets, and simulate the prop internal boot loader for transparency with existing tools, but keep cog 7 untouched
3a) Watch for loss of incoming DC, and drop back to RCSLOW when power is lost,
3b) as well as putting IO pins into their low power state (input, output low, etc depending on what they are connected to)
4) Provide a conduit (viewport or similar to viewport) for reading/writing hub ram,
5) Optional encryption and decryption of the data streams for 2) and 4) ?
6) Optional tamper detection and key / cog 7 / hub memory erase ?
...
7) Optional RTC-like scheduler for periodic wake up
8) Optional slow recovery via resistor if the battery voltage is below 1.41v (Lawson identified need for slow rising supply voltage to avoid triggering the power-on reset)
anything else?
#4 debug conduit, would have to be heavily encrypted. Otherwise it's a back-door to bypass all the work done to secure the hub image.
#2 I don't think programming wouldn't require encryption as long as hub memory was completely cleared any time a programming cycle started. At this point you'd protect the program the same way all companies protect trade secrets, don't tell anyone and carefully track all copies of the program. (encryption would still be useful for on-site maintenance where loosing the programmer is a risk)
Lawson
4) Wouldn't this make it less secure?
Nice idea, though! I'm sure it can be made to work.
-Phil