CLEVIS-ENCRYPT-PKC(1)

πŸ’– CLEVIS-ENCRYPT-PKC(1) πŸ’–

okay bestie, pull up a chair, we're doing clevis-encrypt-pkcs11 today and honestly? it's giving hardware-key-girlie ✨ this is the clevis-encrypt-pkcs11 manual page, and I'm about to make PKCS#11 make sense, no cap 🫢


✨ NAME ✨

clevis-encrypt-pkcs11 β€” encrypts using a PKCS#11 device πŸ”πŸ¦‹


✨ SYNOPSIS ✨

clevis encrypt pkcs11 CONFIG < PT > JWE

🌸 OVERVIEW 🌸

so the clevis encrypt pkcs11 command encrypts stuff using a PKCS#11 device. its only argument is the JSON configuration object. simple. elegant. iconic. πŸ’…

when you use this pin, we make a brand new random key, and that key gets encrypted using the PKCS#11 chip. then at decryption time, that key gets decrypted again using the PKCS#11 chip β€” normally by handing over a PIN (Personal Identity Number) at boot time. main character behavior, honestly. πŸ‘‘

your configuration object MUST have the uri JSON key, and the JSON value attached to that uri key has to start with the word pkcs11::

$ clevis encrypt pkcs11 '{"uri":"pkcs11:"}' < PT > JWE

now, as an alternative, you can store the PIN at configuration time. but bestie… for security reasons, this is NOT recommended. 🚨 like, I'm telling you this because you're my friend, not because I want you to do it. but if you absolutely still need it, it goes through the pin-value parameter:

$ clevis encrypt pkcs11 '{"uri":"pkcs11:?pin-value=123456"}' < PT > JWE

and if you need to hand over a module library? that's a thing too β€” it goes through the URI module-path parameter:

$ clevis encrypt pkcs11 '{"uri":"pkcs11:module-path=/usr/lib64/libykcs11.so"}' < PT > JWE

Clevis sits on top of OpenSC to bring you the PKCS#11 functionality. OpenSC β€” and pkcs11-tool specifically β€” gives you an option to say which mechanism to use for decryption. and here's the tea β˜•: for testing purposes, some libraries (looking at you, SoftHSM 😭) don't play nice with the default pkcs11-tool mechanism, so you have to name a specific mechanism for them to work at all. that's exactly why Clevis lets you provide the mechanism yourself, in case the default one β€” RSA-PKCS-OAEP β€” isn't valid:

$ clevis luks bind -d /dev/sda1 pkcs11 '{"uri": "pkcs11:", "mechanism":"RSA-PKCS"}'

to decrypt the data, you literally just hand over the ciphertext (JWE):

$ clevis decrypt < JWE > PT

and quick note: like the other pins, no configuration is used for decryption 🫢 that's because clevis stores the public and private keys needed to unseal the encrypted object inside the JWE itself, so clevis can just fetch that info straight from there. it remembers so you don't have to πŸ’–βœ¨


πŸŽ€ CONFIG πŸŽ€

this command uses these configuration properties:

  • uri (string) β€” the PKCS#11 URI to use. (REQUIRED) ⭐
  • mechanism (string) β€” the mechanism to use when working with pkcs11-tool. it has to be supported by pkcs11-tool. examples of supported mechanisms are:
    • RSA-PKCS-OAEP (the default one)
    • RSA-PKCS

for the complete list of supported mechanisms, run this next command:

$ pkcs11-tool -M
heads up bestie πŸ’€ β€” that previous command will show you whether the mechanism allows encryption/decryption, and that capability is required for the PKCS#11 Clevis pin to work appropriately. no encryption/decryption on the mechanism = no vibe. periodt.

🌈 SEE ALSO 🌈


and that's the whole page, my love πŸ§šπŸ’œ you ate that. go forth and encrypt.

source/version: CLEVIS-ENCRYPT-PKC(1) β€” dated 10/16/2026 πŸ“βœ¨ mwah, bye bestie! πŸ’…πŸ’–

πŸ“¦ where this page comes from