oSIST prEN IEC 62541-2:2024

SLOVENSKI STANDARD
01-marec-2024
Enotna arhitektura OPC - 2. del: Varnostni model
OPC unified architecture - Part 2: Security model
Ta slovenski standard je istoveten z: prEN IEC 62541-2:2024
ICS:
25.040.40 Merjenje in krmiljenje Industrial process
industrijskih postopkov measurement and control
35.240.50 Uporabniške rešitve IT v IT applications in industry
industriji
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

65E/1040/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62541-2 ED1
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2024-01-26 2024-04-19
SUPERSEDES DOCUMENTS:
65E/950/NP, 65E/1010/RVN
IEC SC 65E : DEVICES AND INTEGRATION IN ENTERPRISE SYSTEMS
SECRETARIAT: SECRETARY:
United States of America Mr Donald (Bob) Lattimer
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:

Other TC/SCs are requested to indicate their interest, if any,
in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY
SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING
Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft for
Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.
This document is still under study and subject to change. It should not be used for reference purposes.
Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which
they are aware and to provide supporting documentation.
Recipients of this document are invited to submit, with their comments, notification of any relevant “In Some Countries”
clauses to be included should this proposal proceed. Recipients are reminded that the CDV stage is the final stage for
submitting ISC clauses. (SEE AC/22/2007 OR NEW GUIDANCE DOC).

TITLE:
OPC Unified Architecture – Part 2: Security Model

PROPOSED STABILITY DATE: 2026
NOTE FROM TC/SC OFFICERS:
electronic file, to make a copy and to print out the content for the sole purpose of preparing National Committee positions.
You may not copy or "mirror" the file or printed version of the document, or any part of it, for any other purpose without
permission in writing from IEC.

1 CONTENTS
2 Page
4 1 Scope . 1
5 2 Normative References . 1
6 3 Terms, definitions, and abbreviations . 2
7 3.1 Terms and definitions . 2
8 3.2 Abbreviations . 7
9 3.3 Conventions for security model figures. 7
10 4 OPC UA security architecture . 7
11 4.1 OPC UA security environment . 7
12 4.2 Security objectives . 8
13 4.2.1 Overview . 8
14 4.2.2 Authentication . 8
15 4.2.3 Authorization . 9
16 4.2.4 Confidentiality . 9
17 4.2.5 Integrity . 9
18 4.2.6 Non- Repudiation . 9
19 4.2.7 Auditability . 9
20 4.2.8 Availability . 9
21 4.3 Security threats to OPC UA systems . 9
22 4.3.1 Overview . 9
23 4.3.2 Denial of Service . 9
24 4.3.3 Eavesdropping . 10
25 4.3.4 Message spoofing . 11
26 4.3.5 Message alteration . 11
27 4.3.6 Message replay . 11
28 4.3.7 Malformed Messages . 11
29 4.3.8 Server profiling . 11
30 4.3.9 Session hijacking . 12
31 4.3.10 Rogue Server . 12
32 4.3.11 Rogue Publisher . 12
33 4.3.12 Compromising user credentials . 12
34 4.3.13 Repudiation . 12
35 4.4 OPC UA relationship to site security . 12
36 4.5 OPC UA security architecture . 13
37 4.5.1 Overview . 13
38 4.5.2 Client / Server . 14
39 4.5.3 Publish-Subscribe . 15
40 4.6 SecurityPolicies . 16
41 4.7 Security Profiles . 16
42 4.8 Security Mode Settings . 17
43 4.9 User Authentication . 17
44 4.10 Application Authentication . 17
45 4.11 User Authorization . 17
46 4.12 Roles . 18
47 4.13 OPC UA security related Services . 18
48 4.14 Auditing . 19
49 4.14.1 General . 19
50 4.14.2 Single Client and Server . 20

