• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 1162 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM64x: Question about FIT image signature

Guillaume Gonnet
Prodigy 20 points
Other Parts Discussed in Thread: TMDS64EVM

Hi support team,

I am currently working with TMDS64EVM on secure boot. I have read documentation from Processor SDK Linux for AM64X and READMEs (and code) from TI U-Boot.

If I undertood well, each individual component of all fitImages (SPL, U-Boot, kernel) is signed using customer key. But not the entire fitImage nor the "configuration" node of the fitImage.

So, here is the question: what prevent an attacker from mixing fitImage components?

For example, an attacker could recreate the kernel fitImage with U-Boot or SPL DTB instead of the desired kernel DTB. As they are both signed with the same key, they will be correctly authentificated and boot with continue with the wrong DTB, which may not put the Linux kernel in a desirable state.

Is there a way of preventing this kind of attack?

Best regards,
Guillaume

  • 0
    TI__Guru 70280 points

    Hello Guillaume,
    Thank you for your inquiry.
    We'll look into it, and get back to you.
    Best,
    -Hong

  • +1 in reply to Hong Guan64
    TI__Guru 70280 points

    Hello Guillaume,
    1. In the current Linux SDK, each SW components packed into FIT image is individually signed and verified by bootrom/TIFS signature verification process, where the public key hash is bounded to onship OTP efuse on TI HS SoC. Out of FIT image, only SW components (binary blob, dtb…) legitimately signed would pass verification process during the extended secure boot flow anchored with HW enforced root-of-trust starting from HW reset.
    2. On the "mix and match" attack, one would have to find some combination of kernel and dtb that would compromise security. But all DTB/Images have to still be provided and signed by the board owner, so the selection of DTBs are limited.
    3. There’s additional customization from the generic u-boot FIT ignature flow as described in https://github.com/ARM-software/u-boot/blob/master/doc/uImage.FIT/signature.txt There is nothing stopping users from enabling signed configurations for their solution if there's concern on the "mix and match" attack.

    TI is looking into enhancement on secure boot flow architecture in Linux SDK, and we'll share more details once implementation are worked out in the coming months.

    Best,
    -Hong

  • 0 in reply to Hong Guan64
    TI__Guru 69927 points

    Adding to this thread in case somebody finds this helpful. I got a chance to discuss this with the developers some more just now, and our upcoming Kirkstone-based SDKs will support the signing/authentication of the FIT images and configuration nodes the Yocto/U-Boot way, meaning using an UBOOT_SIGN_ENABLE = "1" approach. This is currently under active development and there are several tradeoffs that need to be considered from an ease-of-use and FW-update point of view. I'd expect this to be shaken out and available in the public TI Kirkstone trees in a few weeks. For now you should be using the existing basic approach where the individual image artifacts are signed using secure-binary-image.sh all going back to the TI device specific authentication approach (what Hong outlined under 1).

    Regards, Andreas