TRUST M MTR SHIELD cannot read data.

[NNAA0917]

Have you looked for an answer?

I am referring to the README for linux-optiga-trust-m.

Question/Issue:

I am using OPTIGA TRUST M MTR.
I connected https://github.com/Infineon/linux-optiga-trust-mを参考にRaspberry pi4B and TRUST M MTR SHIELD.
In addition, I have implemented the following on Raspberry pi4B.
git clone --recurse-submodules https://github.com/Infineon/linux-optiga-trust-m.git
cd linux-optiga-trust-m
./provider_installation_script.sh

To pair the host with OPTIGA™ Trust M, I executed the following to write the default shared secret to OPTIGA™ Trust M.
cd linux-optiga-trust-m/scripts/misc/
./write_default_shared_secret
When I execute the above, the following error is output and I cannot connect normally.
Generate default shared secret

Bypass Shielded Communication.

Shared Platform Binding Secret. [0xe140]

1922:Error [0x8007] : OPTIGA device Access Condition Not Satisfied
Please tell me the cause.

Context

Raspberry pi4B
TRUST M MTR SHIELD

[ying-css]

Hi @NNAA0917 It seems you are using TRUST M MTR SHIELD. Please note that the script write_default_shared_secret.sh is specifically designed for OPTIGA™ Trust M V3 variant. For the MTR variant, the Lcso has been set to operational mode and the change conditions are restricted to Conf-0xE140&&Auto-0xF1D0. This means modifications can only be made if you have both the PBS and Auth.Ref which can be claimed here. To check the metadata for PBS (0xE140) on your device, you can run the following command: ./bin/trustm_metadata -r 0xe140 -X .Thanks.

[NNAA0917]

Hi @ying-css
Thanks for the confirmation.

. /write_default_shared_secret.sh
and ,
. /bin/trustm_metadata -r 0xe140 -X
you will get output similar to the following

Generate default shared secret

Bypass Shielded Communication.

1274:Error [0x0102] : OPTIGA comms API failed

1274:Error [0x0102] : OPTIGA comms API failed
1274:Error in trustm_helper/trustm_helper.c:1250 trustm_Open: Error opening Trust M, EXIT

As shown above, an error seems to have occurred in the Opening section.
Do I need to do a Shielded Connection?
If so, please let me know how to do the Shielded Connection.

Also, my final goal is as follows

1. output DAC, PAI, etc. from Kudelski's keySTREAM
2. write the output certificate to OPTIGA TRUST M MTR
3. perform commissioning using the written certificates (DC(F1E0), DAC(E0E0), PAI(E0E8), DAC Privatekey(E0F0))

Currently, 1 has been executed and already downloaded the 7z file.
Currently, this error occurred when we are considering using Raspberrypi to write the certificate in order to implement 2.
Also, I am aware that the DC and DAC Private Keys are built into OPTIGA by default, is that correct?
In process 3, I tried to write the default DC, DAC, and
However, when I try to read the DAC Private Key, I cannot read it.
Infineon/optiga-trust-m#108

Please check the above.

[ying-css]

Hi @NNAA0917 It seems you have encountered some issues when communicating with OPTIGA™ Trust M. Could you please confirm whether the I2C interface is enabled on your Raspberry Pi? The following command: ./bin/trustm_metadata -r 0xe140 -X should work if the communication between Raspberry Pi and OPTIGA™ Trust M MTR is properly established. The -X argument ensures that shielded communication is bypassed. Enabling shielded communication is not mandatory for Matter applications.
To write DAC, PAI, and CD into the OPTIGA™ Trust M MTR, we have prepared a dedicated script available here. An example of how to use this script is as follows:
./matter_provisioning_master.sh
-b [path_to_bundle_file_3.0.7z]
-k [transport_key]
-c [path_to_certificate_declaration.bin]
-v -o
For more details, please refer to the documentation here.

For Step 3: performing commissioning using the credentials(DAC,PAI,CD, Private Key) stored inside Trust M, which platform do you prefer to use? Currently, we have a Door Lock example available here which is using Infineon PSoC6 platform.

