Subject: Re: replacement for signedAndEnvelopedData for CMS with

From: Alicia da Conceicao <[email-masked]>
Date: Thu, 8 Sep 2005 15:08:11 -0400 (EDT)

> Have you come up with a way to support SignedAndEnvelopedData that does not 
> include the vulnerability that was described last week?
>>> The SignedAndEnvelopedData was dropped because of a security concern.  An 
>>> attacker can remove the signature, essentially making an EnvelopedData,
>>> and the recipient has no way to tell that the originator intended to sign
>>> and encrypt the protected content.

Dear Russ:

In answer to your question, NO.  Mind you, I do not consider this
to be a serious security concern when compared to the following:

An attacker can also remove the signature from a CMS SignedData
structure and be left with a blocked of unsigned data.  How is this
any less of a security concern?

And an attacker can also re-encrypt using a recipient public key,
and replace any encrypted data in a CMS EnvelopedData structure.

On a side note, how about this:

What if we placed a CMS SignedData structure without any encapsulated
data, and placed it in the EncryptedContent of a CMS EnvelopedData
structure?  The original detached data that was signed can then be
encrypted using the EncryptedKey in the CMS EnvelopedData structure.

An unprotected attribute for the CMS EnvelopedData structure can be
added that specifies that the original data is encrypted and provide
a digest hash of the encrypted data so that it can be matched against
it.

This appears to be CMS compliant, and it would only need to have
acceptance of an unprotected attribute as a common standard.  This
approach for signing and encrypting works great with detached
encrypted data, and protects the identity of the signer since the
detached signature is encrypted.

Comments?

Alicia.

---

From: Alicia da Conceicao <[email-masked]>
Date: Sun, 18 Sep 2005 08:56:31 -0400 (EDT)

>> What OID should I assign this DigestInfo attribute?  Although I  
>> could use a custom OID from my corporate tree (2.16.124.113568),
>> it would be best to use any existing standard.  In fact, if no
>> existing standard exists, then it should be offically published
>> by this IEFT-SMIME group.
> I think we need to get some buy-in from the working group to  
> determine if we want to undertake this. One way to start is to submit  
> an individual submission with your proposal, and then see if you can  
> get traction for it. The worst case is that it's an individual  
> submission and you've contributed your work, but not in the working  
> group (which isn't that bad). I think that this is a perfectly  
> reasonable thing to discuss on the list, however, since it's an add- 
> on for CMS.
> I am only aware of the message-digest attribute in section 11.2 of  
> RFC 3852, which does not include any information about the algorithm  
> used (just the digest value).

Hi Blake:

Correct, that is why I suggested using a DigestInfo attribute instead
of the message-digest attribute, since the DigestInfo includes the
algorithmIdentifier.  In addition, a different OID should be used,
since the hash is generated by digesting the encrypted data, instead
of digesting the unencrypted data.

Note that if one does not include the encryptedContent, then without
my proposed hash, there is NOTHING IN THE CMS EnvelopedData structure
that can be used to MATCH it with its EXTERNAL ENCRYPTED DATA.  Hashes
are also used to match up CMS SignedData with its external data.

>> For signed and encrypted data that is completely detached from a CMS
>> structure, which is useful for large or streamed data, one can do the
>> following...  Place a SignedData structure with **DETACHED DATA**  
>> inside the encryptedContent of a CMS EnvelopedData structure, then  
>> **ENCRYPT THE EXTERNAL DETACHED DATA WITH THE SAME CIPHER AND KEY
>> USED IN THE encryptedContent**.  Adding the UnprotectedAttribute
>> DigestInfo would also be essential, although this time the hash
>> should be of the external encrypted data and not the internal
>> encryptedContent.
> I don't understand -- why not just produce a normal Enveloped data  
> and then detach the entire encryptedContent (which is basically an  
> encrypted SignedData)?

Because then the SignedData has to embed the data.  I am looking for a CMS
replacement for PKCS7 SignedAndEnvelopedData that would work with fully
detached and encrypted data.  What I suggested would do that.

This way I can send a single CMS structure in a small messager header
which contains both the digital signature and encryption keys.  Then stream
the actual external encrypted data in a large message body, which can be
directly decrypted on the fly since it is just a RAW data OCTET STRING.
This is especially true for large (> 2GB) data, since it much easier to
decrypt streaming data and keep a running hash total on the fly.
Especially if one uses DER encoding.

Alicia.