IEC CDV 62541-2 © IEC 2023 ii
51 4.14.3 Aggregating Server . 20
52 4.14.4 Aggregation through a non-auditing Server . 21
53 4.14.5 Aggregating Server with service distribution . 22
54 5 Security reconciliation . 23
55 5.1 Reconciliation of threats with OPC UA security mechanisms . 23
56 5.1.1 Overview . 23
57 5.1.2 Denial of Service . 23
58 5.1.3 Eavesdropping . 24
59 5.1.4 Message spoofing . 24
60 5.1.5 Message alteration . 25
61 5.1.6 Message replay . 25
62 5.1.7 Malformed Messages . 25
63 5.1.8 Server profiling . 25
64 5.1.9 Session hijacking . 25
65 5.1.10 Rogue Server or Publisher . 25
66 5.1.11 Compromising user credentials . 26
67 5.1.12 Repudiation . 26
68 5.2 Reconciliation of objectives with OPC UA security mechanisms . 26
69 5.2.1 Overview . 26
70 5.2.2 Application Authentication . 26
71 5.2.3 User Authentication . 26
72 5.2.4 Authorization . 26
73 5.2.5 Confidentiality . 27
74 5.2.6 Integrity . 27
75 5.2.7 Auditability . 27
76 5.2.8 Availability . 27
77 6 Implementation and deployment considerations . 28
78 6.1 Overview. 28
79 6.2 Appropriate timeouts: . 28
80 6.3 Strict Message processing . 28
81 6.4 Random number generation . 28
82 6.5 Special and reserved packets . 29
83 6.6 Rate limiting and flow control . 29
84 6.7 Administrative access . 29
85 6.8 Cryptographic Keys . 29
86 6.9 Alarm related guidance . 29
87 6.10 Program access . 30
88 6.11 Audit event management . 30
89 6.12 OAuth2, JWT and User roles . 30
90 6.13 HTTPs, TLS & Websockets . 30
91 6.14 Reverse Connect . 31
92 6.15 Passwords . 31
93 6.16 Additional Security considerations . 31
94 7 Unsecured Services . 31
95 7.1 Overview. 31
96 7.2 Multi Cast Discovery . 31
97 7.3 Global Discovery Server Security . 32
98 7.3.1 Overview . 32
99 7.3.2 Rogue GDS . 32

iii IEC CDV 62541-2 © IEC 2023

100 7.3.3 Threats against a GDS . 32
101 7.3.4 Certificate management threats. 33
102 8 Certificate management . 33
103 8.1 Overview. 33
104 8.2 Self signed certificate management . 33
105 8.3 CA Signed Certificate management . 34
106 8.4 GDS Certificate Management . 35
107 8.4.1 Overview . 35
108 8.4.2 Developers Certificate management . 35
IEC CDV 62541-2 © IEC 2023 iv
110 Figures
111 Figure 1 – OPC UA network example . 8
112 Figure 2 – OPC UA security architecture – Client / Server . 13
113 Figure 3 – OPC UA security architecture- Publisher - Subscriber . 14
114 Figure 4 – Role overview . 18
115 Figure 5 – Simple Servers . 20
116 Figure 6 – Aggregating Servers . 20
117 Figure 7 – Aggregation with a non-auditing Server . 21
118 Figure 8 – Aggregate Server with service distribution . 22
119 Figure 9 – Manual Certificate handling . 34
120 Figure 10 – CA Certificate handling . 35
121 Figure 11 – Certificate handling . 36
123 Tables
124 Table 1 – Security Reconciliation Threats Summary . 23
v IEC CDV 62541-2 © IEC 2023
127 INTERNATIONAL ELECTROTECHNICAL COMMISSION
128 ____________
130 OPC UNIFIED ARCHITECTURE –
132 Part 2: Security Model
134 FOREWORD
135 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
136 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all
137 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities,
138 IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS)
139 and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC
140 National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental
141 and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with
142 the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between
143 the two organizations.
144 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus
145 of opinion on the relevant subjects since each technical committee has representation from all interested IEC National
146 Committees.
147 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in
148 that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC
149 cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
150 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to
151 the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and
152 the corresponding national or regional publication shall be clearly indicated in the latter.
153 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment
154 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by
155 independent certification bodies.
156 6) All users should ensure that they have the latest edition of this publication.
157 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of
158 its technical committees and IEC National Committees for any personal injury, property damage or other damage of any
159 nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication,
160 use of, or reliance upon, this IEC Publication or any other IEC Publications.
161 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable
162 for the correct application of this publication.
163 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights.
164 IEC shall not be held responsible for identifying any or all such patent rights.
165 The main task of IEC technical committees is to prepare International Standards. However, a technical
166 committee may propose the publication of a technical report when it has collected data of a different
167 kind from that which is normally published as an International Standard, for example "state of the art".
168 International Standard IEC 62541-2 has been prepared by subcommittee 65E: Devices and integration
169 in enterprise systems, of IEC technical committee 65: Industrial-process measurement, control, and
170 automation.
171 The text of this international standard is based on the following documents:
CDV Report on voting
65E/XX/CDV 65E/XX/RVC
173 Full information on the voting for the approval of this international standard can be found in the report
174 on voting indicated in the above table.
175 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
176 Throughout this document and the other Parts of the series, certain document conventions are used:

