BS PD CEN ISO TS 19299-2015 Electronic fee collection Security framework《电子收费 安全框架》.pdf

《BS PD CEN ISO TS 19299-2015 Electronic fee collection Security framework《电子收费 安全框架》.pdf》由会员分享，可在线阅读，更多相关《BS PD CEN ISO TS 19299-2015 Electronic fee collection Security framework《电子收费 安全框架》.pdf（154页珍藏版）》请在麦多课文档分享上搜索。

1、BSI Standards Publication Electronic fee collection Security framework PD CEN ISO/TS 19299:2015National foreword This Published Document is the UK implementation of CEN ISO/TS 19299:2015. It supersedes PD CEN/TS 16439:2013 which is withdrawn. The UK participation in its preparation was entrusted to

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

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

4、egy Committee on 31 October 2015. Amendments/corrigenda issued since publication Date Text affected PUBLISHED DOCUMENT PD CEN ISO/TS 19299:2015 TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN ISO/TS 19299 O c t o b e r 2 0 1 5 ICS 35.240.60; 03.220.20 Supersedes CEN/TS 16

5、439:2013 English Version Electronic 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 201

6、5 for provisional application. The 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

7、 to announce the existence of this 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 convers

8、ion of the CEN/TS into an EN is 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, Luxem

9、bourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brusse

10、ls 2015 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. CEN ISO/TS 19299:2015 E PD 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 forew

