Stuck on digitally signing using digital signature from YubiKey

[outofthisworld]

I'm currently working with a digital certificate stored on a YubiKey HSM. However I was wondering if anyone had guidance if its possible to use this library to take the output from this function, and attach then sign a PDF.

I had a look through the current signers, but don't think there was one that fit my use case.

Example YubiKey code which produces a signature:

from ykman import connect_to_device
from yubikit.core.smartcard import SmartCardConnection
  
from yubikit.piv import (
        PivSession,
        SLOT,
        ALGORITHM,
)
conn, dev, devInfo = connect_to_device(DEVICE_SERIAL_NUMBER, [SmartCardConnection])
session = PivSession(conn)
  
#signature 
signature = session.sign(
        SLOT.Signature, #Slot 9c, where the certificate is stored (but not retrievable)
        KEY_TYPE.ECCP384, #RSA OR EC
        message, #[pdf bytes]
        ALGORITHM.SHA512
        #padding: Optional[AsymmetricPadding] = None,
)

Additionally.. the YubiKey package has the possibility of signing bytes using ECDSA

def generate_pdf_signature(session):
    """ Generates signature for pdf """
    # Retrieve the assymetric key...
    key = get_digital_cert_assym_key(session)
    #read in the pdf byes
    pdf_bytes = retrieve_pdf_bytes()
    #sign the pdf byes
    return key.sign_ecdsa(pdf_bytes) 

Would it be possible to take the output of one of these functions and then use this library to attach to PDF?

[MatthiasValvekens]

Hi @outofthisworld, thanks for your question.

Short answer: yes, you can use a YubiKey to sign PDFs with pyHanko.

I own a YubiKey, but I've only ever used the PIV module to sign PDFs through the generic PKCS#11 API (ykcs11), not the dedicated PIV API provided by Yubico. Do note that the PIV module needs more than just a key; for document signing, the slot has to have a certificate loaded into it as well.

So you can do either of two things:

• Use the existing PKCS#11 API together with Yubico's ykcs11 module. You can also get some inspiration from the tests.
• Extend Signer to provide your own signing logic using Yubico's PIV API, which is what you appear to be using in your question. This doesn't require writing any PDF-specific code yourself. The documentation provides a good starting point.

You're better off letting PyHanko handle the PDF wrangling during & after the signing process; it's more complicated than just "attaching" a pregenerated signature.

If you decide to go with the second method: I'd be open to PRs implementing such a YubiKey signer, either as part of the library or as an example for the advanced examples page. If I find the time, I might even do it myself :).

[outofthisworld]

Thanks @MatthiasValvekens really appreciate your help on this. I believe I'm going to go with trying to roll a custom signer, and if it gets there more than happy to share it for the docs if you don't get around to making a better one!

So iv'e discovered this can be a little bit of a nightmare if you don't have much of a crypto/pdf format background!
If you have the time, I have a few more questions - to ensure I'm going in the right direction :)

1. Given that the output of sign from the YubiKey package returns a sha_512 hash of the ecsda output

        self.yubi_key_session.sign(
            SLOT.SIGNATURE,
            KEY_TYPE.ECCP384,
            data,
            hashes.SHA512
        )

When specifying md_algorithm to signers.PdfSignatureMetadata would `sha512_ecdsa' be the correct choice?

2. how would I go about determining the correct amount of bytes assign during a dry run?

3. Would returning the output of YubiKey sign method be appropriate within the context of async_sign_raw, or does additional formatting/transforming have to happen?

I don't currently have the YubiKey on me so I can't test what I have written, so your response will be super useful :)

Thanks!

[MatthiasValvekens]

Hi Dale, (Replying on mobile, sorry if this message sounds a little curt.) 1. What that means is that the YubiKey signs a SHA-512 hash of the input data, but sha512_ecdsa is correct in that case. For ECCP384, SHA-384 is the more orthodox choice, though. You don’t gain anything by using a longer hash. 2. For ECDSA that’s actually a tricky one, since in the traditional ECDSA signature serialisation format the output length is not constant. That’s not a big deal though, pyHanko overestimates generously. If you put in something like 256 bytes as an estimate, you should be more than covered. There are more sophisticated ways to do it, but that’ll work. 3. Probably, you can use the output as-is, but I’d have to check the YK API docs to say for sure. If you don’t mind me asking, are you using a YubiKey 4 or a YubiKey 5?

…

On Sun, 10 Jul 2022 at 14:06, Dale ***@***.***> wrote: Thanks @MatthiasValvekens <https://github.com/MatthiasValvekens> really appreciate your help on this. Little bit of a nightmare if you don't have much of a crypto/pdf format background! I do have a couple more questions regarding this if you have the time, just to make sure I'm going in the right direction... 1. Given that the output of sign from the YubiKey package returns a sha_512 hash of the ecsda output self.yubi_key_session.sign( SLOT.SIGNATURE, KEY_TYPE.ECCP384, data, hashes.SHA512 ) When specifying md_algorithm to signers.PdfSignatureMetadata would `sha512_ecdsa' be the correct choice? 1. how would I go about determining the correct amount of bytes assign during a dry run? 2. Would returning the output of YubiKey sign method be appropriate within the context of async_sign_raw, or does additional formatting/transforming have to happen? I don't currently have the YubiKey on me so I can't test what I have written, so just wanted to get some clarification on these things :) Thanks! — Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABREJH3QD76KZP3OXHKW5T3VTK4C3ANCNFSM53CJS2LA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>