Towards multi-user personalized TV services, introducing combined RFID Digest authentication

Transcription

1 Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek / Netherlands Organisation for Applied Scientific Research ONGERUBRICEERD TNO report RA Towards multi-user personalized TV services, introducing combined RFID Digest authentication Date 10 December 2009 Author Supervisors Ray van Brandenburg Dr.ir. Georgios Karagiannis, University of Twente Prof.dr. Hans van den Berg, University of Twente Dr.ir. M. Oskar van Deventer, TNO-ICT Ir. Mike Schenk, TNO-ICT Project number Key words Prsonalisation, multi-user, television, IMS, IPTV, EPG, SIP, Digest, RFID Summary This is a master thesis. It focusses on the paradox between personalization and the concurrent use of television by multiple users. A use case analysis shows that personalization and multi-user are not mutually exclusive. One use case was technically implemented: a combined electronic program guide for multiple users that use RFID to log in on their TV service. All rights reserved. No part of this report may be reproduced and/or published in any form by print, photoprint, microfilm or any other means without the previous written permission from TNO. All information which is classified according to Dutch regulations shall be treated by the recipient in the same way as classified information of corresponding value in his own country. No part of this information will be disclosed to any third party. In case this report was drafted on instructions, the rights and obligations of contracting parties are subject to either the Standard Conditions for Research Instructions given to TNO, or the relevant agreement concluded between the contracting parties. Submitting the report for inspection to parties who have a direct interest is permitted TNO ONGERUBRICEERD

2 Master Thesis Faculty of Electrical Engineering, Mathematics and Computer Science, Design and Analysis of Communication Systems (DACS), University of Twente Towards multi-user personalized TV services Introducing combined RFID Digest authentication Ray van Brandenburg, August 31, 2009 Supervisors: Dr.ir. Georgios Karagiannis, University of Twente Prof.dr. Hans van den Berg, University of Twente Dr.ir. M. Oskar van Deventer, TNO-ICT Ir. Mike Schenk, TNO-ICT

3 2 / 97 Abstract In recent years, TV has become increasingly focused on personalization and individualization. This trend is slowly diminishing the traditional use of TV as a concurrent medium; one that is shared by multiple viewers sitting on the couch next to each other. We should therefore be careful that with the increasing focus on the individual experience, the collective experience, and with it the social component of TV, is not lost. The fact that a recent IPTV architecture, IMS-based IPTV, does not even take the multi-user scenario into account, only further supports this notion. The question therefore is: Are personalization and concurrency necessarily contradictory? This document tries to answer this question, both from a use case perspective and from a technical point of view. A set of multi-user use cases is presented that show that there are in fact applications imaginable that combine the two concepts of personalization and concurrency in a way that they complement and reinforce each other; resulting in applications that provide users with personalized services while reinforcing the social and collective component of watching TV. When trying to implement these new types of use cases, however, it becomes apparent that current IMS-based IPTV identification and authentication mechanisms are not flexible enough to support concurrent use in a way that results in a user-friendly system. To solve this problem, a new identification and authentication mechanism, called RFID Digest is presented. This system, which is based on the use of personal RFID cards, is developed in a way so that it doesn t require any changes to the server side of the IPTV architecture, allowing for seamless integration in existing infrastructure. Apart from the development details of RFID Digest, an evaluation of its properties is also presented. This evaluation consists of two parts: an assessment of RFID Digest s security level, which shows it to be comparable to other IMS authentication mechanisms, and a brief survey into the impact of RFID Digest on total TV access times, which shows this effect to be minimal. Finally, to show that multi-user personalized services using RFID Digest are not only possible in theory but also in practice, a proof-of-concept prototype will be presented.

4 3 / 97 Table of Contents Abstract... 2 Table of Figures... 6 List of Abbreviations Introduction Project background Research questions Document outline Introducing multi-user television Individual experience versus collective experience Current IPTV use cases New multi-user use cases Interactive TV show Personal EPG/Channels Multi-user social TV Conclusion Identification requirements Summary Identification in IMS-based IPTV Understanding IMS IMS identifiers Authentication in IMS IMS AKA NASS-bundled Authentication SIP Digest Conclusion Introducing RFID Digest Different solutions possible Using RFID RFID in general Different approaches possible Understanding Mifare Classic Mifare Classic memory organization Command set Security features Access conditions Developing RFID Digest... 37

5 4 / IMPI/IMPU storage considerations Complications with the Mifare Classic Storing IMS identifiers on Mifare Classic Keys and access conditions Authentication through SIP Digest Summary RFID Digest security considerations Understanding the security context Defining security domains Vulnerabilities of SIP Digest Security of shared secret Moment of detection Message confidentiality and integrity General RFID vulnerabilities Cloning of RFID cards in general Cloning the Mifare Classic and possible solutions Specific RFID Digest vulnerabilities Conclusion Performance evaluation Current practices What is considered acceptable? Performance impact of RFID Digest Prototyping multi-user TV using RFID Digest Deciding on a use case Deciding on a general structure Availability of IMS-based IPTV Replacing IMS nodes Client-side structure Detailed design RFID Handler Video component IP Communication block EPG Handler Overview Demonstration Conclusions & Future work References... 85

6 5 / 97 Appendix A Authentication in IMS Appendix B RFID... 94

7 6 / 97 Table of Figures Figure 1: TV over time Figure 2: Use cases in TS Figure 3: Two examples of what a multi-user interactive TV show might look like. The different colored icons represent different users playing Figure 4: An example of a personalized EPG. The picture on the left shows the channel order if the red user ("Tim") is logged in, while the picture on the right shows the channel order when the yellow user ("Paul") is logged in Figure 5: An example of what a multi-user social TV application might look like. The two logged in users ("Tim" and "Rick") each keep their own buddy lists Figure 6: IMS overview (from (Hunter, Clark, & Park, 2007)) Figure 7: Relationship between different IMS identifiers (from (ETSI TISPAN, 2008)). In this diagram, a subscription is shared by two users, both having their own IMPI. Each of these IMPIs is linked to a personal IMPU, with a third IMPU being shared by both users. This third IMPU can for example be used for a shared family telephone Figure 8: Multiple users per UICC Figure 9: Single user per UICC Figure 10: Different types of RFID Figure 11: Overview of RFID Digest Figure 12: Mifare Classic 1K memory organization Figure 13: Mifare Classic manufacturer block organization Figure 14: Mifare Classic sector trailer organization Figure 15: Mifare Classic data block versus value block Figure 16: Mifare Classic sector trailer state transition diagram Figure 17: Mifare Classic data access condition Figure 18: Overview of RFID Digest Figure 19: Use credentials storage requirements Figure 20: Overview user credential storage on Mifare Classic 1K Figure 21: Overview of RFID Digest message flow Figure 22: Categorizing security vulnerabilities Figure 23: Security domains in the internet world. Circles represent different security domains Figure 24: Security domains in the mobile telephony world Figure 25: TV Boot times survey Figure 26: MOS Scale Figure 27: Configuration of test parameters (number of testers on the left, boot delays on the right) Figure 28: One test event. From top left to bottom right: the TV in standby mode (1), the TV boot delay (2), the TV in on mode (3) and the TV in standby mode again (4)

8 7 / 97 Figure 29: Acceptability of boot delays Figure 30: Mifare Classic transaction times Figure 31: Overview of RFID Digest Figure 32: Structure of multi-user personal EPG prototype Figure 33: Server-side block diagram Figure 34: Client-side block diagram Figure 35: RFID block diagram Figure 36: Complete block diagram Figure 37: Screenshot of RFID Editor Figure 38: EPG Database Figure 39: An example of an EPG package Figure 40: Visualized EPG data. The red band indicates that the specific channel is adult only and is removed when children are present Figure 41: Client-side block diagram with interconnections Figure 42: RFID-related block diagram with interconnections Figure 43: Server-side block diagram with interconnections Figure 44: Demonstration step Figure 45: Demonstration step Figure 46: Demonstration Step Figure 47: Demonstration Step Figure 48: Demonstration Step Figure 49: Demonstration Step Figure 50: IMS AKA message flow overview Figure 51: SIP Digest message flow overview Figure 52: NASS-bundled Authentication message flow overview Figure 53: IMS Residential Gateway message flow overview Figure 54: Different types of RFID... 95

9 8 / 97 List of Abbreviations AKA ALU CA CRC CSA CSCF DRM DVB (C/T/H/S) EPG ETSI GUI HSS I-CSCF IMEI IMPI IMPU IMS IMSI IPsec IPTV ISP ITU MOS MSISDN NAI NASS NBA PCD P-CSCF PICC QoE RF RFID RTP RTSP S-CSCF SIM SIP ST STB TISPAN TLS UICC URI Authentication and Key Agreement Arithmetic Logic Unit Conditional Access Cyclic Redundancy Check Common Scrambling Algorithm Call Session Control Function Digital Rights Management Digital Video Broadcasting (Cable/Terrestrial/Handheld/Satellite) Electronic Program Guide European Telecommunications Standards Institute Graphical User Interface Home Subscriber Server Interrogating Call Session Control Function International Mobile Equipment Identity IMS Multimedia Private Identity IMS Multimedia Public Identity IP Multimedia Subsystem International Mobile Subscriber Identity IP Security Internet Protocol Television Internet Service Provider International Telecommunication Union Mean-Opinion-Score Mobile Subscriber ISDN Number Network Access Identifier Network Attachment Subsystem NASS Bundled Authentication Proximity Coupling Device Proxy Call Session Control Function Proximity Integrated Circuit Card Quality of Experience Radio Frequency Radio Frequency Identification Real-time Transport Protocol Real-time Streaming Protocol Serving Call Session Control Function Subscriber Identity Module Session Initiation Protocol Sector Trailer (Mifare Classic) Set-Top-Box Telecoms & Internet converged Services & Protocols for Advanced Networks Transport Layer Security Universal Integrated Circuit Card Uniform Resource Identifier

10 9 / 97 1 Introduction People have been watching TV for over 60 years. For most of that time, not much changed. Black-and-white TV became color TV and the number of channels increased from only a few to several hundred but the general concept of watching TV remained the same; a passive activity which one could enjoy with friends and which everyone experienced in the same way (since everyone received the same channels). Only in the past decade, with the introduction of new TV architectures and business models such as subscription TV, digital TV and IPTV, have there been any major changes to the experience of watching TV. The most notable concept these architectures have introduced is an unmistakable trend towards personalization or individualization; no longer is TV an anonymous and homogenous medium, the experience depends on the identity of the person (or subscriber) watching. With the introduction of personalization the focus of TV services and applications is also changing, with an increasing focus on the single-user scenario; the situation where a single user is watching TV by himself. This is a change from the traditional multi-user scenario, where multiple family members or friends are often watching TV together, simultaneously (concurrently). This change can best be observed when looking at IPTV architectures. The identification mechanisms provided by these architectures, which form the basis for personalization, are exclusively aimed at the single-user scenario. At this moment it is unclear in what way these architectures can be made to handle the situation of multiple users sharing a TV. Even more importantly, it is unclear if and how the two concepts of personalization (which is by definition aimed at the individual experience) and concurrency (which is aimed at the collective experience) can be combined in the first place. The aim of this project is to look into these two problems with the final goal being the development of an identification system designed with the multi-user scenario in mind. With such a system, a completely new type of application, one that combines personalization with concurrency, can be built. 1.1 Project background This project has been carried out at TNO, the Dutch Organization for Applied Scientific Research. The goal of TNO is to apply scientific knowledge with the aim of strengthening the innovative power of industry and government. TNO is divided into five core branches, one of which is Information- and Communication Technology (TNO-ICT), the branch at which this project was carried out. In the area of IPTV, one of the points of focus for TNO-ICT is the IMS-based IPTV architecture. IMS-based IPTV is based on the IP Multimedia Subsystem (IMS), which is a session control framework for delivering multimedia services. TNO takes part in the standardization process of IMS-based IPTV which is currently being carried out by the Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) standardization body of the European Telecommunications Standards Institute (ETSI). One of the requirements set by TNO for this thesis assignment is to use IMS-based IPTV as the primary IPTV architecture within this project. Apart from this imposition there are also technical reasons to use IMS-based IPTV instead of other architectures. The most important of these is the fact that IMS, which forms the foundation for IMSbased IPTV, features a very extensive identity management framework; which is of course very useful in the context of this project.

11 10 / Research questions The goal of this project is to develop an identification system that can be used to identify multiple users sharing a TV. This goal is captured in the following main research question: How can one develop a secure, fast and user-friendly multi-user TV identification system? In order to properly answer the different components of the main research question, it has been divided into six sub questions. 1. To what extent is the recent trend of personalization in TV unifiable with the traditional situation of the TV being used as a concurrent medium? To understand the problems encountered by multi-user television, it is important to first know how the two seemingly contradictory concepts behind it, personalization and concurrency, are currently being combined in IPTV architectures and if this combination is even possible at all. 2. Is it possible to re-use the identification mechanisms provided by current IPTV architectures for multi-user scenarios? The most ideal situation would be if the identification and authentication mechanisms already used by IPTV architectures would be able to support multi-user scenarios as well as the current single-user scenarios for which they were developed. Multi-user identification, however, has a number of requirements not found in single-user identification. 3. What would be a user-friendly and flexible form of identification? Should it become apparent that current identification mechanisms do not meet multi-user requirements, then a new form of identification should be developed. This hypothetical new type of identification should be flexible enough to support a wide variety of situations and on top of that be userfriendly. 4. How can IMS s standard identifiers be mapped to this new form of identification? Whatever method is chosen to provide multi-user identification, it should be able to incorporate IMS s set of standard identifiers. 5. How can the new form of identification be integrated into IMS-based IPTV in a secure way? A new form of identification should be able to integrate itself in the existing IMS framework. Therefore some form of connection should be made between them. This connection should be at least as secure as the ones used by other forms of identification, in order not to make it into a vulnerability to the IMS framework. 6. In what way does the proposed system affect total system access time? And related, to this: What are acceptable times for TV systems in general? To evaluate the performance of the proposed identification system, the total system access time should be measured. In order to put this measurement in the right perspective, some research should be done to determine what access times are acceptable in the TV world. 7. Which use case is most appropriate for demonstrating a multi-user TV application?

12 11 / Document outline An attractive use case should be found that shows off the most important features of the new-to-be-developed identification system. This use case can then be included in a prototype that demonstrates the total system and its advantages over existing identification systems. The remainder of this document is organized as follows. After the introduction of the two concepts of personalization and concurrency, Chapter 2 deals with the question in how far these two concepts are contradictory. To answer this question current architectures are discussed and a number of specific multi-user use cases are presented. In Chapter 3 an analysis is made of the identification and authentication methods of IMS-based IPTV. This information is used to get an idea to what extent IMS-based IPTV supports the requirements of multi-user TV. Chapter 4 deals with the development of a new identification method specifically designed for multiple users of the same TV. After the design of the new identification method has been completed, Chapter 5 will look at its potential vulnerabilities in the area of security. An evaluation of the performance of the new identification system is given in Chapter 6, together with some research into TV access times in general. In Chapter 7 a prototype of a multi-user application that incorporates the newly developed identification system is presented. Chapter 8, finally, presents the conclusions of this thesis assignment and presents a number of recommendations for future work.

13 12 / 97 2 Introducing multi-user television The goal of this chapter is to answer the first of the research questions: 1. To what extent is the recent trend of personalization unifiable with the traditional situation of the TV being used as a concurrent medium? In order to do so, Section 2.1 starts with a brief historical perspective, introducing personalization and concurrent use. Section 2.2 then proceeds with an analysis of how current IPTV architectures deal with these two seemingly contradictory concepts. In Section 2.3 a number of new multi-user use cases are presented. Section 2.4, finally, uses the use cases presented earlier to obtain a set of requirements for multi-user identification. The chapter finishes with a short summary and a conclusion that discusses how to proceed from here. 2.1 Individual experience versus collective experience When analogue TV (PAL, NTSC, SECAM (International Telecommunication Union)) was introduced more than fifty years ago, it was delivered over the air using antennas. In these times, there was no form of identification or authentication whatsoever; there was no way for the TV broadcasters to know how many TVs or users would be receiving their signal. This also meant that TV set owners could receive TV channels free of charge. Analogue cable TV introduced an early form of authentication; the physical connection from TV to provider. It was now possible for TV broadcasters to offer bundles of television channels to individual households. Still, it was not possible for the TV providers to know how many actual TVs were connected to their signal, since subscribers could easily split the signal. The introduction of scrambling of analogue signals and the associated decoders marked the first time real authentication was available in the TV world. This allowed TV broadcasters and content providers with a system to more effectively control subscriptions to television channels; it was no longer possible to split signals without permission of the provider. These systems also allowed for the first time a form of personalization; households could subscribe to individual channels or packages of channels, meaning that for the first time, not everyone in the same street (or even in the same building) received the same TV channels. Digital TV and mobile TV improved on this with more advanced forms of encryption, conditional access (CA) and digital rights management (DRM). Examples of these are DVB-C (Digital Video Broadcasting), DVB-T (Digital Video Broadcasting), DVB-H (Digital Video Broadcasting) and DVB-S (Digital Video Broadcasting) for cable, terrestrial, handheld and satellite access respectively. An integrated return channel, however, was still not available, meaning that there were some limits to the functionality of the identification and authentication processes. In parallel to these developments in the area of subscription TV, early forms of interactive TV were introduced. By using a separate return channel, not linked to whichever TV access technology was used, customers were for the first time able to interact with TV shows. In the beginning, this return channel was the telephone line. Later SMS and the internet became the return path of choice. A present day example of this kind of technology is SMS voting on popular TV shows such as Idols and Big Brother. In a sense, SMS voting is the first example of user identification in the way that it is sent using a mobile telephone and a mobile telephone number. The mobile telephone number is a perfect example of an identifier that can be used to uniquely identify a single user.

14 13 / 97 While subscriber TV and interactive TV have been separate developments towards personalization for quite some time, the two are growing towards each other in a relatively new technology called IPTV (see Figure 1). The distinguishing feature of IPTV is that both the subscribed content delivery and the interactivity are provided over one and the same IP network. This integration enables more advanced use cases using true user identification without requiring additional access technologies. Social TV (Boertjes, Klok, Niamut, & Staal, 2009) is an example of a type of application that uses these new features. It combines the regular television experience with social contact, such as exchanging text- and video messaging, sending content recommendations and sharing TV presence status between users sitting at different TVs. Watching apart, together is a good way to describe the TV experience brought by Social TV. As personalization becomes more and more important, so is watching TV becoming more and more of an individual/personal experience. Figure 1: TV over time On the other hand, TV has traditionally been a medium for concurrent use; a medium that is enjoyed by multiple users at the same time. Concurrency is intrinsic to the TV experience. The situation where multiple family members watch TV together in the evening in the living room is recognizable by many. Big sports events broadcast on TV are often also social events, in which groups of friends get together to watch them collectively. This shows that TV has always had a social component and that the collective experience is an important element. In a way, the introduction of Social TV reinforces this; apparently there is a need for users to share the TV experience; if not with users sitting next to them, then with users sitting elsewhere. The trend of personalization on the one hand and the traditional practice of concurrent use on the other seem contradictory, since one is aimed at the individual experience and the other at the collective experience. It is important to check whether this is indeed the case, because it would be a shame if the introduction of personalization would mean that we would slowly lose the social element of enjoying TV together with family and friends. On the other hand, if new use cases could be thought up that do successfully combine personalization with concurrency, a completely new type of application could be built that incorporates the best of both experiences. The answer to the first research question, as presented at the start of this chapter, lies in finding out if the hypothesis that personalization and concurrent use are contradictory is valid. The first step to this answer is finding out how current IPTV architectures deal

15 14 / 97 with concurrency. For this reason the next section will check the blueprints of these architectures: the documents detailing the use cases and thus the requirements. 2.2 Current IPTV use cases To see in how far the combination of personalization and concurrent use has been taken into account in current TV architectures, this section will look at the use case documents of some standardized IPTV architectures. The reason use case documents are being checked here instead of documents describing the technical details of the architectures is that use cases documents often function as a form of blueprint. They show the goals and intentions of the designers. Of course it is not true that if a use case document does not explicitly mention a specific requirement that the final architecture does not meet this requirement; however, it does show that the architecture was not built with that specific requirement in mind and it was therefore probably not considered particularly important. What we will do in this section is look at the use case document of IMS-based IPTV and see if there are any references to multi-user scenarios or concurrency. As discussed earlier, IMS-based IPTV is intrinsically suited to personalized services due to its advanced identity management framework. There are two other major IPTV architectures: Integrated IPTV (ETSI TISPAN, 2008) and DVB-IPTV (Digital Video Broadcasting). DVB-IPTV does not currently feature an identity management component at all, so at this point it is useless to consider this architecture in the context of this project. Integrated IPTV, which is standardized by ETSI TISPAN in conjunction with IMS-based IPTV, shares its use case document with IMS-based IPTV; so by examining this document, it is possible to draw conclusions for both architectures. By analyzing the document in question, TS (ETSI TISPAN, 2009), it is possible to get a good idea of the focus of IMS-based IPTV and Integrated IPTV. Which types of use are included and which are considered most important? The central question of course is, to what extent has concurrent use been taken into account? To answer these question we will take each and every use case described in TS and put it into one of the following three groups: use cases for single users or arbitrary numbers of users, use cases for multiple users at different TVs (one per TV) and use cases for concurrent use (multiple users at one TV). An example of a use case in the first group is traditional broadcast TV. While one could argue that broadcast TV is also perfectly suited for multiple users sharing a TV, this is not what the use case is explicitly designed for. Broadcast TV is designed for an arbitrary number of users; the use case does not depend on the number of users present. For this reason it is categorized in the first category. For the Electronic Program Guide (EPG) use case, similar arguments hold. TS also features a large number of video-on-demand-like use cases, each one for a slightly different situation and within a different context but all sharing the basic concept of a user receiving personalized video content. These use cases include payper-view, content-on-demand, personal-video-recording etc. All these use cases can be placed in the single user category for the same reason as stated above for broadcast TV: the use cases do not depend on the number of users present. Another group of use cases are the ones that fall under the Social TV banner. TS features a wide variety of such services. Among them: presence, watching apart together, content recommendations and sharing the remote control. These are use cases that show just how important the social component is for the TV experience; they are developed specifically for the situation in which users are alone but still want social contact. The use cases provide this contact by getting the user in touch with other users

