BS PD CLC TR 62541-2-2010 OPC Unified Architecture nPart 2 Security model《OPC统一架构 第2部分 安全模型》.pdf

1、raising standards worldwide NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW BSI Standards Publication OPC Unified Architecture Part 2: Security model PD CLC/TR 62541-2:2010National foreword This Published Document is the UK implementation of CLC/TR 62541-2:2010. It is identica

2、l to IEC/TR 62541-2:2010. The UK participation in its preparation was entrusted to Technical Committee AMT/7, Industrial communications: process measurement and control, including fieldbus. A list of organizations represented on this committee can be obtained on request to its secretary. This public

3、ation does not purport to include all the necessary provisions of a contract. 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.50 Compliance with a British Standard cannot confer immunity from legal obligations. This Publishe

4、d Document was published under the authority of the Standards Policy and Strategy Committee on 3 2010. Amendments/corrigendum issued since publication Date Text affected PUBLISHED DOCUMENT PD CLC/TR 62541-2:2010 1 October TECHNICAL REPORT CLC/TR 62541-2 RAPPORT TECHNIQUE TECHNISCHER BERICHT August 2

5、010 CENELEC European 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

6、worldwide for CENELEC 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

7、-Sicherheit (IEC/TR 62541-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, Irelan

8、d, Italy, Latvia, Lithuania, 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 integrat

9、ion in enterprise systems, 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 approv

10、ed by CENELEC as a Technical 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.

11、IEC 62541-6 NOTE Harmonized 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 docume

12、nt. For dated references, 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. Public

13、ation Year Title EN/HD 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,

14、definitions, abbreviations 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.

15、2.3 Authorization .13 4.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

16、 4.3.7 Malformed messages.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.

17、9 User authentication .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 distri

18、bution.23 5 Security reconciliation 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

19、.1.7 Malformed messages.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 .2

20、7 5.2.5 Integrity.27 5.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 F

21、igure 1 OPC UA network 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

22、 This technical report 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 in

23、ter-operate seamlessly 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 envi

24、ronments in which OPC UA 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

25、 other parts of this series 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

26、an application developer 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 de

27、velop OPC UA client or 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 in

28、dispensable for the application 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

29、 1: Overview and concepts 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 progr

30、am running on one computer 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

31、instance of an application 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

32、 kept secret, the other 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

33、 data with a Public Key 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 K

34、ey to sign the data. To 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 comput

35、e the new key value. See 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

36、 Cryptography for signing 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 a

37、ctions and activities in 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

38、right or the permission 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 cle

39、ar, meaningful information 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 Avai

40、lability, whether they 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 asymm

41、etric key pair which can 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 integri

42、ty 3.1.16 Hash Function 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 Messag

43、e Authentication Code HMAC 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 establish

44、ing a secure communication 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 Protoco

45、l specified in SSL/TLS. 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 id

46、entical using the same 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 cat

47、egorized as symmetric (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 mes

48、sage and the integrity 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 p

49、air of cryptographic keys 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 certif