Secure RTP : AV Security on the Internet

1
Secure RTP A/V Security on the Internet
Marshall Eubanks Chief Technology Officer

• Video Conferencing Summit
• February 24. 2004

2
Some Security Principles

• Chiffrez bien, ou ne chiffrez pas! (Encipher
  well, or do not Encipher at all.)
• Marcel Givierge
• The Enemy Knows the System Being Used.
• (Kerckoffs' Principle as stated by Claude
  Shannon)
• The Enemy Can Penetrate the Network Being
  Protected.
• (Eubanks' Corollary to Kerckoffs' Principle)

3
Why RTP ?

• RTP is the Real-time Transport Protocol of the
  IETF.
• It is commonly used to encapsulate and send real
  time audio and video on the Internet
• As videoconferencing moves to the Internet
  protocol, we can expect more usage of RTP for
  videoconferencing, especially for MPEG and H.264
  video.
• It was not designed for secure data transport.
• (For more RTP information http//www.cs.columbia
  .edu/hgs/rtp/faq.html )

4
Why Secure ?

• Business conversations may deal with
• Multi-Billion Dollar Contracts
• Many Billion Dollar Mergers
• We want these conversations conducted using
  videoconferencing!
• Unauthorized Knowledge of these Conversations
  could be worth Millions or even Billions of
  Dollars
• Stock Manipulation is an obvious criminal threat.
• National Intelligence Services have been known to
  spy on behalf of commercial interests.
• This creates a strong security threat and a very
  demanding security model.

5
The Threat Model

• For a Billion Dollar reward, we must assume that
  there is almost nothing an attacker cannot do
• They can buy entire systems to reverse engineer
  them
• They can buy connections into private networks to
  snoop
• They can bribe and coerce employees
• They will find the system being used !
• If there is a weakness, they will attack it !
• The only hope is in a robustly secure system
  subject to extensive outside analysis.
• Security must rest in secret keys, not secret
  systems.

6
Secure RTP

• Secure RTP, or SRTP, is a new protocol coming
  through the IETF
• It is not the same and much more robust that then
  security features in RTP itself
• It was built for 128 bit security and has been
  scrutinized by the cryptographic community.
• It provides for confidentiality, authentication
  and replay protection.
• I will focus on A/V features, not wireless phone
  features
• The draft is at
• http//www.ietf.org/internet-drafts/draft-ietf-avt
  -srtp-09.txt

7
Security Primitives

• SRTP allows you to chose your encryption
• However, the following are the defaults, and I
  would strongly recommend their use
• AES (Advanced Encryption Standard)
• For encryption
• SHA-1 (Secure Hash Algorithm)
• For authentication
• Counter Mode Block Encryption Mode

8
NIST Standards

• AES (Advanced Encryption Standard)
• Faster than DES in software
• MUCH faster than triple-DES
• Official NIST standard
• 128 bit symmetric key
• 128 bit block size
• SHA1
• 160 bit hash function
• HMAC-SHA1 is the default authentication mode

9
Block Cipher Modes

• AES will encrypt a 128 bit block
• What if you have more than 128 bits of video data
  ?
• This seems simple
• Divide the input into blocks
• Encrypt each Plaintext block with the key
• Ci E(K, Pi )
• This is called Electronic CodeBook (ECB) mode,
  and it is dangerous.
• ECB leaks too much information - identical
  plaintext encrypts to identical cybertext

10
What Block Cipher Mode to Use ?

• There are other Block Cipher Modes that encrypt a
  combination of current data and previous
  encryptions
• These avoid the weaknesses of ECB, but have one
  BIG problem for RTP
• Missing data causes the data stream to become
  undecipherable
• Instead, Counter Mode is the default.
• This is a stream cipher mode

11
Counter Mode

• The problem is we do not want identical
  (repeated) plaintext data to encrypt to the same
  cryptotext
• One solution is combine the current plaintext
  with previous cryptotext and encrypt that
• This called chaining - the problem is that if
  you loose any data, you may not be able to
  decrypt the rest!
• Counter Mode (CTR) has a simple structure
• Start with a unique number, a NONCE, 128 bits
  formed from a salt and the SSRC
• Combine that with the key and a counter for each
  packet and encrypt that.
• XOR the resulting one time padthat the
  Plaintext
• Can always recover from lost packets.
• But you can never, ever, repeat the NONCE - or
  all security is lost

12
Authentication

• SHA1 is a secure hash
• Easy to compute, effectively impossible to find
  two inputs with the same hash.
• HMAC uses SHA1 to combine the plaintext with the
  key (twice) for a cryptographic hash
• Authentication includes the entire RTP header,
  including the SSRC, time stamp and sequence
  number
• Authentication is not required (a wireless
  consideration) but my recommendation is that it
  MUST be used with Counter Mode.

13
Whats Missing ?

• SRTP does not deal with key exchange !
• This is a major lapse - the Internet draft pushes
  the problem onto other protocols.
• However, the problem is not really different from
  exchanging credit card numbers with secure
  servers
• There are lots of solutions out there.

14
Conclusions

• In security, you do not want to re-invent the
  wheel.
• In SRTP, the AVT community, led by Mark Baugher
  of Cisco, has created a robust system for the
  protection of audio visual conferences, including
  video conferences
• This should serve the needs of the community for
  the foreseeable future.
• A key exchange standard needs to be adopted by
  the community.