IEC CDV 62541-2 © IEC 2023 vi
177 Italics are used to denote a defined term or definition that appears in the “Terms and definition” clause
178 in one of the parts of the series.
179 Italics are also used to denote the name of a service input or output parameter or the name of a structure
180 or element of a structure that are usually defined in tables.
181 The italicized terms and names are also often written in camel-case (the practice of writing compound
182 words or phrases in which the elements are joined without spaces, with each element's initial letter
183 capitalized within the compound). For example, the defined term is AddressSpace instead of Address
184 Space. This makes it easier to understand that there is a single definition for AddressSpace, not
185 separate definitions for Address and Space.
186 A list of all parts of the IEC 62541 series is included in IEC 62541-1 clause 4 Structure of the OPC UA
187 series and published under the general title OPC Unified Architecture, can be found on the IEC website.
188 The committee has decided that the contents of this publication will remain unchanged until the stability
189 date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific
190 publication. At this date, the publication will be
191 • reconfirmed,
192 • withdrawn,
193 • replaced by a revised edition, or
194 • amended.
195 A bilingual version of this publication may be issued at a later date.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct understanding
of its contents. Users should therefore print this document using a colour printer.
1 IEC CDV 62541-2 © IEC 2023
201 OPC Unified Architecture Specification
203 Part 2: Security Model
205 1 Scope
206 This document describes the OPC Unified Architecture (OPC UA) security model. It describes the
207 security threats of the physical, hardware, and software environments in which OPC UA is expected
208 to run. It describes how OPC UA relies upon other standards for security. It provides definition of
209 common security terms that are used in this and other parts of the IEC 62541 series. It gives an
210 overview of the security features that are specified in other parts of the series. It references services,
211 mappings, and Profiles that are specified normatively in other parts of the 62541 series. It provides
212 suggestions or best practice guidelines on implementing security. Any seeming ambiguity between
213 this document and one of the other normative parts does not remove or reduce the requirement
214 specified in the other normative part.
215 Note that there are many different aspects of security that have to be addressed when developing
216 applications. However, since OPC UA specifies a communication protocol, the focus is on securing
217 the data exchanged between applications. This does not mean that an application developer can
218 ignore the other aspects of security like protecting persistent data against tampering. It is important
219 that the developers look into all aspects of security and decide how they can be addressed in the
220 application.
221 This document is directed to readers who will develop OPC UA applications. It is also for end Users
222 that wish to understand the various security features and functionality provided by OPC UA. It also
223 offers some recommendations that can be applied when deploying systems. These recommendations
224 are generic in nature since the details would depend on the actual implementation of the OPC UA
225 applications and the choices made for the site security.
226 2 Normative References
227 The following documents, in whole or in part, are normatively referenced in this document and are
228 indispensable for its application. For dated references, only the edition cited applies. For undated
229 references, the latest edition of the referenced document (including any amendments) applies.
230 IEC 62541-1, OPC Unified Architecture – Part 1: Overview and Concepts
231 IEC 62541-3, OPC Unified Architecture – Part 3: Address Space Model
232 IEC 62541-4, OPC Unified Architecture – Part 4: Services
233 IEC 62541-5, OPC Unified Architecture – Part 5: Information Model
234 IEC 62541-6, OPC Unified Architecture – Part 6: Mappings
235 IEC 62541-7, OPC Unified Architecture – Part 7: Profiles
236 IEC 62541-12, OPC Unified Architecture – Part 12: Discovery and Global Services
237 IEC 62541-14, OPC Unified Architecture – Part 14: PubSub
238 IEC 62541-18, OPC Unified Architecture – Part 18: Role-Based Security
240 TLS: RFC 2246: The TLS Protocol Version 1.0
241 https://www.ietf.org/rfc/rfc2246.txt
242 X509: X.509 Public Key Certificate Infrastructure
243 https://www.itu.int/rec/T-REC-X.509-200003-I/e

2 IEC CDV 62541-2 © IEC 2023
244 HTTP: RFC 2616: Hypertext Transfer Protocol - HTTP/1.1
245 https://www.ietf.org/rfc/rfc2616.txt
246 HTTPS: RFC 2818: HTTP Over TLS
247 https://www.ietf.org/rfc/rfc2818.txt
248 IS Glossary: Internet Security Glossary
249 https://www.ietf.org/rfc/rfc2828.txt
250 NIST 800-12: Introduction to Computer Security
251 https://csrc.nist.gov/publications/nistpubs/800-12/
252 NIST 800-57: Part 3: Application-Specific Key Management Guidance
253 https://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_PART3_key-
254 management_Dec2009.pdf
255 NERC CIP: CIP 002-1 through CIP 009-1, by North-American Electric Reliability Council
256 https://www.nerc.com/page.php?cid=2|20
257 SPP-ICS: Guide to Industrial Control Systems (ICS) Security
258 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf
259 SHA-1: Secure Hash Algorithm RFC
260 https://tools.ietf.org/html/rfc3174
261 PKI: Public Key Infrastructure article in Wikipedia
262 https://en.wikipedia.org/wiki/Public_key_infrastructure
263 X509 PKI: Internet X.509 Public Key Infrastructure
264 https://www.ietf.org/rfc/rfc3280.txt
265 RFC 5958: Asymmetric Key Packages
266 https://tools.ietf.org/search/rfc5208
267 PKCS #10: Certification Request Syntax Specification
268 https://tools.ietf.org/html/rfc2986
269 OAuth2: The OAuth 2.0 Authorization Framework
270 https://tools.ietf.org/html/rfc6749
271 JWT: JSON Web Token (JWT)
272 https://tools.ietf.org/html/rfc7519
273 OpenID: OpenID Connect Discovery 1.0
274 https://openid.net/specs/openid-connect-discovery-1_0.html
276 3 Terms, definitions, and abbreviations
277 3.1 Terms and definitions
278 For the purposes of this document, the terms and definitions given in IEC 62541-1 as well as the
279 following apply.
280 3.1.1 AccessRestriction
281 A limit on the circumstances under which an operation, such as a read, write or a call, can be
282 performed on a Node.
3 IEC CDV 62541-1 © IEC 2023
283 Note 1 to entry: Operations can only be performed on a Node if the Client has the necessary Permissions and has satisfied
284 all of the AccessRestrictions.
285 3.1.2 AccessToken
286 A digitally signed document that asserts that the subject is entitled to access a Resource.
287 Note 1 to entry: The document includes the name of the subject and the Resource being accessed.
288 3.1.3 ApplicationInstance
289 individual installation of a program running on one computer.
290 Note 1 to entry: There can be several ApplicationInstances of the same application running at the same time on several
291 computers or possibly the same computer.
292 3.1.4 ApplicationInstanceCertificate
293 Certificate of an individual ApplicationInstance that has been installed in an individual host.
294 Note 1 to entry: Different installations of one software product would have different ApplicationInstanceCertificates. The
295 use of an ApplicationInstanceCertificate for uses outside of what is described in the specification could greatly reduce the
296 security provided by the ApplicationInstanceCertificate and should be discouraged.
297 Note 2 to entry: also written as ApplicationInstance Certificate
298 3.1.5 Asymmetric Cryptography
299 Cryptography method that uses a pair of keys, one that is designated the Private Key and kept secret,
300 the other called the Public Key that is generally made available.
301 Note 1 to entry: ‘Asymmetric Cryptography, also known as "public-key cryptography". In an Asymmetric Encryption
302 algorithm when an entity “A” requires Confidentiality for data sent to entity “B”, then entity “A” encrypts the data with a Public
303 Key provided by entity “B”. Only entity “B” has the matching Private Key that is needed to decrypt the data. In an asymmetric
304 Digital Signature algorithm when an entity “A” requires message Integrity or to provide Authentication for data sent to entity
305 “B”, entity A uses its Private Key to sign the data. To verify the signature, entity B uses the matching Public Key that entity
306 A has provided. In an asymmetric key agreement algorithm, entity A and entity B each send their own Public Key to the
307 other entity. Then each uses their own Private Key and the other's Public Key to compute the new key value.’ according to
308 IS Glossary.
309 3.1.6 Asymmetric Encryption
310 the mechanism used by Asymmetric Cryptography for encrypting data with the Public Key of an entity
311 and for decrypting data with the associated Private Key
312 3.1.7 Asymmetric Signature
313 the mechanism used by Asymmetric Cryptography for signing data with the Private Key of an entity
314 and for verifying the data’s signature with the associated Public Key
315 3.1.8 Auditability
316 security objective that assures that any actions or activities in a system can be recorded
317 3.1.9 Auditing
318 the tracking of actions and activities in the system, including security related activities where Audit
319 records can be used to review and verify system operations
320 3.1.10
321 AuthenticatedEncryption
322 an encryption scheme which simultaneously assures the data confidentiality and authenticity
323 Note 1 to entry: AuthenticatedEncryption algorithms may allow for associated data to be signed but not encrypted.
324 3.1.11 Authentication
325 The process that assures that the identity of an entity such as a Client, Server, Publisher or user can
326 be verified
327 3.1.12 Authorization
328 the ability to grant access to a system resource
329 Note 1 to entry: Authorization of access to resources should be based on the need-to-know principle. It is important that
330 access is restricted in a system.

