ZynqMP - secure-boot /encrypted bitstream

[marek.kvas]

Hi all,

After reading TRM, software development guide and some other document I am still not sure about some basic security concepts in ZynqMP. I would like to use encrypted bitstream for PL with key stored in BBRAM or EFUSEs. I have these questions, where I am not sure:

Is secure boot a must to use key from BBRAM or EFUSE? Is encryption(AES) enough, or authentication(RSA) must be used to?

I think so based on TRM UG1085, p. 217 that says:

A device key (a key used to boot the device) is selected by the CSU ROM based on the
authenticated boot header.

Is it possible to configure PL with one encrypted bitstream in FSLB and then reconfigure it with another encrypted bitstream in U-Boot and Linux? I think it should be possible as the statement above continues like this:

To use the device key post boot, the following conditions must
be met.
• The device key is available post boot if the initial configuration files are encrypted or if
the authentication only option is selected. See Hardware Root of Trust Only Boot
(Auth_Only Option) for more information.
• The device key used during boot must be the device key used post boot. The key
source cannot be changed until the next POR.

I found this discussion:

https://forums.xilinx.com/t5/Zynq-All-Programmable-SoC/Encrypted-Bitstream-Delivery/m-p/753383#M14648

Where it is clearly stated that reloading encrypted bitstream after boot is a backdoor and it is clearly refused. I am not sure whether it is valid for ZynqMP to? Is that different for Zynq and ZynqMP?

I found this  describing Linux driver loading bitstream to PL:

http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming#x-Programming%20the%20PL%20through%20Linux

 where no such limitation is mentioned. On the other hand I don't understand why user has to provide key and IV for it. Does it mean that it cannot use e.g. BBRAM device key? Unfortunately some links (to bif and script) are not working so I have only part of the information from this guide.

If I understood correctly whole secure-boot process it should work like this:

1) CSU authenticates/decrypts and loads FSBL. it runs at EL3. It can directly use CSU and device key to authenticate/decrypt ATF and U-Boot. ATF and U-Boot are both loaded by FSBL.

2) U-Boot is run at EL2. It cannot directly access CSU, so it uses calls to ATF to load encrypted bitstream.

3) Linux is started by U-Boot. Neither Kernel nor rootfs or anything running under Linux is authenticated/encrypted (BTW:can this be also secured in the same way as FSBL, ATF, U-Boot and bitstream?). It again calls ATF to configure PL with encrypted bitstream. Because ATF is secured and isolated from Linux and it is the only piece of software that is allowed to use CSU to decrypt bitstream, chain of trust is not broken.

I can imagine that without secure-boot, FSBL and ATF can be forged by attacker. He/she can then program CSU to load encrypted FW, decrypt it and store into memory in its original decrypted form. So the condition to use safe-boot in order to use device key in BBRAM of EFUSE seems to be logical.

I would really appreciate if somebody corrected this my view of the problem if it is flawed.

Thanks

Marek

[austin]

m,

'Is secure boot a must to use key from BBRAM or EFUSE?'

Yes

'Is encryption(AES) enough, or authentication(RSA) must be used too?'

For complete security, AES and at least a verification of the hash (SHA256) is required.  RSA is a further refinement

'Is it possible to configure PL with one encrypted bitstream in FSLB and then reconfigure it with another encrypted bitstream in U-Boot and Linux?'

No.  Once is secure mode, further loading is prevented.  One can use the ICAP/PCAP to build a back door, but I do not recommend that, as the system is no longer secure (unless you are willing to prove your back door is secure  -- a nearly impossible task).

'Where it is clearly stated that reloading encrypted bitstream after boot is a backdoor and it is clearly refused. I am not sure whether it is valid for ZynqMP to? Is that different for Zynq and ZynqMP?'

Absolutely valid for all devices, even Artix, Kintex, and Virtex.

[marek.kvas]

Hi Austin,

thanks for answear. I accepted it as a solution, but few more questions occured to me.

Is the "one bitstream load in safe mode" policy documented somewhere in TRM or other Xilinx document? I cannot find any explicit statement or anything that implies it.

Is it possible to authenticate/encrypt kernel and rootfile system image in the same way. It seems to me that U-Boot should be able to use CSU with device keys to do it.

Thanks

Marek

[marek.kvas]

Hi again austin,

I finally had chance to play with real HW and my findings don't correspond with what was said in the answer to my original question.

I created BOOT.BIN containing fsbl, atf, pmufw, bitstream and u-boot. All authenticated and encrypted - so bitstream was loaded in FSBL. When U-boot came up I tried to reconfigure PL with unencrypted and not authenticated bitstream and it works.  While it shouldn't, right?

So I see three possible reasons:

1) bh_auth_enable option used to avoid necessity to write key hashes to eFuse does more than said in TRM. But TRM seems to be quiet clear about what it does.

2) Device didn't boot securely for other reasons. But debug prints of FSBL say all partitions were authenticated and encrypted. Is it possible to check this somehow?

3) Statement "Once is secure mode, further loading is prevented." is not valid.

Can anybody provide any input on this?

Thanks

Marek

[austin]

"Tried to reconfigure..."

How exactly?  As in pulled PROG_b low?  JTAG load of foo.bin?  cat /dev/dvc/*.bin?  Full, or partial bitstream?

Once in secure mode, no further bitstream access is allowed.  Unless your design is intentionally leaving secure mode, or creates its own back-door.

Just because there is a key in BBRAM does not prevent a load (one-time) after a PROG_b, or unecrypted configuration (how would one test a part otherwise?).  There is an EFUSE to set for encrypted loads ONLY.  I strongly suggest you NOT set that, unless you are building gambling machines in Nevada (a requirement for such equipment).

[marek.kvas]

I didn't write to any eFuses so they are in default state. I think that except for public key validation that is no difference between "real flow" and bh_auth_enable flow. Is that correct?

First my ZCU102 boots from SD-card that contains BOOT.BIN created with this .bif file:

sec_enc_img: {
   [aeskeyfile] ../keys/bbram_aes_key.nky
   [fsbl_config] a53_x64, bh_auth_enable
   [keysrc_encryption] bbram_red_key
   [auth_params] ppk_select=0; spk_id=0x00000000
   [pskfile] ../keys/rsa_PSK.pem
   [sskfile] ../keys/rsa_SSK.pem
   [bootloader, authentication=rsa, encryption=aes] zynqmp_fsbl.elf
   [pmufw_image, authentication=rsa, encryption=aes] pmufw.elf
   [authentication=rsa, encryption=aes] download.bit
   [destination_device=ps, destination_cpu=a53-0, exception_level=el-3, trustzone, authentication=rsa, encryption=aes] bl31.elf
   [destination_device=ps, destination_cpu=a53-0, exception_level=el-2, authentication=rsa, encryption=aes] u-boot.elf  
}

Then FSBL prints it is up and goes thorugh all partitions - authenticates them and decrypts them. The it executes U-Boot. I enabled all debugging messages in FSBL so prints look like this:

ZynqMP> Xilinx Zynq MP First Stage Boot Loader
Release 2017.2   Nov 15 2017  -  14:21:25
Reset Mode      :       System Reset
Platform: Silicon (4.0), Cluster ID 0x80000000
Running on A53-0 (64-bit) Processor, Device Name: XCZU9EG
Board Configuration successful
Processor Initialization Done
================= In Stage 2 ============
SD1 with level shifter Boot Mode
SD: rc= 0
File name is BOOT.BIN
Multiboot Reg : 0x0
Image Header Table Offset 0x8C0
Authentication Enabled
Auth: Partition Offset FFFF0040, PartitionLen 1F40, AcOffset FFFDBFC4, HashLen 30
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
Doing Partition Sign verification
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
Partition Verification done
*****Image Header Table Details********
Boot Gen Ver: 0x1020000
No of Partitions: 0x5
Partition Header Address: 0x440
Partition Present Device: 0x0
Initialization Success
======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x65216F
Data word offset: 0x65218F
Total Data word length: 0x653050
Destination Load Address: 0xFFFFFFFF
Execution Address: 0x0
Data word offset: 0xF980
Partition Attributes: 0x2080A6
Destination Device is PL, changing LoadAddress
 Aes initialized
Authentication Enabled
Authenticated Bitstream download to start now
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
Decryption Enabled
PL Configuration done successfully
Partition 1 Load Success
======= In Stage 3, Partition No:2 =======
UnEncrypted data Length: 0x1800
Data word offset: 0x1820
Total Data word length: 0x1BD0
Destination Load Address: 0xFFFEA000
Execution Address: 0xFFFEA000
Data word offset: 0x6629D0
Partition Attributes: 0x8197
 Aes initialized
Authentication Enabled
Auth: Partition Offset FFFEA000, PartitionLen 6F40, AcOffset FFFDBFC4, HashLen 30
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
Doing Partition Sign verification
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
Partition Verification done
Decryption Enabled
Decryption Successful
Partition 2 Load Success
======= In Stage 3, Partition No:3 =======
UnEncrypted data Length: 0x8
Data word offset: 0x28
Total Data word length: 0x3E0
Destination Load Address: 0xFFFF0000
Execution Address: 0x0
Data word offset: 0x6645A0
Partition Attributes: 0x8197
 Aes initialized
Authentication Enabled
Auth: Partition Offset FFFF0000, PartitionLen F80, AcOffset FFFDBFC4, HashLen 30
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
Doing Partition Sign verification
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
Partition Verification done
Decryption Enabled
Decryption Successful
Partition 3 Load Success
======= In Stage 3, Partition No:4 =======
UnEncrypted data Length: 0x2589E
Data word offset: 0x258BE
Total Data word length: 0x25C70
Destination Load Address: 0x8000000
Execution Address: 0x8000000
Data word offset: 0x664980
Partition Attributes: 0x8194
 Aes initialized
Authentication Enabled
Auth: Partition Offset 8000000, PartitionLen 971C0, AcOffset FFFDBFC4, HashLen 30
XFsbl_SpkVer: Ppk Mod FFFDC004, Ppk Mod Ex FFFDC204, Ppk Exp 1000100
Doing Partition Sign verification
XFsbl_PartVer: Spk Mod FFFDC444, Spk Mod Ex FFFDC644, Spk Exp 1000100
Partition Verification done
Decryption Enabled
Decryption Successful
Partition 4 Load Success
All Partitions Loaded
================= In Stage 4 ============
PM Init Success
Protection configuration applied
  ATF running on XCZU9EG/silicon v4/RTL5.1 at 0xfffea000, with PMU firmware
NOTICE:  BL31: Secure code at 0x0
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v1.3(release):0d9d51a
NOTICE:  BL31: Built : 16:59:19, Nov 13 2017


U-Boot 2017.01 (Nov 13 2017 - 18:00:08 +0100) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  4 GiB
EL Level:       EL2
Chip ID:        xczu9eg
MMC:   sdhci@ff170000: 0 (SD)
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB, total 128 MiB
In:    serial
Out:   serial
Err:   serial
Net:   ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id
eth0: ethernet@ff0e0000
Hit any key to stop autoboot:  0

Now I am in U-boot console and see DONE led shining.

Stil in U-Boot I read other bitstream (no enc, no auth) from SD-card to memory and use it to reconfigure PL part:

ZynqMP> mmc info
Device: sdhci@ff170000
Manufacturer ID: 3
OEM: 5344
Name: SL16G
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 14.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
ZynqMP> fatload mmc 0 ${netstart} download.bit
reading download.bit
26510899 bytes read in 1904 ms (13.3 MiB/s)
ZynqMP> fpga loadb 0 ${netstart} ${filesize}
  design filename = "zcu102_wrapper;UserID=0XFFFFFFFF;Version=2017.2"
  part number = "xczu9eg-ffvb1156-2-i"
  date = "2017/06/19"
  time = "21:13:31"
  bytes in bitstream = 26510780
zynqmp_align_dma_buffer: Align buffer at 0000000010000077 to 000000000fffff80(swap 1)

I see DONE led go down for fraction of a second and the up again.

Is something wrong with this flow?

What do you mean by "Unless your design is intentionally leaving secure mode, or creates its own back-door."? Who is responsible for preventing reconfiguration in secure boot? You said in other answer that the only way is via PL's ICAP - is it what you mean?

BR,

Marek

[austin]

m,

I see a non-secure partition message.  It could be you have allowed non secure information to be loaded (an option).  I am unfamiliar with all of the possible settings, so Will go ask.

[marek.kvas]

Austin,

can you be more specific, please? Which part is the non-secure partition message?

Thanks

Marek

[austin]

"

======= In Stage 3, Partition No:1 =======
UnEncrypted data Length: 0x65216F

"

So, I see authentication of bitstream, but no decryption?  Something is not as it seems.

I did ask for help here.

[marek.kvas]

Hi Austin,

thanks for asking your colleagues for further help.

In the meantime I went through the FSBL code and compared it to log I sent in previous posts and I think that both authentisation and decryption was done. From what I understood from the source code, the "Unencrypted data Length" part of the log is printed based on partition header for any partition regardless it is encrypted or not.

I also looked into generated BOOT.BIN and it looks like encrypted too. Instead of long constant sequences that can be found in original bitstream there is only random data in encrypted BOOT.BIN.  I know this is not very scientific, but how else can I check it? So if bitstreeam is encrypted and I get done after PL configuration, decryption had to be done...

I agree that something is not as it seems. Is there any flag in any register that I can read from U-Boot or Linux that can tell me what security state the device is in? Possibility to check it would be nice to have anyway.

Thanks

Marek

[marek.kvas]

Hi Austin,

have you received any response from your collegues?

Thanks

Marek

[austin]

m,

No, I have not.  Pinged them.