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.

AM2434: Cryptography Modules Documentation

Part Number: AM2434
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

We are looking to use the AM243x in our aerospace products. For export control reasons, we need to ensure that the cryptography modules in the device are disabled. We also need to understand the process for enabling the crypto engines to ensure this is not done inadvertently.

I’ve found SDK API documentation and source code for enabling the various crypto engines in the AM243x’s DMSC. However, the TRM and datasheet of the AM243x do not document the registers that the SDK API is writing to enable the various crytpo engines such as SA2_UL, PKA.

 

I’m referring to this register structure in the CSL:

typedef struct {

    CSL_Cp_aceMmrRegs        MMR;

    volatile uint8_t         RSVD0[3824];

    CSL_Cp_aceUpdatesRegs    UPDATES;

    volatile uint8_t         RSVD1[61144];

    CSL_Cp_aceTrngRegs       TRNG;

    volatile uint8_t         RSVD2[65408];

    CSL_Eip_29t2_ramRegs     PKA;

} CSL_Cp_aceRegs;

 

I see that these registers are accessed through MMR, CBASS, via region based firewall.

For ex SA2_UL0 is accessed through region based firewall at: 0x40900000

 

However, the register map of these ACE registers is not documented anywhere I can find.
Can you suggest where the cryto engine registers documentation exists besides in the SDK source code?

 

Also, is it possible to disable these features permanently in a specific version of the Am243x?

I see the cryto modules device specific availability is shown in DEVICE_FEATURE2 and DEVICE_FEATURE6 . But the defaults for these read-only registers in the TRM is listed as -X.

So for AM243x, I’m assuming these registers will always say they are always viewed as present?

  • Another question is if it's possible through EFUSE one-time programming in the factory to disable the crytpo modules?
    I see for ex in the SA2_UL driver that it looks at these bits in the MMR.EFUSE register:

    /* EFUSE_EN */
    
    #define CSL_CP_ACE_EFUSE_EN_ENABLE_MASK                           (0x00000007U)
    #define CSL_CP_ACE_EFUSE_EN_ENABLE_SHIFT                          (0x00000000U)
    #define CSL_CP_ACE_EFUSE_EN_ENABLE_MAX                            (0x00000007U)
    
    /////
    
        /* Is sha enabled in efuses */
        reg = CSL_FEXT(CSL_REG_RD(&pSaRegs->MMR.EFUSE_EN), CP_ACE_EFUSE_EN_ENABLE);
        if((reg & 1u) == 0u)
        {
            retVal = SystemP_FAILURE;
        }
        
        

    This would be a great method for us, as it would guarantee said module is permanently disabled and the EFUSE programming would only be written once.

  • Hello,

    Please request access to the page hosting Security resources like SAx_UL with the following link

    https://www.ti.com/drr/opn/AM243X-RESTRICTED-SECURITY

    Once the access is granted, you would find the resources at the following page

    ti.com/secureresources/

    Regards,

    Prashant

  • Hi Prashant, 

    Can you provide info on how TI can provide us OTP eFUSE programming in factory that disables through this eFUSE register called out in SPRUIL3B?

    I think this should be sufficient for us to ensure cryto modules are disabled and can't be utilized by a bad actor opening our products.

    We may also be interested in permanent JTAG disable for DMSC i.e. HS_FS device release.

  • Hi Daryl,

    The HSSE devices, which are the one deployed in the field, requires usage of SAx_UL for secure boot. So, it might not be possible to actually disable the crypto engines. I think you can firewall the SAx_UL MMRA region to prevent any configurations & thus any usage of the crypto engines.

    As for the permanent JTAG disable, which is possible only on HSSE devices, can be done through the OTP Keywriter package in your production environment.

    Regards,

    Prashant

  • Thanks for the information. If we decide to go the firewall route, I will create a separate forum post regarding its Sysconfig settings etc.