Subject: RE: [AVT] SRTP: (In)security of encrypted SID Frames - A new Secu rity Threa t?

From: "Elisabetta Carrara (ERA)" <[email-masked]>
Date: Thu, 31 Jan 2002 11:16:32 +0100

Hi Martin!

The attack model considered when designing stream ciphers
*is* that large amounts of plaintext are known. 
A cipher whose security would depend on plaintext entropy 
would be completely unacceptable. 

In SRTP we use AES in counter mode (or f8 mode). Both of these modes
are provably secure under the assumption that AES is a "pseudo random
permutation" (which is widely believed). The proof of security implies 
the following: even if an attacker has a large amount of known plaintext
(and thus, knows the output of the corresponding keystream segments), 
it will in no way help him to deduce *any* non-trivial information about 
an unknown plaintext portion.

If they did, there would be a fundamental design flaw in AES, 
which would probably render all use of AES insecure.

Thus, your concern is a general stream cipher issue. The alternative,
using a block cipher would be completely unacceptable from wireless
(bit-error) point of view. Moreover, except for the fact that a block cipher can
(marginally) conceal the length (up to block boundaries), there is really nothing
that suggests that AES is more or less secure when runs as a block cipher, or
as a stream cipher.

Section 10.3 does consider the issue. We can expand it, and also add something like:

"Due to the way a stream cipher combines plaintext
with its output, (secure) stream ciphers are designed to resist known
plaintext attacks."

thanks, 
cheers,

/Mats & Elisabetta

> -----Original Message-----
> From: Euchner Martin ICN M SR 3 [mailto:[email-masked]]
> Sent: den 31 januari 2002 09:22
> To: [email-masked]'; Euchner Martin ICN M SR 3
> Subject: [AVT] SRTP: (In)security of encrypted SID Frames - A new
> Security Threa t?
> 
> 
> Dear SRTP and security experts,
> 
> 
> This text raises a security concern upon the RTP payload 
> voice encryption as
> accomplished by SRTP for example. The conclusion is to 
> further investigate
> analysis of this security issue but also to consider this issue in the
> security consideration section of SRTP.
> 
> Background
> Certain voice codecs and voice compression algorithms provide 
> the capability
> of silence detection and silence suppression (see e.g. 
> G.723.1, G.729AB,
> G.728 and also new G.711 Appendix II). Instead of 
> transmitting the sampled
> silence signal itself, these schemes rather transmit silence 
> parameters as
> SID frames. The purpose of this mechanism is to reduce 
> bandwidth on the wire
> and generate comfort noise at the peer side when there isn't 
> any significant
> input signal at the source.
> 
> Basically, SID frames provide an indication of detected 
> silence and the
> duration of this event. SID frames usually provide compact 
> parameters as
> input to a noise generator on the recipient's end instead of 
> the actual
> sampled silence. Typically, SID frames are much shorter than 
> encoded voice
> payload; SID frames may even be of a short fixed length, as 
> opposed to some
> codecs in which voice frames are of variable length.
> 
> So far, multimedia security schemes such as SRTP encrypt all 
> voice payload
> regardless of its semantics and contents. Doing this is 
> straightforward.
> Thus, at present, SRTP does not distinguish between actual 
> encoded voice
> payload data and SID frames. All application layer plaintext 
> content is
> encrypted as ciphertext in the same manner.
> 
> Thesis
> However, there are doubts on whether this security technique 
> would not be
> subject to the following security weakness:
> 
> While the purpose of encryption is to conceal the contents of the
> transmitted data, the characteristics of SID frames would 
> allow an attacker
> intercepting ciphertext to deduce that encrypted SID frames were
> transmitted. Thus, by traffic analysis, an attacker could distinguish
> between encrypted SID frames and actual encrypted voide/video etc.
> 
> It is presumed and appears likely that SID frame patterns 
> provide much less
> entropy than any other regular voice data. This would be due 
> to the fact
> that the SID frame provides only very few parameters that 
> would not change
> dramatically from one SID frame to another. As such plaintext 
> SID frame
> content could probably be guessed with much higher 
> probability than varying
> voice content.
> 
> Assuming this to hold true however, would permit cryptoanalysts and
> attackers specifically, to efficiently run known-plaintext 
> attacks assuming
> available ciphertext material by interception and guessed SID 
> plaintexts.
> While brute-force attacks on arbitrary ciphertext would be 
> always possible
> in theory, it is believed that brute-force attacks or known plaintext
> attacks are infeasible in practice when assuming high entropy 
> plaintext and
> strong encryption ciphers.
> 
> Although SID frames would be encrypted, the presence of a SID 
> frame could be
> deduced as the ciphertext would be of shorter length 
> typically. As a result
> of a successful known-plaintext attack, the attacker would obtain the
> session encryption key and thereby would be able to decrypt 
> any encrypted
> voice payload. This attack appears feasible when done 
> off-line but depending
> of the efficiency of the known-plaintext attack, an online 
> attack might be
> feasible as well. This would break the entire security scheme.
> 
> Conclusion
> While the RTP payload encryption method as specified by SRTP 
> has not been
> proven broken yet, we believe that this issue as pointed out 
> above should be
> taken seriously. While any detailed analysis is not yet 
> available, we see
> enough motivation by the raised concern above, to further 
> cryptanalyze the
> ramifications of SID frame encryption. We encourage security 
> experts to
> think about the problem and attempt to prove or disprove the 
> thesis. It is
> to be noted, that a similar security concern might persist 
> for encrypted
> video frames as well for particular video codecs, where the 
> video payload
> headers were mostly constant or vary only moderately.
> 
> If the security issue would turn out to be true, we seek appropriate
> technical countermeasures how to improve the multimedia 
> payload encryption
> method. One possibility could be not to encrypt SID frames but rather
> transmit SID frames in plaintext. This would be acceptable 
> and valid as the
> content of a SID frame itself would not leak any confidential 
> information to
> an outsider. Doing this however, would make it necessary to 
> in-band signal
> within the RTP packet that certain payload was not encrypted 
> and thereby let
> the recipient selectively by-pass the decryption function. An 
> appropriate
> signalling means should be defined then.
> 
> In any way, it is proposed to address this security matter in 
> the security
> consideration section of SRTP.
> 
> 
> I appreciate any comments and feedback on this matter and 
> would particularly
> like to know whether this issue has already been researched 
> anywhere so far.
> 
> 
> With kind regards
> 
> Martin Euchner.
> --------------------------------------------------------------
> ---------
> | Dipl.-Inf.                     Rapporteur Q.G/SG16
> | Martin Euchner                 Phone: +49 89 722 55790
> | Siemens AG.....................Fax  : +49 89 722 47713
> | ICN M SR 3                     mailto:[email-masked]
> |                                mailto:[email-masked]
> | Hofmannstr. 51                 Intranet:
> http://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt