keying data exchange and rekeying mechanisms for ... exchange between the server and the client is done .... allow monitoring of the data delivery, and to.
A secure multicast pay-per-view application over Internet
Ramon Martí, Jaime Delgado Universitat Pompeu Fabra (UPF) Pg. Circumval·lació 8, E-08003 Barcelona, Spain E-mail: {ramon.marti, jaime delgado}@tecn.upf.es
1 Abstract This paper describes the implementation of a demonstrator system to provide secure multicast pay-per-view TV over Internet, to prove that it can be developed with existing technologies. In these pay-per-view systems, there is a single server sending the audio/video data, and a set of clients that can receive this data only if they have paid for that specific transmission. The main problem in such a system is the management and distribution of the keying data to the clients in a secure way, including rekeying when a user leaves the group. Standardisation of keying data exchange and rekeying mechanisms for multicast groups by IETF Multicast Security Working Group (MSEC) is still on draft stage ([MSEC-Draft] and [MSEC-DoI]). We propose a system that integrates different existing technologies into a Linux-based environment. Video and audio are transmitted using RTP real time protocol [RTP] through multicast IPSec [IPSec] protocols: multicast for bandwidth efficiency, and IPSec for privacy and authentication of the audio/video data. Secure rekeying data exchange between the server and the client is done through an innovative combination of technologies: Multicast messages from the server to the client for notification of keying data updates; authenticated and encrypted TLS-Tunnel [TLS] connection between the clients and the server for requesting the new keys (that are only sent to the clients that have paid for receiving that specific transmission); and IPSEC keying updating through direct interaction with IPSEC SAD database.
2 Introduction This paper describes the implementation of a demonstrator system able to provide secure multicast pay-per-view TV transmission over Internet. The main objective of the development and integration was to prove that with the current technology, a system providing secure pay-perview audio/video transmission over Internet could
be possible, even in case of participants joining and leaving the group dynamically at runtime. In pay-per-view, for each specific data transmission, only the customers that have paid for that content must be able to receive the information. Then, the system must support a mechanism for encrypting the audio/video data, together with a mechanism for dynamic exchange and update of the security mechanisms and keys without resetting the client nor the server systems. Although these mechanisms are already defined and standardised for unicast communication, secure and efficient key exchange for multicast groups is still under study, since the main problem is that one user leaving the group implies that some keying data update must be done in order not to allow this user to receive the multicast transmission. During the specification of the system, the following requirements were defined: • Linux-based system • Use of existing technologies • Secure encrypted and authenticated transmission of audio/video data through standard protocols • Support for several encryption and authentication security algorithms • Transmission with bandwidth optimisation • Support for a dynamic users list, including user addition and removal • Support for a secure and dynamic mechanism for updating keying data • User authentication through X.509 certificates In the next clauses of this paper, we give a brief introduction to all the existing technologies used in the system, followed by the description of the architecture of the full demonstrator system, together with the description of the data flow between the client and the server, including the explanation of the innovative mechanism for dynamic multicast keying data exchange between the server and the client systems.
3 Background For the development of the secure multicast payper-view TV system over Internet, a set of different existing technologies have been used. This clause gives and overview of all of them.
3.1
IPSec
IPSec (IP Security) [Ipsec] is a protocol that provides security for transmission of sensitive
information over unprotected networks such as the Internet. IPSec acts at the network layer, protecting and authenticating IP packets. IPsec consists of several separate protocols. Standard keying data exchange is actually optional, since the security mechanisms and the secret keys can be agreed beforehand and configured manually.
3.2
Multicast and IGMP
Multicast is a communication between a single sender and a group of selected receivers on a network. It is based on the definition of multicast groups, each one associated to one multicast application, and with an associated IP address (224.0.0.0-239.255.255.255 range), that identifies it. When a host wants to send or receive multicast information to/from a specific multicast group, this host must join that group. Appendix I of RFC 1112 [IGMP] defines the Internet Group Management Protocol (IGMP). IGMP is used by IP hosts to report their group memberships to any immediately-neighbouring multicast routers.
3.3
SSL/TLS - Secure Sockets Layer / Transport Layer Security
management and exchange ([MSEC-Draft] and [MSEC-DoI]). Their approach is based on a central controller. Different keys are used for the encryption of group management data and the multicast traffic itself.
4 System Implementation The different existing technologies introduced in the previous clause were integrated in the final demonstrator system. A system architecture was defined, with a set of different modules that make use of these technologies to achieve the functionality defined by the user requirements.
4.1
System Architecture
The architecture in Figure 1 was decided for the secure multicast pay-per-view TV system over Internet. The different components of the system are described in this clause, and the functionality and the data flow between them is described in the following one. Server
Client Multicast Notifications
Users DB Manag.
Users DB
MC Manag. Server
TLS Tunnel Keying Data
SSL/TLS provide data encryption, message integrity, server authentication, and optional client authentication for a TCP/IP connection. They run above TCP/IP and below higher-level protocols.
3.4
RTP/RTCP - Real Time Transport Protocol / Real Time Control Protocol
RTP, the real-time transport protocol [RTP], provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video. RTP provides payload type identification, sequence numbering, timestamping and delivery monitoring. Applications typically run RTP on top of UDP. The data transport is complemented by a Real Time Control Protocol (RTCP) (also defined in [RTP]) to allow monitoring of the data delivery, and to provide minimal control and identification functionality. RTCP is also independent of the underlying transport and network layers.
3.5
IETF MSEC Group
Recently IETF Multicast Security Working Group (MSEC) published the first drafts on multicast key
RTP MC Video Stream Server
IPSec
Launch
Write SA
Write SA
SAD
SAD
Secure Sockets Layer (SSL) [SSL] is a protocol designed to provide secure communications on the Internet. Transport Layer Security (TLS) [TLS] is the successor to the Secure Sockets Layer, and is based on SSL 3.0 protocol.
MC Manag. Client
Multicast IPSec Audio/Video Data
IPSec
RTP MC Video Stream Player
Figure 1: Architecture of the secure multicast payper-view TV system over Internet
4.2
Multicast
For the transmission of audio/video data, it was necessary a protocol able to provide bandwidth efficiency. For this purpose, multicast transmission was chosen. In this system, multicast is also used as part of an innovative way of keying data exchange, for notification to all the clients of keying data updates. The support for multicast provided by the Linux Operating System, with the appropriate kernel options, was successfully used.
4.3
IPSec
The demonstrator system had to provide secure transmission of the audio/video data, with support for multicast and support for different encryption and authentication mechanisms. IPSec was the mechanism chosen to provide the data security to the transmissions of multicast audio/video. From the security features provided by IPSec, it was decided that the demonstrator system should provide data encryption and also authentication.
From the different security mechanisms, ESP [ESP] was chosen, with 3DES algorithm for encryption and MD5 for authentication. Anyway, the system allows changing the security mechanism and the security algorithms in an easy way. IPSec is based on establishing unicast Secure Associations (SA) between the sender and the receiver, each one identified by its own IP address. In the demonstrator system, only one SA had to be defined in the server and in the client computers, since there was only one sender, the multicast video sender, sending video streams to a multicast group address, associated to a set or registered users. The Security Association Database (SAD) is where IPSec stores all the SA configuration information. The IPSec platform used in the demonstrator was SSH [SSH], because it supports IPSec for multicast transmissions on the Linux operating system.
4.4
TLS-Tunnelling
TLS-Tunnelling was integrated in the system as the communications protocol between the client and the server for the secure transmission to the user of the keying data required for establishing the multicast SA connection. Additionally, the communication authentication facilities through X.509 certificates provided by TLS where used to achieve server and client authentication for the keying data exchange. The introduction of TLS into the system for server and client authentication and for tunnelling of keying data was done by developing and integrating a TLS client and a TLS server, supporting both security mechanisms. For the TLS protocol software, libraries provided by OpenSSL were used. Anyway, the TLS-Tunnel was included in the system in a way that would allow a later replacement by an IPSec standard SA, when multicast keying data exchange mechanisms were clearly defined in the standard.
4.5
MC-Mgnt-Client / MC-Mgnt-Server
The Multicast-Management-Client (MC-MgntClient) and the Multicast-Managment-Server (MCMgnt-Server) modules are the core of the system. They are in charge of managing the negotiation and exchange of keying data between the server and the client systems in a secure way. For the MC-Mgnt-Client and the MC-Mgnt-Server, two specific applications were developed. These applications make use of the TLS-Tunnelling, integrating a TLS-Client and a TLS-Server, respectively, developed with the facilities provided by OpenSSL for secure and authenticated unicast data transmission. A multicast sender and a receiver were also developed and integrated in these
applications for the transmission of multicast keying data update notification messages. Additionally, the MC-Mgnt-Client and the MCMgnt-Server also interact with the local IPSec through the direct access to the SAD, for configuring the security parameters of the multicast IPSec channel used in the audio/video transmission. 4.5.1
MC-Mgnt-Server
The MC-Mgnt-Server is the module in the server system in charge of managing IPSec keying data and storing it in the IPSec SAD to establish the secure multicast transmission connection. It receives connections from the MC-Mgnt-Client through the secure TLS-Tunnel, it checks if the user has valid reception rights and, in this case, it sends to the client all the keying data required to join the multicast group. This module is also in charge of the rekeying when users leave the group, or when a new transmission starts. This rekeying is done by the MC-MgntServer informing the MC-Mgnt-Client about keying data updates through multicast notifications, combined with a keying data exchange through the TLS-Tunnel. For these purposes, the MC-Mgnt-Server includes a TLS server and a multicast sender. Once received the keying data, it is stored in the server IPSec SAD to set-up the secure IPSec multicast connection with the client systems. 4.5.2
MC-Mgnt-Client
The MC-Mgnt-Client is the module in the client system in charge of requesting to the MC-MgntServer through the secure TLS-Tunnel, all the keying data required for the multicast connection and storing it in the IPSec SAD to establish the secure multicast transmission connection. Once received, the keying data, it is stored in the server IPSec SAD to establish the secure IPSec multicast connection with the client systems. The MC-Mgnt-Client can request the keying data through the TLS-Tunnel either at the beginning of the session or as a response to the reception from the MC-Mgnt-Server of a multicast keying data update notification message. The MC-Mgnt-Client is also in charge of starting (or restarting) the MC-Video-Streaming-Player with the information received through the TLSTunnel. For theses purposes, the MC-Mgnt-Client includes a TLS client and a multicast receiver.
Once received the keying data, it is stored in the client IPSec SAD to set-up the secure IPSec multicast connection with the server system.
4.6
Users-DB
The Users-Database is where the server system stores the information about the users, the certificates of these users and for each data transmission the list of users with reception rights (i.e. those who have paid for it).
4.7
Users-DB-Management-Tool
The Users-DB-Management-Tool is a tool in the server system to manage the users information stored in the Users-DB, including the list of the users with valid reception rights.
4.8
X.509 Certificates/Keys Generation
X.509 security certificates and keys were required for user authentication in the communication between the MC-Mgnt-Client and the MC-MgntServer. For the creation of the keys and certificates, OpenSSL software was also used. Anyway, the usage of any keys and certificates supported by OpenSSL, should also be supported.
4.9
RTP-Multicast-Video-Streaming-Server
The RTP-Multicast-Video-Streaming-Server is the module in the server in charge of the transmission of the audio/video data to a specific multicast group through the multicast IPSec connection set-up by the MC-Mgnt-Server. It was decided that RTP should be used for the video streaming in the system. The RTP-Multicast-Video-Streaming-Server integrated in the demonstrator system sends synchronised mpeg videos and mp3 audio in two RTP separate sessions. It has been implemented adapting and integrating two separate applications: a RTP mpeg video streaming server and a RTP mp3 audio streaming server, both based on LIVE.COM streaming media [Live].
4.10 RTP-Multicast-Video-Streaming-Player The client system had to include a video streaming player able to receive, through the multicast IPSec connection set-up by the MC-Mgnt-Client, the multicast RTP video and audio transmissions sent from the server, and play both in a synchronised way. The RTP-Multicast-Video-Streaming-Player used in the demonstrator system is a combination of mim [MIM], for managing the RTP transmissions,
together with mtvp [mtvp] for the video playback and mpg123 [mpg123] for the audio playback.
5 System Functionality Implementation of the MC-Mgnt-Client and MCMgnt-Server has been done, integrating two communication mechanisms to provide an innovative way of keying data exchange: • TLS-Tunnel channel: For secure keying data exchange supporting encryption and authentication through X.509 certificates. • Multicast channel: To be used by the MCMgnt-Server to send keying data update notification messages to all the MC-MgntClients at the same time. To understand the system, it is necessary to describe its functionality. This can be done by describing the data flow between the different modules and the different phases in the data flow: • Data Flow between the MC-Mgnt-Client MC-Mgnt-Server • Phases of the data flow between the MC-MgntClient MC-Mgnt-Server
5.1
MC-Mgnt-Client MC-Mgnt-Server Data Flow
The innovative combination of two different mechanisms developed for the management and exchange of keying data between the server and the clients is described in the following subclauses: • TLS-Tunnelling keying data exchange • Multicast dynamic keying data update 5.1.1
TLS-Tunnelling Keying Data Exchange: MC-Mgnt-Server MC-Mgnt-Client
TLS-Tunnelling is used to provide secure user authentication through X.509 certificates and secure transmission of keying data to users that have paid for it. The data exchanged between the MC-Mgnt-Server and the MC-Mgnt-Client is mainly keying data related to IPSec configuration. When one user connects to the server, the server is in principle already using a specific IPSec configuration for the transmission of the audio/video data. Then, the IPSec connections with new users must use the same existing configuration, so no real negotiation of the IPSec configuration options is required between the MC-Mgnt-Client and the MC-Mgnt-Server: The MC-Mgnt-Server must send the existing configuration options and the MC-Mgnt-Client must accept and use them. The following is the data exchanged between MCMgnt-Server and MC-Mgnt-Client: • MC-Mgnt-Server -> MC-Mgnt-Client: The MC-Mgnt-Server must send to the MC-Mgnt-
•
Client all the keying data to allow the establishment of the SA. These include the IPSec encryption and authentication keys and algorithms. MC-Mgnt-Client -> MC-Mgnt-Server: The multicast SA is mainly configured with the options provided by the sender of the data, in this case, the server. Then, the MC-MgntClient does not need to send any information to the MC-Mgnt-Server.
5.1.2
Multicast Dynamic Keying Data Update: MC-Mgnt-Server -> MC-MgntClient Multicast
User removal is the most critical security issue in the management of keying data for multicast groups. A combination of Multicast keying data updates notification messages and TLS-Tunnelling keying data exchange was used to update dynamically the current keying data during the video transmission without resetting the system. For this purpose, multicast sender and receiver applications were developed and integrated into the MC-Mgnt-Client and -Server. For the multicast dynamic keying data update, two different multicast notification messages were defined to be sent from the MC-Mgnt-Server to the MC-Mgnt-Client: • “Request keys” multicast notification message, to inform that the MC-Mgnt-Clients must request for new keying data and store it. • “Change keys” multicast notification message to inform that the MC-Mgnt-Clients must change the keying data, and that they must start to use the just received one.
5.2
MC-Mgnt-Client MC-Mgnt-Server Data Flow Phases
Three phases can be distinguished in the system flow between the MC-Mgnt-Server and the MCMgnt-Client: • Server start-up phase • Client start-up phase / Stationary phase • Keying data update phase 5.2.1
Server Start-Up Phase
When the MC-Mgnt-Server starts, it generates new keys and sends the “Request keys” and “Change keys” multicast notification messages to all MCMgnt-Clients joined to the multicast group. Then, the clients must use the TLS-Tunnel to ask for the current keying data, and begin using it.
5.2.2
Stationary Phase / Client Start-Up Phase
In Stationary phase, the server is running and when the MC-Mgnt-Client starts, connects to the MCMgnt-Server through a TLS-Tunnelling and requests the current keying data. 5.2.3
Keying Data Update Phase
The system needs a keying data update phase when any user is removed from the list of users with reception rights or when the full list is updated. In this phase, the MC-Mgnt-Server generates new keys and then the flow continues like in the server Start-up Phase.
6 Future Work Future work includes upgrading the system in the following ways: • Integration of Standard IPSec multicast keying data exchange. At this moment, the keying data exchange is done through SSL/TLS-Tunnelling + Multicast Notifications mechanism. When a mechanisms for interchanging of keying data for multicast groups is clearly defined in IPSec, this mechanism should be integrated in the system. • Add SSL/TLS keying data exchange into IPSec standard. For this purpose the SSL/TLSTunnelling + Multicast Notifications mechanism used in this system could be upgraded and then integrated into IPSec. • Secure transmission of Multicast notification messages. Among some of the issues to be upgraded is securing the Multicast notification messages, mainly providing authentication of the messages, through the MC-Mgnt-Server server signing them. • Integration of an Intenet-based Electronic Program Guide (EPG) interacting with with the Users-DB-Management-Tool, to provide authenticated users with an automatic electronic facility to request for specific transmissions. • Integration in the system of accounting, billing and payment modules.
7 Conclusions It has been proved that with the current technology, a system providing secure multicast pay-per-view TV transmission over Internet is possible. Different technologies have been used to achieve the identified user requirements (see section 2): • Linux-based system: The client and the server system have been implemented on a Linuxbased system.
•
•
•
•
•
•
•
Use of existing technologies: Multicast, IPSec, TLS, X.509 and RTP existing technologies have been used, both using existing tools or developing new tools using these existing technologies. Secure encrypted and authenticated transmission of audio/video data through standard protocols: IPSec has been used for encryption and authentication of the audio/video data transmitted with RTP. Support, if possible, of several encryption and authentication security algorithms: IPSec supports several encryption and authentication algorithms. In the demonstrator, ESP with 3DES encryption and MD5 authentication are used. Transmission with bandwidth optimisation: For bandwidth optimisation, audio/video data is sent using multicast (IPSec multicast) transmissions. Support for a dynamic users list, with user addition and removal: The Users-DB stores the list of the users with reception rights for each specific transmission. This DB is managed by the Users-DB-Manager-Tool, and is accessed by the MC-Mgnt-Server to know current reception rights of users. Support for a secure and dynamic mechanism for updating keying data: An innovative mechanism combining TLS-Tunnelling, for secure and authenticated keying data exchange, together with multicast notification messages, for notification of keying data updates, has been integrated in the MC-Mgnt-Server and MC-Mgnt-Client. User authentication through X.509 certificates: The TLS-Tunnelling also uses the X.509 certificates facilities for keying data update user authentication, and for billing purposes.
8 Acknowledgments The work described in this paper has been partially supported by EURESCOM in the P1107 Project [EUR-P1107] and has been developed in collaboration with Deutsche Telekom (DT) and media transfer GmbH (mtG).
9 References ESP
RFC 2406, “IP Encapsulating Security Payload (ESP)”, S. Kent R. Atkinson November 1998.
EUR-P1107
EURESCOM P1107, IP-VPN, “IPVirtual Private Networks” RFC 1112, “Host Extensions for IP Multicasting”, S. Deering, August 1989. RFC 2401, “Security Architecture for the Internet Protocol” S. Kent, R. Atkinson, November 1998. Live.com streaming media (http://www.live.com/http://live.sourceforge.net/) MIM (MIM Isn't mtv) (http://videolab.uoregon.edu/mim/) mpg123 (http://www.mpg123.de/). EXT / IETF MSEC Group, The Group Domain of Interpretation, November 21, 2001 (http://www.ietf.org/internetdrafts/draft-ietf-msec-gdoi-04.txt) EXT / IETF MSEC Group, Group Secure Association Key Management Protocol, March 2001 (http://www.ietf.org/internetdrafts/draft-ietf-msec-gsakmp-sec00.txt). Mpeg TV Player (http://www.mpegtv.com/). OpenSSL Project Documentation (http://www.openssl.org/) RFC 1889, “RTP: A Transport Protocol for Real-Time Applications”, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, January 1996. SSH (http://www.ssh.com/) SSL3, “The SSL 3.0 Protocol”, A. Frier, P. Karlton, and P. Kocher, Netscape Communications Corp., November 18, 1996. RFC 2246, “The TLS Protocol Version 1.0”. T. Dierks, C. Allen. January 1999.
IGMP
IPSEC
Live
MIM mpg123 MSEC-DoI
MSEC-Draft
mtvp OpenSSL RTP
SSH SSL
TLS
