Introduction#

Attacks include both logical and physical attacks. Logical attacks attempt to exploit software vulnerabilities over some type of communication interface such as a wireless protocol or serial communication interface. Physical attacks require an attacker to have physical access to the device so that they perform attacks such as fault injections and side channel analysis. Defending against these attacks requires implementing a variety of security features. These include:

Securing the application firmware using secure boot
Locking access to the debug port using secure debug
Mitigating fault injections using automatic tamper detection and response
Mitigating side channel attacks using DPA and DFA countermeasures against cryptographic operations
Secure key storage

Secure Engine Principles#

The following is a list of the various security features found in Series 3. This document is intended to provide an overview of each security feature. Refer to the linked documents in each section for details, including examples for implementing each feature.

Users and Modes#

The SE has a single user -- the product developer. The interfaces to the SE are described in the following section. The SE has two modes, active and inactive. When the Secure Engine is processing a command, it is active, otherwise it is inactive.

Mailbox/DCI Interface#

The Secure Engine is accessible to a single user through commands that can be issued using:

SE Mailbox (from host core) via the SE Manager API.
Debug Challenge Interface (DCI). The Silicon Labs Simplicity Commander tool is the recommended method for using the DCI interface. The Simplicity Commander user guide is available here. The recommended version of Simplicity Commander for the steps in this application note is v1.17.4, or higher.

These commands provide access to the following features:

Key provisioning
Debug port configuration and locking
Secure boot configuration and status reporting
Tamper response configuration
Secure engine (SE) and host firmware updates
Code/data region configuration for EXiP/AXiP
Cryptographic operations

Secure Engine Manager#

The Secure Engine manager provides an interface for users to control all the features mentioned here. Documentation for SE Manager APIs can be found here. At the time of publication, this document refers to SE Manager API documentation version v5.2.0.

Authenticated eXecute in Place (AXiP)#

The AXiP feature is used to encrypt and authenticate external flash memory to protect the confidentiality and integrity of code and data.

The AXiP feature is configurable in up to 8 regions, and each region can be either unprotected, encrypted (eXiP), or authenticated and encrypted (AXiP). Each region must be a multiple of 32 KB.

The configuration can be read or changed using either DCI commands or SE manager APIs. The commands are summarized in Table: AXiP Security Parameters. The default configuration is to configure region 0 for 32 KB with AXiP enabled and region 1 for the remainder of flash with AXiP enabled. Unused regions are set to size 0 and start address immediately following the previous region.

Users and User-controlled Security Parameters#

The user of this feature is the end product developer who configures the feature through the use of the DCI interface or the SE manager APIs mentioned in the SE Manager APIs for AXiP table.

Table: AXiP Security Parameters.


Parameter	Configuration Options	Description
Region Start Address	Start address - Integer	The starting address of one of up to 8 code regions
Region Size	Region size - integer, multiple of 32 KB	The size of the current region (1)
Region Protection Type	Integer indicating the protection type for the region	The protection mode for the code region. One of the following settings is valid. No encryption, encryption only, authentication with encryption
Code Region Closed	Boolean	Closing a code region finalizes the message authentication code (MAC) for that region.

Note:
Unused regions default to a size of 0.

Table: SE Manager APIs for AXiP.


DCI Command (1,2)	SE Manager API	Usage
Read Region Config	`sl_se_code_region_get_config`	Reads the memory region configuration and reports the region sizes and protection types
Close Region	`sl_se_code_region_close`	Finalizes the message authentication tag (MAC) for the memory region
Apply Region Config	`sl_se_code_region_apply_config`	Writes the memory region configuration to set the size and protection type for each region. Some regions can have a size of 0.
Erase Region	`sl_se_code_region_erase`	Erases a code region
Get Region Version	`sl_se_code_region_get_version`	Gets the version of a code region (32bit int)
Write Region	`sl_se_code_region_write`	Write code region
Write Region	`sl_se_data_region_write`	Write to a data region
Erase Region	`sl_se_data_region_erase`	Erase data sectors
Get Data Region Location	`sl_se_data_region_get_location`	Get data region location
-	`sl_se_flash_pause`	Resume the previously paused long-running flash operation and/or re-enable long-running operations.
-	`sl_se_flash_resume`	Resume the previously paused long-running flash operation and/or re-enable long-running operations.
-	`sl_se_code_region_set_active_banked`	Check if a long-running operation (page/region erase, bulk write) is currently being executed on the flash
-	`sl_se_flash_is_busy`	Pause the ongoing long-running flash operation (and/or inhibit new long-running operations from starting), which frees up the auto-port such that code can run again (unless it tries to access the sector/region being erased, in which case the SE will need to auto-resume).

