identify_flash_reset_qpi's behavior has been revised to
include setting all relevant parameters so that the device
that is identified behaves identically to the model device
(e.g. Macronix), to the extent that it is possible. This
includes setting the QE bit.
The routine to check QE has been renamed to `flash_ensure_eq()`
to reflect that it is safe to call multiple times: it checks
if the bit is already set, and if so, doesn't do anything.
Thus it can be routinely called without worry of wearing
out the device.
xtx devices still not fully working, but at least able to switch
in and out of spim modes in the face of uncertainty over which
device type is present.
loader was previously just accepting a dev key image and not
doing any countermeasures. now, kernel, detached-app, or swap
not being properly signed activates countermeasuers.
also select the swap key fallback for checking swap. this is
"half" of the solution, the other half will have to be implemented
in userspace - if we do it at all. i'm starting to think that
the swap encryption is not necessary, it was introduced
under the assumption that signature checking swap would be
too slow, but it's not. so maybe this feature will get dropped.
also fixup a return-type bug in the std implementation for
bio pin settings
much more bio abstractions will be needed, but for now,
this branch is just focused on the keystore.
dabao has no external TRNG, and so it can "cheat" and use the
server ID api call from the kernel to get random numbers (the
server ID is just TRNG output from the kernel's TRNG).
baosec has an external TRNG, and it needs a userspace
server to blend both kernel TRNG output and this external TRNG.
the TRNG requires the BIO block to aggregate the random data.
This commit adds that implementation.
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.
- setup rram security bits immediately
- setup coreuser mapping immediately
- check boot0 pubkey region against data slots, and note if
issues are found (and erase keys)
audit is now expanded to track one way counters and
summarizes security state
boot0 key indelibility test added as a feature, to be
used in the future for CI
just learned of another ECO incoming that will tie the key
and data areas together in terms of access control from
the IFR region, so the nuisance key range has to have
its access control redefined to steer clear of the data
slots allocated that have write-protects on them.
pubkey block is added to the data ranges
also a oneway counter to keep track of pubkey validation
failures in boot0 is added
The motivation for this is to make the tester configuration
exactly identical to that used in production. Right now a
"cheater" step is used to set the board type to dabao and
enable boot waiting because in the test environment there
isn't a physical switch anyone can press to invoke that
behavior.
So, in order to get the test environment to work just like
production, the behavior goes from insta-die if no valid
image is found on the next stage, to "wait for new image".
This is slightly less secure of a default, but only slightly
so. Basically the previous scheme required someone to be
physically present to press the "give me a new image" button,
this one causes the system to automatically accept a new image.
I suppose the main downside is this does allow the possibility
of say, a fully remote, automated exploit to be delivered
if an adversary can damage the loader image such that it
doesn't pass signature check and then it will automatically
go into a mode looking for a new image, at which point
an arbitrary image could be potentially loaded (although
because the image would need to be signed, and there is
a trap that destroys secrets if a developer image is
presented, it wouldn't instantly lead to secret disclosure,
but it would be a denial of service).
The flip side is that with the paranoid default, developers
are "confused" by the silent failure of a brand new chip that
has no code loaded in it (because it goes catatonic until
the developer knows to press the load button).
The loader image is protected from writes after boot, so
in theory there isn't a direct path to "spoil" the loader
image and trigger this path, so it's not like we're just
hanging in the wind. It just means that there isn't a
full human-presence requirement as a defense in depth against
a potential denial of service if an adversary could find
a way to spoil the loader image.
If the DoS path is a concern, one option is to configure
the system such that the developer key is revoked. This
would disallow that from being recognized as a valid
image, and would also prevent the DoS from happening,
as it would require the adversary to present a valid,
signed image which presumably they can't as long as
the signing keys are kept safe.
