RE: creating kek messages

["Colestock, Robert" <Robert.Colestock@xxxxxxxxxxxxxx>]

Gavin:

#############################
> How do I go about creating an asn.1 dump of a blob ?

Sorry, I assumed you had your own tools for this.  The "report_tool"
utility in smp/SMIME/testutil/report_tool can decode EnvelopedData, etc.
(quite versatile, also handles MIME), in the SFL test utilities source.
I am not sure it was tested before delivery on R2.2; let me know if it
fails to build.


#############################
>The content encryption algorithim should be the same as the
>key encryption algo ? ...

Yes, but you would not be following the CMS RFC3369 specification for
such an issue.


#############################
> doesn't actually run the SMTI methods from the sm_ibeDLL CTIL I've
>created, it instead goes to CSM_TokenInterface and runs the code

These 2 calls, SMTI_GenerateKeyWrapIV(...), SMTI_GenerateKeyWrap(...)
are declared "virtual", but not "pure virtual", so they do have a
default implementation in sm_apiCtilMgr.h.  They are only executed if
the inheriting class does not have an implementation that matches these
definitions.  If your definitions in "sm_ibeDLL" match, they should
override these 2.  Are you sure it is not executing the logic in
sm_CommonCtil.cpp?  This could be an ordering problem.
I noticed that sm_teestDLL.h contains an obsolete definition; try
adding:

	class SM_TESTDLL_API CSm_TestDLL : public CSM_Common

the "public CSM_Common" reference.  This will also allow you to directly
reference the AES encrypt/decrypt logic.


#############################
>pTmpInstCS = (CSM_CSInst
*)pTmpInst->AccessTokenInterface()->AccessCSInst();

No.  This call is correct.  The idea is that the SFL libraries do not
link directly to the CTIL library(s).  The TokenInterface contains a
number of "virtual" calls that are filled in by the CTIL logic, specific
to the algorithm(s) being implemented.  The above "public CSM_Common"
should fix this.  If not, please send me your .h file (and source .cpp
if you don't mind, but just the .h will do) for the CTIL, I will look at
it.

Bob Colestock

-----Original Message-----
From: Gavin O' Gorman [mailto:gavin.ogorman2@xxxxxxxxxxx] 
Sent: Tuesday, April 01, 2003 2:18 PM
To: Imc-Sfl
Subject: RE: creating kek messages


Bob,
Thanks for the rapid and comprehensive reply ! One or two more question
below

> A FEW NOTES OF INTEREST HERE:
>
> - AES may not work for KEK in the SMP R2.2 version; the AES Key Wrap
> implementation(RFC3394) was just written by me, but not in time for
> R2.2.  Unfortunately, the content encryption and key wrap algorithms
> must match, so this should fail.  I never tested this particular
> condition, so I suspect even if you get a good encode, it may still
not
> work.  The algorithm check for a matching content encryption should be
> in the CTIL since the SFL libraries are not aware of algorithms, so
you
> should be OK.  This condition will cause an exception, not a crash, so
> you should see an error message if you capture and print the
exception.
>
>
> Bob Colestock


How do I go about creating an asn.1 dump of a blob ?

And also just to clear it up in my mind, as regards kek.
The content encryption algorithim should be the same as the
key encryption algo ? However, the SFL leaves it up to the CTIL
to check this, so I could get away with using a different encryption
algorithm to encrypt the content key (using kek )?

The encrypt method appears to be stepping through everything it
should (that I can see anyway), however there is one area that is a
bit odd. In CSM_DataToEncrypt::AddRecipient, when handling kek,
the code

pTmpIV =
pInst->AccessTokenInterface()->SMTI_GenerateKeyWrapIV(lKekLength,
              &WrapAlg);
SME(pInst->AccessTokenInterface()->SMTI_GenerateKeyWrap(&bufMEK,
              &pRecip->m_bufEMEK, &contentEncryptParams,
              &pRecip->m_pKEKDetails->m_UserEncryptionData, pTmpIV));

doesn't actually run the SMTI methods from the sm_ibeDLL CTIL I've
created, it instead goes to CSM_TokenInterface and runs the code
there. Every where else it appears to find the sm_ibeDLL fine. Any
idea why that might be ?

Possibly this bit of code in CSM_DataToEncrypt::ProcessRecipients ?

pTmpInstCS = (CSM_CSInst
*)pTmpInst->AccessTokenInterface()->AccessCSInst();

thanks,
Gav