bunnie cb6bc4d2c6 add keystore master key derivation ... the master key is currently derived from a number of factors: - the key seed - chaff keys - nuisance keys and then a salt of the uuid/cpid and some info based on the developer bit is added. The info addition ensures that the key rotates if developer mode is entered, so in addition to the key material being deleted, the info itself is different which should cause the master key to rotate and "be lost" even if the key erasure routine is flawed. Chaff keys harden against side channel analysis of data in flight from the RRAM array - under the theory that the RRAM array is a big, long set of wires (on the order of mm's) that should make a great target for EM microprobes. The chaff keys are read out in a random order every boot, to make it harder to accumulate enough samples to average out what's going on. The nuisance keys are just read straight out of the array. They might be recoverable by side channel analysis, but their purpose is to make it annoying for a brute-force read-out of the key array by a microscopist. The location and size of the nuisance keys are picked to force the attacker to really dial in their polishing process so that they have to hit the right layer across the entire chip (or at least a couple mm's); and then a set of bits are packed closely together to try and induce as much cross talk on the word lines, running under the theory that any attack relying on stray electrons activating the bitlines to enable read-out are likely to non-selectively activate bitlines, so the resulting "glow" of the word line is going to be a superposition of several bits at once. An attacker could, of course, cap each bit line with a FIB, read the word lines, then uncap/recap them one by one - but this drives up the cost of the attack and ensures that it's not just a single imaging run but will take at least hours if not days for a skilled adversary with the most modern equipment to extract the data. Furthermore, the large amount of bits demands that the attacker read out the data with better than 97% accuracy (the last 3% can be cleaned by the ECC coded into the array), so mistakes are costly. The chaff/nuisance keys are read out where the chaff keys (which are order-independent) are interleaved with the nuisance key readout. The chaff keys are read roughly twice, using a continuous-time algorithm to pick which version of the chaff key is read, making it a bit harder for sidechannel analysis to pick out which key is in flight. It's an attempt at sidechannel hardening, we'll see how it holds up. Pretty sure there's still some low hanging fruit in the read-out, it'll be interesting to see what the red team comes up with. Hopefully this at least makes the keystore not the low hanging fruit, and we're back at looking at bootloader/kernel exploits etc. to do key extraction, which I'm sure there are many; but at least those can be patched.		2025-10-28 17:29:06 +08:00
..
src	add keystore master key derivation	2025-10-28 17:29:06 +08:00
Cargo.toml	add keystore master key derivation	2025-10-28 17:29:06 +08:00