CLC TR 62541-2-2010 OPC unified architecture - Part 2 Security model《OPC统一架构 第2部分 安全模型》.pdf

1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationOPC Unified ArchitecturePart 2: Security modelPD CLC/TR 62541-2:2010National forewordThis Published Document is the UK implementation of CLC/TR 62541-2:2010.It is identical to IE

2、C/TR 62541-2:2010.The UK participation in its preparation was entrusted to Technical CommitteeAMT/7, Industrial communications: process measurement and control, including fieldbus.A list of organizations represented on this committee can be obtained onrequest to its secretary.This publication does n

3、ot purport to include all the necessary provisions of acontract. Users are responsible for its correct application. BSI 2010 ISBN 978 0 580 64158 9 ICS 25.040.40; 35.100.01; 35.200; 35.240.50Compliance with a British Standard cannot confer immunity from legal obligations.This Published Document was

4、published under the authority of the Standards Policy and Strategy Committee on 3 2010.Amendments/corrigendum issued since publicationDate Text affectedPUBLISHED DOCUMENTPD CLC/TR 62541-2:20101 OctoberTECHNICAL REPORT CLC/TR 62541-2 RAPPORT TECHNIQUE TECHNISCHER BERICHT August 2010 CENELEC European

5、Committee for Electrotechnical Standardization Comit Europen de Normalisation Electrotechnique Europisches Komitee fr Elektrotechnische Normung Management Centre: Avenue Marnix 17, B - 1000 Brussels 2010 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC

6、 members. Ref. No. CLC/TR 62541-2:2010 E ICS 25.040.40; 35.100.01 English version OPC unified architecture - Part 2: Security model (IEC/TR 62541-2:2010) Architecture unifie OPC - Partie 2: Modle de scurit (CEI/TR 62541-2:2010) OPC Unified Architecture - Teil 2: Modell fr die IT-Sicherheit (IEC/TR 6

7、2541-2:2010) This Technical Report was approved by CENELEC on 2010-06-25. CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lit

8、huania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. CLC/TR 62541-2:2010 - 2 - Foreword The text of the Technical Report IEC/TR 62541-2:2010, prepared by SC 65E, Devices and integration in enterprise sys

9、tems, of IEC TC 65, Industrial-process measurement, control and automation, was submitted to vote and was approved by CENELEC as CLC/TR 62541-2 on 2010-06-25. Annex ZA has been added by CENELEC. _ Endorsement notice The text of the Technical Report IEC/TR 62541-2:2010 was approved by CENELEC as a Te

10、chnical Report without any modification. In the official version, for Bibliography, the following notes have to be added for the standards indicated: IEC 62541-3 NOTE Harmonized as EN 62541-3. IEC 62541-4 NOTE Harmonized as EN 62541-4. IEC 62541-5 NOTE Harmonized as EN 62541-5. IEC 62541-6 NOTE Harm

11、onized as EN 62541-6. _PD CLC/TR 62541-2:2010- 3 - CLC/TR 62541-2:2010 Annex ZA (normative) Normative references to international publications with their corresponding European publications The following referenced documents are indispensable for the application of this document. For dated reference

12、s, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. NOTE When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD applies. Publication Year Title EN/HD

13、Year IEC/TR 62541-1 2010 OPC unified architecture - Part 1: Overview and concepts CLC/TR 62541-1 2010 IEC 62541 Series OPC unified architecture EN 62541 Series PD CLC/TR 62541-2:2010 2 TR 62541-2 IEC:2010(E) CONTENTS INTRODUCTION.6 1 Scope.7 2 Normative references .7 3 Terms, definitions, abbreviati

14、ons and conventions7 3.1 Terms and definitions 7 3.2 Abbreviations and symbols11 3.3 Conventions concerning security model figures .11 4 OPC UA Security architecture 11 4.1 OPC UA security environment .11 4.2 Security objectives 12 4.2.1 General .12 4.2.2 Authentication .13 4.2.3 Authorization .13 4

15、.2.4 Confidentiality .13 4.2.5 Integrity.13 4.2.6 Auditability 13 4.2.7 Availability.13 4.3 Security threats to OPC UA systems .13 4.3.1 General .13 4.3.2 Message flooding 13 4.3.3 Eavesdropping 14 4.3.4 Message spoofing .14 4.3.5 Message alteration 14 4.3.6 Message replay .14 4.3.7 Malformed messag

16、es.15 4.3.8 Server profiling15 4.3.9 Session hijacking.15 4.3.10 Rogue server.15 4.3.11 Compromising user credentials15 4.4 OPC UA relationship to site security16 4.5 OPC UA security architecture16 4.6 Security policies 18 4.7 Security profiles 18 4.8 User authorization .19 4.9 User authentication .

17、19 4.10 Application authentication .19 4.11 OPC UA security related services19 4.12 Auditing.20 4.12.1 General .20 4.12.2 Single client and server .21 4.12.3 Aggregating server 21 4.12.4 Aggregation through a non-auditing server 22 4.12.5 Aggregating server with service distribution.23 5 Security re

18、conciliation 24 5.1 Reconciliation of threats with OPC UA security mechanisms .24 PD CLC/TR 62541-2:2010TR 62541-2 IEC:2010(E) 5 5.1.1 General .24 5.1.2 Message flooding 24 5.1.3 Eavesdropping 25 5.1.4 Message spoofing .25 5.1.5 Message alteration 25 5.1.6 Message replay .25 5.1.7 Malformed messages

19、.26 5.1.8 Server profiling26 5.1.9 Session hijacking.26 5.1.10 Rogue server.26 5.1.11 Compromising user credentials26 5.2 Reconciliation of objectives with OPC UA security mechanisms 26 5.2.1 General .26 5.2.2 Authentication .27 5.2.3 Authorization .27 5.2.4 Confidentiality .27 5.2.5 Integrity.27 5.

20、2.6 Auditability 28 5.2.7 Availability.28 6 Implementation considerations .28 6.1 General .28 6.2 Appropriate timeouts .28 6.3 Strict message processing.28 6.4 Random number generation 29 6.5 Special and reserved packets29 6.6 Rate limiting and flow control 29 Bibliography30 Figure 1 OPC UA network

21、model .12 Figure 2 OPC UA security architecture.17 Figure 3 Simple servers .21 Figure 4 Aggregating servers.22 Figure 5 Aggregation with a non-auditing server 23 Figure 6 Aggregate server with service distribution 24 PD CLC/TR 62541-2:2010 6 TR 62541-2 IEC:2010(E) INTRODUCTION This technical report

22、introduces security concepts for OPC Unified Architecture as specified by IEC 62541. This technical report and specification are a result of an analysis and design process to develop a standard interface to facilitate the development of applications by multiple vendors that inter-operate seamlessly

23、together. PD CLC/TR 62541-2:2010TR 62541-2 IEC:2010(E) 7 OPC UNIFIED ARCHITECTURE Part 2: Security Model 1 Scope This part of IEC 62541 describes the OPC Unified Architecture (OPC UA) security model. It describes the security threats of the physical, hardware and software environments in which OPC U

24、A is expected to run. It describes how OPC UA relies upon other standards for security. It gives an overview of the security features that are specified in other parts of the OPC UA specification. It references services, mappings, and profiles that are specified normatively in other parts of this se

25、ries of standards. Note that there are many different aspects of security that have to be addressed when developing applications. However since OPC UA specifies a communication protocol, the focus is on securing the data exchanged between applications. This does not mean that an application develope

26、r can ignore the other aspects of security like protecting persistent data against tampering. It is important that the developer look into all aspects of security and decide how they can be addressed in the application. This part of IEC 62541 is directed to readers who will develop OPC UA client or

27、server applications or implement the OPC UA services layer. It is assumed that the reader is familiar with Web Services and XML/SOAP. Information on these technologies can be found in SOAP Part 1 and SOAP Part 2. 2 Normative references The following referenced documents are indispensable for the app

28、lication of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC 62541 (all parts), OPC Unified Architecture IEC 62541-1, OPC Unified Architecture Part 1: Overview and concep

29、ts 3 Terms, definitions, abbreviations and conventions 3.1 Terms and definitions For the purposes of this document the following terms and definitions as well as the terms and definitions given in IEC 62541-1 apply. 3.1.1 Application Instance individual installation of a program running on one compu

30、ter NOTE There can be several Application Instances of the same application running at the same time on several computers or possibly the same computer. PD CLC/TR 62541-2:2010 8 TR 62541-2 IEC:2010(E) 3.1.2 Application Instance Certificate Digital Certificate of an individual instance of an applicat

31、ion that has been installed in an individual host NOTE Different installations of one software product would have different Application Instance Certificates. 3.1.3 Asymmetric Cryptography Cryptography method that uses a pair of keys, one that is designated the Private Key and kept secret, the other

32、 is called the Public Key that is generally made available NOTE Asymmetric Cryptography, also known as “public-key cryptography“. In an asymmetric encryption algorithm when an entity A wants to ensure Confidentiality for data it sends to another entity B, entity A encrypts the data with a Public Key

