Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

TRAVEO™ T2G Automotive Body Controller - FAQ – SECURITY - KBA232509

TRAVEO™ T2G Automotive Body Controller - FAQ – SECURITY - KBA232509

ChaitanyaV_61
Employee
Employee
50 questions asked 25 likes received 25 sign-ins

11.Security

 

11.1 What is eSHE and HSM of TRAVEO™ T2G?

 

For body entry devices, different MPNs support different Crypto features. For a high-level description of TRAVEO™ T2G eSHE/HSM, see the first page of the device datasheet. 

Following are the details from the In 1M datasheet, 002-18043 Rev. *G:

IFX_Publisher2_0-1703050089812.png

 

For body high devices, all devices support all Crypto Engine features listed in the device datasheet. For more details, see the device datasheet.

11.2 How do I perform Authenticated Debugging in TRAVEO™ T2G devices?

 

TRAVEO™ T2G devices support debug access restrictions that are configured by the boot code depending upon the lifecycle state of the device.

Access restrictions in NORMAL protection state:

 

Boot will read the NAR (Normal Access Restrictions) row of the SFlash (SFlash address 0x1700 1A00) and configures CPUSS_AP_CTL register bits according to access restriction configurations present in SFlash. Since the NAR row of SFlash can be modified, access restrictions can be modified in NORMAL protection state. NAR row of SFlash can be configured using the ‘WriteRow’ system call. See the section “33.4.25-WriteRow” in the TRAVEO™ T2G Automotive Body Controller Entry Family Architecture Reference Manual (002-19314 Rev. *I).

Note the following points:

  • When NORMAL access restrictions are requested to be updated in NORMAL protection state and if new restrictions are wider than the existing ones, the 'WriteRow' SROM API (which is called to write to NAR SFlash row) will return the STATUS_INVALID_ACCESS_RESTRICTION status. For example, if once settings made in NAR row leads to setting of CPUSS_AP_CTL.xx_DISABLE bit, then this is the most stringent restriction applied to that specific access port and it cannot be reverted. It leads to the permanent disabling of the specific access port in NORMAL protection state.
  • In TRAVEO™ T2G devices, to enable authenticated debug access, the AP_CTL_xx_DISABLE bit should be ‘01’.
  • There is no recommended procedure/method for authentication. You can design the protocol to enable authenticated debugging (for example, a challenge-response, an RSA/ECC signed request, related encoding of messages, or using the CRYPTO driver).
  • To temporarily disable an AP (access port) and enable its access upon certain authentication criteria, make both CPUSS_AP_CTL.xx_DISABLE and CPUSS_AP_CTL.xx_ENABLE bits '0' as per the NAR setting (see Table 1). Upon successful authentication, the application software can set CPUSS_AP_CTL.xx_ENABLE bit so that access is provided. However, this is applicable until the next device reset. After device reset, device authentication is needed again to get the access for AP.
  • At any given time, CPUSS_AP_CTL register setting decides the access permission to different access ports. To avoid unintended/illegal writes to this register bit, consider protecting against write access to CPUSS_AP_CTL register during run time in NORMAL protection state.

Access restrictions in SECURE protection state:

 

In SECURE protection state, secure access restriction (SAR) is stored in one-time programmable eFuse memory. After every devie reset, boot will read the respective eFuse bits and configures CPUSS_AP_CTL register bits accordingly. Once the eFuse bits are blown, it cannot be reverted.

To implement authenticated debugging, employ the similar approach as explained for NORMAL protection.

The only difference is to configure the eFuse bits instead of NAR SFlash row. Efuse bits configures automatically as per the provided parameters using the ‘TransitiontoSecure’ SROM API. For more details on this API, see section “33.4.24-TransitiontoSecure” in the TRAVEO™ T2G Automotive Body Controller Entry Family Architecture Reference Manual (002-19314 Rev. *I).

Note: In the case of secure debug lifecycle stage, protection state will be secure, but NAR/NDAR will be employed.

Table 1  Access restriction settings

AP_CTL_xx_DISABLE in NAR/SAR

CPUSS_AP_CTL.xx_ENABLE register bits

CPUSS_AP_CTL.xx_DISABLE register bits

Debug access

00

1

0

Enabled

01

0

0

Temporiraly disabled (used for Authenticated debug access)

1x

0

1

Permanently disabled (irreversible)

See the example mentioned in “Debug access port authentication” section of the AN228680 - Secure system configuration in TRAVEO™ T2G family.

  • The earlier example is not the only method to implement the authentication-based debug access, you can implement your own method.

11.3 What is the state of the SWPU when the device goes to DeepSleep state?

 

The SWPU configuration is part of the reserved SRAM region (first 2 KB). This region should be retained in DeepSleep mode if the SWPU configuration needs to be restored after wake-up from DeepSleep mode.

11.4 Can the CyBAF used in SECURE protection stage?

 

No, in the SECURE protection stage (both SECURE and SECURE_W_DEBUG life-cycle stage) only CySAF can be used.

11.5 How are the device keys in the TRAVEO™ T2G devices generated?

 

These keys are generated and programmed during the chip manufacturing. Every chip generates its keys using its own Crypto IP hardware TRNG block. The keys never leave the device and are not stored in any database. After the manufacturing, these keys can be accessed only by the Crypto module, other masters cannot access them.

11.6  How can the flash update be prevented for specific region?

 

SWPU would be the appropriate protection unit to be used to flash erase/writes. SWPU blocks the access to flash operations based on the master which initiates the system call.

11.7 What are the pitfalls to be considered during configuration of SMPU?

 

Here are some pitfalls.

a. Address alignment not followed

If the alignment is not followed, the actual address range covered by SMPU will be different from the configured/intended address range since the lower bits violating the alignment will be ignored. SMPU fault may not occur when a violating access occurs and an allowed access may result in fault.

For example, consider the configured base address of 0x12000 for a 64 KB region.

Intended address range covered by SMPU: 0x12000 to 0x 0x22000

Actual address range covered by SMPU: 0x10000 to 0x20000.

According to the Registers TRM:

ADDR24 specifies the most significant bits of the 32-bit address of an address region. The region size is defined by ATT0.REGION_SIZE. A region of n Byte is always n Byte aligned. As a result, some of the lesser significant address bits of ADDR24 may be ignored in determining whether a bus transfer address is within an address region. For example, a 64 KB address region (REGION_SIZE is "15") is 64 KB aligned, and ADDR24[7:0] are ignored.

Default Value: Undefined

b. SMPU fault occurring for regions not configured by user application Some sections of memory are protected by SMPU configured during boot.

You can check if the address leading to SMPU fault falls under SMPU 14 or SMPU 15 based on SMPU 14 and SMPU 15 registers.

See the section "11.3.4.1 SMPU Configuration in SFlash" in 002-19314 TRAVEO™ T2G Automotive Body Controller Entry Family Architecture Technical Reference Manual (TRM).

c. Two SMPU regions with overlapping addresses The attributes of SMPU with larger index is considered similar to MPU.

0 Likes
2095 Views