You can perform commissioning using either a Raspberry Pi or a smartphone as the commissioner:
Apple Phone + Apple HomePod Mini
or
Android Phone + Google Nest Hub
For security reason, the private key could not be read out from OPTIGA™ Trust M MTR.

Let me know if this helps or if you have any further questions!

[NNAA0917]

Hi @ying-css
Thank you for confirming.
I reconnected and ran
./bin/trustm_metadata -r 0xe140 -X
and the following was output.

Bypass Shielded Communication.
Shared Platform Binding Secret. [0xe140]
OPTIGA execution time: 0.0140 sec.
[Size 0029] :
20 1B C0 01 07 C4 01 40 C5 01 40 D0 07 20 E1 40
FD 23 F1 D0 D1 01 FF D3 01 00 E8 01 22
LcsO:0x07, Max Size:64, Used Size:64, Change:Conf-0xE140&&Auto-0xF1D0, Read:NEV, Execute:ALW, Data Type:PTFBIND,

./matter_provisioning_master.sh is being used to write the DAC and PAI.
It seems that the CD is not provided by Kudelski's keySTREAM, but is it correct to assume that it is not necessary to write it because it was originally written to the OPTIGA TRUST M MTR?

For security reasons, the private key could not be read out from the OPTIGA™ Trust M MTR.

So, for Matter commissioning, is it correct to assume that as long as you have a DAC, PAI and CD, you will not have any problems? Is the private key not required during commissioning?

Also, the platform is stm32.

Thank you for your confirmation.

[ying-css]

Hi @NNAA0917, Yes, It seems OPTIGA™ Trust M MTR can communicate properly with RaspberryPi now.
For Matter devices, CD is mandatory and should be written during the late-stage provisioning process. For testing purpose, you can write in the test CD which is available here. Once the Matter certification is complete, the Connectivity Standards Alliance (CSA) will issue a dedicated CD for production Matter devices. Additionally, the private key is required during commissioning, but it cannot be read out. It is unique and paired with the DAC you claimed from Kudelski's keySTREAM. This makes the use of an HSM essential to ensure security for Matter devices. Let us know if you have any further questions! Thanks.

[NNAA0917]

Hi @ying-css
Thank you for checking.
At the moment, the certification process has not been completed, so there is no CD for the actual production. For this reason, we are trying to commission it using the test CD you shared with us.
In that case, what should we use for the DAC and PAI?
I have already downloaded the Test DAC by specifying the Reel ID, Vendor ID, and Product ID from Kudelski's keySTREAM. Is it not possible to test using these? (.7z file) https://if.obp.iot.kudelski.com/products/iot/workspace/test-dacs

[ying-css]

Hi @NNAA0917 In this case, you can use the DAC and PAI you claimed from Kudelski's keySTREAM along with the test CD from CSA which I just shared with you for evaluation purpose. Thanks.

[NNAA0917]

Hi @ying-css
Thank you for confirming.
I was able to write the bundle file and test CD to the OPTIGA using matter_provisioning_master.sh. (Using the transport key)
./matter_provisioning_master.sh -b [path_to_bundle_file_3.0.7z] -k '[transport_key]' -c [path_to_certificate_declaration.bin] -v -o

If I want to do commissioning, is it enough to read the CD, DAC and PAI that I wrote to from the OPTIGA and use them?
What I want to check is whether the data objects in the OPTIGA used for commissioning are only CD:F1E0, DAC:E0E0 and PAI:E0E8.

[NNAA0917]

Hi @ying-css
I have a few more questions.
I am considering using the OPTIGA TRUST M MTR on the stm32 platform. In that case, is it necessary to incorporate the following into the stm32 platform?
https://github.com/project-chip/connectedhomeip/tree/v1.4-branch/src/platform/Infineon/crypto/trustm
If you have any solutions, please let me know.

[ying-css]

