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

Traveo II Automotive Body Controller - FAQ – SECURITY - KBA232509

Traveo II Automotive Body Controller - FAQ – SECURITY - KBA232509

50 questions asked 25 likes received 25 sign-ins

Traveo II Automotive Body Controller - FAQ – SECURITY - KBA232509

Home Page: Traveo II Automotive Body Controller - FAQ – CDC -... - Cypress Developer Community

11. Security


11.1. What is eSHE and HSM of Traveo II?

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

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



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 CYTx devices?

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

In the NORMAL protection state, debug access restrictions are controlled by the SFlash address 0x1700 1A00. See Table 33-94 in the Traveo™ II Automotive Body Controller Entry Family Architecture Technical Reference Manual (TRM) (002-19314 Rev. *E). This memory location can be set using the ‘Write Row’ system call. Note that once an access is disabled in SFlash, it cannot be enabled again.

In the SECURE protection state, debug access is controlled by the eFuse bits. See Table 11-4 in the Traveo™ II Automotive Body Controller Entry Family Architecture Technical Reference Manual (TRM) 002-19314 Rev. *E. This can be set with the ‘Transition to Secure’ system call.

In both NORMAL and SECURE states, during boot, these SFlash/eFuse values are used to configure the CPUSS_AP_CTL register, which controls debug access restrictions depending on the protection state. Table 1 summarizes the possible options.

Table 1.Access Restriction Settings




Debug Access








Authenticated debug access






Generally, debug access is blocked, and a provision is provided to enable debugging using an authentication mechanism. For this use case, AP_CTL_xx_DISABLE should be ‘01’ to enable authenticated debugging.

There is no specific configuration for authenticated debugging; you can implement your own protocol to enable authenticated debugging (e.g., challenge-response, an RSA/ECC signed request, related encoding of messages, using the CRYPTO driver, and by modifying the CPUSS_AP_CTL.xx_ENABLE to ‘1’).

When password-based authentication is required for the Debugger, the access restriction settings (eFuse/SFlash) AP_CTL_xxx_DISABLE is set to 01 and SYS_AP_MPU_ENABLE is set to 0. Boot will make CPUSS_AP_CTL.SYS_DISABLE and CPUSS_AP_CTL.SYS_ENABLE to 0 disabling debugging access and will not configure SYS_AP_MPU.

HSM initialization sets CPUSS_AP_CTL.SYS_DISABLE to 0, CPUSS_AP_CTL.SYS_ENABLE=1, and enables SYS_AP_MPU (MPU15) with limited access required for authentication. The implementation of password-based authentication is open. Inter-processor communication (IPC) is one of the method to communicate the password to the HSM. For example, SYS_AP_MPU is enabled with limited access to only specific MMIO for IPC register, and minimal RAM to initiate IPC interrupt on HSM. After receiving the password, HSM validates it and, if correct, reconfigures SYS_AP_MPU to allow access for debugging. It is recommended to set up a PPU such that only HSM has a write access to SYS_AP_MPU, SYS_AP_MPU_MS_CTL.

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 II 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 " SMPU Configuration in SFlash" in 002-19314 Traveo™ II 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.