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 CKM_EXTRACT_KEY_FROM_KEY mechanism #128

Conversation

fuzzykat
Copy link
Contributor

Added support for CKM_EXTRACT_KEY_FROM_KEY mechanism as per PKCS#11 3.0 specification (see section 2.43.7).

SoftHSM does not support the mechanism unfortunately.

def __init__(self, extractParams):
"""
:param extractParams: the number of a bit in the original key, which will
be used as the first bit of the newly-derived key
Copy link
Owner

Choose a reason for hiding this comment

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

If I understand correctly the parameter is the number of bit that will be skipped (NOT used) from the original key.

From the oasis documentation: "We will derive a 2-byte secret key from this key, starting at bit position 21 (i.e., the value of the parameter to the CKM_EXTRACT_KEY_FROM_KEY mechanism is 21)."

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are correct if we start to count bits from 1. However, the example from oasis counts bits starting from 0 (and so did I):

We regard this binary string as holding the 32 bits of the key, labeled as b0, b1, …, b31

Besides, the oasis documentation defines the parameter as the number of the first bit to be included in the derived key:

This mechanism has a parameter, a CK_EXTRACT_PARAMS, which specifies which bit of the original key should be used as the first bit of the newly-derived key.

From what I see, this implies that bits are meant to be numbered starting from 0.

Nevertheless, I agree that this might me confusing, I will add a comment to clarify the bits numeration.

Copy link
Owner

Choose a reason for hiding this comment

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

OK, I misunderstood the comment.
I propose to use: "the index of the first bit of the original key to be used in the newly-derived key. For example if extractParams=5 then the 5 first bits are skipped and not used."
No need to add the "note" any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I'm fine with it. I changed the comment to what you propose.

@fuzzykat fuzzykat force-pushed the feature/ckm_extract_key_from_key branch from af2d414 to 275f87d Compare January 18, 2025 18:27
@coveralls
Copy link

coveralls commented Jan 18, 2025

Coverage Status

coverage: 86.686% (-0.5%) from 87.2%
when pulling 10903b7 on fuzzykat:feature/ckm_extract_key_from_key
into 6674d1e on LudovicRousseau:master.

@fuzzykat fuzzykat force-pushed the feature/ckm_extract_key_from_key branch from 275f87d to 10903b7 Compare January 19, 2025 08:20
@LudovicRousseau
Copy link
Owner

What PKSC#11 library have you used to test the code?

@LudovicRousseau LudovicRousseau merged commit 059aca2 into LudovicRousseau:master Jan 19, 2025
14 of 16 checks passed
@fuzzykat
Copy link
Contributor Author

What PKSC#11 library have you used to test the code?

I tested it with a proprietary software HSM library used internally in the company I work for. If you're looking for something open source to test this - there is libsoftokn3.so from Mozilla NSS libraries which might work. It seems like it supports the mechanism from what I see here. I've not tried it though.

@fuzzykat fuzzykat deleted the feature/ckm_extract_key_from_key branch January 19, 2025 17:17
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.

3 participants