Re: [AVT] Attack causing false key derivation

[mcgrew <mcgrew at cisco.com>]

Hi Mike,

>Hello all,
> 
>Maybe this has been asked and answered, but it seems like session key
>derivation can be triggered by a packet that has not yet been authenticated
>since one can't authenticate such a packet until after the new session keys
>have been derived.  Isn't that true?

Yes, that's right. 

>Or am I missing something.  When the packet index is zero, modulo the key
>derivation rate, then you have to do a key derivation to get the
>authentication key to attempt to authentication the packet.  Right?

Exactly.

> 
>So it seems like an attacker can cause significant CPU usage, especially for a
>low key derivation rate (i.e., frequently deriving new session keys) by just
>sending packets with random sequence numbers and getting lucky when they fall
>within the range that causes a new key derivation.  Once the offending packet
>fails authentication the damage could be undone (save old keys etc. and don't
>overwrite until the packet is authenticated) but it would still burn
>significant CPU time doing the derivation?
> 
>Is this a correct assessment?

Yes and no.  Your analysis of the protocol is right, but in most cases the
additional CPU usage due to the need to generate a new authentication key is
not that significant.   When the default authentication method of HMAC-SHA1,
it takes two AES operations to generate a new auth key; this is the same
amount of time that it takes to encrypt 32 bytes of data with AES.  So if
the packets are 80 bytes, by way of example, then the cost of generating the
auth key is an additional 40% of the cost of encryption.  It would be an
even smaller fraction of the total crypto cost, since we need to factor in
the computational cost of checking the authentication of the packet too.
For small packets, the computational cost of HMAC-SHA1 authentication is
actually greater than the cost of AES encryption, so in the above example
the key derivation overhead drops to 20%.   So for many applications, I
would expect that the additional cost of a key derivation could be fit into
the processor budget associated with the processing of a single packet.

I suppose that the worst case scenario would be g.729, in which the two AES
operations are required to encrypt the packet, and the cost of HMAC-SHA1
authentication would be roughly double that cost (recall that authentication
processes the headers as well).   Deriving a key will take an additional %33
of the CPU.  Quite possibly there are processors that could handle the
default SRTP cryptoalgorithms, but could not handle that additional burden -
I guess they might need to avoid using the key derivation.   (As a side
note, the cost of g.729 encoding on a DSP is higher than that for the
cryptography, so the actual picture might not be so bleak.  The shortest
packets come from the most intensive compression algorithms, so there is an
inverse relationship between the amount of processing needed for compression
and the amount needed for cryptography.)

Best regards, 

David

> 
>Regards,
> 
>Mike Taylor

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt