EN ISO TS 19299-2015 en Electronic fee collection - Security framework.pdf

《EN ISO TS 19299-2015 en Electronic fee collection - Security framework.pdf》由会员分享，可在线阅读，更多相关《EN ISO TS 19299-2015 en Electronic fee collection - Security framework.pdf（154页珍藏版）》请在麦多课文档分享上搜索。

1、BSI Standards PublicationElectronic fee collection Security frameworkPD CEN ISO/TS 19299:2015National forewordThis Published Document is the UK implementation of CEN ISO/TS19299:2015. It supersedes PD CEN/TS 16439:2013 which is withdrawn.The UK participation in its preparation was entrusted to Techn

2、icalCommittee EPL/278, Intelligent transport systems.A list of organizations represented on this committee can be obtained onrequest to its secretary.This publication does not purport to include all the necessary provisions ofa contract. Users are responsible for its correct application. The British

3、 Standards Institution 2015.Published by BSI Standards Limited 2015ISBN 978 0 580 87862 6ICS 03.220.20; 35.240.60Compliance with a British Standard cannot confer immunity fromlegal obligations.This Published Document was published under the authority of theStandards Policy and Strategy Committee on

4、31 October 2015.Amendments/corrigenda issued since publicationDate Text affectedPUBLISHED DOCUMENTPD CEN ISO/TS 19299:2015TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN ISO/TS 19299 October 2015 ICS 35.240.60; 03.220.20 Supersedes CEN/TS 16439:2013English Version Electro

5、nic fee collection - Security framework (ISO/TS 19299:2015) Perception de tlpage - Cadre de scurit (ISO/TS 19299:2015) Elektronische Gebhrenerhebung - Sicherheitsgrundstruktur (ISO/TS 19299:2015) This Technical Specification (CEN/TS) was approved by CEN on 26 June 2015 for provisional application. T

6、he period of validity 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 th

7、is CEN/TS in the same 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

8、reached. CEN members 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, Norwa

9、y, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey andUnited Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels 2015 CEN All rights of exploit

10、ation in any form and by any means reserved worldwide for CEN national Members. Ref. No. CEN ISO/TS 19299:2015 EPD CEN ISO/TS 19299:2015CEN ISO/TS 19299:2015 (E) 2 Contents Page European foreword . 3 PD CEN ISO/TS 19299:2015CEN ISO/TS 19299:2015 (E) 3 European foreword This document (CEN ISO/TS 1929

11、9:2015) has been prepared by Technical Committee ISO/TC 204 “Intelligent transport systems“ in collaboration with Technical Committee CEN/TC 278 “Intelligent transport systems” the secretariat of which is held by NEN. Attention is drawn to the possibility that some of the elements of this document m

12、ay 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 supersedes CEN/TS 16439:2013. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Associat

13、ion. According to the CEN-CENELEC Internal Regulations, the national standards organizations 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 Macedonia, F

14、rance, 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. Endorsement notice The text of ISO/TS 19299:2015 has been approved by CEN as

15、CEN ISO/TS 19299:2015 without any modification. PD CEN ISO/TS 19299:2015ISO/TS 19299:2015(E)Foreword vIntroduction vi1 Scope . 12 Normative references 23 Terms and definitions . 44 Symbols and abbreviated terms . 95 Trust model .105.1 Overview . 105.2 Stakeholders trust relations . 105.3 Technical t

16、rust model . 115.3.1 General. 115.3.2 Trust model for TC and TSP relations .115.3.3 Trust model for TSP and service user relations .135.3.4 Trust model for Interoperability Management relations .135.4 Implementation . 135.4.1 Setup of trust relations 135.4.2 Trust relation renewal and revocation 145

17、.4.3 Issuing and revocation of sub CA and end-entity certificates 145.4.4 Certificate and certificate revocation list profile and format .155.4.5 Certificate extensions .156 Security requirements .176.1 General 176.2 Information security management system 186.3 Communication interfaces . 186.4 Data

18、storage 196.5 Toll charger . 196.6 Toll service provider . 216.7 Interoperability Management . 236.8 Limitation of requirements . 237 Security measures countermeasures .247.1 Overview . 247.2 General security measures 247.3 Communication interfaces security measures .257.3.1 General. 257.3.2 DSRC-EF

19、C interface .267.3.3 CCC interface 277.3.4 LAC interface 287.3.5 Front End to TSP back end interface .287.3.6 TC to TSP interface 297.3.7 ICC interface 307.4 End-to-end security measures . 307.5 Toll service provider security measures 327.5.1 Front end security measures 327.5.2 Back end security mea

20、sures . 337.6 Toll charger security measures 347.6.1 RSE security measures .347.6.2 Back end security measures . 347.6.3 Other TC security measures 358 Security specifications for interoperable interface implementation .358.1 General 358.1.1 Subject 35 ISO 2015 All rights reserved iiiContents PagePD

21、 CEN ISO/TS 19299:2015ISO/TS 19299:2015(E)8.1.2 Signature and hash algorithms . 358.2 Security specifications for DSRC-EFC . 368.2.1 Subject 368.2.2 OBE .368.2.3 RSE 369 Key management .369.1 Overview . 369.2 Asymmetric keys 369.2.1 Key exchange between stakeholders . 369.2.2 Key generation and cert

22、ification . 379.2.3 Protection of keys .379.2.4 Application . 379.3 Symmetric keys 389.3.1 General. 389.3.2 Key exchange between stakeholders . 389.3.3 Key lifecycle . 399.3.4 Key storage and protection 409.3.5 Session keys 41Annex A (normative) Security profiles 42Annex B (normative) Implementation

