Skip to content
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

Add PIV smart card keyfile encryption #1451

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

the-dan
Copy link

@the-dan the-dan commented Dec 3, 2024

Add an option to create a keyfile which is encrypted using a smart card's private key (e.g. YubiKey)

Comment on lines +206 to +209
<entry lang="en" key="IDM_REVEAL_REDKEY">Reveal Red Key...</entry>
<entry lang="en" key="REVEAL_REDKEY_INFO">This will produce decrypted keyfile which can be used without using the smart card, thus reducing security to two factors. This keyfile should be stored securely. Are you sure to continue?</entry>
<entry lang="en" key="REVEAL_REDKEY_DONE">Red key is saved</entry>
<entry lang="en" key="REVEAL_REDKEY_PATH">Choose file to save red key to</entry>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addition of new entries must always be done at the bottom of the XML file to preserve position of existing entries.

Comment on lines +374 to +379
<entry lang="en" key="IDC_SECURITY_TOKEN_KEY">Security token key</entry>
<entry lang="en" key="IDT_SECURITY_TOKENS">Security Tokens...</entry>
<entry lang="en" key="TOKEN_SLOT_ID">Slot ID</entry>
<entry lang="en" key="SELECT_TOKEN_KEYS">Select token keys</entry>
<entry lang="en" key="TOKEN_NAME">Token name</entry>
<entry lang="en" key="TOKEN_KEY_LABEL">Key label</entry>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above: new entries should be added at the bottom.

Comment on lines +266 to +275
if (privateAttrib.size() == sizeof (CK_BBOOL) && *(CK_BBOOL *) &privateAttrib.front() != CK_TRUE)
continue;

GetObjectAttribute (slotId, dataHandle, CKA_MODULUS_BITS, privateAttrib);
if (privateAttrib.size() == sizeof (CK_ULONG)) {
CK_ULONG modulus = *(CK_ULONG *) &privateAttrib.front();
key.maxDecryptBufferSize = modulus / 8 - 11;
key.maxEncryptBufferSize = modulus / 8;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic will fail for cards that contain ECC keys. Since the current implementation supports only RSA keys, the code should use CKA_KEY_TYPE to restrict logic to RSA keys only (CKK_RSA)

Comment on lines +358 to +364
GetObjectAttribute (slotId, dataHandle, CKA_MODULUS_BITS, publicAttrib);
if (publicAttrib.size() == sizeof (CK_ULONG)) {
CK_ULONG modulus = *(CK_ULONG *) &publicAttrib.front();
key.maxDecryptBufferSize = modulus / 8 - 11;
key.maxEncryptBufferSize = modulus / 8;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above: the code should restrict logic to RSA keys only.

Comment on lines +643 to +644
CK_MECHANISM m = { CKM_RSA_PKCS, 0, 0 };
CK_RV status = Pkcs11Functions->C_EncryptInit (Sessions[slotId].Handle, &m, tokenObject);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not use CKM_RSA_PKCS since it is insecure. We must use CKM_RSA_PKCS_OAEP with SHA256 MGF.

Comment on lines +671 to +672
CK_MECHANISM m = { CKM_RSA_PKCS, 0, 0 };
CK_RV status = Pkcs11Functions->C_DecryptInit (Sessions[slotId].Handle, &m, tokenObject);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Like above, we should not use CKM_RSA_PKCS since it is insecure. We must use CKM_RSA_PKCS_OAEP with SHA256 MGF.

@idrassi
Copy link
Member

idrassi commented Dec 8, 2024

@the-dan Thank you for this contribution.
Native support for PKI smart cards has always been planned but I personally never found the time to work on it. Your approach strikes a good balance between native support and the keyfiles mechanism, making it a strong first step.

I will need some time to review the code changes because there are so many...this is the largest PR I have ever had to review.

That being said, I have already provided some comments and will add more as I progress with the review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants