1
$\begingroup$

I was looking through the S/MIME Message specification (RFC 8551) to find out what security services it offers. Section 2.4.4 of this document describing AuthEnvelopedData content type (which uses the CMS type of the same name) says:

This content type is used to apply data confidentiality and message integrity to a message. This content type does not provide authentication or non-repudiation.

Authenticated-Enveloped-Data CMS content type uses authenticated encryption algorithms (such as AES-CCM or AES-GCM) according to the RFC 5083.

Authenticated encryption algorithms generally provide confidentiality, authenticity and integrity of data. So why does the S/MIME specification state that AuthEnvelopedData type doesn't provide authentication?

$\endgroup$

1 Answer 1

1
$\begingroup$

Authentication (and nonrepudiation) is relative to a source.

'Authenticated' encryption like GCM and CCM is a limited form of authentication that guarantees successfully decrypted data came from the entity that did the encryption, and was not modified (tampered) in transit, but does not by itself tell you anything about who the encrypter was, only that they had the key. The environment it is used in may add to this; as a common example, TLS (always in 1.3 and usually in 1.2 nowadays) can encrypt session data with an AEAD algorithm and a nonce key known only to the two endpoints of the connection (and with one exception an IV-aka-nonce at least partly known only to the endpoints); thus if one endpoint receives data that decrypts correctly, and knows it didn't send that data, the data must be from the other endpoint and untampered.

S/MIME and CMS messages can be transmitted in an unlimited number of steps to and from anybody, although signed messages can only be created by the entity with the relevant privatekey (and there should be only one because privatekeys should not be shared) and similarly enveloped messages (with the normally used RecipientInfo types) can only be 'opened' (decrypted) with a privatekey which only one entity should have. The AuthEnveloped variant, using AEAD encryption, guarantees that the ciphertext wasn't tampered with -- unlike traditional encryption which without outer signature or other integrity measure can sometimes be done in a way that causes undetected attacker-desired changes to the plaintext -- but it does not say anything about who the data comes from. Anybody in the world who has your (public) certificate can create a valid AuthEnveloped message to you. Since you don't know who the sender is, repudiation is meaningless -- there is no assertion of responsibility to be repudiated.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.