4 IEC CDV 62541-2 © IEC 2023
331 3.1.13 AuthorizationService
332 A Server which validates a request to access a Resource returns an AccessToken that grants access
333 to the Resource
334 Note 1 to entry: The AuthorizationService is also called STS (Security Token Service) in other standards.
335 3.1.14 Availability
336 security objective that assures that the system is running normally. That is, no services have been
337 compromised in such a way to become unavailable or severely degraded
338 3.1.15 Certificate Authority
339 entity that can issue Certificates, also known as a CA
340 Note 1 to entry: The Certificate certifies the ownership of a Public Key by the named subject of the Certificate. This allows
341 others (relying parties) to rely upon signatures or assertions made by the Private Key that corresponds to the Public Key
342 that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner)
343 of the Certificate and the party relying upon the Certificate. CA s are characteristic of many Public Key infrastructure (PKI)
344 schemes
345 3.1.16 CertificateStore
346 persistent location where Certificates and Certificate revocation lists (CRLs) are stored
347 Note 1 to entry: It may be a disk resident file structure or on Windows platforms it may be a Windows registry location.
348 3.1.17 Claim
349 A statement in an AccessToken that asserts information about the subject which the Authorization
350 Service knows to be true.
351 Note 1 to entry: Claims can include username, email, and Roles granted to the subject.
352 3.1.18 Confidentiality
353 security objective that assures the protection of data from being read by unintended parties
354 3.1.19 Cryptography
355 transforming clear, meaningful information into an enciphered, unintelligible form using an algorithm
356 and a key
357 3.1.20 Cyber Security Management System
358 program designed by an organization to maintain the security of the entire organization’s assets to
359 an established level of Confidentiality, Integrity, and Availability, whether they are on the business
360 side or the industrial automation and control systems side of the organization
361 3.1.21 Digital Signature
362 value computed with a cryptographic algorithm and appended to data in such a way that any recipient
363 of the data can use the signature to verify the data’s origin and Integrity
364 3.1.22 Hash Function
365 algorithm for which it is computationally infeasible to find either a data object that maps to a given
366 hash result (the "one-way" property) or two data objects that map to the same hash result (the
367 "collision-free" property), see IS Glossary
368 3.1.23 Hashed Message Authentication Code
369 MAC that has been generated using an iterative Hash Function
370 3.1.24 Integrity
371 security objective that assures that information has not been modified or destroyed in an unauthorized
372 manner, see IS Glossary
373 3.1.25 Identity Provider
374 A Server which verifies credentials provided by a Security Principal and returns a token which can be
375 passed to an associated Authorization Service.

