Community Translation(JP): OPTIGA™ Trust M: セキュリティ モニタ – KBA235349
version: **
1 Security monitor
Security monitor is the central component of OPTIGA™ Trust M that enforces, controls, and responds to security events.
1.1 Security events
Security events in OPTIGA™ Trust M are frequently triggered by the operations that access secret or private keys. This is to ensure that physical and logical attacks are slowed down from an attacker’s point of view. For example,
There are many known physical attacks like Side channel power analysis, where the attacker may probe into the power consumption and figure out few bytes of the secret key (if not all) when OPTIGA™ Trust M is running these jobs. Another type of physical attack is fault injection, where the attacker injects faults into the system via voltage glitching, clock glitching, and so on. OPTIGA™ Trust M is built with these attacks in mind from the hardware side, which makes OPTIGA™ Trust M resistant to these attacks. The security is enhanced further on the software side, by throttling the performance of OPTIGA™ Trust M in order to avoid exploitation via brute force.
The following operations or jobs performed by OPTIGA™ Trust M are considered as security events by the security monitor.
1.1.1 Decryption failure
Decryption in both asymmetric and symmetric algorithms can be done only by using the private and secret key respectively. Therefore, a failure in decryption is a security event. Additionally, integrity check failure using a public key is also considered as a decryption failure event.
1.1.2 Key derivation
OPTIGA™ Trust M triggers a security event if a key is derived using a previously existing pre-shared secret key. The pre-shared secret key is stored in a persistent object and is used in encrypting the communication over the I2C channel between the host (like PSoC™ or Arduino) and OPTIGA™ Trust M.
1.1.3 Private key use
This security event is triggered if a private key is used to generate the signature. The private key is a key stored in any persistent object of OPTIGA™ Trust M. Session keys are exempted, because they are short-lived (stored and used via volatile memory like the RAM) and are unique to a session. An attacker does not gain much by probing a session private key compared to probing a persistent private key, which may permanently compromise a secure system.
1.1.4 Secret key use
The same rules of private keys apply to secret keys as well. Its usage from a persistent key object triggers a security event and session keys are exempted.
1.1.5 Suspect system behaviour
This security event is triggered if OPTIGA™ Trust M detects that the system in which it is deployed is compromised. This may happen when it detects inconsistent information or redundant information in the system, which may bait the system into revealing its secret elements.
For example, fault injection methods like clock glitch, voltage glitch may result in skipping an instruction or unknown states within a device. This is considered as suspect system behaviour by OPTIGA™ Trust M. Other scenarios include package tampering and unexpected temperature variations.
1.2 Security monitor policy
The security monitor enforces a few rules and restrictions on what operations and how many operations in a given time (tmax) OPTIGA™ Trust M can perform. The following are the rules and restrictions:
- One protected operation per tmax. Protected operations are private/secret key usage from this list that trigger the security monitor (excluding suspect system behavior). The default value of tmax is 5 seconds, and can be configured.
- If tmax = 0, security monitor is disabled.
- If tmax > 5 s, it is considered as 5. In other words, tmax > 5 s can be configured, but it is internally considered as 5s.
If more than one protected operation is performed within the tmax period, a counter called “security event counter” (SEC) is incremented by 1 (SEC is incremented by 1 per protected operation and decremented by 1 after tmax).
- Suspect system behavior is not allowed and it sets the SEC to maximum.
For example, if a private key is used for signature generation, the SEC is incremented by 1. For suspect system behavior, the SEC is incremented directly to 255 (max of 1-byte).
1.3 Security event counter (SEC)
SEC is a 1-byte counter in the security monitor, holding the count of security events. The SEC is stored persistently in non-volatile memory (NVM). The SEC is a count of security events; its core mechanism is quite simple.
- Increment by 1 for every protected operation executed on OPTIGA™ Trust M.
- Decrement by 1 when tmax elapses.
For example, if OPTIGA™ Trust M performs 1 decryption (secret key use), 1 signature generation (private key use), 1 key derivation within tmax, then SEC = (1+1+1) = 3. After tmax elapses, SEC = (3-1) = 2
1.3.1 Security event counter credit (SECCREDIT)
Because of the nature of NVMs, which generally have endurance cycles (number of programming cycles up to which the data stored is reliable), SECCREDIT mechanism is used by the security monitor to save the stress on NVM cells and enhance their durability. To understand the SECCREDIT mechanism, consider the following example:
Consider a scenario where the host microcontroller (like PSoC™ or Arduino) does not trigger a protected operation on OPTIGA™ Trust M that could cause a security event for 100 seconds and SEC is 0. Using the default tmax of 5 s, OPTIGA™ Trust M rewards the host with (100/5) = 20 SECCREDIT. As this is credit, it works in the opposite direction. If the host triggers OPTIGA™ Trust M for 20 protected operations within tmax of 5 s, then the SEC will not be incremented, instead SECCREDIT will get decremented by 20. So, at least 20 NVM write operations of the SEC are saved, because the security events were handled in a RAM variable named SECCREDIT, instead of the SEC, which is in the NVM.
To summarize:
- The SECCREDIT is cleared after power up or restart because it is in the RAM.
- If the tmax elapses without a security event and the SEC is > 0, the SEC is decremented by one.
- If tmax elapses without a security event and the SEC is 0, SECCREDIT is incremented by one to the maximum limit configured (SECCREDIT_MAX, 5 by default).
- If a security event occurs and SECCREDIT is > 0, SECCREDIT is decremented by one.
- If the SECCREDIT is = 0 and a security event occurs, the SEC incremented.
1.3.2 Delayed SEC decrement synchronization count (SECDELAY)
This is another mechanism along with SECCREDIT to increase the durability of NVM cells. The SEC has two copies.
- SECCURR: Current SEC, which is maintained in the RAM. This value is updated real time on every security event.
- SECNVM: Persistent copy of the SEC, which is maintained in the NVM. This value is not necessarily updated in real time. At this point, “delayed SEC decrement synchronization count” is considered.
The delayed SEC decrement synchronization count is set to ‘1 ‘by default. This is also the minimum allowed value. If it is set to ‘0’, it is still considered to be ‘1’. This is because of the implementation shown in Figure 1.
- This count is a persistent configuration stored in the security monitor.
“Delayed SEC decrement synchronization count” is the solution at the time of SEC decrement (due to tmax elapse). Instead of decrementing SECNVM in line with SECCURR, writing of the decremented value can be delayed to SECNVM by a configured number of tmax intervals. Effectively, if the delay sync decrement count is configured as ‘4’, the SEC is only decremented in RAM until (4*tmax) elapses, and only after (4*tmax) elapses, the real-time SECCURR in RAM is copied to SECNVM. In other words, we wrote to NVM only once, instead of four times, thereby saving three NVM write cycles. This will scale up over the lifetime of the OPTIGA™ Trust M device and significantly increase the NVM durability.
Figure 1 Security monitor flow diagram (Implementation details)
1.4 Throttling down profile
OPTIGA™ Trust M throttles its performance as a guard against planned attacks like side channel analysis involving power. The throttling of performance starts when the SEC reaches a threshold value (see Figure 1) of 128 (or >127). OPTIGA™ Trust M starts slowing down the operations by inducing a specific amount of delay. This is shown in Figure 1 at the bottom left “Induce Delay” block. The delay induced increases linearly over the SEC and reaches the maximum delay of tmax when the SEC reaches 255 (SEC max).
Figure 2 Throttling down profile
Consider the following example:
From Figure 2, if SEC > 127, consider it as 150, and consider tmax = 5 s. If the host microcontroller triggers a signature verification job at OPTIGA™ Trust M, it takes up the job only after a certain induced delay. As there are 128 values between 127-255, the delay to be (tmax/128) = (5/128) per SEC increase from 128 can be calculated. In this example, SEC is 150, so considering a linear throttling profile, the induced delay in this case is (5/128) * (150-128) = (5/128) * 20 = 0.78125s = 781.25 ms. If SEC reaches 255, the induced delay is 5 s.
1.5 Security monitor configuration
The following screenshot is taken from the solution reference manual that provides hints on how to configure the security monitor.
Figure 3 Security monitor configuration