Close
1 Security monitor
Security monitor is the central component of OPTIGA™ Trust M that enforces, controls, and responds to 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.
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.
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.
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.
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.
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.
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:
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).
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).
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.
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
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:
This is another mechanism along with SECCREDIT to increase the durability of NVM cells. The SEC has two copies.
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.
“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)
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.