Visit our new Infineon Academy learning platform today!

Developer Community 论坛 资源 关于我们 EN Account

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

 Resources  Knowledge Base Articles  Secure Microcontrollers - Migrate a TRAVEO™ T2G de... Opt ions

Secure Microcontrollers - Migrate a TRAVEO™ T2G device to Version history

the SECURE lifecycle stage
Last update: May 22, 2024 01:11 AM
IFX_Publisher1 Employee Updated by: lobosu
Feb 04, 2022 04:24 AM

Secure Microcontrollers (MCU Security) Supported Lifecycle

Stage
The device lifecycle is a key aspect of the TRAVEO™ T2G MCU security. Lifecycle stages follow a strict irreversible
progression dictated by blowing eFuses (changing a fuseʼs value from ʻ0ʼ to ʻ1ʼ). This system is used to protect the
internal device data and code at the level required by the customer. Figure 1 shows the TRAVEO™ T2G supported
lifecycle stages.

Figure 1: TRAVEO™ T2G supported lifecycle stages

SECURE Microcontrollers lifecycle stage

This stage is the lifecycle stage of a secure device. Before transitioning to this stage, the SECURE_HASH must have
been blown in eFuse and valid application code must have been programmed in the code flash. In this stage, the
protection state is set to SECURE and SECURE access restrictions are deployed.

The SECURE_HASH is calculated and written to the eFuse by SROM firmware, when transitioning to the SECURE or
SECURE_W_DEBUG lifecycle stage from the NORMAL_PROVISIONED lifecycle stage using the SROM API
“TransitionToSecure”. You can also specify the SECURE access restrictions (which defines how TRAVEO™ T2G should be
accessible when connected with an external debugger) as a parameter in this SROM API. For more details on these
topics, refer the device architecture TRMs and AN228680.

Transitioning TRAVEO™ T2G to SECURE lifecycle stage is useful to make the device secure. For example, the SECURE
access restrictions could be programmed in eFuses in such a way that the device can only be unlocked a er a password
authentication is successful. In SECURE stage, the user can also make use of the Secure Boot feature in which internal
boot verifies the integrity of all SFLASH objects and optionally authenticate and launch a user image only if it is
authentic.

Migrating to SECURE lifecycle stage is also useful for performing failure analysis on the device. This is because
TRAVEO™ T2G should be transitioned to another lifecycle stage called RMA when eff icient failure analysis is required
and transitioning to RMA can only be done from SECURE or SECURE_W_DEBUG as shown in Figure 1. For more details
on this topic, refer AN230102.

Differences between SECURE and SECURE_W_DEBUG

SECURE_W_DEBUG is not a production lifecycle stage and is intended to be used only during development. SECURE is
a production lifecycle stage for TRAVEO™ T2G.

In SECURE_W_DEBUG, the access restrictions are applied from NORMAL Access Restrictions (NAR) SFLASH row, while
in SECURE stage the SECURE access restrictions are applied from eFuses.

If TRAVEO™ T2G was transitioned to the RMA lifecycle stage from SECURE_WITH_DEBUG, then “OpenRMA” system
call is skipped and the device will not wait for OpenRMA execution. Hence, full access to the device will be unlocked
and the user application will be executed. If TRAVEO™ T2G was transitioned to the RMA lifecycle stage from SECURE,
then “OpenRMA” is mandatory to unlock the device in RMA stage and should be done a er every reset. For more
details on “OpenRMA”, refer AN230102.

Points to consider before transitioning to SECURE stage

The requirements listed in points 1, 2, and 3 shall first be configured and tested when TRAVEO™ T2G is in
NORMAL_PROVISIONED lifecycle stage. A er confirming that TRAVEO™ T2G successfully works and the user
application gets executed, then the user can perform operations to transition TRAVEO™ T2G to SECURE or
SECURE_W_DEBUG lifecycle stage.

Program all required SFLASH rows based on your requirements

Once the device is migrated to the SECURE or SECURE_W_DEBUG lifecycle stage, the SFLASH locations that were
allowed to be programmed by the user will no longer be reprogrammable. Hence, the SFLASH rows need to be
carefully programmed based on the required configurations. The system call “WriteRow” can be used for
programming the SLFASH rows. The SFLASH rows that user can program is listed in the following table.

Table 1: User programmable SFLASH rows

