Instead of having our own copy of the AES code, use a good library to do that.
Crypto++ is well-maintained, supports a lot of ciphers, works on many OSes, and
is optimized for many architectures.
Change-Id: I7d7d24b47993206d7338c5f9bac8bbdd3915a667
It was a mess, a mix of crypto_* and cbc_mac calls. I made everything call crypto
functions, and also separate key setup from cryptographic operations, this will
be useful to speed up the code in the upcoming commits. Drop support for "usbotp"
key, since the crypto code for that was never mainlined and we can always get the
keys from a device as long as we have code execution (using the DCP debug registers).
Change-Id: I7aa24d12207ffb744225d1b9cc7cb1dc7281dd22
After some reverse engineering, it appears that the keys of the
sb1 format are very weak: the 128 bytes are generated from the
laserfuse words 4,5 and 6 but in a weird manner: 4 and 5 are
simply ORed and 6 is only half used (somehow), making it "only" a
48 bit word to find.
Change-Id: I40702e19d0924ef51c01894efce3cb65bd664456
The STMP36xx series also uses .sb files but with a different
format. The main differences are the encryption and the lack of
sections, making it basically a list of commands: fill, load,
call, jump, switch mode, set sdram settings. Currently only the
sbtoelf has support for the sb1 and can only dump the list of
commands. Actual support for elf creation will come later.
Change-Id: I1f2e0230c91ac64efd0e8430e0c5212098c599fd