Notes:
Performing these commands over DCI is implemented in Simplicity Commander.
Not all commands exist as both APIs and DCI commands.

Secure Attestation#

The secure attestation feature is used to authenticate a device as a genuine Silicon Labs product. Each device is provisioned with one certificate to identify the device and another certificate to identify the batch to which the device belongs. Together with Silicon Labs' root certificate and factory certificate, a chain of trust is formed which can be used to verify the identity of a device, confirming it to be a genuine Silicon Labs product. The private key associated with the public key in the device certificate is securely stored on the device to facilitate signing of random number challenges. Refer to AN1268 for more details.

Table: SE Manager APIs for Secure Attestation.


DCI Command (1,2)	SE Manager API	Usage
Vault Device Attestation	`sl_se_attestation_get_psa_iat_token`	Get the PSA attestation token from the SE with the given nonce.
Read Device Certificate	`sl_se_read_cert`	Read stored certificates (DER format) in the device.
Read Public Key from Device	`sl_se_read_pubkey`	Read stored Public Device Key in the device.
-	`sl_se_attestation_get_config_token`	Get the security configuration token from the SE with the given nonce.
-	`sl_se_attestation_get_psa_iat_token_size`	Get the size of a PSA attestation token with the given nonce.
-	`sl_se_attestation_get_config_token_size`	Get the size of a security configuration token with the given nonce.
-	`sl_se_read_cert_size`	Read the size of stored certificates in the device.

Note:
Performing these commands over DCI is implemented in Simplicity Commander.
Not all commands exist as both APIs and DCI commands.

Secure Attestation Users and User-controlled Security Parameters#

Table: Secure Attestation Security Parameters.


Parameter	Configuration options	Description
SE Device Identity Certificate	None (1)	X.509 certificate identifying the specific device
SE Batch Certificate	None (1)	X.509 certificate identifying the batch of devices
SE Device Private Signing Key	None (1)	ECC P-256 private key used to sign attestation tokens

Note:
This parameter is provisioned in the Silicon Labs production facility and cannot be changed by the user of the product.

Secure Debug#

Access to the host core's debug port can be securely locked and unlocked. The command public key is stored securely in SE OTP. The associated command private key signs a certificate that includes the device serial number, permitted debug modes, and a public key referred to as the certificate public key. The certificate private key is used to sign an access token consisting of the access command, a debug mode request, and a nonce. The random number challenge is issued by the device and must be correctly signed for the debug port to be unlocked. The debug port is automatically locked again upon reset. The random challenge can be rolled to a new value to prevent previous access tokens from being reused by unauthorized parties.

For a detailed description, see AN1190.

Secure Debug Users and User-controlled Security Parameters#

The user of this feature is the end product developer who configures the feature through the DCI interface or the SE manager APIs mentioned in Table: SE Manager APIs for Secure Debug.

Table: Secure Debug Security Parameters.


Parameter	Configuration Options	Description
Secure Debug Unlock	Boolean -- enable/disable	Enables or disables the ability to securely unlock the debug port using a signed access token
Public Command Key	ECC public key	User generated ECC P-256 public key used to verify a signed certificate
Device Erase Command	Boolean -- enable/disable	One-time programmable option to disable the device erase command. Disabling this command makes it impossible to reset the secure debug unlock bit or to unlock the debug port by erasing the device.
Debug lock	Boolean -- enable/disable	This parameter controls the lock state of the debug port.
Non-secure Zone Invasive Debug Restriction	Boolean -- enable/disable	This option enables or disables the ability to perform invasive debugging on the non-secure memory region. Only applies when using TrustZone.
Non-secure Zone Non-Invasive Debug Restriction	Boolean -- enable/disable	This option enables or disables the ability to perform non-invasive debugging on the non-secure memory region. Only applies when using TrustZone.
Secure Zone Invasive Debug Restriction	Boolean -- enable/disable	This option enables or disables the ability to perform invasive debugging on the secure memory region. Only applies when using TrustZone.
Secure Zone Non-Invasive Debug Restriction	Boolean -- enable/disable	This option enables or disables the ability to perform non-invasive debugging on the secure memory region. Only applies when using TrustZone.
Device Serial Number	Not configurable by the user	128-bit unique identifier provisioned by Silicon Labs production process.

Table: SE Manager APIs for Secure Debug.


DCI Command (1)	SE Manager API	Usage
Enable Secure Debug	`sl_se_enable_secure_debug`	Enables the ability to securely unlock the debug port using a signed access token.
Disable Secure Debug	`sl_se_disable_secure_debug`	Disables the ability to securely unlock the debug port using a signed access token.
Set Debug Options	`sl_se_set_debug_options`	Sets options for restricting invasive/non-invasive debug access in the secure/non-secure memory regions.
Disable Device Erase	`sl_se_disable_device_erase`	Disables the device erase SE command. Once enabled, it is impossible to unlock the device through an erase.
Apply Lock	`sl_se_apply_debug_lock`	Locks the debug port. Unlocking depends on the secure debug lock and disable device erase settings.
- (2)	`sl_se_get_challenge`	Gets a random number challenge from the SE to be signed.
Roll Challenge	`sl_se_roll_challenge`	Rolls the random number challenge for unlocking the debug port.
Secure Debug Unlock	`sl_se_open_debug`	Unlocks the debug port. Requires a signed certificate.
Read Lock Status	`sl_se_get_debug_lock_status`	Returns the current state of the debug port lock.
Disable Device Erase	`sl_se_disable_device_erase`	Disables the Erase Device command. This command does not lock the debug interface to the part, but it is an IRREVERSIBLE action for the part.

Notes:
Performing these commands over DCI is implemented in Simplicity Commander.
Device challenge is retrieved through the secure unlock command.

Secure Key Storage#

The SE isolates cryptographic functions and data from the host core. The SE is used to accelerate cryptographic operations as well as provide a method to securely store keys.

The SE contains OTP key storage slots for three specific keys:

The Public Sign Key, used for Secure Boot and Secure Upgrades
The Public Command Key, used for Secure Debug unlock and tamper disable
The Symmetric OTA Decryption Key, used for Over-The-Air updates

These keys are one-time programmable and are persistent for the lifetime of the device.

Secure Key Storage Users and User-controlled Security Parameters#

The user of this feature is the end product developer who configures the feature using the SE manager APIs mentioned in Table: SE Manager APIs for Secure Key Storage and DCI commands through Simplicity Commander.

Table: Security Parameters for Secure Key Storage.


Parameter	Configuration Options	Description
Key Size	Integer -- number of bits	Indicates the size of the key in bits
Key Type	Integer -- type of key	Indicates the type of key symmetric or asymmetric
Key Permissions	Bitfield -- allowed uses for the key	A set of flags indicating the permitted uses for the key, the exportability of the key, and whether the key is in volatile or non-volatile memory
Key Storage	Data structure pointing to the physical storage location of the key	A pointer to the physical location of the key material together with a size parameter indicating the size of the key material
Key Password	Data structure	An optional 8-byte value which, if set, is required to use the key
Key Domain	Data structure	For ECC asymmetric keys, a set of data that indicates the parameters for the curve used

SE Volatile Storage#

