headers
Russ Housley | 3 Sep 2005 21:51

Re: replacement for signedAndEnvelopedData for CMS with external encrypted data


Alicia:

Have you come up with a way to support SignedAndEnvelopedData that does not 
include the vulnerability that was described last week?

Russ

At 10:24 AM 8/29/2005, Alicia da Conceicao wrote:
>If anyone has any reasonable work around for SignedAndEnvelopedData that
>works with detached encrypted data and still meets the CMS standards,
>please let me know.  Otherwise it may be useful to look at ammending
>the CMS specification to include SignedAndEnvelopedData.
Permalink | Reply | 0 comments |
headers
Alicia da Conceicao | 8 Sep 2005 21:08
Picon
Favicon

Re: replacement for signedAndEnvelopedData for CMS with


> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 14 Sep 2005 00:50
Picon
Favicon

I-D ACTION:draft-ietf-smime-gost-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Using the GOST 28147-89, GOST R 34.11-94, GOST
                          R 34.10-94 and GOST R 34.10-2001 algorithms
                          with the Cryptographic Message Syntax (CMS)
	Author(s)	: S. Leontiev, G. Chudov
	Filename	: draft-ietf-smime-gost-05.txt
	Pages		: 25
	Date		: 2005-9-13
	
This document describes the conventions for using cryptographic
   algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R
   34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is
   used for digital signature, digest, authentication and encryption
   arbitrary message contents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-gost-05.txt".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gregory S. Chudov | 14 Sep 2005 12:42
Picon
Favicon

Re: I-D ACTION:draft-ietf-smime-gost-05.txt


Greetings.
This is i hope the last revision to contain non-editorial changes.

* updated references to cpalgs, which is now in the RFC editor queue
* fixed some typos and terminology (UKM was sometimes called synchrovector, 
etc)
* key agreement algorithms reworked, they are now very close to ESDH from 
rfc3370
* added binary samples in style of rfc4134

Good luck!
Greg.
Permalink | Reply | 0 comments |
headers
Alicia da Conceicao | 18 Sep 2005 11:43
Picon
Favicon

Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


Greetings:

For CMS EnvelopedData, it would be very useful to have an
UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with
a hash of the encrypted data.

        DigestInfo ::= SEQUENCE {
            digestAlgorithm DigestAlgorithm,
            digest OCTET STRING }

This would be essential when the encrypted data is detached from the CMS
EnvelopedData structure, which occurs when the optional encryptedContent
is not present.  If one has either the detached encrypted data or the CMS
EnvelopedData, then this hash would greatly assist in finding a match for
the other.

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.

In additional, since SignedAndEnvelopedData is not available in CMS, one
could simply place a CMS SignedData structure inside the encryptedContent
of a CMS EnvelopedData structure.  This would protect the identity of the
signer and prevent forgery.

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Blake Ramsdell | 18 Sep 2005 13:19
Favicon

Re: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


On Sep 18, 2005, at 2:43 AM, Alicia da Conceicao wrote:
> 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).

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alicia da Conceicao | 18 Sep 2005 14:56
Picon
Favicon

Re: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


>> 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 19 Sep 2005 10:35
Picon
Picon
Picon
Favicon

Re: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


Alicia da Conceicao <alicia <at> engine.ca> writes:

>For CMS EnvelopedData, it would be very useful to have an
>UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with a
>hash of the encrypted data.
>
>        DigestInfo ::= SEQUENCE {
>            digestAlgorithm DigestAlgorithm,
>            digest OCTET STRING }

I proposed something like this a while back to get around the patent mess
surrounding the encrypt+authenticate modes of operation, and the response was
pretty underwhelming.  Specifically though, you want a MAC, not a digest, to
protect the content.  PGP uses a straight hash, but protects it by encrypting
it alongside the content.  If you use a hash then besides the obvious weakness
of not protecting it from modification, you also leak information about the
content in the hash.

>This would be essential when the encrypted data is detached from the CMS
>EnvelopedData structure, which occurs when the optional encryptedContent is
>not present.  If one has either the detached encrypted data or the CMS
>EnvelopedData, then this hash would greatly assist in finding a match for the
>other.

OK, that's a quite different use for what I was proposing it for - I was after
integrity protection of the content.  This is something that no current CMS
mechanism provides, but which a great many users expect as being provided when
they use encryption (see Simpson Garfinkel's thesis).  Adding a MAC as PGP has
would ensure that the behaviour of a CMS envelope met user's expectations.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alicia da Conceicao | 19 Sep 2005 12:02
Picon
Favicon

Re: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


>>For CMS EnvelopedData, it would be very useful to have an
>>UnprotectedAttribute containing a DigestInfo (as defined in PKCS#1) with a
>>hash of the encrypted data.
>>
>>        DigestInfo ::= SEQUENCE {
>>            digestAlgorithm DigestAlgorithm,
>>            digest OCTET STRING }
> 
> I proposed something like this a while back to get around the patent mess
> surrounding the encrypt+authenticate modes of operation, and the response was
> pretty underwhelming.  Specifically though, you want a MAC, not a digest, to
> protect the content.  PGP uses a straight hash, but protects it by encrypting
> it alongside the content.  If you use a hash then besides the obvious weakness
> of not protecting it from modification, you also leak information about the
> content in the hash.

Hi Peter:

Actually since the hash is generated by digesting the encrypted data,
no information would be leaked, since that data is encrypted with
random session keys, the resulting hash would be random as well.

There is no signifigant advantage in using an HMAC, and the encrypted
data integrity, and hence the unencrypted data integrity can be verified.

You are correct though, since the hash in an UnprotectedAttribute, it can
be replaced by an attacker.  This would not gain the attacker any info on
the data itself, but the attacker would be able to corrupt the encrypted
data, and the recipient would not be able to verify its integrity since
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Gutmann | 19 Sep 2005 13:15
Picon
Picon
Picon
Favicon

Re: Proposal for DigestInfo as UnprotectedAttribute in CMS EnvelopedData


Alicia da Conceicao <alicia <at> engine.ca> writes:

>But that is why I am interested in place a CMS SignData structure inside the
>encryptedContent of a CMS Enveloped structure, since a digital signature
>would verify data integrity, originality, and more.

But in that case why not just nest encrypted inside signed or signed inside
encrypted?  This seems like a rather awkward way of recreating the old
SignedAndEncrypted...

>Prehaps we need two UnprotectedAttribute for the CMS EnvelopedData structure.
>One attribute for matching of detached encrypted data, and the other
>attribute for data integrity that is protected.  I would be open to any
>creative suggestions on a way for us to solve both problems with a single
>attribute.

I think one of the possible objections to the HMAC use was that you need two
distinct keys, one for encryption and one for the HMAC, and there's no obvious
way to handle the second key in a system that usually only has a single
encryption key.  My suggestion would have been to use the key as is for
encryption and pass it through PBKDF2 to get the HMAC key.  This would be
backwards-compatible, since existing code would decrypt as normal and
integrity-enhanced code would know about the extra PBKDF2 + MAC step.

A bigger problem is that RecipientInfo doesn't provide any way of indicating
that integrity protection is to be applied without breaking backwards-
compatibility.  That is, you could use (say) a 3DES-with-HMAC-SHA1 OID, but
any existing app looking for 3DES only won't be able to process it based
solely on the OID.  The only place where you could put this is in the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane