[messaging] Naming and classifying a security property

[Ximin Luo]

On 14/09/15 12:47, Katriel Cohn-Gordon wrote:
>     - (in: w encrypts m to r) if attacker "a" passively compromises w, they are able/unable to decrypt current (in-transit) and/or future ciphertext (i.e. "act as r")
>     - (in: w authenticates m to r) if attacker "a" passively compromises r, they are able/unable to authenticate messages to r (i.e. "act as w")
> 
>     I'm sure *someone* has considered it before, but I can't remember any literature that explicitly names this property - as opposed to say, "forward secrecy" or "key compromise impersonation". Does anyone who's more widely-read than I, know more about this?
> 
> 
> This is discussed inActor Key Compromise: Consequences and Countermeasures <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6957115&tag=1> [Basin, Cremers, Horvat; CSF 2014]. As you point out, the idea is known as KCI for authenticated key exchange protocols, but it's applicable much more widely.
> 

Nice paper, thanks Katriel! If I understand correctly, the paper includes a construction on how to make any key agreement protocol AKC-secure (for any security property derived from the session-key) by adding a round to further protect the session-key.

It'd be interesting to see how to work this construction into protocols that *continuously perform key agreement* during communication, as is desirable in asynchronous messaging - though OTR does it too. (And then you need to consider compromise of not just the long term key, but of the "current" session-key.) Also interesting would be if this is easily extensible into group messaging. That would be a lot of work, though.

Intuitively, I had thought that AKCS for secrecy would be very hard to achieve for private group messaging. Rough thoughts:

- AKCS for authentication ("KCIR" in the paper) can probably be achieved in a straightforward way in groups: each sender gets (as the result of the session establishment protocol) an authentication capability, and the whole group gets the verification capability, including the sender. If a verifier is compromised, the attacker doesn't get the authentication capability. This doesn't seem too hard to arrange.
- AKCS for secrecy however, would need to explicitly exclude the decryption capability from the sender. This would be very awkward to achieve in a group scenario - the session establishment scenario would have to somehow generate n decryption capabilities, and keep each of them secret from {all-but-1} of the group.

The existence of a construction offers some hope in this area, but I'm not trained enough in this area to give formal arguments.

However, it's good to mention the security property at least, for completeness and future reference, even if it's not achieved by the protocol one is designing.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150914/3f3e5972/attachment.sig>