Starting on rev. C silicon, I believe smart pin mode %100010_OHHHLLL can also be useful, since it no longer connects the ADC to the adjacent pin, but would be able to capture the floating bias point of each one.
Unless a varying operational temperature can severelly affect its sense range (or usefulness), perhaps adding those samples into the mix could turn the extraction of the extra bit(s) you are looking for, into a real possibility.
Hope it helps.
Henrique
Yes great idea Henrique.
Unfortunately we can't combine with 100x ADC zoom, but just staring at the signal for longer should make it work
However, it seems like there are a couple of issues. How can we get a consistent 4-bit value over the temperature range? Some, or maybe most of the pins will straddle an adjacent value. As an example, if we read a 4-bit value of 3, then at some other temperature it could be a 2 or maybe a 4.
It may be simpler to store the mid band of each print bar, and then check for excess deviation from that.
That avoids boundary errors, but takes a bit more to store the band values.
UIDs like this could be useful for larger systems and to pass to an overall security checker.
Storing the mid band should allow for verifying the fingerprint. But then what do you do with the fingerprint? This doesn't really solve the code protection problem. It only ensures that the code will run on one chip. And if someone hacks the boot program they can run it on any chip.
Thanks Lachlan, for calling my attention to this particularity.
When I did a look at the pad I/O modes (original V33' docs image) I'd noticed it's still listing this mode as being able to connect the ADC to pin B, wich I know isn't true for Rev. C silicon.
Part of the following note, tagged at 2020_02_24 seems to confirm the finding:
"Received 10 Rev C chips which fix the adjacent-pin ADC crosstalk problem on prior revisions. Smart pin mode %100010_OHHHLLL no longer connects the ADC to the adjacent pin, but floats the ADC input. This mode is now useful for determining the floating bias point of the ADC."
Unfortunately we can't combine with 100x ADC zoom, but just staring at the signal for longer should make it work
Would it means we could leave it as a second and fourth pass, interspersed after the GIO and VIO ones, but with a longer timespan, between the mode setup and the samplings?
Well like I said, the P2D2 has the UB3 as the supervisory micro and security mechanisms and 128-bit UUID communicating with the P2 over I2C. If the P2 fails the security handshaking it could be made to work anyway, but hobbled so that it won't be immediately and directly obvious. The UB3 also has access to the boot pins too and can even load some boot code from its spare flash.
There are all kinds of security schemes possible but the P2 by itself can't really be protected. Maybe the fingerprinting in conjunction with the UB3 could be useful.
To reiterate, it does not matter what is connected to the pins. This is an internal ADC operation that has no electrical relationship to the external pin, other than its local VIO power supply.
I think the only safe way to extract bits from the fingerprint is to pick pin pairs which have at least a 25% full-range difference between readings. That is the coarsest way, anyway.
Does this means that (the deprecated connection to) Pin B's stray capacitance could not be otherwise discharged by any means?
Thus, it'll mostly precharges towards the Vio node it's connected to, and keeps tracking it.
Real pity...
But, anyway, it also sets a "constant" to which pin A Vio readings could be compared... If we only could find a way to "expose" the pin A node to another internal-only connection, in order to pull it down, and observe the time it takes to reach its "companion" voltage readings...
With P1 I replaced the eeprom with an FM32L278 which beside the 32K fram has also an RTC, a 64bit programmable SN and 2 16bit event counters which can also work as a single 32 bit one. The counter value forms the decryption key. The counters together with the RTC are backed by the battery.
The protection consisted in make the counter advance eg with a switch on the box, a phototransistor on the pcb, ... that enables a single gate oscillator that feed the counters and "advance" the decryption key. After P1 finished its boot, the code reads the key and decrypt the encrypted part of the hub calculating its decrypted checksum. If OK it continued running the program.
I'll point out that those fuse bits were left in place. It would have cost more to re-lay the custom area without them. I'm guessing they were accessible in revA silicon but not after that.
From my experiments it looks like anything that runs in the Prop only needs one valid opcode as the starting point :) The rest can be progressively worse gibberish (LFSR noise within a few words, and not soon after crypto-grade noise). So, the whole thing will look like noise if you just dump the code from EEPROM. On top of that there's the chip-fingerprint-specific encryption key source. With a little bit of code generation, the initial decryptor can also be generated from a random seed, so every one will be different - even the first opcode would be different to a large extent, and thus comparing the EEPROMs of multiple devices won't yield much insight - they'll all be good quality random noise that passes all statistical tests, save for a couple of words - those would be slightly less random, but it'd require good investigation to see.
Of course, everything can be reverse engineered, but if you'd sand down the chip and otherwise not advertise nor mention anywhere that there's a Prop onboard, and the bootloader's serial connection was disabled (pin strapping should be enough), so that nobody randomly stumbled upon Forth, then it'll be hard-ish to figure out what the heck even that thing is - for anyone who hasn't heard of P2.
That method is largely irrelevant if the code in flash is open - it is meant to work with secure bootloaders, and is meant to both protect the flash's contents *as well as* disallow running third-party code.
Next Propeller silicon could use a way of routing an arbitrary pin to the PLL input. Then you could have a crystal on the two designated pins, or an oscillator hooked up anywhere :)
Comments
Yes great idea Henrique.
Unfortunately we can't combine with 100x ADC zoom, but just staring at the signal for longer should make it work
Storing the mid band should allow for verifying the fingerprint. But then what do you do with the fingerprint? This doesn't really solve the code protection problem. It only ensures that the code will run on one chip. And if someone hacks the boot program they can run it on any chip.
Thanks Lachlan, for calling my attention to this particularity.
When I did a look at the pad I/O modes (original V33' docs image) I'd noticed it's still listing this mode as being able to connect the ADC to pin B, wich I know isn't true for Rev. C silicon.
Part of the following note, tagged at 2020_02_24 seems to confirm the finding:
"Received 10 Rev C chips which fix the adjacent-pin ADC crosstalk problem on prior revisions. Smart pin mode %100010_OHHHLLL no longer connects the ADC to the adjacent pin, but floats the ADC input. This mode is now useful for determining the floating bias point of the ADC."
So this did started my wonderings...
Would it means we could leave it as a second and fourth pass, interspersed after the GIO and VIO ones, but with a longer timespan, between the mode setup and the samplings?
But then you can still just hack the boot code to dump the decrypted code and you're back to square one
Was there some plan as to how to use them?
There are all kinds of security schemes possible but the P2 by itself can't really be protected. Maybe the fingerprinting in conjunction with the UB3 could be useful.
Yes, the loader had crypto built in. Load signed code per fuse bits.
Thus, it'll mostly precharges towards the Vio node it's connected to, and keeps tracking it.
Real pity...
But, anyway, it also sets a "constant" to which pin A Vio readings could be compared... If we only could find a way to "expose" the pin A node to another internal-only connection, in order to pull it down, and observe the time it takes to reach its "companion" voltage readings...
With P1 I replaced the eeprom with an FM32L278 which beside the 32K fram has also an RTC, a 64bit programmable SN and 2 16bit event counters which can also work as a single 32 bit one. The counter value forms the decryption key. The counters together with the RTC are backed by the battery.
The protection consisted in make the counter advance eg with a switch on the box, a phototransistor on the pcb, ... that enables a single gate oscillator that feed the counters and "advance" the decryption key. After P1 finished its boot, the code reads the key and decrypt the encrypted part of the hub calculating its decrypted checksum. If OK it continued running the program.
I'll point out that those fuse bits were left in place. It would have cost more to re-lay the custom area without them. I'm guessing they were accessible in revA silicon but not after that.
It looks like the method described here will work:
Protect and control software stored in flash memory - Embedded Computing Design
It's not perfect, but it can be made difficult to copy.
From my experiments it looks like anything that runs in the Prop only needs one valid opcode as the starting point :) The rest can be progressively worse gibberish (LFSR noise within a few words, and not soon after crypto-grade noise). So, the whole thing will look like noise if you just dump the code from EEPROM. On top of that there's the chip-fingerprint-specific encryption key source. With a little bit of code generation, the initial decryptor can also be generated from a random seed, so every one will be different - even the first opcode would be different to a large extent, and thus comparing the EEPROMs of multiple devices won't yield much insight - they'll all be good quality random noise that passes all statistical tests, save for a couple of words - those would be slightly less random, but it'd require good investigation to see.
Of course, everything can be reverse engineered, but if you'd sand down the chip and otherwise not advertise nor mention anywhere that there's a Prop onboard, and the bootloader's serial connection was disabled (pin strapping should be enough), so that nobody randomly stumbled upon Forth, then it'll be hard-ish to figure out what the heck even that thing is - for anyone who hasn't heard of P2.
Standard practice is to look for where the crystal connects, which helps pinpoint what you're dealing with
Its a good article, Rayman
That method is largely irrelevant if the code in flash is open - it is meant to work with secure bootloaders, and is meant to both protect the flash's contents *as well as* disallow running third-party code.
Next Propeller silicon could use a way of routing an arbitrary pin to the PLL input. Then you could have a crystal on the two designated pins, or an oscillator hooked up anywhere :)
Now you're talking. Yes that would be nice and help layout