Best practices for managing composite keys on HSMs/smartcards

[SimonMontoya123]

Hello everyone,

I am opening this discussion to talk about best practices regarding composite keys on hardware security modules / smartcards.
From my understanding of the LAMPS drafts on this topic (for example, https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/), composite keys must be used as a single key. None of the individual parts must be used independently.

This raises the question of when exactly the composite key should be split to call the algorithms.
Let's assume we have a composite key: private_key_composite := (private_key_algo_A, private_key_algo_B).
For example, to perform a signature, we will need to call the signature algorithm A using private_key_algo_A and the signature algorithm B using private_key_algo_B.
From my perspective, there are two possible approaches:

• At the crypto library / HSM level. One crypto call is made using the composite key and the crypto library will split the key.

• At the application level, where crypto calls are made separately with private_key_algo_A and private_key_algo_B

Splitting at the crypto library / HSM level

In this case, the application calls a composite algorithm directly using private_key_composite, and it's the cryptographic library's job to manage the process.
From my point of view, this is the most secure solution, as cryptographic management is left to dedicated crypto implementations.
However, this requires crypto libraries and HSMs to support composite algorithms. When looking at the pkcs11 v3.2 draft, it does not seem composite mechanisms will be included.

Splitting at the application level

This approach enables the use of composite algorithms even if crypto libraries or HSMs do not support them. From an application standpoint, this means making two separate cryptographic calls: one using private_key_algo_A and another using private_key_algo_B.
The disadvantage is the increased risk of key misuse. The application layer might be managed by individuals with less expertise in cryptography, leading to potential security issues.

I would like to hear your thoughts on this topic and if you have already made implementation choices.
What recommendations would you make? Which approach would you choose?

[primetomas]

Some personal thoughts which is not claimed to be any official view of the PKIC.

Initially I'd foresee option 2 when it comes to crypto calls, i.e. there will be one call for algoA and one for algoB. My estimate from this comes from looking at crypto APIs.
Higher level APIs is adding KEMs, but I haven't seen composites in the roadmap, for example Java added KEMs in Java 21. Libraries such as Bouncy Castle of course adds classes for it, but there are no standard lower level calls for it.
PKCS#11, still the most used, and the only standardized, API for talking to cryptographic tokens (HSMs and smartcards) is adding KEMs and other PQ algorithms in PKCS#11 v3.2, but there is nothing there for composites as far as I know.

Without standard APIs it will only be possible to make composite calls with vendor specific methods, which while possible I don't think it will be widely deployed.

[SimonMontoya123]

Hello,

Thank you for your feedback.

I attended yesterday's meeting, and here are the key points I noted:

• For now, from a hardware perspective, composite key management has not been resolved.

• The hardware world is moving slower than the software world.

• The composite paradigm will require a complete redesign of key management at the hardware level.

• NIST has moved up the transition to PQC to 2028, which is a short timeline to have ready hardware (about two years for FIPS certification).

• The PQC working group will discuss this topic again.

Please feel free to add or correct anything.

After yesterday’s meeting, I had the following thought:
It seems complex (but not impossible), in terms of time, to have hardware/smartcards that support composite mechanisms. However, thinking about the management of composite key and the development of APIs could be useful for future transitions. We can easily imagine that several transitions will be necessary to obtain robust and efficient post-quantum algorithms. I think that moving forward on this topic could be useful, at least, for future transitions.

[bruno-couillard]

Not trying to "muddy" the water further, but I'm curious about some further refinements. However, before I ask that question, I'd like to make sure that my understanding of the current nomenclature surrounding digital signature is correct.

If I understand correctly, the current nomenclature surrounding the digital signature construct is as follows:

1- HYBRID Signatures are techniques that employ 2 or more digital signatures algorithms to achieve a digital signature and verification service. The digital signature algorithms used in the HYBRID Signature technique may be classic or PQC. HYBRID Signature techniques further divide into two sub variants as follows:

2- COMPOSITE Signatures are a form of HYBRID Signatures where 2 or more digital signatures are applied in "parallel" and must both be verified in "parallel" in order to achieve digital signature and verification processes;

3- CATALYST or CHAMELEON Signatures are a form of HYBRID Signatures where 2 or more digital signatures are applied "sequentially" in order to achieve a digital signature. The verification process however is performed in steps where signature layers are verified in sequence. The verifier in this case does not have to fully unravel all the signature layers if it is not capable of performing the algorithm employed in the inner signature layers, and may therefore achieve its verification process by verifying only a subset of the layered signatures.

I'm not describing the existing "PURE Signature", but perhaps it should be added to ensure a complete definition list.

Is the above nomenclature correct?

[SimonMontoya123]

Yes, I agree with your definitions

[ounsworth]

Hi,
I am an author of the Composite algorithms specification.
I think this discussion correctly captures the situation: it would be more secure if HSMs supported the composite algorithms directly because, exactly as you say, this lowers the risk of key misuse. However I agree that I don't see any evidence that hardware vendors will support this any time soon, so application layer split is the only option.

Also, you say: "NIST has moved up the transition to PQC to 2028". NIST IR 8547 ipd still says "Deprecated after 2030, Disallowed after 2035". Changing from 2035 to 2028 is big news! Where was that announced?

[SimonMontoya123]

Hi,
Thanks for your feedback.

Concerning the transition update from NIST, I've only summarised the discussions at the PQC meeting. You can find this information in the minutes. For the next PQC meeting, someone will try to confirm this information. I haven't been able to find anything on my own about this information. Let's wait and see.

[philippnagel]

@SimonMontoya123 are you aware of any confirmation thus far?

[SimonMontoya123]

No, I haven't had any confirmation. To be honest, I'm a bit sceptical about a potential change of timeline. In the NIST talk at PQCrypto, during the Q&A part, the presenter said "timeline has not been changed".