Plans for support of MLDSA

[kingcdavid]

Are there any plans to support Post Quantum Safe Algo's like MLDSA in SoftHSM?

[reznik99]

Hi there,
As far as I am aware, no finalized PQC algorithms have been officially standardized into the PKCS#11 specification yet.
So I don't think SoftHSM developers will be working on this yet, unless they are doing some work with vendor specifc extensions like Thales is.

[dengert]

no finalized PQC algorithms have been officially standardized into the PKCS#11 specification yet.

Not official yet, but a place to start:
https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.2/pkcs11-spec-v3.2.html
https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.2/csd01/include/pkcs11-v3.2/pkcs11t.h

[kingcdavid]

Just out of wondering, as OpenSSL now supports ML-DSA natively since 3.5, (and Botan since 3.6) would that mean SoftHSM would then require have to increase the dependency to these versions, or could it be done with some build options?

I assume the other work to be done would be to re-fork the pkca11.h from oasis and then reference it?

Do we know when pkcs11 v3.2 would be finalized, (apologies if i'm asking this in the wrong place!)

[dengert]

Do we know when pkcs11 v3.2 would be finalized, (apologies if i'm asking this in the wrong place!)

No we do not know. https://www.oasis-open.org/ Oasis committees are open. You could consider joining but requires a substantial fee.

Also look at https://github.com/oasis-tcs/pkcs11 with updates to the header files last month, and other info I have not looked at.

Note that two of the Oasis-TCS are from RedHat. One also works on https://github.com/latchset/pkcs11-provider and OpenSC has a number of developers from RedHat. (I am an OpenSC developer.) So would suspect that once the PKCS11 is out of draft, latchset would add support to its OpenSSL provider to use any PKC11 module to use PQC. And once there is some PKCS11 "smart card' or emulator like SoftHSM2 that provides a PQC pkcs11 module, OpenSC would update to support that "smart card".

[kingcdavid]

Thanks very much @dengert!

Yes i saw the updates to the header file here, but of i assume that needs to be merged back to main/master before anyone should really use it

Looks like latchset already have an open issue for it as well
latchset/pkcs11-provider#558
but again are waiting on the finalization the 3.2 PKCS11 standard

Sounds like we are probably 6 months + away from getting into a version of SoftHSM though

Really appreciate the time to answer my questions!

[antoinelochet]

I have made such developments.
You can check antoinelochet#4 for ML-DSA.
I have also implemented ML-KEM here: antoinelochet#5

Obviously, these branches require OpenSSL 3.5 and are based on tweaked version on the PKCS#11 3.2 draft headers.

These have been tested against BouncyCastle and a real HSM.

[kingcdavid]

Ah fantastic, will try to test it out, any hints on the best way to use it? were you building the pkcs11 library then using it from some code? or was there any pre-built tools you used?

[antoinelochet]

Our main use is to test a Java application which use IAIK as PKCS#11 provider.
We had to fork and modify IAIK too.
Our application connects to various HSMs and we use SoftHSM as our dev+testing standard.

[kingcdavid]

Ahh OK, makes sense

I'm trying to get it to work in golang, can you give me an example of the pkcs11 attributes you use to generate a ML DSA 65 key

my current implementation is here
https://github.com/kingcdavid/pkcs11-mldsa
So it builds your fork in a docker container, then uses a fork of https://github.com/miekg/pkcs11 with has the new MLDSA types within it

I think i need to add a new Param type here:
https://github.com/kingcdavid/pkcs11/blob/9078ad6b9d4b17a548e56959b10e8949afab10ec/types.go#L264

but hoping you could point me in the right direction!

[antoinelochet]

You need to have the attribute CKA_PARAMETER_SET with the value '2' in the public/private key template. CKA_PARAMETER_SET is a CK_ULONG.
No need for mechanism parameter.
'1' is ML-DSA-44, '2' is ML-DSA-65 and '3' is ML-DSA-87.

[kingcdavid]

That did the job for me, it will now generate a MLDSA keypair

Thanks very much, i assume we would only be able to review that as a PR after the PKCS11 3.2 spec is finalized

if there is any other specific testing i can help with, i'm happy to help

[antoinelochet]

Wow, thanks for your input !
I need to rebase that branch to develop instead of my fork branch first and add a working CI.
Then I will do the PR.

[antoinelochet]

Draft of the PR is here : #809

[hbjcr]

I have made such developments. You can check antoinelochet#4 for ML-DSA. I have also implemented ML-KEM here: antoinelochet#5

Obviously, these branches require OpenSSL 3.5 and are based on tweaked version on the PKCS#11 3.2 draft headers.

These have been tested against BouncyCastle and a real HSM.

Thank you for your repository. I was able to successfully compile the code and can confirm that the new mechanisms are listed with their corresponding hexadecimal values:

mechtype-0x1D, keySize={2560,4896}, sign, verify
mechtype-0x1C, keySize={2560,4896}, generate_key_pair
mechtype-0x1054, keySize={512,16384}, wrap, unwrap

I am running into an issue when trying to create a new key. I have tried several approaches, including pkcs11-tool, p11tool, and the PyKCS11 library, but have not had any luck. I would be grateful if you could share a working command example to help guide my efforts.

[antoinelochet]

The "real" PR is here: #809

I have tried pkcs11-tool and it does not support ML-DSA yet.

You can look into the PR unit test for the keypairgen example: https://github.com/softhsm/SoftHSMv2/pull/809/files#diff-8a391f0956e5ba5b19a928f92dbb98cfcecf6949cda166210e1ac04e3dd7dbea
I think your best shot is to use PyKCS11 if you can extend what is supported.
What you must do is use CKM_ML_DSA_KEY_PAIR_GEN (0x1cUL) as key pair gen mechanim and CKA_PARAMETER_SET (0x61dUL) in the templates. CKA_PARAMETER_SET can be valued to 1, 2 or 3 or use CKP_ML_DSA_44, CKP_ML_DSA_65 and CKP_ML_DSA_87.
This is the bare minimum to generate a key.