PKCS11 Message Based Encryption Initialization Was: Re: [pkcs11] Groups - Slides: PKCS #11 AEAD Functions at 2014-02-28 F2F uploaded

[Michael StJohns <msj@nthpermutation.com>]

Splitting these into pieces.

On 3/28/2014 8:13 PM, Wan-Teh Chang wrote:
> Hi Mike,
>
> Thank you again for your comments on the PDF file of my proposal.
>
> On Tuesday, March 25, I revised the proposal to address some of your 
> comments. Here are my responses to your other comments.
>
>
> 3. Re: whether an association object should be explicitly marked as 
> Encrypt, Decrypt, Sign, or Verify:
>
> This issue has been discussed separately on this email thread. I 
> didn't change this aspect of the proposal.
>
> Thanks,
> Wan-Teh Chang

I haven't actually seen an analysis from you which supports your approach.

As I understand this, you're saying that we'll need 12 new functions -  
NEW_encrypt/decrypt/sign/verify_ASSOCIATION. That's assuming that there 
is one and and only one association per session.  (there are 4 message 
processing functions, and 4 close association functions in addition to 
the 4 new association functions).

An association consists of 1) a key, 2) a mechanism, 3) an optional IV 
generator.

The mechanism describes whether the association is an encrypt/decrypt or 
sign/verify pair.

The C_EncryptMessage call (after the new association call) taken with 
the association data sets up the operation context (and tears down the 
operation context).  It knows that a) its an encryption (from the call), 
b) the mechanism to use with the encryption (from the association data), 
the key to use with the encryption (from the association data), and the 
IV (from either the association data or supplied).  So there's no reason 
for the association data to know this is an encryption (vs decryption) 
as that data is implicit in which call you use to process the message.

You don't actually need individual close association messages, as you've 
already indicated there is one and only one association per session.  
(Going back to your previous email that noted there could be two 
operations pending in an session, those operations can't both be 
encryption/decryption or sign/verify - they have to be one encrypt or 
decrypt and one sign or verify under the current definition).  If you 
want to have multiple associations per session, then the new association 
call should return an association object, rather than have it implicit 
in the session.

So cleaning up your API slightly:

CK_RV C_NewAssocation (
   CK_SESSION_HANDLE hSession,
   CK_MECHANISM_PTR pMechanism,
   CK_OBJECT_HANDLE hKey,
    CK_MECHANISM_PTR pIvMechanism,
    CK_BOOLEAN bReceiver
);

CK_RV C_CloseAssocation (
   CK_SESSION_HANDLE hSession
);

Where bReceiver is CK_TRUE if this is a decrypt or verify association, 
false if it is an encrypt or sign association.  (Not really necessary 
with your use of processing specific functions such as C_EncryptMessage, 
but tired of arguing).



If you really wanted to do this in a very compact way you could do:


CK_RV C_NewAssociation (
    CK_SESSION_HANDLE hSession,
    CK_MECHANISM_PTR pMechanism,
    CK_OBJECT_HANDLE hKey,
    CK_MECHANISM_PTR pIvMechanism,
    CK_BOOLEAN bReceiver
);   The mechanism indicates encrypt/decrypt vs sign/verify, and the 
bReceiver indicates encrypt vs decrypt or sign vs verify.

CK_RV C_ProcessMessage (
    CK_SESSION_HANDLE hSession,
    CK_BYTE_PTR pInData,
    CK_ULONG ulInDataLength,
    CK_BYTE_PTR pInAssocatedData,
    CK_ULONG ulInAssociatedDateLen,
    CK_BYTE_PTR pOutData,
    CK_ULONG_PTR ulOutDataLen,
    CK_BYTE_PTR pIntegrityTag,
    CK_ULONG_PTR ulIntegrityTagLen,
    CK_BYTE_PTR pIv,
    CK_ULONG_PTR pIvLength,
    CK_BOOLEAN bFirstSegment,
    CK_BOOLEAN bLastSegment
);

The association data indicates sign/verify/encrypt/decrypt.


Call it 3 new API calls.

The above has the benefit that it's pretty easy to define macros for the 
subcases that you're actually using:

#define C_ProcessSignMessage (sessionHandle, data, dataLen, 
tagOutputPtr, tagOutputLenPtr) \
C_ProcessMessage ( \
    sessionHandle, \
    CK_NULL, 0, \
    data, dataLen, \
    CK_NULL, CK_NULL, \
    tagOutputPtr, tagOutputLenPtr, \
    CK_NULL, CK_NULL, \
    CK_TRUE, CK_TRUE \
);



Later, Mike