the loader is a little funky, and requires some maintainer hand-holding
due to the split of the page ownership between the root-keys
crate and the graphics-server crate.
Improved docs so I don't forget this detail in the future.
this allows for a quick readout of the version of each of these
artifacts, inside a signed region, by just inspecting the last
few words of the binary object.
this commits a script that will repeatedly rerun the `btest`
which creates several Bases, fills them with pseudorandom datat,
and goes through a lock/unlock cycle.
should be run with the disk size set to 4MiB for maximum stress
testing (the larger disk won't trigger an FSCB refill because its
hard to run out free space on the larger disk size)
The FPGA gateware region is blocked from trivial readout via USB:
this makes it a tiny bit harder to obtain the gateware image, which
contains the secret keys. This slightly aids users who haven't
burned any efuse keys and are using the default "null" key from
a trivial readout attack, and it also hampers a WBSTAR exploit.
This makes the most convenient path of attack to be loading
a custom xous.img (or otherwise exploiting the kernel) with
a gadget that is capable of reading the gateware region
through priveleged code, and then relaying it over USB through
some run-around of the firewall. This primitive isn't impossible
to create but it doesn't exist and has no use in a normal
operational flow, so, it's going to at least force an attacker
to write some code, as opposed to using off the shelf utilities
we provide.
The `xmas-elf` crate doesn't deal with `raw_data()` of sections that are
`NO_COPY`. These sections may point to data that is outside of the file.
In order to avoid hitting this assert, don't call `raw_data()` on
sections that are marked `NO_COPY`.
Signed-off-by: Sean Cross <sean@xobs.io>
use `usb kbdtest` to output a mapping assuming US-101 maps
it will then derive an appropriate keymap based on that mapping
doesn't support non-ascii characters (yet)
The next release will feature an access control on USB so that
root keys and the encrypted gateware cannot be read back and
transitively the writes would be guttered (but this is not a problem
because the write target address is not set by the memory location
of the write, it's actually set by the location specified in
the program command to the FLASH).
This means that the updating program has to be modified accordingly;
now, for writes, a single location is targeted (and as alluded above,
this is funneled to a write FIFO buffer, and then the actual address is
set with the page program command); and for readback, attempts to read
back the SoC area are flagged and noted as impossible due to security
precautions.
So you'd like to think that an authenticating cipher would like,
authenticate stuff on decryption. And AES-GCM-SIV was billed as sort
of AES with the pointy edges taken off.
Well, there's always one more bug, actually this time a salamander:
https://eprint.iacr.org/2020/1456.pdf Apparently one can forge
authentication if the attacker can control keys and ciphertext. In the
case of the PDDB I think the attack is largely theoretical, because
you'd have to forge through both the AES-GCM-SIV and the rather
insufficient nonce/murmur hash check on the PTE that locates the page
to be decrypted.
But it's never good to have cryptographic properties depend upon
something that's known to be insufficient, so let's assume the attacker
can simply forge keys and stick some data on the device.
This wouldn't be a problem for confidentiality but it could lead to
the ability to plant evidence, but more importantly could lead to code
paths that were thought to be protected against fuzzing being fuzzed
as you could conceivably create a Basis root record that "checked out"
and then the larger body of the PDDB code would try to chomp on other
pages that are forged, leading to a bigger attack surface. Plus who
knows what else might exist beyond salamanders...
This patch does a "key commitment" on the Basis root page, so that it
is now cryptographically hard to create a salamander. Basically
instead of using the system root key directly in AES-GCM-SIV, the key
goes through a KDF that expands it with yet another nonce plus a bit
of header data. The KDF is SHA512/256 and it expands it twice,
changing one bit in the header data (as prescribed by the paper cited
above), to create a version of the key that is written to disk (the
commitment), and a version of the key that is used to
decrypt/authenticate the AES-GCM-SIV data. Only if both the commitment
and the authentication check out, do we accept a Basis root page as
valid.
I had some concerns about the slightly different structure of the
Basis Root page being detectable, but I have been assured that the key
commitment form and the MAC in AES-GCM-SIV satisfy a property known as
IND$-CPA ("indistinguishable from uniform randomness by a
chosen-plaintext attacker") by Rogaway[1], and, more strongly, "Secure
nonce misuse-resistant authenticated encryption (mrAE)" by Gueron and
Lindell (see appendix for def)[2]. Still, just out of total paranoia
and nothing else, I organize the basis root page such that the MAC is
in the identical location as the other non-committed pages...just in
case there is some mathematical property of the MAC that could be
leveraged to leak info about the existence of the basis root record.
The commitment nonce and sha512/256 result I understand better and
feel pretty comfortable that they are going to be strongly random and
indistinguishable from AES ciphertext.
Thanks to Michael Rosenberg for taking the time to explain all this to
me and to guide me through the process of making the fixes. It is a
major PDDB API-breaking change and I'm glad it's able to be rolled out
before most users have received a device.
[1] https://web.cs.ucdavis.edu/~rogaway/papers/ad.pdf
[2] https://eprint.iacr.org/2015/102
the actual transition to a new version isn't here. But,
at the very least, the root keys are now derived by hashing
them MAX_ROLLBACK_LIMIT times, which allows us to create a
key chain based on a global version number that can be incremented
while allowing derviation of older keys without compromising newer
keys.