Hi @ying-css Thank you for confirming. I was able to write the bundle file and test CD to the OPTIGA using matter_provisioning_master.sh. (Using the transport key) ./matter_provisioning_master.sh -b [path_to_bundle_file_3.0.7z] -k '[transport_key]' -c [path_to_certificate_declaration.bin] -v -o

If I want to do commissioning, is it enough to read the CD, DAC and PAI that I wrote to from the OPTIGA and use them? What I want to check is whether the data objects in the OPTIGA used for commissioning are only CD:F1E0, DAC:E0E0 and PAI:E0E8.

Hi @NNAA0917 The data objects in OPTIGA TRUST M MTR used for commissioning include the following:
CD:F1E0, DAC:E0E0, PAI:E0E8 and DAC Private Key:E0F0. Thanks.

[ying-css]

Hi @ying-css I have a few more questions. I am considering using the OPTIGA TRUST M MTR on the stm32 platform. In that case, is it necessary to incorporate the following into the stm32 platform? https://github.com/project-chip/connectedhomeip/tree/v1.4-branch/src/platform/Infineon/crypto/trustm If you have any solutions, please let me know.

Hi @NNAA0917 To port OPTIGA TRUST M MTR to stm32 platform, you need to implement the PAL (Platform Abstraction Layer) for stm32 platform. You can refer to the existing PAL layer for the Trust X implementation here.The PAL layer for Trust X is almost same as what is required for Trust M. Additionally, you must update some configuration files, such as BUILD.gn, args.gni and targets.py to align with your Matter application requirements. Please refer to this commit as your reference. BTW, Could you kindly let us know which development board(stm32) you are using for this integration? What is the target matter application? We can order the boards and help to integrate at our side. Thanks.

[NNAA0917]

Hi @ying-css Thank you for confirming. I was able to write the bundle file and test CD to the OPTIGA using matter_provisioning_master.sh. (Using the transport key) ./matter_provisioning_master.sh -b [path_to_bundle_file_3.0.7z] -k '[transport_key]' -c [path_to_certificate_declaration.bin] -v -o
If I want to do commissioning, is it enough to read the CD, DAC and PAI that I wrote to from the OPTIGA and use them? What I want to check is whether the data objects in the OPTIGA used for commissioning are only CD:F1E0, DAC:E0E0 and PAI:E0E8.

Hi @NNAA0917 The data objects in OPTIGA TRUST M MTR used for commissioning include the following: CD:F1E0, DAC:E0E0, PAI:E0E8 and DAC Private Key:E0F0. Thanks.

Hi @ying-css
Thank you for your confirmation.
I understand.

[NNAA0917]

Hi @ying-css I have a few more questions. I am considering using the OPTIGA TRUST M MTR on the stm32 platform. In that case, is it necessary to incorporate the following into the stm32 platform? https://github.com/project-chip/connectedhomeip/tree/v1.4-branch/src/platform/Infineon/crypto/trustm If you have any solutions, please let me know.

Hi @NNAA0917 To port OPTIGA TRUST M MTR to stm32 platform, you need to implement the PAL (Platform Abstraction Layer) for stm32 platform. You can refer to the existing PAL layer for the Trust X implementation here.The PAL layer for Trust X is almost same as what is required for Trust M. Additionally, you must update some configuration files, such as BUILD.gn, args.gni and targets.py to align with your Matter application requirements. Please refer to this commit as your reference. BTW, Could you kindly let us know which development board(stm32) you are using for this integration? What is the target matter application? We can order the boards and help to integrate at our side. Thanks.

Hi @ying-css
Thank you for your confirmation.
PAL (Platform Abstraction Layer) has already been integrated into the stm32 platform and porting has been completed. We have also succeeded in reading data by specifying the object ID of the OPTIGA TRUST M MTR using stm32 by itself. We have used the following as a reference.
https://github.com/Infineon/optiga-trust-m/tree/main/extras/pal/NEW_PAL_TEMPLATE
Also, we are using STM32WB5MMG-DK as evaluation board.
The Matter application targets WindowCovering.
We have tried commissioning with the following built into the stm32 platform,
https://github.com/project-chip/connectedhomeip/tree/master/src/platform/Infineon/crypto/trustm
Commissioning fails with the attached error.
Commissionng_Error.log