11、ord This document (CEN ISO/TS 19299: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

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

13、d the European Free Trade Association. 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

14、 Yugoslav Republic of Macedonia, 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. Endorsement notice The text of ISO/TS 19299

15、:2015 has been approved by CEN as CEN ISO/TS 19299:2015 without any modification. PD CEN ISO/TS 19299:2015 ISO/TS 19299:2015(E)Foreword v Introduction vi 1 Scope . 1 2 Normative references 2 3 T erms and definitions . 4 4 Symbols and abbreviated terms . 9 5 Trust model .10 5.1 Overview .10 5.2 Stake

16、holders trust relations .10 5.3 Technical trust model .11 5.3.1 General.11 5.3.2 Trust model for TC and TSP relations .11 5.3.3 Trust model for TSP and service user relations .13 5.3.4 Trust model for Interoperability Management relations .13 5.4 Implementation .13 5.4.1 Setup of trust relations 13

17、5.4.2 Trust relation renewal and revocation 14 5.4.3 Issuing and revocation of sub CA and end-entity certificates 14 5.4.4 Certificate and certificate revocation list profile and format .15 5.4.5 Certificate extensions .15 6 Security requirements .17 6.1 General 17 6.2 Information security managemen

18、t system 18 6.3 Communication interfaces .18 6.4 Data storage 19 6.5 Toll charger .19 6.6 Toll service provider .21 6.7 Interoperability Management .23 6.8 Limitation of requirements .23 7 Security measures countermeasures .24 7.1 Overview .24 7.2 General security measures 24 7.3 Communication inter

19、faces security measures .25 7.3.1 General.25 7.3.2 DSRC-EFC interface . 26 7.3.3 CCC interface 27 7.3.4 LAC interface 28 7.3.5 Front End to TSP back end interface .28 7.3.6 TC to TSP interface 29 7.3.7 ICC interface 30 7.4 End-to-end security measures .30 7.5 Toll service provider security measures

20、32 7.5.1 Front end security measures 32 7.5.2 Back end security measures .33 7.6 Toll charger security measures 34 7.6.1 RSE security measures . 34 7.6.2 Back end security measures .34 7.6.3 Other TC security measures 35 8 S ecurity specifications for int er oper able int erfac e implementation .35

21、8.1 General 35 8.1.1 Subject35 ISO 2015 All rights reserved iii Contents Page PD CEN ISO/TS 19299:2015 ISO/TS 19299:2015(E)8.1.2 Signature and hash algorithms .35 8.2 Security specifications for DSRC-EFC .36 8.2.1 Subject36 8.2.2 OBE .36 8.2.3 RSE 36 9 Key management .36 9.1 Overview .36 9.2 Asymmet

22、ric keys 36 9.2.1 Key exchange between stakeholders .36 9.2.2 Key generation and certification .37 9.2.3 Protection of keys .37 9.2.4 Application .37 9.3 Symmetric keys 38 9.3.1 General.38 9.3.2 Key exchange between stakeholders .38 9.3.3 Key lifecycle .39 9.3.4 Key storage and protection 40 9.3.5 S

23、ession keys 41 Annex A (normative) S ecurity pr ofiles 42 Annex B (normative) Implementation conformance statement (ICS) proforma 46 Annex C (informative) Stakeholder objectives and generic requirements .64 Annex D (informative) Threat analysis .68 Annex E (informative) Security policies .124 Annex

24、F (informative) Example for an EETS security policy 131 Annex G (informative) Recommendations for privacy-focused implementation .133 Annex H (informative) Pr oposal for end-entity c ertificat es135 Bibliography .136 iv ISO 2015 All rights reserved PD CEN ISO/TS 19299:2015 ISO/TS 19299:2015(E) Forew

25、ord ISO (the International Organization for Standardization) and IEC (the International Electrotechnical 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 c

26、ommittees established by the respective organization to deal with particular fields of technical activity. 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 t

27、he work. In the field of information technology, ISO and IEC have established a joint technical committee, 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

28、criteria needed for the different types of document should be noted. This document was drafted in accordance 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

29、 patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. 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 tr

30、ade name used in this document is information given for the convenience of users and does not constitute 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

31、Technical Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information ISO/TS 19299 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 I

32、SO and CEN (Vienna Agreement). This first edition of ISO/TS 19299 cancels and replaces CEN/TS 16439:2013. ISO 2015 All rights reserved v PD CEN ISO/TS 19299:2015 ISO/TS 19299:2015(E) Introduction Readers guide The development process for a security concept and implementation to protect any existing

33、electronic fee collection (EFC) system normally includes several steps as follows: definition of the security objectives 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 developm

34、ent of security test specifications. Figure 1 Development path for the security documents In the second step, each 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 improv

35、ed. The development of the EFC security framework follows this approach as closely as possible. The used methodology 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

36、 regulations. Nonetheless, this Technical Specification provides basic examples of possible security policies (in Annex 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

37、 perform an attack. It is the trade-off evaluation of the cost and benefit of each countermeasure which is only possible 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

38、 the available EFC base standards and the comments received by the CEN/TS 16439:2013 (i.e. the previous edition of 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

39、) need to be taken into consideration during the implementation in addition to the present EFC security framework.vi ISO 2015 All rights reserved PD CEN ISO/TS 19299:2015 ISO/TS 19299:2015(E) The selection of requirements and the respective security measures for an existing EFC system is based on th

40、e security policy and the risk assessment of several stakeholders systems. Due to the fact that there is neither an overall 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

41、many threats as possible without claiming to provide an exhaustive list. There is one limitation though to be compliant 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 Specif

42、ication, the reader should be aware of the methodological assumptions used to develop it. The security of an (interoperable) 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

43、trustworthy operation of interacting components of toll charging environments. Therefore, this security framework also covers systems or interfaces which are not EFC specific like back office connections. The application independent security framework for such system parts and interfaces, the Inform

44、ation Security Management System (ISMS), is provided in the ISO 2700x family of standards. The development process of this 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 re

45、quirements (Annex C). A possible security policy with a set of policy statements is provided in Annex E, and an example of 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 17

46、573), the specification defines an abstract EFC system model as the basis for a threat analysis, definition of requirements, 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

47、first approach considers a number of threat scenarios from the perspective of various attackers. The second approach looks in depth on threats against the various identified assets (tangible and intangible entities). This approach, although producing some redundancy, ensures completeness and coverag

48、e of a broader range of risks (see Annex D). d) The requirements specification (see Clause 6) is based on the threats identified 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) pro

49、vides a high-level description of recommended possible methods to cover the developed requirements. f) The security specifications 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 (key