RTP Encryption for

3G Networks

Rolf Blom, Elisabetta Carrara, Karl Norrman, Mats Näslund

Communications Security Lab

Ericsson

• “Conversational Multimedia Security in 3G Networks”

draft-blom-cmsec-3G-00.txt

• “RTP Encryption for 3G Networks”

draft-blom-rtp-encrypt-00.txt

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)

Scenario

• Conversational Multimedia

• IP-all-the-way

• Heterogeneous environment (including wireless)

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

Requirements (cont.)

• Bandwidth message-size expansion and added fields

limitation• Header Compression (ROHC)

unencrypted IP/UDP/RTP headers • Unequal Error Protection

UEP classes independence

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

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

Encryption Algorithm

BLOCK CIPHERS

STREAM CIPHERS

BLOCK CIPHERS used as STREAM

( )

Cons: padding, error prop

if random-access property

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.

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

IV

m

k

AES in f8-mode

AES

ct=2ct=1

AES AES AES AES

From the RTP header

128 bits, may be the same for all RTP sessions media session

Public sec evaluation doc available

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

Implementation

• Running testbed

• AES/Rijndael 128

• 40-60 Mbit/s

• 6 microsec initialization

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)

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