/dev/vcio_crypto permissions too broad

[embetrix]

Describe the bug

looking at :

https://github.com/raspberrypi/linux/blob/ac2010ab872809cefb790183949b11bdf22db647/drivers/char/broadcom/vcio.c#L72C1-L84C1

I noticed that /dev/vcio_crypto allows access to several firmware crypto operations including HMAC-SHA256, ECDSA signing, public/private key operations and key generation.

My concern is that access to /dev/vcio_crypto may still be too broad for application-level use. In particular, if GET_CRYPTO_HMAC_SHA256 can be called with arbitrary input,an application with access to this device may be able to use the firmware as a generic HMAC/key-derivation oracle.

If the same firmware-protected secret material is also used, directly or indirectly, to derive encryption keys, this could allow an application to derive sensitive key material that should remain restricted to a trusted component.

Thanks.

Steps to reproduce the behaviour

just check the code

Device (s)

Raspberry Pi CM5

System

check the code: https://github.com/raspberrypi/linux/blob/ac2010ab872809cefb790183949b11bdf22db647/drivers/char/broadcom/vcio.c#L72C1-L84C1

Logs

No response

Additional context

No response

[embetrix]

maybe seperate in two ?

/dev/vcio_crypto
/dev/vcio_crypto_hmac

the ecdsa key is protected from extraction when locked but hmac is very senstive

[pelwell]

This was already on the list of possible refinements, but implementation TBD.

[timg236]

For fine-grained access control it's more likely that we'd recommend polkit e.g. sign / verify / OTP updates / hmac

[embetrix]

Thanks for the suggestion.

For fine-grained access control polkit may make sense for higher-level operations.

In my current use case I do not need that level of policy control yet. The HMAC derivation is only used during early boot in the initramfs for filesystem decryption. After the root filesystem is mounted there are network-facing services that use a key-backed ECDSA OTP key for TLS. Those services currently need access to /dev/vcio_crypto.

The problem is that giving them access to /dev/vcio_crypto also gives them access to the HMAC derivation interface. If one of these network services is compromised, an attacker could potentially abuse the HMAC derivation path and use it to help decrypt protected data.

To address this I added a small kernel patch that splits the HMAC-SHA256 tag handling into a separate device node:

https://github.com/embetrix/meta-raspberrypi-secure/blob/wrynose/recipes-kernel/linux/linux-raspberrypi/patches/v6.18/0003-char-broadcom-vcio-split-HMAC-SHA256-tag-into-separa.patch

Would it make sense for me to submit this as a PR?

[pelwell]

If one of these network services is compromised, an attacker could potentially abuse the HMAC derivation path and use it to help decrypt protected data.

Could you explain how that works?

[embetrix]

Seeing your reference code is using :

https://github.com/raspberrypi/cryptsetup-passphrase-agent/blob/main/src/passphrase.rs

the LUKS passphrase is derived as:

HMAC-SHA256(OTP key 1, block-device ID)

and the resulting HMAC is used as the cryptsetup passphrase.

So if a compromised network service has access to /dev/vcio_crypto, it can call the same firmware HMAC operation with the block-device ID and reproduce the LUKS passphrase!

That is why I want to split the HMAC operation into a separate device node.

By the way I don't use this mechanism at all but implement it a new kernel trusted key based on rpifwcrypto:

https://github.com/embetrix/meta-raspberrypi-secure/blob/wrynose/recipes-kernel/linux/linux-raspberrypi/patches/v6.18/0001-security-keys-add-rpi-firmware-crypto-trusted-key-so.patch

still have the similar problem but at least the key blobs are avaibale only in initramfs and the encryption key is never revealed in user-space.

[timg236]

I think fragmenting the vcio node further is the wrong approach. You could just change the ownership of the node to make it more restricted.

In future versions of rpi-fw-crypto we may make the locking more fine-grained e.g. for a particular key, sign, OTP modify, hmac etc can disabled at runtime via mailbnox until a power-on-reset.

[embetrix]

Changing ownership only restricts access to /dev/vcio_crypto as a whole.

So this is not about restricting the whole node but about separating operations...

Fine-grained runtime locking would solve this nicely in the future but until I'll keep separate HMAC node with my patch that provides me the needed separation.

[timg236]

That sounds reasonable.

From a security point of view we started at 'raw OTP' and are slowly walking the system towards a 'software security' module, fine-grained locking and better memory isolation (BCM2712) are the next steps.

[embetrix]

maybe you can look at parsec : https://github.com/parallaxsecond/parsec and add rpifwcrypto as module there

[timg236]

Yeah, we looked at it and various other ones, however, I think it's likely that rpi-fw-crypto will remain a very narrow set of functionality that just does enough for PiConnect, LUKS and pair with a full featured HSM e.g.
https://www.picokeys.com/pico-hsm/

[embetrix]

looks very interesting but it requires an extra HW ?

for the rpi-fw-crypto I have already developed and open sourced a mini HSM around it:

https://github.com/embetrix/rpifwcrypto-pkcs11

It's fully usable with OpenSSL Providers and SSL/TLS using the ecdsa key:

https://github.com/embetrix/meta-raspberrypi-secure/blob/wrynose/recipes-httpd/nginx/files/default_server.site#L6
https://github.com/embetrix/meta-raspberrypi-secure/blob/wrynose/recipes-support/swupdate/files/swupdate.cfg#L28

this is why my original concerns about the permissions :-)