Design and Implementation of a Secure Media Content ... - CiteSeerX

Design and Implementation of a Secure Media Content Delivery Broker Architecture Sofie Van Hoecke, Wouter Haerick, Gregory De Jans, Filip De Turck, Eric Laermans, Bart Dhoedt, Piet Demeester Department of Information Technology Ghent University, Ghent, Belgium fax: +32 9 264 9960 - tel: +32 9 264 9970 {sofie.vanhoecke, wouter.haerick}@intec.ugent.be Submitted to ISWS’05 - Technical Session on Multimedia Applications using Web Services Keywords: Web services, multimedia, broker, content delivery, security performance. Abstract— With the current evolution of applications towards distributed deployment on heterogeneous systems, possibly owned by different business players, subsystems typically interact through XML-messages (although alternatives exist) to ensure proper operation of the application. In this context the Web service technology is becoming the main player. Despite the impressive efforts to standardize Web services in all its aspects, there still is a lack of clarity in the area of security. Therefore, this paper compares security mechanisms on transport and message layer. Since Media Content Delivery (MCD) uses many services, each requiring a different security, it is difficult to build trust in the MCD architecture and thus a broker service is used with specialized algorithms to optimize the selection and security of services. The results show that secure Web services perform better using transport layer security. Nevertheless, since nonrepudation is of high importance in MCD architectures and cannot be achieved by transport layer security, a combination of transport and message layer security will be used and motivated to secure the MCD broker architecture presented in this paper. Combining SSL and WSS, a trade-off is achieved between performance and security functionality, resulting in an optimally secure architecture at low performance penalty. A proof-ofconcept architecture has been built to evaluate the security countermeasures for video content delivery.

I. I NTRODUCTION An ever increasing number of applications use the Internet to interact with each other without human intervention. By exchanging XML-messages, complying with the Web service standards, previously incompatible platforms can easily integrate. This goal of perfect interoperability has been promised before, but has rarely been achieved. In view of the broad support for Web services and common XML-based standards such as SOAP, WSDL and UDDI, Web services are a promising new concept for the integration of heterogeneous software components. Based on the exchange of structured text messages, the interaction abstracts the underlying technologies. Whereas in the past applications were obliged to set up a private connection before using remote functionality, they now can use the Internet and expose well-defined functionality as a service, which consumes and produces XML-messages over HTTP.

Integrating heterogeneous partners (e.g. content providers, Internet Service Providers (ISPs), billing and broker servers), by using Web service technology, enables the deployment of multiple promising end-to-end e-media applications. Accordingly a Media Content Delivery (MCD) architecture using the Web service technology is presented in this paper where the security aspects of the complete architecture are investigated. The remainder of this paper is organized as follows. In section 2, we summarize the related work. Section 3 gives an overview of the MCD broker architecture. In section 4 we compare security mechanisms on transport and message layer. Subsequently, section 5 motivates implementation choices for securing the MCD broker architecture, while section 6 describes the the implemented proof-of-concept architecture. Section 6 describes future work, while finally, in section 7, we will summarize the paper and give the concluding remarks. II. R ELATED W ORK A Media Content Delivery architecture imposes a lot of challenges for distributed system architects. Much of the current research effort goes into caching mechanisms and device specific content adaptation [9], [10]. These papers focus on efficient use of bandwidth, avoiding buffer underflow at client side and personalized content delivery, while security aspects are not taken into consideration. Also in the area of digital rights management valuable results have been achieved, leaving however total security also unaddressed. This paper reports research on following areas: (1) We strongly focus on the security aspects of the complete MCD architecture, starting from the security requirements of each component. To obtain maximum applicability, an authentication service is proposed that abstracts the underlying technologies. In this way both Kerberos- and PKI-authentication can be achieved. (2) To allow for maximum interoperability in a heterogeneous environment, the MCD broker architecture has been Web service enabled for the setup and control of Media Content Delivery. For the content delivery and streaming itself, existing content delivery protocols are leveraged. As

most of those protocols are platform independent, there is no need to add Web service overhead here. (3) Through a performance study we compare channel security (SSL/TLS) versus message security (WSS). The results are especially useful if performance is a key design factor which is the case for the proposed realtime Media Content Delivery architecture. III. C ASE : S ECURE MCD BROKER ARCHITECTURE The Integrated Project MediaNet [1], funded by the European Union, has the main objective to create a common open and shared delivery platform enabling the easy exchange of digital and audio-video content between creators, providers, customers and citizens. In this context a secure Media Content Delivery (MCD) architecture using the Web service technology was proposed. As illustrated in figure 1, the MCD broker architecture allows Internet Service Providers to seamlessly interconnect with any content provider platform, extending their current offerings with extensive multimedia delivery services. The broker server, sitting in between the ISP and the content providers, selects the most appropriate content provider. Therefore it owns a UDDI register containing the available services of content providers and a cache containing the service endpoints of recently requested multimedia. A service-

reveal confidential information. 4) To avoid spoofing between the business partners, mutual authentication must exist between the ISPs and the broker service. Additionally strict access control must be applied to prevent unauthorized access of multimedia services. 5) Similarly, mutual authentication must exist between the content broker and the content providers combined with an appropriate mechanism to avoid unauthorized acces. 6) Anti-replay mechanisms make it impossible for a hacker to intercept a captured content delivery request and insert changed packets back into the data stream. Adding a timestamp or nonce to the request helps to ensure that invalid packets are discarded. Nonces uniquely identifies each request by a number. 7) A proof-of-transaction should be stored at the broker to avoid discussions about billed services (nonrepudiation). To allow for pay-per-view the granularity of the proof-of-transaction must be customizable. 8) At any time the availability of the servers need to be ensured by providing lightweight inspection of incoming messages against denial-of-service attacks and messages with malicious content. IV. S ECURE M EDIA C ONTENT D ELIVERY S ETUP Web services represent a new phase in the evolution of integration middleware but still need effort to standardize in the area of security. Since security is a key element in Media Content Delivery, this document investigates Web service related standards in order to secure Web services and the MCD broker architecture. A. WSS versus SSL

Fig. 1.

Secure MCD broker architecture

oriented architecture based upon the Web service standards is proposed to permit the interconnection of heterogeneous, previously less compatible platforms. The delivery of digital content such as movies, pictures and articles requires stringent security measurements to ensure privacy of the content consumer and to protect the content to unauthorized users. The proposed MCD broker architecture therefore takes into account the following 8 security requirements: 1) The Internet Service Provider must be authenticated to the content consumer to protect the latter from server spoofing. Additionally each ISP should be able to choose its authentication mechanism without impacting the content delivery architecture. 2) At consumer side the management of keys should be simplified as much as possible. Also, key distribution should be made transparent and should not be sensitive to man-in-the-middle attacks. 3) Each content request message must be protected against altering. It must also be impossible for an attacker to

Two basic mechanisms can be distinguished for securing Web services. On one hand there is the traditional channel security where the plain-text message is sent into a secure channel. The message is thus made secure in the transport layer. On the other hand Web services introduce message-level security. Hereby the secured (signed/encrypted) message is sent over an insecure channel. The message is thus made secure in the application layer, using the XML Signature and XML Encryption specification. Channel security and message security correspond to a different security context. Since all data is sent through a protected tunnel, channel security is well suited for protection of a point-to-point communication. Once the data leaves the tunnel, protection is no longer applied and thus messages cannot stay encrypted in files or databases. Channel security is typically achieved using the well performing Secure Socket Layer (SSL) or the Transport Layer Security (TLS) protocol. Since the SOAP message model operates on logical endpoints that abstract the physical network and application infrastructure, it frequently incorporates a multi-hop topology with intermediate actors. For example, when entering the requestor’s network, a SOAP intermediary may first need to scan portions of the SOAP message header for management, routing or charging

purposes but should not be able to read the complete content since it may contain confidential information that needs to be protected against malicious intent. Transport level security however doesn’t allow to route a message securely across a Web service intermediary. The message would need to be decrypted by the intermediary before being forwarded to the ultimate receiver using a new encrypted stream. Since the Internet is accessible to the world and transport layer security is not sufficient, the content or portions of the content of the SOAP messages that are transferred over the Internet need to be encrypted and protected against unauthorized changes, the owner or sender of the messages needs to be uniquely identified and measures need to be taken against replay of the message. Fortunately, message level security allows to establish an end-to-end security context across multiple pointto-point connections so that the data remains secure until the message reaches the ultimate receiver. In addition, message security provides a way to protect only one part of the message in order to limit the overhead for encryption and decryption. Message security ensures complete independence of the underlying (insecure) transport layer.

