PKCS #11 defines a new interface for handling AEAD type ciphers that allow
multiple AEAD operations without repeating the key schedule. It also allows
tokens to keep track of the number of operations, and generate IVs (depending
on the cipher).
1. implement those new functions in softoken.
With the addition of CKF_MESSAGE_* flags to various mechanism, we need
to strip them when using the version 2 API of softoken (since there are
no C_Message* function in version 2). For that we need a separate
C_GetMechanismInfo function. We use the same trick we used to have
a separate version function for the V2 interface.
Also now that the new message functions are in their own file, they
still need access to the common Session state processing functions.
those have gone from static to exported within softoken to accomidate
that. Same with sftk_MapDecryptError() (sftk_MapVerifyError() was also
made global, though nothing else is yet using it).
Only C_MessageEncrptInit(), C_EncryptMessage(), C_MessageEncryptFinal,
C_MessageDecryptInit(), C_DecryptMessage(), and C_MessageDecryptFinal
are implemented. C_EncryptMessageBegin(), C_EncryptMessageNext(),
C_DecryptMessageBegin(), and C_DecryptMessageNext() are all
part of the multi-part withing a multi-part operation and
are only necessary for things like S/MIME (potentially). If we wanted
to implement them, we would need more functions exported from freebl
(and initaead, updateaead, finalaead for each mechanism type).
2. make those interfaces call aes_gcm and chacha20_poly1503
(and make adjustments for those ciphers).
For AES, I added a new function AES_AEAD, which handles both encrypt
and decrypt. Internally, the gcm functions (both the generic gcm and
the intel gcm wrapper) had their init functions split into key scheduling
and counter mode/tag initialization. The latter is still called from
init, but the former is now for each update call. IV generation is
handled by a single function in gcm.c, and shared with intel_gcm_wrapper.c
Since the AES functions already know about the underlying PKCS #11
mechanism parameters, the new AEAD functions also parse the PKCS #11 GCM
For Chacha/Poly new aead update functions were created called
ChaChaPoly1305_Encrypt and ChaChaChaPoly1305_Decrypt. There was no
Message specific initialization in the existing chacha_init, so no
changes were needed there. The primary difference between
_Encrypt/_Decrypt and _Seal/_Open is the fact that the tag is put at
the end of the encrypted data buffer in the latter, and in a generic
buffer in the former.
3. create new pk11wrap interfaces that also squash the api differences
between the various mechanisms for aead (similiar to the way we do it for
CBC and ECB crypto today).
To accomplish this I added PK11_AEADOp() and PK11_AEADRawOp(). Both
functions handle the case where the token only supports the single shot
interface, by using the single short interface to simulate the
Message interface. The PK11_AEADOp() also smooths out the
differences in the parameters and symantics of the various mechanism
so the application does not need to worry about the PKCS #11 differences
in the mechanism. Both use contexts from the standard
PK11_CreateContext(), so key schedules are done once for each key rather
than once for each message. MESSAGE/AEAD operations are selected by adding
the psuedo attribute flag CKA_NSS_MESSAGE to the requested operation
(CKA_ENCRYPT, CKA_DECRYPT, CKA_SIGN, CKA_VERIFY).
4. write tests for the new interfaces
Tests were added to make sure the PK11_AEADRawOp interface works,
The single shot interface is used to test output of the message interface
we also use two test only functions to force the connection to use
the simulation interface, which is also compared to the non-simulate
inteface. The AES_GCM also tests various IV generators.