[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: creating kek messages



Gavin:

You can certainly do this, but I am not sure how much of the CTIL
implementation will be necessary.  In your case, I would have to try and
step through the entire encrypt/decrypt process to be sure the proper
triggers are satisfied.  Writing a new CTIL always takes me more time
due to the hooks(expectations) in the SFL; they are more closely tied
than we intended.  If we get absolutely stuck and you do not mind
sending me the source, I can set this up for you; you appear to be very
close to a working implementation so it should not take long.

As to the testDLL; this logic is no longer delivered.  It has not been
kept up-to-date, as you have probably already discovered.

I assume you are loading these OIDs for the CTIL load in
"SMTestSMTIInit(...)"; so that they are recognized as a content
encryption.  The reason the SFL expects the KEK RecipientInfo processing
to see a content encryption OID is due to the key wrap operation; the
KEK key wrap is not done using a key encryption key but a simple content
encryption key (symmetric) so it expects a content encryption OID.  The
OIDs are usually different from content encryption, but the algorithm(s)
are the same (for RC2, 3DES, and AES).  

The fact that the EnvelopedData decode fails implies that the KEK
processing was not triggered correctly when encrypting.  I would like to
fix the SFL logic so that this condition errors if encountered.  You can
determine what component from the EnvelopedData is missing by looking at
an ASN.1 dump of the produced binary.  I would appreciate it if you
could send me this binary file as well so that I may fix the SFL to
error in this case.

The failure below could be that the "login->UseAllEncryptors()" call
relies on certificates to determine if a login is an encryptor; in this
case this login will never be set.  First try to set the Applicable flag
directly:

    login->m_pCSInsts->First()->SetApplicable();

There is a demonstration of the SFL KEK processing in
smp/SMIME/test/testsrc/util/sm_CLMsgToDecrypt.cpp in the method:

	CL_MsgToDecrypt::ReadKEKDetails(...)

(used by both encrypt and decrypt).  You appear to be missing the KEKRid
data, to be loaded into the CSM_RecipientIdentifer; this could be the
cause of the decode failure.  According to the CMS ASN.1 specification,
the KEKRid must contain a valid OCTEC STRING (not OPTIONAL):

   KEKIdentifier ::= SEQUENCE {
     keyIdentifier OCTET STRING,
     date GeneralizedTime OPTIONAL,
     other OtherKeyAttribute OPTIONAL }

If this is the case, I will add a check to the SFL to exception when not
provided by the user.  Please let me know.

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.

- The "Localkey" RecipientInfo feature should work, but has not been
tested recently.  Please e-mail if you encounter problems; I will
re-test this feature presently.

- There is a demonstration of mixing CTILs in order to provide custom
logic, but utilize another library for alternative/supplementary
algorithms.  This CTIL was provided, but not updated to build in R2.2; I
have it running now, so let me know if you are interested in mixing your
CTIL with another (e.g. sm_free3; the demo mixes PKCS11 and
free3/Crypto++).  This feature would allow you to front-end all SMTI_
calls and selectively call sm_free3 to complete certain processing.


Bob Colestock

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


Hey,

I'm in the process of writing a CTIL to work with IBE
(Identity Based Encryption - http://crypto.stanford.edu/ibe/)

I've created a sm_ibeDLL, which is basicly a copy of the testDLL.
Only changes I have made are registering both aes as a content
encryption
alg
and a made up IBE OID, neither of which are actually implmented in the
CTIL.
The IBE oid
is registered as a content encryption algo, key encryption algo and also
as
the Localkey algo.
(The SFL appears to require it to be registered as a content algo for
KEK,
but then does not use it as such ? )
Nothing else at all has been implemented in the CTIL, it's all just as
in
the testDLL.

I've decided to use kek as a pose to key transport because key transport
seems to be tied closely in with certificates in the SFL and I will not
be
using certs at all.

I've done a small bit of code to test out the encrypt and decrypt.
Obviously
I don't expect anything to actually get encrypted/decrypted but I was
expecting it to create an EnvelopedData blob and then be able to 'read'
this
in the CSM_MsgToDecrypt. It runs through Encrypt() fine, but when I
create a
MsgToDecrypt with the EnvelopedData blob, it dies in
EnvelopedData::BDecContent with a ("SEQUENCE is missing non-optional
elmt",
DECODE_ERROR);

My code is pasted below. Am I doing something stupid, or perhaps do I
need
to implement some more functionality in the CTIL before it will be able
to
create the EnvelopedData properly ? I'd really appreciate any ideas or
comments.

Thanks,
Gav

(this is all in Windows 2000, visual c++ 6)


	CSM_AppLogin* login = new CSM_AppLogin();
	login->AddLogin("sm_ibedll","") ;

	char* test =	"Reply-To: <gavin@xxxxxxx>\
						From: \"Gavin O'
Gorman\" <gavin@xxxxxxx>\
						To: <gavin@stinger>\
						Subject: test\
						Date: Tue, 1 Apr 2003
09:45:14 +0100\
						Message-ID:
<PIEGLMFDLEPHELOCJAEAOEKNCHAA.gavin@xxxxxxx>\
						MIME-Version:
1.0\nContent-Type:
text/plain;\ncharset=\"iso-8859-1\"\nContent-Transfer-Encoding:
7bit\n\ntesty\n." ;

	CSM_Buffer* buffer = new CSM_Buffer(test, strlen(test)) ;
	CSM_MsgToEncrypt* encrypt = new CSM_MsgToEncrypt(buffer) ;

	SNACC::AsnOid oidContentEncryption(SNACC::id_aes128_CBC);
	SNACC::AsnOid oidIBE("1.2.3.4441");

	encrypt->SetContentEncryptOID(&oidContentEncryption) ;
	encrypt->SetAddOriginatorAsRecipient(false);

	login->UseAll() ;
	login->UseAllEncryptors() ;

	encrypt->m_pRecipients = new CSM_RecipientInfoLst ;

	CSM_RecipientInfo *pRecipInfo;
	pRecipInfo = encrypt->m_pRecipients->Append();

	CSM_KEKDetails details ;
	details.m_UserEncryptionData = CSM_Buffer("blahblah",
strlen("blahblah")) ;
	details.m_keyEncryptionAlgorithm = oidIBE ;
	details.m_RID = CSM_RecipientIdentifier() ;

	pRecipInfo->m_pCert = NULL ;
	pRecipInfo->m_pKEKDetails = &details ;
	encrypt->m_pMsgCrtCrls = NULL ;

	encrypt->SetIncludeOrigCertsFlag(false) ;
	encrypt->Encrypt(login) ;


	CSM_MsgToDecrypt* decrypt = new CSM_MsgToDecrypt(login,
encrypt->
GetEncodedContentInfo()) ;