is introduced by interpreting the Web service description and loading the certificates and classes for SOAP and WSS handling at server side. Finally the method call covers the security handshake and the method call itself. A first Web service call consists of the actual method invocation encumbered with client, proxy instantiation and server overhead. Subsequent calls only consist of the method call and optionally the proxy instantiation. Taking this into account, figure 3 shows the effective response times of the Web service calls. The distinction is made between subsequent calls with and without proxy instantiation. If one client performs multiple calls of a Web service’s method, the same proxy can be reused for all the method calls. If multiple clients call the same Web service’s method, they all have to seperately instantiate the proxy and thus the performance result of subsequent calls with proxy instantiation (see figure 3) presents the expected response time.

B. Performance results The overhead of both channel security and message security has been analyzed through a performance study for .NET Web services using SSL for transport layer security and the Web Services Enhancements (WSE) 2.0 filters and classes for Web service security (WSS) at the message layer. WSE is implemented as a pipeline architecture that modifies the SOAP envelope. When using the WSE proxy, all messages are passed through input and output filters, generating additional overhead and SOAP header tags compared to the normal proxy. This is reflected in the test results of figure 4 and 5. In order to break down the total response time into individual component contributions, the response time has been divided into four parts: client overhead, proxy instantiation, server overhead and method call (see figure 2). The client overhead

Fig. 2. Separated overhead response time results for small-sized messages (10 bytes)

consists of loading certificates and classes for the SOAP, SSL and/or WSS handler. The proxy instantiation covers the security set-up and XML marshalling. The server overhead

Fig. 3. bytes)