The SE also contains four volatile storage slots for other user keys. These slots are not persistent through a reset. In the case where a key needs persistent storage, the key must be stored wrapped outside of the SE in non-volatile storage. After a device reset, the key can be loaded into the SE volatile key storage for usage by index or used in-place (passed to the SE on every requested operation).

Wrapped Keys#

Without any secure key storage mechanism, the user key stored in non-volatile storage is opened to storage-extraction attacks (such as gaining access to and downloading device flash), as well as application-level attacks (i.e., taking control of the user application or privileges in a manner that allows access to the keys). With Secure Key Storage, a user can only access a key from the SE in a "wrapped" format. In this format, the key is encrypted by a device-unique root key, only available to the SE. This allows a user to store a key confidentially in non-volatile storage to provide key persistence. Using Secure Key Storage, the plaintext key is never stored in non-volatile memory, preventing storage-extraction attacks from obtaining the key. After a device reset, the wrapped key can be loaded from non-volatile storage into the SE. The SE then unwraps the key and stores it in one of the key storage slots without ever exposing the plaintext key to the application, which also prevents application-level attacks from exposing the key. To perform cryptographic operations using a wrapped key, the key is referred to by its identifier. Refer to AN1271 for more details.

Key Slot Unit (KSU)#

The KSU module provides local key storage for wrapped keys. The SE can unwrap a wrapped key and place it in the KSU for the appropriate AES engine. Each key contains metadata that controls which AES engine may use it. The host cannot read the contents of the KSU slots directly, it can only reference the keys using their slot identifiers. KSU slots are volatile, meaning their contents are not visible when the device is powered off.

Note: DFA countermeasures are only available in the SE cryptographic accelerator, not in the host cryptographic accelerators. Any operations that should be protected against DFA attacks must be restricted to the SE.

Table: SE Manager APIs for Secure Key Storage.


SE Manager API	Usage
`sl_se_generate_key`	Generate a new key and store it either in a volatile HSE storage slot or as a wrapped key.
`sl_se_import_key`	Import a plaintext key and store it either in a volatile HSE storage slot or as a wrapped key.
`sl_se_export_key`	Export a volatile or wrapped key back to plaintext if allowed. It will fail for a key that has been flagged as `SL_SE_KEY_FLAG_NON_EXPORTABLE`.
`sl_se_transfer_key`	Transfer a volatile or wrapped key to another storage option (volatile HSE storage slot or a wrapped key) if allowed.
`sl_se_delete_key`	Delete a key from a volatile SE storage slot.
`sl_se_generate_key`	Generate a new key and store it either in a volatile HSE storage slot or as a wrapped key.
`sl_se_import_key`	Import a plaintext key and store it either in a volatile HSE storage slot or as a wrapped key.
`sl_se_export_key`	Export a volatile or wrapped key back to plaintext if allowed. It will fail for a key that has been flagged as `SL_SE_KEY_FLAG_NON_EXPORTABLE`.
`sl_export_public_key`	Export the public part of an ECC keypair.
`sl_se_validate_key`	Validates a key descriptor to determine if all of the required properties for that key type have been set.
`sl_se_get_storage_size`	Returns the required storage size for the given key.
`sl_se_init_otp_key`	Provision a key to SE OTP. Used for symmetric and public keys.
`sl_se_read_pubkey`	Read out a public key from SE OTP.

Secure Boot and Root of Trust Secure Loader (RTSL)#

One of the most important criteria for a secure product is to ensure that the firmware that defines the behavior of that product is authentic. Secure boot ensures that firmware is authentic by verifying the signature of that firmware using a tamper-resistant public key. The firmware is only allowed to run once it has been verified to be authentic. Another important feature of secure boot is roll-back protection. Firmware rollbacks should be prevented to mitigate an attacker's ability to take advantage of vulnerabilities in previous firmware versions. Refer to AN1218 for more details.

Secure Boot Users and User-controlled Security Parameters#

The user of this feature is the end product developer who configures the feature through the use of the SE manager APIs and DCI commands mentioned in Table: SE Manager APIs for Secure Boot.

Table: Secure Boot Security Parameters.


