cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
274 Views
Registered: ‎01-02-2019

Using the AES device key from Linux on ZynqMP

Think I posted this question in the wrong forum earlier.

The system is a 2020.1 Linux, 5.4 kernel with the zynqmp-aes kernel module loaded.

We are running a secure boot, authenticated and encrypted.

The AES key is in the eFuse.

The intent is to be able to encrypt a file off system with the same AES key we burned to the eFuse. Then on the board, decrypt the file using the hardware key.

So for instance, right now I have a userland program that lets me test the zynqmp-aes kernel module and just for debug also lets me specify an IV so I can keep it constant.

If I encrypt a small piece of data using a user provided KUP key I can do this

./enc -k key -i iv -p data -c data.enc
./dec -k key -c data.enc -p data.dec
diff data data.dec
<the same>

I can also do the same thing off-board on another workstation using the same key, iv and data and another aes-gcm utility.

So that all works as expected.

Now if I tell the driver to use the AES_DEVICE_KEY I also get consistent results

./enc -k AES_DEVICE_KEY -i iv -p data -c data.enc
./dec -k AES_DEVICE_KEY -c data.enc -p data.dec
diff data data.dec
<the same>


I definitely know the value of the AES_DEVICE_KEY, as again I am running a successful encrypted boot, so generating a boot.bin with the known key. (Also the AES_DEVICE_KEY option is rejected by the linux driver/PMU if I am not running secure boot.)

But if I try to do this with 'key' equal to the AES key burned to the efuse (i.e. the same key we used for the boot header of boot.bin).

./enc -k key -i iv -p data -c data.enc
./dec -k AES_DEVICE_KEY -c data.enc -p data.dec
diff data data.dec
<files differ>

Likewise this fails

./enc -k AES_DEVICE_KEY -i iv -p data -c data.enc
./dec -k key -c data.enc -p data.dec
diff data data.dec
<files differ>

So pretty sure this is just an endian thing with the way the key is being handled by the PMU vs the way it is handled by the CSU on initial boot.

Is my theory correct?

If so, can someone quickly advise how I should swap around the byte order of the AES key I use from the command line so that my examples will work?

Thanks.

2 Replies
Highlighted
238 Views
Registered: ‎01-02-2019

As a reference for others, the issue was the key left as the 'device key' after boot was the ephemeral AES key used for the last partition of boot.bin. Not the efuse key used for partition zero.

0 Kudos
Highlighted
229 Views
Registered: ‎01-02-2019

To be more specific, we use an opt_key for boot.bin and it is this opt_key that is left as the AES_DEVICE_KEY when using the crypto engine from Linux.

0 Kudos