Response times of subsequent calls for small-sized messages (10

WSE supports the ability to encrypt portions of a SOAP message. When encrypting a SOAP message using WSE, the entire content of the SOAP body element is encrypted unless explicitly specified otherwise. The extra code needed for partial WSS in the WebMethod to set the OASIS Id that the security reference will point to, is more time consuming for the server. This can be seen on figure 2. Figure 3 shows no differences in subsequent response times for small-sized messages using WSS full or partial encryption. For increasing message size, one can see in figure 4 that partial encryption generates less overhead (e) than full encryption (d) since only few parameters needs to be encrypted instead of the total amount of data. The number of encrypted bytes in partial encryption is kept constant for increasing message size. Nevertheless this overhead is still remarkably higher than for SSL encryption (f). Noteworthy in figure 4 is the large offset caused by the overhead of digitally signing the message (a). Test results, presented in figure 5, show the influence of different security mechanisms on the SOAP header size. One can see here that digital signatures are still verbose and create SOAP headers more than twice the size of the SOAP headers for encryption.

Fig. 4.

Overview of response times for increasing message size and different security mechanisms

This way extra XML parsing and processing has to be done, resulting in a larger overhead.

exchanging multimedia content and services, it is extremely important (e.g. for billing purposes) to guarantee that the requestor cannot deny having sent the request. Only the less performing WSS can achieve this security functionality through digital signatures. Therefore a trade-off between performance (SSL) and security functionality (WSS) has to be made in order to secure the MCD broker architecture to the best. Although all security functionality can be provided by WSS solely, figure 4 indeed confirms that the best results of total response time are achieved by combining SSL for encrypting and WSS for digitally signing the messages. V. MCD BROKER ARCHITECTURE

Fig. 5. Influence on size of SOAP header for different security mechanisms

C. Trade-off between performance and security functionality As can be seen in the test results above, secure Web services perform better using SSL, thus using transport layer security, instead of WSS message level encryption. Since SSL is more mature, tools are already optimized to provide this security technology. Although less efficient, WSS has its own advantages such as the independence of the transport layer, the possibility to secure data over multiple SOAP hops and the protection against repudiation. Despite the attractive features of Web service Security at message-level, almost all current Web service implementations still use the better performing SSL as a security solution. This is mainly due to two reasons: • a lot of the real-world scenarios consist of multiple pointto-point interactions, which can be easily secured with SSL (hopping is not always a requirement) • SSL is a well-known, proven and well performing solution Using SSL can ensure confidentiality, authentication and integrity. Nevertheless it is also important to accomplish nonrepudiation in a MCD architecture. When multiple partners are

It is important that a safe information exchange can be ensured among all the partners of the MCD architecture. In order to accomplish the security requirements as stated in section III, multiple security mechanisms have been chosen to secure the complete architecture, thereby taking into account the results of the performance study in section IV-B and the set of security countermeasures covered by each of the security techniques. It is certainly not the goal to overload the architecture with the strongest possible security defense mechanisms for each communication link. On the contrary, by studying the security requirements for each of the links of the content delivery architecture the minimum required security is proposed. Extension points are defined to allow for even higher protection. However, these extensions will typically come at a performance cost and often also at a reduced user friendliness. A. Content delivery set-up Figure 6 illustrates the proposal to secure the content delivery request and reply messages: • An SSL/TLS connection with one-way (1w) X.509 server authentication, combined with WSS containing a password-token inside the header block, to be used between the content consumer and the ISP. The WSS header is further extended with a nonce and a timestamp. • An SSL/TLS connection with two-way (2w) server authentication, to be used on one hand between ISP and

content broker and on the other hand between the broker and the content providers. The channel security is extended with a nonce, timestamp, digital signature and access control assertions in the WSS header.

Fig. 6. Secured MCD Broker Architecture, combining channel and message security

1) Server-only authentication between consumer and ISP: Similar to the current e-commerce transactions, a https connection is proposed with a server certificate to prove the authenticity of the ISP to the content consumer and to avoid server spoofing (requirement 1). Mutual authentication is achieved by adding a password token to the security header of each SOAP message, sent over the SSL-secured channel. While the identity of the ISP is guaranteed by the X.509 certificate, which binds the public key to the ISP (such a guarantee is not strictly enforced with respect to the content consumer). This allows any user of an ISP to join the content delivery service without the need to buy certificates and avoids the management of certificates on end-user side (requirement 2). ISPs are free to foresee a stronger authentication mechanism to identify their customers or to adopt upcoming identification solutions as smart cards, e-identity cards, etc. These possible extensions will not impact the behavior of the media content delivery architecture. 2) Generic authentication server for ISP, content broker and content provider: The deployment of the proposed, distributed media content delivery solution will require investments from all business partners involved. A profitable model is therefore needed that prevents content piracy and builds upon strong business-to-business relationships between ISP’s and the content broker, as well as between the content broker and the content providers. Also, as those partners will be involved in high-volumes of billable content requests, mutual authentication becomes a strict requirement. Considering the performance gain of channel security compared to message level security, SSL/TLS with mutual authentication is chosen to protect the communication between the business partners (requirements 4 and 5). To be able to charge the delivery of digital content, it should be impossible for a content consumer to deny the delivery of requested content (non-repudiation). Therefore the storage of a proof-of-transaction is required at the content broker server.

As a proof-of-transaction it is sufficient to store a decrypted message which still includes a digital signature of the complete message. In the proposed MCD architecture this implies that the authenticity of the signature is guaranteed by the ISP. The digital signature then not only ensures integrity (requirement 3) but also non-repudiation (requirement 7) as the identity of the originator is now linked to an unaltered message. As nonrepudiation is not supported by channel security, the proposed solution combines SSL/TLS security with digital signatures encapsulated in a Web service security (WSS) header. To further allow pay-per-view, the content consumer is able to send proof-of-transaction messages to the content broker on receipt of each media segment. The length of the media segment could be made a function of the strength of a content encryption algorithm. For example, if a stronger encryption algorithm is applied (e.g. by choosing larger encryption keys), the media segments can be longer as it is harder to compromise the encryption key. To prevent the reuse of keys by resending an earlier processed request message, the WSS headers also need to include a timestamp and a nonce. Using a caching mechanism, the broker server should verify for each incoming request if the message has already been processed (requirement 6). Here, a lightweight verification method is needed to ensure the availability of the server in case a flood of replayed messages is received (requirement 8). As to prevent authenticated users to access restricted Web services, the WSS header is furthermore extended with XACML [2] access control assertions (requirements 4 and 5). With its common XML-based language for expressing access policies, XACML contributes to the interoperability of the proposed architecture.