Parameter	Configuration options	Description
Secure Boot Enable	Boolean -- enable/disable	OTP flag to indicate whether secure boot is enforced or not
Secure Boot Anti-Rollback	Boolean -- enable/disable	OTP flag to indicate whether rollback protection of host firmware is enabled or not
Secure Boot Verify Certificate	Boolean -- enable/disable	OTP flag to indicate whether certificate-based signing of host firmware is required or not
Secure Boot Public Sign Key	ECC P-256 public key	User-generated ECC P-256 public key. Used to verify either the host firmware certificate when certificate-based secure boot is used, or the host firmware signature itself when certificate-based secure boot is not used
Secure Boot Certificate	Proprietary data structure	A certificate containing a version and a public key used to verify host firmware signature. This is injected into the host firmware image binary
Host Firmware Signature	ECDSA signature	User-generated signature created with ECDSA on ECC P-256 curve with the user's private signing key. Injected into the host firmware image binary

Table: SE Manager APIs for Secure Boot.


DCI Command (1,2)	SE Manager API	Usage
Write User Configuration	`sl_se_init_otp`	Provision the configuration settings to OTP. Settings include secure boot enforcement, anti-rollback of host firmware, flash page locking, and tamper response settings. Settings are provisioned as a single word. Therefore, all settings must be set in a single operation
Read User Configuration	`sl_se_read_otp`	Read out the OTP settings currently provisioned to the device
Get Device Status	`sl_se_get_status`	Read the boot status of the SE. The information retrieved also includes SE firmware version, state of the debug port lock, tamper status, secure debug configuration
-	`sl_se_check_se_image`	Validate SE firmware image
-	`sl_se_apply_se_image`	Apply SE firmware image
-	`sl_se_get_upgrade_status_se_image`	Get upgrade status of SE firmware image
-	`sl_se_check_host_image`	Validate Host firmware image
-	`sl_se_apply_host_image`	Apply Host firmware image
-	`sl_se_get_upgrade_status_host_image`	Get upgrade status of Host firmware image

Note:
Performing these commands over DCI is implemented in Simplicity Commander.
Not all commands exist as both APIs and DCI commands.

SE Boot Status#

The SE can be queried through the DCI interface to determine the boot status. Refer to AN1218 section 6 for a full list of the status codes.

Cryptographic Acceleration#

Security Parameters for Cryptographic Acceleration#

Table: Security Parameters for Cryptographic Algorithms.


Parameter	Configuration Options	Description
Private Key	Integer -- size depends on algorithm	For ECDSA/EdDDSA algorithms, this is the key used for signing. For key agreement algorithms, this is the key used together with a peer's public key for establishing a shared secret.
Public Key	Derived from associated private key and elliptic curve	For ECDSA/EdDDSA algorithms, this is the key used for verification. For key agreement algorithms, this is the key used together with a peer's private key for establishing a shared secret.
Elliptic Curve	One of the following: P-192, P-256, Curve25519	A set of parameters that define an elliptic curve. These are used to associate a public key with a private key.
Symmetric Key	Key material	128, 192, or 256 bits of key material used for encrypting/decrypting/authentication.
Key Size	For symmetric algorithms, 128, 192, or 256 bits	The size of the key to be used in AES operations.
Algorithm	One of the following: AES-ECB, AES-CFB8, AES-CFB128, AES-CBC, AES-CTR, AES-CMAC, AES-CCM, AES-GCM, ECDSA, EdDSA, ECDH, SHA1/SHA2/HMAC-AES-MMO, EC-JPAKE, HMAC	The cryptographic algorithm to be performed.
Operation	Encrypt or decrypt	This parameter controls the behavior of algorithms that support encryption or decryption through the same API function.
Nonce	Data	Initialization value for supported cipher algorithms.
Nonce Length	Integer -- allowable values depend on chosen algorithm	The length of the nonce passed to the cryptographic algorithm.
Input Data	Data	The data to be processed by the cryptographic algorithm.
Associated Data	Data	For supported algorithms, data that is to be used in the generation of an authentication tag but not encrypted or decrypted.
Output Data	Storage location	The storage location for the data output by the cryptographic algorithm.
Data Length	Integer -- allowable values depend on chosen algorithm	The length of the data to be operated on by the cryptographic algorithm. Configurable for all algorithms except AES-ECB.
Authentication Tag	Storage location	Location where an authentication tag such as a CCM or GCM tag is to be stored.
Authentication Tag Length	Integer -- allowable values depend on chosen algorithm	The length of authentication tag to be generated or verified by the chosen cryptographic algorithm.
Password	Data	Password for EC-JPAKE.
Password Length	Integer	Length of the EC-JPAKE password in bytes.
Role	Boolean -- client or server	The role for EC-JPAKE. Only values indicating client or server are allowable.
Hash Type	Integer	The type of hash to use. Supported hashes are SHA1, SHA2/256/384/512, and HMAC-AES-MMO.