5 IEC CDV 62541-1 © IEC 2023
376 3.1.26 Key Exchange Algorithm
377 protocol used for establishing a secure communication path between two entities in an unsecured
378 environment whereby both entities apply a specific algorithm to securely exchange secret keys that
379 are used for securing the communication between them
380 Note 1 to entry: A typical example of a Key Exchange Algorithm is the Handshake Protocol specified in TLS.
381 3.1.27 Message Authentication Code
382 short piece of data that results from an algorithm that uses a secret key (see Symmetric Cryptography)
383 to hash a Message whereby the receiver of the Message can check against alteration of the Message
384 by computing a MAC that should be identical using the same Message and secret key
385 3.1.28 Message Signature
386 Digital Signature used to ensure the Integrity of Messages that are sent between two entities
387 Note 1 to entry: There are several ways to generate and verify Message Signatures however they can be categorized as
388 symmetric (See Clause 3.1.42 ) and asymmetric (See Clause 3.1.5) approaches.
389 3.1.29 Non-Repudiation
390 strong and substantial evidence of the identity of the signer of a Message and of Message Integrity,
391 sufficient to prevent a party from successfully denying the original submission or delivery of the
392 Message and the Integrity of its contents
393 3.1.30 Nonce
394 random number that is used once typically by algorithms that generate security keys
395 3.1.31 Permission
396 The right to execute an operation, such as a read, write or a call, on a Node.
397 3.1.32 Private Key
398 the secret component of a pair of cryptographic keys used for Asymmetric Cryptography
399 Note 1 to entry: Public Key and Private Key are always generated as a pair. If either is updated the other must also be
400 updated
401 3.1.33 Public Key
402 the publicly-disclosed component of a pair of cryptographic keys used for Asymmetric Cryptography,
403 see IS Glossary
404 Note 1 to entry: Public Key and Private Key are always generated as a pair. If either is updated the other must also be
405 updated
406 3.1.34 Public Key Infrastructure
407 the set of hardware, software, people, policies, and procedures needed to create, manage, store,
408 distribute, and revoke Certificates based on Asymmetric Cryptography
409 Note 1 to entry: The core PKI functions are to register users and issue their public-key Certificates, to revoke Certificates
410 when required, and to archive data needed to validate Certificates at a much later time. Key pairs for data Confidentiality
411 may be generated by a Certificate authority (CA); it is a good idea to require a Private Key owner to generate their own key
412 pair as it improves security because the Private Key would never be transmitted according to IS Glossary. See PKI and
413 X509 PKI for more details on Public Key Infrastructures.
414 3.1.35 Resource
415 A secured entity which an application needs to access.
416 Note 1 to entry: A Resource is usually a Server.
417 3.1.36 Rivest-Shamir-Adleman
418 algorithm for Asymmetric Cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and Leonard
419 Adleman, see IS Glossary
420 3.1.37 Role
421 A function assumed by a Client when it accesses a Server.