Fig. 7.

Security chain at the content broker server

To acquire the authentication credentials to establish the SSL/TLS connection, the proposed architecture features a generic authentication server. This Web service enabled server has an open interface to allow issueing different types of

security tokens. To promote interoperability between the business partners, at least the two most common authentication mechanisms, Kerberos ticketing and X.509 certificates, must be supported. For X.509 certificates, a proposal exists for XML-based token issuance and token validation through an open interface, namely, the X-KRSS and X-KISS components of the XML Key Management Specification currently being standardized under the W3C [3]. Microsoft and IBM are also working on a specification, WS-Trust [4], which allows to transform an authentication request according to the requirements of the target service. As both specifications are still in draft phase and WS-Trust only applies to message security, the proposed architecture currently only features Kerberos ticketing for the SSL authentication. The Kerberos protocol allows for authentication across different Kerberos security domains. To support a next level of interoperability, two extension points are defined: (1) A translation service that enables the transformation of one authentication message into another one, e.g. to transform an X.509 certificate into a kerberos ticket; (2) Authentication across different trust communities, each with at least one trusted, generic authentication server. B. Content delivery Once the content consumer receives a successful reply on its content delivery request message, the content delivery starts using proven UDP-based content delivery protocols as H.263 Baseline [5], MPEG4 [6], AMR [7], etc. To protect these UDP streaming, IPsec [8] is proposed which imposes encryption at the IP-layer. As an alternative, videostreams could be encrypted in advance and stored as a cipherstream. Although this reduces the needed processing power at transfer time, it requires decryption to be performed on application level. Consequently, this would lead to non-interoperable mediaplayers, as the currently implemented video standards do not yet support a common way to interpret the encryption metadata of an encrypted mediastream. Therefore, the demo architecture uses IPsec to protect the content delivery. C. Content control messages and proof-of-transaction Apart from the content request message and the content delivery, a secure way of communication needs to be available for control messages (pause, zoom, ...) and proof-oftransaction messages. Control messages can be easily sent on the established IPsec-channel. Proof-of-transaction messages, however, are delivered to each business partner by means of Web service interfaces, secured with a special WSS header block containing a timestamp and a digital signature. Nonrepudiation is thus enforced as a result of the digital signature, which links message integrity with an identity and the corresponding public key. This way correct billing can be assured. As will be described in section VII, our future research will extend the proof-of-transaction messages to contain tags for providing Quality of Service (QoS) to the architecture.

D. End-to-end security Note that end-to-end security, applied on the application level, between content consumer and content provider is not a viable option as this would require a direct trust relation between the content consumer and a possibly high number of content providers. The client application should in that case be able to manage the distribution, secure storage and usage of a huge number of signature and encryption keys, which contradicts the requirement to keep key management as simple as possible at consumer side. E. Key establishment The strength of a cryptographic system rests with the key distribution technique [12]. If a private key or shared secret gets compromised during initial distribution, it does not matter anymore if a weak or strong encryption mechanism is used. In fact, three ways for key distribution can be distinguished: • Physical delivery of a new key: A newly generated secret key is physically delivered from one party to the other or from a third party (e.g. an authentication server) to two partners that wish to communicate. This is the recommended way for distribution of initial keys between the authentication server and MCD business partners, especially given the relatively low number of business relations that need to be established per business partner. In the case of Kerberos authentication each partner needs to share one secret key with the Key Distribution Center (KDC). Similarly, using X.509 certificates it is sufficient to distribute one private key, and the corresponding certificate, to each partner involved. Note that in the latter case, a partner can also locally generate the private and public key. This avoids the distribution of a private key while a certificate, which is solely based on the public key, can still be issued at a certificate authority (CA). • Delivery of a new key encrypted with an older key: A new key can securely be distributed by using an existing, secured communication channel which has earlier been established to secure other applications. This type of distribution is also recommended for the re-issuance of keys. • Delivery of a new key in plain text: For free services on the web, it is common practice to authenticate a user based on his e-mail address. The shared secret (e.g. a password) is sent in plain to the user’s e-mail box. Here, a tradeoff has to be made between the cost of additional security compared to the possible loss of revenue as a result of the higher security risk. In the case of free (or cheap) services or if the security risks are considered very low, it is not worth to invest in costly security mechanisms. VI. I MPLEMENTATION The proposed architecture has been implemented using the .NET technology and currently includes one content consumer, an ISP server, a broker server, an authentication server and two content servers, each deployed on a separate machine.

