Visit our new Infineon Academy learning platform today!

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

We use cookies and similar technologies (also from third parties) to collect your
 Knowledge Baseand
device Articles
browser information for a better understanding on how you use our Options

online offerings. This enables us to optimize and personalize your experience

Secure
withMicrocontrollers
Infineon and to provide you with - Migrate
additional servicesa TRAVEO™
and information basedT2G

device to the SECURE lifecycle stage

on your individual profile. Details are available in our privacy policy where you
can also change your preferences on cookies at any time.

IFX_Publisher1 Employee
Privacy policy and Imprint

View04:24
‎Feb 04, 2022 andAM
change
Reject Accept
cookie settings
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 after 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 efficient
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 after 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. After 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.

Software 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
(offset＝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 different 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 offset 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 : TRAVEO™ T2G

Tags: Automotive: TRAVEO II Lifecycle state SEC_W_DEBUG secure secure boot security

Likes 0 1213 Views


Version history

Last update: ‎May 22, 2024 01:11 AM

Updated by: lobosu