Refer to SE Manager API for more information.

Asymmetric Cryptography#

Asymmetric cryptographic operations, those that operate on public/private keypairs, are always performed by the SE core. The supported curves and operations are summarized in Table: Supported Curves and Operations.

Table: Supported Curves and Operations.


Curve	Supported Operations
P-192, P-256	ECDSA, ECDH, EC-JPAKE
Curve25519	ECDH, EdDSA

All operations are available through the mailbox interface. The APIs are summarized in Table: SE Manager APIs for Asymmetric Cryptographic Functions.

Table: SE Manager APIs for Asymmetric Cryptographic Functions.


SE Manager API	Usage
`sl_se_ecc_sign`	This function computes Elliptic-Curve Cryptography (ECC) digital signatures of a message.
`sl_se_ecc_verify`	This function verifies Elliptic-Curve Cryptography (ECC) digital signatures of a message.
`sl_se_ecdh_compute_shared_secret`	This function computes the shared secret with Elliptic Curve Diffie Hellman (ECDH) algorithm.
`sl_se_ecjpake_check`	Check if an EC J-PAKE context is ready for use.
`sl_se_ecjpake_derive_secret`	Derive the shared secret (TLS: Pre-Master Secret).
`sl_se_ecjpake_free`	This clears an EC J-PAKE context and frees any embedded data structure.
`sl_se_ecjpake_init`	Initialize an EC J-PAKE context.
`sl_se_ecjpake_read_round_one`	Read and process the first round message (TLS: contents of the Client/ServerHello extension, excluding extension type and length bytes).
`sl_se_ecjpake_read_round_two`	Read and process the second round message (TLS: contents of the Client/ServerKeyExchange).
`sl_se_ecjpake_setup`	Set up an EC J-PAKE context for use.
`sl_se_ecjpake_write_round_one`	Generate and write the first round message (TLS: contents of the Client/ServerHello extension, excluding extension type and length bytes).
`sl_se_ecjpake_write_round_two`	Generate and write the second round message (TLS: contents of the Client/ServerKeyExchange).

Symmetric Cryptography#

Symmetric cryptographic operations such as AES and hash operations can be performed by the SE, when high performance on large blocks with high security is desired or by one of the host cryptographic accelerators. The following symmetric cipher modes are supported with key sizes of 128/192/256 bits:

ECB
CTR
CBC
CFB
CCM
GCM
CBC-MAC

The following hashes are supported:

SHA-1
SHA-2/256/384/512
HMAC-AES-MMO

Operations to be performed by the SE use the mailbox interface. The following user-friendly APIs are provided for these operations.

Table: SE Manager APIs for Symmetric Cryptographic Functions.


