SIST-TP CLC/TR 62541-2:2010
(Main)OPC unified architecture - Part 2: Security model (IEC/TR 62541-2:2010)
OPC unified architecture - Part 2: Security model (IEC/TR 62541-2:2010)
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 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 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 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 develop 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.
OPC Unified Architecture - Teil 2: Modell für die IT-Sicherheit (IEC/TR 62541-2:2010)
Architecture unifiée OPC - Partie 2: Modèle de sécurité (CEI/TR 62541-2:2010)
Poenotena arhitektura OPC - 2. del: Zaščitni model (IEC/TR 62541-2:2010)
Ta del IEC 62541 opisuje zaščitni model poenotene arhitekture OPC (OPC UA). Opisuje grožnje za varnostne fizičnih strojnih in programskih okolij, v katerih se pričakuje delovanje OPC UA. Opisuje kako se OPC UA navezuje na druge standarde za varnost. Podaja pregled varnostnih lastnosti, ki so opredeljene v drugih delih OPC UA specifikacije. Sklicuje se na storitve, preslikave in profile, ki so normativno določeni v drugih delih standardov teh serije. Opozoriti je treba, da je veliko različnih vidikov varnosti, ki jih je potrebno nasloviti, kadar razvijamo aplikacije. Vendar, odkar OPC UA določa komunikacijski protokol, je poudarek na zaščiti podatkov med aplikacijami. To ne pomeni, da lahko razvijalec aplikacije zanemari ostale varnostne vidike, kot je varovanje obstojnih podatkov pred nedovoljenim spreminjanjem. Pomembno je, da razvijalec pregleda vse varnostne vidike in odloči, kako se jih lahko obravnava v tej aplikaciji. Ta del IEC 62541 je usmerjen k bralcem, ki bojo razvijali OPC UA aplikacije za kliente ali strežnike ali uvajali storitveno plast OPC UA. Predvideva se, da je bralec seznanjen s spletnimi storitvami in XML/SOAP. Informacije o teh tehnologijah se nahajajo v 1. delu in 2. delu SOAP.
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TP CLC/TR 62541-2:2010
01-december-2010
3RHQRWHQDDUKLWHNWXUD23&GHO =DãþLWQLPRGHO ,(&75
OPC unified architecture - Part 2: Security model (IEC/TR 62541-2:2010)
OPC Unified Architecture - Teil 2: Modell für die IT-Sicherheit (IEC/TR 62541-2:2010)
Architecture unifiée OPC - Partie 2: Modèle de sécurité (CEI/TR 62541-2:2010)
Ta slovenski standard je istoveten z: CLC/TR 62541-2:2010
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.100.01 Medsebojno povezovanje Open systems
odprtih sistemov na splošno interconnection in general
SIST-TP CLC/TR 62541-2:2010 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TP CLC/TR 62541-2:2010
---------------------- Page: 2 ----------------------
SIST-TP CLC/TR 62541-2:2010
TECHNICAL REPORT
CLC/TR 62541-2
RAPPORT TECHNIQUE
August 2010
TECHNISCHER BERICHT
ICS 25.040.40; 35.100.01
English version
OPC unified architecture -
Part 2: Security model
(IEC/TR 62541-2:2010)
Architecture unifiée OPC - OPC Unified Architecture -
Partie 2: Modèle de sécurité Teil 2: Modell für die IT-Sicherheit
(CEI/TR 62541-2:2010) (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, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland and the United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für 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 members.
Ref. No. CLC/TR 62541-2:2010 E
---------------------- Page: 3 ----------------------
SIST-TP CLC/TR 62541-2:2010
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 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 approved 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.
IEC 62541-6 NOTE Harmonized as EN 62541-6.
__________
---------------------- Page: 4 ----------------------
SIST-TP 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
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.
Publication Year Title EN/HD Year
IEC/TR 62541-1 2010 OPC unified architecture - CLC/TR 62541-1 2010
Part 1: Overview and concepts
IEC 62541 Series OPC unified architecture EN 62541 Series
---------------------- Page: 5 ----------------------
SIST-TP CLC/TR 62541-2:2010
---------------------- Page: 6 ----------------------
SIST-TP CLC/TR 62541-2:2010
IEC/TR 62541-2
®
Edition 1.0 2010-02
TECHNICAL
REPORT
OPC Unified Architecture –
Part 2: Security Model
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
V
ICS 25.040.40; 35.100.01 ISBN 2-8318-1080-3
® Registered trademark of the International Electrotechnical Commission
---------------------- Page: 7 ----------------------
SIST-TP CLC/TR 62541-2:2010
– 2 – TR 62541-2 © IEC:2010(E)
CONTENTS
FOREWORD.4
INTRODUCTION.6
1 Scope.7
2 Normative references .7
3 Terms, definitions, abbreviations and conventions.7
3.1 Terms and definitions .7
3.2 Abbreviations and symbols.11
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.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 messages.15
4.3.8 Server profiling .15
4.3.9 Session hijacking.15
4.3.10 Rogue server.15
4.3.11 Compromising user credentials.15
4.4 OPC UA relationship to site security.16
4.5 OPC UA security architecture.16
4.6 Security policies .18
4.7 Security profiles .18
4.8 User authorization .19
4.9 User authentication .19
4.10 Application authentication .19
4.11 OPC UA security related services.19
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 reconciliation .24
5.1 Reconciliation of threats with OPC UA security mechanisms .24
---------------------- Page: 8 ----------------------
SIST-TP CLC/TR 62541-2:2010
TR 62541-2 © IEC:2010(E) – 3 –
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.26
5.1.8 Server profiling .26
5.1.9 Session hijacking.26
5.1.10 Rogue server.26
5.1.11 Compromising user credentials.26
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.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 packets.29
6.6 Rate limiting and flow control .29
Bibliography.30
Figure 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
---------------------- Page: 9 ----------------------
SIST-TP CLC/TR 62541-2:2010
– 4 – TR 62541-2 © IEC:2010(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC UNIFIED ARCHITECTURE –
Part 2: Security Model
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC 62541-2, which is a technical report, has been prepared by subcommittee 65E: Devices
and integration in enterprise systems, of IEC technical committee 65: Industrial-process
measurement, control and automation.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
65E/93/DTR 65E/155/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
---------------------- Page: 10 ----------------------
SIST-TP CLC/TR 62541-2:2010
TR 62541-2 © IEC:2010(E) – 5 –
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
A list of all parts of the IEC 62541 series, under the general title OPC Unified Architecture,
can be found on the IEC website.
The committee has decided that the contents of this publication will remain unchanged until
the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data
related to the specific publication. At this date, the publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.
---------------------- Page: 11 ----------------------
SIST-TP CLC/TR 62541-2:2010
– 6 – TR 62541-2 © IEC:2010(E)
INTRODUCTION
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 inter-operate seamlessly together.
---------------------- Page: 12 ----------------------
SIST-TP CLC/TR 62541-2:2010
TR 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 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 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 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 develop 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 indispensable 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 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 program 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.
---------------------- Page: 13 ----------------------
SIST-TP 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 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
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 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 Key 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
other's Public Key to compute 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 Cryptography for signing data with the Private Key of an
entity and for verifying the data’s 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 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 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
---------------------- Page: 14 ----------------------
SIST-TP CLC/TR 62541-2:2010
TR 62541-2 © IEC:2010(E) – 9 –
3.1.12
Cryptogrophy
transforming clear, 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 organization’s
assets to an established level of Confidentiality, Integrity, and Availability, 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 asymmetric 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 data's origin and integrity
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
IS Glossary
same hash result (the "collision-free" property), see
3.1.17
Hashed Message 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 establishing 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 Protocol 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 identical 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
---------------------- Page: 15 ----------------------
SIST-TP 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 (see 3.1.32) and asymmetric (see 3. 1. 5 ) ap pr oac h es .
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 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 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 certificates
when required, and to archive data needed to validate certificates at a much later time. Key pairs for data
Confidentiality may be generated by a certificate authority (CA), but requiring a Private Key owner to generate its
own key pair improves security because the Private Key would never be transmitted, see IS Glossary. See PKI and
X509 PKI for more details on Public Key Infrastructures.
3.1.28
Rivest-Shamir-Adleman
RSA
algorithm for Asymmetric Cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and
Leonard Adleman, see IS Glossary
3.1.29
Secure Channel
in OPC UA, a communication path established between an OPC UA client and server that
have authenticated each other using certain OPC UA services and for which security
parameters have been negotiated and applied
3.1.30
Symmetric Cryptography
branch of cryptography involving algorithms that use the same key for two different steps of
the algorithm (such as encryption and decryption, or signature creation and signature
verification), see IS Glossary
---------------------- Page: 16 ----------------------
SIST-TP CLC/TR 62541-2:2010
TR 62541-2 © IEC:2010(E) – 11 –
3.1.31
Symmetric Encryption
mechanism used by Symmetric Cryptography for encrypting and decrypting data with a
cryptographic key shared by two entities
3.1.32
Symmetric Signature
mechanism used by Symmetric Cryptography for signing data with a cryptographic key shared
by two entities
NOTE The signature is then validated by generating the signature for the data again and comparing these two
signatures. If they are the same then the signature is valid, otherwise either the key or the data is different from the
two entities. Subclause 3.1.17 defines a typical example for an algorithm that generates Symmetric
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.