OpenSSL provider implementation does not handle properly unitialized keys.

[reds71]

When using the OpenSSL CLI using public keys stored in the Trust M, when the key object has not been initialized, either the operation succeeds as if normal (RSA) or crashes with a segmentation fault (ECC). Note that all works fine when we create the key first with 0xe0f1:*:NEW:...

Knowing the 0xe0f1 and 0xe0fc OID were never initialized (I agree it may happen a limited period of time, but...), the following OpenSSL executed in a bash on a RPi3 with latest Raspcerry Pi OS and a Trust M Security Shield2GO :

$ openssl pkeyutl -provider trustm_provider -inkey 0xe0fc:^ -sign -rawin -in data.txt -out sig2.bin
Input OID E0FC
$ openssl pkeyutl -provider trustm_provider -inkey 0xe0f1:^ -sign -rawin -in data.txt -out sig2.bin
Input OID E0F1
Segmentation fault

The first should not produce a signature but an error and the second one should not crash obviously. There must miss some defensive code somewhere.

Software version:

• Branch: provider_dev
• OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)

Chip info:

$ ./bin/trustm_chipinfo 
Read Chip Info [0xE0C2]: Success.
========================================================
CIM Identifier             [bCimIdentifer]: 0xcd
Platform Identifer   [bPlatformIdentifier]: 0x16
Model Identifer         [bModelIdentifier]: 0x33
ID of ROM mask                  [wROMCode]: 0x9301
Chip Type                    [rgbChipType]: 0x00 0x1c 0x00 0x05 0x00 0x00
Batch Number              [rgbBatchNumber]: 0x0a 0x01 0x27 0x17 0x00 0x0a
X-coordinate              [wChipPositionX]: 0x0067
Y-coordinate              [wChipPositionY]: 0x0053
Firmware Identifier [dwFirmwareIdentifier]: 0x80101071
Build Number                 [rgbESWBuild]: 24 40

Chip software build: 
OPTIGA(TM) Trust M rev.3; Firmware Version: 3.00.2440
========================================================

Host:

• Raspberry Pi3 model B
• Trust M Security Shield2GO

Host OS and Version:

Linux rpi3 6.6.47+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.47-1+rpt1 (2024-09-02) armv7l GNU/Linux

Compiler:

cc (Raspbian 12.2.0-14+rpi1) 12.2.0

Thank you!

[ying-css]

Hi @reds71 We used Raspberry Pi 4 for provider_dev code development and testing and didn't see the same issue you mentioned. Let me set up the same testing environment as yours and repeat the issue. I will come back to you very soon. Thanks.

[ying-css]

Hi @reds71 We created the latest RPI OS image(Raspberry Pi OS(32-bit) which was released on 2024-07-04): Linux raspberrypi 6.6.31+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.31-1+rpt1 (2024-05-29) armv7l GNU/Linux on Raspberry Pi3. The OpenSSL version is exactly same as yours: OpenSSL 3.0.14 4 Jun 2024. Unfortunately, we could not repeat the issue you encountered. Please find the output shown as below as your reference.

When both 0xe0f1 and 0xe0fc key slots are not initialized with key:

openssl pkeyutl -provider trustm_provider -inkey 0xe0fc:^ -sign -rawin -in data.txt -out sig2.bin
Input OID E0FC
Invalid public key header. Please generate another key
Could not read private key from 0xe0fc:^
pkeyutl: Error initializing context
openssl pkeyutl -provider trustm_provider -inkey 0xe0f1:^ -sign -rawin -in data.txt -out sig2.bin
Input OID E0F1
Invalid public key. Please generate another key
Could not read private key from 0xe0f1:^
pkeyutl: Error initializing context

we could not repeat the issue for Linux raspberrypi 6.6.31+rpt-rpi-v7. After this, we run command: sudo rpi-update to update the RPI OS to the latest one to test again, the RPI OS is updated to Linux raspberrypi 6.6.51+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.51-1+rpt2 (2024-10-01) armv7l GNU/Linux and the output for these two commands are still same. Could you kindly Let us know where you get the RPI OS Linux rpi3 6.6.47+rpt-rpi-v7? by running sudo rpi-update command or other way? Which commit from provider_dev branch are you using? Could you kindly provide us more details for your testing environments? Thanks a lot.

[reds71]

Hi Ying. Thanks for trying to reproduce.

OK... Puzzling.

RPi OS
About the RPi OS, I flashed the image and upgraded less than 2 weeks ago, that explains why you have a version from 2024-10-01 and mine is still 2024-09-02. I'm upgrading right now and will try to test again. Do you have a command hint for me in order to reset the key OIDs to "uninitialized"?

linux-optiga-trust-m commit
I built commit d7e24c8f6ac3ced5224ffa3d8dab4a1050616338 (HEAD -> provider_dev, origin/provider_dev) on the RPi. Is see you pushed only readme updates since then? Is it correct or the _dev suffix is a hint for "work in progress" (because I think I saw along with trace printf()̀, some exits on error not freeing memory) ?

But on the build subject, if the RPi upgrade does not solve the issue, I wondered if you built the provider in debug mode? From my experience, it can explain sometimes why memory issues can go under the radar: in those situations it shows up when the code is build in release mode (no -g)

Thanks for your help.

[ying-css]

Hi @reds71 I also checked out from the same commit: d7e24c8f6ac3ced5224ffa3d8dab4a1050616338 as you used, the output of these two commands are still same, No segmentation fault was observed. Yes, We only pushed some updates for readme after this commit. We do have some commands to flush the key object with zero, Let me work out the script and update you tomorrow. At the same time, I will continue to try and see whether this issue can be repeated from our side. Thanks a lot.

[ying-css]

Hi @reds71 To reset the key OIDs to "uninitialized", you need to perform metadata update for the key slot. To make it easy to perform this task, you can clone our GUI tools: optiga-trust-m-explorer Follow the instruction to install it on your RPI3, then you can go to subpage Protected Update to perform Metadata Update for the Key OIDs you want to reset. Please remember if you want to flush the key, you need to select the option: Set Lcso=0x03(Init) ResetType=0x11(Wipe TargetData) before you click Step1:Provisioning for All OIDs. Please refer to the picture shown as below:

BTW, I reproduced the segmentation fault for ECC key OID when the ECC key was flushed(For RSA key OID, no segmentation fault was observed at same scenario)yesterday and will fix it soon. Thank you very much for pointing out this issue for us. We will let you know once it is fixed.

[ying-css]

Hi @reds71 We just fixed this issue by this commit Could you kindly check and let us know whether it is working at your side? Thank you very much.