SE Manager API	Usage
`sl_se_aes_crypt_ecb`	AES-ECB block encryption/decryption.
`sl_se_aes_crypt_cbc`	AES-CBC buffer encryption/decryption.
`sl_se_aes_crypt_cfb128`	AES-CFB128 buffer encryption/decryption.
`sl_se_aes_crypt_cfb8`	AES-CFB8 buffer encryption/decryption.
`sl_se_aes_crypt_ctr`	AES-CTR buffer encryption/decryption.
`sl_se_ccm_encrypt_and_tag`	AES-CCM buffer encryption.
`sl_se_ccm_auth_decrypt`	AES-CCM buffer decryption.
`sl_se_ccm_multipart_starts`	Prepare a CCM streaming command context object.
`sl_se_ccm_multipart_update`	This function feeds an input buffer into an ongoing CCM computation.
`sl_se_ccm_multipart_finish`	Finish a CCM streaming operation and return the resulting CCM tag.
`sl_se_gcm_crypt_and_tag`	This function performs GCM encryption or decryption of a buffer.
`sl_se_gcm_auth_decrypt`	This function performs a GCM authenticated decryption of a buffer.
`sl_se_cmac`	This function calculates the full generic CMAC on the input buffer with the provided key.
`sl_se_cmac_multipart_starts`	Prepare a CMAC streaming command context object.
`sl_se_cmac_multipart_update`	This function feeds an input buffer into an ongoing CMAC computation.
`sl_se_cmac_multipart_finish`	Finish a CMAC streaming operation and return the resulting CMAC tag.
`sl_se_gcm_multipart_starts`	Prepare a GCM streaming command context object.
`sl_se_gcm_multipart_update`	This function feeds an input buffer into an ongoing GCM computation.
`sl_se_gcm_multipart_finish`	Finish a GCM streaming operation and return the resulting GCM tag.
`sl_se_hmac`	Compute an HMAC on a full message.
`sl_se_hmac_multipart_starts`	Prepare an HMAC streaming command context object to be used in subsequent HMAC streaming function calls.
`sl_se_hmac_multipart_update`	This function feeds an input buffer into an ongoing HMAC computation.
`sl_se_hmac_multipart_finish`	Finish an HMAC streaming operation and return the resulting HMAC.

Countermeasures for Side-channel and Other Physical Attacks#

Side channel attacks observe physical quantities such as power consumption to extract information such as secret keys. Physical fault injection can be used to alter program behavior. Refer to the following section for specific types of fault injection.

Fault Injection#

Power Supply Glitching#

Injecting current into the power supply of a victim device can cause applications to misbehave by altering bits in non-volatile memory. This type of attack is mitigated using a brown-out detector (BOD) which triggers a configurable automatic response.

Electromagnetic Glitching#

The presence of an electromagnetic pulse can cause applications to misbehave by altering bits in memory. Glitch detection circuits detect these fault injections and trigger a configurable automatic response.

Temperature Glitching#

Applications running on devices operating near their temperature limit may misbehave. A temperature sensor monitors the device temperature and can trigger a configurable automatic tamper response when the temperature is above or below the defined limits.

Enclosure Opening#

Most attacks in this section require the product's enclosure to be opened as a prerequisite. This can be detected with the External Tamper Detect (ETAMPDET) module.

Refer to AN1247 for details on automatic tamper responses.

Table: SE Manager APIs for Secure Tamper Responses.


DCI Command	SE Manager API	Usage
Write User Configuration	`sl_se_init_otp`	Initialize SE OTP configuration (including tamper configuration on HSE-SVH devices).
Read User Configuration	`sl_se_read_otp`	Read SE OTP configuration (including tamper configuration on HSE-SVH devices).
Generate Access Certificate	`sl_se_get_serialnumber`	Read out the serial number (16 bytes) of the HSE device.
Roll Challenge	`sl_se_get_challenge`	Read out the current challenge value (16 bytes) for tamper disable.
Get Device Status	`sl_se_get_status`	Read the current HSE status (including recorded tamper status on HSE-SVH devices).
-	`sl_se_get_tamper_reset_cause`	Read the cached value of the EMU->TAMPERRSTCAUSE register after a tamper reset.
-	`sl_se_disable_tamper`	Temporarily disable tamper configuration using the Disable Tamper Token.
-	`sl_se_get_reset_cause`	Read the EMU->RSTCAUSE register from HSE devices after a tamper reset.
-	`sl_se_get_tamper_reset_cause`	Read the cached value of the EMU->TAMPERRSTCAUSE register after a tamper reset.
-	`sl_se_enter_active_mode`	Force the SE to remain active to enable the detection of glitch tamper events on the host Cortex-M33 core.
-	`sl_se_exit_active_mode`	Exit active mode and allow the SE to sleep when not performing operations. This will prevent the detection of glitch tamper events when the SE is sleeping. This API should only be used if active mode was entered by calling `sl_se_enter_active_mode`. If active mode is set through a DCI command, it can only be disabled through a DCI command.

