Closed yoshi-ohta closed 3 years ago
Hello @yoshi-ohta
You probably have a different one, as the Security Monitor Configuration is new feature presented in the M3
Second important thing, for the generally available chips on the market this value is blocked on purpose as its non-careful manipulation is always connected to some security risks and it is not possible to configure it. The configuration is freely configurable in case a new custom order is started.
Now to your questions: [Q1]: I think I have already answered it.
[Q2]: I've written a small article about the Security Monitor and I believe this figure from there (the one after the Finite State Machine) might help you to understand better the mechanics. Let me know if the Q2 is not covered there.
[Q3] so the value you see there is 247, you have an output of two sequential read_status commands, what will happen if you have the same setup, then: 1) call the trustm_read_status -> see the 7F output 2) call the trustm_sign_data 3) call the trustm_read_status -> see the output it should increase as well, if not can you please past here as well the log of it with timestamps
@ayushev
Hi, Thank you for replaying.
[Q1]: I think I have already answered it.
I made a mistake in the tip name, I'm sorry. The correct chip name is SLS32AIA010MK. (I used to use SLS32AIA010MS, but currently I use SLS32AIA010MK)
Therefore, I think you can configure Security Monitor, so please tell me how to set it. If you have any sample code, would you please provide it?
[Q2]: I've written a small article about the Security Monitor and I believe this figure from there (the one after the Finite State Machine) might help you to understand better the mechanics. Let me know if the Q2 is not covered there.
I have some questions.
[Q2-1] : Is the referenced flowchart the same flow for SLS32AIA010MK?
[Q2-2] : Is the value of "Security Event Counter" displayed by the trustm_read_status command the value of SEC (NVM)? Or is it the value of SEC (CREDIT)?
[Q2-3] : SecurityMonitor configuration settings are default values. (Tmax = 50 (5sec), SECcredit_max = 5, Delayed SEC decrement synchronization count = 1)
I think SEC (NVM) and SEC (CREDIT) will be decremented after the Tmax time (5sec). When I check with the trustm_read_status command, the SEC value is not decremented. The SEC value was not decremented even if it was left for 1.5 hours. (I haven't accessed TrustM for 1.5h) Why isn't the SEC decremented?
[Q2-4] : In the flowchar , What is the value of X in the judgment process of "(SECcurr + X) <= SECnvm"?
[Q2-5] : In the flowchar , Does Threshold mean SECcredit_max in the judgment process of "SECcurr> Threshold"?
[Q3] so the value you see there is 247, you have an output of two sequential read_status commands, what will happen if you have the same setup, then:
call the trustm_read_status -> see the 7F output call the trustm_sign_data call the trustm_read_status -> see the output it should increase as well, if not can you please past here as well the log of it with timestamps
There is no trustm_sign_data command in my environment. I have the following commands in my environment.
# cd /usr/bin
# ls trust*
trustm_cert trustm_errorcode trustm_read_status trustm_rsa_keygen
trustm_chipinfo trustm_hkdf trustm_readmetadata_data trustm_rsa_sign
trustm_data trustm_hmac trustm_readmetadata_private trustm_rsa_verify
trustm_ecc_keygen trustm_metadata trustm_readmetadata_status trustm_symmetric_dec
trustm_ecc_sign trustm_monotonic_counter trustm_rsa_dec trustm_symmetric_enc
trustm_ecc_verify trustm_read_data trustm_rsa_enc trustm_symmetric_keygen
[Q1]:
The security monitor is just a generic data object, though with a special functionality, if it is available for writing (LcsO is less than operational) you can form a value and update the object with the ./bin/trustm_data -w 0xe0e9 -i 1234.txt
, where the file contains target configuration. Table 80 from the SRM describes how the content should look like
So for instance, to recreate the current settings you need to write to the chip the following binary data: 0x32 0x00 0x05 0x01 0x00 0x00 0x00 0x00
[Q2-1] : yes, it describes the mechanics, how does it work for the whole OPTIGA Trust family (X, M1, M3, Charge)
[Q2-2]
it is a value of the Security Event Counter (SEC
counter which is stored in the NVM)?
[Q2-3] let me cross check it locally, I'll update this later on.
[Q2-4] The X is the Delayed SEC decrement synchronization count, the flowchart has this note in the left upper corner
[Q2-5] no, it doesn't, the SECcredit_max isn't related to the induced delays, please have a look on the diagram below the flowchart to see when delays are induced. Answer after SECcurr will be more than 128, so 128 is the threshold.
There is no trustm_sign_data command in my environment. I have the following commands in my environment.
Sorry, I meant any private key relevant command, for instance trustm_ecc_sign
@ayushev
[Q1] Returning to the very first question, the metadata settings are as follows. Therefore, the Security Monitor configuration cannot be changed. How can I change the Security Monitor config?
# trustm_metadata -r 0xE0C9
========================================================
[Size 0019] :
20 11 C0 01 07 C4 01 08 D0 03 E1 FC 07 D1 01 00
D3 01 FF
LcsO:0x07, Max:8, C:LcsO<0x07, R:ALW, E:NEV,
========================================================
# echo -en \\x32\\x00\\x05\\x01\\x00\\x00\\x00\\x00 > sec.conf
# trustm_data -w 0xE0C9 -i sec.conf
========================================================
Offset: 0
Input data :
32 00 05 01 00 00 00 00
4410:Error [0x8007] : OPTIGA device Access Condition Not Satisfied
========================================================
[Q2-1] : OK [Q2-2] : Yes. SEC has several variables (SECnvm, SECcredit, SECcurr). The value displayed by the trustm_read_status command is not decremented, so I was wondering which variable was displayed by the command.
[Q2-3] : Please check it.
[Q2-4] : OK. I'm sorry, I overlooked it.
[Q2-5] : OK
[Q3] : OK. I used the trutm_ecc_sign command, then SEC value was counted up.
[Q1]: sorry I probably didn't make it clear in the first answer.
Second important thing, for the generally available chips on the market this value is blocked on purpose as its non-careful manipulation is always connected to some security risks and it is not possible to configure it. The configuration is freely configurable in case a new custom order is started.
Also the same stated in the article:
Note: Configuration is allowed only during a new order configuration due to the security impact which this configuration might have.
To explain you what do you see:
4410:Error [0x8007] : OPTIGA device Access Condition Not Satisfied
The lifecycle state of this 0xe0c9 object is set to be 0x07 = operational, and the statement C:LcsO<0x07
means that the change is allowed only if LcsO<0x07 (less than operational) which isn't satisfied which means the change operation is not possible.
But in your case this value 247 looks very suspicious, do you see it often without doing much on the chip? If you don't perform a lot of security operation on the chip (like signing data, deriving a key, etc) you should not have this high value. There are some suggestions to how analyze further, but please share whether you do a lot of crypto relevant operations before you read out the SEC counter value or not?
@ayushev Sorry for the late response.
Note: Configuration is allowed only during a new order configuration due to the security impact which this configuration might have.
The Solution manual didn't have the above, so I thought we could set it up. Is my understanding correct that if we want to change the SecureMonitor settings, we need to request a change and have a special TrustM chip created?
There are some suggestions to how analyze further, but please share whether you do a lot of crypto relevant operations before you read out the SEC counter value or not?
ECC signature processing is performed during TLS communication. This process is the operation that mainly uses TrustM.
Currently, we access TrustM every time I reconnect due to poor communication environment. Also, the frequency of connections depends on the situation, so it is not clearly decided, but it is not a few.
[Q2-2] [Q2-3] We have not received any answers. Please answer its.
I have additional questions. [Q4] Just reading the data (trustm_read_status, trustm_data -r xxx, etc ...) will increase the SEC. The increase in SEC is described in SecurityEvents, but does SecurityEvents occur even when reading data?
[Q5] I think the ECC signature is causing a Security Evens "Private Key Use". Is my understanding correct? Also, is it possible to exclude only the "Private Key Use" event from the conditions for increasing the SEC?
The Solution manual didn't have the above, so I thought we could set it up.
It has, but I agree this might slip your attention. Table 71 depicts default Access Conditions for the objects, see below
Is my understanding correct that if we want to change the SecureMonitor settings, we need to request a change and have a special TrustM chip created?
Not exactly, it isn't a special Trust M chip, just personalized only for you. The chip remains the same, only personalization information will be applied.
ECC signature processing is performed during TLS communication. This process is the operation that mainly uses TrustM.
Currently, we access TrustM every time I reconnect due to poor communication environment. Also, the frequency of connections depends on the situation, so it is not clearly decided, but it is not a few.
I see, but it also doesn't sound like a very exhaustive usage. There is another aspect, due to a implementation nature of the commands (I guess you call them from the console) in linux, they use an i2c shielded connection (protected communication) for each command by default. As commands are in individual context (one command doesn't know about another) they will all try to establish a secure channel with the OPTIGA Trust by default, the latter triggers a SEC counter as a symmetric key is used to encrypt/decrypt the i2c communication session.
Important: A lot of commands don't need active protection (like signature generation or data read), for such commands you might use an option -X
(See trustm_data options)
I guess if you enable this it might significantly reduce SEC counter growing up that fast.
[Q2-2]
Sorry, I put a question mark, but that was already an answer, it is a SEC
counter stored in NVM
[Q2-3]
SecurityMonitor configuration settings are default values. (Tmax = 50 (5sec), SECcredit_max = 5, Delayed SEC decrement synchronization count = 1)
I think SEC (NVM) and SEC (CREDIT) will be decremented after the Tmax time (5sec). When I check with the trustm_read_status command, the SEC value is not decremented. The SEC value was not decremented even if it was left for 1.5 hours. (I haven't accessed TrustM for 1.5h) Why isn't the SEC decremented?
Just a small remark to have the same understanding: SEC(Credit) counts up if everything is fine and there are no security events, whereas SEC(NVM) counts down if everything is fine and no security events.
To the question: We tested internally once again and all looks good, SEC(NVM) counts down, could you please share logs how do you see this? So that we can analyze further?
[Q4]
This is because of the shielded communication being performed (this is valid only for Linux environment). Some functions which shouldn't been extra protected (this triggers a SEC counter additionally) should you -X
option.
[Q5]
I think the ECC signature is causing a Security Evens "Private Key Use". Is my understanding correct?
Correct
is it possible to exclude only the "Private Key Use" event from the conditions for increasing the SEC?
No this can't be modified, this might lead to attacks on the key, by calling a signature generation many times. Only SEC Monitor Configuration can change that behaviour.
[Q1]
Is my understanding correct that if we want to change the SecureMonitor settings, we need to request a change and have a special TrustM chip created?
Not exactly, it isn't a special Trust M chip, just personalized only for you. The chip remains the same, only personalization information will be applied.
OK. I got it.
Important: A lot of commands don't need active protection (like signature generation or data read), for such commands you might use an option -X (See trustm_data options) I guess if you enable this it might significantly reduce SEC counter growing up that fast.
Which command requires a shield connection?
[Q2-2] OK
[Q2-3]
To the question: We tested internally once again and all looks good, SEC(NVM) counts down, could you please share logs how do you see this? So that we can analyze further?
This is the log when the command is executed. I think SECcurr and SECnvm will be decremented after Tmax (5sec), but they were not decremented after waiting 30 minutes. When the board was turned off and on, the SEC value decreased.
Why does the SEC value decrease when the power is turned off and on? Is there any other information you need to investigate? Is there a way to check the SECcurr?
[2021-08-30 11:57:38.089] # trustm_read_status -X
[2021-08-30 11:57:38.089] Bypass Shielded Communication.
[2021-08-30 11:57:38.343] ========================================================
[2021-08-30 11:57:38.351] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 11:57:38.375] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 11:57:38.402] UID [0xE0C2] [Size 0027] :
[2021-08-30 11:57:38.402] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 11:57:38.402] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 11:57:38.412] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 11:57:38.422] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 11:57:38.447] Security Event Counter [0xE0C5] [Size 0001] : 69
[2021-08-30 11:57:38.487] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 11:57:38.495] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 11:57:38.519] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 11:57:38.544] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 11:57:38.544] ========================================================
Leave for 30 minutes (with the board turned on)
[2021-08-30 12:33:33.332] # trustm_read_status -X
[2021-08-30 12:33:33.332] Bypass Shielded Communication.
[2021-08-30 12:33:33.578] ========================================================
[2021-08-30 12:33:33.586] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 12:33:33.611] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 12:33:33.638] UID [0xE0C2] [Size 0027] :
[2021-08-30 12:33:33.638] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 12:33:33.638] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 12:33:33.646] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 12:33:33.655] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 12:33:33.680] Security Event Counter [0xE0C5] [Size 0001] : 69 (*)
[2021-08-30 12:33:33.719] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 12:33:33.727] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 12:33:33.752] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 12:33:33.777] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 12:33:33.777] ========================================================
(*) No change in SEC value
******* Board power off, and power on ******
[2021-08-30 12:38:12.670] # trustm_read_status -X
[2021-08-30 12:38:12.670] Bypass Shielded Communication.
[2021-08-30 12:38:12.950] ========================================================
[2021-08-30 12:38:12.993] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 12:38:13.043] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 12:38:13.096] UID [0xE0C2] [Size 0027] :
[2021-08-30 12:38:13.100] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 12:38:13.100] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 12:38:13.133] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 12:38:13.171] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 12:38:13.223] Security Event Counter [0xE0C5] [Size 0001] : 62 (*)
[2021-08-30 12:38:13.283] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 12:38:13.312] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 12:38:13.361] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 12:38:13.407] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 12:38:13.407] ========================================================
(*) When the power of the board is turned off and on, the SEC value decreases.
[2021-08-30 12:47:47.867] # trustm_read_status -X
[2021-08-30 12:47:47.867] Bypass Shielded Communication.
[2021-08-30 12:47:48.123] ========================================================
[2021-08-30 12:47:48.133] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 12:47:48.158] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 12:47:48.185] UID [0xE0C2] [Size 0027] :
[2021-08-30 12:47:48.185] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 12:47:48.185] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 12:47:48.194] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 12:47:48.202] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 12:47:48.228] Security Event Counter [0xE0C5] [Size 0001] : 62
[2021-08-30 12:47:48.269] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 12:47:48.278] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 12:47:48.303] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 12:47:48.329] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 12:47:48.329] ========================================================
[2021-08-30 12:48:06.085] # trustm_data -r 0xE0C5 -X
[2021-08-30 12:48:06.085] Bypass Shielded Communication.
[2021-08-30 12:48:06.340] ========================================================
[2021-08-30 12:48:06.364] Security Event Counter [0xE0C5] [Size 0001] : 62
[2021-08-30 12:48:06.364] ========================================================
[2021-08-30 13:24:25.786] # trustm_read_status -X
[2021-08-30 13:24:25.786] Bypass Shielded Communication.
[2021-08-30 13:24:26.040] ========================================================
[2021-08-30 13:24:26.050] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 13:24:26.074] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 13:24:26.100] UID [0xE0C2] [Size 0027] :
[2021-08-30 13:24:26.100] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 13:24:26.100] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 13:24:26.106] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 13:24:26.115] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 13:24:26.142] Security Event Counter [0xE0C5] [Size 0001] : 62
[2021-08-30 13:24:26.183] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 13:24:26.191] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 13:24:26.216] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 13:24:26.242] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 13:24:26.242] ========================================================
[2021-08-30 13:24:29.700] # trustm_data -r 0xE0C5 -X
[2021-08-30 13:24:29.700] Bypass Shielded Communication.
[2021-08-30 13:24:29.955] ========================================================
[2021-08-30 13:24:29.980] Security Event Counter [0xE0C5] [Size 0001] : 62
[2021-08-30 13:24:29.980] ========================================================
******* Board power off, and power on ******
[2021-08-30 13:25:56.827] # trustm_read_status -X
[2021-08-30 13:25:56.827] Bypass Shielded Communication.
[2021-08-30 13:25:57.077] ========================================================
[2021-08-30 13:25:57.086] Global Life Cycle Status [0xE0C0] [Size 0001] : 07
[2021-08-30 13:25:57.109] Global Security Status [0xE0C1] [Size 0001] : 20
[2021-08-30 13:25:57.135] UID [0xE0C2] [Size 0027] :
[2021-08-30 13:25:57.135] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00
[2021-08-30 13:25:57.135] 0B 00 42 00 78 80 10 10 71 24 40
[2021-08-30 13:25:57.149] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14
[2021-08-30 13:25:57.159] Current Limitation [0xE0C4] [Size 0001] : 06
[2021-08-30 13:25:57.184] Security Event Counter [0xE0C5] [Size 0001] : 58
[2021-08-30 13:25:57.226] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15
[2021-08-30 13:25:57.235] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01
[2021-08-30 13:25:57.260] Application Security Sts [0xF1C1] [Size 0001] : 20
[2021-08-30 13:25:57.285] Application Error Codes [0xF1C2] [Size 0001] : 00
[2021-08-30 13:25:57.285] ========================================================
[Q4] OK. After adding the "-X" option to the trustm_read_status command, the SEC no longer counts up.
[Q5] OK
@ yoshi-ohta For Q2-3, Could you kindly let us know which branch or which repository you are using? What is the test condition? only read status after SEC value is high already? We could not repeat this issue at our side yet. Thank you very much
@ying-css
For Q2-3, Could you kindly let us know which branch or which repository you are using?
We use it based on the following sources: repository : cli-optiga-trust-m: branch : development_v3 hash : d17543d
repository : trustm_lib: branch : trust_m1_m3 tag : v3.00.2490-ghr
What is the test condition?
I wanted to see the SEC value decrease, so I increased the SEC value with the following command.
# watch -n 1 trustm_read_status
When the SEC value increased to some extent, the command was stopped. After stopping the command, I waited for a while and checked the SEC value(by "trustm_read_status -X"). The board was not turned off during this operation.
only read status after SEC value is high already?
No. Since the SEC value does not decrease over time, I have run the read command many times to check. We mainly do ECC signing operations with TLS (Openssl).
@yoshi-ohta Could you kindly try
# watch -n 5 trustm_read_status -X
?Thanks.
@yoshi-ohta Do you have any observation by running # watch -n 5 trustm_read_status -X
? We repeated your command at our side, by setting interval to 5, the SEC value will go down. Please use this command to monitor the SEC counter going down.Thanks.
@ying-css
Sorry for the late reply. I executed trustm_read_status and increased the SEC. SEC = 0x91 (145)
[2021-09-02 10:16:31.234] # trustm_read_status -X [2021-09-02 10:16:36.328] [2021-09-02 10:16:36.329] Bypass Shielded Communication. [2021-09-02 10:16:36.583] ======================================================== [2021-09-02 10:16:36.595] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:16:36.617] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:16:36.644] UID [0xE0C2] [Size 0027] : [2021-09-02 10:16:36.644] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:16:36.644] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:16:36.652] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:16:36.663] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:16:36.688] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:16:36.726] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:16:36.735] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:16:36.760] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:16:36.785] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:16:36.785] ========================================================
I monitored the SEC value with "watch -n 5 trustm_read_status -X", but the SEC value did not decrease. Do you need any logs to find out why the SEC isn't going down?
[2021-09-02 10:16:53.552] Bypass Shielded Communication. [2021-09-02 10:16:53.805] ======================================================== [2021-09-02 10:16:53.818] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:16:53.847] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:16:53.867] UID [0xE0C2] [Size 0027] : [2021-09-02 10:16:53.867] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:16:53.867] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:16:53.877] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:16:53.889] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:16:53.914] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:16:53.954] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:16:53.966] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:16:53.988] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:16:54.014] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:16:54.014] ======================================================== [2021-09-02 10:16:59.069] [2021-09-02 10:16:59.069] Bypass Shielded Communication. [2021-09-02 10:16:59.319] ======================================================== [2021-09-02 10:16:59.326] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:16:59.350] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:16:59.378] UID [0xE0C2] [Size 0027] : [2021-09-02 10:16:59.378] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:16:59.378] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:16:59.384] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:16:59.394] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:16:59.420] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:16:59.460] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:16:59.469] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:16:59.492] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:16:59.517] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:16:59.517] ======================================================== [2021-09-02 10:17:05.174] [2021-09-02 10:17:05.174] Bypass Shielded Communication. [2021-09-02 10:17:05.176] ======================================================== [2021-09-02 10:17:05.176] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:17:05.176] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:17:05.176] UID [0xE0C2] [Size 0027] : [2021-09-02 10:17:05.176] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:17:05.176] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:17:05.176] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:17:05.176] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:17:05.176] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:17:05.176] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:17:05.176] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:17:05.176] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:17:05.176] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:17:05.176] ========================================================
...
[2021-09-02 10:55:00.548] [2021-09-02 10:55:00.548] Bypass Shielded Communication. [2021-09-02 10:55:00.794] ======================================================== [2021-09-02 10:55:00.806] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:55:00.827] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:55:00.854] UID [0xE0C2] [Size 0027] : [2021-09-02 10:55:00.854] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:55:00.854] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:55:00.864] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:55:00.873] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:55:00.897] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:55:00.939] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:55:00.947] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:55:00.971] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:55:00.998] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:55:00.998] ======================================================== [2021-09-02 10:55:06.047] [2021-09-02 10:55:06.047] Bypass Shielded Communication. [2021-09-02 10:55:06.303] ======================================================== [2021-09-02 10:55:06.316] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:55:06.338] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:55:06.365] UID [0xE0C2] [Size 0027] : [2021-09-02 10:55:06.365] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:55:06.365] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:55:06.373] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:55:06.383] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:55:06.407] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:55:06.447] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:55:06.454] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:55:06.479] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:55:06.504] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:55:06.504] ======================================================== [2021-09-02 10:55:11.555] [2021-09-02 10:55:11.555] Bypass Shielded Communication. [2021-09-02 10:55:11.814] ======================================================== [2021-09-02 10:55:11.827] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:55:11.849] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:55:11.875] UID [0xE0C2] [Size 0027] : [2021-09-02 10:55:11.875] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:55:11.875] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:55:11.883] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:55:11.891] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:55:11.914] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:55:11.953] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:55:11.960] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:55:11.985] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:55:12.014] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:55:12.014] ======================================================== [2021-09-02 10:55:17.062] [2021-09-02 10:55:17.062] Bypass Shielded Communication. [2021-09-02 10:55:17.307] ======================================================== [2021-09-02 10:55:17.322] Global Life Cycle Status [0xE0C0] [Size 0001] : 07 [2021-09-02 10:55:17.342] Global Security Status [0xE0C1] [Size 0001] : 20 [2021-09-02 10:55:17.368] UID [0xE0C2] [Size 0027] : [2021-09-02 10:55:17.368] CD 16 33 94 01 00 1C 00 01 00 00 0A 09 A4 13 00 [2021-09-02 10:55:17.368] 0B 00 42 00 78 80 10 10 71 24 40 [2021-09-02 10:55:17.374] Sleep Mode Activation Delay [0xE0C3] [Size 0001] : 14 [2021-09-02 10:55:17.382] Current Limitation [0xE0C4] [Size 0001] : 06 [2021-09-02 10:55:17.410] Security Event Counter [0xE0C5] [Size 0001] : 91 [2021-09-02 10:55:17.448] Max Com Buffer Size [0xE0C6] [Size 0002] : 06 15 [2021-09-02 10:55:17.460] Application Life Cycle Sts [0xF1C0] [Size 0001] : 01 [2021-09-02 10:55:17.485] Application Security Sts [0xF1C1] [Size 0001] : 20 [2021-09-02 10:55:17.508] Application Error Codes [0xF1C2] [Size 0001] : 00 [2021-09-02 10:55:17.508] ========================================================
@yoshi-ohta Is there any other background activity running which is accessing trustm at the same time? Thanks.
@ying-css
No other process is accessing TrustM. If the SEC value doesn't go down, does it mean that TrustM is in a strange state? If so, is there a way to check the status?
@yoshi-ohta Could you kindly check out from the latest update from development_v3 branch(also do submodule update) and check again? The commands for latest update are listed below as your reference.
git checkout development_v3
git submodule update -f
Then monitor the SEC value with "watch -n 5 trustm_read_status -X" Please let us know whether SEC value will go down with the latest update. Thank you very much.
@ying-css Based on the latest version, I tried porting I2C and GPIO for our board(i.MX8MM).
However, the command execution fails. The log when it fails is shown below. Do I need to make any special settings to use the latest version?
[2021-09-06 16:54:43.035] ~/TrustM/bin# ./trustm_chipinfo
[2021-09-06 16:54:48.138] pal_loger_write : [optiga util] : optiga_util_open_application
[2021-09-06 16:54:48.138] pal_loger_write :
[2021-09-06 16:54:48.138]
[2021-09-06 16:54:48.143] pal_loger_write : [optiga cmd] : optiga_cmd_open_application
[2021-09-06 16:54:48.143] pal_loger_write :
[2021-09-06 16:54:48.143]
[2021-09-06 16:54:48.152] [IFX-PRL]: Init
[2021-09-06 16:54:48.152] [IFX-TL]: Init
[2021-09-06 16:54:48.155] [IFX-DL]: Init
[2021-09-06 16:54:48.155] [IFX-PL]: Init
[2021-09-06 16:54:54.535] 7488:Error in trustm_helper/trustm_helper.c:1019 trustm_WaitForCompletion: Fail : Optiga Busy Time Out:6000
[2021-09-06 16:54:54.535]
[2021-09-06 16:54:54.537] 7488:Error in trustm_helper/trustm_helper.c:1091 _trustm_Open: Fail : optiga_util_open_application
[2021-09-06 16:54:54.537]
[2021-09-06 16:54:54.537]
[2021-09-06 16:54:54.537] 7488:Error [0x0001] : OPTIGA host library in busy state
[2021-09-06 16:54:54.740] pal_loger_write : [optiga util] : optiga_util_open_application
[2021-09-06 16:54:54.740] pal_loger_write :
[2021-09-06 16:54:54.745]
[2021-09-06 16:55:01.133] 7488:Error in trustm_helper/trustm_helper.c:1019 trustm_WaitForCompletion: Fail : Optiga Busy Time Out:6000
[2021-09-06 16:55:01.133]
[2021-09-06 16:55:01.133] 7488:Error in trustm_helper/trustm_helper.c:1091 _trustm_Open: Fail : optiga_util_open_application
[2021-09-06 16:55:01.139]
[2021-09-06 16:55:01.139]
[2021-09-06 16:55:01.139] 7488:Error [0x0001] : OPTIGA host library in busy state
[2021-09-06 16:55:01.139] 7488:Error in trustm_helper/trustm_helper.c:1126 trustm_Open: Error opening Trust M, EXIT
@ying-css Based on the latest version, I tried porting I2C and GPIO for our board(i.MX8MM).
- trustm_lib/pal/linux/pal_i2c.c (modified)
- trustm_lib/pal/linux/pal_gpio.c (modified)
- trustm_lib/pal/linux/target/xxx/pal_ifx_i2c_config.c (added)
However, the command execution fails. The log when it fails is shown below. Do I need to make any special settings to use the latest version?
[2021-09-06 16:54:43.035] ~/TrustM/bin# ./trustm_chipinfo [2021-09-06 16:54:48.138] pal_loger_write : [optiga util] : optiga_util_open_application [2021-09-06 16:54:48.138] pal_loger_write : [2021-09-06 16:54:48.138] [2021-09-06 16:54:48.143] pal_loger_write : [optiga cmd] : optiga_cmd_open_application [2021-09-06 16:54:48.143] pal_loger_write : [2021-09-06 16:54:48.143] [2021-09-06 16:54:48.152] [IFX-PRL]: Init [2021-09-06 16:54:48.152] [IFX-TL]: Init [2021-09-06 16:54:48.155] [IFX-DL]: Init [2021-09-06 16:54:48.155] [IFX-PL]: Init [2021-09-06 16:54:54.535] 7488:Error in trustm_helper/trustm_helper.c:1019 trustm_WaitForCompletion: Fail : Optiga Busy Time Out:6000 [2021-09-06 16:54:54.535] [2021-09-06 16:54:54.537] 7488:Error in trustm_helper/trustm_helper.c:1091 _trustm_Open: Fail : optiga_util_open_application [2021-09-06 16:54:54.537] [2021-09-06 16:54:54.537] [2021-09-06 16:54:54.537] 7488:Error [0x0001] : OPTIGA host library in busy state [2021-09-06 16:54:54.740] pal_loger_write : [optiga util] : optiga_util_open_application [2021-09-06 16:54:54.740] pal_loger_write : [2021-09-06 16:54:54.745] [2021-09-06 16:55:01.133] 7488:Error in trustm_helper/trustm_helper.c:1019 trustm_WaitForCompletion: Fail : Optiga Busy Time Out:6000 [2021-09-06 16:55:01.133] [2021-09-06 16:55:01.133] 7488:Error in trustm_helper/trustm_helper.c:1091 _trustm_Open: Fail : optiga_util_open_application [2021-09-06 16:55:01.139] [2021-09-06 16:55:01.139] [2021-09-06 16:55:01.139] 7488:Error [0x0001] : OPTIGA host library in busy state [2021-09-06 16:55:01.139] 7488:Error in trustm_helper/trustm_helper.c:1126 trustm_Open: Error opening Trust M, EXIT
@ying-css
For Q2-3, Could you kindly let us know which branch or which repository you are using?
We use it based on the following sources: repository : cli-optiga-trust-m: branch : development_v3 hash : d17543d
repository : trustm_lib: branch : trust_m1_m3 tag : v3.00.2490-ghr
What is the test condition?
I wanted to see the SEC value decrease, so I increased the SEC value with the following command.
# watch -n 1 trustm_read_status
When the SEC value increased to some extent, the command was stopped. After stopping the command, I waited for a while and checked the SEC value(by "trustm_read_status -X"). The board was not turned off during this operation.
only read status after SEC value is high already?
No. Since the SEC value does not decrease over time, I have run the read command many times to check. We mainly do ECC signing operations with TLS (Openssl).
@yoshi-ohta based one your previous working configuration,
repository : cli-optiga-trust-m: branch : development_v3 hash : d17543d
repository : trustm_lib: branch : trust_m1_m3 tag : v3.00.2490-ghr
We found that the SEC counter was not reducing due to the RESET pin is pulled LOW(not released properly). To verify this, you may disconnect the RESET pin and use SOFT RESET by setting the in the "optiga_lib_config_m_v3.h"
#define OPTIGA_COMMS_DEFAULT_RESET_TYPE (1U)
We have tested the latest development_v3 and the submodules, it should work the same and with the RESET in the correct state(HIGH).
@yoshi-ohta
for the following
trustm_lib/pal/linux/target/xxx/pal_ifx_i2c_config.c
(added)`
some minor changed needed https://github.com/Infineon/optiga-trust-m/blob/b172bcbd54571a5f4e006f299283b322099972a3/pal/linux/target/rpi3/pal_ifx_i2c_config.c#L44
for the following
trustm_lib/pal/linux/pal_i2c.c (modified)
minor change on the "pal_linux->i2c_if"
@RaymWong
Thank you for replaying.
for the following
trustm_lib/pal/linux/target/xxx/pal_ifx_i2c_config.c
(added)`some minor changed needed
After making this fix, the command should succeed.
for the following
trustm_lib/pal/linux/pal_i2c.c (modified)
minor change on the "pal_linux->i2c_if"
This fix has already been incorporated.
We found that the SEC counter was not reducing due to the RESET pin is pulled LOW(not released properly). To verify this, you may disconnect the RESET pin and use SOFT RESET by setting the in the "optiga_lib_config_m_v3.h"
define OPTIGA_COMMS_DEFAULT_RESET_TYPE (1U)
We have tested the latest development_v3 and the submodules, it should work the same and with the RESET in the correct state(HIGH).
[For the latest source] On our custom board, we only have GPIO RST. There is no VDD. After making the following settings, the SEC value decreased. Therefore, when I checked with the following settings, the SEC value dropped. When I checked RST GPIO after executing "trustm_read_status" command, it was High (= 1).
#define OPTIGA_COMMS_DEFAULT_RESET_TYPE (2U)
By the way, when the value is 1U, communication has failed.
[For the source that was originally used] I made the same setting for OPTIGA_COMMS_DEFAULT_RESET_TYPE, but the SEC value did not decrease. When I checked RST GPIO after executing "trustm_read_status" command, it was Low (= 0).
[Q6] Is there a bug in the version we are using that causes the RST GPIO settings to go wrong? (I checked the source diff, but I couldn't figure out which fix fixed this bug)
[Q7] For the latest source, If I check every 5 seconds, the SEC value will decrease, but if I check it in less than 5 seconds, the SEC value will not decrease. Why doesn't the SEC value go down?
@RaymWong
Thank you for replaying.
for the following
trustm_lib/pal/linux/target/xxx/pal_ifx_i2c_config.c
(added)` some minor changed needed https://github.com/Infineon/optiga-trust-m/blob/b172bcbd54571a5f4e006f299283b322099972a3/pal/linux/target/rpi3/pal_ifx_i2c_config.c#L44After making this fix, the command should succeed.
for the following
trustm_lib/pal/linux/pal_i2c.c (modified)
minor change on the "pal_linux->i2c_if"This fix has already been incorporated.
We found that the SEC counter was not reducing due to the RESET pin is pulled LOW(not released properly). To verify this, you may disconnect the RESET pin and use SOFT RESET by setting the in the "optiga_lib_config_m_v3.h"
define OPTIGA_COMMS_DEFAULT_RESET_TYPE (1U)
We have tested the latest development_v3 and the submodules, it should work the same and with the RESET in the correct state(HIGH).
[For the latest source] On our custom board, we only have GPIO RST. There is no VDD. After making the following settings, the SEC value decreased. Therefore, when I checked with the following settings, the SEC value dropped. When I checked RST GPIO after executing "trustm_read_status" command, it was High (= 1).
#define OPTIGA_COMMS_DEFAULT_RESET_TYPE (2U)
By the way, when the value is 1U, communication has failed.
[ANS]: The state of the RST is correct at HIGH and if VDD is not used the correct value is OPTIGA_COMMS_DEFAULT_RESET_TYPE =2U as you mentioned.
[For the source that was originally used] I made the same setting for OPTIGA_COMMS_DEFAULT_RESET_TYPE, but the SEC value did not decrease. When I checked RST GPIO after executing "trustm_read_status" command, it was Low (= 0).
[Q6] Is there a bug in the version we are using that causes the RST GPIO settings to go wrong? (I checked the source diff, but I couldn't figure out which fix fixed this bug)
[ANS]: Will need further check on the exact changes made that resolved the issue. [Q7] For the latest source, If I check every 5 seconds, the SEC value will decrease, but if I check it in less than 5 seconds, the SEC value will not decrease. Why doesn't the SEC value go down? [ANS]: It must be IDLE for tmax for the SEC CNT to decrease as mention in the following link https://github.com/Infineon/optiga-trust-m/wiki/Security-Monitor#security-policy-in-the-nutshell
Thanks a lot for your feedback.
@yoshi-ohta Please refer to new issue raised. #68 pertaining to your Q6. Based on the latest code, you may enable #define TRUST_CLOSE_APP_ENABLE to repeat the same behavior. https://github.com/Infineon/linux-optiga-trust-m/blob/5e93cb40c1b0df31ddcaa1316d8f3545316956da/trustm_helper/include/trustm_helper.h#L50
@RaymWong
[Q6] : Thank you for confirmation. There was a bug in trustm_Close () and the SEC value didn't decrease, correct?
[Q7] : OK. I got it.
@yoshi-ohta
@RaymWong
[Q6] : Thank you for confirmation. There was a bug in trustm_Close () and the SEC value didn't decrease, correct? [ANS] Yes, this is will be investigated separately in #68 [Q7] : OK. I got it.
Thanks a lot for your feedback and if there is no more security monitor topic. Kindly close the this issue for now.
@RaymWong
I have no special topics so far, so I'll close it. Thank you for your support!!
Hi, We are running an application on Linux. This application accesses TrustM when using TLS. At this time, the value of SecureMonitorCounter (SEC) is counted up. If you continue to access TrustM, the SEC will be counted up and the response from TrustM will gradually slow down. As a result, the performance of the application is reduced.
So we have some questions. We are using SLS32AIA010MS chip, and we have confirmed OPTIGA_Trust_M_Solution_Reference_Manual (Rev3.15).
[Q1] We would like to change the Security Monitor configuration described in OPTIGA_Trust_M_Solution_Reference_Manual 4.6.3. However, the metadata for OID = 0xE0C9 looks like this and cannot be changed. How can we change the Security Monitor configuration?
The following is reference information.
[Q2] The value of SEC cucurrent keeps increasing. Even if I waited for a while and then accessed it, the SEC value did not decrease. The SEC value is decremented over time for the Tmax value in OPTIGA_Trust_M_Solution_Reference_Manual Figure 28-Security Monitor flow diagram. However, the value of SEC is not decremented. Is this behavior correct? And, SEC does not return to 0 after rebooting. The SEC value is decrease.
[Q3] The SEC value does not count up from 0xF7. After communicating with TrustM for a while, the SEC value will no longer count up from 0xF7. OPTIGA_Trust_M_Solution_Reference_Manual 4.6.4 states that the maximum value of SEC is 255, but it does not reach that level.