search

chipsalliance / caliptra-rtl

HW Design Collateral for Caliptra RoT IP
Apache License 2.0
76 stars 38 forks source link

Using internal AES engine for f/w decryption #395

Closed RJMJJJ closed 10 months ago

RJMJJJ commented 10 months ago

Can you comment if the AES engine (Deobfuscation engine) in CAliptra Crypto block can be used to decrypt the incoming encrypted firmware?

If yes how the cipher text and the encryption key can be supplied to this AES engine?

Regards Rahul

Nitsirks commented 10 months ago

Rahul, DOE block is used only for deobfuscation of the field entropy and UDS. This is handled by ROM, which is provided in the caliptra-sw repo.

The SoC does not interface with the deobfuscation engine.

RJMJJJ commented 10 months ago

Thanks for the response. We are exploring on converting the existing passive mode Caliptra to active mode and exploring also for some operations like Caliptra after fetching the encrypted firmware from Flash decrypts it before further validation/authentication. My queries are as below:

  1. In Caliptra-rtl/src folder there is aes folder and doe folder. https://github.com/chipsalliance/caliptra-rtl/tree/main/src
  2. Does the existing DOE block (used for UDS/FE deobfuscation) support AES256 algorithm for encryption and decryption?
  3. Does the source code in aes (used in CSRNG) support support AES256 algorithm for encryption and decryption?
bharatpillilli commented 10 months ago

It cannot be used doe any external consumption or exposure due to security threat model consideration. We will consider it for the next generation. If you have a side channel mitigation capable AES 256 that is FPV proven and that is open sourced, please feel free to provide that code for next generation.

RJMJJJ commented 10 months ago

Hi Bharat, Thanks for the response. Just for clarification,I understand that there are no paths to these IPs DOE and AES in current Caliptra IP to use them for external consumption or exposure. But, would like to know what capabilities and difference both these have.
Capability in terms of supporting support AES256 algorithm for encryption and decryption.

RJMJJJ commented 10 months ago

WRT the De-obfuscation engine details given in Hardware Spec link below, I think it does support AES for encryption/decryption, can you please comment. https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md Below content: To protect software intellectual property from different attacks and, particularly, for thwarting an array of supply chain threats, code obfuscation is employed. Hence, the de-obfuscation engine is implemented to decrypt the code.

Advanced Encryption Standard (AES) is used as a de-obfuscation function to encrypt and decrypt data [4]. The hardware implementation is based on Secworks/aes [1]. The implementation supports the two variants: 128- and 256-bit keys with a block/chunk size of 128 bits.

The AES algorithm is described as follows:

The key is fed to an AES core to compute and initialize the round key The message is broken into 128-bit chunks by the host For each chunk: The message is fed to the AES core The AES core and its working mode (enc/dec) are triggered by the host The AES core status is changed to ready after encryption or decryption processing The result digest can be read before processing the next message chunks

RJMJJJ commented 9 months ago

Can we repurpose the existing doe/aes RTL modules, by adding them as new slave on AHB-L to perform encryption/decryption on f/w fetched from Flash. We are exploring active mode implementation and hence the Flash (QSPI) is accessed by RISC-V (in Caliptra). WRT above answer I understand these doe/aes RTL modules do not have side channel mitigation capability. But, apart from this which of the doe/aes is better suitable candidate for mentioned purpose. The doc covers the kind of AES support by doe but there is no mention of what capability aes module have. Why there are two different modules with different set of files? Kindly address this - as we dont have any other AES IP available we would like to experiment with this.

bharatpillilli commented 9 months ago

We did not design/implement/validate it for that purpose. May be a next gen version will have it.

On Thu, Feb 8, 2024 at 9:38 PM RJMJJJ @.***> wrote:

Can we repurpose the existing doe/aes RTL modules, by adding them as new slave on AHB-L to perform encryption/decryption on f/w fetched from Flash. We are exploring active mode implementation and hence the Flash (QSPI) is accessed by RISC-V (in Caliptra). WRT above answer I understand these doe/aes RTL modules do not have side channel mitigation capability. But, apart from this which of the doe/aes is better suitable candidate for mentioned purpose. The doc covers the kind of AES support by doe but there is no mention of what capability aes module have. Why there are two different modules with different set of files? Kindly address this - as we dont have any other AES IP available we would like to experiment with this.

— Reply to this email directly, view it on GitHub https://github.com/chipsalliance/caliptra-rtl/issues/395#issuecomment-1935363910, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABXGILVLEKKTH6IZPGGK7I3YSWY4HAVCNFSM6AAAAABCFB5NEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGM3DGOJRGA . You are receiving this because you commented.Message ID: @.***>

RJMJJJ commented 9 months ago

Thanks for reply Bharat,

I understand the usage of these IPs with current Caliptra version. But why there are 2 different set of RTLs used for same AES functionality? Usage wise doe is for deobfuscating the UDS and FE and AES is used in CSRNG is what is clear, but can you please help to understand the difference in these 2, maybe individual IPs capability wise. Or whatever reason these separate modules were used.

Thanks Rahul