23、 conformance statement (ICS) proforma 46Annex C (informative) Stakeholder objectives and generic requirements .64Annex D (informative) Threat analysis .68Annex E (informative) Security policies . 124Annex F (informative) Example for an EETS security policy 131Annex G (informative) Recommendations fo

24、r privacy-focused implementation .133Annex H (informative) Proposal for end-entity certificates 135Bibliography . 136iv ISO 2015 All rights reservedPD CEN ISO/TS 19299:2015ISO/TS 19299:2015(E)ForewordISO (the International Organization for Standardization) and IEC (the International Electrotechnical

25、 Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activit

26、y. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committe

27、e, ISO/IEC JTC 1.The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of document should be noted. This document was drafted in accorda

28、nce with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives). Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

29、Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents). Any trade name used in this document is information given for the convenience of users and does not constitute

30、an endorsement.For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISOs adherence to the WTO principles in the Technical Barriers to Trade (TBT) see the following URL: Foreword - Supplementary informationISO/TS 19299

31、was prepared by European Committee for Standardization (CEN) in collaboration with ISO/TC 204, Intelligent transport systems, in accordance with the agreement on technical cooperation between ISO and CEN (Vienna Agreement).This first edition of ISO/TS 19299 cancels and replaces CEN/TS 16439:2013. IS

32、O 2015 All rights reserved vPD CEN ISO/TS 19299:2015ISO/TS 19299:2015(E)IntroductionReaders guideThe development process for a security concept and implementation to protect any existing electronic fee collection (EFC) system normally includes several steps as follows: definition of the security obj

33、ectives and policy statements in a security policy; threat analysis with risk assessment to define the security requirements; development of the security measures followed by the development of security test specifications.Figure 1 Development path for the security documentsIn the second step, each

34、actor in an existing EFC system has to implement the defined security measures and supervise the effectiveness. Security measures which do not work or work incorrectly need to be improved. The development of the EFC security framework follows this approach as closely as possible. The used methodolog

35、y needs to consider following limitations: No security policy exists: The security policy can only be defined by the responsible stakeholders and its freedom is only limited by laws and regulations. Nonetheless, this Technical Specification provides basic examples of possible security policies (in A

36、nnex E to Annex F). No risk assessment possible: The risk assessment compares the possible 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 pos

37、sible for an implemented system. No specific system design or configuration during the development of this Technical Specification was considered to keep it universally applicable. Only the available EFC base standards and the comments received by the CEN/TS 16439:2013 (i.e. the previous edition of

38、the EFC security framework) were taken as references. Specific technical details of a particular system (e.g. servers, computer centres, and de-central elements like road side equipment) need to be taken into consideration during the implementation in addition to the present EFC security framework.v

39、i ISO 2015 All rights reservedPD CEN ISO/TS 19299:2015ISO/TS 19299:2015(E)The selection of requirements and the respective security measures for an existing EFC system is based on the security policy and the risk assessment of several stakeholders systems. Due to the fact that there is neither an ov

40、erall valid security policy, nor the possibility to provide a useful risk assessment, the EFC security framework provides a toolbox of requirements and security measures covering as many threats as possible without claiming to provide an exhaustive list.There is one limitation though to be compliant

41、 to this Technical Specification that is, if a requirement is selected, the associated security measure(s) have to be implemented.To understand the content of this Technical Specification, the reader should be aware of the methodological assumptions used to develop it. The security of an (interopera

42、ble) EFC scheme depends on the correct implementation and operation of a number of processes, systems, and interfaces. Only a reliable end-to-end security ensures the accurate and trustworthy operation of interacting components of toll charging environments. Therefore, this security framework also c

43、overs systems or interfaces which are not EFC specific like back office connections. The application independent security framework for such system parts and interfaces, the Information Security Management System (ISMS), is provided in the ISO 2700x family of standards.The development process of thi

44、s Technical Specification is described briefly in the steps below:a) Definition of the stakeholder objectives and generic requirements as the basic motivation for the security requirements (Annex C). A possible security policy with a set of policy statements is provided in Annex E, and an example of

45、 an European electronic toll service (EETS) security policy is given in Annex F.b) Based on the EFC role model and further definitions from the EFC architecture standard (ISO 17573), the specification defines an abstract EFC system model as the basis for a threat analysis, definition of requirements

46、, and security measures.c) The threats on the EFC system model and its assets are analysed by two different methods: an attack-based analysis and an asset-based analysis. The first approach considers a number of threat scenarios from the perspective of various attackers. The second approach looks in

47、 depth on threats against the various identified assets (tangible and intangible entities). This approach, although producing some redundancy, ensures completeness and coverage of a broader range of risks (see Annex D).d) The requirements specification (see Clause 6) is based on the threats identifi

48、ed in Annex D. Each requirement is at least motivated by one threat and at least one requirement covers each threat.e) The definition of security measures (see Clause 7) provides a high-level description of recommended possible methods to cover the developed requirements.f) The security specificatio

49、ns for interoperable interface implementation (Clause 8) provide detailed definitions, e.g. for message authenticators. These specifications represent an add-on for security to the corresponding relevant interface standards.g) Basic key management requirements that support the implementation of the interoperable interfaces are described in Clause 9. The toll charging environment uses cryptographic elements (keys, certificates, certificate revocation lists, etc.) to support security services like confidentiality, integrity, authenticity, and