mirror of
https://github.com/saymrwulf/xous-core.git
synced 2026-11-13 07:48:30 +00:00
0b454cb7a8
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 |
||
|---|---|---|
| .. | ||
| src | ||
| wycheproof-import | ||
| Cargo.toml | ||
| factory_reset.ps1 | ||
| factory_reset.sh | ||
| pddbci.py | ||
| pddbdbg.py | ||
| README.md | ||
| README_UPDATE.md | ||
| rfc8452.py | ||
| sign_image.py | ||
| trng_test.py | ||
| update_ci.sh | ||
| update_release.ps1 | ||
| upload_audiotest.sh | ||
| usb_update.py | ||
| usb_update_xous_0.8.py | ||
| zadig.png | ||
Xous Tools
This repository contains build tools for Xous, used to package up the kernel and initial program images and create something that the runtime can use.
It contains a number of programs:
- copy-object: A reimplementation of
objcopy - create-image: Tool used to create a boot args struct for Xous
- make-tags: Test program used to create raw boot arg tags
- read-tags: Test program to verify the tags were created
Building
To build this repository, you will need Rust.
- Build the tools:
cargo build --release
Using
The two most useful tools are copy-object and create-image.
To use copy-object, simply run target/release/copy-object and
specify the elf file you would like to copy.
To create a tags file with create-image, you will need to specify the
path to the kernel, as well as any initial programs you would like to
run. You will also need to specify the memory range, or pass a
csr.csv file as an argument.
For example:
$ target/release/create-image \
--kernel ../kernel/target/riscv32i-unknown-none-elf/debug/xous-kernel \
--csv ../betrusted-soc/test/csr.csv \
--init ../shell/target/riscv32i-unknown-none-elf/debug/xpr \
args.bin
Arguments: Xous Arguments with 4 parameters
Main RAM "SrEx" (78457253): 40000000 - 41000000
Additional regions:
Audi (69647541): e0000000 - e0001000
CSRs (73525343): f0000000 - f000c000
Disp (70736944): b0000000 - b0006000
SpFl (6c467053): 20000000 - 28000000
SrIn (6e497253): 10000000 - 10020000
VexD (44786556): efff0000 - efff1000
kernel: 75200 bytes long, loaded from 000000c4 to 00200000 with entrypoint @ 00200004, and 5624 bytes of data @ 00280000
init: 31464 bytes long, loaded from 00012684 to 20000000 with entrypoint @ 20000004 and 0 bytes of data @ 10000000
Bflg: -no_copy -absolute +DEBUG
Runtime will require 36916 bytes to track memory allocations
Image created in file ../tools/args.bin
$
You can then verify this file is correct by running read-tags on it:
$ cargo run --bin read-tags -- args.bin
Finished dev [unoptimized + debuginfo] target(s) in 0.14s
Running `target/debug/read-tags args.bin`
Found Xous Args Size at offset 8, setting total_words to 208
67724158 (XArg) (20 bytes, crc: 48b0): 00000034 00000001 40000000 01000000 78457253
7845524d (MREx) (96 bytes, crc: 671a): e0000000 00001000 69647541 00000000 f0000000 0000c000 73525343 00000000 b0000000 00006000 70736944 00000000 20000000 08000000 6c467053 00000000 10000000 00020000 6e497253 00000000 efff0000 00001000 44786556 00000000
6e724b58 (XKrn) (24 bytes, crc: 14e2): 000000c4 000125c0 00200000 00280000 000015f8 00200004
74696e49 (Init) (24 bytes, crc: 9da0): 00012684 00007ae8 20000000 10000000 00000000 20000004
676c6642 (Bflg) (4 bytes, crc: 8e32): 00000004
$
Testing
TBD
Contribution Guidelines
Please see CONTRIBUTING for details on how to make a contribution.
Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide its terms.
License
Copyright © 2020
Licensed under the Apache License 2.0 LICENSE