Post on 21-Dec-2014
description
IDC’99, Madrid23 Sept. 1999
1Ian Brown, UCL
Secure multicast conferencing
Peter Kirstein, Ian Brown and Edmund Whelan
University College London
IDC’99, Madrid23 Sept. 1999
2Ian Brown, UCL
Multicast conferencing involves...
VideoAudio
Shared whiteboard
IDC’99, Madrid23 Sept. 1999
3Ian Brown, UCL
Security provides...
• Confidentiality: only authorised conference members can access conference data
• Integrity: you can be sure data has not been altered in transit
• Authentication: of conference announcers and participants
IDC’99, Madrid23 Sept. 1999
4Ian Brown, UCL
Point-to-point conferencing security is easy...
GCCProvider
Node 2 Node 3 Node 4
Node 1
MCS Connections
Top GCCProvider
NodeController
ApplicationProtocol
Entity
GCCProvider
GCCProvider
NodeController
NodeController
NodeController
ApplicationProtocol
Entity
• Each link is secured using a standard communications security protocol: IPSEC, SSL/TLS, SSH
• Extremely wasteful of bandwidth
• Multipoint control units are security risks
IDC’99, Madrid23 Sept. 1999
5Ian Brown, UCL
But multicast is more tricky...
• Multicast doesn’t fit the “point-to-point” model of current security protocols
• There is no standard method of sharing keys between group members
IDC’99, Madrid23 Sept. 1999
6Ian Brown, UCL
Insecure conferences
• Use Real-time Transport Protocol (RTP) to send data
• Users announce conferences and invite users by sending a session invitation via e-mail, the Session Announcement or Session Invitation Protocols
IDC’99, Madrid23 Sept. 1999
7Ian Brown, UCL
Secure transport
• RTP allows data to be encrypted with DES - implemented in UCL’s tools
• We want to move to IPSEC to remove need for cryptographic code in applications and take advantage of its wide range of ciphersuites and protocol and implementation security
IDC’99, Madrid23 Sept. 1999
8Ian Brown, UCL
IP security extensions
• Now standardised by IETF (RFC 2411)
• Provides network-layer protection for all packets sent between compatible machines
• Not yet finished for multicast
IDC’99, Madrid23 Sept. 1999
9Ian Brown, UCL
Key distribution problem
• The Internet Key Exchange (IKE) allows two hosts to negotiate security parameters for an IPSEC connection
• But multicast IKE is much harder, and being investigated by the IRTF
IDC’99, Madrid23 Sept. 1999
10Ian Brown, UCL
Conferencing solution
• We use secure session invitations to distribute security parameters
• Sent using secure SAP, SIP, or e-mail (S/MIME) or retrieved via the World Wide Web (TLS)
IDC’99, Madrid23 Sept. 1999
11Ian Brown, UCL
Web distribution
• Session descriptions are stored on a secure Web server
• Authorised conference members can retrieve descriptions over a TLS link
IDC’99, Madrid23 Sept. 1999
12Ian Brown, UCL
Smartcards
• Users don’t like having to remember many long passphrases
• Mobile users need access to keys from many different systems
• Software keys are vulnerable to theft
• Smartcards alleviate all these problems
IDC’99, Madrid23 Sept. 1999
13Ian Brown, UCL
Active services
• In-network code can reduce bandwidth requirements, convert between coding schemes, provide multicast connectivity, etc. etc.
IDC’99, Madrid23 Sept. 1999
14Ian Brown, UCL
Processing encrypted data
Trusted environment
Filter
Plugin filtersCryptoengine
Cryptoengine
Secure, wireless low-bandwidth links
Secure, wired high-bandwidth links
Internet
Mobile Host
• You can give proxies the session keys needed for them to access and process data
• We are developing proxies that can work without this security risk
IDC’99, Madrid23 Sept. 1999
15Ian Brown, UCL
Conclusions
• Multicast conference data can be secured at the network or application layer
• Until multicast key distribution is standardised, lightweight methods based on session descriptions can be used
• New techniques are needed to allow in-network processing of encrypted data