Security Monitor
The Security Monitor is a central component, which enforces the security policy of the OPTIGA™ Trust hardware. It consumes security events sent by security aware parts of the OPTIGA™ embedded software and takes actions accordingly. For instance, in case the firmware detects that the host MCU sends "Sign my data" commands to the OPTIGA™ Trust too often, the latter will induce delays between signature operation.
More data about the Security Counter you can find in the Solution Reference Manual (.pdf).
Below is a list of events, which the firmware on the security solution counts:
Note: Applicable for both OPTIGA™ Trust M1 and OPTIGA™ Trust M3
| Name | Description |
|---|---|
| Decryption Failure | The Decryption Failure event occurs in case a decryption and/ or integrity check of provided data lead to an integrity failure |
| Key Derivation | The Key Derivation event occurs in case an operation, which executes a key derivation gets applied on a persistent data object which contains a pre-shared secret. |
| Private Key Use | The Private Key Use event occurs in case the internal services are going to use a OPTIGA™ hosted private key, except temporary keys from session context are used for key agreement like ECDH. |
| Secret Key Use | The Secret Key Use event occurs in case the internal services are going to use a OPTIGA™ hosted secret (symmetric) key (once per respective command), except temporary keys from session context are used. |
| Suspect System Behavior | The Suspect System Behavior event occurs in case the embedded software detects inconsistencies with the expected behavior of the system. Those inconsistencies might be redundant information, which doesn’t fit to their counterpart. This might happen for instance if a underlying hardware detects suspicious or unexpected voltage/current deviation. |
The Security Monitor on the OPTIGA™ Trust have two indicators to decide whether to induce a delay or not, these are SEC counter and SEC-credit counter (lower -> better), the first one resides in NVM and has a maximum of 255, whereas the second one is in RAM and set to 0 after every reboot with a maximum value set to 5 (by default, but configurable). The latter has been introduced to reduce NVM stress and increase lifetime of the security solution. The SEC-credit counter works as a buffer to accumulate security events before increasing the SEC counter.
The figure below depicts a complete state machine
The Figure below depicts different situations when the Security Monitor has to induce delays between consequent operations
The induced delay reaches its maximum when the SEC counter reaches its maximum and becomes tmax (by default this value is set to 5 sec).
In case no security relevant operations is detected the blocks (see the figure above) or the counter value will slowly restore to its original value, this restoration happens every tmax (by default this value is set to 5 sec). In other words if in some point of the time the OPTIGA™ Trust reached for the SEC counter the value 255 and afterwards no security relevant operation is performed, the security solution needs to wait:
- 128 * tmax (5 sec) = 640 sec before doing a first security relevant operation with no delay induced
- 256 * tmax (5 sec) = 1280 sec till the complete
SECcounter recovery - (256 + 5) * tmax (5 sec) = 1305 sec till the complete
SECandSECcreditcounter recovery
Starting from the OPTIGA™ Trust M3 it is possible to configure the Security Monitor behavior. Note: Configuration is allowed only during a new order configuration due to the security impact which this configuration might have.
This value defines how fast does the recovery to smaller SEC values happen (Note: smaller is better with no induced delays). The default value is set to 5 seconds. If tmax is set to 0, the security monitor gets disabled. In general, higher tmax value lowers the possible frequency of attacks.
This value defines how many "credits" can the system accumulate before counting up the SEC counter, this SECcredit resides in the RAM memory and gets flushed every power cycle. The default value is 5.
The SEC is as well maintained in RAM (SECCURR) in addition to the NVM (Security Event Counter (SEC))(SECNVM) and the synchronization (writing to SEC data object in NVM) of decrement events (e.g. tmax elapsed or Decryption Failure) can be delayed by configuring this value (> 1). If there are multiple security events with in tmax due to use case demand, the number of NVM write operations can be avoided by configuring this count appropriately. The default and minimum value is 1. In case, this value is configured to 0, minimum 1 will be applied. This option reduces SEC NVM write operations reasonably across the life time, if there are too frequent security events.
For example, if this configuration is set to 4, and there are 4 security events (e.g. sign operations) immediate after reset which led to SEC increment, then the total number of SEC NVM write operations are 5 instead of 8 (in case of default ( = 1) configuration).