1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationPD CEN/TS 16439:2013Electronic fee collection Security frameworkCopyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproducti
2、on or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013 PUBLISHED DOCUMENTNational forewordThis Published Document is the UK implementation ofCEN/TS 16439:2013.The UK participation in its preparation was entrusted to TechnicalCommittee EPL/278, Road transport informatics.A list
3、of organizations represented on this committee can beobtained on request to its secretary.This publication does not purport to include all the necessaryprovisions of a contract. Users are responsible for its correctapplication. The British Standards Institution 2013.Published by BSI Standards Limite
4、d 2013 ISBN 978 0 580 78694 5 ICS 35.240.60 Compliance with a British Standard cannot confer immunity fromlegal obligations.This Published Document was published under the authority of theStandards Policy and Strategy Committee on 28 February 2013. Amendments issued since publicationDate T e x t a f
5、 f e c t e dCopyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN/TS 16439 January 2013
6、ICS 35.240.60 English Version Electronic fee collection - Security framework Perception de tlpage - Cadre de scurit Elektronische Gebhrenerhebung - Sicherheitsgrundstruktur This Technical Specification (CEN/TS) was approved by CEN on 27 August 2012 for provisional application. The period of validity
7、 of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard. CEN members are required to announce the existence of this CEN/TS in the same
8、 way as for an EN and to make the CEN/TS available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached. CEN members
9、are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
10、Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre: Avenue Marnix 17, B-1000 Brussels 2013 CEN All rights of exploitation in any form and by any mea
11、ns reserved worldwide for CEN national Members. Ref. No. CEN/TS 16439:2013: ECopyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013CEN/TS 16439:2013 (E) 2 Contents
12、Page Foreword . 6 0 Introduction 7 0.1 Readers guide . 7 0.2 EFC role model . 8 0.3 Relation to other security standards . 9 1 Scope 11 1.1 EFC specific scope 11 1.2 Scope in relation to other security frameworks 14 2 Normative references . 15 3 Terms and definitions 16 4 Symbols and abbreviations .
13、 22 5 Trust model 24 5.1 Introduction 24 5.2 Stakeholders trust relations 24 5.3 Technical trust model 25 5.3.1 General . 25 5.3.2 Trust model for TC and TSP relations . 25 5.3.3 Trust model for TSP and User relations 27 5.3.4 Trust model for Interoperability Management relations . 27 5.4 Implementa
14、tion . 27 5.4.1 Setup of trust relations 27 5.4.2 Trust relation renewing and revocation 27 5.4.3 Issuing and revocation of sub CA and entity certificates 28 5.4.4 Certificate and Certificate Revocation List profile and format . 28 5.4.5 Certificate extensions 28 6 Security requirements 29 6.1 Intro
15、duction 29 6.2 Information Security Management System . 29 6.3 Communication interfaces . 30 6.3.1 General . 30 6.3.2 Generic interface requirements . 31 6.3.3 DSRC profile . 31 6.3.4 TC to TSP profile 32 6.3.5 Communication provider profile 32 6.4 Data storages . 33 6.4.1 General . 33 6.4.2 OBE dat
16、a storages . 33 6.4.3 RSE data storages 33 6.4.4 Back End data storage . 34 6.5 Toll Charger 34 6.6 Toll Service Provider 35 6.7 User. 37 6.8 Interoperability Management . 38 6.9 Limitation of requirements 38 7 Security measures - countermeasures . 38 7.1 Introduction 38 7.2 General security measure
17、s 39 7.3 Communication interfaces security measures . 39 Copyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013CEN/TS 16439:2013 (E) 3 7.3.1 General . 39 7.3.2 DSRC
18、-EFC interface . 39 7.3.3 CCC interface . 40 7.3.4 LAC interface 40 7.3.5 Front End to TSP Back End interface 41 7.3.6 TC to TSP interface 41 7.4 End-to-end security measures . 41 7.5 Toll Service Provider security measures 43 7.5.1 Front End security measures. 43 7.5.2 Back End security measures .
19、43 7.6 Toll Charger security measures. 44 7.6.1 RSE security measures 44 7.6.2 Back End security measures . 44 7.6.3 Other TC security measures 44 8 Security specifications for interoperable interface implementation 45 8.1 General . 45 8.1.1 Subject 45 8.1.2 Signature and hash algorithms . 45 8.1.3
20、MAC algorithm 45 8.1.4 MAC key derivation 46 8.1.5 Key encryption algorithm. 46 8.1.6 Padding algorithm 46 8.2 Security specifications for DSRC-EFC 46 8.2.1 Subject 46 8.2.2 OBE . 46 8.2.3 RSE . 47 8.3 Security specifications for CCC. 47 8.3.1 Subject 47 8.3.2 OBE . 47 8.3.3 RSE . 47 8.4 Security sp
21、ecifications for LAC . 47 8.4.1 Subject 47 8.4.2 OBE . 47 8.4.3 RSE . 47 8.5 Security specifications for Front End to TSP interface 48 8.5.1 General . 48 8.5.2 ChargeReport message authentication . 48 8.6 Security specifications for TC to TSP interface 49 8.6.1 General . 49 8.6.2 Secure communicatio
22、n channel 49 8.6.3 Message authentication . 49 8.6.4 Proof of message delivery . 51 8.6.5 TSP ChargeReport authentication . 51 9 Key management 52 9.1 Introduction 52 9.2 Asymmetric keys 52 9.2.1 Key exchange between stakeholders 52 9.2.2 Key generation and certification 52 9.2.3 Protection of Keys
23、53 9.2.4 Application 53 9.3 Symmetric keys 53 9.3.1 Introduction 53 9.3.2 Key exchange between stakeholders 53 9.3.3 Key lifecycle . 54 9.3.4 Key storage and protection . 56 9.3.5 Session keys 57 Annex A (normative) Data type specification. 58 Annex B (normative) Implementation Conformance Statement
24、 (ICS) proforma 62 Copyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013CEN/TS 16439:2013 (E) 4 B.1 Guidance for completing the ICS proforma 62 B.1.1 Purposes and
25、structure . 62 B.1.2 Abbreviations and conventions. 62 B.1.3 Instructions for completing the ICS proforma 64 B.2 Identification of the implementation 64 B.2.1 General . 64 B.2.2 Date of the statement . 64 B.2.3 Implementation Under Test (IUT) identification 64 B.2.4 System Under Test (SUT) identific
26、ation 65 B.2.5 Product supplier . 65 B.2.6 Applicant (if different from product supplier) . 66 B.2.7 ICS contact person . 66 B.3 Identification of the standard . 67 B.4 Global statement of conformance . 67 B.5 Roles . 67 B.6 Trust Model functionalities 67 B.7 Profiles . 68 B.8 Requirements . 68 B.9
27、Security measures . 71 B.10 Specifications for interoperable interfaces security 74 Annex C (informative) Stakeholder objectives and generic requirements . 76 C.1 Introduction 76 C.2 Toll Chargers 77 C.2.1 Toll chargers and their main interests 77 C.2.2 Security service requirements for a Toll Charg
28、er . 77 C.3 Toll Service Providers 78 C.3.1 Toll service providers and their main interests 78 C.3.2 Security service requirements for a Toll Service Provider . 78 C.4 Users . 79 C.4.1 Users and their main interests 79 C.4.2 Users requirements 79 C.5 Interoperability Management . 79 C.5.1 Interopera
29、bility management and its main interests 79 C.5.2 Security service requirements for interoperability management . 80 Annex D (informative) Threat analysis . 81 D.1 General introduction 81 D.2 Attack trees based threat analysis 81 D.2.1 Introduction 81 D.2.2 System model . 82 D.2.3 Presentation of at
30、tack trees . 83 D.2.4 Attacker class 1: User 84 D.2.5 Attacker class 2: Toll Service Provider . 86 D.2.6 Attacker class 3: Toll Charger . 89 D.2.7 Attacker class 4: Hacker 91 D.2.8 Attacker class 5: Activist . 94 D.2.9 Attacker class 6: Communication provider . 95 D.2.10 Attacker class 7: Enterprise
31、 96 D.2.11 Attacker class 8: Government . 99 D.2.12 Attacker class 9: Foreign power 101 D.3 Asset based threat analysis 102 D.3.1 General . 102 D.3.2 Threatened Assets . 102 D.3.3 Compliance matrix . 104 D.3.4 Presentation of threats 106 D.3.5 Generic threats . 107 D.3.6 Asset: Billing details 109 D
32、.3.7 Asset: OBE Charge Report 110 D.3.8 Asset: Customisation information 111 D.3.9 Asset: User contract information 111 Copyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS
33、16439:2013CEN/TS 16439:2013 (E) 5 D.3.10 Asset: Exception List . 112 D.3.11 Asset: “Help, info, complain“. 112 D.3.12 Asset: OBE . 113 D.3.13 Asset: User privacy 115 D.3.14 Asset: RSE 115 D.3.15 Asset: EFC stakeholders image and reputation . 116 D.3.16 Asset: TC and TSP central system 117 D.3.17 Ass
34、et: Transit information . 117 D.3.18 Asset: Trust object . 118 D.3.19 Asset: User identification. 120 D.3.20 Asset: Context Data . 120 D.3.21 Asset: Payment means 121 D.3.22 Asset: Limited autonomy . 122 D.3.23 Asset: EFC Schema 122 D.3.24 Asset: Contractual conditions . 123 D.3.25 Asset: Operationa
35、l rules 124 D.3.26 Asset: Complaint 125 D.3.27 Asset: Certification . 127 D.3.28 Asset: Operational report. 128 Annex E (informative) Security Policies . 129 E.1 Introduction 129 E.1.1 Scope of the annex . 129 E.1.2 Motivation for the need of security policies 129 E.2 Example EFC scheme security pol
36、icy . 129 E.2.1 Motivation for information security . 129 E.2.2 Purpose of the security policy . 130 E.2.3 Scope 130 E.2.4 Policy statements . 132 E.3 Development of operators security policies . 134 E.3.1 General . 134 E.3.2 Interface requirements . 135 E.3.3 Data storage requirements 135 Annex F (
37、informative) Example for an EETS Security Policy 136 F.1 Introduction 136 F.2 Basic laws and regulations 136 F.3 Organisation of EETS Information Security 136 F.3.1 General . 136 F.3.2 Steering Committee 136 F.3.3 Trust Model . 136 Annex G (informative) Requirements on privacy-focused implementation
38、 138 G.1 Introduction 138 G.2 Legal basis . 138 G.2.1 EU Directive 95/46/EC. 138 G.2.2 European data protection supervisor (EDPS) . 138 G.3 Users requirements . 139 Bibliography 140 Copyright European Committee for Standardization Provided by IHS under license with CENNot for ResaleNo reproduction o
39、r networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013CEN/TS 16439:2013 (E) 6 Foreword This document (CEN/TS 16439:2013) has been prepared by Technical Committee CEN/TC 278 “Road transport and traffic telematics”, the secretariat of which is held by NEN. Attention is drawn to the p
40、ossibility that some of the elements of this document may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Tra
41、de Association. According to the CEN/CENELEC Internal Regulations, the national standards organisations of the following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of M
42、acedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. Copyright European Committee for Standardization Provided by IHS u
43、nder license with CENNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PD CEN/TS 16439:2013CEN/TS 16439:2013 (E) 7 0 Introduction 0.1 Readers guide The development process for the security concept and implementation to protect an existing system normally includes sev
44、eral steps as follows: threat analysis with risk assessment, security policy definition, requirements and countermeasures definition followed by the implementation of countermeasures and supervising of their effectiveness. Countermeasures which do not work or work incorrectly need to be improved. Th
45、e development of the Electronic Fee Collection (EFC) - Security Framework follows this approach as closely as possible, although there is no existing system to analyse. The used methodology needs to consider following limitations: No risk assessment possible: The risk assessment compares the possibl
46、e loss for the stakeholder and the required resources (e.g. equipment, knowledge, time, etc.) to perform an attack. It is the trade-off evaluation of the cost and benefit of each countermeasure which is only possible for an existing system. No security policy exists. The security policy can only be
47、defined by the responsible stakeholder and its freedom is only limited by laws and regulations. Nonetheless, basic but incomplete examples of possible security policies can be provided. No specific system design or configuration exists to be based on. Only the available EFC base standards can be tak
48、en as references. Specific technical details of a particular system (e.g. servers, computer centres, de-central elements like road side equipment) need to be taken into consideration in addition to the present security framework. The selection of requirements and the respective security measures for
49、 an existing EFC system is based on the security policy and the risk assessment of the several stakeholders for their system parts. Due to the fact that there is neither an overall valid security policy, nor that the possibility to provide a useful risk assessment exists, the EFC security framework provides a toolbox of requirements and s