33、 provided by entity B. Only entity B has the matching Private Key that is needed to decrypt the data. In an asymmetric digital signature algorithm when an entity A wants to ensure Integrity or provide Authentication for data it sends to an entity B, entity A uses its Private Key to sign the data. To

34、 verify the signature, entity B uses the matching Public Key that entity A has provided. In an asymmetric key agreement algorithm, entity A and entity B each send their own Public Key to the other entity. Then each uses their own Private Key and the others Public Key to compute the new key value. Se

35、e IS Glossary. 3.1.4 Asymmetric Encryption mechanism used by Asymmetric Cryptography for encrypting data with the Public Key of an entity and for decrypting data with the associated Private Key NOTE See 3.1.3 for details. 3.1.5 Asymmetric Signature mechanism used by Asymmetric Cryptography for signi

36、ng data with the Private Key of an entity and for verifying the datas signature with the associated Public Key NOTE See 3.1.3 for details. 3.1.6 Auditability security objective that assures that any actions or activities in a system can be recorded 3.1.7 Auditing tracking of actions and activities i

37、n the system, including security related activities where the Audit records can be used to verify the operation of system security 3.1.8 Authentication process of verifying the identity of an entity such as a client, server, or user 3.1.9 Authorization process of granting the right or the permission

38、 to a system entity to access a system resource 3.1.10 Availability running of the system with unimpeded capacity 3.1.11 Confidentiality protection of data from being read by unintended parties PD CLC/TR 62541-2:2010TR 62541-2 IEC:2010(E) 9 3.1.12 Cryptogrophy transforming clear, meaningful informat

39、ion into an enciphered, unintelligible form using an algorithm and a key 3.1.13 Cyber Security Management System CSMS program designed by an organization to maintain the security of the entire organizations assets to an established level of Confidentiality, Integrity, and Availability, whether they

40、are on the business side or the industrial automation and control systems side of the organization 3.1.14 Digital Certificate structure that associates an identity with an entity such as a user, a product or an Application Instance where the certificate has an associated asymmetric key pair which ca

41、n be used to authenticate that the entity does, indeed, possess the Private Key 3.1.15 Digital Signature value computed with a cryptographic algorithm and appended to data in such a way that any recipient of the data can use the signature to verify the datas origin and integrity 3.1.16 Hash Function

42、 algorithm such as SHA-1 for which it is computationally infeasible to find either a data object that maps to a given hash result (the “one-way“ property) or two data objects that map to the same hash result (the “collision-free“ property), see IS Glossary 3.1.17 Hashed Message Authentication Code H

43、MAC MAC that has been generated using an iterative Hash Function 3.1.18 Integrity security goal that assures that information has not been modified or destroyed in a unauthorized manner NOTE definition from IS Glossary. 3.1.19 Key Exchange Algorithm protocol used for establishing a secure communicat

44、ion path between two entities in an unsecured environment whereby both entities apply a specific algorithm to securely exchange secret keys that are used for securing the communication between them NOTE A typical example of a Key Exchange Algorithm is the SSL Handshake Protocol specified in SSL/TLS.

45、 3.1.20 Message Authentication Code MAC short piece of data that results from an algorithm that uses a secret key (see Symmetric Cryptography) to hash a message whereby the receiver of the message can check against alteration of the message by computing a MAC that should be identical using the same

46、message and secret key 3.1.21 Message Signature Digital Signature used to ensure the Integrity of messages sent between two entities PD CLC/TR 62541-2:2010 10 TR 62541-2 IEC:2010(E) NOTE There are several ways to generate and verify Message Signatures, however, they can be categorized as symmetric (

47、see 3.1.32) and asymmetric (see 3.1.5) approaches. 3.1.22 Non-Repudiation strong and substantial evidence of the identity of the signer of a message and of message integrity, sufficient to prevent a party from successfully denying the original submission or delivery of the message and the integrity

48、of its contents 3.1.23 Nonce random number that is used once, typically by algorithms that generate security keys 3.1.24 OPC UA Application OPC UA Client, which calls OPC UA services, or an OPC UA Server, which performs those services 3.1.25 Private Key secret component of a pair of cryptographic ke

49、ys used for Asymmetric Cryptography 3.1.26 Public Key publicly-disclosed component of a pair of cryptographic keys used for Asymmetric Cryptography, see IS Glossary 3.1.27 Public Key Infrastructure PKI set of hardware, software, people, policies and procedures needed to create, manage, store, distribute and revoke Digital Certificates based on Asymmetric Cryptography NOTE The core PKI functions are to register users and issue their public-key certificates, to revoke certificates when requir