6 IEC CDV 62541-2 © IEC 2023
422 Note 1 to entry: A Role may refer to a specific job function such as operator or engineer.
423 3.1.38 Scope
424 A Claim representing a subset of a Resource.
425 Note 1 to entry: A Scope may indicate a set Nodes managed by a Server.
426 3.1.39 SecurityKeyService
427 A Server that accepts AccessTokens issued by the Authorization Service and returns security keys
428 that can be used to access the specified Resource.
429 Note 1 to entry: The keys are typically used for cryptography operations such as encrypting or decrypting messages sent
430 on a PubSub stream.
431 3.1.40 Secure Channel
432 in OPC UA, a communication path established between an OPC UA Client and Server that have
433 authenticated each other using certain OPC UA services and for which security parameters have
434 been negotiated and applied
435 3.1.41 Symmetric Cryptography
436 branch of cryptography involving algorithms that use the same key for two different steps of the
437 algorithm (such as encryption and decryption, or signature creation and signature verification), see
438 IS Glossary
439 3.1.42 Symmetric Encryption
440 the mechanism used by Symmetric Cryptography for encrypting and decrypting data with a
441 cryptographic key shared by two entities
442 3.1.43 SecurityGroup
443 Publisher(s) and Subscriber(s) that utilize a shared security context
444 Note 1 to entry: This context may include share keys.
445 3.1.44 Symmetric Signature
446 the mechanism used by Symmetric Cryptography for signing data with a cryptographic key shared by
447 two entities
448 Note 1 to entry: The signature is then validated by generating the signature for the data again and comparing these two
449 signatures. If they are the same then the signature is valid, otherwise either the key or the data is different from the two
450 entities.
451 3.1.45 TrustList
452 list of Certificates that an OPC UA Application has been configured to trust
453 3.1.46 Transport Layer Security
454 standard protocol for creating Secure Channels over IP based networks
455 3.1.47
456 UnauthenticatedEncryption
457 an encryption scheme which assures confidentiality, but not authenticity
458 Note 1 to entry: UnauthenticatedEncryption algorithms are all Symmetric Encryption algorithms that are not
459 AuthenticatedEncryption algorithms.
461 3.1.48 X.509 Certificate
462 Certificate in one of the formats defined by X.509 v1, 2, or 3
463 Note 1 to entry: An X.509 Certificate contains a sequence of data items and has a Digital Signature computed on that
464 sequence. OPC UA only uses V3.
7 IEC CDV 62541-1 © IEC 2023
466 3.2 Abbreviations
467 AES Advanced Encryption Standard
468 CA Certificate Authority
469 CRL Certificate Revocation List
470 CSMS Cyber Security Management System
471 DNS Domain Name System
472 DSA Digital Signature Algorithm
473 ECDH Elliptic Curve Diffie-Hellman
474 ECDSA Elliptic Curve Digital Signature Algorithm
475 HMAC Hash-based Message Authentication Code
476 JSON JavaScript Object Notation
477 JWT JSON Web Token
478 NIST National Institute of Standard and Technology
479 PKI Public Key Infrastructure
480 RSA public key algorithm for signing or encryption, Rivest, Shamir, Adleman
481 SHA Secure Hash Algorithm (Multiple versions exist SHA1, SHA256,…)
482 SKS Security Key Server
483 SSL Secure Sockets Layer
484 TLS Transport Layer Security
485 UA Unified Architecture
486 UACP Unified Architecture Connection Protocol
487 UADP Unified Architecture Datagram Protocol
488 URI Uniform Resource Identifier
489 XML Extensible Mark-up Language
491 3.3 Conventions for security model figures
492 The figures in this document do not use any special conventions. Any conventions used in a particular
493 figure are explained for that figure.
495 4 OPC UA security architecture
496 4.1 OPC UA security environment
497 OPC UA is a protocol used between components in the operation of an industrial facility at multiple
498 levels: from high-level enterprise management to low-level direct process control of a device. The
499 use of OPC UA for enterprise management involves dealings with customers and suppliers. It may
500 be an attractive target for industrial espionage or sabotage and may also be exposed to threats
501 through untargeted malware, such as worms, circulating on public networks. Disruption of
502 communications at the process control could result in financial losses, affect employee and public
503 safety or cause environmental damage.
504 OPC UA will be deployed in a diverse range of operational environments with varying assumptions
505 about threats and accessibility, and with a variety of security policies and enforcement regimes. OPC
506 UA, therefore, provides a flexible set of security mechanisms. Figure 1 is a composite that shows a
507 combin
...