RTP Encryption for 3G Networks Rolf Blom, Elisabetta Carrara, Karl Norrman, Mats Näslund...
-
Upload
sharlene-mason -
Category
Documents
-
view
221 -
download
0
Transcript of RTP Encryption for 3G Networks Rolf Blom, Elisabetta Carrara, Karl Norrman, Mats Näslund...
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