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
This commit adds the current's app name to the security bar at the top
of the screen, just beneath the status bar.
I had to add a new generated function to map app index back to its name,
along with an enum to signal whether or not the id is valid.
Signed-off-by: Gianguido Sorà <me@gsora.xyz>
This adds a working Ethernet implementation based on the WF200. It
currently gets connected to a Linux machine running a udhcpd server,
however it could also get connected to a TUN/TAP connection on Linux or
Mac.
Signed-off-by: Sean Cross <sean@xobs.io>
It's crappy because it uses a busy wait loop to poll the udp
rx socket in order to accurately emulate the Xous async callback
feature (which is _not_ emulated for Tcp, for example).
It's more accurate because this emulation happens. But it's a lot
more complicated to implement it because zero-cost async UDP callbacks
aren't really a host-native feature (but they are a Xous-native feature!),
and I didn't want to .. pull in tokio or mio code surface into
the Xous hosted mode, seemed a bit like crushing a fly by dropping
a house on it. Maybe that's a fine solution in Oz, but Xous doesn't live in Oz.
Total bodge -- we lop off the TCP stack at the Xous API level, and
substitute it with a native host TCP stack.
Caveat hacker: this means that a lot of OS-specific net properties
will carry through to the hosted mode emulation. This is adequate
for "smoke testing" a build but do not be shocked, *shocked* if
there are more bugs to be found because of some weird host integration
issue.
since xous 0.9.5, we've had a Box and we've had threads, so now we
can put the callback in a Box and pass it to a thread, instead
of relying on an `unsafe` work-around to get the callback function
pointer into the thread's environment.
also remove async write callbacks: in practice, these aren't used
Downside of this refactor is that threads for handling the
callbacks are not spawned on demand, they are spawned at boot,
leading to about an extra 68k of RAM used (most of it being
consumed in the codec block, actually). Some of this is also
probably extra object code because we're using more of the stdlib
primitives, which carry some weight.
The COM bus is fundamentally three things: The SoC, the EC, and the glue
that binds the two together.
Now that we have the `EnsureTypeIsLoaded` trick, split the file into
three different groups.
Signed-off-by: Sean Cross <sean@xobs.io>
Emulate both the SPINOR block as well as the OSPI flash attached to it.
With this change, the PDDB can now be initialized and resets itself
properly. Additionally, data persists across virtual reboots.
Data does not persist across runs of the emulator. That will follow in
an upcoming patch.
Signed-off-by: Sean Cross <sean@xobs.io>
The init code tried to set up the ECC block to report errors by writing
into the softirq block. Correct the block so that it goes into the
spinor block instead.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, the HOLD signal was updated in a different clock domain from
the transmission signal. This could result in the HOLD bit being set
even if there was no data available.
Update the HOLD bit if it's present as part of the Transmit cycle.
Signed-off-by: Sean Cross <sean@xobs.io>
Connect the EC to the SoC. This allows for emulating both the EC and SoC
in tandem. Messages flow via a 16-bit bus. When data is not available,
`0xdddd` is returned.
There is a HOLD line that goes from the EC to the SoC. This is tied to
the inverse of presence of data in the EC FIFO -- when it's empty, HOLD
is `1`, and when there is data it's `0`.
Signed-off-by: Sean Cross <sean@xobs.io>
