-
Notifications
You must be signed in to change notification settings - Fork 21
Changes for Yubikey #149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes for Yubikey #149
Conversation
derivePublicKey() will generate the key for both PEM and PKCS11 get_signing_directives() is removed and ifs are placed where openssl call is made. This is because get_signing_directives was returning string that was incorrectly processed by the openssl command (single parameter rather than multiple parameters). There is likely a way to fix the get_signing_directives and avoid repeating the code but my bash skills are too limited to do it unfortunately. This version of the file was tested with Raspberry Pi 4 used as host (running standard PI OS 64 bit image) and it provisioned CM4 module correctly with the private key stored in the Yubikey 5. One thing that is worth noting is to store the key outside of the 9c slot (I have used 9a) to avoid script getting prompted for pin.
Thanks for the submission, @krygas-crane While I note that your approach is functional for PKCS11 use, I'm confused as to how this failed to work for your PKCS11 case when the same strategy was used for passing an argument combination for the PEM file case. If you observed a failure in the PKCS11 case, I would have expected to see reports of the PEM file path also failing. I think there's a value in digging in to why the PKCS11 name was getting mangled on the way down - but there are other changes in this PR that have separate value (most notably, removing assumptions on using the PEM files). As such, while I'm not currently inclined to accept the patch as-is, I will certainly use the suggestion to inform the 2.0 branch work. |
Thanks @tdewey-rpi . I am certainly going to be happy if any of this work will end up being useful for the future releases and that was my goal behind this PR. Considering my lack of bash skills, I was definitely not expecting this to just be accepted as is. Regarding the PKCS11 handling, I was also confused why get_signing_directives() seems to work just fine for PEM and fail for the PKCS11. I have tried various combinations of things to see if what gets returned will be parsed by the openssl command correctly but could not find anything that worked. I was thinking the issue could be due to the quotes needed for the PKCS11 string (not present in the PEM path) but I am not sure if this is the root cause or something else. I still have my setup available to be plugged in when needed so if there are additional experiments / logs that could be useful for you on this one then please let me know and I'll try to collect some. |
Circling back around to this - did you try URL encoding the spaces, and not using double-quotes? Eg, replace each space with %20 -Additionally, I'm not sure you want to be using your authentication key for this. Fundamentally, the key is being used to sign binary objects - so I'd recommend using the PIV Digital Signature key.- Edit: Re-read your initial, and I understand why you're using 9a over 9c. |
Following the advise given earlier, I've modified my config file and restored the get_signing_directives(). With the modified config, everything appears to be working now and the image was loaded correctly. The config used: CUSTOMER_KEY_FILE_PEM= CUSTOMER_KEY_PKCS11_NAME='pkcs11:object=PIV%20AUTH%20key;type=private;pin-value=123456' GOLD_MASTER_OS_FILE=/media/kamil/sandisk/bookworm_2025_02_03.img/myimg.img RPI_DEVICE_STORAGE_TYPE=emmc RPI_DEVICE_STORAGE_CIPHER=xchacha12,aes-adiantum-plain64 RPI_DEVICE_FAMILY=4 RPI_DEVICE_BOOTLOADER_CONFIG_FILE=/home/kamil/Desktop/config_cm4_bookworm.txt RPI_DEVICE_LOCK_JTAG=1 RPI_DEVICE_EEPROM_WP_SET= RPI_DEVICE_FETCH_METADATA=1 RPI_DEVICE_RETRIEVE_KEYPAIR=/home/kamil/Desktop/keys DEMO_MODE_ONLY= RPI_SB_WORKDIR= RPI_SB_PROVISONER_MANUFACTURING_DB=/home/kamil/Desktop/provisioning-db.db
Thanks for your suggestions @tdewey-rpi . I've restored the get_signing_directives() (leaving my public key changes in place) and used the following config: CUSTOMER_KEY_FILE_PEM= With this setup, everything has worked correctly and the CM4 was provisioned without any errors. |
derivePublicKey() will generate the key for both PEM and PKCS11
get_signing_directives() is removed and ifs are placed where openssl call is made. This is because get_signing_directives was returning string that was incorrectly processed by the openssl command (single parameter rather than multiple parameters). There is likely a way to fix the get_signing_directives and avoid repeating the code but my bash skills are too limited to do it unfortunately.
This version of the file was tested with Raspberry Pi 4 used as host (running standard PI OS 64 bit image, OpenSSL 3.0.15) and it provisioned CM4 module correctly with the signing key stored in the Yubikey 5. One thing that is worth noting is to store the key outside of the 9c slot (I have used 9a) to avoid script getting prompted for pin.
Example config that has worked for me:
CUSTOMER_KEY_FILE_PEM=
CUSTOMER_KEY_PKCS11_NAME="pkcs11:object=PIV AUTH key;type=private;pin-value=123456"
GOLD_MASTER_OS_FILE=/media/kamil/sandisk/bookworm_2025_02_03.img/myimg.img
RPI_DEVICE_STORAGE_TYPE=emmc
RPI_DEVICE_STORAGE_CIPHER=xchacha12,aes-adiantum-plain64
RPI_DEVICE_FAMILY=4
RPI_DEVICE_BOOTLOADER_CONFIG_FILE=/home/kamil/Desktop/config_cm4_bookworm.txt
RPI_DEVICE_LOCK_JTAG=1
RPI_DEVICE_EEPROM_WP_SET=
RPI_DEVICE_FETCH_METADATA=1
RPI_DEVICE_RETRIEVE_KEYPAIR=/home/kamil/Desktop/keys
DEMO_MODE_ONLY=
RPI_SB_WORKDIR=
RPI_SB_PROVISONER_MANUFACTURING_DB=/home/kamil/Desktop/provisioning-db.db