16 15 / 97 (friends or family) who are also watching TV by themselves. These use cases are placed in the multiple users at different TVs category. A final use case that can be found is incoming call management. This use case is a perfect example of the advantages of IMS-based IPTV being based on the multi-domain IMS framework. It allows one to receive notifications of incoming mobile phone calls on his/her TV. While a wonderful example of personalization, it is also an example of a strictly single user use case. For a good overview of all the different use cases presented in TS , Figure 2 lists them in a convenient diagram. Figure 2: Use cases in TS When one looks at the table above, one thing is clear: the fact that no use cases or services were found that are explicitly meant for concurrent use. When one delves somewhat deeper into the requirements document, a single line can be found that does refer to this situation. This line, which is related to the presence use case, is the following: The interactive IPTV solution shall allow multiple users in front of one TVset to communicate their status What this means, is that out of tens of use cases, and hundreds of requirements, there is only a single sentence devoted to concurrent use. Even more remarkable is the fact that in the final stage 2 document (TS (ETSI TISPAN, 2008)), that describes the IMS-based IPTV architecture itself, there is no mention of this requirement and the feature is not explicitly implemented. Based on the use case analysis and the above observations, it is safe to say that IMSbased IPTV, while enabling many personalized services for individual users, has not been designed with multiple users and concurrency in mind. One could argue that this reinforces the notion that personalization and concurrency do not go well together. The only way to invalidate this view is by coming up with a use case that proves the opposite; that there are useful applications or services imaginable that combine the two concepts in a meaningful way. This is exactly what will be done in the next section. 2.3 New multi-user use cases The observation that the use cases that form the foundation for IMS-based IPTV and Integrated IPTV focus exclusively on single users, raises the question whether personalization and concurrent use are indeed contradictory.

17 16 / 97 To test this hypothesis, the goal is to come up with the opposite: use cases that combine both aspects; personalized use cases for multiple users sharing the same TV. In a number of brainstorm sessions, several of such use cases have been formulated Interactive TV show TV game shows have been around for many years. One of the possible reasons game shows have been such a success is the ability for viewers at home to play along by thinking about the questions and discussing them with friends and relatives. Although some interactive TV products (Sack, 2007) have responded to this with applications in which users can play along using their remote control, these products are limited to one user per TV. Having multiple viewers sitting on the couch next to each other, competing against each other, can add both a social element and a form of competition to it, making it a richer experience. An example which proves people like to play these types of games is the success of the PlayStation game Buzz! which is basically an offline TV quiz. Total sales of Buzz games have reached 6 million as of May 2008(Eurogamer, 2008). Figure 3: Two examples of what a multi-user interactive TV show might look like. The different colored icons represent different users playing. The interactive TV show use cases is a good example of how multiple users simultaneously enjoying a TV application can enrich the experience, making it more interesting than a single user experience would have been. Alice and Bob are sitting on the couch together. Alice remembers the TV show Movie Quiz is scheduled to begin in 3 minutes. Alice and Bob both pickup their own remotes and turn on the TV. Short movie trailers are shown followed by the show host asking several questions relating to the trailers shown. Bob and Alice use their remote controls to answer the questions. After the show is over the results are shown on the TV screen: Alice wins with 14 good answers against Bob s 12. The TV also shows Alice is in the top 25 of most correct answers countrywide Personal EPG/Channels In recent years, both in the US and Europe, the number of TV channels has skyrocketed. This makes it increasingly harder for customers to make a selection; users are overwhelmed by choice. To add to this problem, different members of the same household often have different tastes, each family member subscribing to different channels. This results in a TV that contains hundreds of channels, of which every member only watches a very small subset (Nielsen Media, 2008), (RNW, 2008).

18 17 / 97 A useful multi-user application would be a system in which every family member is able to choose and order his own list of channels. When this user turns on the TV, he only sees his favorite channels, in the order of his choosing. When two or more members are simultaneously logged in, the subscribed channels are added to each other. Figure 4: An example of a personalized EPG. The picture on the left shows the channel order if the red user ("Tim") is logged in, while the picture on the right shows the channel order when the yellow user ("Paul") is logged in. The personal EPG/Channels use case is an example of a use cases meant for users sharing a TV primarily in a time-share manner. In a single-user scenario, this use case would be less of an issue, since a user could just adjust the TV s main channel list. However, in a multi-user situation, users share the TV and an extra personalization layer is required. Alice and Bob are neighbors. Alice is a big movie fan and has a subscription to the premium channel Movie Channel. Bob on the other hand likes to watch sports and has a subscription to ESPN. Bob is at home watching ESPN. Then the doorbell rings: it s Alice. After having dinner together they decide to watch a movie. However, Bob does not have a subscription to Movie Channel. Without logging out Bob, Alice logs in to Bob s TV. The on-screen EPG immediately expands to include both Alice s as well as Bob s channels. Bob picks up the remote and switches to the Movie Channel. After the movie is over, Alice decides to go home. She logs out and the TV automatically switches back to ESPN, which is Bob s favorite channel Multi-user social TV The main idea behind Social TV is to add a social element to the otherwise isolated experience of watching TV alone. Services that fall under the social TV banner are presence, text/video chatting and seeing what friends are watching.

19 18 / 97 Figure 5: An example of what a multi-user social TV application might look like. The two logged in users ("Tim" and "Rick") each keep their own buddy lists When multiple users are watching the same TV, this brings additional opportunities and requirements to the concept of Social TV. Simple features are additional forms of presence statuses such as Watching Comedy Central with Rick. This serves both as an interesting way to get more information on somebody as well as increasing privacy and preventing embarrassing situations (such as sending someone a private message assuming he is alone, when in reality he isn t). Other examples are added social networking opportunities: Facebook lets you view the friends of your friends; a similar experience could be introduced for multi-user TV. Alice is watching TV. While watching TV she is chatting with her sister in a corner of the TV screen. At some point Bob comes home from work. Bob picks up his own remote and logs in. Next to Alice s chat window a new one opens up, showing Bob s buddy list. Bob sets his status to public which means that all received chat messages classified as private, and of which Bob doesn t want Alice to read them, are not shown on the TV screen. After Alice logs out, Bob sets his status to private so other users can see he is now alone and they can have a more private conversation with him Conclusion These three use cases (and others) show that there are interesting use cases possible that involve both personalization and concurrent use of one TV, hereby proving that the hypothesis of concurrent use and personalization being contradictory is not valid. Even more, they show that in some cases concurrent use and personalization are not only non-contradictory but enrich each other; concurrent use increasing the need for personalization (EPG use case) and personalization providing extra opportunities for concurrent use (interactive TV show). The first research question ( To what extent is the recent trend of personalization unifiable with the traditional situation of the TV being used as a concurrent medium? ) can now be answered. The answer is that, from a use-case perspective, the two concepts

20 19 / 97 are perfectly unifiable. This, combined with the fact that currently architectures do not take combinations of these two types of concepts into account, means that there is room for a new type of application to distinguish itself. Up until now, however, the technical side has been ignored. The next step is to check whether there are any technical issues preventing the combination of personalization and concurrency. In other words; do the identity frameworks part of current IPTV architectures provide the technical functionality necessary to support these new multiuser use cases? Chapter 3 will answer this question. But before getting to that, we will first introduce a set of requirements with which the identity frameworks can be judged. 2.4 Identification requirements In the previous section it was proven that, in terms of use cases, personalization and concurrency are not necessarily contradictory. To find out if this is also the case from a technical point of view, it is necessary to find out if current architectures support use cases that combine the two concepts. In order to do this properly, it is useful to first determine a number of requirements a proper multi-user-capable architecture should meet. The one thing all three of the use cases presented in the previous section share is the need for identification. Identification can be both local and global. An example of local identification is an interactive TV show keeping two participants on the same TV apart from each other. Global identification is needed to keep the users apart from the rest of the participants taking part nationwide. Where local identification is the domain of the TV or Set-Top-Box (STB), global identification needs to be taken care of by the IPTV architecture. At this moment it is also useful to distinguish between two different ways in which multiple users can share a TV: concurrently and consecutively. Concurrent use is the situation in which multiple users are using the same TV at the same time. Consecutive use is the situation in which multiple users share the same TV at different times; in a time-share manner. For example: one users uses the TV in the afternoon, while the another uses the same TV in the evening. Up until now, the main focus of this report has been on concurrent use; consecutive use, however, should not be forgotten. The personal EPG use case, for example, is a use case that is particularly well suited to consecutive use. Another requirement a proper multi-user-capable TV architecture should support is roaming. In the telecom world, roaming refers to the concept of switching from one carrier to another (in a different country). In this report, roaming refers to the concept of switching from one TV to another. Again taking the interactive TV show use case as an example, it would make an identity framework far more versatile if it would allow users to not only play with members of the same household, but also with friends or family living in other households. A requirement would therefore be to not only let users switch between TVs within the same household, but also between TVs in different households. Furthermore, this means that it should be able for users from different subscriptions to be able to log in on the same TV at the same time. The following list presents a number of requirements a multi-user-capable TV architecture should support: 1. The IPTV solution should support globally unique identification of a user 2. The IPTV solution should support multiple consecutive users at the same terminal 3. The IPTV solution should support multiple concurrent users at the same terminal

21 20 / The IPTV solution should support roaming between different TVs within the same household (intra-house roaming) 5. The IPTV solution should support roaming between different TVs in different households (inter-house roaming) 6. The IPTV solution should allow different users of the same subscription to be simultaneously logged in at different TVs 7. The IPTV solution should allow users of different subscriptions to be logged in at the same TV It should be noted that the requirements included in the above list are purely functional requirements related to multi-user identification. Needless to say, they are meant purely as an addition instead of a replacement to the standard single-user identification requirements found in numerous IPTV documents. 2.5 Summary The goal of this chapter was to answer the first research question: To what extent is the recent trend of personalization unifiable with the traditional situation of the TV being used as a concurrent medium? To answer this question, first a historical perspective on the development of TV was given to confirm that there is indeed a trend towards personalization and individualization. It was observed that this trend is possibly in competition with the traditional social component of TV in which multiple users watch TV together. To check whether this is the case, a use case document was analyzed to see how IMSbased IPTV handled these two concepts. The analysis showed that personalized services for concurrent use are not taken into account. This resulted in one of two possible conclusions: Either personalization and concurrency are contradictory and no combination is possible, or there is room for a new type of application, which does combine the two concepts. A set of new use cases was developed that show that the second conclusion is the correct one and there is indeed room for a new type of application. To check whether this new type of application is also technically feasible, the next chapter will check whether IMS-based IPTV provides the necessary functionality.

22 21 / 97 3 Identification in IMS-based IPTV The goal of this chapter is to answer the second research question: 2. Is it possible to re-use the identification mechanisms provided by current IPTV architectures for multi-user scenarios? For reasons discussed in the introductory chapter, this project will primarily be focused on the use of IMS-based IPTV. Because of this, the real question becomes: 2. Is it possible to re-use the identification mechanisms provided by IMS-based IPTV for multi-user scenarios? In order to answer this question, this chapter will start with a brief introduction of IMS, on which IMS-based IPTV is built, in Section 3.1 and its system of identifiers in Section 3.2. Then in Section 3.3, the different authentication methods of IMS are discussed. By comparing these methods to the set of multi-user requirements introduced in Chapter 2, it is possible to get an idea if IMS-based IPTV is able to support concurrency and multi-user use cases. The chapter ends with a short summary and conclusion. 3.1 Understanding IMS This section features a brief introduction of IMS. An overview of IMS s development and its structure is given. Also, the most important components of IMS within the context of this project are discussed. As its name implies, IMS-based IPTV is built around the IP Multimedia Subsystem (IMS). IMS is a framework originally developed to deliver multimedia services to mobile devices. A number of standardization bodies collaborate on IMS; among them 3GPP, 3GPP2 and ETSI TISPAN. IMS is based almost entirely on Internet Engineering Task Force (IETF) protocols such as the Session Initiation Protocol (SIP) (IETF, 2002) and Diameter (IETF, 2003). In the last few years, IMS has developed from being dedicated to mobile devices running over UMTS (hence its 3GPP origin) to a more general IP multimedia framework that is access independent ; supporting both mobile and fixed access technologies such as xdsl and WLAN (where ETSI TISPAN comes in). However, IMS s origin in the mobile telecom world is still apparent when looking at its structure, components and identification system. Before proceeding with IMS s identification & authentication system, it is necessary to very briefly introduce a number of entities that together form the IMS core network and are vital to the authentication process: the Home Subscriber Server (HSS) and the Call Session Control Functions (CSCFs). For more information on the IMS core network, see (ETSI TISPAN, 2008). The HSS is a master database containing subscriber information such as user profiles. It also performs authentication and authorization in cooperation with the S-CSCF. The HSS can be compared to the Authentication Center (or HLR) found in GSM/UMTS. The CSCFs are SIP servers processing SIP signaling packets. There are three types of CSCFs: S-CSCF, P-CSCF and I-CSCF. The Serving-CSCF (S-CSCF) is a central SIP server in a subscriber s home network. It performs SIP registration and communicates with the HSS for authentication information. The Proxy-CSCF (P-CSCF) is the SIP server closest to the user terminal and the first and last point of contact; it is also responsible for maintaining secure channels to the user terminal. The Interrogating-

23 22 / 97 CSCF (I-CSCF) is used for routing purposes and can be found between different IMS networks. For a simple overview of the IMS core, see Figure 6. Figure 6: IMS overview (from (Hunter, Clark, & Park, 2007)) Now the general structure of IMS is clear, it is time to move on to a part of IMS that is of special importance to this project: its system of identifiers. 3.2 IMS identifiers IMS was originally meant to run completely over mobile networks such as UMTS and this obvious when looking at its system of identifiers. In the same way GSM and UMTS use IMSI and MSISDN as their main identifiers, IMS uses IMPI and IMPU. IMPI, which stands for IP Multimedia Private Identity, is an identifier only known to the UICC and the network s authentication center. It is analogous to the IMSI (International Mobile Subscriber Identity) used in GSM/UMTS and takes the form of a Network Access Identifier (NAI). Just as with the IMSI, the IMPI identifies a single user. Since the IMPI is a private identifier, only known to the SIM application on the UICC and the network s HSS, the IMPI is not used for the routing of SIP messages; it should be sent over the network as rarely as possible. The IMPI is therefore only used during the authentication process. In the HSS, the IMPI is linked to a set of security credentials and a user profile. In a typical situation, one or more IMPIs are part of an IMS subscription. An example would be for a family to share an IMS subscription with each user having their own IMPI. The other main identifier used in IMS is the IMPU, which stands for IP Multimedia Public Identity. The IMPU does not represent a user but a way to make contact with a user. It can be compared to the Mobile Subscriber ISDN Number (MSISDN) in GSM/UMTS. In IMS it takes the form of a SIP URI or TEL URI (SIP or TEL Uniform Resource Identifier). As opposed to the IMPI, the IMPU is a public identifier available to the outside world; others can use it to contact the owner. An IMPU always belongs to one (or more) IMPIs.

24 23 / 97 Just as it is possible for a person to have multiple phone numbers or -addresses, it is also possible for a user to have multiple IMPUs. An example of this would be for a user to have both a personal and a business IMPU. It is also possible for an IMPU to be shared among different IMPI. This could for example be used to identify a group of people, for example a family or a group of colleagues. To get an idea of the different configurations possible with IMPIs and IMPUs, Figure 7 shows a diagram showing a typical situation. Figure 7: Relationship between different IMS identifiers (from (ETSI TISPAN, 2008)). In this diagram, a subscription is shared by two users, both having their own IMPI. Each of these IMPIs is linked to a personal IMPU, with a third IMPU being shared by both users. This third IMPU can for example be used for a shared family telephone. One final thing that should be noted is that is that it is both possible for an IMPU to be registered at different terminals at the same time (analogue to different phones ringing simultaneously when a certain number is called) as well as for different IMPUs to be registered at the same terminal (calling to different numbers resulting in the same phone ringing). The important thing to remember from this section is that IMS is based around two identifiers: IMPI and IMPU. An IMPI represents a user and is authenticated. An IMPU belongs to one or more IMPI and represents a way to make contact with that user. An IMPU is not authenticated. Different configurations of IMPI and IMPU have different advantages and disadvantages. In order to answer the second research question ( Is it possible to re-use the identification mechanisms provided by current IPTV architectures for multi-user scenarios? ) we need some more information. At this moment it is safe to say that the concept of IMPIs and IMPUs does not pose any problems for multi-user TV use cases; in fact their flexibility makes them well suited for such purposes. The most important requirement for concurrency is that it should be possible for multiple users to be logged in simultaneously and this is certainly possible with IMPUs. However, before the research question can be answered affirmatively, some more information is needed about the more practical aspects of IMS s identification system. For this reason, the next section will analyze IMS s authentication methods. 3.3 Authentication in IMS With IMS-based IPTV, every time a user turns on the TV, he/she needs to be authenticated (in the same way a mobile phone user is authenticated when he/she turns on his mobile phone). As already discussed, this authentication process makes use of the user s IMPI. IMS features three different methods for authentication, all three of which are specified in TS (ETSI TISPAN, 2009).

25 24 / IMS AKA The main authentication method used in IMS is IMS AKA (Authentication-and-Key- Agreement). IMS AKA is related to similar AKA mechanisms found in GSM and UMTS. With IMS AKA, identifiers (IMPI and IMPU) are stored on Universal Integrated Circuit Cards (UICCs). UICCs are tamper-resistant smartcards that aim to ensure the integrity of the data stored on them. On a UICC, one or more applications can be run. Examples of such applications are SIM, USIM and ISIM in GSM, UMTS and IMS respectively. Since UICCs are most commonly known for the SIM applications used in GSM, they are often referred to as SIM-cards. The idea behind IMS s authentication system is to have each terminal support IMS AKA. However, since it relies on ISIM-equipped UICCs, there are a number of reasons this has not been possible so far (Jorstad, Thuan, Jonvik, & Thanh, 2008)(Priselac & Mikuc, 2008). One of them is the urge of operators to quickly deploy IMS before the specification is complete and therefore allow legacy terminals on the IMS network. Another one is that replacing all SIM-based UICCs currently in the market with ISIMbased UICCs is a very costly and complex operation. The final one, and the one most important in the context of this project, is that most fixed terminals do not have the UICC interfaces (readers) that are required for the successful operation of IMS AKA. For all of these reasons, two additional authentication methods are supported by IMS. The following section will very briefly describe each of IMS s three authentication methods: IMS AKA, SIP Digest and NASS-bundled Authentication. Additionally, the authentication methods are analyzed to see whether they meet the multi-user requirements introduced in the previous chapter. All this will result in an answer to the second research question. For more information on the different authentication methods, the reader is referred to Appendix A. As already discussed, IMS AKA is based on the use of a UICC. On such a UICC one or more ISIM applications are run. Each ISIM application is linked to one exactly one user through this user s IMPI. Every application contains, apart from the IMPI, one or more IMPUs and a shared secret K. This shared secret K is, apart from the ISIM, only known to the HSS in the user s home network and is of vital importance to the authentication process. Every time a user needs to be authenticated, a challenge response mechanism takes place between the UICC and the network s S-CSCF. The idea behind this challenge-response mechanism is that it allows both client (TV/mobile phone etc.) and server (IMS core) to make sure that the other knows the shared secret K, and is therefore who he claims to be, without having to send this shared secret over the network. For more information on the inner workings of IMS AKA, see A.1. The main advantage of IMS AKA, and the one that sets it apart from most other authentication methods, are the computational abilities of a UICC. Since the UICC handles the complete challenge-response mechanism including computing the required ciphers internally, the terminal in which the UICC is placed (i.e. the TV or mobile phone) does not come into contact with the shared secret K. This makes for a very secure authentication system since the terminal (and thus any other application running on the terminal) does not know anything more than any other node along the path from UICC to IMS core. The unique concept of a UICC also makes that there are some issues with IMS AKA when used in the context of multi-user TV. The problem lies in the fact that, unlike most other identifiers, a UICC is physical. In Section 3.2 it was described that if a household would subscribe to IMS-based IPTV, each family member would receive his or her own IMPI (and associated IMPU). With

26 25 / 97 IMS AKA there are now two options: either the different IMPIs of the different users are placed on the same UICC (see Figure 8) or they are placed on different UICCs (see Figure 9). Figure 8: Multiple users per UICC Figure 9: Single user per UICC Each of these two situations can now be checked against the multi-user requirements presented in Section 2.4. In the first case, multiple users on one UICC, there is a problem when the different users want to watch TV at different TVs within the same house. Since the physical UICC cannot be split, it is only possible for it to be in one TV at the same time. This problem could possibly be solved with a central IMS Residential Gateway (a device to which all IMS-enabled terminals in a single house are connected and which houses the UICC. For more information see A.4). However, that set-up cannot solve the problem of several family members watching TV at multiple TVs in different households. In the second situation, with a single user per UICC, there are similar problems. In this case, there is no problem with family members watching TV at different TVs within the same house. However, when they want to watch TV together (concurrently) there is a problem, since only one UICC can be present in a single terminal. The problem gets even bigger when friends that are part of different households want to watch TV together. Since concurrency is the essence of multi-user TV, the single-impi-per-uicc scenario is also problematic. Of course the problems described above could be partially solved by requiring TVs to be equipped with multiple UICC slots. Such a solution however is not scalable; how many slots should a TV have? Two? Three? Five? In any case, UICCs were never designed to be physically swapped between different terminals often and it should therefore not come as a surprise that a scenario in which this is required presents problems. To sum up this section: While IMS AKA technically supports multi-user TV use cases, there are some serious functional and usability issues that would have to be solved in order for it to become practical to use. Fortunately, IMS offers two other authentication methods.

27 26 / NASS-bundled Authentication NASS-bundled Authentication (NBA) is meant for terminals that do not feature UICC slots, which is obviously the case for the majority of current TV sets. NBA is based on the concept of re-using existing access-line authentication protocols. In almost all IP-based networks there is a system that authenticates a terminal s physical connection to the network and provides it with an IP address. In IMS this function is provided by the Network Access Subsystem (NASS). It is this IP-connectivity authentication that is re-used in NBA. The exact protocols used by NASS to perform network attachment are outside the scope of this text. For now it is enough to know that every physical line is identified with a Line Identifier (LI). In the HSS, this LI is linked to a specific IMPI. If a terminal is turned on, its LI is confirmed and the associated user is logged on. For more information on the exact workings of NBA, see A.3. The obvious problem with NBA is its lack of flexibility. Inter-house roaming (see Section 2.4) for example is not possible since an IMPI is tied to a specific location due to its associated LI. Concurrency is therefore restricted to members of the same household. Since it is clear that NBA does not meet the multi-user requirements and there is no simple workaround for these problems, NBA is no longer interesting for the purposes of this project SIP Digest Just as NBA, SIP Digest authentication is meant for terminals that do not support UICC cards. However, instead of re-using access-line authentication, SIP Digest is based on a username/password combination. SIP Digest is based on HTTP Digest, which is often used to control access to websites. HTTP Digest (and thus SIP Digest) is built around the same basic principle as IMS AKA, namely the existence of a shared secret between the terminal (in the case of IMS AKA, the UICC) and the HSS. A challenge-response mechanism is then used to verify this. For more information on the technical details of SIP Digest, see A.2. The main difference here is that in IMS AKA the shared secret is an abstract value in an ISIM application embedded on a UICC while in Digest authentication the shared secret is a password known by the user. The essence of this difference is that with SIP Digest the password is open and accessible (known) to the user, while with IMS AKA, the secret is inaccessible and hidden from the user. This obviously makes SIP Digest the less secure of the two. Even more so since, with SIP Digest, not just the user but also the terminal comes into contact with the shared secret. From a multi-user requirements point of view however, SIP Digest fares better than IMS AKA. In theory it supports all of the requirements introduced earlier. There are however two problems with SIP Digest. The first concerns security. The fact that both user and terminal come into contact with the shared secret makes it more vulnerable. An in-depth investigation of the workings of SIP Digest brings up a number of other security issues (see A.2). The main problem with SIP Digest, however, has nothing to do with security; it is the simple fact that it requires a keyboard for a user to input his username and password. This is obviously not very user-friendly in the keyboard-less TV world. 3.4 Conclusion The goal of this chapter was to answer the second research question: Is it possible to re-use the identification mechanisms provided by current IPTV architectures for multi-

28 27 / 97 user scenarios? In order to answer this question, the IMS-based IPTV architecture has been analyzed. Of particular interest were its identifiers and authentication system. The answer to the research question can now be given: On the one hand IMS-based IPTV supports multi-user scenarios; both the SIP Digest and IMS AKA authentication mechanisms support all of the requirements stated in Section 2.4. However, both authentication methods have some serious issues in the area of usability which prevents the implementation of multi-user use cases from being trivial and therefore requires some innovative solutions. Either the aforementioned issues should be solved or a completely new authentication method should be developed. The following chapter will discuss this problem.

29 28 / 97 4 Introducing RFID Digest In the previous chapter it was shown that there are some problems with current authentication methods when used for multi-user scenarios. This chapter will deal with trying to solve these problems. In effect the following three research questions will be answered: 3. What would be a user-friendly and flexible form of identification? 4. How can IMS s standard identifiers be mapped to this new form of identification? 5. How can the new form of identification be integrated into IMS-based IPTV in a secure way? The first section of this chapter, Section 4.1, presents a short discussion of the different types of solutions possible to solve the problems identified in the previous chapter. At the end of that section, the decision will be made that it is best to develop a new clientside identification method. This new identification method is the subject of the rest of this chapter. In Section 4.2, after describing a number of options, the general design of the new system will be decided upon. Then, after a brief technology introduction in Section 4.3, the more detailed design of the identification system will be presented in Section 4.4. The chapter will end with a short summary and conclusion on how to proceed from here. 4.1 Different solutions possible This section will answer the third research question: 3. What would be a user-friendly and flexible form of identification? In the previous chapter it was concluded that while IMS s system of identifiers is wellsuited to multi-user scenarios, its three authentication methods have a number of limitations which make them impractical to use. The question now is: what to do about this? There are basically two answers to this question. The first is trying to work around the limitations of the existing authentication methods. The second is developing a completely new authentication method. Both of these options have a number of drawbacks. Workarounds for existing authentication systems will never be as flexible as completely new authentication systems. On the other hand, for a completely new IMS authentication method to be useable requires it to be standardized and included in the IMS standards. This is a very long, costly and complex process which makes it a very difficult path to take. For the purposes of this project, developing a completely new authentication method and having it standardized is therefore completely unrealistic. There is also a third option. When looking at the problems of the three existing authentication methods, it becomes apparent that the problems are mainly on the client side. With IMS AKA, it is the fact that the IMS identifiers are stored on physical UICCs; with SIP Digest it is the fact that a keyboard is required to type in passwords. Apart from some security vulnerabilities with SIP Digest there are no issues on the server side or on the path from client to server. Another option would therefore be developing a new client-side identification mechanism that, on the server side, is compatible with existing authentication methods. Such a system would have the

30 29 / 97 flexibility of a completely new system without it having to be standardized (since it would use existing infrastructure). For the purposes of this project, this is probably the best solution. In a side-project carried out by this author (Brandenburg, 2008), some research has been done into different forms of identification that would be suitable to the TV world. A number of potentially suitable technologies and identifiers were discussed; among them mobile phones, facial recognition and Radio Frequency Identification (RFID). For readers not familiar with RFID: An RFID tag (or transponder) is a combination of an antenna and an integrated circuit. RFID tags work by receiving a signal sent by an RFID reader, using the power embedded in this signal to power the integrated circuit and then transmitting a response signal such as the tag s unique identifier. Due to their flexibility, the fact that they are inherently suited to roaming (since they can easily be carried around) and their user-friendliness, RFID tags are especially wellsuited to the concept of multi-user television. Because of these reasons, this project will follow the recommendations made in (Brandenburg, 2008) and use RFID as the foundation for the new client-side identification system. Now the choice has been made to go with RFID for identification and an existing IMS authentication method for authentication, the obvious follow-up question is how exactly this combination should be made. This is the subject of the rest of this chapter. 4.2 Using RFID In the previous section an answer to the third research question ( What would be a userfriendly and flexible form of identification? ) was found in the form of RFID. It was also decided to combine RFID with an existing IMS authentication method so that no changes on the server side would have to be made. This brings us to the following two research questions: 4. How can IMS s standard identifiers be mapped to this new form of identification? 5. How can the new form of identification be integrated into IMS-based IPTV in a secure way? The fourth research question basically asks how IMS current systems of identifiers, with IMPIs and IMPUs, can be successfully mapped to the new form of identification, RFID. The fifth research question concerns the problem of connecting the new client-side identification method, based RFID, to the existing IMS infrastructure. In the previous section it was decided to re-use an existing authentication method for this, but at this time it is not clear how such a combination should be made. This section will lay the foundation for the answering of both these research question in the next section. In order to do so, we will first present a general introduction of RFID, its possibilities and limitations. After this, the general design of the new identification system will be decided upon RFID in general RFID, which stands for Radio Frequency Identification, is a technology that allows for automatic identification of objects. It does this by remotely accessing information stored on a so-called RFID tag (also referred to as PICC, for Proximity Integrated Circuit Card) placed on the object. The device that accesses the tag and retrieves its information is called the RFID reader (or PCD, for Proximity Coupling Device). What

31 30 / 97 makes RFID unique from other identification techniques is that it is completely contactless. The actual range from which an RFID reader is able to access an RFID tag depends on the used technology and varies from a few centimeters to multiple meters. Figure 10, shown below, shows the four main RFID technologies. Figure 10: Different types of RFID RFID can (and is) used for a wide variety of applications. These range from animal identification to public transportation tickets and from supply chain labels to building access control. Each of these environments requires its own level of security. For example, RFID tags used to identify different animals at a farm require far less security than RFID tags used to control access to military buildings. Apart from varying in their need for security, RFID tags also vary in their supported functionality. While some tags do nothing more than sending back a serial number, other tags contain complex cryptographic functions and multiple kilobytes of memory. Every RFID tag consists of two parts: an antenna and an integrated circuit. The role of the antenna is sending and receiving a radio-frequency (RF) signal used to communicate with an RFID reader. The role of the integrated circuit is modulating and de-modulating this signal as well as storing and processing information. The most common RFID tag is the passive tag. The passive tag works by receiving a signal send out by an RFID reader. The power embedded in this signal is then used to operate the integrated circuit inside the tag. This circuit modulates the incoming signal with some information stored inside the tag (usually a unique serial number). The modulated signal is then send back to the reader by the antenna. Finally, the reader receives the signal and performs de-modulation to extract the information. This mechanism allows passive RFID to communicate without requiring a power source on the tag-side. Obviously this system severely limits the power available to the integrated circuit so power-heavy applications are not possible. Another, less common, type of RFID solves this problem. This type of tag includes a battery and is therefore called an active tag. The availability of the battery makes more complex types of applications possible. Examples include sensor tags that actively measure their environment (such as humidity or temperature sensors) and then send this information back to the RFID reader when queried. One drawback of active tags is that the battery capacity limits the tag s lifetime. The integrated circuit contained in most RFID tags can perform various functions; from simply retrieving a stored number to performing complex cryptographic calculations. The most straightforward operation, and the one that is performed by most tags, is simply sending back a serial number. This serial number is most often 64 or 96 bits in length and can be used to uniquely identify that specific tag among its peers. In the simplest tags, this number is hardwired in the tag itself. In more complex tags, this number can be stored once after which it is permanently associated with the tag. Even more complex tags allow a reader to overwrite the number over and over. Apart from the relatively straightforward operation of reading a serial number from a tag, there are also more sophisticated tags. Most of these offer a small EEPROM from which an RFID reader can read/write data. Some of these tags also include advanced security functionality. One example of this type of functionality is the ability to encrypt communication between reader and tag using a shared key. Another example is a system that allows reader and tag to mutually authenticate each other before giving

32 31 / 97 access. It should be noted that the protocols used for this type of functionality can be either proprietary or standardized. For a more detailed description of RFID, see Appendix B Different approaches possible Now the decision has been made to use RFID in a client-side identification system and the general properties of RFID are known, the next step is to decide on an overall design for the RFID multi-user identification system. The most important step here is to decide on how the connection between RFID and the IMS core should be made. In Section 4.1 it was proposed to use one of the existing authentication methods as an interface to the IMS core. In other words, RFID should be connected in some way to either IMS AKA or SIP Digest. One of the most obvious ideas would be trying to duplicate UICC functionality in an RFID card; if an RFID card would behave as a UICC, it could be authenticated with regular IMS AKA and no changes would have to be made to the IMS core. However, there are a number of obstacles that don t allow this. The main problem is the technical limitation of current RFID cards. Most RFID cards are basically memory sticks that allow one to perform very simple operations on the data. They do not contain general purpose processors; all functionality provided by the card, such as cryptographic ciphers and simple data manipulation, is hardwired into the integrated circuit design of the card itself. This means that applications can only be developed on the reader side of an RFID system. (It should be noted that there are some RFID cards available that do allow users to run their own applications on them. These cards however are still very expensive and therefore not suitable for this project.) Because of these technical limitations, it is impossible for a generic RFID card to be programmed to behave like a UICC. The only way to have RFID cards be authenticated by IMS AKA, as if they were UICCs, is to develop a custom-built RFID card that includes integrated circuits for carrying out the specialized algorithms performed in UICCs. Since integrated circuit design does not lie in the direction of this project, this option is considered outside the scope of this project. The complete opposite of the type of complex RFID card described above is an RFID card that only includes a unique serial number. This unique number could be linked to user profile stored on a local computer. When the RFID card is read, the computer opens the appropriate user profile and, using the credentials stored in this profile (such as IMPI and password) performs SIP Digest authentication on behalf of the user. In this simple system, RFID is only used for local identification. Although such a system is relatively easy to implement, and does not require any change to the IMS infrastructure, it is too limited in its supported functionality; it does not support roaming for example. In this way it can be compared to NBA authentication (with the added bonus that different family members can not steal each other s identities). What is required is something in-between the two extremes of the examples just described: more flexible than RFID serial numbers linked to local user profiles, but not so complex that specialized integrated circuits need to be developed. Furthermore, the system should require the least possible amount of adjustments to IMS infrastructure. A concept that meets these requirements is the following: a user s IMPI and IMPU are stored on an RFID card, together with a shared secret K. When the card is read by a RFID reader connected to a terminal (TV or STB), the terminal extracts the user credentials and contacts the IMS core with the extracted IMPI. Authentication is then

33 32 / 97 performed through SIP Digest with the extracted shared secret K functioning as the Digest password. An overview of this new concept, which from now on will be called RFID Digest (since it combines RFID with Digest authentication), is shown in Figure 11. Figure 11: Overview of RFID Digest Apart from meeting all of the multi-user requirements presented earlier, RFID Digest has a number of additional advantages: It re-uses existing authentication methods so that changes on the server side are not required; it is highly flexible since it is not bound to specific terminals and it is very user-friendly. Another advantage is that the storage capacity of an RFID card could, in addition to storing user credentials, also be used to store additional user profile information (parental control information, volume preferences etc.). For all of these reasons, it has been decided to select RFID Digest as the new multi-user identification and authentication system. 4.3 Understanding Mifare Classic Now this decision has been made to go with RFID Digest, the next step is to turn it from a concept into an actual system. The first step in this process is the choice of RFID card. For this, the Mifare Classic card has been selected, mainly due to the fact that it is well-documented, inexpensive and very flexible. Before continuing with the design of RFID Digest, this section will first describe the Mifare Classic card in more detail. Some readers might recognize the name Mifare Classic from the infamous Dutch OV- Chipkaart project. This new Dutch public transportation payment system has become known for its supposedly weak security due to its use of the Mifare Classic card. Several researchers around the world have proven this particular card to be easily cloneable and therefore not secure. In Chapter 5, which deals with RFID Digest s security level, the cloning issues are investigated. In the same chapter, a number of solutions are given. For the purposes of this chapter however, it is best to ignore these issues and remember that the structure of the Mifare Classic, which will be discussed in this chapter, is comparable with other (more secure) RFID cards. It is therefore perfectly possible to port RFID Digest to another type RFID card Mifare Classic memory organization The Mifare Classic is the most used RFID card worldwide with over 75% of the total market (NXP Semiconductors, ). Since this is the card that will be used for this project, it is important to learn its possibilities and its limitations. In order to do this, its memory organization, its set of commands and its security features will be described. The source of most of this information is the card s datasheet (NXP Semiconductors, 2008).

34 33 / 97 The Mifare Classic RFID card is basically a memory card with some additional authentication features. There are two versions available: a 1Kbyte version and a 4Kbyte version. Apart from the memory structure, there are no differences between the two. The Mifare Classic s memory is divided into blocks of 16 bytes long. Blocks are grouped into sectors. In the 1K version, there are a total of 16 sectors of 4 blocks each. In the 4K version, the first 32 sectors contain 4 blocks, with the remaining 8 sectors containing 16 blocks each. The last block of each sector is called the sector trailer (ST), with the remaining blocks called data blocks. For an overview of the memory structure, see Figure 12. Figure 12: Mifare Classic 1K memory organization 1 The first data block of the first sector is called the manufacturer block and contains special data. The complete block is locked and cannot be written to. The block contains the following: The 4-byte Unique Identifier (UID) of the card, a 1-byte Bit-Count- Check (BCC) which is used to check the integrity of the UID (successive XOR ing of UID bytes), and 11 bytes of undefined manufacturing data. Figure 13: Mifare Classic manufacturer block organization The Mifare Classic is based around a principle where each sector is protected separately. Before a reader is allowed to read or write to a data block he first has to be 1 This diagram has been recreated from a somewhat similar diagram in [24]

35 34 / 97 authenticated by the sector containing the block. For these purposes, the sector s ST is used. The exact organization of the ST will be discussed in upcoming sections, for now it is enough to know that the ST contains two keys A and B, a set of access conditions and an undefined byte U. Under no conditions can the keys A and B be read (although they can under some circumstances be written to). It should be noted that it is possible for the sector trailer to be configured in a way that the second key B is not used, so that its bytes can be used for data storage. Figure 14: Mifare Classic sector trailer organization Data blocks can be configured for general data storage or as a value block. An advantage to value blocks is that simple internal calculations can be performed on them (adding/subtracting). One example of the use of value blocks are electronic purse applications. A value block contains a 4-byte signed value. For redundancy, this value is stored three times; once inverted and twice non-inverted. The remaining four bytes are used to store a 1-byte block-address which can be used as a pointer. The blockaddress is also stored redundantly; twice inverted, twice non-inverted Command set Figure 15: Mifare Classic data block versus value block The Mifare Classic RFID card contains a limited number of commands that can be carried out on blocks. Commands are always carried on one block at a time. Before a command can be carried out, the reader has to be authenticated by the sector containing the block. Also, before an operation is carried out on a block, the block s access conditions are checked to see whether the chosen command is allowed on that specific block. Access conditions can for example specify a block to be read-only or allow a value block only to be decremented. Furthermore, a block s access conditions may differ whether key A or key B is used for authentication. For more information on access conditions, see Sections to Mifare Classic supports the following commands: Read/Write Read and write commands can be carried out on all block types (except for write commands on the manufacturer block) and either read or write one block. When a read command is carried out on a sector trailer, the parts of the ST that contain keys A and B return zero. Write commands can also be used to convert a data block to a value block. Increment/Decrement/Restore/Transfer These commands can only be carried out on value blocks. An increment or decrement command is used to increment or decrement a value block with a given value and store the result in a memory register. The restore

36 35 / 97 command loads a value into a memory register without changing the value. The transfer command, finally, saves the contents of a memory register to a block Security features Apart from the system of access conditions that will be discussed in the next subsection, the Mifare Classic features two main security mechanisms: encryption and authentication. Encryption In order to make sure communication between reader and card is not intercepted by malicious readers, most advanced RFID cards encrypt all messages. The exact cryptographic protocol used differs between implementations. The Mifare Classic uses a proprietary cipher called CRYPTO1. In addition to encryption, the transmission protocol used in the Mifare Classic also supports data integrity protection. This is implemented by a 16-bit CRC check per block, parity bits and a bit-count-checking algorithm. Authentication The Mifare Classic features an authentication mechanism that makes sure only authorized RFID readers can read specific cards. For this, the Mifare Classic uses two symmetric keys A and B. As already discussed in a previous section, these keys are sector-specific. This means that every sector has its own set of keys and a reader needs to be authenticated every time it accesses a different sector. The authentication mechanism used is based on a three-pass challenge-response system. The way this works is as follows: 1. After initialization and anti-collision is completed, the reader specifies the target sector and chooses between keys A and B. 2. The card reads the indicated key and access conditions from the sector trailer and then sends a random 32-bit challenge N C to the reader. 3. The reader calculates the response to N C based on the secret key, N C and some undefined additional input. The reader then calculates a new random challenge N R and transmits it together with the response back to the card. 4. The card verifies the response to N C and, when correct, calculates a response to N R. This response is then transmitted back to the reader. 5. The reader verifies the response to N R. All messages transmitted after the initial challenge N C (starting with step 3) are encrypted Access conditions The Mifare Classic card features an extensive access control system. This system will now be briefly explained in order to get an idea of its possibilities. As explained in Section 4.3.1, the sector trailer consists of keys A and B (both 6 bytes), an undefined byte U and 3-byte access conditions field. This access condition field is able to control access to every block in the sector, including the ST block, separately (except for the 8 extra-large sectors of the 4K card, where access control is managed in groups of 5 blocks). In order to do so, the access control field uses 3 bits per block, making for a total of 12 bits (3 data blocks, 1 ST). Because the access condition bits are stored redundantly (once inverted, once non-inverted), the total comes to 24 bits, or 3 bytes. In the card s documentation, the access control bits are named as follows: C 10 C 20 C 30, C 11 C 21 C 31, C 12 C 22 C 32 and C 13 C 23 C 33. The first three groups of bits, with subscripts 0 through 2, are data access bits that control access to the three data blocks. The bits with subscript 3 are called trailer access bits and represent the sector trailer.

37 36 / Trailer access bits The trailer access bits C 13 C 23 C 33 are of particular interest since these bits control the configurability of the complete sector. As long as one can write to these bits, one can change the configuration of the sector. Figure 16: Mifare Classic sector trailer state transition diagram 2 The 3 access bits result in 8 possible states for the sector to be in. Figure 16 shows a state transition diagram for these 8 states. The letters A and B in a state (in the diagram depicted by circles) represent the key needed in order to change the sector trailer while in that state. When looking at the diagram, it becomes apparent that there are a number of states in which neither A nor B is shown. In these states it is therefore not possible to change the sector trailer (and thus change access conditions, move to another state or change keys A or B). These types of states (and sectors that are in this state), are therefore called frozen, since the sector trailer can no longer be modified. When the sector trailer can be changed, the type of change that is allowed to the sector trailer is depicted in the diagram by the letters within parentheses after keys A or B. When the letter K is included here, it is possible to overwrite the keys A and B in the sector trailer. When the letters AC are included, it is possible to change access conditions (and thus also move to another state). It should be noted that there are a number of states that include K but not AC. Because these states do not include AC, it is not possible to change access conditions and thus move to another state. While these states are not frozen since it is still possible to write to the sector trailer (for overwriting keys), they are restricted since it is no longer possible to move to another state. Finally, as explained in a previous section, it is possible to invalidate key B and use its bits for data storage. In the diagram, this is the case for the top 3 states (001, 000, and 010). 2 This diagram has been re-created from a similar diagram in [36].

38 37 / Data access bits The data access bits, named C1 j C2 j C3 j with j 0,1,2, are used to control access to data blocks (in the 1K version per block, in the 4K version per group of 5 blocks). There are four possible operations that can be carried out on a block: read (r), write (w), increment (i) and decrement (d). The data access bits allow for each of these commands to be allowed or not on a specific block. The commands transfer and restore are inherent to the nature of increment and decrement and therefore do not have separate access conditions. The 3-bit data access field allows for 8 possible combinations of the four commands to be allowed. However, the trailer access bits C1 3 C2 3 C3 3 determine whether key B exists or not. Because it is possible to give separate access conditions for keys A and B there are a total of 16 possible combinations. Figure 17 gives an overview of which commands are allowed for different combinations of data access bits and trailer access bits. In this figure, a combination marked dead means that the specific block cannot be accessed at all, frozen means that a block can only be read, restricted means that a blocks contents can be changed but only in a limited way and fluid means that a block can be changed in every possible way. 4.4 Developing RFID Digest Figure 17: Mifare Classic data access condition 3 Now the possibilities and limitations of the Mifare Classic are known, we will proceed with the actual design of the RFID Digest system. In doing so, the following two research questions will be answered: 4. How can IMS s standard identifiers be mapped to this new form of identification? 5. How can the new form of identification be integrated into IMS-based IPTV in a secure way? At this moment, all that is known of RFID Digest is the following diagram: 3 This diagram has been recreated from a similar diagram in [36].

39 38 / 97 Figure 18: Overview of RFID Digest This diagram can be divided in two parts: the first part concerning storing and subsequent reading of user credentials from an RFID card (in Figure 18 marked 1 ) and a second part concerning the connection between terminal and IMS core (in Figure 18 marked 2 ). On the second part, not much work needs to be done, since it is basically SIP Digest. The first part, however, is still relatively unknown. It has already been decided to use the Mifare Classic card for this part, but that is about it. This section will therefore mainly be concerned with the development of this first part. This section will include a number of references to specifics of the SIP Digest protocol. Readers not familiar with this protocol are encouraged to read Section A.2 of the appendices before continuing IMPI/IMPU storage considerations One of the most important parts in designing RFID Digest is determining how to store the IMS user credentials on the Mifare Classic card. A total of three parameters need to be stored on each card: an IMPI, an IMPU and a shared secret K. Shared secret versus Password The reason the shared secret parameter is referred to as such, instead of simply as password as is more common in Digest standardization documents, is to reinforce the fact that this parameter is not known to the user. It can therefore better be compared to the UICC-stored shared secret K as used in IMS AKA than to the user-memorized password as used in HTTP/SIP Digest authentication. The storage of these variables introduces a number of issues. As explained in Section 3.2, the IMPI takes the form of a NAI (see (IETF, 2005)), while the IMPU takes the form of either a SIP URI (see (IETF, 2002), (IETF, 2005)) or a TEL URI (see (IETF, 2004)). In both NAIs and URIs most characters are represented by an 8-bit sequence (in RFCs often referred to as an octet instead of a byte). This means that on an RFID card, each character that is part of the IMPI or IMPU takes up 1 byte. A common IMPI or IMPU will therefore easily take up multiple data blocks (each block being 16 bytes in length) of the Mifare Classic s memory. Since IMPIs and IMPUs do not have a fixed length, the question now is: how much space to reserve for these parameters? The standard (RFC 4282) that describes the NAI (which is the form taken by the IMPI) states that Devices handling NAIs MUST support a NAI length of at least 72 octets. This means that a minimum of 72 bytes need to be reserved for storing the IMPI. With 16 bytes per data block, this means that storing the IMPI requires 5 data blocks. RFC 4282 further states that it is recommended for devices to handle 253 octets instead of

40 39 / 97 the minimum requirement of 72. This would translate to 16 data blocks, or a third of the total memory capacity of the Mifare Classic 1K. An IMPU on the other hand, is represented by either a SIP URI or a TEL URI. The problem with both SIP URIs and TEL URIs is that no maximum lengths are specified. Because of this, it is unknown how much memory space needs to be reserved for an IMPU. Obviously, a SIP URI of unlimited length is not desirable. It is also important to remember that it is possible for a user (an IMPI) to have multiple IMPUs. Although in IMS AKA, it is not required for an ISIM application to store more than one IMPU, it would be preferable if RFID Digest would allow a user to store at least two IMPUs on his RFID card. A good way to work around the problem of unlimited-length SIP URIs is to use the same technique a lot of SIP applications use. That is, simply choose an upper limit to the length of SIP URIs supported (SIP applications use a dedicated SIP protocol message to deny service to longer SIP URIs). An example of an appropriate limit would be the same as used for IMPIs (72 bytes). It is important to remember that IMPUs are meant as public identifiers which one gives out to other people and prints on business cards. IMPUs much longer than 72 bytes (characters) would not be very well suited to this purpose anyway. In IMS AKA, the shared secret K which is stored on the UICC is 128-bits in length. For RFID Digest it makes sense to at least choose a similar length. A 128-bit key or a multiple of this also fits nicely with the length of a data block, which is 16 bytes (128 bits) long. Figure 19 shows an overview of the storage requirements for the different user credentials Complications with the Mifare Classic Figure 19: Use credentials storage requirements Before deciding on the final storage specifics, it is important to mention something about the Mifare Classic communication protocol. The Radio Frequency (RF) interface between card and reader features a number of data integrity features. Among them are parity checks for every sent byte, bit coding, bit counting and a 16-bit Cyclic Redundancy Check (CRC) for every sent data block. One could assume all of these measures taken together would result in a problem-free transmission of data and most of the times this is indeed the case. However, for some reason, when an RFID card is removed during the transmission of a data block, instead of sending back an error, the reader sends back an all-zero data block (16 bytes of zeros). The problem here is probably not with the reader itself but with the low-level driver on the terminal side that controls the interface between terminal and RFID reader. Whatever the exact reason is, because of this problem it is impossible to distinguish between an empty data block and a removed card. Although the above should not be a problem during normal operation (since the situation with the binary representation of part of an IMPI consisting of 128 consecutive zeros is not very likely), it is better to solve this potential issue. A simple solution would be to end each data block with a specific bit pattern. Although a single bit would suffice to solve this problem, it is better to use a complete byte. Using a single bit would result in data blocks of 127 usable bits; data blocks that cannot be divided into complete

41 40 / 97 bytes and therefore make splitting a long parameter over several data blocks less elegant. The choice has therefore been made to format the last byte of every data block with the value 0xAA. Of course the end-of-block-byte solution described above has consequences on the storage requirements of the user credentials in the sense that now only 15 bytes can be stored in a single data block Storing IMS identifiers on Mifare Classic Figure 20 shows a diagram that presents the final situation of how the different user credentials are stored on the Mifare Classic 1K. In this situation, the IMPI is stored with a maximum length of 74 bytes, the shared secret K has been made 254 bits long and a total of two IMPUs can be stored, each with a maximum length of 74 bytes. Figure 20: Overview user credential storage on Mifare Classic 1K Since the different use credentials are stored in different sectors (one for the shared secret, two each for the IMPI and IMPUs), each of these credentials has one data block

42 41 / 97 of space left (in the figure marked with reserved ). The reason this has been done is twofold. First, giving the different credentials separate sectors allows for more advanced security schemes since each sector can be given its own authentication keys and access conditions (more about that later). Secondly, by not setting the maximum credential length to a multiple of the sector-size (for example a shared secret K of 3 data blocks instead of 2) so that a sector is not completely filled, the empty data block at the end of each credential can be used in the future for additional data integrity and security mechanisms. Examples of such mechanisms are (partial) redundancy or data encryption Keys and access conditions As already discussed, the fact that each of the user credentials is placed in its own sector(s), allows for each of the sectors to have separate security keys and access conditions. In most systems, the RFID access keys are stored in the RFID reader s internal memory, although it is also possible for the terminal to which the RFID reader is connected to provide the key. Concerning the nature of the access keys in this project there are two possible options. The first is for each RFID card to have a unique set of keys, the second is for all RFID cards to share the set of keys. The advantage of the first option is added security; if one of the keys should leak, this card can just be blocked and a new one issued. However, the multi-user identification requirements presented in Section 2.4 clearly state that roaming between different terminals and different households should be possible. With a unique set of keys for every RFID card, this is not possible, since readers would then be required to know the unique keys of all RFID cards in existence. For this reason, the only possible solution is for all RFID Digest cards to share the same set of keys. Using the Mifare Classic s system of access conditions, the data blocks containing the user credentials can be set to the frozen state so that it is only possible for terminals to read them, not change them. However, this would prevent any form of change at all. If a user would change his IMPU for example (in the same way a mobile phone subscriber might want to change his phone number), this would require the operator to issue a completely new RFID card. A better alternative would be to use a tiered system that allows most readers to only read the credentials, while some special readers (readers owned by the TV operator for example) could overwrite them under special circumstances. This could be done by setting different access conditions for sector-keys A and B; for example having all RFID readers know key A while the special readers also know key B Authentication through SIP Digest In the last few sections the fourth research question ( How can IMS s standard identifiers be mapped to this new form of identification? ), has been answered. This leaves us with the fifth research question ( How can the new form of identification be integrated into IMS-based IPTV in a secure way? ). As has already been discussed, the connection between terminal and IMS core will be made by re-using SIP Digest authentication so that no changes to the server-side are required. The only difference is that instead of the user typing in a password, the terminal uses the shared secret K read from an RFID card. The following diagram shows the complete process of a user logging in with RFID Digest; the SIP Digest part and the RFID part.

43 42 / 97 Figure 21: Overview of RFID Digest message flow RFID Digest message flow 1) The TV/STB is turned on and sends a signal to the reader to wait for an RFID card. 2) The reader uses polling to wait for an RFID card. When an RFID card enters the reader s RF field, an initialization and anti-collision sequence is entered. 3) When the card is successfully initialized, it responds to the reader s polling signal with its UID. 4) The UID is sent back to the terminal as a way to tell a card has been detected. 5) The terminal transmits a request to read the first block o the first sector of the RFID card, containing the first half of the IMPI. 6) The reader sends the RFID card a request to select sector 1.

44 43 / 97 7) The card checks the access conditions from sector 1 s sector trailer and sends an authentication challenge containing a random 32-bit nonce to the reader. 8) The reader checks its internal memory for the required read key and uses it together with the nonce to calculate a response. It then calculates a new random challenge cnonce and transmits it together with the response back to the card. 9) The card verifies the response to its initial nonce and, when correct, calculates a response to the reader s cnonce. This response is then sent back to the reader. 10) When the card s response to the cnonce is correct, reader and card have both been identified. The reader is finally ready to read the first data block of the first sector. 13) After receiving the contents of the first data block, and with it the first 15 bytes of the IMPI, the terminal requests the second data block. 17) And the third. 18) The fourth and fifth parts of the IMPI are in a different sector, so a new round of authentication is required. The same goes for the IMPUs and the shared secret K. 19) Once all necessary sectors and data blocks have been read out, the user credentials are re-assembled at the terminal. 20) Now the user credentials are complete, the next step is authentication at the IMS Core. This process begins with the terminal sending a SIP Register message, containing the IMPI and IMPU, to the S-CSCF. 21) The S-CSCF responds with an authentication challenge. 22) The terminal uses the shared secret K to calculate a response to the server-side authentication challenge. It then sends back the challenge together with a new client-side challenge. 23) Once both S-CSCF and terminal have verified their responses, the authentication process is complete and the user has successfully authenticated. 4.5 Summary In Chapter 3, IMS s authentication methods were introduced. In that chapter it became apparent that some serious usability problems were standing in the way of these authentication methods being used for multi-user use cases. The goal of this chapter was to come up with a solution to these problems. This solution has been found in the form of RFID Digest; a system that combines a client-side RFID identification mechanism with the existing SIP Digest authentication system. The result is a system that meets all of the multi-user requirements stated in Chapter 2. Furthermore, because the system re-uses SIP Digest authentication, it doesn t require any changes to the IMS core. However, because the IMS core can t see the difference between regular SIP Digest and RFID Digest, it is especially important that RFID Digest is secure. If it would be less secure than regular SIP Digest, this would mean that RFID Digest could become a vulnerability to IMS itself. To make sure this is not the case, it is important to take a look at the different vulnerabilities of RFID Digest. This will be the topic of the next chapter.

45 44 / 97 5 RFID Digest security considerations The fifth research question, one that the previous chapter has tried to partially answer, is the following: 5. How can the new form of identification be integrated into IMS-based IPTV in a secure way? Even though the previous chapter has described how SIP Digest is used to seamlessly integrate RFID Digest in IMS-based IPTV, the security component of the question has been ignored up until now. One could simply argue that if SIP Digest is secure, and RFID Digest completely reuses SIP Digest, than RFID Digest must also be secure. However, this argument does not hold. The client-side nature of RFID Digest is completely different from SIP Digest and could therefore introduce new vulnerabilities. The total security of a system is determined by its weakest link and it is therefore required to analyze RFID Digest as if it is a new system, instead of a variant of SIP Digest. This is especially true in this case, because if RFID Digest would prove to not be secure, it could become a vulnerability to IMS itself; functioning as a way to get easy access to the entire system. What this section will do is try to do is identify the most important of RFID Digest s vulnerabilities and see if these vulnerabilities can be solved by making changes to the system. It should be noted that this chapter will in no way claim to identify each-and-every vulnerability of RFID Digest; only the most important issues will be described. Should RFID Digest ever be used in practice, than a more complete security analysis would be advisable. With RFID Digest, vulnerabilities can be divided into three different categories: Vulnerabilities related to the use of RFID and manifesting itself between RFID card and terminal (marked 1 in Figure 22) Vulnerabilities between terminal and IMS core, and related to the use of SIP Digest (marked 2 in Figure 22) And finally, vulnerabilities related to the terminal itself (marked 3 in Figure 22) In this chapter, the three categories will be handled in Section 5.3, 5.4 and 5.5 respectively. Figure 22: Categorizing security vulnerabilities In order to properly assess the importance of these security issues, it is necessary to place them in the right context. Therefore, Section 5.1 will first discuss this context very briefly. After this, Section 5.2 will introduce the concept of security domains and their relation to RFID Digest.

46 45 / Understanding the security context An identification and authentication system is never 100% secure; in the same way that no building is 100% safe. With enough resources it will always be possible to break in to any building or exploit any computer system. Because of this, the goal of securing a system is not to make it 100% secure, but to make it so secure that exploiting it is not worthwhile; the cost should be higher than the potential profit. This is also true the other way around: If the cost of securing something is higher than the loss of somebody stealing it, than it is probably not worth securing. A useful analogy can be found in the credit card world. For many years it has been known that there are vulnerabilities in the way credit cards are secured. However, it is very expensive to replace all credit cards. So instead of solving the security problems, banks accept the risk of somebody using them illegitimately and just refund the victims (the individuals whose credit card has been used); the cost of refunding a small percentage of customers is less than the cost of replacing every credit card. Similar situations can be found in all kinds of businesses. Going back to RFID Digest, it should be remembered that it is a system that identifies TV users; it is not a system with which users transfer thousands of Euro. Accordingly, it would make sense if it is not as safe as an online-banking application. RFID Digest should only be as secure as any other application that allows users to watch subscription TV channels and pay small amounts of money for pay-per-view like applications. From a TV provider point of view, the worst that could happen if someone gained illegitimate access is that he or she could watch TV channels which he isn t subscribed to. Of course the above doesn t mean that security is not an issue; it means that security vulnerabilities should be placed in the right context. A good requirement for RFID Digest, and one that has already been mentioned a number of times earlier, is that RFID Digest should be at least as secure as SIP Digest as not to become a vulnerability to IMS itself. 5.2 Defining security domains Before delving into an analysis of the vulnerabilities of RFID Digest, it is interesting to first look at its nature in the context of security domains. A security domain can be defined as a group of systems of which the responsibility is within the hands of a single individual or institution. The concept of security domains can best be illustrated by looking at the following diagram. Figure 23, shown below, illustrates the different security domains found in the internet world. The main players here are the subscriber and the Internet Service Provider (ISP).

47 46 / 97 Figure 23: Security domains in the internet world. Circles represent different security domains. The ISP provides the subscriber with the means to enable him to access the internet. Apart from a physical connection, the subscriber also requires a modem. This modem is issued by the ISP who, in most cases, also remains the owner of the modem, even though it is placed within the subscriber s home. Everything up to, and including, the modem is the responsibility of the ISP; should anything go wrong anywhere between the modem and the ISP s authentication center, the ISP is to blame. The modem and authentication center, and anything in between, are therefore part of the ISP s security domain. Any devices placed, and connections made, after the modem are no longer the responsibility of the ISP. The ISP only has the obligation to make sure the modem is securely connected to the internet. If the subscriber chooses to connect a wireless access point to the modem and, by not configuring it right, allows the neighbors to read his messages, this is the subscriber s responsibility, not the ISP s. Everything after the modem can therefore be considered the Subscriber Domain. A similar example can be made for the mobile telephony world, shown in Figure 24. Here, the mobile operator s domain stretches very far, even into the subscriber s devices: in the form of the SIM card in the subscriber s mobile phone. This makes for a far more controlled environment, making the subscriber domain very small, or even non-existent.

48 47 / 97 Figure 24: Security domains in the mobile telephony world The security domain analysis can also be made for IMS-based IPTV. The notable thing here is that with IMS-based IPTV the nature of the security domain depends on the used authentication system. With IMS-AKA, the security domain diagram is practically the same as the one for the mobile telephony world shown in Figure 24; the UICC is part of the TV operator domain, resulting in that domain extending into the user s devices. SIP Digest on the other hand, has a very small operator domain. It is not possible for the operator to be responsible for the user keeping his password a secret, the password is therefore part of the subscriber s domain. With RFID Digest, the situation is again completely different. The question here is if the RFID card is the operator s responsibility or the subscriber s. One could argue that an RFID card can be compared to a UICC, in the sense that it is issued by the operator so that the operator is responsible for making sure it is secure. On the other hand, a UICC is a closed environment. Even though it is in the user s mobile phone, neither the user nor the mobile phone is able to extract security-related information from it; all cryptographic ciphering is performed internally and the outside world (user and mobile phone) does not come into contact with the shared secret. This is different from an RFID card. It is the user s terminal (the TV or STB) that extracts the information from the RFID card and performs the cryptographic ciphers with it. Theoretically it would be possible for the user (or any other person having access to the terminal) to extract the information from the terminal and use it for personal gain. From this point of view it would make sense to make the RFID card part of the subscriber s security domain. It is not possible to make a clear decision here to which security domain RFID cards should belong. It is however something that will need to be thought about before RFID Digest is used in practice. 5.3 Vulnerabilities of SIP Digest Now a number of general security-related issues have been discussed, it is time to move on to specific vulnerabilities of the RFID Digest system. The part of RFID Digest that communicates with the IMS core is regular SIP Digest. This means that in order to assess the security of RFID Digest, the security of SIP

