1. RTP Encryption for 3G Networks Rolf Blom, Elisabetta Carrara, Karl Norrman, Mats Näslund Communications Security Lab Ericsson

2. “Conversational Multimedia Security in 3G Networks” draft-blom-cmsec-3G-00.txt “RTP Encryption for 3G Networks” draft-blom-rtp-encrypt-00.txt

3. to end up with a service as attractive as today’s CS (cost and speech quality) Objective Confidentiality of media streams in Conversational Multimedia scenarios (cellular environment)

4. Scenario Conversational Multimedia IP-all-the-way Heterogeneous environment (including wireless)

5. Requirements for the encryption scheme Target BER over the air link  error-robustness Delay (processing time, thin client)  efficiency Packet-loss and non-ordered delivery (IP)  "fast-forward/rewind" property Classification and demux of the traffic  selective payload encryption

6. Requirements (cont.) Bandwidth  message-size expansion and added fields limitation Header Compression (ROHC)  unencrypted IP/UDP/RTP headers Unequal Error Protection  UEP classes independence

7. Message Integrity and Authentication Two issues: bandwidth consumption (96/128/160 bits of MAC) even using a very short MAC (with lower security), still it has cost impact, and what should it cover? Message integrity and authentication as optional

8. IPsec Applicability IPsec is the promising security solution for the All-IP scenario and ROHC supports IPsec hc but ‘transport ESP’ – the most efficient ROHC profile does not work –IPsec header ‘tunnel ESP’ –header overhead AH and ESP+NULL –bandwidth

9. Encryption Algorithm BLOCK CIPHERS STREAM CIPHERS BLOCK CIPHERS used as STREAM ( ) Cons: padding, error prop if random-access property

10. Conclusions We have to accept the cost/security trade-off to get an attractive service We go for –application encryption –only the RTP payload is encrypted –a block cipher used as a stream cipher –careful analysis of message authentication usage We promote the use of security profiles.

11. Our proposal Objective: confidentiality of the media session Use the f8 mode of operation with AES It satisfies all the requirements, plus it is flexible (any secure block cipher as core) and the sync is given by the IV on a per- packet base

12. IV m k AES in f8-mode AES ct=2ct=1 AES From the RTP header 128 bits, may be the same for all RTP sessions  media session Public sec evaluation doc available

13. Open issues Adding a MAC per-packet is unacceptable for cost (optional) realtime aspects + f8 sync mechanism make attacks difficult, at least in conversational multimedia the main danger (as usual): DoS RTCP key management

14. Implementation Running testbed AES/Rijndael 128 40-60 Mbit/s 6 microsec initialization

15. Conclusions Our proposal {f8+AES on RTP payload} as a low cost method, to allow full hc, and low complexity implementation RTPEncrypt achieves confidentiality of the media session also in the most demanding scenario (conversational multimedia) local policies decide the sec scheme (profiles)

16. RTPEncrypt and SRTP Similarities confidentiality by per- packet appl of block cipher bandwidth saving (hc) low computational cost Differences f8 vs CTM authentication cost RTCP keying