threat analysis of video on demand services in next generation
TRANSCRIPT
Institutionen för datavetenskapDepartment of Computer and Information Science
Final thesis
Threat Analysis of Video on DemandServices in Next Generation Networks
by
Rickard von Essen
LIU-IDA/LITH-EX-A–09/052–SE
9 december 2010
Linköpings universitetSE-581 83 Linköping, Sweden
Linköpings universitet581 83 Linköping
Linköping UniversityDepartment of Computer and Information Science
Final thesis
Threat Analysis of Video on Demand Services in NextGeneration Networks
by
Rickard von Essen
LIU-IDA/LITH-EX-A–09/052
9 december 2010
Supervisor: Anders WeilandAttentec AB
Examiner: Nahid ShahmehriDept. of Computer and Information Scienceat Linköping University
LINKÖPING UNIVERSITY
ELECTRONIC PRESS
På svenskaDetta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under en läng-re tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheteruppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skrivaut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiellforskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kaninte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsman-nens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns detlösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i denomfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samtskydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhangsom är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hem-sida http://www.ep.liu.se/
In EnglishThe publishers will keep this document online on the Internet - or its possible replacement- for a considerable time from the date of publication barring exceptional circumstances.
The online availability of the document implies a permanent permission for anyone toread, to download, to print out single copies for your own use and to use it unchanged forany non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional on theconsent of the copyright owner. The publisher has taken technical and administrativemeasures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned whenhis/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and itsprocedures for publication and for assurance of document integrity, please refer to itsWWW home page: http://www.ep.liu.se/
c© Rickard von Essen
AbstractIP Multimedia Subsystem (IMS) is the next generation of telecommunication systems.The system is based on an IP network and uses technologies from the Internet.
The IMS system is designed to evolve from a telephone system into a general infor-mation and communication system. It is meant to include television, Video on Demand(VoD), interactive services etc, etc. It is designed to simplify the implementation of newservices in telecom networks.
This report investigates security aspects of VoD services when merging an IP Television(IPTV) system with IMS. The investigation covers security functions in IMS, transitionsolutions for authentication of the Set-Top-Box (STB) in IMS, and identifies problems inthe integration of IPTV and IMS.
The report concludes that IMS has good solid Authentication, Authorization, and Ac-counting (AAA) functions that will provide security and billing functionality. One problemis found in the media control between the STB and the streaming server. This interfacelacked specification at the time of investigation, and some problems have been identified.These problems have to be solved before a system can be brought into service and beregarded as secure.
Keywords: Threat analysis, Security, NGN, IMS, SIP, UE, IPTV, STB, VoD, AAA,RTSP, Threat tree, Authentication, IPsec
AcknowledgementsThis thesis would not have been what it is without the contributions of a number of peoplewho deserve to be acknowledged.
There are a few people that have directly affected the content of this thesis report, mostof all my supervisors Anders Weiland and Åsa Detterfelt who gave me the opportunityto do this thesis work and guided me into the world of consulting. Both of them deservemany thanks. And of course my first examiner Claudiu Duma, previously at LiU and myfinal examiner Nahid Shahmehri, ADIT, LiU both for their valuable knowledge and theirguidance through out the completion of my work. Without their help and effort this reportwould never have been possible.
I also want to thank Henrik Carlsson at Motorola for introducing the topic of thethesis and for his valuable insights in real-world IPTV systems. He also deserves gratitudefor helping out with the sometimes complicated jungle of embedded systems. Among mycolleagues Stefan Östergaard deserve a special acknowledgment for his help with gettinginto the world of IMS, and for always providing fast and accurate answers to my questions.He also provided valuable input on how to complete a thesis in general, with his own freshexperience.
And finally I am forever grateful to my grandmother for giving me my first homecomputer, a Sinclair XZ Spectrum1 in the Christmas of 1988. This gift made me discoverthe world of computer science.
1http://en.wikipedia.org/wiki/ZX_Spectrum
Innehåll
Figurer xiii
Tabeller xv
1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4.1 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4.2 STB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4.3 Billing and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.7 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.8 Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.9 Target Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.10 Outline of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I Theoretical Background 72 IPTV – IP Television 9
2.1 Common configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.1 Multicasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.2 MPEG-TS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.3 RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 SIP – Session Initiation Protocol 133.1 User Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Location Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 SIP Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 SIP Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6 SDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
ix
x INNEHÅLL
3.8 Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.9 Invite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.10 Basic Network Media Service . . . . . . . . . . . . . . . . . . . . . . . . . . 173.11 RTP/RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 IMS – IP Multimedia Subsystem 194.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 CSCF – Call Session Control Function . . . . . . . . . . . . . . . . . . . . . 204.3 HSS – Home Subscriber Server . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 AS – Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 PEP/PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.6 CCF/OCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.7 ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.8 Reference Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8.1 Gm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.8.2 Mw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8.3 Cx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8.4 ICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8.5 Sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.8.6 Ro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Security 255.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255.2 Attacks on Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.2 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.2.3 DoS – Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Basic cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3.1 Symmetric cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 275.3.2 Asymmetric cryptography . . . . . . . . . . . . . . . . . . . . . . . . 275.3.3 Cryptographic Signatures . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.5 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5.1 Transport and Tunnel Mode . . . . . . . . . . . . . . . . . . . . . . . 285.5.2 ESP – Encapsulating Security Payload . . . . . . . . . . . . . . . . . 29
5.6 SIP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.7 IMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.7.1 NDS/IP – Network Domain Security IP . . . . . . . . . . . . . . . . 305.7.2 AKA – Authentication and Key Agreement . . . . . . . . . . . . . . 305.7.3 Diameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 Risk Analysis 336.1 Secure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2 Vocabulary Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2.1 Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.2 Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.2.3 Threat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.4 Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.5 Countermeasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
INNEHÅLL xi
6.2.6 Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Peltier’s Ten Step Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
6.3.1 Step 1: Develop a Scope Statement . . . . . . . . . . . . . . . . . . . 356.3.2 Step 2: Assemble a Quality Team . . . . . . . . . . . . . . . . . . . . 356.3.3 Step 3: Identify Threats . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.4 Step 4: Prioritize Threats . . . . . . . . . . . . . . . . . . . . . . . . 366.3.5 Step 5: Threat Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3.6 Step 6: Risk Factor Determination . . . . . . . . . . . . . . . . . . . 366.3.7 Step 7: Identify Safeguards and Controls . . . . . . . . . . . . . . . . 366.3.8 Step 8: Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . 376.3.9 Step 9: Rank Safeguards in Recommended Order . . . . . . . . . . . 376.3.10 Step 10: Risk Assessment Report . . . . . . . . . . . . . . . . . . . . 37
6.4 Threat Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.5 Threat Analysis of NGN IMS . . . . . . . . . . . . . . . . . . . . . . . . . . 37
II Investigation 39
7 Adapted Risk Analysis Method 417.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.2 What is a Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.3 Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427.5 Adapted Risk Analysis Method . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.5.1 Step 1: Define the Scope of the Analysis . . . . . . . . . . . . . . . . 427.5.2 Step 2: Assemble the Quality Team . . . . . . . . . . . . . . . . . . . 427.5.3 Step 3: Identify Assets . . . . . . . . . . . . . . . . . . . . . . . . . . 427.5.4 Step 4: Identify Threats . . . . . . . . . . . . . . . . . . . . . . . . . 427.5.5 Step 5: Refine Threats Using Threat Trees . . . . . . . . . . . . . . . 437.5.6 Step 6: Assign Probabilities and Impact to Leaves . . . . . . . . . . 437.5.7 Step 7: Calculate Risk Factors . . . . . . . . . . . . . . . . . . . . . 447.5.8 Step 8: Identify Safeguards and Controls . . . . . . . . . . . . . . . . 447.5.9 Step 9: Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . 447.5.10 Step 10: Rank Proposed Safeguards . . . . . . . . . . . . . . . . . . 447.5.11 Step 11: Risk Assessment Report . . . . . . . . . . . . . . . . . . . . 44
7.6 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.7 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8 Threat Analysis 478.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478.2 Description of System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.2.1 Boundaries of the Analysis . . . . . . . . . . . . . . . . . . . . . . . 488.3 Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.3.1 Step 1: Scope Statement . . . . . . . . . . . . . . . . . . . . . . . . . 488.3.2 Step 2: Assemble a Quality Team . . . . . . . . . . . . . . . . . . . . 508.3.3 Step 3: Identify Assets . . . . . . . . . . . . . . . . . . . . . . . . . . 508.3.4 Step 4: Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518.3.5 Step 5-8: Refine Threats Using Threat Trees . . . . . . . . . . . . . 518.3.6 False Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
xii INNEHÅLL
8.3.7 Unauthorized Media Access . . . . . . . . . . . . . . . . . . . . . . . 538.3.8 Traffic Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.3.9 Free Service Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.3.10 Incorrect Billing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548.3.11 Step 9: Cost-Benefit Analysis . . . . . . . . . . . . . . . . . . . . . . 548.3.12 Step 10: Rank Proposed Safeguards . . . . . . . . . . . . . . . . . . 558.3.13 Step 11: Risk Assessment Report . . . . . . . . . . . . . . . . . . . . 55
9 Different Authorization Methods 579.1 Hardware ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579.2 Software ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589.3 Bluetooth Pass-through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589.4 Billing Through Another UE . . . . . . . . . . . . . . . . . . . . . . . . . . 599.5 IRG – IMS Residential Gateway . . . . . . . . . . . . . . . . . . . . . . . . 609.6 Secure Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.7 Step 10: Rank Proposed Safeguards . . . . . . . . . . . . . . . . . . . . . . . 61
9.7.1 Hardware ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.7.2 Secure Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.7.3 Software ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
10 Gaps in IMS – IPTV Integration 6310.0.4 SIP – RTSP Handover . . . . . . . . . . . . . . . . . . . . . . . . . . 63
III Conclusions 6711 Conclusions 69
11.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6911.1.1 General IMS Security . . . . . . . . . . . . . . . . . . . . . . . . . . 6911.1.2 STB/UE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6911.1.3 Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7011.1.4 Gaps in IMS – IPTV Integration . . . . . . . . . . . . . . . . . . . . 7011.1.5 RTSP Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7011.3 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
12 Further Studies 7312.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Litteraturförteckning 75
Figurer
1.1 Activity diagram for the default use case. . . . . . . . . . . . . . . . . . . . 3
2.1 A schematic view of an IPTV network. . . . . . . . . . . . . . . . . . . . . . 10
3.1 A basic use case for SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 A setup of a session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 RTP and RTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 An RTP package is encapsulated in a UDP datagram. . . . . . . . . . . . . 18
4.1 Overview of IMS entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Reference points in IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 IPsec Transport and Tunnel Modes . . . . . . . . . . . . . . . . . . . . . . . 285.2 IPsec Transport Mode[16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 IPsec Tunnel Mode[16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 IPsec ESP[16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.5 Registration with Authentication and Key Agreement (AKA) . . . . . . . . 31
6.1 UML diagram for the vocabulary of risk analysis.[5] . . . . . . . . . . . . . 346.2 A common notation for threat trees. . . . . . . . . . . . . . . . . . . . . . . 38
7.1 Threat tree showing the notation used in this thesis. . . . . . . . . . . . . . 43
8.1 The model of the system used for the risk analysis. . . . . . . . . . . . . . . 488.2 Activity diagram for the default use case. . . . . . . . . . . . . . . . . . . . 498.3 Sequence diagram for the default use case. The IMS core network is simp-
lified to the nodes CSCF and OCS. . . . . . . . . . . . . . . . . . . . . . . . 508.4 Threat tree for a false authorization. . . . . . . . . . . . . . . . . . . . . . . 528.5 Threat tree for unauthorized media access . . . . . . . . . . . . . . . . . . . 538.6 Threat tree for traffic snooping. . . . . . . . . . . . . . . . . . . . . . . . . . 548.7 Threat tree for free access to services. . . . . . . . . . . . . . . . . . . . . . 558.8 Threat tree for incorrect billing . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1 Hardware ISIM card in the STB. . . . . . . . . . . . . . . . . . . . . . . . . 579.2 Software emulation of an ISIM card. . . . . . . . . . . . . . . . . . . . . . . 589.3 Bluetooth pass-through from mobile phone to STB. . . . . . . . . . . . . . 599.4 Billing trough another UE. . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.5 IMS Residential Gateway – IRG . . . . . . . . . . . . . . . . . . . . . . . . 60
xiii
xiv FIGURER
9.6 Secure Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
10.1 IMS/IPTV control channels for VoD. . . . . . . . . . . . . . . . . . . . . . . 65
Tabeller
2.1 An RTSP SETUP example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 SIP Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 SIP Response Code Classes[44] . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 An SDP offer example[44] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 An SDP answer example[44] . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Basic threats in the IPTV system . . . . . . . . . . . . . . . . . . . . . . . . 52
10.1 Example of SIP and RTSP setup of video session . . . . . . . . . . . . . . . 64
xv
xvi TABELLER
Kapitel 1
Introduction
This chapter gives an introduction to the thesis work with a short background and problemdescription. It also defines the goal, limitations and method of the thesis work.
1.1 Background
Traditionally, communication networks have been built to support one type of service. Du-ring the evolution of communication services the demand for better services has increased,and this increases the cost of the network. At the same time, competition has decreasedthe price of these services. This has lowered the Average Return Per User (ARPU) andhas increased the network to service cost ratio. To cope with the demand for better ser-vices and to lower the cost for the network, service providers have begun to investigateconverging networks into a common infrastructure delivering multiple services. This willincrease the revenues from the services and offer new possibilities of combined and complexservices.
One fast growing service is IP Television (IPTV), this is television sent over an IP-connection which provides many advantages over normal air broadcasted, cable or satelliteTV. The most important advantages are the availability of an unlimited channel space,two way communication, and support for personalized content based on the preferences ofthe viewer.
One of the most important IPTV services will be Video on Demand (VoD), i.e. theability to buy content directly by using a remote control. This could change the role oftelevision from a passive medium to an interactive medium.
The prime candidate for a standard for a converged communication network is the IPMultimedia Subsystem (IMS)[43]. IMS is standardized by the 3rd Generation PartnershipProject[1] (3GPP) which is also behind the current Third Generation (3G) mobile system;Universal Mobile Telecommunication System (UMTS). The IMS system is a part of UMTSand it reuses most of its protocols from the Internet standard organization Internet Engi-neering Task Force[19] (IETF). The main function of IMS is to route calls but it is alsoa profound base for different services. Because of this, the system receives attention frommore than just telephone service actors.
1
2 1.2. PURPOSE
1.2 PurposeThere is a growing interest among Triple Play1 actors for the IMS Next GenerationNetwork (IMS NGN) which is a variant of IMS that focuses on a wider use of IMS. Itfocuses on providing a service platform in fixed access networks, such as Digital Subscri-ber Line (xDSL) and Fiber To The Premises (FTTP), to give fixed broadband access toan IMS network. These will deliver a multitude of services including telephony, TV, andInternet. [45]
IPTV is one of the major services in an IMS NGN network, without it the deploymentof such a network is of much less value. To be able to use on-demand services in anIPTV/IMS network it has to be reasonably secure to allow the service provider to chargefor the services.
The purpose of this thesis work is to investigate the security of such a network and toprovide useful input for developers of a Set-Top-Box (STB) on which technologies to useand what threats there are that have to be addressed to build a secure IPTV/IMS system.
1.3 ScenarioThe system I investigated consists of an IMS (home-) network, an STB and a streamingserver. The complete network is under the control of the IPTV/IMS service provider.
1.3.1 Use CaseThe basic scenario to investigate is when a user powers up the STB that is connected toan IMS system and selects a video to watch. The user is charged for the service on hisaccount. The activity diagram for this use case is shown in figure 1.1.
The system requires that the subscriber has the correct credentials present in the STBas described in 1.6.
The scenario does not specify any certain business model for billing or any restrictionon the contents the user can access.
1.4 ConstraintsThere are some constraints on the system investigated. These are given by Motorola toconstrain the investigation to a setup that is interesting to them to develop.
1.4.1 IMSIMS should be used for Authentication, Authorization, and Accounting (AAA). The IMSsystem has a security architecture that should be used to the greatest possible extent. Thisleads to easier administration and has the advantage of a well known security architecture.
1Triple Play – Using a single connection to provide phone, TV and Internet
KAPITEL 1. INTRODUCTION 3
RegisterOrderMovieChargingforServiceMovieStreamStarts
DefaultUseCaseActivityDiagram
Authorization?
NotenoughEnoughWatchMovie
FailedSucceeded
Checkfunds?Permissioncontrol?FailedSucceeded
OrderMovie
Figur 1.1: Activity diagram for the default use case.
1.4.2 STBThe STB should be able to send requests for VoD services to IMS using SIP signalingthrough a common API. UE’s have a single way of communicating with IMS, they onlydiffer in their capabilities, such as connection speed, screen resolution, input methods, etc(see 4).
1.4.3 Billing and SecurityThe most important aspect of this thesis is to investigate a secure technology for billing.This should be done by evaluating the existing security methods in IMS and by considering
4 1.5. GOAL
each modification required to add the STB into the IMS system.
1.5 Goal
This thesis should present a well investigated solution to incorporating an STB in an IMSnetwork with functions for handling VoD services in a secure way. A threat analysis willshow what threats the system has to be protected from. The conclusion should presentan evaluation of different technologies for authentication and weaknesses in the currentspecification.
KAPITEL 1. INTRODUCTION 5
1.6 Problem DescriptionThe problem can be specified as follows:
Is it possible to, in a secure way, use an STB to connect to an IMS system and order VoDservices?
This requires a definition of the word secure. I choose to use the following definition: Usingthe same security features as IMS does to achieve security.
This does not explain what is secure, it just declares that if 3GPP uses the samesecurity features in an equivalent scenario it will be regarded as secure. To answer thequestion it is refined into two smaller questions:
• Which technologies can be used for authentication?
• Are there any security gaps in merging IPTV and IMS?
1.7 MethodTo solve the problem, a structured method will be used. First I will investigate how anIMS and IPTV system works. Then a threat analysis method will be chosen and adaptedto suit the specific needs of the task. With the help of the threat analysis, countermeasurescan be evaluated and weak points in the system can be identified.
Different technologies for authentication will be evaluated to answer these questionfor each of the technologies:
1. Is the technology acceptably secure?
2. What are the advantages and drawbacks of the technology?
These two questions go hand-in-hand, since what is acceptable in one system or stage ofdeployment may not be acceptable in a later stage or in another system. This informationwill help guide a system designer to choose the correct solution depending on differentdemands on the architecture, usability, business model and legal demands.
1.8 LimitsThis thesis focuses on using IMS for billing of VoD services in an IPTV network. Othertypes of Pay-Per-View (PPV) will not be considered. Furthermore the confidentiality of themedia stream will neither be taken into account. Since a VoD media stream is singelcastit can be solved with encryption without much difficulties on the client side.
1.9 Target AudienceThis report is intended to be read by developers with a basic knowledge of SIP/IMS, IPTVand a good understanding of modern security technologies. The thesis will present a basicoverview of IPTV, IMS and security techniques. To fully understand the topic the readershould have more knowledge especially in the areas of IMS and security.
6 1.10. OUTLINE OF THE REPORT
1.10 Outline of the ReportThe outline of the thesis is:
Part I Theoretical Background
2. IPTV: Describes IPTV systems and the technology used today. This system isone of the base parts in this thesis.
3. SIP: SIP is the signaling protocol in IMS and very important to understandhow connections are established in IMS.
4. IMS – IP Multimedia Subsystem: IMS is a complex system but an overvi-ew of the system is given in this chapter. It describes the parts necessary tounderstand the problems investigated in this thesis.
5. Security: This chapter mostly serves as a reminder for the user. It is not on itsown enough to present all important aspects of information security.
6. Risk Analysis: Describes the basics of risk analysis used in this report.
Part II Investigation
7. Adapted Risk Analysis Method: An adapted risk analysis method is usedto analyze the risks in the system. This is used to structure and break downthe complex problem.
8. Threat Analysis: This sections contains the analysis of threats to the system.These are presented in section 8.3 and are used to evaluate the differentauthorization methods in the next section.
9 Different Authorization Methods: Presents some authorization methods thatcould be used in the STB. It uses results of the threat analysis to evaluatedifferent alternatives of authorization.
10 Gaps in IMS – IPTV Integration: Describes problems with specificationsand integration between an IMS system and IPTV. This section does notcover this topic, but rather pointing out the problems found by the author.
Part III Conclusions
Del I
Theoretical Background
7
Kapitel 2
IPTV – IP Television
IPTV is TV broadcasted over an IP network. The main advantage is that instead ofbuilding and maintaining a special network for cable TV it can be combined with a normalIP network used for Internet access. This gives opportunities for advanced TV services,such as web browsing, e-mail, Electronic Program Guides (EPG), and Video on Demand(VoD).
There is no standard for IPTV networks and transmission, but the general setup iscommon and most protocols for the network are well known standard protocols.
The network is always under control of the service provider who has to be able toguarantee Quality of Service (QoS). The transmission starts at the Video Head End (VHE),which is a streaming server receiving video feeds from satellite or cable, and encodes andcompresses it into a digital video stream. The transmission could also start in a VoD serverstreaming video to customers. These video streams are stored in the server.
2.1 Common configuration
A common configuration of an IPTV network is shown in figure 2.1. The figure showsthe backbone which connects all local networks with a high bandwidth connection. At thebackbone there is a live feed server that captures, encodes and streams live video over thenetwork. This server captures the video from some external source such as satellite or acable-TV connection. It uses multicast to transmit channels to viewers. Commonly thereis also an application server that supplies customers with mostly non-video services, suchas web browsing, e-mail and content information. Finally there is a VoD server storingvideo for distribution by unicast to customers on demand.
The backbone is connected to the local networks through at least one layer of routers.Since the VoD media is unicasted, the VoD server and the network would soon be overloa-ded if many customers used VoD at the same time. To solve this there are caching serverscloser to the customer that cache VoD contents that pass the network. The next time acustomer accesses the VoD contents the VoD server can delegate to the caching server toprovide it.
9
10 2.1. COMMON CONFIGURATION
Figur 2.1: A schematic view of an IPTV network.
2.1.1 MulticastingMulticast is to send one-to-many, this is vital for live transmissions of TV in an IP network.This gives the VHE the ability to send a stream for one channel to every subscriber thatwatches that particular channel. If normal unicasting where to be used the VHE had toset up a stream to every viewer. This would make up-scaling of the network impossibleand in reality make it unprofitable to build IPTV networks.
Since VoD does not use multicast, no further information will be given on this topiceven though it is vital for live feeds in IPTV networks.
2.1.2 MPEG-TSThe most common way to transport live video media in an IPTV network is to use MotionPictures Expert Group (MPEG)[40] version 2 or 4. The stream is actually an MPEGTransport Stream (MPEG-TS) that runs on top of UDP and encapsulates the media insmall 188 byte datagrams[15].
2.1.3 RTSPThe Real-time Streaming Protocol (RTSP)[21] is used as a remote control for a videostream. It can be used to setup feeds, play, pause, forward and record. This is mostly usedfor VoD services where these functions make sense but it could also be used for remoterecording of a live feed to a server for later viewing.
KAPITEL 2. IPTV – IP TELEVISION 11
C→S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0CSeq: 302Transport: RTP/AVP;unicast;client_port=4588-4589
S→C: RTSP/1.0 200 OKCSeq: 302Date: 23 Jan 1997 15:35:06 GMTSession: 47112344Transport: RTP/AVP;unicast;client_port=4588-4589;
server_port=6256-6257
Tabell 2.1: An RTSP SETUP example
Since the topic for this thesis is VoD we go into some detail on RTSP. RTSP is mostlyused on a reliable transport protocol, normally TCP. It uses commands and responsessimilar to HTTP to make it possible to use an HTTP parser to build an RTSP server. Incontrast to an HTTP server an RTSP server is not stateless, it has to maintain a state foreach connected client. The central commands in RTSP are:
• DESCRIBE is used to get parameters for a stream such as type, bitrates, encoding,and decryption keys. Describe uses SDP to describe the session, see section 3.6 forinformation on SDP.
• SETUP is used to order a stream, with a specific set of parameters.
• PLAY/RECORD can be issued after a successful SETUP has been executed. Thisorders the server to start the stream or to connect to the stream and start recordingit.
• PAUSE stops the streaming but keeps the current state in the RTSP server. If aPLAY/RECORD command is issued after PAUSE without arguments the play-ing/recording is continued from the same place as it was paused.
• TEARDOWN is used to close a connection. This is important since it allows theRTSP server to free the resources reserved for the connection.
To show some important properties of RTSP we look a bit closer at the setup andplay commands. An example setup and response is shown in table 2.1.
RTSP can use the HTTP basic authentication or HTTP digest authentication mecha-nisms [23]. It can also be used with security from the network layer, e.g. IPsec[35].
2.2 FutureIPTV is quite a new technology for distributing TV. It has been built without standardi-zation or common technology.
To successfully continue to develop and deploy these systems they have to be basedon an open standard. IPTV is mostly deployed by companies also providing phone and
12 2.2. FUTURE
Internet services to their customers and the demand for a converged network from theservice providers is strong.
Kapitel 3
SIP – Session Initiation Protocol
Session Initiation Protocol (SIP)[27] is a protocol for setting up media streams betweentwo parties. The protocol was originally intended for setting up audio and video calls overan IP network, but since it is so flexible it can be used to setup any type of stream.
SIP is a signaling protocol used for Voice-over-IP (VoIP) and general signaling in IMSsystems. As such it is one of the basic building blocks of the next generation of IP basedtelephone systems.
There are three types of elements in SIP: User Agents (UA), Servers, and Locationservers. A basic use case of SIP is shown in figure 3.1. SIP users are identified by their
Figur 3.1: A basic use case for SIP.
SIP URI. It is similar to an e-mail address but is proceeded by sip:// or sips:// fortransport layer encrypted connections, e.g. sip://[email protected].
3.1 User AgentsUA’s are the end devices in the SIP network. They communicate with each other throughzero or more SIP servers. A UA may be a mobile phone, software phone, or a traditionalwired phone in a Public Switched Telephone Network (PSTN) calling through an SIPgateway. It could also be a voice mail server which acts on behalf of an unregistered orbusy UA.
13
14 3.2. SERVERS
3.2 ServersThere are three types of SIP servers: SIP proxies, Redirect servers, and Registrar servers.
An SIP proxy is a signaling only server which modifies and/or controls the passingSIP signaling. It is often used to enforce policies, for anonymizer services, or similar.
A Redirect server is also a signaling only server. It answers the invite method witha redirection response (3xx). This is used to direct a caller to the correct UA where thecallee is currently registered.
A Registrar server is used by UA’s to register their current status and location intothe location server. This information is used by the caller to reach the callee by calling aredirect server.
3.3 Location ServersA location server[27] is a database containing information about users’ registered IP ad-dresses, features, and other preferences. The UA does not directly communicate with thelocation server, this is done through a proxy, redirect, or a registrar server. These serverscommunicate with the location server in an unspecified way and act as an SIP front-endfor the location server.
3.4 SIP MethodsSIP uses plain text message methods similar to HTTP[22] and Simple Mail Transfer Pro-tocol (SMTP)[26]. The most common SIP methods are shown in table 3.1. The first sixare defined in the basic RFC[27], the rest of the methods are extensions to SIP.
Method RFC DescriptionINVITE RFC3261[27] Session setupACK RFC3261 Acknowledgment to INVITEBYE RFC3261 Session terminationCANCEL RFC3261 Abort sessionREGISTER RFC3261 Register a user’s URIOPTIONS RFC3261 Query of options and capabilitiesINFO RFC2976[25] Midcall signaling transportPRACK RFC3262[28] Provisional response acknowledgmentREFER RFC3515[31] Redirect user to another URLSUBSCRIBE RFC3265[29] Request notification of an eventNOTIFY RFC3265 Notification of an eventMESSAGE RFC3428[30] Instant message body
Tabell 3.1: SIP Methods
KAPITEL 3. SIP – SESSION INITIATION PROTOCOL 15
3.5 SIP Response CodesSIP uses a set of numeric response codes as response to each method sent. These responsecodes correspond to and extend the ones used in HTTP. The codes can be followed bya text string, the content of which is insignificant to the client and only used to simplifydebugging. The response codes are divided into classes shown in table 3.2.
Class Description1xx Provisional or Informational: the request is progressing
but not yet complete2xx Success: the request has completed successfully3xx Redirection: the request should be tried at another loca-
tion4xx Client Error: the request was not completed due to error
in the request and can be retried when corrected5xx Server Error: the request was not completed due to error
in the recipient and can be retried at another location6xx Global Failure: the request has failed and should not be
retried again
Tabell 3.2: SIP Response Code Classes[44]
3.6 SDPTo negotiate the setup of streams SIP uses another protocol named Session DescriptionProtocol (SDP)[37]. It is a special protocol for describing sessions and their parametersused by a number of different protocols. An SDP offer is shown in table 3.3.
v is the version of the protocol, the current version is 0.c is the connection, with the arguments IN for Internet, IP4 for IP version 4, and
finally the IP address.m is the media type, in this case there are two: one video and one audio. Each
of them are followed by a port and two Real-time Transport Protocol/AudioVideo Profile (RTP/AVP).
a is the attributes: rtpmap maps an RTP/AVP to a codec e.g. RTP/AVP 14 isMPA with a sampling rate of 90000Hz.
The callee answers with an SDP with a subset of the offered media sessions. In thisparticular example the GSM encoded audio is kept. But video is declined by specifying azero (0) port number.
SDP includes many more descriptors, these are just the basic ones needed for un-derstanding and reasoning in the thesis. For any details the reader is directed to the RFC4566[37].
SDP is also used by RTSP for session description, see section 2.1.3 for more informa-tion.
16 3.7. AUTHENTICATION
v=0o=s=c=IN IP4 128.2.3.1t=m=video 4004 RTP/AVP 14 26a=rtpmap:14 MPA/90000a=rtpmap:26 JBEG/90000m=audio 4006 RTP/AVP 0 4a=rtpmap:0 PCMU/8000a=rtpmap:4 GSM/8000
Tabell 3.3: An SDP offer example[44]
v=0o=s=c=IN IP4 16.22.3.1t=m=video 0 RTP/AVP 14m=audio 6002 RTP/AVP 4a=rtpmap:4 GSM/8000
Tabell 3.4: An SDP answer example[44]
3.7 AuthenticationThe specification for SIP[27] requires that it has some authentication mechanisms, theseare inherited from HTTP. The most important one for this thesis is the HTTP digestauthentication[23] that is used in IMS. See 5.6.
3.8 RegisterTo be able to find the correct UA from an SIP URI the UA has to register its currentlocation and status in the location service. By issuing a register method to a registrarserver connected to the location server, the UA is registered.
Later when a caller calls an SIP URI it starts by looking up the address to the serverpart of the URI. This lookup is done by Domain Name System Service (DNS SRV)[24].The DNS SRV response gives a redirect server for the domain. The caller issues an inviteto the redirect server. It answers with a redirect response, calling for a redirect to theUA previously registered by the user. Often the DNS SRV response directs the caller to a
KAPITEL 3. SIP – SESSION INITIATION PROTOCOL 17
proxy server instead of a redirect server.
3.9 InviteThe invite method is used to setup communication between two UA’s. The caller, A, issuesan invite to the callee, B. The invite includes an SDP with the available encodings andoptions that the caller wants to use. The callee’s UA answers with trying and ringing.When the callee answers the call the UA sends an OK message including an SDP with theselected codec’s and options. This is answered with an acknowledgment from the callersUA. After this the media streams negotiated by the exchange of SDP messages can begin.See figure 3.2.
Figur 3.2: A setup of a session
3.10 Basic Network Media ServiceThe request for media from an SIP media server is done by issuing an invite to the SIP URIwith the user annc at the media server and with the parameter: play=[media URL][34].E.g.
sip:[email protected]; \play=http://audio.example.net/allcircuitsbusy.g711
This is useful since it limits the usernames needed for the media server and eases the loadof the registrar server. If each media file were to be selected just by a username part of theURI, the media server would have to register each of them with the registrar server andrenew them before they timed out. This could easily lead to overloading of the registrar,
18 3.11. RTP/RTCP
Figur 3.3: RTP and RTCP
Figur 3.4: An RTP package is encapsulated in a UDP datagram.
e.g. an on-demand repository of music could collect millions of items that need to bere-registered, usually every hour.
3.11 RTP/RTCPReal-time Transport Protocol (RTP)[32] is a transport layer protocol for sending mediastreams over an IP-network. RTP is typically used on top of User Datagram Protocol(UDP)[20].
UDP lacks information important to a media stream, such as the datagram sequencein the stream and timestamps to keep the playback in real-time and to sync differentstreams. RTP implements these vital functions on top of UDP. It adds type information,sequencing, time stamping, and mixing information to the UDP datagram.
Since RTP is a transport layer protocol it does not have a well defined port number,but an RTP-connection always uses an even port number to send its data. The odd portnumbers are used for the Real-time Transport Control Protocol (RTCP)[32] that common-ly accompanies an RTP-connection. The associated RTCP-connection uses the succeedingport number of the RTP port number which it is controlling. RTCP is mainly used toreturn feedback on the reception of the stream to the sending server.
Kapitel 4
IMS – IP Multimedia Subsystem
IP Multimedia Subsystem (IMS) is the service platform for the next generation phonesystems, both fixed and mobile. By using this open standard on an IP based network,telecommunication will move towards using cheap and well known IP networks. IMS alsoadds functions to satisfy the strict QoS and Authentication, Authorization, and Accounting(AAA) (see 5.1) demands on a telecommunication network. The open standard ensuresinteroperability between operators and system providers. To speed up the development,IMS mostly uses well known protocols used on the Internet, specified by IETF.
This will be the next big step for the telecom industry according to Ericsson [43], theworld leading telecommunication system provider[13].
4.1 OverviewAn IMS system is built in four layers: the Access network plane, the user plane, the controlplane, and the application plane.
The access network plane consists of a physical network infrastructure supplying IPconnectivity. The access network can consist of RAN, WLAN, xDSL, or other types of IPable networks. Some of these access methods are not fully specified in IMS yet, but theyare being investigated in Next Generations Network (NGN), and will eventually find theirway into a release of IMS.
The user plane transports the media between the different users. It consist of thelogical connections between users.
The control plane contains control signaling and enforces policies and security onlower levels of the network. It is also responsible for the QoS of the network. This isvery important since it ensures that a standard “best-effort” IP network is usable as atelecommunication network with its strict QoS requirements. The two most importantfunctions in the control plane are the Call Session Control Function (CSCF) and theHome Subscriber Server (HSS), see figure 4.1. There are more functions in the controlplane but they are not crucial to the scenario in this thesis.
At the top is the application plane where the Application Server (AS) and OnlineCharging System (OCS) reside. AS’s implement different services for the users such asvoice mail, teleconferencing etc.
The IMS specifications do not define how each function works, it rather specifiesreference points and how the functions communicate with each other.
19
20 4.2. CSCF – CALL SESSION CONTROL FUNCTION
UE P-CSCF I-CSCF
S-CSCF
AS
HSS
OCS
User Plane
Control Plane
Application Plane
IPv6 Backbone Media Stream
Figur 4.1: Overview of IMS entities
4.2 CSCF – Call Session Control Function
The Call Session Control Function (CSCF) consists of three different functions, the ProxyCSCF (P-CSCF), the Interrogating CSCF (I-CSCF), and the Serving CSCF (S-CSCF).
All UA signaling first passes the edge gateway, the P-CSCF, which directs the trafficto an I-CSCF or an S-CSCF. The P-CSCF is responsible for finding the correct I/S-CSCFand handles the security of the UE.
The I-CSCF is the contact point for all SIP signaling from another operator’s networkdestined to a UE in the I-CSCF’s network. It is usually also responsible for hiding thetopology of the operator’s network from other operators by a function called TopologyHiding Inter-network Gateway (THIG).
The S-CSCF is the function that actually handles the session. It routes the connectionto its correct destination, controls the type of connection set up between UE’s, takes careof registration etc.
KAPITEL 4. IMS – IP MULTIMEDIA SUBSYSTEM 21
4.3 HSS – Home Subscriber ServerThe HSS maintains a database of all the subscribers, their setup, and their current re-gistration state. This information is used by the CSCF’s to route the signaling to thecorrect S/I-CSCF. The HSS also produces AAA vectors to be used by the network whenauthenticating itself and the UE.
In an NGN IMS-network the HSS is called User Profile Server Function (UPSF) andhas some additional capabilities; it is however functionally equivalent for the purpose ofthis investigation.
4.4 AS – Application ServerAn Application Server (AS) provides the IMS system with a specialized service. Since theycommunicate with well defined protocols, the deployment time is short and they can beused in all IMS systems. This is one of the main advantages of IMS; by using an openplatform it opens for competitive development of services that do not need to be tailoredfor each service provider.
4.5 PEP/PDFThe Policy Enforcement Point (PEP) is an entity in the network that enforces policies.This is usually done by filtering the traffic. The Policy Decision Function (PDF) controlsthe network by controlling the PEP’s. For example, S-CSCF can reserve QoS in a routerfor a call. Then the S-CSCF acts as a PDF and the router as a PEP. This is a complicatedmatter, but it is necessary in order to make the best-effort IP network to a strict QoSnetwork acceptable for telecommunication services.
4.6 CCF/OCSThere are two functions for charging (billing) in IMS: the Charging Collection Function(CCF) for offline charging and the Online Charging System (OCS) for online charging.Offline charging is classical charging where service usage is collected on a bill at the end ofthe month. Online charging is used when the user prepays for services by buying credits.When an OCS is used, the charging entity, e.g. an S-CSCF, reserves a certain amount ofcredits and deducts them as the service session continues. If the user runs out of creditsthe OCS notifies the charging entity which will terminate its service. OCS can also be usedfor traditional billing at the end of the month.
4.7 ISIMAll UE in an IMS network will have a Universal Integrated Circuit Card (UICC) with anIMS Subscribers Identity Module (ISIM) function. The ISIM is an advanced version ofthe old Subscribers Identity Module (SIM) and the UMTS Subscribers Identity Module(USIM). It contains information regarding public and private user identity, home network
22 4.8. REFERENCE POINTS
information, and administrative data. It also contains security keys used to calculate re-sponses to authentication challenges and session keys. There will be more about this insection 5.7 IMS security.
4.8 Reference PointsBy tradition, all connections between different functional entities in telecommunicationsare assigned a name, usually consisting of two letters. The reference point is specified byits protocol and the messages that are sent through it.
The reference points important for this thesis in a basic IMS system are shown infigure 4.2.
Figur 4.2: Reference points in IMS
4.8.1 GmGm is the reference point between the UE and the P-CSCF. It is used to send SIP messagesto initiate services. This is probably the most important reference point since it is the onebetween the user owned UE and the service provider’s core network. It cannot be physicallyprotected since it should be possible to use in a mobile environment and to roam throughother service providers’ networks. It also requires a high compatibility between P-CSCF’sand different UE’s in contrast to equipment within the core network which can be finetuned to inter-operate.
KAPITEL 4. IMS – IP MULTIMEDIA SUBSYSTEM 23
The Gm interface has three main categories of messages: registration, session controland transactions. Registration handles the authentication of the user and setup of thesecurity on the reference point. The session control messages are used to initiate, setup,and terminate sessions. The transaction messages are standalone messages that carry forexample Instant Messages (IM) that do not create a dialog.
4.8.2 MwMw is the reference point between the CSCF’s which transmits SIP messages. The Mwreference point has the same classes of messages as the Gm interface.
4.8.3 CxCx is the reference point between I/S-CSCF and the HSS which uses the Diameter protocol.
4.8.4 ICSThe IMS Service Control (ICS) is used between the I/S-CSCF and an AS. When an I/S-CSCF gets a session initiation request it analyzes it and if required routes it to an ASfor further processing. Also, initial invites can originate from an AS in response to someexternal event. This could be an automated wake up call where the AS calls a subscriberon a requested time.
4.8.5 ShAn AS may need user information or parameters stored in the HSS. this is what the Shreference point is used for. It uses the Diameter protocol to handle data and for subscrip-tion/notification. The HSS has a list of the AS’s permissions to read and alter data.
4.8.6 RoOnline charging is done over the Ro reference point towards the OCS. It communicatesover Ro using Diameter with AS’s and S-CSCF’s. The OCS can reserve, control and chargethe user depending on the request from the peer.
24 4.8. REFERENCE POINTS
Kapitel 5
Security
This chapter has a brief introduction to some security concepts and a description of somesecurity technologies used by IPTV or IMS.
5.1 IntroductionSecurity for services and communication is often divided into three properties Confidenti-ality, Integrity, and Availability (CIA).
• Confidentiality is the property that only authorized users can access the informa-tion. This is often enforced by Access Control (AC) and/or encryption, which onlyallows the holders of the key to read the information.
• Integrity is the property that only authorized users can modify and create theinformation. This is also enforced by AC and cryptographic signatures or sometimeswith encryption.
• Availability is the property that ensures the availability of the service or the in-formation. This requires good design of the services and networks, so that they arenot easily exhausted of resources.
To ensure the CIA-properties there have to be three systems or functions in a service orcommunication: Authentication, Authorization, and Accounting (AAA).
• Authentication it the function which identifies the user. It must exist an authen-tication system since it is the base of all security. This does not have to be a classicusername and password system, it could be implicit, e.g. the holder of the secret keyis authenticated by the ability to encrypt a message that the receiver can decryptproducing a meaningful message.
• Authorization is the system which determines if a user is granted or denied a re-source. The authorization system enforces the access policies based on the identifieduser and the resource requested.
• Accounting is the system which logs activities. This information can be used inmultiple ways, e.g. for billing, for monitoring attempts to breach security, and formonitoring legitimate users’ use of services and resources.
25
26 5.2. ATTACKS ON COMMUNICATION
These systems are the main systems that try to enforce the security policy, but all systems,software and hardware are important since attackers often uses weaknesses in the systemto bypass one or several of the AAA systems. These attacks require security awarenessand proper routines within the organization, and are extremely important for maintaininghigh security. They are however out of scope for this thesis.
5.2 Attacks on CommunicationAttacks on communication can be divided into different classes depending on how theyare executed. They are not necessarily mutually exclusive. The classes described here areuseful in this thesis to understand the threats and countermeasures.
5.2.1 Man-in-the-middleTo read communication between Alice and Bob, Eve sits in the middle and fools Alice thatshe is Bob and Bob that she is Alice. Thus Alice and Bob send all their communicationto Eve who reads it and passes it on to the correct destination. Eve can also modify themessage before re-sending it or choose not to pass it on. She can also insert fake messagesinto the communication. This is mostly used against public key encryption systems withouta system for authentication. Thus the attacker can sit in the middle of an encryptedcommunication and read and alter message as she pleases.
To protect from false or altered messages, but not deleted and read messages, a cryp-tographic checksum can be attached to the message. Only the holder of the key can verifyand construct a correct message.
To protect against Eve reading the message in transit, the message can be encrypted.This requires Eve to get hold of the secret key before being able to read the message.
5.2.2 ReplayA replay attack is when a message can recorded to be replayed later. For example Everecords the communication from Alice to Bob. Later, Eve can send it again. For example,if Alice sends “Pay Eve $100” to Bob and Eve records it and sends it five more times, Bobthinks he should pay Eve $600 instead of $100.
To protect against such an attack each message needs timing information, either atime stamp or a sequence number, and only new messages are accepted by the receiver.
5.2.3 DoS – Denial of ServiceBy blocking, overloading, or stopping a service, an attacker can deny other users access tothe service. This can be done in many ways, but the basic idea is to exhaust a resource ofthe service so that it cannot serve legitimate requests for the service.
It is hard to protect from Denial of Service (DoS) attacks since the attack simply con-sists of too many requests for service. It can be protected against with Intrusion DetectionSystems (IDS) that detect an attack and try to block the attacker out. Since usuallyDoS attacks are distributed between many different attackers, a so called Distributed DoS(DDoS), this can be hard.
KAPITEL 5. SECURITY 27
5.3 Basic cryptographyIn this section a short description of the vocabulary of cryptography is presented. Forfurther reading consult a text book on information security such as [12].
5.3.1 Symmetric cryptographyAlice sends a message to Bob and encrypts it using a secret key that is also known toBob. When Bob receives the encrypted message, he decrypts it by using the same key andrunning the same encryption algorithm backwards. This gives Bob the original messageand protects the confidentiality of the message since only the holder of the key can readit. It also protects the integrity of the message because it is not possible to change thecrypto text without the key and end up with a reasonable clear text. Further, if only Aliceand Bob have the key it serves as an authentication if only a small set of all possible cleartext messages are reasonable.
5.3.2 Asymmetric cryptographyWith an asymmetric crypto there are two keys: a public encryption key and a secretdecryption key. With such a system it is possible for anyone that has the public key togenerate an encrypted message and send it to the holder of the secret decryption key. Thisholder can then decrypt the message, but she is the only one able to do that. This protectsthe confidentiality of the message, but never the integrity or the origin, since anyone withaccess to the public encryption key can generate a crypto text. This is a simplification sincethe encryption key does not have to be public, but this is how asymmetric cryptographyis used in practice.
5.3.3 Cryptographic SignaturesTo provide authentication of origin and integrity of a message, asymmetric cryptographycan be used. The signature is created by using a non-colliding hash function to producea hash of the message and then use a secret encryption key to encrypt it. This encryptedhash output is attached to the message. The receiver can verify the signature by generatingthe same hash, decrypt the signature (the encrypted hash) with the public decryption keyand compare the result with the anticipated hash. If they are the same it proves that thesender had the secret encryption key and that the message was unaltered in transit. Thisuses the keys in the opposite way compared to normal symmetric encryption, where theencryption key is public and the decryption key is private.
The non-colliding hash function is used because it is impractical to encrypt the wholemessage and attach it to the original; this would result in a message twice as long as theoriginal one. Instead, a checksum of the message is calculated and encrypted. The checksumis always of the same size regardless of the length of the message. To do this a collision-freehash function is needed. This is a function that calculates a fixed size checksum for aninput in a way that it is impossible (at least infeasible) to guess a possible message froma checksum.
If it were possible to guess another possible message for the checksum this couldbe done by an impostor to alter the message and still get the same output of the hashfunction. With the same output of the hash function the cryptographic signature wouldstill be correct, for an altered message.
28 5.4. SSL/TLS
5.4 SSL/TLSSecure Socket Layer (SSL) is a protocol developed by Netscape to secure connectionsover HTTP. This protocol was later transformed into a general security protocol for thetransportation layer by IETF, the Transport Layer Security (TLS)[36].
TLS is used between a reliable transport protocol, e.g. TCP, and the applicationlayer. TLS complements the transport layer with authentication of the server and client,encryption of the application data for privacy, and a digest for controlling the integrity ofthe application data. It also takes care of the negotiation of security parameters such asencryption algorithms and exchanges of session keys.
The level of security that TLS offers depends on the parameters and the implementa-tion used; with a good setup it can be considered secure.
5.5 IPsecIP Security (IPsec)[35] is a collection of protocols designed by IETF. These protocols sup-ply security on the IP level, which requires the connection-less IP protocol to be changedinto a connection oriented protocol. The connection is a unidirectional connection definedby three elements:
1. Security Parameter Index (SPI)
2. Protocol, AH or ESP
3. Source IP Address
The IPsec connection is setup by an Secure Association (SA), which defines modes, keysand algorithms for a connection. The SA is fetched from an Security Policy Database(SPD) which contains policy decisions on what traffic should use which SA, no IPsec,or be dropped. This decision is based on the type of IP datagram, the source and thedestination address and port.
5.5.1 Transport and Tunnel ModeIPsec works in two different modes: transport mode and tunnel mode, see 5.1. In the
Figur 5.1: IPsec Transport and Tunnel Modes
normal mode, i.e the transport mode, the IPsec header is put between the IP headerand the payload of the datagram, see 5.2. In the tunnel mode, the entire IP datagram is
KAPITEL 5. SECURITY 29
Figur 5.2: IPsec Transport Mode[16]
put within an IPsec datagram with a new IP header, IPsec header and the complete IPdatagram as payload, see 5.3. This is useful for putting up VPN’s when not all entitiesin the network implement IPsec. Two entities are used as tunnel start- and end-points.Between these all traffic is protected by IPsec, but on each side there is a normal IPnetwork.
Figur 5.3: IPsec Tunnel Mode[16]
5.5.2 ESP – Encapsulating Security PayloadThere are two protocols within IPsec: ESP and Authentication Header (AH). The AHprotocol is the older one and only provides authentication of the source host. This protocolis replaced by ESP which is the only one used in IMS.
ESP adds a header and a trailer to the IP datagram. After this the authenticationdata is added by using an authentication scheme.
ESP provides authentication, integrity and privacy for a message.
Figur 5.4: IPsec ESP[16]
5.6 SIP SecuritySIP borrows authentication functions from HTTP. It can use a HTTP-digest to authenti-cate users. This is done in a simple challenge response which includes a random generated
30 5.7. IMS SECURITY
nonce, and the required algorithm to use. The client is expected to re-register by supply-ing the server with a response; the response is the random nonce encrypted with a secretkey only known to the client and the server. If the response matches the servers expectedresponse the client is authenticated and authorized to register.
5.7 IMS SecurityIMS uses two systems to provide a secure communication within the network. Within thecore network it uses Network Domain Security for the IP-layer (NDS/IP) this is specifiedin “Network Domain Security (NDS)”[8]. The security functions for the communicationbetween the UE and the core network are described in “Access security for IP-based ser-vices”[7]. A general overview is given in “Security architecture”[6]. Further, the specificdemands on NGN IMS security are described in “NGN SEC”[10].
5.7.1 NDS/IP – Network Domain Security IPThe NDS document specifies that NDS/IP is optional to use in the core network but man-datory to use between different core networks. NDS/IP uses IPsec to secure the integrityand optionally the confidentiality of the communication.
The whole system is optional since the core network can be seen as a trusted network.
5.7.2 AKA – Authentication and Key AgreementThe mechanism to setup a secure channel for SIP between the UE and the P-CSCFis named Authentication and Key Agreement (AKA). This is derived from the UMTS(3G) system specification. It uses a UICC[39][41], often called a smart card, with a IMSSubscribers Identity Module (ISIM)[11]. The ISIM stores information about the subscriber.The ISIM stores a secret key which it shares with the HSS.
When the UE wants to register, it issues a register to the P-CSCF who responds witha 401 challenge response. This answer includes the security parameters and a nonce.The UE calculates a response, an Integrity Key (IK), and a Cipher Key (CK) using thesecret key stored in the ISIM card. Actually, the response, IK, and CK are calculated inthe ISIM card. The secret key cannot be read out from the ISIM card. This is a importantsecurity feature since the ISIM card cannot be copied. To access this function in the ISIMcard it requires the user to input a Personal Identification Number (PIN). See the figure5.5. This requires the user to identify herself by something she knows, the PIN and bysomething she has, the ISIM card. This gives a robust base for the authentication. Theresponse is sent in a new register message and the message is sent over IPsec with acryptographic signature using the IK. This can then be verified by the P-CSCF to ensurethat the message is unaltered and that the encrypted nonce, the response, is verified. Thisshows that the UE has the correct ISIM card.
Depending on the policy of the network, the IPsec connection uses encryption; this ishowever optional. Since some IP Connectivity Access Networks (IPCAN’s) have encryptionon a lower level or are trusted, this feature is only used when it is mandated by the policy.In the case of an NGN IMS network with an xDSL or Ethernet connection it should beused since they lack lower level encryption.
To protect from man-in-the-middle attacks against UE’s fooled to connect to a falseP-CSCF, the network is authenticated with a AUTN line in the challenge response request.
KAPITEL 5. SECURITY 31
Figur 5.5: Registration with Authentication and Key Agreement (AKA)
The AUTN includes a sequence number that has to match the sequence number stored inthe ISIM card. This is to prevent replay attacks on the UEs. If the sequence is incorrectthe UE sends a special synchronization failure message with a correct sequence number.
5.7.3 DiameterThe P-CSCF does not know the secret key stored in the ISIM card. This is stored in theHSS and is never sent to other network entities. This design restricts the secret informationas much as possible by only storing the secret key in the ISIM card and in the HSS.
For the P-CSCF to be able to authenticate a registering user, it connects to the I-CSCF. The I-CSCF in turn uses the Diameter protocol originally developed for distributingauthentication information in telephone systems, then calls Radius to get an Authentica-tion Vector (AV) for the P-CSCF.
The AV consists of the random nonce, the expected response, CK, IK, and the AUTHN.The P-CSCF strips the message of all these parameters except for the random nonce andnetwork authenticator, and passes it on to the UE in the challenge response. The CK, IKand the expected response are stored to verify the new attempt to register from the UE.
32 5.7. IMS SECURITY
Kapitel 6
Risk Analysis
Risk analysis is the field of estimating and minimizing the risk for loss of life and moneyto a reasonable level. This field spans over many disciplines of engineering. Even thoughthe methods differ from field to field, the fundamental principles are the same.
6.1 SecureIf a system has the property that it works as expected with an acceptable failure rate it issecure. Within computer science Garfinkel et.al. define it as “A computer is secure if youcan depend on it and its software to behave as you expect.” [17]
This definition says that there is no absolutely secure system, only different degreesof security. When we say that a system is secure we mean that the failure-rate is lowerthan the acceptable. Thus, it is the expectations on how a system should behave that isimportant, not the architecture or requirements.
6.2 Vocabulary OverviewTo discuss the topic of risk analysis, a stringent vocabulary is needed. Common practicefor the field of risk analysis is to use the following terms: asset, threat, threat agent,vulnerability, attack, risk, and countermeasure. They are defined below, and their relationsare shown in figure ??.[5]
6.2.1 AssetThe asset is what has to be protected. It could either be a physical object such as gold,a house or employees or an intellectual asset such as information, money, or secret keys.The definition used by 3GPP is: “Anything that has value to the organization, its businessoperations and its continuity.”[5]
6.2.2 VulnerabilityAgain the 3GPP definition of vulnerability is: “Weakness of an asset or group of assetsthat can be exploited by one or more threats”[5]
33
34 6.2. VOCABULARY OVERVIEW
Figur 6.1: UML diagram for the vocabulary of risk analysis.[5]
6.2.3 Threat3GPP’s definition is: “Potential cause of an incident that may result in harm to a systemor organization.”[5]
Threat AgentA threat agent is the agent that causes a threat. It can be a person, a machine or eventhe environment, e.g. weather phenomena, disasters, etc.
Threat MotiveThe threat agent’s motive to enact a threat in an attack can either be accidental orintentional.
ResultsThe results of an enacted threat.
ProbabilityThreats are ranked according to their probability of occurence. The ranking estimates therelative risk of an attack taking place; the actual probability is most often unknown.
ImpactThe impact of an attack is the other key number of a threat. Without an estimate of howsevere the harm of an attack would be, the threats can not be prioritized. The impact iscommonly assigned a severity or an actual cost is estimated.
6.2.4 AttackThe actual event of a threat being enacted by a threat agent who is trying to exploit avulnerability.
KAPITEL 6. RISK ANALYSIS 35
6.2.5 CountermeasureA countermeasure is a function, an organizational routine or a method used to protectagainst an attack and/or limit its impact.
6.2.6 RiskThe risk is a value of how severe a threat is. It is based on the probability that an attack isenacted and the impact of an attack. This gives important information on how to prioritizethreats. 3GPP defines a risk as the: “Potential that a given threat will exploit vulnerabilitiesof an asset or group of assets and thereby cause harm to the organization.”[5]
A common way to generate the risk factor is to use the formula:
ALE = C · P (6.1)
ALE: Annual Loss Exposure, C: Cost of failure,P : Annual probability of an attack.
When making business decisions regarding security, it is useful to use this formula sinceeach risk is valued as an annual cost. The annual cost can be compared to the cost of thecountermeasures. It is of no use to deploy a countermeasure if the annual cost is higherthan the annual cost of the threat.
Sometimes it is hard or even impossible to estimate the annual probability for howoften a threat will occur or how much an attack will cost. In that case, the probability,impact, and risk are assigned relative numbers ranking the severity. The drawback of thismethod is that it is hard to see if the deployment of certain countermeasures will pay off.
6.3 Peltier’s Ten Step MethodThis method is described in Information Security Risk Analysis [42]1. A short summaryof the method follows, for a more complete description the reader is recommended to readPeltier’s book[42].
6.3.1 Step 1: Develop a Scope StatementThe first step is to develop a scope statement. It is very important that the team un-derstands and agrees on the scope statement. Usually the scope statement starts by iden-tifying the sponsor, e.g. the owner of the analysis.
6.3.2 Step 2: Assemble a Quality TeamTo make the risk analysis efficient the team performing it should consist of experts fromdifferent departments. This ensures a more complete analysis.
It is also important that the team consists of people that can argue freely on the topicwithout restriction due to rank or other management issues.
14.3 Qualitative Risk Assessment Basics, page 79
36 6.3. PELTIER’S TEN STEP METHOD
6.3.3 Step 3: Identify ThreatsThere are two common ways of identifying threats. The first is to brainstorm, either in agroup or everyone by themself, in a structured or unstructured way. The second way is touse a list of possible threats and to choose the ones that apply. The problem with bothof these (and all) methods is that there is no way of knowing if all threats are found or ifthere are some left undiscovered.
Another important aspect is that all of the team members have to agree on the defi-nition of the threats.
6.3.4 Step 4: Prioritize ThreatsAll threats found in the previous step are ranked based on their likelihood of occurring.They are assigned a number between one and five, where five is the most common. Thisis done either in consensus within the team or by calculating the mean of the rankingsassigned by the group members. Members that have low or no knowledge of a threat shouldrefrain from estimating the likelihood of occurrence.
6.3.5 Step 5: Threat ImpactThis is done in much the same way as the previous step. Each threat is assigned a numberreflecting how severe the damage of an occurrence of the threat would be.
6.3.6 Step 6: Risk Factor DeterminationThe risk is a value based on the likelihood of occurrence and the impact of the threat. Therisk value shows the severity of the threat, and is used for prioritizing which threats aremost important to protect against. In the ten step method the probability and the impactare added together to form the risk factor.
6.3.7 Step 7: Identify Safeguards and ControlsIn this step the team will analyze and identify threats with a high risk factor and selecttechnical, administrative, and physical controls that will protect the asset.
There are four categories of control:
• Avoidance – proactive safeguard to avoid or minimize the risk.
• Assurance – safeguard to ensure the effectiveness of other systems.
• Detection – systems to detect and possibly intercept security breaches.
• Recovery – systems and planning to ensuring a quick recovery of a secure environ-ment.
The team should focus on cost effective controls which limit the risk factor to an acceptablelevel and allow the mission of the enterprise to be fulfilled.
KAPITEL 6. RISK ANALYSIS 37
6.3.8 Step 8: Cost-Benefit AnalysisThis is an important step of the risk assessment. Each safeguard should be reviewed andthe cost of implementing it and its effectiveness should be evaluated. To evaluate theeffectiveness of the safeguard in step 6: risk factor determination may be redone in orderto evaluate how much the risk factor will be reduced with the safeguard in place.
6.3.9 Step 9: Rank Safeguards in Recommended OrderThe cost-benefit analysis should be used to rank the safeguards. It order the safeguardsaccording to effectiveness, cost, cost/effectiveness ratio, impact on productivity etc. It isimportant to document the decision on why the list is order in a certain way.
The list with the ranked safeguards is the most important information for the execu-tives when taking decisions on which systems to deploy. The list should be referred to inthe executive summary.
6.3.10 Step 10: Risk Assessment ReportThe result of the risk assessment process must be documented in a report. This reportshould be used as input when taking decisions on the investigated system. The report isalso a historic document showing that a risk assessment has been done.
The report has to include both the details leading to the recommendation and the infor-mation useful to management. The level of understanding can span from expert knowledgeof the system and security to only basic understanding of the topic.
6.4 Threat TreeThreat trees are a structured way of presenting threats. The method does not help tofind threats, but rather structure them and visualizes the inheritance between threats. Acommon notation is shown in figure 6.2. [18]
6.5 Threat Analysis of NGN IMSETSI has done some work in threat and risk analysis for NGN. This work is in progressand only parts of it are applicable on the IPTV subsystem.
The additional systems in an IPTV subsystem in NGN are the RTSP server and theSTB/UE. The interaction between these is the main interest of the upcoming risk analysis.
The NGN security is analyzed in four documents: Methods and performa for Threat,Risk, Vulnerability Analysis[5], Counter Measures[2], NGN Threat and Risk Analysis [4],and NGN Security Requirements [9]. All these documents are recommended as referencebut mostly include standards for documenting security concerns as well as lists of possiblethreats and security requirements.
38 6.5. THREAT ANALYSIS OF NGN IMS
OR
OR
TopThreat
Un- analysedThreats
CompositThreat
BasicThreat Subtree
Cut Away
Countermeasure
BasicThreat
BasicThreat
Figur 6.2: A common notation for threat trees.
Del II
Investigation
39
Kapitel 7
Adapted Risk Analysis Method
To analyze the threats against the system a structured approach, based on the methodsand tools described in previous chapters, is used. This is used in the analysis described inthe next chapter.
7.1 GoalThe goal of the risk analysis is a specification of a system with no implementation deployed.This restricts the analysis to the specification of the system and does not include theimplementation.
Also, the analysis is only targeted against deliberate threats and not against otherthreats like natural disasters, mechanical failures or mishaps, although some of the threatsinvestigated can be enacted unintentionally by a threat agent.
7.2 What is a Risk AnalysisRisk analysis is to find, visualize and understand risks in the analyzed system and to usethese as input in business decisions. These business recommendations try to maximizethe likelihood of proper function of the system within certain business constraints (time,money, human resources, legal demand, etc.) and limit the impact of failure.
7.3 FoundationThe adapted method is based on Peltier’s Ten Step Method1 and threat trees2. The threattrees are used to divide the threats into smaller parts and to deal with the complexity ofthe system. This is an application of the classic “divide and conquer” strategy commonlyused in engineering.
1See section 6.3.22See section 6.4
41
42 7.4. OVERVIEW
Peltier’s Ten Step Method was chosen since my examiner Claudiu Duma recommendedit and was familiar with it. Threat threes where added to help coping with the complexsystem and make the threats and countermeasures easier to understand.
7.4 OverviewBy following Peltier’s Ten Step Method all parts of a risk assessment are covered. Thechange or improvement is that threat trees are extensively used to visualize and structurethe information. In many of the steps information is added to the trees and in the laststeps this information is used to draw conclusions and to base recommendations on.
7.5 Adapted Risk Analysis MethodThe adapted risk analysis method is described below. Most steps are similar to Peltier’smethod and only new information is given for each step, so the reader needs to be familiarwith Peltier’s Ten Step Method.
7.5.1 Step 1: Define the Scope of the AnalysisIn this step the foundation for a good analysis is laid down. The scope of the analysishas to be defined as clearly as possible and presented in such a way that both engineers,management, and others understand and agree on it. It should be kept short and precise.
It is good to start by identifying the sponsor of the analysis. The scope should also beas narrow as possible and only a part of the system should be included in order to reducethe complexity and the time consumed by the analysis.
7.5.2 Step 2: Assemble the Quality TeamThe analysis team should consist of experts from different branches of the company andexperts on different aspects of the investigated system. See Peltier’s Ten Step Method formore information, section 6.3.2.
7.5.3 Step 3: Identify AssetsTo fully understand what the threats, risks and possible safeguards are, we should identifythe assets of the system; what are we trying to protect? Without this information theanalysis may end up recommending safeguards that are unnecessary since they do notprotect anything of value.
7.5.4 Step 4: Identify ThreatsBy using a brain storming session, threats against one or more assets are identified andlisted.
All threats should be linked to at least one asset that they threaten. Threats that donot link to any asset are either incorrect or misunderstood; it is also possible that an assetis missing.
Some of the threats will overlap, this will however be cleared up in the next step.
KAPITEL 7. ADAPTED RISK ANALYSIS METHOD 43
7.5.5 Step 5: Refine Threats Using Threat Trees
To investigate and understand each threat further, it is analyzed by dividing it into bran-ches. This shows which investigated subsystems are threatened, and gives an understandingof which parts could be protected to counter a threat. This also breaks down the problemof estimating the probability and impact for each threat. It might be easier to estimate theprobability and impact for a threat against a specific function than against the completesystem. The notation used in this thesis is shown in figure 7.1.
OR
OR
TopThreat
Un- analysedThreats
CompositeThreat
BasicThreat Subtree
Cut Away
Countermeasure
BasicThreat
BasicThreat
IP 1 1 IP 2 2
IP 3 3
R 1R 2
R 1,2
R 1,2 3 4
R 3R 4
Probability
Impact
Risk
Aggregated Risk
Figur 7.1: Threat tree showing the notation used in this thesis.
7.5.6 Step 6: Assign Probabilities and Impact to Leaves
Each leaf is assigned a probability and an impact factor between one (1) and five (5). Onecorresponds to a low probability or impact and five to a high probability or critical impact.These factors are put into the trees, see figure 7.1.
The estimates of the probability and impact may be easier to do for the leaves thanfor the root of the tree.
44 7.6. PURPOSE
7.5.7 Step 7: Calculate Risk FactorsThe risk factor is aggregated from the probability and the impact. To calculate the riskfactor I have chosen to multiply the probability and impact, because of the following simplereasons; the risk of (0, x) is 0, and increasing one factor will increase the risk factor moreif the second factor is high.
Risk factors should be propagated up through the tree to the root, this gives each nodein the tree a risk factor, which helps to rank the safeguards. The function propagating therisk factor upwards in the tree is of interest. Again there are several functions that can beused.
Simple reasoning is used to decide which function will be used. It is important tounderstand that different functions will produce different risk factors in the tree and havea big impact on how we see the risks. It is therefore important to keep these choices inmind when the trees are reviewed.
The two simple functions of interest are sum and maximum. It is reasonable to sum upall risk factors of the children to a node; the drawback of this is that the aggregated factordepends on the granularity of the tree. This is the main reason to choose the maximumfunction to propagate risks. Both choices have drawbacks, and this has to be understoodby the ones using the information.
7.5.8 Step 8: Identify Safeguards and ControlsIdentify existing and possible safeguards and add them to the tree. This clearly showswhere the safeguard works. This give information on which functions of the system thesafeguard protect.
7.5.9 Step 9: Cost-Benefit AnalysisNo difference to Peltier’s ten step method. The cost is estimated and compared againstthe benefit for each safeguard.
7.5.10 Step 10: Rank Proposed SafeguardsNo difference to Peltier’s ten step method. With the help of the cost-benefit analysis it iseasy to evaluate which safeguards give the most “bang for the buck”.
7.5.11 Step 11: Risk Assessment ReportNo difference to Peltier’s ten step method. The analysis should be documented.
7.6 PurposeThe purpose of a risk assessment is to be able to take better decisions to minimize the risk.These decisions have to be based on facts that are often already known to the company,but the facts have to be gathered, analyzed, and condensed into a recommendation inorder to allow executives to get the important information in an efficient manner.
KAPITEL 7. ADAPTED RISK ANALYSIS METHOD 45
The motive for using the above method is that it structures the problem and abstractsand visualizes the threats. Gathering the essence of the information into figures makes thereport easy to understand and quick to review.
7.7 DiscussionWhy use this method and not any other? There are pros and cons for most methods.Most methods emphasize analyzing a system in design or a system that is deployed. Thisusually means the risk analysis team has more information on threats, probabilities ofthreats, cost and impact of attacks, etc. The problem at hand is also a rather complexsystem with many subsystems that require abstraction. Visualizing the threat gives theanalysis team a better view of the problem, which increases effectiveness.
46 7.7. DISCUSSION
Kapitel 8
Threat Analysis
The questions “Is it secure?” can not be answered without first answering “Secure againstwhat?”. When the threats are understood the analysis can continue and answer the firstquestion.
The threat analysis is made to help answer the first question from section 1.6 “Whichtechnologies can be used for authentication?”. Without knowing the threats, you can notknow what safeguards are needed.
8.1 Method
The threat analysis is done by using Peltier’s 10 Step Method to organize the work. Whenthreats are identified they are broken down into threat trees, according to the adaptedmethod described in chapter 7.
These trees will differ somewhat depending on the authentication technology used andwill give important information on the strengths and weaknesses of the different systems.The full analysis is used for the ISIM card technology and the other technologies arereviewed by evaluating the changes in the threat trees.
8.2 Description of System
The investigated system consist of an STB with an ISIM card, a core IMS (home) networkand a generic application server representing the streaming media server. The core IMSnetwork consists of P-/I-/S-CSCF, UPSF and OCS as the billing system. The AS streamsthe video and set up the RTSP connection. For a overview see figure 8.1. The use caseinvestigated is: A subscriber inserts her ISIM card into an STB in the network and entersher PIN to identify herself as the owner. She chooses a movie to watch and orders it. Thesystem adds the price of the movie to her bill and begins streaming the film to the STB.See the sequence diagram in figure 8.3 and activity diagram in figure 8.2 for the defaultuse case.
47
48 8.3. THREAT ANALYSIS
Figur 8.1: The model of the system used for the risk analysis.
8.2.1 Boundaries of the AnalysisThe risk and security of the media will not be included in the analysis. The analysis willonly concern the signaling used to control the media connection. Further, attackers willonly be considered to have physical access to the STB with the ISIM card and the last linkof the network (the UE to P-CSCF interface, Gm). The rest of the network is physicallysecure, which only allows the attacker to manipulate it on a logical level.
Insiders are not considered; no attackers have legal access to security information suchas keys. Disasters and other rare external events will also not be considered.
Authentication based on a system called Network Attachment Sub-System (NASS)[14]is not investigated since the NASS level of security depends fully on how the network issetup and lower level security mechanisms outside the scope of IMS.
8.3 Threat AnalysisEach step of the threat analysis is presented below. This chapter and chapter 11 are therisk assessment report, in other words the result of the threat analysis.
8.3.1 Step 1: Scope StatementThe scope of the threat analysis is to investigate the billing security for a VoD service inan NGN IMS network using an STB, with focus on the interface towards the STB. Thesponsor of the analysis is Motorola IPTV Open Systems. Motorola both build STB’s andtelecommunication systems, a move towards IMS is of special interest to them.
KAPITEL 8. THREAT ANALYSIS 49
RegisterOrderMovieChargingforServiceMovieStreamStarts
DefaultUseCaseActivityDiagram
Authorization?
NotenoughEnoughWatchMovie
FailedSucceeded
Checkfunds?Permissioncontrol?FailedSucceeded
OrderMovie
Figur 8.2: Activity diagram for the default use case.
For a description of the system and the boundaries of the analysis see section 8.2above.
Security Objectives and Requirements
The security objective of the system is “The system should ensure that only paying (aut-horized) customers access the contents and that customers are only billed for a serviceactually used by them.”
The requirements to achieve the objective above are listed in NGN SECurity (SEC)- Requirements[9]. The document contains long listings of features needed to achieve thelevel of security required in a telecommunications system.
50 8.3. THREAT ANALYSIS
Figur 8.3: Sequence diagram for the default use case. The IMS core networkis simplified to the nodes CSCF and OCS.
8.3.2 Step 2: Assemble a Quality TeamThe special nature of a master thesis limits the quality team to myself with some inputfrom my colleagues, my examiner and the sponsor, Motorola, this is not an ideal qualityteam. More about this in the discussion on the validity of the analysis, see section 11.2.
8.3.3 Step 3: Identify AssetsThe assets of the IPTV system is the information that needs to be protected by the securitysystems:
1. Secret Key2. Traffic Data3. Media4. Accounting Information
Secret KeyThe secret key is used to authorize and authenticate the subscriber. This is vital in orderto be able to trust that the subscriber is the one he claims to be. Authentication is aprerequisite for billing (accounting). Disclosure of a small number of secret keys inflictsloss of income and extra expenses, and a loss of reputation. Loss of secret keys on a bigscale will inflict serous damage on a service provider’s revenue and reputation and canpossibly inflict damage that will bring the company out of business.
Traffic dataTraffic data cannot be disclosed for two reasons. First, the user’s privacy is important,your neighbor should not be able to see which films you watch. Second the aggregate of
KAPITEL 8. THREAT ANALYSIS 51
all traffic data could be regarded as a trade secret. It could give a competitor advantagesif he got hold of it.
Media
The media is the asset that the customer pays to get access to. This is the main asset, allother assets only exists to protect this and to support the business model. The foundationis an exchange of the service of watching a film for money.
If the media leaks it can be spread over the Internet without the authorization ofthe copyright holder. This could lead to lawsuits against service providers, problems withdoing business with movie distributors in the future, and decreased usage of the serviceby the customers.
Accounting information
The ability to charge for a service requires correct information regarding who used whatservice and when. There are three degrees of damage that can be done to the accountinginformation. First it can be disclosed, which is an invasion of privacy for the subscriberand can give away trade secrets to competitors. Second, billing records can be lost, whichinflicts damage on the income of the service provider since they cannot charge for a servicewithout a record of it being used. Third, records can be altered which does the samedamage as loss of records but can also inflict a severe loss of reputation since subscribersdo not like to get a incorrect bill.
Stake Holders
The stake holders are the owners of the information in the system.
1. Content Owners2. The Service Provider3. (Customer)
The customers are not really stake holders even though some personal information can beregarded as theirs. The service provider is concerned about the safety of all assets but thecontent owner, e.g. a movie producer, is only concerned about the security of the media.
8.3.4 Step 4: ThreatsThreats can threaten one or more assets. The threats are found by investigating how eachasset can be abused.
8.3.5 Step 5-8: Refine Threats Using Threat TreesAll five basic threats are refined in threat trees. Probabilities and impacts are assigned tothe leaves, risk factors are calculated and existing safeguards are inserted into the tree.
All these steps are presented together for a compact presentation with all the infor-mation.
The risk factors do not take into account the safeguards in the figure. If a safeguard isapplied the risks above have to be recalculated. In general, it is supposed that a safeguardcompletely removes the branch of threats.
52 8.3. THREAT ANALYSIS
Threat Name AssetT-1 False Authorization Secret KeyT-2 Traffic Snooping Traffic InformationT-3 Unauthorized Media Access MediaT-4 Free Service AccountingT-5 Incorrect Billing Accounting
Tabell 8.1: Basic threats in the IPTV system
8.3.6 False AuthorizationThe leftmost branch contains the unlikely but fatal event of the secret key (K) beingdisclosed. The only high risk threat is that the HSS is hacked. It should be of highest prio-rity for a service provider to protect it from intrusion by proven effective security routinesand systems. The security of the HSS will probably be under constant test by attackers.With proper auditing such attackers can be minimized by proactive countermeasures anddiscouraged of future attacks by investigation and prosecution.
OR
OROR
Distributionof ISIM
credentials
Distributed K
DistributedRES, IK
HackedHSS
MD5algorithmcracked
ISIM cardhacked
FakedP-CSCF
Trojan codeon UE
IPSec integrety
+AKA
AKA authnHardening
the UE
DistributedRES
2 5
10
~0 5
0
1 3
3
3 4
12
4 2
8
10 12 12
12
Figur 8.4: Threat tree for a false authorization.
The rightmost and center branches contain the case where RES is spread. This couldbe read in clear text if encryption is not used. To protect against a man-in-the-middle-
KAPITEL 8. THREAT ANALYSIS 53
attack all communication is signed with IK, this makes it impossible for an attacker tochange the message in transit without the receiver noticing.
If the Gm reference point is completely without IPsec (a possible but not mandatedearly IMS alternative) there is no protection against MiM-attacks. If the IK also is leakeda MiM-attack is also possible. This is somewhat harder since it requires intrusion of theUE, and not only eavesdropping the Gm reference point.
8.3.7 Unauthorized Media AccessThere are three cryptographic countermeasures: AKA, NDS/IP, and encryption of themedia stream. All these should be applied to ensure a safe transport of the media.
OR
OR
Read MediaStream
NDS/IP
ModifiedSDP in Core
Network
UE proxiesthe stream
3 3
9
ModifiedSDP in Gm
2 3
6
Read stream in
path
2 3
6
HardenedUE
PDP/DPF AKA
IPSec IntegrityMedia
EncryptionModified
in NE
Modifiedin Zb
1 4
4
9
4
Figur 8.5: Threat tree for unauthorized media access
The two remaining sub-threats concern the entities. Either the UE proxies the streamto some other destination or the SDP is modified in a core Network Entity (NE).
To protect the stream in the UE two things should be done: hardening of the UE, andproper policy enforcement of its connections. Since all traffic should be setup with SIP,the traffic can be strictly controlled. There are clever ways to bypass such controls, e.g. aUE can set up a video call to pipe the stream through. This will make it show up on thebill which will at least alert the subscriber some time after the abuse, if the subscriber isnot part of the threat-agent.
These systems can also be detected by an IDS but this will never give full protection.For instance, avoidance of detection is always possible by clever hiding of the stream.
54 8.3. THREAT ANALYSIS
8.3.8 Traffic SnoopingTo protect the traffic information from unauthorized reading, it should always be encryp-ted.
Figur 8.6: Threat tree for traffic snooping.
This leaves the only point of attack to a node. The information could be read from ahacked UE or core NE. Deploying strict policy control of traffic , use of IDS, and hardeningthe nodes will protect from traffic snooping.
8.3.9 Free Service AccessIf an attacker can get free access directly to the media without using the authenticationor billing system those system exists in vain. It is a minor threat if proper configurationand testing of the core network is done. Also IDS’s can easily be set up to detect suchattacks. However, failure to test the core setup can leave the system in a vulnerable statewhere an attacker can bypass the AAA system.
8.3.10 Incorrect BillingThis threat breaks down into two branches where one is the threat false authorizationdealt with earlier.
The other sub-threat is that the message to the OCS is altered in transit, which isprotected against by integrity protection of the message with NDS/IP and by hardeningthe core NE’s. This is different from blocking the message to OCS since blocking could bedone even though the integrity of the link is protected, e.g. with a DoS-attack bringingthe OCS out of service.
8.3.11 Step 9: Cost-Benefit AnalysisThe cost-benefit analysis for the threat false authorization, different alternatives of imple-mentations are investigated in chapter 9.
KAPITEL 8. THREAT ANALYSIS 55
Figur 8.7: Threat tree for free access to services.
Figur 8.8: Threat tree for incorrect billing
8.3.12 Step 10: Rank Proposed SafeguardsThe ranking of the proposed safeguards is done in the next chapter, see section 9.7.
8.3.13 Step 11: Risk Assessment ReportThe result of the risk assessment is presented in chapter 8 through 11.
56 8.3. THREAT ANALYSIS
Kapitel 9
Different Authorization Methods
Of the countermeasures listed in section 8 the only one that impacts the STB directly isthe hardening of the STB and the authentication. To analyze the hardening of the STBthe actual implementation has to be scrutinized. On the other hand, the authenticationimplementation can be done using different architectures and realizations. These are ofspecial interest to the sponsor, Motorola.
The different authorization methods only affect the False Authorization threat. Thedifferent methods have different strengths and vulnerabilities when it comes to protectingthe secret key asset, they also have different costs of implementation and deployment thatwill affect the recommendation.
9.1 Hardware ISIMThe hardware solution uses a standard UICC-card with ISIM functionality. The cardsecurely stores the secret key, and returns an answer to a challenge. The UE can neverextract the key. The only way to abuse a UE with a hardware ISIM is to proxy challengesin near real time to use in another UE. This type of abuse can be made hard by hardeningthe UE and using specialized hardware and firmware for the security functions.
Figur 9.1: Hardware ISIM card in the STB.
Advantages
• Clean and easy implementation.• Strongest security
Drawbacks
• Requires the smart card reader in the box. This makes it hard to combine with aproprietary Conditional Access/Digital Rights Management (CA/DRM) system.
57
58 9.2. SOFTWARE ISIM
9.2 Software ISIMThe software ISIM version is similar to a hardware solution but the key is stored in normalflash or ROM memory. This is a big weakness since a penetration can give an intruderthe secret key rendering the AAA system useless until the key has been replaced and thevulnerability removed.
A software solution is allowed in early IMS[3]. This solution should be more restrictedin the server-end than a full hardware ISIM. One option which decreases the loss in caseof breaking of the system is to disallow soft certified UE’s to use services of other networkoperators and to disallow roaming of the device. These restrictions are probably not evennoticed by normal users in an early IMS/IPTV network since this is the way a contem-porary IPTV system works. Furthermore additional lower level authentication methodscan be combined e.g. NASS access-line authentication, where UE’s are identified by whichwire they connect through.
Figur 9.2: Software emulation of an ISIM card.
Advantages
• Clean and easy implementation• No additional hardware required• Fast to deploy• Can be used in combination with a proprietary CA/DRM system
Drawbacks
• Low security• The security depends fully on the system security of the STB.
9.3 Bluetooth Pass-throughA alternative to having an ISIM card in the STB could be to use another device with anISIM card, like a mobile phone. The STB could communicate with the ISIM card in theother UE through bluetooth, The other UE’s credential could be used to authenticate theSTB. This could provide a system with the same security as a hardware ISIM card in thebox.
The design could be done in two different ways: either the box is supplied with thecorrect response from the mobile phone, or the mobile phone sets up a connection, that istunneled over bluetooth onto the IMS network, and proxies all signaling (SIP traffic) backto the box. The second approach has the advantage of not requiring the mobile phone toallow access to the ISIM card from an application. Both solutions depend on the designof the mobile phone. It may be hard or impossible to implement this on certain phones.Certainly it will require different software for different mobile phones.
KAPITEL 9. DIFFERENT AUTHORIZATION METHODS 59
Figur 9.3: Bluetooth pass-through from mobile phone to STB.
Also, this system increases the risk of social engineering attacks and mistakes whenmobile phones are used to authorize and authenticate UE’s without the owner’s knowledgeand/or permission.
It could also require weakening security policies since the control and media destina-tions are different in the UE end.
Advantages
• Nearly the same security as a hardware ISIM.• Can be used in combination with a proprietary CA/DRM system.
Drawbacks
• Different applications for different mobile phones have to be implemented. Somemobile phone may not be possible to use at all.
• Requires additional devices, an IMS-compliant mobile phone and a bluetooth dong-le.
• Slow to develop• Mobile phone owners risk getting their subscription abused.
9.4 Billing Through Another UEBy using another UE connecting to an AS, the UE can be used to authorize and authen-ticate the service to a certain STB. This requires a secure communication from the AS tothe STB. The advantage of this is that it could be done with a integration of the alreadyexisting proprietary CA/DRM system. This has several drawbacks. One is that the de-velopment has to be done in cooperation with the company that provides the CA/DRMsystem. Another drawback is that it does not really integrate IPTV in an IMS network,but just combines it and uses its facilities for billing.
Figur 9.4: Billing trough another UE.
60 9.5. IRG – IMS RESIDENTIAL GATEWAY
Advantages
• Billing is done with well defined IMS security functions.• Can be used in combination with a proprietary CA/DRM system.
Drawbacks
• Requires another UE in an IMS network• Only handles billing. STB security has to be solved in another way, e.g. NASS with
access-line authentication.
9.5 IRG – IMS Residential GatewayIRG[10] is a gateway device similar to a home wireless Internet router with an additionalUICC-card reader and functions for bridging SIP to IMS. The gateway connects to thehome network and allows SIP-enabled devices such as SIP-phones to connect to IMSthrough the gateway. The IRG handles all AAA with its ISIM card and adapts the signalingto IMS.
Figur 9.5: IMS Residential Gateway – IRG
Advantages
• High level of security from IRG to IMS.• Can be used in combination with a proprietary CA/DRM system.
Drawbacks
• Requires additional hardware• Does not necessarily protect against malicious users.• Home network is vulnerable in case of low security or misconfiguration, especially
in combination with wireless access technologies like WLAN.
9.6 Secure ProcessorInstead of an ISIM card a secure processor can be used. It has special instructions tohandle keys and encryption. It would provide the same level of security as an ISIM card,except for the fact that the user cannot remove his credentials.
Advantages
• Strong security
Drawbacks
• Requires hardware support.• Does not comply with full IMS specifications.
KAPITEL 9. DIFFERENT AUTHORIZATION METHODS 61
Figur 9.6: Secure Processor
9.7 Step 10: Rank Proposed SafeguardsThe priority is based on estimated cost of development, strength, possibilities for longterm use, and appliance to standards. The recommendation is (with the highest priorityfirst):
1. Hardware ISIM2. Secure Processor3. Software ISIM
Other authorization methods are not recommended.
9.7.1 Hardware ISIMHardware ISIM and the IRG system are the only ones mandated by the specificationfor an NGN network. This employs the full strength of IMS AAA and only requires ashort development since most critical security functions reside in the ISIM card. The onlydrawback is the use of the smart card interface on the STB which makes it complicatedto coexist with a proprietary CA/DRM system.
9.7.2 Secure ProcessorThe system with a secure processor could have the same strength as the hardware ISIMcard solution if properly implemented. It shifts the authentication of something you havefrom a UICC card to an STB. The drawback is that it makes it harder to change subscrip-tion from one provider to another. This solution is not mandated in the standard IMSspecifications[9] but could be deployed in an early IMS scenario according to Security ofearly IMS [3].
9.7.3 Software ISIMSoftware ISIM is not mandated in the standard IMS specifications[9] but could be deployedin an early IMS scenario according to Security of early IMS [3].
The security of this system is weaker than the two previous recommended systems,since the secret key is stored in memory, allowing the key to be copied.
The main advantage of this solution is that it can coexist with a proprietary CA/DRM-system, that it does not require any special hardware, and that it is really fast to imple-ment.
It could be the first choice for test beds and small trial systems with just a few serviceproviders which share the risk of a failing AAA system.
62 9.7. STEP 10: RANK PROPOSED SAFEGUARDS
Kapitel 10
Gaps in IMS – IPTV Integration
The second question in section 1.6 : Are there any security gaps in merging IPTV andIMS? will be covered in this chapter. During the course of investigating an IMS/IPTVnetwork, one area with weak security was found, the incorporation of the RTSP for controlof the VoD stream is not yet specified and lacks protection.
10.0.4 SIP – RTSP HandoverSIP is used to initiate and setup the media-stream, but to control the playback with: play,pause, forward, etc. RTSP is required. This can be specified in the SDP of the SIP-medianegotiation with a control attribute for the connection, e.g. a=control:rtsp://vod.ims.com/classic/dr_strangelove.avi.
ThreatsRTSP is sent in clear text. The session can be eavesdropped and malicious messages canbe inserted. There is no TLS extension to RTSP, the only security feature is to use HTTPdigest for access control which does not protect the confidentiality of the traffic.
CountermeasuresA session-id in the origin-line could be used to link the RTSP session with the SIP/SDP-negotiation; this protects against an attacker that cannot read or guess the session id frominserting faked messages.
The RTSP server should strictly check the parameters to ensure that the parameterssetup by the secure SIP/SDP connection are used.
Since RTSP is a clear-text-only protocol, IPsec should be used for the connection.The problem is to setup this IPsec connection in a standard and secure way. This or anysimilar scenario is not covered in any of the IMS documents.
There is one short term solution and one long term solution on how to setup the RTSPconnection on an IPsec Secure Association.
The short term solution is to use the SDP key attribute (k=) to convey an IPsec key,for a predefined algorithm and key size. The use of this mechanism is not recommendedin the specification for SDP[37].
The short term solution is not recommended since a more advanced and flexible keyagreement system is suggested in Key Management Extension for SDP and RTSP [38]
63
64
C−→S SIP INVITE [email protected];\play=rtsp://vod.rices-ims.test/action/heat.mp4
S−→C SIP 200 OK with SDPv=0o=alice 432784123 23413131 IN IP4 128.3.2.1s=c=IN IP4 128.3.2.1a=control:rtsp://vod.rices-ims.test/action/heat.mp4t=m=video 4004 RTP/AVP 14a=rtpmap:14 MPA/90000a=recvonly
C−→S SIP ACKC−→S RTSP SETUP rtsp://vod.rices-ims.test/action/heat.mp4 RTSP/1.0
CSeq: 302Session:432784123Transport: RTP/AVP;unicast;client_port=4004
S−→C RTSP RTSP/1.0 200 OKCSeq: 302Date: 23 Jan 1997 15:35:06 GMTSession:432784123Transport: RTP/AVP;unicast;\client_port=4004;server_port=3986
Tabell 10.1: Example of SIP and RTSP setup of video session
KAPITEL 10. GAPS IN IMS – IPTV INTEGRATION 65
Figur 10.1: IMS/IPTV control channels for VoD.
which uses MIKEY[33] to negotiate security parameters and convey keys. However, thisRFC currently only supports key management for Secure Real-Time Protocol (SRTP). Anew proposal for an RFC describing an extension for IPsec must be produced and approvedbefore this solution can be used in. That extension would provide a solution where the ASand the STB can negotiate the type of encryption and parameters for the RTSP.
66
Del III
Conclusions
67
Kapitel 11
Conclusions
To answer the original questions for this thesis: Is it possible to, in a secure way, use anSTB to connect to an IMS system and order VoD services? The question was broken downinto two more narrow questions:
1. Which technologies can be used for authentication?
2. Are there any security gaps in converging IMS and IPTV?
The first question is answered in section 11.1.2 and the second in 11.1.4, but first somegeneral conclusions on IMS security deserve to be mentioned.
11.1 RecommendationsThe following recommendations are important input for business decisions concerningIPTV/IMS development and deployment.
11.1.1 General IMS SecurityIMS offers solid AAA functions. These functions offers a high level of security if usedproperly. The system use open and well-known protocols that have been designed andscrutinized by many experts.
Using these standards ensures early detection and response to weaknesses in the systemdesign. Also, security is not provided by obscurity.
11.1.2 STB/UEThe STB is a likely target of attacks. Using IPsec with encryption for all signaling willprotect contents and stop man-in-the-middle attacks.
A secure ISIM card should be used, if it is broken the user must change it immediatelysince everyone who has the secret can use the users account.
69
70 11.2. DISCUSSION
Authentication
Authentication can in early scenarios be done by software emulation of an ISIM module.This will however not be acceptable in the long term[3][9].
In a long term high security scenario there are two options: to use an ISIM cardor to use a secure processor with special functions for CA. The ISIM card is the onlyoption approved by the specifications, but a secure processor could provide the samelevel of security. The drawback of the ISIM card is that it is not easily combined witha proprietary CA/DRM system. The drawback of the secure processor is that it is muchmore cumbersome to handle key changes and move STB’s between customers.
11.1.3 Core NetworkThe core network should be protected with NDS/IP to protect from false or altered mes-sages in the network. This can be set up at a low cost and it introduces a mechanism thatis hard to circumvent without hacking the core network entities.
The network should be restricted as much as possible. Especially stand-alone networksonly used for IPTV should not deploy any IMS functions that are unnecessary.
The HSS must be well protected since it holds all secret keys. If it is breached theAAA is worthless until the vulnerability is fixed and all exposed keys are revoked andreplaced.
11.1.4 Gaps in IMS – IPTV IntegrationThe NGN IMS IPTV subsystem is just in draft stadium and most functions are notspecified at all. This requires careful specification, evaluation, and implementation beforeany final conclusion can be drawn.
One problem is the lack of security for the RTSP control of the VoD stream, whichcould offer an opportunity for an attacker to do damage. This weakness has to be addressedby future IMS standards.
11.1.5 RTSP SecuritySpecial care has to be taken regarding the use of RTSP and media encryption. RTSP hasto be used over an encrypted tunnel to be secure. The media encryption has some supportbut only for media transferred in SRTP which may not be the transport of choice for anIPTV system.
The suggested solution is to extend the RFC “Key Management Extensions for SDPand RTSP”[38] by a new RFC, managing key exchange and negotiation for IPsec over SDPor RTSP. Since IMS has a secure connection over SIP it could be used to deliver sessionkeys to setup IPsec connections for other protocols, such as RTSP.
This is a general solution that could be used to solve other similar problems of provi-ding a secure connection between the IMS core and the UE for any type of protocol.
11.2 DiscussionThe thesis report has used the specifications of IMS and a structured approach to evaluatethe security provided by it if IPTV is merged into IMS. The thesis does not go into protocol
KAPITEL 11. CONCLUSIONS 71
details to argue for or against the security provided by these protocols. The conclusionsare largely based on the assumptions that the security protocols are well designed and thealgorithms are secure. The level of detail is heavily influenced by the original question andan industry perspective.
Since this is a prestudy of a system that has not yet been developed it does not analyzedetails of an implementation or configuration of a deployed system.
The cooperation with Motorola and Attentec has put the focus on analyzing the systemand not on evaluating and investigating the methods.
11.3 ValidityThe validity of the thesis can be argued, since it uses a small quality team for the evalua-tion. However, this thesis could serve as a starting point for further and deeper evaluation.
72 11.3. VALIDITY
Kapitel 12
Further Studies
The area of IMS is new and uncharted. There are a lot of opportunities for new features,services and technologies to analyze, implement and scrutinize. I will try to name a fewthat are connected with the topic and results of this thesis.
12.1 SecuritySecurity can and should be analyzed both at large, i.e. system level, and in detail, onprotocol level. Testing of security in real IMS system is of course an important topicto conclude how feasible it is to implement a secure IMS system. This work could beaccompanied by studies on how to detect breaches and abuse. Also, guidelines on setupand configuration of IMS systems have to be provided and analyzed.
One issues to study further could be VoD security, since it lacks some protection. Thiscould possibly influence the standardization work of the IPTV subsystem in IMS. Also,to ensure secure UE’s, investigations have to be done how to harden the box by varioustechniques, e.g. containment restrictions of code, network security etc.
73
74 12.1. SECURITY
Litteraturförteckning
[1] 3rd generation partnership project, the. http://www.3gpp.org/.
[2] 3GPP. TS 102.165-2 - Methods and protocols - Counter Measures, 2003. Version4.1.1.
[3] 3GPP. TR 133.978 - 3G security - Security of early IMS, 2006. Version 6.6.0.
[4] 3GPP. TR 187.002 - NGN Security - Threat and Risk Analysis, 2006. Version 1.1.1.
[5] 3GPP. TS 102.165-1 - Methods and protocols - Methods and performa for Threat,Risk, Vulnerability Analysis, 2006. Version 4.2.1.
[6] 3GPP. TS 133.102 - 3G security - Security architecture, 2006. Version 7.1.0.
[7] 3GPP. TS 133.203 - 3G security - Access security for IP-based services, 2006. Version7.4.0.
[8] 3GPP. TS 133.210 - 3G security - Network Domain Security (NDS), 2006. Version7.2.0.
[9] 3GPP. TS 187.001 - NGN SECurity (SEC) - Requirements, 2006. Version 1.1.1.
[10] 3GPP. TS 187.003 - NGN Security - Security Architecture, 2006. Version 1.1.1.
[11] 3GPP. TS 31.103 - Characteristics of the IP Multimedia Services Identity Module(ISIM) application, 2006. Version 7.1.0.
[12] Matt Bishop. Computer Security: Art and Science. Addison-Wesley Professional,2002.
[13] China Daily. Ericsson increases lead on telco gear market. http://www.chinadaily.com.cn/bizchina/2009-02/27/content_7521675.htm.
[14] ETSI. ES 282.004 - Network Attachment Sub-System (NASS), 2006. Version 1.1.1.
[15] G. Fairhurst. Internet over mpeg-2 transmission networks. International Journal ofComputer and Telecommunications Networking, 48(1):5–20, 2003.
[16] Behrouz A. Forouzan. TCP/IP Protocol Suite. McGraw-Hill, third edition, 2006.
75
76 LITTERATURFÖRTECKNING
[17] Simson Garfinkel, Gene Spafford, and Alan Schwartz. Practical UNIX & InternetSecurity. O’Reilly, third edition, 2003.
[18] Michael Howard and David LeBlanc. Writing Secure Code. Microsoft Press, secondedition, 2003.
[19] Internet engineering task force, the. http://www.ietf.org/.
[20] IETF. RFC 768 - User Datagram Protocol (UDP). J. Postel, 1980.
[21] IETF. RFC 2326 - Real Time Streaming Protocol (RTSP). H. Schulzrinne et.al.,1998.
[22] IETF. RFC 2616 - Hypertext Transfer Protocol – HTTP/1.1. R. Fielding et.al., 1999.
[23] IETF. RFC 2627 - HTTP Authentication: Basic and Digest Access Authentication.J. Franks et.al., 1999.
[24] IETF. RFC 2782 - A DNS RR for specifying the location of services (DNS SRV). A.Gulbrandsen et.al., 2000.
[25] IETF. RFC 2976 - The SIP INFO Method. S. Donovan, 2000.
[26] IETF. RFC 2821 - Simple Mail Transfer Protocol. J. Klensin, Ed., 2001.
[27] IETF. RFC 3261 - Session Initiation Protocol (SIP). J. Rosenberg et.al., 2002.
[28] IETF. RFC 3262 - Reliability of Provisional Responses in the Session InitiationProtocol (SIP). J. Rosenberg and H. Schulzrinne, 2002.
[29] IETF. RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification. A.B. Roach, 2002.
[30] IETF. RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging.B. Campbell et.al., 2002.
[31] IETF. RFC 3515 - The Session Initiation Protocol (SIP) Refer Method. R. Sparks,2003.
[32] IETF. RFC 3550 - RTP: A Transport Protocol for Real-Time Applications. H.Schulzrinne et.al., 2003.
[33] IETF. RFC 3830 - MIKEY: Multimedia Internet KEYing. J. Arkko and E. Carraraet.al., August 2004.
[34] IETF. RFC 4240 - SIP Media Services. E. Burger, Ed. .et.al, 2005.
[35] IETF. RFC 4301 - Security Architecture for the Internet Protocol. S. Kent and K.Seo, 2005.
[36] IETF. RFC 4346 - The Transport Layer Security (TLS) Protocol Version 1.1. T.Dierks, E. Rescorla, 2006.
LITTERATURFÖRTECKNING 77
[37] IETF. RFC 4566 - Session Description Protocol (SDP). M. Handley et.al., 2006.
[38] IETF. RFC 4567 - Key Management Extensions for Session Description Protocol(SDP) and Real Time Streaming Protocol (RTSP). J. Arkko and F. Lindholm, et.al.,July 2006.
[39] ISO/IEC. ISO/IEC 7816: Identification cards – Integrated circuit(s) cards with con-tacts, 1 edition, 11 2003. Stage 90.93.
[40] ISO/IEC. ISO 13818: Information technology – Generic coding of moving picturesand associated audio information: Systems (MPEG v2), 11 2005. Stage 90.92.
[41] ISO/IEC. ISO/IEC 7810: Identification cards – Physical characteristics, 3 edition,12 2005. Stage 90.93.
[42] Thomas R. Peltier. Information Security Risk Analysis. CRC Press, second edition,2005.
[43] Ericsson Media Relations. Press release: Ericsson ceo says ims is the next stepfollowing the successful rollout of 3g. http://www.ericsson.com/ericsson/press/releases/20060213-1034297.shtml.
[44] Henry Sinnreich and Allan B. Johnston. Internet Communications Using SIP. Wiley,first edition, 2001.
[45] Loring Wirbel. For carriers, iptv poses new challenges. For carriers, IPTV posesnew challenges, Electric Engineering Times, online 2006-08-16, August 2006. http://www.eetasia.com/ART_8800429812_1034362_4e2b0270200608_no.HTM.
78 LITTERATURFÖRTECKNING