Address region Description

0x1700 0800 - 0x1700 0FFF The userʼs area. 2 KB are used to store arbitrary data.

NORMAL Access Restrictions (NAR). Used for chip

0x1700 1A00 - 0x1700 1A03
protection in the NORMAL Life Cycle stage.

NORMAL DEAD Access Restrictions (NDAR). Used for chip

0x1700 1A04 - 0x1700 1A07
protection in the NORMAL DEAD Life Cycle stage.

The Public Key. Used for a digital signature of the

0x1700 6400 - 0x1700 6FFF
application

0x1700 7600 - 0x1700 77FF Application protection settings.

The Table of Contents, Part 2 (TOC2). Used to locate

0x1700 7C00 - 0x1700 7DFF
OEM objects.

More details and configurations of these SFLASH rows is available in the device architecture TRMs and AN228680.
So ware image application format

In SECURE or SECURE_W_DEBUG lifecycle stage, internal Flash Boot can only launch an application which is
based on a format called Cypress secure application format (CySAF). This means the user application format
specified as “Format of First/Second User Application Object (off set＝0x10/0x18)” in Table Of Contents 2 (TOC2)
should be “1”. The default value of this field is “0”. User must update this entry using the system call “WriteRow”
before migrating to SECURE stage and also ensure that an image according to CySAF (see Figure 2) is
programmed in the Code Flash. For details on diff erent TOC2 fields, refer AN228680.

Note: CySAF format is mandatory in SECURE lifecycle stage even if the user application authentication specified by
TOC2_FLAGS.APP_AUTH_CTL is disabled. If user application authentication is disabled, then a Digital Signature is
not necessary.

Figure 2: Secure application format

Program a valid public key

The user must program a valid public key before transitioning the device to the SECURE or SECURE_W_DEBUG
lifecycle stage. The public key format is shown in Figure 3.

Figure 3: Public key format

The Public key shall be programmed to the SFLASH locations 0x1700 6400 - 0x1700 6FFF using the “WriteRow”
system call. Also ensure that the Public key structure address (for e.g. 0x1700 6400) is programmed to “Address of
signature verification key” at off set 0x104 as specified in TOC2.

This Public key will be used for application image authentication if user application authentication specified by
TOC2_FLAGS.APP_AUTH_CTL is enabled.

Note: For SECURE or SECURE_W_DEBUG lifecycle stage, a valid Public key should always be deployed in the device
even if authentication is disabled in TOC2_FLAGS.APP_AUTH_CTL.

Internal CAN/LIN bootloader is disabled

TRAVEO™ T2G supports an internal CAN/LIN bootloader. For more details on this feature, refer AN227076.

Note: This internal bootloader is disabled in SECURE and SECURE_W_DEBUG lifecycle stages and hence cannot be
launched. If any activities related to bootloading is required, then it must be completed before transitioning
TRAVEO™ T2G to SECURE or SECURE_W_DEBUG stage.

Clock requirements for blowing e-Fuse

The system call “TransitionToSecure” can be used for transitioning TRAVEO™ T2G to SECURE and
SECURE_W_DEBUG lifecycle stage. This API blows the necessary e-Fuses that defines the device lifecycle stage,
access restrictions and the SECURE_HASH. APIs that target blowing of e-Fuses, such as BlowFuseBit and
TransitionToSecure, have some requirements for clk_hf0. To avoid complications, these APIs can be triggered
with any of the clock settings used by internal boot (specified by TOC2_FLAGS.CLOCK_CONFIG) before the
application changes the clk_hf0 settings. If the application changes the configurations used by boot for clk_hf0,
then ensure that the source clock for clk_hf0 is FLL and the frequency of clk_hf0 is restricted to 100 MHz
maximum. If clk_hf0 is not sourced from FLL and FLL is disabled, then the maximum frequency of clk_hf0 should
be 8 MHz.

Community Translation: セキュアライフサイクルステージにTRAVEO™ T2Gを移行する – KBA234640

Version: **

Labels : T RAVEO™ T 2G

Tag s: Aut omot ive: T RAVEO II Lif ecycle st at e SEC_W_DEBUG secure secure boot securit y

Likes 0 1217 Views



Follow Us    

© 1999 - 2024 Infineon Technologies AG  Terms of Use  Imprint  Contact  Privacy Policy  www.infineon.com  Help