ShangMi signature and asymmetric encryption algorithms (SM9)

[athoelke]

The Crypto API already has definitions for the SM3 hash algorithm and a SM4 block cipher key type. #22 proposes the addition of support for SM2, a set of elliptic curve algorithms for signature, encryption and key establishment.

CSTC also defines the SM9 suite of identity-based cryptographic (IBC) algorithms for digital signature, key encapsulation, and asymmetric encryption.

IBC is different to other forms of asymmetric algorithms, as it makes a trusted third party an explicit role in the functioning of the algorithm. In contrast, with algorithms such as ECDSA, or SM2-DSA, the association of the public key with the other party's identity involves trust relationships that are outside the scope of the algorithm definition.

In IBC, there is a Key Management Service (KMS), or some other trusted authority, that creates an maintains a paired Master Secret Key (MSK) and Master Public Key (MPK). The usual participants, Alice and Bob, make use of the MPK when encrypting data, or verifying signatures; and the other party's plain-text, public identity (e.g. email address) is also used when encrypting data or verifying signatures. To decrypt data, or create signatures, a participant must request from the KMS their personal secret key that is associated with their identity (this can be done ahead of time, or just in time), for use with the MPK. Aside from using slightly different keying material, the Sign, Verify, Encrypt and Decrypt functions used by Alice and Bob are similar to existing asymmetric APIs.

The major difference is the key generation and management:

• The KMS must Create the paired MSK and MPK, publish MPK, and protect the MSK.
• The KMS must provide a service to participants to Extract their secret key associated with the MPK and their identity string. The KMS must authenticate the participant making the request, and the participant must protect the resulting secret key.

API requirements/design

I assume that the Crypto API should support the roles of individual participants (Alice and Bob)

• Enable the import of a SM9 secret key (maybe a key pair, that combines the MPK, and the secret key)
• Enable the import of an SM9 public key (maybe just the MPK)
• Provide Sign/Verify and perhaps Encrypt/Decrypt functions, that take the key-pair or public key (as appropriate)
• The participant identity string associated with the key either needs to be part of the key, or provided as context to the algorithms

Does the Crypto API need to also support the KMS role? It would need to also:

• Provide a Create function for generating a Master key pair
• Support export-public-key of the MPK from the key pair
• Provide an Extract function for deriving a personal secret key from the Master key-pair and the identity (probably a KDF)
• Support the export of the secret key (for transfer to the participant)

References:

IETF draft: The SM9 Identity-Based Cryptographic Algorithms SM9 summary and security analysis The SM9 Cryptographic Schemes ETSI technical report: Guide to Identity-Based Cryptography

[athoelke]

A critical decision for designing this API is whether we need to support the KMS role, and the key generation and extraction functions.

[MarcusJGStreets]

I think that the KMS role should be separately optional. There would only be one KM Service, per organization - though it could be distributed for reliability.

Most devices will not need it. But if PSA crypto is used by servers, they may need it.