49 48 / 97 Digest should also be assessed. The following three subsections will each identify a specific vulnerability of SIP Digest. While some of these vulnerabilities are the same in RFID Digest and regular SIP Digest, some are also partially solved by RFID Digest Security of shared secret One of the main problems with regular SIP Digest is the nature of its shared secret. Systems based around humans memorizing passwords and typing them in every time they log in are inherently vulnerable. The problems begin with the limited capacity of the human brain to remember large strings of independent numbers and letters. Because of this, humans tend to choose relatively simple passwords often forming a word or a combination of words and short numbers. This makes a password created and remembered by humans especially vulnerable to two types of attacks (apart from the obvious vulnerability of a user writing the password down somewhere). First is the brute force attack. A brute force attack exhaustively tries every possible combination of letters and numbers until it has found the password. Because human-created passwords are often relatively short, the time it takes a brute force to guess it is relatively short. The second type of attack to which passwords are vulnerable are dictionary attacks. The human brain can more easily remember actual words that make sense than random strings of letters, and therefore usually choose actual words as their password. Dictionary attacks exploit this by performing a specific type of brute force attack; this time not by guessing every possible combination but by simply trying a list of actual words (such as is found in a dictionary). One of the advantages of RFID Digest compared with regular SIP Digest is that it is not based around user-memorized passwords. It is therefore not prone to the type of attacks described above. Instead of having passwords that should be easy to remember, RFID Digest uses a random 254-bit key. Current brute force attacks should have considerable difficulty defeating 254-bit keys. What all this means is that this specific vulnerability of SIP Digest, the fact that is based on user-memorized password, is solved with RFID Digest. One could therefore argue that this makes RFID Digest more secure than SIP Digest, at least in this area Moment of detection There is another security issue related to user-memorized passwords. One in which switching to physical RFID cards makes another contribution to a more secure system: the moment of fraud detection. Whatever the security measures taken in an authentication system, there will always be some, however small, chance that at some moment in time, a user account will be compromised. For this user, it is no longer important how this happened, but it is important when he finds out. If the user finds out relatively quickly, he is able to contact his TV operator and block his account so that it cannot be used. On the other side, if the user only finds out later (when receives his bill for example) or even never at all, the damage has already been done and he may have to pay a huge bill or suffer the consequences of his identity being stolen. The moment of fraud detection depends on a number of factors. One of them is the nature of the authentication system used. Because SIP Digest depends on a user memorizing a password and not on a hardware token, there is no way for the user to know if his account has been compromised. Someone may have been reading over his shoulder when he was typing in his password or a key-logger may have recorded and stored the password. Either way, the person committing the fraud can use the password to log in without the user finding out. IMS is especially vulnerable to this since it allows multiple devices to be logged in with the same account simultaneously (a concept

50 49 / 97 known as SIP forking). To sum up, it could be a long while before the user finds out, if the finds out at all If RFID Digest is used, the most probable way an account will be compromised is if someone steals a user s RFID card. Since the user will no longer be able to log in, he will probably find out relatively quickly (probably within a matter of hours). This means that the user can act and possibly prevent any damage from being done. Of course it is also possible for the user s identity being stolen in another way (such as the IMPI and password being intercepted on the terminal handling the authentication) which is equally unnoted as is the case with somebody stealing a password, in all of these cases RFID Digest does not improve on the regular SIP Digest situation. However the fact that a user-memorized password has been changed to a physical token makes that RFID Digest is again somewhat more secure than SIP Digest Message confidentiality and integrity One aspect of RFID Digest that is not different from SIP Digest is its message confidentiality and integrity protection; the systems that protect the data being sent between IMS core and terminal. IMS AKA relies on IPSec, more specifically IPSec ESP (IETF, 2005), to provide message confidentiality as well as message integrity. IPSec makes that the complete path from terminal to P-CSCF in the IMS core is able to provide confidentiality and integrity guarantees. In order to function, IPSec requires a set of pre-determined session keys. In the case of IMS AKA, these are generated during the authentication process. Herein lays the problem for SIP Digest. IPSec Internet Protocol Security (IPSec) is a suite of protocols for securing IP communications by authenticating and encrypting each IP packet of a data stream(stallings, 2007). IPSec is a host-to-host protocol, working at the network layer. In order to work, IPSec requires a set of pre-determined session keys. IPSec consists of three parts: the Authentication Header (AH) protocol, the Encapsulating Security Payload (ESP) protocol and the Internet Key Exchange (IKE) protocol. Most important in the context of this chapter is the ESP protocol. ESP provides origin authenticity, integrity and confidentiality protection of packets. ESP can function in transport mode or in tunnel mode. In transport mode, which is used by IMS AKA, ESP encrypts the payload of an IP packet while keeping the IP header intact. However, since the payload is encrypted, it is no longer possible to translate the IP addresses in the IP header since this would invalidate the packet checksum/hash. When ESP operates in tunnel mode, the entire original IP packet is encrypted and a new, unprotected, IP header is added. The original version of the SIP protocol (specified in RFC 2542, (IETF, 1999)), while supporting both UDP as well as TCP, only obligated user clients to support UDP. This made it a connection-less protocol. It was therefore required to use a network-layer security protocol: IPSec, which works regardless of the used transport layer protocol (TCP or UDP). However, since SIP Digest authentication does not generate the for IPSec required session keys, it is not possible for sessions established with SIP Digest to use IPSec. This makes SIP Digest authentication a very vulnerable path to choose, since it leaves the connection between terminal and P-CSCF open to attacks. More recently however, newer versions of SIP (specified in RFC 3261(IETF, 2002)) have moved to a more connection-oriented approach. SIP clients based on this newer

51 50 / 97 version are obligated to support both UDP as well as TCP. This makes it possible to choose connection-oriented security protocols such as TLS. This is good news for SIP Digest authentication since it can now use TLS to protect the vulnerable path between terminal and IMS core. The most recent version of SIP (IETF, 2002) actually recommends using TLS instead of IPSec for SIP signaling. TLS Transport Layer Security (TLS) is set of cryptographic protocols that provide security and data integrity for communications over TCP/IP networks. TLS encrypts the segments of network connections at the transport layer (Stallings, 2007). TLS is an end-to-end protocol. Important to note is the fact the authentication procedures in TLS support both unilateral authentication, in which only the client is authenticated, as well as bilateral (or mutual) authentication in which both client and server are authenticated. Whether IPSec or TLS is preferred in the case of IMS is open to debate since both have their advantages and drawbacks. There is however a consensus (Nokia, 2002) that both protocols result in reasonably secure channels that are comparable from a security-level point of view (ETSI TISPAN, 2009) and offer message confidentiality and integrity. Where the protocols differ is in the moment the protection starts. In the case of IPSec (IMS AKA), the SIP control messages are protected from the moment the terminal sends the challenge response back to the P-CSCF/S-CSCF. This and all further messages are then protected by the IPSec security association. In the case of TLS (SIP Digest) the moment protection starts is when the initial registration is finished (after the terminal has received the Authentication OK message). In this area, IMS AKA with IPSec therefore has a slight advantage over SIP Digest with TLS. To sum up: RFID Digest inherits its message confidentiality and integrity system from SIP Digest. Once the connection is set up properly it is relatively secure, comparable with IMS AKA. However, in contrast with IMS AKA, the protection only starts after the connection has been set up, which means that the complete authentication procedure is not protected. 5.4 General RFID vulnerabilities Now various security vulnerabilities related to SIP Digest have been discussed, the next step is to look at the potential vulnerabilities on the RFID side of the terminal. With the ever more increasing use of RFID within our society in recent years, a lot has been written on the topic of RFID security. Most papers on the subject distinguish between two sets of issues: privacy related and authentication related. One way to describe these two categories is the following (from (Juels, 2006)): privacy concerns the problem of misbehaving readers harvesting information from well-behaving tags, while authentication concerns the problem of well-behaving readers harvesting information from misbehaving tags (counterfeit ones). In this section, the focus will primarily be on the latter: counterfeit tags who claim to be something they are not; or, in the case of this project, users who claim to be someone they are not. (Privacy issues are not considered here because users will mostly use their tags in controlled environments; at home or at friends) Cloning of RFID cards in general A recent paper, (Juels, 2006), divides RFID tags in two categories: simple tags that do not feature authentication mechanisms and tags containing symmetric key mechanisms (since public-key cryptography is not yet widely used in RFID, this category is not

52 51 / 97 considered). The Mifare Classic card used in this project obviously falls in the second category. Within the category of symmetric-key tags, the problem of counterfeit tags is primarily composed of cloning. Cloning refers to the activity of duplicating an RFID tag in its entirety so that for an RFID reader it is impossible to distinguish the duplicate from the original. In practice, cloning a symmetric-key tag usually follows the following three steps: 1. First the cryptographic protocol used inside the tag is reverse-engineered. This step usually (but not necessarily) involves determining the physical structure of the tag s integrated circuit. This can for example be done with a microscope and image recognition software (Karsten, 2008). 2. With the cryptographic protocol known, it is implemented on a dedicated hardware setup. Using this setup, a form of brute force attack is carried out. With only a few plaintext/ciphertext pairs (that can be obtained by simply eavesdropping on legitimate transactions), the brute force attack can recover the secret key belonging to the plaintext/ciphertext pairs. 3. The third and final step in the cloning process is constructing a programmable radio device that simulates the output of the original tag. The general cloning-process described above is based around a number of vulnerabilities that are found in most commercial RFID products. Since most RFID tags use relatively short secret keys (in the Mifare Classic 48-bit long, but often 40-bit or even 32-bit) that are vulnerable to brute force attacks, the cryptographic protocol used in the tags are often proprietary and not published, relying on a concept known as security through obscurity. What this means is that if the cryptographic protocol is somehow discovered (for example through physical examination), the entire security is left being dependent on the relatively short secret key. Under normal circumstances, performing a brute force attack on an RFID tag with a 48- bit key length is relatively difficult. Most RFID cards have a mechanism that only allows them to be queried once every couple of milliseconds. What this means is that for an on-line brute force attack to be carried on a tag with a 48-bit secret key (and thus with 2 48 possible keys) and a 5ms delay between successive attempts; it would take more than 44,000 years to recover the key. Obviously, this is not practical. However, if the cryptographic protocol is known it is possible to build a hardware set-up that simulates the cryptographic protocol and allows an off-line brute force attack. Since this set-up does not have the 5ms delay between successive attempts, it is now possible to perform the brute force attack much more quickly; in a time-frame that is more useful in regular circumstances. Depending on the used hardware, such an attack can be carried out in between one week (with a regular desktop PC) and a couple of hours (with dedicated hardware) (Karsten, 2008) Cloning the Mifare Classic and possible solutions The cloning process described above has also been carried out on the Mifare Classic. In a number of a much-publicized reports by amongst others the Radboud University Nijmegen (Verdult, 2008) (Koning Gans, 2008), it was shown that the Mifare Classic is especially prone to the type of cloning process described above. A number of weaknesses in the design of the card (particularly in relation to the random number generators) make that a brute force attack is possible that results in the secret key being able to be recovered by a regular laptop within two minutes. The obvious question know is: Does the fact that it is possible to easily clone the Mifare Classic card make that the RFID Digest system is less secure? The short and simple answer here is yes; if no additional security measures are taken into account, cloning

53 52 / 97 could indeed become an issue for RFID Digest. There are however a number of options that can prevent this from happening. The first and most obvious solution would be to simply use another type of RFID card. There is no reason the RFID Digest system, with some minor adjustments could not be ported to another type of RFID card. The recent Mifare Plus card would be a good candidate for this. This card features exactly the same memory organization as the Mifare Classic, with the only difference being its security system. Instead of relying on proprietary security through obscurity cryptographic protocols, it uses the widely accepted Advanced Encryption Standard (AES). Since the Mifare Plus is compatible with the Mifare Classic, it would fit seamless into the existing RFID Digest architecture. The only disadvantage of the Mifare Plus is that it is more expensive than the Mifare Classic. If for some reason or another (such as cost) it is not deemed desirable to replace the Mifare Classic with another card such as the Mifare Plus, there is another option to prevent cloning from becoming a serious problem. This system, which has been developed by the Radboud University Nijmegen, is based around detection rather than prevention (Teepe, 2008) Detecting cloned cards In (Teepe, 2008) a technique is presented that allows readers to detect if RFID cards have been cloned. More importantly, it provides a technique to block counterfeit cards without harming the originals cards that have become the victim of cloning. This system will now be briefly explained. Readers interested in knowing all of the details are referred to (Teepe, 2008). The proposed system consists of two parts. The first part is the clone-detection mechanism. This is a relatively simple system that could also be implemented standalone. The second part is the mechanism that is able to check which of the cards is the original and which is the counterfeit and then use this information to block the latter without harming the former. This clone-blocking mechanism is considerably more complex to implement. The clone detection mechanism is based around the concept of a counter. This counter is implemented as a value block that can only be decremented (through access condition setting 001 from Figure 17). When a user receives his RFID Digest card, this counter is initialized at its maximum value (2 32-1). What happens is that every time a user uses his card to log in or out, a transaction takes place. When this happens the counter is decreased by one and the reader stores a transaction report, noting the UID of the card, the value of the counter and a timestamp. This report is then sent to a central server which stores the transaction record together with all other reports of the same card. If all goes well, the list of a specific card should only show decreasing counter values. If this is not the case, then there is probably a clone somewhere. It should be noted that the system described above allows a counterfeit card to be used before it is detected. If a card has been cloned, the system only recognizes this after both cards (the original and the counterfeit) have been used to log in at least once. This means that the moment of detection is when the legitimate user tries to log in after his card has been cloned (and used) and it is thus possible for a counterfeiter to already have exploited the card. This is however not a big problem since it concerns a TV identification system. From the viewpoint of the operator the worst thing that could happen is that the counterfeiter has watched a few unpaid hours of TV; one could argue if this is even worth the effort of cloning a card at all.

54 53 / Blocking cloned cards In some situations detecting a cloning event to have happened is enough. It would for example be possible to block both cards (the original and the counterfeit) by blocking their UID. However this would not be really user-friendly for the victim, whose card has just been cloned. He would then have to wait for the TV operator to send him a new card. A better solution would be to implement the second tier of the clone detection system that provides a method to only block the counterfeit card and leave the original alone. This clone-blocking system relies on the way the cloning process functions. As has already been explained in the previous section, part of the cloning process relies on performing a form of brute force attack to recover the card s secret keys. For this type of attack to succeed, a number of plaintext/cipher-text pairs, built with the to-berecovered key, are required. These pairs are found by eavesdropping on legitimate transactions between card and reader. The clone-blocking method requires each RFID card to have two additional types of parameters stored on it: The first is a unique Flexible Card Identifier (FCID) in addition to the regular UID. The second is a number of data-test sectors. Instead of the usual method of giving all RFID cards the same secret keys, these data-test sectors have unique keys; different for each card and for each data-sector. Finally, the sectors contain unique data. During normal operation, the data-test sectors are left untouched; since they are not used, it is impossible to obtain plaintext/ciphertext pairs for these sectors by eavesdropping on legitimate transactions. With no plaintext/ciphertext pairs, it is impossible to obtain the sectors secret keys and it is thus also impossible to clone these data-test sectors. The clone-blocking method works by using the unique data-test sectors for legitimacy tests. Every time a card is suspected of being a counterfeit, a legitimacy-test is performed. By simply trying to access one of the data-test sectors and seeing if the secret key gives access to them, it is possible to distinguish the original card from the counterfeit one (which cannot possibly contain the unique key since these could not have been cloned). If the legitimacy test gives access to the sector, the data inside is read. If this data is also confirmed to be correct, the card is proven to be the original. It is then given a new FCID and a new record in the central server. The old FCID is then blocked. If the legitimacy test does not give the reader access to the data-test sector, the card is clone and the card s FCID is blocked. The next time the original card is presented, a new legitimacy test is performed on another data-test sector and, if successful, the card is given a new FCID and server record. The mechanism described above relies on the fact that a single data-test sector can only be used once; after this, the safety of its key can no longer be assured. This means that the server should keep a list for each card which of its data-test sectors have been depleted. Since a card can only contain a limited number of data-test sectors, at some point in time a card s data-tests sectors may be depleted. At that moment there are three possible options: After the data-test sectors have been depleted, the card is simply blocked and its user needs to contact the card issuer for a new one. After a number of data-test sectors have been depleted (but not all), the central server notices this and sends the user a message that his card is about to expire. The user then has time to go to a certified terminal where, in a controlled environment where eavesdropping is not possible (such as a terminal with a Faraday cage), his card can be loaded with new data-test sectors After a number of data-test sectors have been depleted (but not all), the central server notices this and the card issuer automatically sends the user a new RFID card.

55 54 / Problems The third of these options is probably best suited for a TV environment, since the first is not very user-friendly and the second one is more suited to a public transportation system where recharging terminals are abundant. It should be noted that in reality, the event of a card being depleted should be very rare; it could only happen if a single card is the victim of repeated cloning efforts. In the previous sections a number of solutions have been given to the problem of cloning RFID cards. There is however one issue with all of these solutions which up until now has not been discussed. This is the issue of requiring changes, or additions, to the server side of the system. Up until now, one of the advantages of the RFID Digest system has been that it presents a number of new features not previously possible, without requiring any changes to the server side; not as part of the IMS core, nor in any other way. By implementing the security measures just described, this advantage is partially removed. Although changes to the IMS core itself are still not required, there needs to be some server that handles RFID clone detection and blocking. One possibility is to solve this issue is by making RFID clone-detection and blocking provider-specific. This way it is still possible to give providers the option of additional security, without making it mandatory and therefore requiring a standardized approach. The same technique can be found in GSM and UMTS, where some security-measures are provider-dependent, with some using them and some not. 5.5 Specific RFID Digest vulnerabilities In the previous two sections vulnerabilities related to the use of RFID and the use of SIP Digest have been discussed. Perhaps the most important vulnerability however, is the terminal (TV/STB) itself. A UICC, which is used in IMS AKA, offers a protected environment. Not only does it serve as a way of storing the shared secret, it is also the only device that comes in direct contact with the shared secret; all cryptographic ciphers are computed internally, which means that the terminal which houses the UICC only comes into contact with the computed ciphers. This way the security level of the terminal can be the same as that of any other node along the path from UICC to IMS core. This is different with RFID Digest. In RFID Digest, an RFID reader reads the shared secret from the RFID card and passes it directly to the terminal. The terminal is then the place where computation of cryptographic ciphers takes place. This means that the terminal is in direct contact with the shared secret. Obviously, this presents a vulnerability; should the terminal be compromised, it is possible for it to store the shared secret for later use. (It should be noted that the same situation is present in SIP Digest, where the terminal also comes in direct contact with the shared secret.) This issue brings up the concept of security domains and responsibility again: who is responsible for the terminal? In the case of STBs, the TV provider is often the owner, in the same way that ISPs often own internet modems. In the case of TVs or PCs, the customer is the owner. Another issue is the question who has the most interest in keeping the user credentials safe. On the one hand, for the user it is important that no one performs identity theft; using the user s credentials to buy things or access his private information. On the other hand, for the provider it is important that a user can only access what he has paid for; if an identity is stolen, somebody can watch somebody else s subscribed TV channels without paying for it; resulting in less profit for the TV provider.