Note:
Performing these commands over DCI is implemented in Simplicity Commander.
Not all commands exist as both APIs and DCI commands.

Differential Power Analysis (DPA)#

Observing the power consumption of a device may leak information. DPA attacks are mitigated by "blinding" the power consumption of the device in a randomized pattern. DPA countermeasures are always on and cannot be disabled.

Differential Fault Analysis (DFA)#

Injecting faults during cryptographic operations may leak information about the internal state of the cryptographic accelerator. DFA attacks are mitigated by performing the same cryptographic operation more than once to compare the results. DFA countermeasures are always on and cannot be disabled.

Secure Tamper Response User-controlled Security Parameters#

Table: Secure Tamper Response Security Parameters.


Parameter	Configuration options	Description
Filter Period	Integer between 0 - 7	Determines the filter period. A tamper event is triggered if a number of filtered tamper events equal to or greater than the filter threshold occurs within the time determined by the filter period. Filter period is 32 ms × 2(n)
Filter Threshold	Integer between 0 -- 31	Determines the number of events required to trigger a filtered tamper. Threshold = 256/2 (n)
Reset Threshold	Integer between 0 - 255	Determines the number of times the device is reset due to a tamper before entering debug mode. Setting to "0" means never enter debug mode.
Active During Sleep	Boolean -- enable/disable	Determines whether tamper detection is active while the device is in sleep mode
Digital Glitch Always On	Boolean -- enable/disable	Determines whether glitch detection is always active
Crypto Error	One of Reset or erase OTP	Tamper source automatic response
DCI Authorization	One of Ignore, filter, interrupt, reset or erase OTP
Decouple Brownout Detect	One of Reset or erase OTP
DPLL Fail	One of Ignore, filter, interrupt, reset or erase OTP
External Tamper Detect	One of Ignore, filter, interrupt, reset or erase OTP
Filter Counter	One of Ignore, filter, interrupt, reset or erase OTP
Glitch Detector	One of Ignore, filter, interrupt, reset or erase OTP
KSU 1-bit ECC Error	One of Ignore, filter, interrupt, reset or erase OTP
KSU 2-bit ECC Error	One of Reset or erase OTP
L2 ICACHE Parity Error	One of Reset or erase OTP
Mailbox Authorization	One of Ignore, filter, interrupt, reset or erase OTP
OTP Alarm	One of Reset or erase OTP
PRS0	One of Ignore, filter, interrupt, reset or erase OTP
PRS1	One of Ignore, filter, interrupt, reset or erase OTP
PRS2	One of Ignore, filter, interrupt, reset or erase OTP
QSPI Reseed Error
Secure Boot Fail	One of Ignore, filter, interrupt, reset or erase OTP
Secure Lock Error	One of Reset or erase OTP
Selftest Error	One of Reset or erase OTP
SE Assert	One of Reset or erase OTP
SE CPU Major Fault	One of Reset or erase OTP
SE ICACHE Error	One of Reset or erase OTP
SE RAM ECC 1-bit Error	One of Ignore, filter, interrupt, reset or erase OTP
SE RAM ECC 2-bit Error	One of Reset or erase OTP
SE Watchdog	One of Reset or erase OTP
SOC PLL Fail	One of Ignore, filter, interrupt, reset or erase OTP
Temperature Sensor	One of Ignore, filter, interrupt, reset or erase OTP
TRNG Monitor	One of Ignore, filter, interrupt, reset or erase OTP