The UDDI server, needed by the broker server to look up the services registered by the content providers, is deployed on the same machine the broker server is running on. The demo architecture currently only features video content delivery services. For the content delivery a VLC server and player has been integrated and made accessible through web service interfaces. Video streaming uses the RTSP protocol over UDP and is made secure through IPsec. The generic authentication server currently features Kerberos ticketing for SSL authentication, while WSE 2.0 is used for digitally signing the messages. All eight security requirements are fulfilled in the proof-ofconcept architecture. Through a client GUI, including the web service proxies, one can search a videostream and start the downloading if the content is available. VII. F UTURE WORK The proposed Media Content Delivery architecture assumes that all business partners have established a trust relationship with a common authentication server. Partners trusted by another authentication party can only join if a trust relation exists between their authentication server and the MCD authentication server. This type of brokering of trust between different authentication servers, and thus different trust communities with possibly different security token formats, will increase interoperability but requires additional research on a common protocol and unambiguous security token semantics. In this context it will be beneficial if all authentication servers feature the Token Translation Service and a Proof Arbiter to avoid repudiation in even more complex, federated trust communities. Additionally, the proof-of-transaction messages used in the proposed architecture will be extended with extra tags to allow for feedback on the Quality of Service (QoS) to the architecture. This way partners can agree a QoS policy assuring for example bandwidth, lowest price or video quality. Based on the QoS requirements encapsulated in the client request, the broker will select different or even plural content providers to meet these requirements. Furthermore the broker can reject a content provider from further cooperation if the content provider doesn’t meet with the agreed QoS boundaries. Adding QoS to the architecture will thus improve the service quality of Media Content Delivery. VIII. C ONCLUSION The advent of Web services, a set of technologies that promises a high level of interoperability and usability, is often put forward as the ideal foundation to build integration architectures. In this paper we have described how the Web service standards can fulfill the requirements for a Media Content Delivery architecture, integrating different partners like content providers, Internet Service Providers, billing and broker servers. Since security is a key element in MCD, this paper has investigated security mechanisms on both transport and message layer. The results of the performance study show that secure Web services perform better using SSL for encryption. Nevertheless, transport layer security lacks options to prevent

non-repudation. Therefore WSS is used to digitally sign the messages. The test results prove that this combination of both SSL and WSS is optimal to secure the MCD architecture. On top of that a generic authentication server is used in the architecture to further promote interoperability. ACKNOWLEDGEMENT This work was partly funded by the european commission through the IST project MediaNet. Sofie Van Hoecke would like to thank the Institute for the Promotion of Innovation through Science and Technology in Flanders for financial support through her Ph.D. grant. R EFERENCES [1] IST Medianet, http://www.ist-medianet.org. [2] OASIS, http://www.oasis-open.org/committees/download.php/2406/oasisxacml-1.0.pdf, XACML version 1. [3] W3C, http://www.w3.org/TR/xkms, XML Key Management Specification. [4] WS-Trust specification, ftp://www6.software.ibm.com/software/developer/ library/ws-trust.pdf, version 1.1. [5] International Telecommunication Union (ITU), Recommendation H.263, http://www.itu.int/rec. [6] R. Koenen, Overview of the MPEG-4 Standard, ISO/IEC, March 2002. [7] 3GPP, 3GPP TS 26.071: AMR Speech Codec, December 2004. [8] S. Kent, IP Encapsulating Security Payload, IETF-IPsec Working Group, September 2004. [9] T. Yohimura, Y. Yonemoto, Mobile streaming media CDN enabled by dynamic SMIL, WWW2002, May 7-11, 2002. [10] R. Rejaie, H. Yu, Multimedia Proxy Caching Mechanism for Quality Adaptive Streaming Applications in the Internet, Proceedings of INFOCOM 2000, March 2000. [11] M. Lorch, S. Proctor, First experiences using XACML for access control in distributed systems, ACM Workshop on XML Security, October 31, 2003. [12] William Stallings, Cryptography and network access, Prentice Hall.