Also, https://github.com/project-chip/connectedhomeip/blob/master/src/platform/Infineon/crypto/trustm/CHIPCryptoPALHsm_P256_trustm. cpp
in the ECDH_derive_secret of
return_status = trustm_ecdh_derive_secret(OPTIGA_KEY_ID_E100, (uint8_t *) remote_key, (uint16_t) rem_pubKeyLen + 3,
out_secret.Bytes(), (uint8_t) secret_length);
but what is the value of OPTIGA_KEY_ID_E100? I am aware that there is no such Object ID. Also, it is not defined.

Please check the above.

[ying-css]

Hi @NNAA0917 Thank you for your response. It's great to hear that the PAL has been successfully integrated into stm32 platform and that you can read out the data inside OPTIGA TRUST M MTR. However, we noticed that the log you shared seems incomplete. Could you kindly provide the complete log for the commissioning process?
Regarding to ECDH implementation, we use OPTIGA_KEY_ID_E100, which is the OID of session context 1,as defined here. Thanks.

[NNAA0917]

Hi @ying-css
Thank you for confirming.
OPTIGA_KEY_ID_E100 was not defined in the PAL Tag (v3.00.2490) that I had installed.
After installing the commit (f802968) that you specified, OPTIGA_KEY_ID_E100 was recognized correctly and commissioning was completed.
There also seems to be another branch called matter_support, but is it correct to install this?

[ying-css]

Hi @NNAA0917 We're glad to hear that the commissioning is now complete. Yes, the matter_support branch is used for matter application support. For more details, please refer to this link. Feel free to reach out to us if you have any further questions or issues. Thank you!

[NNAA0917]

Hi @ying-css
Thank you for checking.
Also, thank you for sharing.

On a different topic, I have a question about writing DAC and PAI during actual mass production.
I was looking at the Infineon-Customer_presentation_OPTIGA_Trust_M_MTR-ProductPresentation, and there is one point I would like to confirm.
It says that the private key is written in Infineon's CC certified fabs, and then the PAI and DAC are written in the OEM's manufacturing facility. Does this OEM's manufacturing facility refer to our manufacturer's factory? Or does it refer to a factory affiliated with Kudelski or Infineon?
Also, do we have to download and write the DAC and PAI linked to the device ID one by one at the OEM's manufacturing facility from Kudelski IoT?
I think it would be quite a hassle, but are there any tools available to write them efficiently?

[ying-css]

Hi @NNAA0917 Yes, the OEM's manufacturing facility refers to your manufacturer's factory. Writing the unique DAC and PAI into the OPTIGA TRUST M MTR during the mass production is straightforward. You can claim the bundle file from Kudelski's keySTREAM platform, then use a shell script to automate the process. This script can read the file content, read UID(unique for every OPTIGA TRUST M MTR) from TRUST M MTR, match it and write the DAC and PAI in accordingly. For more information, Please refer to this. Thanks a lot.

[NNAA0917]

Thank you for checking.
Also, thank you for sharing the script. This script makes writing a lot easier.
Also, for example, I understand that the Private Key is written in a factory that has been certified by Infineon, but since the VID and PID are communicated at that stage, is it not possible to have the DAC and PAI written as well?

If it is only possible to write one at a time, it is my understanding that it is quite difficult because the connection between the OPTIGA and the writing jig has to be made each time.

[ying-css]

Hi @NNAA0917 Late-stage provisioning allows the PID to be modified right up until production begins, enabling OEMs to create multiple variants of their end products. This approach empowers customers to customize their products with different PAIs and DACs.
For the second question, there are multiple approaches to address this. For example, during the MCU firmware flashing stage, the PAI/DAC/CD can be written simultaneously to the MCU's flash memory and the TRUST M MTR. If you have any further questions or would like to discuss this in more detail, please feel free to provide us your contact and we can discuss further. Thank you.