56 55 / 97 Before RFID Digest can be used in practice, it is important to answer these questions and have a clear notion of who is responsible for what. In the case of RFID Digest terminals, it would probably be best to use closed-environment STBs owned by the TV provider. Illegitimate modification would be more difficult than on a PC, on which it is easy to install malevolent software. In this case, the STB would fall in the TV provider s security domain. If this would indeed be the case, then there is one vulnerability left: the connection between RFID reader and STB. (Of course this would only be an issue if external RFID readers are used instead of built-in ones.) To solve this vulnerability it would be an idea to provide an additional security layer between terminal and RFID reader. An example of such a layer would be to have the user credentials on the RFID card be stored in an encrypted form. After receiving the encrypted credentials from the RFID reader, the (secure) STB would then decrypt the credentials before using them in the SIP Digest authentication process. The decryption keys could be stored in a tamper-resistant memory module inside each STB, in the same way RFID keys are stored in a similar module inside RFID readers. 5.6 Conclusion The goal stated at the start of this chapter was to identify a number of RFID Digest vulnerabilities and see how these could possibly be solved. At the same time a general idea of the security level of RFID Digest could be obtained, enabling one to compare it with the other IMS authentication methods: IMS AKA and SIP Digest. It is unrealistic to think the security level of RFID Digest is comparable with IMS AKA; the fact that IMS AKA uses UICCs makes that it is simply more secure. This is mainly due to the fact that in IMS AKA, all cryptography-related functions are carried out internally by the UICC. In RFID Digest these tasks are carried out by the terminal (the TV or STB). This alone makes that RFID Digest can never be as secure as IMS AKA. It is more realistic to compare RFID Digest with SIP Digest, to which it is related. On the one hand, RFID Digest solves several serious vulnerabilities present in SIP Digest by not using user-memorized passwords. On the other hand, the replacements of these passwords, the RFID cards, introduce their own set of problems. Of course it is not possible to quantitatively compare two types of vulnerabilities and say which is worse. However, it is possible to look at the possible solutions for both types of problems and see which offers the most potential of being solved. In the case of SIP Digest, the vulnerabilities are mainly related to the use of usermemorized passwords. In this case there is no clear solution since passwords form the essence of SIP Digest. In the case of the problems introduced by the use of the Mifare Classic card, there are a number of possible solutions: From completely switching to another type of (compatible) RFID card to implementing a clone-detection and blocking mechanism; there are options available. Based on these observations, it is safe to say that RFID Digest is at least as secure, if not more secure, than SIP Digest. One final vulnerability, which is the same for RFID Digest and SIP Digest (and for any other password-based mechanism for that matter) is the client-side terminal. These terminals are a vital part to the overall security since they come into direct contact with the shared secret; if a terminal is compromised then the security of the shared secret can no longer be guaranteed. In the last section of this chapter it was therefore advised to

57 56 / 97 keep these terminals as closed as possible and not provide access to the terminal from the outside (by letting customers install additional applications for example).

58 57 / 97 6 Performance evaluation The goal of this chapter is to answer the sixth research question: 6. In what way does the proposed system affect total system access time? And related, to this: What are acceptable times for TV systems in general? The term total system access time used in the above research question is very generic; it can refer to a wide variety of access times. In the case of an IPTV system it could for example refer to the time it takes a TV to react to remote control input, the time it takes a TV to switch between channels or the time it takes to connect to an IPTV server. In the case of this chapter it refers to the time it takes a TV to boot ; the time between a user pressing the on button on the remote control and that user seeing video and hearing audio content. For sake of clarity, this time will from now on be referred to as boot time. In the case of a TV system using RFID Digest, the total boot time depends on a number of factors in addition to those factors also present in other TV systems (such as the time it takes video codecs to initialize). The two most important RFID Digest-specific factors specific are the extraction of the user credentials from an RFID card and the SIP Digest authentication procedure. The SIP Digest mechanism takes a minimum of three Round-Trip-Times (RTT) to complete (for more information see A.2). This means that a typical SIP Digest authentication process can easily take from several hundreds of milliseconds up to several seconds. This process however, is not unique to RFID Digest. Both regular SIP Digest and IMS AKA also require a minimum 3 RTT for their authentication processes. This means that in order to describe the impact of RFID Digest on system boot time, the Digest authentication process can be ignored. This leaves the RFID reading operation as the sole component of RFID Digest that needs to be measured. 6.1 Current practices A measurement on itself, however, has no meaning. In order to properly judge the impact of RFID Digest on TV boot time, some form of reference or benchmark is required; something like an average TV boot time number. Unfortunately, no such a number exists; that is, up until now no one has published research on the topic of TV boot times. Almost all access-time related research in the TV world is focused on channel zapping times instead of boot times (Kooij, Ahmed, & Brunnstrom, 2006). As a spin-off of this thesis project, a project was started within TNO that aims to solve this empty space in TV research; a project with the goal of finding the average TV boot time. This project is linked to an elementary school science project carried out by TNO. As a part of this project, school children are encouraged to measure the boot time of their TV at home and send this information to TNO. Using this approach, it is possible to quickly gather lots of measurements. Unfortunately, at the time of writing, the results of this project are not yet in. Since the TNO project has not yet concluded and no other research on TV boot times has been published, it has been decided to carry out a short survey as part of this project. A large scale study is not possible due to time-limitations so the survey has been kept short. Using a simple stopwatch the boot times of a number of TVs have been tested. The TVs tested included both LCD TVs as well as traditional CRT TVs (since these TVSs still make up the majority of the TVs in living rooms). The survey measures the time it takes a TV to both show video and output audio content after the user has pressed the on button on the remote control. All tests were performed with the TVs being in the standby mode. The results are displayed in Figure 25.

59 58 / 97 Figure 25: TV Boot times survey As can be seen, boot times of the tested TVs vary between slightly less than 6 seconds to almost 15 seconds. With an average of about 8 seconds. 6.2 What is considered acceptable? The research question stated at the start of this chapter can be answered in two ways: quantitatively or qualitatively. An example of a quantitative answer would be: RFID Digest increases TV boot time with 2.4 seconds for a total of 7.5 seconds For the quantitative answer all that is required is a measurement and a reference (such as the average TV boot time obtained in the previous section). To qualitatively answer the question however, and make statements like The impact of RFID Digest on TV boot time is acceptable to the average user, another form of reference is required; a measure indicating what the average user thinks is an acceptable TV boot time. In order to obtain this reference, a small survey has been carried out. This survey consists of test participants repeatedly turning on a TV. In this case the TV is a custom made Flash application that varies the delay between the user pressing on and a video starting. The test subjects were then asked to judge the delay (the TV boot time) on the Mean-Opinion-Score (MOS) scale (ITU-T, 2006). Figure 26: MOS Scale The MOS scale is a scale originally developed by the International Telecommunication Union (ITU) that allows test participants to quantify the quality-of-experience (QoE) of multimedia applications. Figure 26 shows the scale in its entirety. By having participants experience and judge different boot delays in the Flash application, it is possible to obtain an idea of the acceptability of TV boot times in general. In the survey, a total of five different boot times were tested, ranging from 1 second to 10 seconds. Each person taking part in the test was subjected to the same five delays, albeit in random orders to make sure there are no fixed patterns that might affect test results (such as all increasing or decreasing delays). One effect that might be harmful to the accuracy of the test results is the following: if users turn on the TV several times in a row, they might subconsciously associate this

60 59 / 97 behavior with channel zapping instead of turning a TV on/off repeatedly. Since delays in zapping are generally lower than boot delays, users might judge the delays experienced in the test more harshly, since they experience them as zapping delays instead of boot delays. To circumvent this effect, participants were divided into groups of 3 to 5 persons. They were then queued up somewhere where they could not directly see the TV. One at a time, the test subjects were asked to come forward and turn on the TV. After the test subject scored the delay on the MOS scale, he/she was asked to return to the end of the queue and wait until it was his/her turn again. This way there were several minutes between each test event, so subjects would experience each turn on event as a separate event. Figure 27: Configuration of test parameters (number of testers on the left, boot delays on the right) Figure 27, shown above, shows how the Flash application can be configured for different numbers of testers and different boot time delays. In Figure 28, an overview of one test event is given; from standby to delay to video and to standby again

61 60 / Figure 28: One test event. From top left to bottom right: the TV in standby mode (1), the TV boot delay (2), the TV in on mode (3) and the TV in standby mode again (4). The question posed in the second part of the research question stated at the beginning of this chapter is up until what point boot times can be considered acceptable; in other words, when do boot times get unacceptable? The MOS scale defines MOS 2 to be the point where participants find the delay annoying and MOS 3 to be the point where they find the delay slightly annoying (see Figure 26). Of course one could argue whether unacceptable means annoying or slightly annoying. Whichever is taken to be true, Figure 29 shows the results of the survey carried out with a small set of participants. Figure 29: Acceptability of boot delays It is interesting to see that the majority of participants experience boot times of 5 seconds or more to be annoying. This means that the average boot time of current TVs (which the previous section found to be 8.3 seconds) is considered annoying by the majority of participants. 6.3 Performance impact of RFID Digest Now two types of benchmarks, a quantitative one and a qualitative one, have been obtained it is time to look at the main subject of this chapter: the impact of the RFID Digest identification and authentication system. In Chapter 4, the design of the RFID Digest system was discussed. In that chapter it was made clear that in order to store all IMS user credentials, a relatively large number of sectors of the Mifare Classic RFID card were required (2 per IMPI/IMPU and one for the shared secret K). It was also shown that the way the Mifare Classic works is that a separate authentication procedure is required for each sector. This means that in order to read the minimum set of user credentials (the IMPI, one IMPU and K) a total of five sectors need to be read and therefore authorized for (seven if the proposed two IMPUs are read). The specifications of the Mifare Classic card (NXP Semiconductors, 2008) clearly state the time it takes the Mifare Card to perform different actions. These times have been

62 61 / 97 summed up in Figure 30. Although the different transaction times stated in the diagram cannot be 100% confirmed to be correct, since they come from a document written by the card s manufacturer, some brief validation measurements that have been carried out prove that they are at least in the right order of magnitude. Figure 30: Mifare Classic transaction times With the information from the diagram above, it is possible to calculate the time it takes the RFID Digest system to extract the user credentials from an RFID card. In the case of the minimum set (the IMPI, one IMPU and K) this amounts to the following: One identification and selection operation (assuming no collision takes place, 3.0 ms) Five authentication procedures; one for each sector (for a total of 10 ms) Twelve Read Block operations; five each for the IMPI and IMPU and another two for the shared secret K (for a total of 30 ms) This means that the total set of operations should take no more than 43 ms. Even if both available IMPUs would be read from the RFID card, the reserved data blocks (see 4.4) of all credential sectors would be used and an additional sector full of user profile information would have to be read, the complete set of operations would only last 79 ms. The above analysis shows that the total time required to extract user credentials from an RFID card is relatively small; so small that it is dwarfed by the average time it takes a TV to boot (8.3 seconds). Furthermore, even if the total RFID operation would be added to the current TV boot time, the effect would be minimal and user would be unable to notice it. The research question posed at the beginning of this chapter can therefore be answered positively: the effect of RFID Digest on total system access time is negligible.

63 62 / 97 7 Prototyping multi-user TV using RFID Digest In the first chapter of this report a number of multi-user use cases were presented. When analyzing these use cases, it was then discovered that IMS-based IPTV, in its current form, does not provide the features necessary to successfully implement these use cases. To solve this problem, a new identification and authentication system, called RFID Digest, has been developed. RFID Digest s security level and performance has been assessed. However, up until now, it has only been developed in theory. This chapter will take the next step and actually implement the system in a prototype. Apart from functioning as a proof-ofconcept of RFID Digest, it also functions as a proof-of-concept for a personalized multi user application, proving that personalization and concurrency can successfully be combined in practice. Before the actual prototype can be built, it is necessary to decide on a use case on which to base the prototype. This goal is captured in the seventh research question: Which use case is most appropriate for demonstrating a multi-user TV application? and will be answered in the first section, Section 7.1, of this chapter. After the use case has been decided upon, Section 7.2 describes the general structure of the prototype. Then in Section 7.3, the implementation details of the prototype will be discussed. Finally in Section 7.4, a short demonstration of the final prototype will be given. 7.1 Deciding on a use case There are two main factors to consider when deciding on a use case that should form the basis for the multi-user TV prototype. First is functionality; the chosen use case should be able to show off the most important features and advantages of multi-user TV. Second is ease of implementability; the subject of this project is the development of a multi-user identification system, not the development of the perfect multi-user application. It would therefore be inefficient to spend a lot of time on the development of parts of the prototype that are not directly related to multi-user identification. In Section 2.3, three different multi-user use cases were presented: a multi-user interactive TV show, a personalized Electronic Program Guide (EPG) and multi-user Social TV. It would be logical to choose one of these three to form the basis of the prototype. While the multi-user interactive TV show is probably the best example of concurrent use, showing the essence of multi-user TV, it is a complex use case to implement. A complete system would have to be devised that delivers user-answerable questions and synchronizes these to video content. This requires a lot of work not directly related to multi-user identification. The same reasoning goes for multi-user Social TV. A use case that is relatively easy to implement, yet still shows of multi-user TV, is the personal EPG use case. Even though this use case does not show of concurrency and interactivity as well as the interactive TV show, it still shows how the individual experiences of several users can be combined into an improved collective experience. Since this use case is relatively easy to implement yet still shows a number of unique multi-user features, it will be the one that is implemented in the prototype. The following list of requirements shows the functionality of the proposed multi-user personalized EPG use case.

64 63 / It shall be possible for each user to have a distinct list of subscribed channel 2. It shall be possible for multiple users to be logged in at once. 3. It shall be possible for users to have access to a union of all channels the currently logged in users are subscribed to 4. It shall be possible to show a Electronic Program Guide that lists all of the channels the currently logged in users are subscribed to In order to show the fact that it is possible to place additional user profile information on the RFID card and use this information in a meaningful way, a fifth requirement, related to parental control, has been composed. 5. It shall be possible to mark specific channels as adult-only and have them disappear from the channel list and EPG when a child logs in 7.2 Deciding on a general structure In the previous section it was decided to build an RFID Digest prototype based on the multi-user personal EPG use case. In this chapter the general structure of the prototype will be decided upon Availability of IMS-based IPTV There is one major issue impeding the development of the RFID Digest prototype and that is the availability of an IMS-based IPTV test environment. Figure 31: Overview of RFID Digest Currently, TNO does not have such an environment. Although work is underway on one, it will not be finished in time for this project. What this means is that an essential part of the RFID Digest system, its connection with the IMS core, cannot be included in the prototype. One of the main advantages of RFID Digest is that it is able to interact with IMS without requiring any server side changes. The fact that in this prototype direct interaction with an IMS core is not possible does not mean this feature of RFID Digest should be ignored; it is an important feature and should be emphasized, also in the prototype. Apart from not being able to show how easy RFID Digest integrates with IMS, the lack of an IMS-based IPTV environment also means that some basic server-side IPTV functionality which is normally provided by the architecture, and which could have been used for the prototype, now needs to be specifically developed. Examples of such functionality are simple video broadcasting and EPG delivery mechanisms Replacing IMS nodes Under normal circumstances, the terminal on the client side (TV or STB) would communicate directly with the IMS core. However, due to the fact that the IMS core is not available for the purposes of building the prototype, new server-side architecture is required. A total of four entities are necessary: two nodes performing the duties of the

65 64 / 97 S-CSCF and HSS in the IMS core and two nodes performing the IPTV-specific functions of video broadcasting and EPG delivery. (Other IMS nodes such as P-CSCF are not strictly necessary and their functions can be integrated into whatever entity replaces the S-CSCF). In order to stress the importance of Digest authentication to RFID Digest (and through the use of SIP Digest the easy integration with IMS), it has been decided to use a HTTP Digest-capable HTTP server as a replacement for the SIP-enabled S-CSCF. By replacing SIP Digest with the very-similar HTTP Digest, the general concept is maintained. One could argue that it would also have been possible to replace the S-CSCF with a standard SIP server instead of a HTTP server. Even though this would have resulted in a more accurate representation of the IMS-enabled situation, this would have resulted in a considerable larger amount of work. It was deemed that the advantages of this scenario do not weigh up to the extra time required. The fact that with the transformation from SIP to HTTP the very session-control nature of IMS has been removed is not considered a problem for the purposes of showing the features and advantages of RFID Digest; which is ultimately the goal of the prototype. The most important thing is that Digest authentication, which forms an integral part of RFID Digest, has been maintained in the new situation. The actual authentication process between client and server is therefore practically unchanged from the IMSenabled situation, which should be enough in proving that RFID Digest can be seamlessly integrated with IMS. With the HTTP server performing the role of S-CSCF, another server-side entity is required to perform the role of HSS. For this a simple MySQL server has been chosen. Even though it is not possible to have the HTTP and MySQL servers perform the exact same roles as the S-CSCF and HSS, the overall picture is the same; the MySQL server performing the role of credential storage and the HTTP server handling the authentication itself (and contacting the MySQL server for credential information). Now the basic IMS entities have been replaced, it is time to move to the IPTV-specific server-side functions of IMS-based IPTV. For the Personal EPG use case, two of those are necessary: A video broadcasting node and an EPG delivery node. For the video-broadcasting node, a simple streaming video server with an RTP/RTSP channel has been chosen; of which a multitude are available free of charge. The EPG node is more difficult. The main issue here is that in the case of a multi-user personal EPG, there are a number of requirements not found in regular EPG applications, such as multiple customizable EPGs. It should be noted that if an IMSbased IPTV environment had been available, it might well have been that the EPG node would also have to be newly developed, since it is probable that IMS-based IPTV s EPG system would also have failed to meet all of the multi-user requirements. For the RFID Digest prototype, it has been decided to have the HTTP server already in place for Digest authentication also handle EPG requests. Another MySQL database provides the necessary EPG information. The advantage of this structure is that the HTTP server can use the same credentials obtained for authentication to generate a personalized EPG. Because of the lack of a proper IMS-based IPTV environment, the architectural structure of the prototype has changed from the architecture shown in Figure 31 to the one in Figure 32.

66 65 / 97 Figure 32: Structure of multi-user personal EPG prototype Another way to visualize the server-side entities discussed in this section is in a functional block diagram, shown in Figure 33. Instead of dividing the server components in blocks representing actual nodes, this diagram divides them into five functional blocks. An HTTP Server which is in charge of authentication and delivery of the EPG to the client. A User Credentials Database which contains a list of subscribers and their associated security credentials. An EPG Database, which contains detailed program information. An EPG Handler, which uses the information from both the user credentials database and the EPG database to generate a personalized EPG. A Video Server which delivers video content to the client Client-side structure Figure 33: Server-side block diagram Up until now, the discussion has mainly been about the server-side of the prototype. On the client side, similar decisions have to be made. Because of time constraints, the choice has been made to develop the prototype on a PC instead of on an STB. Implementing the prototype on an STB would have been possible but this would have required a considerable larger amount of time since for example a specific STB driver would have needed to be written for the RFID reader. Since the chosen USB RFID reader ships with a.net library, it has been decided to develop the client-side of the prototype mainly in C#.

67 66 / 97 Figure 34: Client-side block diagram The client-side of the system has been divided into the following five functional blocks: An RFID handler which is in charge of all communication with the RFID reader. Information extracted from the RFID card is passed on to the associated block (in case of IMS credentials to the Digest block but in case of additional user preferences also to the EPG or Video Client blocks) An EPG handler which processes and formats all EPG information received from the EPG server and sends it to the GUI. The EPG handler is also the place where personal EPGs of multiple users are merged. A Video Client that handles all communication with the video server. The Video Client block also handles codecs and channel selection. An IP Communication block that handles all communication with the IMS server (or in the case of this prototype the HTTP server). Its main purpose is performing HTTP/SIP Digest authentication, but it also the place where EPG information is delivered before it gets sent through to the EPG handler. A Graphical User Interface (GUI) that presents all information to the end-user. It is also where the user is able to interact (such as change channels etc.) Now the functional block diagrams of both server and terminal have been discussed, the remaining components are the RFID reader and card. Where both the client and server introduced new functional blocks that have to be developed from the ground up, the RFID reader and card are off-the-shelf components; nothing will be changed or added to them. Of course, the RFID card has to be programmed with the IMS user credentials, but this process has already been discussed in detail in Section 4.4. For sake of completeness, Figure 35 shows the functional block diagrams of both the RFID reader and the Mifare Classic cards. These diagrams have been re-created from similar diagrams in both products respective specifications (NXP Semiconductors, 2008). On the card side: An EEPROM module that stores the data kept on the RFID card. An Authentication module that handles all authentication-related matters with the RFID reader. A Cryptography block that contains all circuitry for computing the specific Mifare Classic cryptographic ciphers. A Control & Arithmetic Logic Unit (ALU) block that functions both as a central control module and as a simple ALU for adding and subtracting Value Blocks.

68 67 / 97 Figure 35: RFID block diagram When all of the functional block diagrams discussed up until now are combined, Figure 36 shows an overview of the functional structure of the personal EPG prototype. Figure 36: Complete block diagram Now the general structure of both the client-side and the server-side of the prototype is clear, the next section will detail with the exact implementations. 7.3 Detailed design In the previous section, the general structure of the multi-user personal EPG prototype has been discussed. This section will delve into more detail by discussing the exact implementation. While it would be possible for this section to describe each functional block shown in Figure 36 separately, this would not result in the clearest description of the prototype, since all blocks are interconnected. It has therefore been decided to divide this section in subsections based on functionality provided by the prototype. The server-side implementations for example will not be described in separate sections but will be discussed together with their client-side counterparts. This results in this section being divided into four subsections, dealing with RFID, Video, IP Communication and EPG Handling respectively (referring to the different functional blocks of the client).

69 68 / RFID Handler One of the most important components of the prototype is of course the RFID system. As has been explained in Chapter 4, the choice has been made to go with Mifare Classic RFID cards. For the prototype an ACR-120U USB RFID reader has been chosen. This reader has the advantage of being able to read a multitude of different types of RFID. This allows easy switching to another type of RFID if this should prove necessary in the future (for example because of the limited security of the Mifare Classic, see 5.4). The ACR-120U Software Development Kit comes with a low-level.net library that includes a number of commands to allow command-line communication with an RFID tag. The problem here is that programming an RFID card through a command line interface is very error-prone; especially with long binary strings representing keys and data blocks in which an error of a single bit can easily result in the blocking of an entire sector (by accidentally changing a sector s access conditions for example). Apart from being very error-prone, the low-level command-line interface also makes performing simple tasks a very tedious procedure, involving numerous commands. Reading and writing to a single data block for example could easily require five or more commands to the reader with a number of radix/unit-conversions required in between. Since the problems described above do not result in a very productive development environment, a solution has been devised that allowed more efficient use of the RFID reader. This solution consists of two separate components: a high-level communication library (that functions as a wrapper for the low-level library) and a Graphical User Interface (GUI) application based on this library. This two-tiered system allows applications (such as the prototype developed in this project) to just use the communication library while the GUI can be used to manage RFID cards. For the purposes of this document, the exact structure of the communication library and GUI is not very interesting. The important thing to note is that they allow most RFID operations to be executed with a single command or button; thereby simplifying the development and testing process. In Figure 37 a screenshot of the RFID Editor GUI is shown. Figure 37: Screenshot of RFID Editor Getting back to the prototype, two possible types of log-in procedures have been implemented, giving users or operators a choice of which to use:

70 69 / 97 Place/Remove In this log-in method, a user logs in by placing his RFID card on top of the reader. When he removes his card from the reader, he logs out. This technique cannot be used with more than four users simultaneously, since in that case the RFID reader is no longer able to distinguish the different cards. Swipe In/Swipe Out In this log-in method, a user logs in by swiping his RFID card in front of an RFID reader. The user than stays logged in until he/she swipes his card again. One final feature of the implemented RFID system is parental control (requirement 5 in Section 7.1). This system allows specific channels to not be viewable when children are present (regardless of subscriptions). In the RFID system, this is implemented with a specific flag in the child s RFID card. When the RFID Handler reads the user credentials from the RFID card, it also reads a parental control data block. When this block includes a byte indicating the card belongs to a child, the RFID Handler communicates this fact with the EPG Handler and the Video Client, so they can block access to adult-only channels Video component For the video broadcasting component of the prototype, both a streaming video server and a client-side video player are required. It has been decided to keep the server-side of the video broadcasting system as simple as possible; it is only used as a means to provide the prototype with some attractive video content. The choice has therefore been made to go with the all-in-one solution VLC (The VideoLan Team, 2009). VLC is one of the most used video streaming solutions and, due to its open source nature, offers a wide variety of features. It has been chosen for its functionality, its cost (free) but most importantly since it allows for a quick and easy video server implementation. For the connection between client and video server, an RTP/RTSP channel is used. The video server used in the prototype simply runs a number of VLC instances equal to the number of offered video channels. Each of the channels is sent out on a different port. As for the client side of the video system, the choice has been made to go with the Videolan.Interop (MeediOS, 2009) library, a library created by the VLC community. This library is basically a.net wrapper for VLC s libvlc.dll, which gives external applications complete access to VLC s large set of functionality and plug-ins. In IMS-based IPTV, access to video content is regulated through internal communication between the different IMS-based IPTV components. Since it would require a lot of work to implement this type of internal server-side communication for this prototype, it has been decided to use a simpler approach and have the video server be a completely separate entity, not directly connected to the HTTP server that performs authentication and EPG generation and delivery Having the video server not communicate with the authentication server, however, requires another form of access control. For this prototype, a simple two-tiered system has been developed. The first and most simple line of defense against illegitimate video server access is a simple username and password mechanism. When the user is authenticated by the HTTP server, the user s terminal is sent a message containing the current username/password combination of the video server. The terminal then uses this information to gain access to this server. This username/password combination, however, is only useful to control access to the video server itself, and cannot be used to differentiate between the different content streams hosted on that server. In order to allow different users access to different content (which is part of the personal EPG use case), another access control mechanism

71 70 / 97 is used: the Common Scrambling Algorithm (CSA). CSA is an algorithm that is most often used in the digital TV world (see 2.1). It scrambles video channels in a way that makes it impossible for terminals without a certain descrambling key to view them. In the prototype, the video server scrambles each video channel using a different CSA key. By controlling who gets and who doesn t get specific CSA keys, it is possible to control access to different channels. The role of CSA key-provider is played by the HTTP web server. More details about the exact way the HTTP server does this will be discussed in the next section. One final feature of the video subsystem is a low resolution option. Should, for any reason, the bandwidth between client and server not be enough for standard video to be broadcast, the client features a low-res button. When the user presses this button, the Video Client switches to a lower resolution stream. In the video server this is supported by simply providing two streams per channel: a low resolution version and a highresolution version. This simple solution to a problem that is often encountered in IPTV allows users to be in charge of the Quality-of-Experience (QoE). Instead of having to watch a choppy video broadcast, a user can now switch to a smooth, but low resolution, alternative. This simple innovation which was developed within this thesis project has now been included in the international RUBENS project, in which TNO is a partner IP Communication block In Section 7.2, it was decided to replace the IMS core, which is not available, with an HTTP web server and a MySQL server for the S-CSCF and HSS respectively. This means that HTTP instead of SIP is the main communication protocol between client and server. On the server-side, the HTTP server is implemented by using the free Apache web server (The Apache Software Foundation, 2009) software. On the client-side, the HTTP interface is implemented using standard functionality of the.net framework. Every time a user logs in, and the RFID handler extracts the user s credentials from his RFID card, these credentials are sent to the IP Communication block. The block then simply sends a HTTP GET message to the HTTP server. As a response, the server sends an authentication challenge and HTTP Digest authentication ensues (for details about this process, see A.2). After the HTTP server has validated the identity of the user, it generates a personalized EPG for the just-identified user and sends it to the terminal. Apart from regular EPG information, video server credentials and CSA keys for the user s subscribed channels are also included in this message. For more details on how the EPG is generated, see Section It should be noted that since HTTP is stateless, compared with the stateful S-CSCF SIP server used in IMS, it is currently possible for a user to be logged in at two different terminals at once; the HTTP server has no knowledge of a user s current status. A user logging out is therefore a local event and not communicated with the HTTP server (since it would not be of any use). This issue is something that would not have existed had a standard IMS-based IPTV environment been available; it is not a weakness of RFID Digest but of a simple serverside implementation. This issue is therefore not considered a problem but rather a simple limitation of the current implementation.

72 71 / EPG Handler In Section 7.2, it was decided to implement the EPG delivery system with a MySQL server that hosts the general EPG information and a HTTP server that generates a personal EPG from a combination of program information and user profiles. Apart from storing program information, the EPG database also stores user profiles (a user s subscribed channels) and video server information (port numbers and CSA keys). It consists of five tables: a networks (channels) table, a programs table, a timeslot table, a user table and a subscription table. For an overview of the database, see Figure 38. The networks table has one entry for every TV channel. Together with the channel name are stored the channel s port on the video server, its current CSA key (which can change over time) and a field describing if the channel is adult-only (restricted). The programs table identifies TV programs. This table is purely for EPG purposes and allows one to define different programs on each network which are broadcast during different timeslots (from the timeslot table). The subscriptions table is the table that defines which user (from the users table) is allowed access to which channels. For each channel a user is subscribed to (is entitled to watch), a separate entry can be found in the subscriptions table. Figure 38: EPG Database As has been discussed in the IP Communication block section, when a user logs in by swiping his RFID card in front of a terminal, he is authenticated by the HTTP server. When the user is validated, the server runs a PHP script that generates a personalized EPG in the following way: The user s IMPI is checked against the entries in the subscriptions table. Each channel the user is subscribed to is added to the personal EPG. Together with program information for that particular channel, the channel s port number and current CSA key is sent. These two properties allow a terminal to later contact the video server and request the channels the user is entitled to. The total EPG package is sent from server to client as a regular HTTP response. The EPG data is not formatted according to an established EPG data format but in a simple comma-separated-value-type-of format. A number of keywords represent the different data types included in the message. The reason for not using established EPG formats such as those developed by DVB is due to simplicity; it would take considerably more time to implement an extensive but complex EPG system than the simple scheme

73 72 / 97 proposed in this section, while for this prototype the advantages of such an extensive system are very small. Figure 39 shows an example of an EPG message such as used by the prototype. Figure 39: An example of an EPG package After the IP Communication block of the client receives the total EPG package, it forwards the complete package to the EPG Handler. This EPG Handler then processes the information in the package by recognizing the different keywords and creating the corresponding data instances (channels, programs etc.). Channel information, consisting of video server port numbers, CSA keys and adult-only flags is then sent to the Video Client block. The remaining pure EPG information is then converted to a more userfriendly graphical format, shown in Figure 40. When children are currently logged in, all references to adult-only channels are removed Overview Figure 40: Visualized EPG data. The red band indicates that the specific channel is adult only and is removed when children are present. When a second user logs in, the entire authentication process is repeated and the EPG Handler receives a new EPG package. The data contained in this package is simply merged with the existing data of the first user and added to the visual EPG and the Video Client, allowing the two users to access their combined sets of subscribed channels. In the previous section, a number of functional block diagrams were presented. Now the exact implementations of these block diagrams are known, it is possible to extend these diagrams with the communication lines and interconnections between these blocks. The following three figures will each show a part of the final prototype (server, client, RFID related) with an associated message flow description of the event of a user logging in.

74 73 / Advanced client-side block diagram Figure 41: Client-side block diagram with interconnections Overview of user log-in event A user swipes his RFID card in front of the terminal: 1) The RFID Handler performs authentication on the RFID card. 2) The card transmits the IMPI, IMPU and shared secret K to the RFID Handler. Also transmitted is a byte indicating if the user is a child. 3) The RFID Handler forwards the user s credentials to the IP Communication block. If the user is a child, this fact is send to the EPG Handler and Video Handler. 4) The IP Communication block contacts the HTTP server with the user s IMPI and performs Digest authentication using K. 5) The IP Communication block receives an EPG data package from the server. 6) The EPG data package is forwarded to the EPG Handler. 7) The EPG Handler processes the EPG data package and creates the necessary data instances. It updates the visual EPG with the newly received program information and sends it to the GUI. If a child is currently logged in, all references to adult-only programs or channels are removed. 8) The EPG Handler sends the port numbers and CSA-keys of the user s subscribed channels, together with the video server credentials, to the Video Client. 9) The Video Client contacts the video server and logs in with the provided credentials. It then requests the required channel using the port number received from the EPG Handler. 10) The Video Client receives a scrambled video channel. 11) The Video Client descrambles the video channel using the CSA-key from the EPG data package and sends it to the GUI. The user can now watch his personal channels and EPG.

75 74 / Advanced RFID-related block diagram Figure 42: RFID-related block diagram with interconnections Overview of user log-in event The RFID reader waits to be activated. 1) The client-side terminal sends the RFID reader the command to poll for RFID cards. 2) Once the RFID reader detects a card and the anti-collision procedure is performed (not shown), the RFID reader sends the card the request to access a specific sector (in this case the sector containing the first part of the IMPI). 3) The Control block of the RFID card forwards this request to the Authentication block. 4) The Authentication block sends a Card Challenge (nonce) to the Authentication block of the RFID reader. 5) The RFID reader s Authentication block contacts the reader s EEPROM for the proper read-key for this particular sector of the RFID card. 6) The EEPROM responds with the required read-key. 7) The Authentication block of the RFID reader computes the response to the card s challenge using the read-key and generates a Reader Challenge. The response and the challenge are then sent back to the RFID card. 8) The RFID card contacts the Cryptography block to verify the response of the RFID reader and calculate a response to the reader s challenge. 9) If the reader s response to the card s challenge is verified, the Cryptography module computes the response to the reader s challenge. 10) The RFID card sends the response back to the RFID reader. 11) After the RFID reader has verified the response, it sends a Read command to the RFID card for the first data block of the sector it has just been authenticated for. 12) The Control block request the required data block from the card s EEPROM. 13) The EEPROM responds with the data. 14) Which the Control block then sends back to the RFID reader. 15) After the complete authentication and data reading procedure is repeated several times (for the rest of the IMPI, the IMPU(s) and K), the RFID reader sends the obtained data to the terminal.

76 75 / Advanced server-side block diagram Figure 43: Server-side block diagram with interconnections Overview of user log-in event A user has just swept his RFID card in front of the RFID reader. The reader has obtained the necessary user credentials from the card and has forwarded it to the terminal. The terminal has re-assembled the different parts of the data and contacts the server. 1) SIP Digest authentication takes place between HTTP server and client-side terminal. For more information on this process, see Chapter 4 or Appendix A. 2) In order for the HTTP Server to verify the terminal s authentication response, it requires the user s shared secret. In order to obtain this, the HTTP server contacts the User Credentials Database with the user s IMPI. 3) The User Credentials Database responds with the user s shared secret K. 4) After authentication is complete and the user s identity has been verified, the HTTP server contacts the EPG Handler module (which is actually a PHP script running on the server). 5) The EPG Handler module requests the EPG database for program information of all channels the user (identified by his IMPI), is subscribed to. 6) The EPG Database responds with a set of program information and additional video server information (such as port numbers and CSA keys) 7) The EPG Handler uses the information from the EPG database to construct a personalized EPG for the just-logged-in user. 8) The HTTP Server sends the generated EPG Data Package to the client-side terminal. 9) After the terminal has obtained the personalized EPG, it contacts the Video Server with the information carried in the EPG Data Package. 10) (The server communicates with the EPG database to make sure all video channels are scrambled using the correct CSA keys) 11) The Video Server responds by sending the terminal the requested scrambled Video stream.

77 76 / 97

78 77 / Demonstration Now the complete multi-user personalized EPG prototype has been described, this section will present a brief visual demonstration of the completed system. Figure 44: Demonstration step 1 The prototype with no users logged in: no EPG and no video content.

79 78 / 97 Figure 45: Demonstration step 2 If a user wants to watch TV, he swipes his RFID card in front of the RFID reader connected to the TV.

80 79 / 97 Figure 46: Demonstration Step 3 The situation with one user logged in. The user has subscriptions to two channels, CBS and NBC, and is currently watching CBS. Note the list on the left that shows the current users logged in and the low-res button beneath the video and next to the Channel Up button.

81 80 / 97 Figure 47: Demonstration Step 4 A second user logs in without interrupting the video channel the first user is watching. The second user has a number of additional subscriptions which are added to the channels already available and shown in the EPG. One of the channels the second user is subscribed to, Comedy Central, is a restricted channel due to the sometimes coarse language used in programs such as South Park. The fact that the channel is meant for adults only is emphasized in the EPG by marking the channel with a red band.

82 81 / 97 Figure 48: Demonstration Step 5 The third user that logs in is a child (shown in the middle-left of the screen, under users logged in ). When one looks at the EPG, it can be seen that Comedy Central is missing. When the child logged in, the client recognized this and removed all adult-only channels from the EPG and from the list of available channels. Should the child log out again, Comedy Central would automatically come back and be available again (for watching as well as being displayed in the EPG).

83 82 / 97 Figure 49: Demonstration Step 6 In this final figure, the second user has logged out. As can be seen, the total number of available channels has decreased to three (the first user having a subscription to CBS and NBC, and the third user having a subscription to ABC). Should the TV have been tuned to a channel to which only the third user had a subscription, then the TV would automatically have been switched to an available channel.

84 83 / 97 8 Conclusions & Future work In the first chapter of this document, the two seemingly contradictory concepts of personalization and concurrency were introduced. With the recent trend towards personalization in the TV world and the focus on the individual experience, it was feared that the collective experience, and with it the social component of watching TV, would be diminished. This notion was supported by the fact that in recent TV architectures, the multi-user situation is not even taken into account. With a number of use cases, however, it was proven that personalization and concurrency are not necessarily as contradictory as one would think and that in fact, they can complement and reinforce each other; thereby introducing a new type of application that delivers personalized services to multiple users at the same time, increasing the social and collective component of watching TV. The technical implementation of these new types of applications, however, proved more difficult; mainly due to usability issues and the fact that current IPTV architectures are not designed with concurrent use taken into account. With RFID Digest, a solution to these problems has been introduced. This new identification and authentication mechanism meets all of the multi-user requirements introduced in Chapter 2, has no significant impact on system performance, is relatively secure and requires no changes to the server side of the TV architecture. To prove that the hypothesis of personalization and concurrency being contradictory is not only invalid in theory, but also in practice, and that an application that combines the two concepts can be successfully implemented, a prototype has been built. This multiuser personal EPG prototype, while being limited in its offered features, shows that it is possible for multiple users to enjoy personalized services together. More importantly, it shows that concurrency can actually increase the need for personalization (by for example blocking specific channels when children are present). The work done during this project, however, is only a start. While the development of RFID Digest, the presented use cases and the implemented prototype prove beyond doubt that multi-user personalized services are a possibility, they are just that: a proof of concept. Before actual applications based on the work done during this project can be rolled out, a lot of work has to be done. For a start, a number of policy decisions should be made regarding the concept of RFID Digest. Should the RFID cards be owned by the TV provider or by the user? And who is responsible if something goes wrong and a user s identity is stolen? Should the STBs used on the client-side be issued by the TV provider or should users be able to choose their own specific STB? These and a number of other policy decisions will determine how RFID Digest is used in practice. Another area for future research is security. The security analysis made in this document is only an overview. A lot of issues not talked about probably exist, and the issues that were discussed probably need to be more deeply examined. An example is the security of RFID cards; an in-depth analysis of the security level of different types of RFID cards should be performed to find out which card is best suited to RFID Digest and the TV world. Another example is the security level of terminals; what is the best way to prevent modified terminals from storing user credentials? And which measures should be taken to prevent terminals from being modified in the first place? Finally, in an effort to convince others of the merits of multi-user personalized TV, a more extensive prototype would also be desirable. The multi-user interactive TV show use case that was presented in this document, in particular would be well suited for this purpose. The main reason for this is that, unlike the multi-user personal EPG, it features interactivity. Where the current prototype includes concurrency in a passive way, the

85 84 / 97 multi-user TV show features active concurrency; multiple users are simultaneously interacting with the TV content, further reinforcing the idea of concurrency and offering a completely new experience at the same time. To sum up, in this project it has been proven, both in theory and in practice, that concurrency and personalization are not necessarily contradictory and that they can in fact be used to complement each other. Although additional work is required, with RFID Digest a new form of TV identification has been introduced that allows the social and collective component of TV to be once again brought to the front.

86 85 / 97 References Boertjes, E., Klok, J., Niamut, O., & Staal, M. (2009). ConnecTV: Share the experience. In P. Cesar, D. Geerts, & K. Chorianopoulos, Social Interactive Television (pp ). IGI Global. Brandenburg, R. v. (2008). Internship report: How to Provide Identification for Multiple Simultaneous TV users? Delft/Enschede: TNO-ICT/University of Twente. Digital Video Broadcasting. (sd). Architectural Framework for the Delivery of DVB- Services over IP-based Networks. Digital Video Broadcasting. (sd). Framing structure, channel coding and modulation for 11/12 GHz satellite services. Digital Video Broadcasting. (sd). Framing structure, channel coding and modulation for cable systems. Digital Video Broadcasting. (sd). Framing structure, channel coding and modulation for digital terrestrial television. Digital Video Broadcasting. (sd). Transmission system for handheld terminals. ETSI TISPAN. (2009). 3G Access Security for IP-based Services. ETSI TISPAN. (2008). IP Multimedia Subsystem: Stage 2. ETSI TISPAN. (2008). IPTV Functions Supported by the IMS Subsystem. ETSI TISPAN. (2008). NGN integrated IPTV subsystem architecture. ETSI TISPAN. (2009). Service Layer Requirements to Integrate NGN Services and IPTV. Eurogamer. (2008, 10 7). PS3 has outsold Xbox 360 in Europe. Opgeroepen op 10 10, 2009, van eurogamer.net: Hunter, M. T., Clark, R. J., & Park, F. S. (2007). Security Issues with the IP Multimedia Subsystem: A White Paper. 2007: Georgia Institute of Technology. IETF. (2003). Diameter Base Protocol. IETF. (2005). Security Architecture for the Internet Protocol. IETF. (1999). Session Initiation Protocol. IETF. (2002). Session Initiation Protocol. IETF. (2005). The Network Access Identifier. IETF. (2004). The tel URI for Telephone Numbers. IETF. (2005). Uniform Resource Identifier: Generic Syntax. International Telecommunication Union. (sd). Conventional Television Systems. ITU-T. (2006). Mean Opinion Score (MOS) terminology. Jorstad, I., Thuan, D. v., Jonvik, T., & Thanh, D. v. (2008). Utilising Emerging Identity Management Frameworks in IMS. 12th International Conference on Intelligence in service delivery Networks (ICIN). Bourdeaux, France. Juels, A. (2006, February). RFID Security and Privacy: A Research Survey. IEEE Journal on Selected Areas in Communications, 24 (2), pp Karsten, N. (2008). Cryptoanalysis of Crypto-1. Opgeroepen op 2 27, 2009, van University of Virginia:

87 86 / 97 Koning Gans, G. d. (2008). Analysis of the Mifare Classic used in the OV-chipkaart project. Nijmegen: Radboud University Nijmegen. Kooij, R., Ahmed, K., & Brunnstrom, K. (2006). Perceived Quality of Channel Zapping. 5th IASTED International Conference Communication Systems and Networks, (pp ). Palma de Mallorca, Spain. MeediOS. (2009). VideoLan Interop. Opgeroepen op 8 25, 2009, van SourceForge: Nielsen Media. (2008, 6 8). Average U.S. Home Now Receives a Record TV Channels. Opgeroepen op 7 7, 2009, van nielsenmedia.com: a062a0/?allRmCB=on&newSearch=yes&vgnextoid=fa7e220af4e5a110VgnVCM ac0a260aRCRD&searchBox=report Nokia. (2002). TLS versus IPsec for HTTP security. NXP Semiconductors. ( ). Opgeroepen op 10 2, 2009, van NXP Semiconductors: NXP Semiconductors. (2008). MF1ICS50 Functional Specification. Priselac, D., & Mikuc, M. (2008). Security Risks of pre-ims AKA Security. Ericsson. RNW. (2008, 10 17). Over 6,500 TV Channels in Europe, UK in top spot. Opgeroepen op 7 7, 2009, van rnw.nl: Sack, M. (2007). ishow - An Interactive TV Show. Thesis, Saxion Hogeschool Enschede. Stallings, W. (2007). Network Security Essentials (3rd Edition ed.). Upper Saddle River: Pearson Prentice Hall. Teepe, W. (2008). Making the Best of Mifare Classic. Nijmegen: Radboud University Nijmegen. The Apache Software Foundation. (2009). HTTP Server Project. Opgeroepen op 8 28, 2009, van Apache Software Foundation: The VideoLan Team. (2009, 8 18). VLC Media Player: Open Source Multimedia Framework and Player. Opgeroepen op 8 25, 2009, van VLC Media Player: Verdult, R. (2008). Security Analysis of RFID tags. Nijmegen: Radboud University Nijmegen.

88 87 / 97 Appendix A Authentication in IMS This Appendix presents a more detailed examination of IMS s authentication systems. A.1 IMS AKA IMS Authentication and Key Agreement (AKA) is based on UMTS AKA. Just as UMTS AKA, IMS AKA is based on the use of an UICC card. On it is an ISIM application, analogue to the USIM application used in UMTS AKA. The biggest difference between IMS AKA and UMTS AKA is the way in which messages and parameters are transported between UE (User Equipment) and authentication center. Furthermore, IMS AKA introduces some additional security measures. (IMS) AKA is based on the principle of a shared secret K and a challenge-response mechanism. Only two entities know the secret key: the HSS in the home network and the subscriber s ISIM. Using this shared secret it is possible for the two entities to authenticate each other by checking if each party knows the key K. Of course, this needs to be done without sending the secret key across the network, where it is vulnerable to interception. IMS AKA starts with the HSS in the IMS Core randomly generating a number, called RAND. The HSS then proceeds by performing some cryptographic function combining RAND with the 128-bit shared secret K, resulting in XRES (for expected RESponse). The randomly generated RAND is, upon request from the S-CSCF, sent to the ISIM. This happens by first combining it with XRES in a container called an Authentication Vector (AV) and downloading it to the S-CSCF. The S-CSCF then extracts RAND and sends it in an Authentication Request (AR) on to the ISIM. When the ISIM receives RAND, it performs the same cryptographic function using RAND and its version of K (which is stored internally). The result of this function, RES, is send back to the S- CSCF, where it is compared with the HSS-calculated XRES. When the two values match, the HSS has successfully authenticated the UE. Obviously, the only way this can happen is when both ISIM and HSS have the same key K. It would be useful to not only authenticate the UE, but also have some way of authenticating the network, so the user can be certain he is connected to his own, trusted, network and not with some other pretending network. To facilitate this, the HSS also generates a so called AUTN (for AUThenticating Network) token. This token is derived from the shared secret K. The AUTN token is send to the ISIM in the AR, along with the original challenge RAND. When the ISIM receives the AR, it first calculates it own version of AUTN. Only when the two tokens match, does the ISIM proceed with calculating RES. In order to prevent replay-attacks on the authentication system described above, a system of sequence numbers is used. Both the ISIM and the HSS maintain a counter which tracks the number of messages send between the ISIM and the HSS. The current states of these counters are called SQNISIM and SQNHSS respectively. When generating the AV, the HSS uses SQNHSS along with RAND and K to calculate XRES and AUTN. In the same way the ISIM uses SQNISIM to calculate the responses. This way, authentication is only successful if the states of the counters on both sides are the same, which cannot be the case when a message is replayed. One final part of the authentication system is related to message confidentiality and message integrity. In IMS AKA these are provided by the security framework IPsec; more specifically, the Encapsulating Security Payload (ESP) protocol. In order for IPsec ESP to do its work, it needs two additional sets of shared keys; one set for ciphering and the other for message integrity. For this reason, when the HSS generates the AV, it also

89 88 / 97 includes two keys, a Cipher Key (CK) and an Integrity Key (IK). These two keys are calculated based on the randomly generated RAND and the shared secret K. The CK and IK are not sent to the ISIM, but to the P-CSCF which functions as the IMS network boundary and communicates directly with the ISIM. Upon receiving RAND, the ISIM generates its own version of both CK and IK which should be the same as the HSSgenerated ones. CK and IK are then expanded into ESP keys CKESP and IKESP that are used by the actual ciphering and message integrity protocols.. The complete message flow of a successful IMS registration is shown in Figure 50 and in the following overview. Figure 50: IMS AKA message flow overview IMS AKA Overview 1-3) The UE sends a SIP REGISTER message containing the user s IMPI and IMPU to the P-CSCF. The P-CSCF forwards the message through an I-CSCF to an S-CSCF in the home network. 4) The S-CSCF asks the HSS for an Authentication Vector (AV) corresponding to the IMPI indicated by the user. 5) The HSS responds to the S-CSCF s query with an AV containing RAND, AUTN, XRES, CK and IK. 6-7) Using the received AV, the S-CSCF generates an Authentication Request consisting of RAND, AUTN, IK, and CK and sends it through an I-CSCF to the P- CSCF. 8) The P-CSCF extracts both the integrity key IK and the cipher key CK, stores them and sends the Authentication Request, now consisting of just RAND and AUTN on to the UE. 9-11) The UE checks if SQN is in the right range. If this is the case, it proceeds by verifying AUTN. When the network is verified, the UE calculates RES and sends it in an Authentication Response via the P-CSCF and I-CSCF to the S-CSCF. The UE also calculates its own version of both IK and CK ) The S-CSCF checks if the received RES matches with the previously calculated XRES. If this is the case, the user is authenticated.

90 89 / 97 This concludes the description of IMS AKA. The important thing to remember is that IMS AKA is built around three concepts: a secret key K residing on an UICC, a challenge-response system and complex cryptographic algorithms for calculating responses. A.2 SIP Digest SIP Digest authentication can be used when a UICC interface is not available on the User Equipment (UE). This is especially valuable for fixed terminals such as PCs, for which this is often the case. Since SIP Digest authentication has been introduced by TISPAN and has not been ratified by 3GPP, IMS specifications clearly state (ETSI TISPAN, 2009) that SIP Digest authentication may not be used by 3GPP specified access technologies such as UMTS. This, however, is not a problem since there are no apparent reasons for a non-legacy mobile device not to use IMS AKA. SIP Digest is based on HTTP Digest. HTTP Digest, in turn, was originally created as a replacement for HTTP Basic authentication that was no longer deemed secure since it sends it sends the shared secret (in this case a password) in the clear. SIP Digest and HTTP Digest are essentially the same with SIP Digest merely introducing some extra constraints on various HTTP Digest parameters. HTTP Digest (and thus SIP Digest) is built around the same basic principle as IMS AKA, namely the existence of a shared secret between the UE and the HSS and a challenge-response mechanism to verify this. The only difference here is that in IMS AKA the shared secret is an abstract value in an ISIM application embedded on a UICC while in Digest authentication the shared secret is a password known by the user. The essence of this difference is that with SIP Digest the password is open and accessible (known) to the user, while with IMS AKA, the secret is inaccessible and hidden from the user. The basic working of Digest authentication in an IMS context is the following: The S- CSCF asks the HSS for a set of authentication parameters related to a specific IMPI, a so-called SD-AV (for Sip Digest Authentication Vector). Among the parameters in this SD-AV is the H(A1) hash which is constructed from the IMPI, the realm and the password associated with the IMPI. Upon receiving the SD-AV, the S-CSCF creates a randomly generated value: nonce N, and stores this together with the H(A1) hash. It then proceeds by sending an Authentication Challenge (AC) to the UE. This AC includes, among others, N and a set of supported digest and checksum algorithms. When the UE receives the AC, it generates its own nonce: NC. It then uses NC together with the IMPI, the password inputted by the user and the received HSS-generated N to create a response. This response is send along with NC and the chosen algorithms back to the S-CSCF. The S-CSCF calculates the expected response from the received nonce NC, the stored nonce N, and the stored H(A1) hash. When the received response matches the expected response, the user is authenticated.

91 90 / 97 Figure 51: SIP Digest message flow overview It should be noted that unlike IMS AKA, Digest authentication does not create session keys CK and IK. This makes it technically impossible to use SIP Digest together with IPsec. However, it is possible to use TLS (for Transport Layer Security) to provide the necessary message confidentiality and integrity. The complete message flow of a successful SIP Digest authentication is shown in Figure 51 and in the following overview. SIP Digest Overview 1-3) The UE sends a SIP REGISTER message containing the user s IMPI and IMPU to the P-CSCF. The P-CSCF forwards the message through an I-CSCF to an S-CSCF in the home network. 4) The S-CSCF asks the HSS for an SD-AV associated with the user s IMPI. 5) The HSS responds with the SD-AV consisting of the realm, a set of supported algorithms and the hash H(A1). 6-8) The S-CSCF generates a randomly generated nonce N and includes it in an authentication challenge to the UE. 9-11) Upon receiving the challenge, the UE randomly generates NC. Using NC, N, the user s IMPI and the user-inputted password, the UE calculates a challenge response. This response is send back to the S-CSCF (via the P-CSCF and the I-CSCF) together with the generated NC ) The S-CSCF uses the received NC together with the stored N and H(A1) to calculate an expected response. When the expected response matches the received response, the user is authenticated. This concludes the description of SIP Digest authentication. The important thing to remember is that, while the challenge response system used in SIP Digest is somewhat similar to the one used IMS AKA, SIP Digest s shared secret is a password remembered by the user. Also, SIP Digest uses TLS for message confidentiality and integrity instead of IPsec.

92 91 / 97 A.3 NASS-bundled Authentication Just as SIP Digest, NASS-IMS-bundled Authentication (NBA) is meant for terminals that do not support UICC cards. However, instead of relying on a password remembered by a user, NBA is based on the concept of re-using existing access-line authentication protocols. In almost all IP-based networks there is a system that authenticates a terminal s physical connection to the network and provides it with an IP address. In IMS this function is provided by the NASS (Network Access Subsystem). It is this IP-connectivity authentication that is re-used in NBA. The exact protocols used by NASS to perform network attachment are outside the scope of this text. Before a terminal can use NBA, the subscriber first has to register a number of so-called Line Identifiers (LI) for future reference with the IMS core. An LI is a unique number that specifies the exact access-line a terminal is connected to; in practice a specific xdsl connection. The reference LI is stored in the HSS associated with a subscriber s IMPI. These reference LIs define which xdsl connections can be used by that specific subscriber to have access to IMS services without explicit IMS-level authentication. It should be noted that this initial registration of linking LIs to IMPIs and storing them in the HSS is not standardized, in the same way that it is not standardized how an initial IMPI/password combination for SIP Digest is registered and stored. Side issue Another form of authentication that is related to NBA is GPRS-IMS-bundled authentication (GBA). This form of authentication is used for legacy terminals that do not have ISIM UICCs but are equipped with regular (GSM) SIM UICCs. GBA can be compared to NBA since it also relies on access-level authentication to authenticate a terminal at IMS-level. GBA is not discussed here further since it is of no use in the TV context (if a TV were to support SIM UICCs, it would probably also support ISIM UICCs). Every time a user turns on the UE, the UE is authenticated on the access level by the NASS and provided with an IP address. When using NBA, the combination of IP address and LI is stored in the network CLF (Connectivity Session and Repository Location Function) which is a part of the NASS. This process is also called IP address binding. Now, when the user contacts the P-CSCF wanting to register in the IMS network, the P-CSCF contacts the CLF with a Location Information Query asking for the LI associated with the user s IMPI. The P-CSCF then proceeds by appending the SIP REGISTER message from the UE with the LI received from the CLF and sending it on to the S-CSCF. Upon receiving the appended SIP REGISTER message from the P-CSCF, the S-CSCF contacts the HSS with a Reference Information Query with the user s IMPI as a parameter. The HSS responds by sending back the reference LI stored during initial registration. The S-CSCF then compares the reference LI with the LI from the CLF. When the two match, the user is authenticated and is allowed access to the network.

93 92 / 97 Figure 52: NASS-bundled Authentication message flow overview The complete message flow of a successful NBA authentication is shown in Figure 52 and in the following overview. NBA Overview 1) The user turns on the UE, which is then authenticated on the access level by the NASS and receives an IP address. The CLF stores a binding between the given IP address and the UE s LI. Then the UE sends a SIP REGISTER message into the network. 2) The P-CSCF, upon receiving the UE s REGISTER message asks the CLF for the LI belonging to the user s IMPI. 3) The CLF responds with the required LI. 4) The P-CSCF appends the original SIP REGISTER with the LI and forwards it to the S-CSCF. 5) The S-CSCF queries the HSS by asking for the NBA authentication information associated with the IMPI indicated by the user. 6) The HSS responds with the reference LI. 7-8) The S-CSCF compares the reference LI received from the HSS with the LI received from the CLF (via the P-CSCF). When the two match, the user is authenticated. This concludes the description of NBA. The most important thing to remember is that NBA uses existing access-level authentication protocols to authenticate the subscriber at a higher level (IMS service level). In order to do so, a subscriber is linked to a specific access line. A.4 IMS Residential Gateway The previous section introduced three different authentication mechanisms. The IMS standards also include a fourth form of authentication, called IMS Residential Gateway authentication (IRG). IRG is not so much an authentication mechanism as it is a different way to use IMS AKA. An IMS Residential Gateway is a device that allows devices that cannot be equipped with an UICC to connect to an IMS network and be authenticated by IMS AKA, thereby also allowing for advanced security features such as IPsec. An IRG is basically an adapter that is placed between the UE and the IMS core. It should be noted that from a network point-of-view the IRG is placed relatively close to the UE, most often in the user s home. Instead of UEs registering themselves on the network, the IRG does this

94 93 / 97 for them. For this purpose the IRG contains an UICC equipped with an ISIM application. The IRG is connected directly to the IMS network. It implements the Back-to-Back User Agent (B2BUA) interface. This is basically a SIP User Agent. To the network the IRG therefore has the role of UE. The actual UE is connected to the IRG using a generic IP protocol. This protocol is not standardized and depends on the type of UE and the specific implementation. When the UE wants access to IMS services it asks the IRG to register itself in the IMS network. The identifier used for this is the IMPI stored on the IRG s UICC. The rest of the authentication process is IMS AKA, now with the IRG taking on the role of UE. It should be noted that it is possible for several devices to connect to a single IRG. These devices can have different IMPU s registered at the same time although they all share the same IMPI; the one in the IRG s UICC. The fact that all user terminals share the same IMPI has consequences on for example billing and user roaming. The complete message flow of a successful NBA authentication is shown in Figure 53. This concludes the description of IRG. Important to remember is that IRG authentication is basically IMS AKA with a UICC-equipped adapter placed between UE and HSS and taking on the role of UE. This is a good example of how existing authentication mechanisms can be re-used to operate in different environments. Figure 53: IMS Residential Gateway message flow overview

95 94 / 97 Appendix B RFID RFID, which stands for Radio Frequency Identification, is a technology that allows for automatic identification of objects. It does this by remotely accessing information stored on a so-called RFID tag (in standardization documents referred to as PICC, for Proximity Integrated Circuit Card) placed on the object. The device that accesses the tag and retrieves its information is called the RFID reader (or PCD, for Proximity Coupling Device). What makes RFID unique from other identification techniques is that it is completely contactless. The actual range from which an RFID reader is able to access an RFID tag depends on the used technology and varies from a few centimeters to multiple meters. RFID can (and is) used for a wide variety of applications. These range from animal identification to public transportation tickets and from supply chain labels to building access control. Each of these environments requires its own level of security. For example, RFID tags used to identify different animals at a farm require far less security than RFID tags used to control access to military buildings. Apart from varying in their need for security, RFID tags also vary in their supported functionality. While some tags do nothing more than sending back a serial number, other tags contain complex cryptographic functions and multiple kilobytes of memory. This appendix will first explain how the basic principles behind RFID work. After this, some potential problems of RFID systems, such as privacy, will be discussed. B.1 RFID in general Every RFID tag consists of two parts: an antenna and an integrated circuit. The role of the antenna is sending and receiving a radio-frequency (RF) signal used to communicate with an RFID reader. The role of the integrated circuit is modulating and de-modulating this signal as well as storing and processing information. The most common RFID tag is the passive tag. The passive tag works by receiving a signal send out by an RFID reader. The power embedded in this signal is then used to operate the integrated circuit inside the tag. This circuit modulates the incoming signal with some information stored inside the tag (usually a unique serial number). The modulated signal is then send back to the reader by the antenna. Finally, the reader receives the signal and performs de-modulation to extract the information. This mechanism allows passive RFID to communicate without requiring a power source on the tag-side. Obviously this system severely limits the power available to the integrated circuit so power-heavy applications are not possible. Another, less common, type of RFID solves this problem. This type of tag includes a battery and is therefore called an active tag. The availability of the battery makes more complex types of applications possible. Examples include sensor tags that actively measure their environment (such as humidity or temperature sensors) and then send this information back to the RFID reader when queried. Another advantage of active tags is that, due to the fact that it is possible to use the battery to send the response signal instead of relying on the power embedded in the received signal, the maximum read-out distance of active tags can be significantly larger. One drawback of active tags is that the battery capacity limits the tag s lifetime. B.2 Physical communication Apart from passive/active tags, RFID systems can be further divided into four different categories based on the wavelength of the signals used for communication between RFID tag and reader. Figure 54 briefly summarizes these categories.

96 95 / 97 Figure 54: Different types of RFID The nature of the communication signal differs between the different categories; LF and HF use a form of inductive coupling, while UHF and microwave are based on a backscatter mechanism. Inductive coupling is based on a magnetic field around an RFID reader and an RFID tag equipped with a coil. When the tag is placed within the magnetic field of the reader, the varying magnetic flux induces a current in the tag s coil. This current is then used to power the integrated circuit which then varies the tag s load so the signal is modulated when send back to the reader. The limited range of this form of communication can be explained by the strength of the dipole magnetic field which decreases very quickly with increasing distance. Because the distance between reader and tag is significantly smaller than the wavelength of the signal (both for LF and HF), this form of communication is also referred to as near field coupling. The mechanism employed in UHF and microwave-based RFID is based on a completely different approach: backscatter coupling. This method is based on an electro-magnetic wave originating from the RFID reader and at a specific moment in time striking the tag s antenna. Part of the signal is absorbed by the antenna and used to power the integrated circuit, which then varies the load on the antenna. Due to the changing load, the part of the original signal that is reflected back to the reader is modulated. Since the electromagnetic wave decreases less quickly with increasing distance than the dipole magnetic field, the range of backscatter coupling can be significantly larger than inductive coupling. Because this range is large compared to the wavelength of the sent signal, this form of communication is also referred to as far field coupling. B.3 Message communication The previous section described the physical communication between RFID readers and tags. This section will look at the communication from a higher level. The integrated circuit contained in most RFID tags can perform various functions; from simply retrieving a stored number to performing complex cryptographic calculations. The most straightforward operation, and the one that is performed by most tags, is simply sending back a serial number. This serial number is most often 64 or 96 bits in length and can be used to uniquely identify that specific tag among its peers. In the simplest tags, this number is hardwired in the tag itself. In more complex tags, this number can be stored once after which it is permanently associated with the tag. Even more complex tags allow a reader to overwrite the number over and over. Apart from the relatively straightforward operation of reading a serial number from a tag, there are also more complicated tags. Most of these offer a small EEPROM from which an RFID reader can read/write data. Some of these tags also include advanced security functionality. One example of this type of functionality is the ability to encrypt communication between reader and tag using a shared key. Another example is a system that allows reader and tag to mutually authenticate each other before giving access. It should be noted that the protocols used for this type of functionality can be either proprietary or standardized. B.4 RFID standardization