Re: Signatures and encryption headers

On Nov 7, 11:22 pm, d...@xxxxxxxxxxxxxxxxxxxxxxxx (David Wagner)
wrote:
Fabrice  wrote:
But in any case, assuming that session key and IVs are
indistinguishable from random data, that any value is a plausible one,
I still dont see how not authenticating those values could breach the
confidentiality....

I've seen all sorts of crazy and surprising chosen-ciphertext attacks.
I wouldn't count on inability to imagine such an attack to imply that
leaving IVs unauthenticated is safe.  I suspect there are scenarios
where it is demonstrably unsafe: where an attacker can modify an IV in
transit, thereby causing controlled modifications to the decrypted
message received by the receiver, thereby breaching confidentiality.

I'm not sure I follow this statement. Do you consider confidentiality
breached when an attacker can modify the message received ? I would
only consider confidentiality breached when the attacker can gain
knowledge of what the sender actually sent.

But I see how the lack of authentication can cause the receiver to act
improperly and "forward" confidential content to unauthorized party.
But I would still think that authenticating the IV is not the real
issue (although it might make injection attacks impossible) but rather
the fact that there is no authentication of the messages.
In the WEP attack described in the paper, it seems to me that the real
issue is that the checksum is not keyed and as such does not provide
authentication.


Now, to come back to my scenario, I would have authentication, but
only for the message itself, not for the iv or other encryption
parameters.

It would look something like that:

A--->S--->D--->R

A is the Author
S is the Signer
D the Distributor (there can be more than 1)
R the Recipient (there willl be more than 1)

First, let see a scenario without encryption, ie there is no secret in
the payload:
A create a payload, S signs it with public key crypto (most likely
RSA).
S private key is probably the most important piece of key material and
is protected accordingly (Think armed guard, retina scans and things
like that). So Signing is here a very expensive and slow operation.
D get the signature and the payload create a file with them and
(somehow) send it to R.
R will only accept and trust payloads signed by S.

R got S Public Key in a physically secure way.
S is also supposed to verify that what it got from A is legit: ie S
will audit the payload or will have setup a secure communication
channel with A in advance.
D just store the outputs of S and when new Recipient come into
existence, it can send them the signed payloads without A or S having
to do anything.

Now, on top of that, sometimes A might include a secret in the
payload, so we want to have it encrypted as well. For that purpose R
and D share a symmetric key. This symmetric key has been shared in a
secure way once. For various reasons (performance, licensing...) the
recipient cannot use public key cryptography for decryption.

So now D does the following:
1- D choose a cipher (supported by R), generate a random session key
and IV, and encrypt the payload using that session key and that
cipher
2- D choose a key derivation method (supported by R) and uses it to
derive a key encryption key.
3- D encrypt the session key using the derived key encryption key.
4- D send the encryption header (cipher, derivation method, IV and
encrypted session key) to R along with encrypted payload and signature

On the R side:
1. R receive the header and check that the parameters are valid (ie
that it supports the chosen cipher and key derivation)
2. Derive the key, decrypt the payload
3. Check the RSA signature on the payload.

Note that R never authenticates D. That is convenient because we dont
want R to have knowledge of D, only S.

Plausible entry points for attacker would be:
- Know Plaintext: It is plausible than an attacker could compromise A
and get the secret directly from him (then we have failed before we
started). It is also very much more so plausible than an attacker
would have access to many plaintexts that do not contain the real
secret.
- Chosen Plaintext: It is somewhat plausible that an attacker could
get S to sign any plaintext it wishes.
- Any attacker could impersonate D, send any encryption header and any
encrypted payload. But, the recipient will not act like a full
decryption oracle. It is possible that the Recipient leaks information
about the plaintext, but only if it is a plaintext signed by S. So for
this reason, I dont think Chosen Ciphertext Attacks are really
possible in this context.
- IV and session key re-use should be avoided by D by selecting them
randomly.

So in that scenario, I dont see how having the encryption header not
authenticated would cause any serious issue.


I note that there is a possibility that A would want to send something
encrypted to R without having it signed by S. In that case I
understand that CCA are probably more plausible, and that would be an
accepted risk.
I also note that if S private key were compromised, then CCA are also
more likely.

-- Fabrice
.

Relevant Pages

  • Vulnerability in encrypted loop device for linux
    ... An attacker is able to modify the content of the encrypted device ... considered a aim of the encryption mode, so most modes (e.g. ECB, CFB, ... As we need to authenticate the device across mounts and not while it is ... It slows down mount operations but they are ...
    (Bugtraq)
  • Re: Encryption and authentication
    ... have encryption without authentication? ... it seems that encryption couldn't exist without authentication. ... and example is asymmetric key cryptography technology. ... http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked ...
    (comp.security.firewalls)
  • [UNIX] Vulnerability in Encrypted Loop Device for Linux
    ... Encrypting a disk device aims to protect against an off-line attacker who ... The encryption mode used by encrypted loop device is CBC. ... We propose 2 types of fixes: one that authenticate at mount time (see ...
    (Securiteam)
  • Re: Question about rsync
    ... The most important aspect of security is improving your weakest links - when you are at the stage that the easiest methodof attack is physical, or personal, then your job as IT security is pretty much done. ... It makes sense to take easy steps to increase security if you can - an attacker might not have the same opinion about the easiest methodof attack as you. ... but it contains information about an algorithm aimed precisely at transferring only those parts of a file that have changed. ... So unless you are doing a backup of a nuclear missile design, encryption on an rsync backup will only make a realistic difference if your network topology is such that the traffic is accessible by more people. ...
    (comp.os.linux.networking)
  • Re: Ciphers and their effect on the size of data
    ... We have a security-sensitive client that is wants common authentication between a J2EE environment and a "fat windows client". ... we'll also be facing 4/3 expansion of the payload after encryption. ... This password field will include a digital signature, or the digital signature will be in another XML element in that document. ...
    (sci.crypt)