bunnie
commented
1 year ago The bbram_helper.py method should work, I've had reports of it working from multiple users.
Is it possible for you to share a sample of the output of ./jtag_gpio.py -d -f my_key.jtg here? obviously it would have key data in it so you'd want to use a throw-away key, but seeing that output would help me casually inspect if the AES key is being inserted or not.
I'm thinking maybe the most likely issue is that maybe this command isn't doing the right thing:
python ./deps/encrypt-bitstream-python/encrypt-bitstream.py --bbram -f build/gateware/betrusted_soc.bin -i dummy.nky -k my_key.nky -o my_encrypted -p keystore.patch
it's possible that this has bit-rotted somewhat because it hasn't been maintained in a while (please note that you are in fact following a set of "legacy instructions" that were deprecated in favor of the bbram_helper.py method). What this script does is take the default bitstream and re-encrypt that bitstream to your new key. Most importantly, it's supposed to change out the configuration bits of the bitstream so that the FPGA knows to retrieve the decryption key from the BBRAM instead of from the eFuse or other bank.
There were some small changes to the header format along the way and I bet this script is outputting an old version of the header format that's incompatible with the current toolchain, and when you try to boot with that image it's not looking for the BBRAM key anymore.
Debugging that would have to wait until I'm back in my lab next week (I'm still trapped overseas because I had limited options for rebooking my flights). But, I might be able to make some progress if you can share with me the contents of
`hexdump -C soc_csr.bin | head -100'
after you have run these two commands
python ./deps/encrypt-bitstream-python/encrypt-bitstream.py --bbram -f build/gateware/betrusted_soc.bin -i dummy.nky -k my_key.nky -o my_encrypted -p keystore.patch
python ./append_csr.py -b ./my_encrypted.bin -c ./build/csr.csv -o ./soc_csr.binnote that my_encrypted.bin should overwrite the original soc_csr.bin file with this sequence of commands, so I'm interested in the overwritten version that is output at the end, and not what was put into the sequence of commands.
The first 100 lines of the binary file would give me an idea of what's going on with the bitstream header, I can compare that against the current toolchain output and maybe visually identify the problem.
One thing I'd note is that with this legacy flow, the encyption key is derived using your local computer's random number generator. So you're not using the TRNG inside of Precursor, you're trusting your local machine to generate a very important secret, so you should make sure your local RNG is configured correctly. The bbram_helper.py script actually pulls the random number for the key out of the Precursor's TRNG, so it does not have that problem.
Answers to other questions:
- The eFuse blowing routine should "just work" now in the latest Xous release. The flow is self-guided and it should work without need of the JTAG port, but I'd recommend running it first before gluing anything up. If you do run the flow, I'd appreciate positive confirmation that it was successful. I have not received any reports of failures, but also, only a few have run the efuse flow that I know of.
- If your AES key is set, you can absolutely update without using JTAG. When a SoC update happens, it is staged in its "null key" encrypted form to a region of FLASH, and the device re-encrypts and writes it to the "live" location with the proper keys
- I'm not sure about what you mean by this one -- if you're using the BBRAM key, the Precursor should operate perfectly normally and not require a backup to add any secrets. However, you are recommended to do regular backups with a BBRAM flow simply because the key is volatile -- if you let the device discharge fully, or perhaps you drop the device and the battery contact disconnects briefly, the key is cleared, and you would need to restore from a backup in that case.
I personally use the BBRAM flow because I like the peace of mind of knowing that eventually the key zeroizes itself in the case that the device is lost or misplaced, but I also backup the device monthly just because the volatile key is fragile by design.
dylangerdaly
spoelstraethan
Hey everyone,
I've been attempting to setup my BBRAM Key on my precursor, I'd ultimately like to blow my AES key into eFuses however there's no documentation on how to do this yet.
I've been following https://github.com/betrusted-io/betrusted-wiki/wiki/FAQ:-FPGA-AES-Encryption-Key-(eFuse-BBRAM)#use-the-key-without-build-environment
I've managed to sign my own FPGA Bitstream and generate a soc_csr.bin, however I when I run
./jtag_gpio.py -f my_key.jtgon my generated jtg file, nothing happens (even after running it with-dto make sure it's doing something), even after Ireset_soc.sh.When I load my own
soc_csr.bnprecursor will hang, I assume this is because the BBRAM Key isn't set, so it's failing to decrypt the new FPGA Bitstream, if I load a nullkey'd soc_csr.bin from the CI Server it'll boot normally, then if I re-run./jtag_gpio.py -f my_key.jtgand reset the SoC, it'll still boot, when I expect it not to, because the BBRAM Key shouldn't be the null key.There also appears to be another way to provision BBRAM Keys, bbram_helper.py, however this method doesn't seem to work and seems to be more complex, I'd prefer to use jtag_gpio if possible
I have another few Qs here if that's okay
Cheers!