OPC UA Specification - Amendment

10001-4

 

OPC Unified Architecture

Amendment 4: ECC

 

 

Release 1.04

2020-12-18

 

 

 

 

 

 


 

Specification Type:

Industry Standard Specification

Comments:

Report or view errata: http://www.opcfoundation.org/errata

 

 

 

 

Document
Number

10001-4

 

 

Title:

OPC Unified Architecture

Amendment 4: ECC

Date:

2020-12-18

 

 

 

 

Version:

Release 1.04

Software:

MS-Word

 

 

Source:

OPC 10001-4 - UA Specification 1.04 Amendment 4 - ECC.docx

 

 

 

 

Author:

OPC Foundation

Status:

Release

 

 

 

 


 

 

OPC Foundation

____________

 

UNIFIED ARCHITECTURE –

FOREWORD

This specification is the specification for developers of OPC UA applications. The specification is a result of an analysis and design process to develop a standard interface to facilitate the development of applications by multiple vendors that shall inter-operate seamlessly together.

Copyright © 2006-2020, OPC Foundation, Inc.

AGREEMENT OF USE

COPYRIGHT RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

OPC Foundation members and non-members are prohibited from copying and redistributing this specification. All copies must be obtained on an individual basis, directly from the OPC Foundation Web site https://opcfoundation.org/.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC specifications may require use of an invention covered by patent rights. OPC shall not be responsible for identifying patents for which a license may be required by any OPC specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation,. 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830

COMPLIANCE

The OPC Foundation shall at all times be the sole entity that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of the State of Minnesota, excluding its choice or law rules.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.

ISSUE REPORTING

The OPC Foundation strives to maintain the highest quality standards for its published specifications, hence they undergo constant review and refinement. Readers are encouraged to report any issues and view any existing errata here: HTUhttp://www.opcfoundation.org/errataUTH

 


Revision 1.04 Amendment 4 Highlights

The following table includes the Mantis issues resolved by this Amendment.

Mantis ID

Summary

Resolution

3819

Add Support for ECC to UA Secure Conversation.

Added OPC 10000-6 Clause 6.8.

4650

Update UserToken discussion to support ECC.

Updated OPC 10000-4 Clauses 7.36.2 and 7.36.4.

4299

KeyCredentialManagement needs to support ECC.

Updated OPC 10000-12 Clauses 8.5.4, 8.5.5 and 8.5.6.

 

 

 

 

 


OPC Unified Architecture Specification

 

AMENDMENT 4: ECC

 

 

OPC 10000-2, OPC UA Specification: Part 2 – Security Model

Clause 3.1.38: Replace 3.1.38 with the following:

3.1.38

Rivest-Shamir-Adleman (RSA)

algorithm for Asymmetric Cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman, see IS Glossary.IS Glossary

Note 1 to entry: ‘Asymmetric Cryptography, also known as "public-key cryptography".RSA is an Asymmetric Cryptography algorithm that supports encryption and Digital Signatures.

 

Add Clauses 3.1.47 through 3.1.51:

3.1.47

Authenticated Encryption

form of encryption that ensures the integrity and confidentiality of the data.

Note 1 to entry: Authenticated Encryption with Associated Data (AEAD) is variation that includes unencrypted data which is included in the integrity check. AES-GCM and ECC are examples of Authenticated Encryption algorithms.

3.1.48

Unauthenticated Encryption

form of encryption that only ensures the confidentiality of the data.

Note 1 to entry: this term is used when it is necessary to state that encryption is not done with Authenticated Encryption. AES-CBC is an example of an Unauthenticated Encryption algorithm.

3.1.49

Diffie Hellman Key Exchange (DH)

a mechanism for negotiating a shared secret between two parties that can be used for secret communication for exchanging data over a public network.

Note 1 to entry: Elliptic Curve Cryptography (ECC) requires the use of a Diffie Hellman Key Exchange.

3.1.50

Elliptic Curve Cryptography (ECC)

an Asymmetric Cryptography method that uses a pair of keys calculated from the mathematical structure of elliptic curves over finite fields.

Note 1 to entry: Asymmetric Cryptography, also known as "public-key cryptography". ECC is a family of algorithms that only support Digital Signatures.

3.1.51

Perfect Forward Secrecy

a technique that ensures that a set of Symmetric Cryptography keys derived from a set of Private Keys will not be compromised if one of the Private Keys is compromised in the future.

Add Clause 4.2.9:

4.2.9   Perfect Forward Secrecy

The content of an encrypted Message cannot be decrypted even if the Private Keys used for the key exchange are compromised in the future.

 

Clause 4.5.2: Replace 4.5.2 with the following:

4.5.2   Client / Server

Client / Server communication can include both Session and session-less communication.

The routine work of a Client application and a Server application to transmit information, settings, and commands is done in a Session in the Application Layer. The Application Layer also manages the security objectives user Authentication and user Authorization. The security objectives that are managed by the Application Layer are addressed by the Session Services that are specified in OPC 10000-4. A Session in the Application Layer communicates over a Secure Channel that is created in the Communication Layer and relies upon it for secure communication. All of the Session data is passed to the Communication Layer for further processing.

Although a Session communicates over a Secure Channel and has to be activated before it can be used, the binding of users, Sessions, and Secure Channels is flexible.

Impersonation allows a user to take ownership of an existing Session.

If a Secure Channel breaks, the Session will remain valid for a period of time allowing the Client to re-establish the connection to the Session via a new Secure Channel. Otherwise, the Session closes after its lifetime expires.

The Communication Layer provides security mechanisms to meet Confidentiality, Integrity, and application Authentication as security objectives.  In some cases it also provides Perfect Forward Secrecy. One essential mechanism used to meet these security objectives is a Secure Channel (see 4.13) that is used to secure the communication between a Client and a Server. The Secure Channel provides encryption to maintain Confidentiality, Message Signatures to maintain Integrity and Certificates to provide application Authentication. In addition, the Secure Channel provides Perfect Forward Secrecy when the Secure Channel is used with ECC and the Diffie Hellman Key Exchange The data that comes from the Application Layer is secured before it is handed over to the Transport Layer. The security mechanisms that are managed by the Communication Layer are provided by the Secure Channel Services that are specified in OPC 10000-4.

The security mechanisms provided by the Secure Channel services are implemented by a protocol stack that is chosen for the implementation. Mappings of the services to some of the protocol stack options are specified in OPC 10000-6 which define how functions in the protocol stack are used to meet the OPC UA security objectives.

The Communication Layer can represent an OPC UA connection protocol stack. OPC UA specifies alternative stack mappings that can be used as the Communication Layer. These mappings are described in OPC 10000-6.

If the OPC UA Connection Protocol (UACP) is used, then functionality for Confidentiality, Integrity, application Authentication, and the Secure Channel are similar to the SSL/TLS specifications, as described in OPC 10000-6.

The Transport Layer handles the transmission, reception, and the transport of data that is provided by the Communication Layer.

To survive the loss of the Transport Layer connections (e.g. TCP connections) and resume with a new connection, the Communication Layer is responsible for re-establishing the Transport Layer connection without interrupting the logical Secure Channel.

The transport layer can also be used to implement Confidentiality and Integrity by using HTTPS as described in OPC 10000-6. It is important to note that HTTPS certificates can be (and often are) shared by multiple applications on a platform and that they can be compromised outside of the OPC UA usage of them. All applications on the platform that use the same shared certificate have the same settings, such as disabling of SSLv2.

OPC UA provides a session-less Service invocation (see OPC 10000-4 overview and see OPC 10000-6 for details). The session-less communication provides User Authentication. The communication channel provides Confidentiality and Integrity. The communication channel might be an OPC UA Secure channel (without a session). It might be a communication channel, such as HTTPS, which relies on transport protocols to provide security. In addition, User Authentication and/or Application Authentication can also be established by the use of an Access Token which is obtained from an AuthorizationService (see OPC 10000-6 for details).

Additional communication mappings are described in OPC 10000-6. These mappings may rely on transport protocols to provide Confidentiality and Integrity. One example is Websockets, which utilizes HTTPS transport layer security to provide Confidentiality and Integrity.

 

Clause 4.13: Replace 4.13 with the following:

4.13    OPC UA security related Services

The OPC UA Security Services are a group of abstract service definitions specified in OPC 10000-4 that are used for applying various security mechanisms to communication between OPC UA Clients and Servers.

The Discovery Service Set (specified in OPC 10000-4) defines services used by an OPC UA Client to obtain information about the security policies (see 4.6) and the Certificates of specific OPC UA Servers.

The services of the Secure Channel Service Set (specified in OPC 10000-4) are used to establish a Secure Channel which is responsible for securing Messages sent between a Client and a Server. The challenge of the Secure Channel establishment is that it requires the Client and the Server to securely exchange cryptographic keys and secret information in an insecure environment, therefore a specific Key Exchange Algorithm (similar to TLS Handshake protocol defined in TLS) is applied by the communication participants.

Once established, a Secure Channel uses Symmetric Cryptography keys to encrypt and sign all Messages. Symmetric Cryptography requires a shared key.  Asymmetric Cryptography is used to create this shared key.

The OPC UA Client retrieves the SecurityPolicies and Certificates of the OPC UA Server by the previously mentioned discovery services. These Certificates contain the Public Keys of the OPC UA Server.

For RSA the following sequence is used:

For ECC the following sequence is used:

Once Clients and Servers have the same set of cryptographic keys, they can communicate securely with each other.

These shared cryptographic keys are changed periodically so that attackers do not have unlimited time and unrestricted sequences of Messages to use to determine what the keys are.

For PubSub communications, the security related definitions are specified in OPC 10000-14 and provide a description of how to secure messages and also how to obtain the security keys required for message security.

The Publisher will utilize the keys provided to secure the Message. It will encrypt the body of the Message and sign the entire message. Subscribers will utilize the keys to decrypt and verify the Signature of the Messages.

To obtain the required keys, the Publisher or Subscriber make use of ClientServer communication. The keys may also be obtained using session-less method calls.


OPC 10000-4, OPC UA Specification: Part 4 – Services

Add Clause 3.1.13:

3.1.13

EphemeralKey

A public-private key pair generated for each execution of a key establishment process.

Note 1 to entry: EphemeralKeys are necessary when using ECC based SecurityPolicies.

 

Clause 7.36.2.3: Replace 7.36.2.3 with the following:

7.36.2.3        EncryptedSecret Format

The EncryptedSecret uses an extensible format which has the TypeId of a DataType Node as a prefix as defined for the ExtensionObject encoding in OPC 10000-6. The general layout of the EncryptedSecret is shown in Figure 39.

Figure 39 – EncryptedSecret Layout

The TypeId specifies how the EncryptedSecret is serialized and secured. For example, the RsaEncryptedSecret requires that the KeyData be encrypted with the public key associated with the EncryptingCertificate before it is serialized.

The SecurityPolicyUri is used to determine what algorithms were used to encrypt and sign the data. Valid SecurityPolicyUris are defined in OPC 10000-7.

The payload is always encrypted using the symmetric encryption algorithm specified by the SecurityPolicyUri. The KeyData is used to create the keys used needed for the symmetric encryption. The structure of the KeyData depends on the EncryptedSecret DataType. 

The EncryptedSecret is secured and serialized as follows:

•     Serialize the common header;

•     Serialize the KeyData;

•     If required, encrypt the KeyData and append the result to the common header;

•     Update the KeyDataLength with the length of the encrypted KeyData;

•     Append the Nonce and the Secret to the encrypted KeyData;

•     Calculate padding required on the payload and append after the Secret;

•     Encrypt the payload;

•     Calculate a Signature;

•     Append the Signature.

 

Individual fields are serialized using the UA Binary encoding (see OPC 10000-6) for the DataType specified in Table 182. The Padding is used to ensure there is enough data to fill an integer multiple of encryption blocks. The size of the encryption block depends on the encryption algorithm. The total length of the Padding, not including the PaddingSize, is encoded as a UInt16. The individual bytes of the Padding are set to the the least significant byte of the PaddingSize.

The EncryptedSecret is deserilized and validated as follows:

•     Deserialize the common header;

•     Verify the Signature if the KeyData is not encrypted;

•     Decrypt the KeyData and verify the Signature if the KeyData is encrypted;

•     Decrypt the payload;

•     Verify the padding on the payload;

•     Extract the Secret;

 

The fields in the EncryptedSecret are described in Table 182. The first three fields TypeId, EncodingMask and Length belong to the ExtensionObject encoding defined in OPC 10000-6.

Table 182 – EncryptedSecret Layout

Name

Type

Description

TypeId

NodeId

The NodeId of the DataType Node.

EncodingMask

Byte

This value is always 1.

Length

Int32

The length of the data that follows including the Signature.

SecurityPolicyUri

String

The URI for the SecurityPolicy used to apply security.

Certificate

ByteString

The signing and/or encrypting Certificate.

SigningTime

DateTime

When the Signature was created.

KeyDataLength

UInt16

The length, in bytes, of the KeyData that follows

If the KeyData is encrypted this is the length of the encrypted data;

Otherwise, it is the length of the unencrypted data;

KeyData

Byte [*]

The key data used to create the keys needed for decrypting and verifying the payload. Each EncryptedSecret DataType describes how the key data is structured for different SecurityPolicies.

Nonce

ByteString

This is the last serverNonce returned in the CreateSession or ActivateSession Response when a UserIdentityToken is passed with the ActivateSession Request.

If used outside of an ActivateSession call, the Nonce is created by the sender and is a function of the SecureChannelNonceLength.

Secret

ByteString

The secret to protect.

The password when used with UserNameIdentityTokens.

The tokenData when used with IssuedIdentityTokens.

If the Secret is a String is it encoded using UTF-8 first.

PayloadPadding

Byte [*]

Additional padding added to ensure the size of the encrypted payload is an integer multiple of the input block size for the symmetric encryption algorithm specified by the SecurityPolicyUri.

The value of each byte is the least significant byte of the PayloadPaddingSize.

PayloadPaddingSize

UInt16

The size of the padding added to the payload.

Signature

Byte [*]

The Signature calculated after all encryption is applied.

Each EncryptedSecret DataType describes how the Signature is calculated for different SecurityPolicies.

 

The PayloadPaddingSize adjusted with the following formula:

If (Secret.Length + PayloadPaddingSize < InputBlockSize) Then

PayloadPaddingSize = PayloadPaddingSize + InputBlockSize

Where the InputBlockSize is specified by the SymmetricEncryptionAlgorithm.

The currently available EncryptedSecret DataTypes are defined in Table 183.

Table 183 – EncryptedSecret DataTypes

Type Name

When to Use

RsaEncryptedSecret

Used when the SecurityPolicy requires the use of RSA cryptography.
It is described in 7.36.2.4.

EccEncryptedSecret

Used when the SecurityPolicy requires the use of ECC cryptography.
It is described in 7.36.2.5.

 

Clause 7.36.2.4: Replace 7.36.2.4 with the following:

7.36.2.4        RsaEncryptedSecret DataType

The RsaEncryptedSecret uses RSA based Asymmetric Cryptography.

Additional semantics for the fields in the EncryptedSecret layout for the RsaEncryptedSecret Structure are described in Table 184.

Table 184 – RsaEncryptedSecret Structure

Name

Type

Description

TypeId

NodeId

The NodeId of the RsaEncryptedSecret DataType Node.

EncodingMask

Byte

See Table 182.

Length

UInt32

See Table 182.

SecurityPolicyUri

String

See Table 182.

Certificate

ByteString

The CertificateDigest the Certificate used to encrypt the KeyData.

SigningTime

DateTime

See Table 182.

KeyDataLength

UInt16

The length, in bytes, of the encrypted KeyData.

KeyData

 

The KeyData is encrypted with the PublicKey associated with the Certificate.

    SigningKey

ByteString

The key used to compute the Signature.

    EncryptingKey

ByteString

The key used to encrypt payload.

    InitializationVector

ByteString

The initialization vector used with the EncryptingKey.

Nonce

ByteString

A Nonce. This is the last ServerNonce returned in the CreateSession or ActivateSession Response when proving a UserIdentityToken passed in the ActivateSession Request. In other contexts, this is a Nonce created by the sender with a length equal to the SecureChannelNonceLength.

Secret

ByteString

See Table 182.

PayloadPadding

Byte [*]

See Table 182.

PayloadPaddingSize

UInt16

See Table 182.

Signature

Byte [*]

The Signature calculated with the SigningKey.

The Signature calculated is calculated after encrypting the KeyData and the payload.

 

Add Clause 7.36.2.5:

7.36.2.5        EccEncryptedSecret DataType

The EccEncryptedSecret uses ECC based Asymmetric Cryptography.

Additional semantics for the fields in the EncryptedSecret layout for the EccEncryptedSecret Structure are described in Table 184a.

The EccEncryptedSecret uses ECC EphemeralKeys to create the symmetric key used to encrypt the Secret. The handshake required to create and use the EphemeralKeys is described in OPC 10000-6.

Table 184a – EccEncryptedSecret Layout

Name

Type

Description

TypeId

NodeId

The NodeId of the EccEncryptedSecret DataType Node.

EncodingMask

Byte

See Table 182.

Length

UInt32

See Table 182.

SecurityPolicyUri

String

See Table 182.

Certificate

ByteString

The signing Certificate encoded in DER form.

The value shall include the entire chain specified in OPC 10000-6.

This value may be omitted if the SigningCertificate is known to the receiver. This is true if the structure is used to provide a UserIdentityToken to a Server over a SecureChannel and the SigningCertificate is the Client ApplicationInstance Certificate.

SigningTime

DateTime

See Table 182.

KeyDataLength

UInt16

The length of the KeyData without encryption.

KeyData

 

The KeyData is not encrypted.

    SenderPublicKey

ByteString

The Public Key for the EphemeralKey created by the sender.

    ReceiverPublicKey

ByteString

The Public Key for the EphemeralKey created by the receiver.

Nonce

ByteString

A Nonce. This is the last ServerNonce returned in the CreateSession or ActivateSession Response when proving a UserIdentityToken passed in the ActivateSession Request. In other contexts, this is a Nonce created by the sender with a length equal to the ½ of the SecureChannelNonceLength.

Secret

ByteString

See Table 182.

PayloadPadding

Byte [*]

See Table 182.

PayloadPaddingSize

UInt16

See Table 182.

Signature

Byte [*]

The Signature calculated with the PrivateKey of the signing Certificate.

The Signature calculated is calculated after encrypting the payload.

 

Clause 7.36.4: Replace 7.36.4 with the following:

7.36.4 UserNameIdentityToken

The UserNameIdentityToken is used to pass simple username/password credentials to the Server.

This token shall be encrypted by the Client if required by the SecurityPolicy of the UserTokenPolicy. The Server should specify a SecurityPolicy for the UserTokenPolicy if the SecureChannel has a SecurityPolicy of None and no transport layer encryption is available. If None is specified for the UserTokenPolicy and SecurityPolicy is None then the password only contains the UTF-8 encoded password. The SecurityPolicy of the SecureChannel is used if no SecurityPolicy is specified in the UserTokenPolicy.

If the token is to be encrypted the password shall be converted to a UTF-8 ByteString, encrypted and then serialized according to the rules for the SecurityPolicy. When using an RSA based SecurityPolicy the password is encrypted and serialized as shown in Table 181. When using the ECC based SecurityPolicies the password is encrypted and serialized as described in 7.36.2.3.

The Server shall decrypt the password and verify the ServerNonce.

If the SecurityPolicy is None then the password only contains the UTF-8 encoded password. This configuration should not be used unless the network traffic is encrypted in some other manner such as a VPN. The use of this configuration without network encryption would result in a serious security fault, in that it would cause the appearance of a secure user access, but it would make the password visible in clear text.

Table 186 defines the UserNameIdentityToken parameter.

Table 186 – UserNameIdentityToken

Name

Type

Description

UserNameIdentityToken

Structure

UserName value.

    policyId

String

An identifier for the UserTokenPolicy that the token conforms to.

The UserTokenPolicy structure is defined in 7.37

    userName

String

A string that identifies the user.

    password

ByteString

The password for the user. The password can be an empty string.

The format used for the encrypted data is described in 7.36.2.2.

    encryptionAlgorithm

String

A string containing the URI of the AsymmetricEncryptionAlgorithm.

The URI string values are defined names that may be used as part of the security profiles specified in OPC 10000-7.

This parameter is null if the password is not encrypted.

This parameter is only used for RSA based SecurityPolicies. It is null if not used.

 

Table 187 describes the dependencies for selecting the AsymmetricEncryptionAlgorithm for the UserNameIdentityToken. The SecureChannel SecurityPolicy URI is specified in the EndpointDescription and used in subsequent OpenSecureChannel requests. The UserTokenPolicy SecurityPolicy URI is specified in the EndpointDescription. The encryptionAlgorithm is specified in the UserNameIdentityToken or IssuedIdentityToken provided by the Client in the ActivateSession call. The SecurityPolicy “Other” in the table refers to any SecurityPolicy other than None. The selection of the EncryptionAlgorithm is based on the UserTokenPolicy. The SecureChannel SecurityPolicy is used if the UserTokenPolicy is null or empty.

Table 187 – EncryptionAlgorithm selection

SecureChannel SecurityPolicy

UserTokenPolicy SecurityPolicy

UserIdentityToken EncryptionAlgorithm

Security Policy - None

Null or empty

No encryption

Security Policy - None

Security Policy - None

No encryption

Security Policy - None

Security Policy - Other

Asymmetric algorithm for "Other"

Security Policy - Other

Null or empty

Asymmetric algorithm for "Other"

Security Policy - Other

Security Policy - Yet another

Asymmetric algorithm for "Yet another"

Security Policy - Other

Security Policy - Other

Asymmetric algorithm for "Other"

Security Policy - Other

Security Policy - None

No encryption

 

Add Clause 7.40

7.40    AdditionalParametersType

The AdditionalParametersType parameter is the value of the additionalHeader field of the RequestHeader and ResponseHeader parameters. It allows Clients and Servers to pass additional named parameters with Service requests or responses. These named parameters may be defined by the OPC UA specification, a companion specification or be specific to a vendor implementation. The name is a QualifiedName which allows the same name to be used in different contexts. The value is a Variant which allows Structures to be passed in addition to basic types such as Strings.

Note that the calls to CreateSession/ActivateSession are made before the Client can read the Server’s current NamespaceArray. This means that only names with a NamespaceIndex of 0 or 1 may be used in the requests for these Services. Companion specifications and vendors can define names in for use with NamespaceIndex 1 if they add prefix that ensures uniqueness. The same restriction applies to values which contain DataTypes with NamespaceIndexes

The components of this structure are defined in Table 192a.

Table 192a – AdditionalParametersType

Name

Type

Description

AdditionalParametersType

Structure

Specifies a list of value qualified by a name.

    parameters

KeyValuePair []

A list of headers identified by a QualifiedName.

The KeyValuePair type is defined in OPC 10000-5.

 

Add Clause 7.41

7.41    EphemeralKeyType

The EphemeralKeyType parameter is used to return an ECC EphemeralKey needed to provide encrypted data back to the owner of the key. See OPC 10000-6 for a discussion of ECC EphemeralKeys. The EphemeralKey is created based on an ECC named curve specified by a SecurityPolicy. The SecurityPolicy to use depends on the context in which this parameter is used.

The components of this structure are defined in Table 192b.

Table 192b – EphemeralKeyType

Name

Type

Description

EphemeralKeyType

Structure

Specifies an ECC ephemeral Public Key and a signature created by the application that owns the associated Private Key.

    publicKey

ByteString

The Public Key associated with an EphemeralKey created by the sender.

It is encoded according to the rules for the ECC SecurityPolicies (see OPC 10000-7).

The size of the Public Key is specified by the current SecurityPolicyUri.

    signature

ByteString

The Signature calculated using the ApplicationInstance Certificate of the owner of the Private Key associated with the Public Key.

The value of the Public Key field is the data used to calculate the Signature.

The SecurityPolicyUri used to generate the EphemeralKey is the SecurityPolicyUri used to calculate the signature.

 




 

OPC 10000-6, OPC UA Specification: Part 6 – Mappings

Clause 6.7.2.1: Replace with the following:

6.7.2.1 Overview

The structure of the Message depends on whether the SecurityPolicy requires an algorithm that combines encryption and authentication (e.g. Authenticated Encryption algorithms) used or if it requires separate algorithms for each operation (Unauthenticated Encryption algorithms).

Figure 11 shows the structure of a MessageChunk and how security is applied to the Message when using Unauthenticated Encryption algorithms. For these SecurityPolicies any padding is appended to the message before appending the Signature.

Figure 11 – MessageChunk for Unauthenticated Encryption Algorithms

Figure 11a shows the structure of a MessageChunk and how security is applied to the Message when using Authenticated Encryption algorithms. For these SecurityPolicies the Signature is calculated during encryption and appended after the encrypted data. Padding is not needed.

Figure 11a – MessageChunk for Authenticated Encryption Algorithms

 

Clause 6.7.2.5: Replace with the following:

6.7.2.5 Message Footer

6.7.2.5.1 Unauthenticated Encryption Algorithms

Each MessageChunk when using SecurityPolicies with an Unauthenticated Encryption algorithms have a footer with the fields defined in Table 45.

Table 45 – Message Footer for Unauthenticated Encryption Algorithms

Name

Data Type

Description

PaddingSize

Byte

The number of padding bytes (not including the byte for the PaddingSize).

Padding

Byte [*]

Padding added to the end of the Message to ensure length of the data to encrypt is an integer multiple of the encryption block size.

The value of each byte of the padding is equal to PaddingSize.

ExtraPaddingSize

Byte

The most significant byte of a two-byte integer used to specify the padding size when the key used to encrypt the message chunk is larger than 2 048 bits. This field is omitted if the key length is less than or equal to 2 048 bits.

Signature

Byte [*]

The signature for the MessageChunk.

The signature includes the all headers, all Message data, the PaddingSize and the Padding.

 

The formula to calculate the amount of padding depends on the amount of data that needs to be sent (called BytesToWrite). The sender shall first calculate the maximum amount of space available in the MessageChunk (called MaxBodySize) using the following formula:

MaxBodySize = PlainTextBlockSize * Floor ((MessageChunkSize
                                         – MessageHeaderSize
                                         - SecurityHeaderSize
                                         – SignatureSize - 1)/CipherTextBlockSize) – SequenceHeaderSize;

The MessageHeaderSize is 12 bytes and the SecurityHeader size depends on whether symmetric or asymmetric cryptography is used. The SequenceHeaderSize is always 8 bytes.

During encryption a block with a size equal to PlainTextBlockSize is processed to produce a block with size equal to CipherTextBlockSize. These values depend on the encryption algorithm and may be the same.

The OPC UA Message can fit into a single chunk if BytesToWrite is less than or equal to the MaxBodySize. In this case the PaddingSize is calculated with this formula:

PaddingSize = PlainTextBlockSize –

((BytesToWrite + SignatureSize + 1) % PlainTextBlockSize);

If the BytesToWrite is greater than MaxBodySize the sender shall write MaxBodySize bytes with a PaddingSize of 0. The remaining BytesToWriteMaxBodySize bytes shall be sent in subsequent MessageChunks.

The PaddingSize and Padding fields are not present if the MessageChunk is not encrypted.

The Signature field is not present if the MessageChunk is not signed.

6.7.2.5.2    Authenticated Encryption Algorithms

Each MessageChunk when using SecurityPolicies with an Authenticated Encryption algorithms have a footer with the fields defined in Table 45a.

Table 45a – Message Footer for Authenticated Encryption Algorithms

Name

Data Type

Description

Signature

Byte [*]

The signature for the MessageChunk.

The signature includes the all headers, all Message data, the PaddingSize and the Padding.

 

Add Clause 6.8

6.8 Elliptic Curve Cryptography (ECC)

6.8.2    Secure Channel Handshake

The OPC UA Secure Conversation (UASC) mechanism described 6.7 is designed for use with asymmetric cryptography algorithms, such as RSA, that allow Public Keys to be used for encryption and for digital signatures. ECC is an asymmetric cryptography algorithm that only supports digital signatures. To accommodate algorithms like ECC, the UASC handshake needs to be modified to allow negotiation of inputs used for key derivation in 6.7.5 without making the keys available to eavesdroppers. This negotiation uses a Diffie Hellman algorithm defined in and is shown in Figure 11b.

Figure 11b – ECC Key Negotiation

ApplicationInstance Certificates for ECC have a public-private key pair that are used to create and verify a digital signature. To negotiate the keys needed for the SecureChannel the Client generates a new key pair (JC, KC) and passes the Public Key (JC) in the request. After verifying the signature on the request, the Server generates a new key pair (JS, KS) and returns the Public Key (JS) in the response. The new key pairs are used each time a SecureChannel is negotiated and they are called EphemeralKeys.

ECC public-private key pairs are always based on a specific elliptic curve function which is used for the ECC calculations. Many curves exist, however, ECC cryptography libraries support a finite set of “named curves” to allow for better interoperability. Each OPC UA SecurityPolicy defined in OPC 10000-7 specifies exactly one named curve which is used for the EphemeralKeys.

Each ECC ApplicationInstance Certificate is also based on a named curve. Each SecurityPolicy specifies a list of named curves which are permitted for use in the ApplicationInstance Certificate. This list always includes the named curved used for the EphemeralKey, however, it may allow other named curves. OPC UA applications that support ECC SecurityPolicies will need to support multiple ApplicationInstance Certificates.  

ECC Public Keys and digital signatures are the output of an ECC operation. The encoding of these outputs depends on the ECC curve and are described by the SecurityPolicy in OPC 10000-7.

Clause 6.7.4 specifies the contents of the OpenSecureChannel request and response messages. When using an ECC SecurityPolicy the ClientNonce is the Public Key for the Client’s EphemeralKey encoded using the Public Key encoding for the curve. Similarly, the ServerNonce is the Public Key for the Server’s EphemeralKey.

The EphemeralKeys are used to calculate a shared secret by using the Private Key of an EphemeralKey and the Public Key of the peer’s EphemeralKey. The exact algorithm to calculate the shared secret depends on the ECC curve and is defined by the SecurityPolicy. This shared secret is then used to derive key data using the following algorithm from RFC 5869. Note that the algorithm is repeated here for clarity, however, the RFC is the normative source.

Step 1: Calculate Salts

   ServerSalt = L | UTF8(opcua-server) | ServerNonce | ClientNonce
   ClientSalt = L | UTF8(opcua-client) | ClientNonce | ServerNonce 

Where

·      L is the length of derived key material needed encoded as a 16-bit little endian integer;

·      UTF8(label) is the UTF8 encoding of the string literal ‘label’;

·      ServerNonce is the Server EphemeralKey from the OpenSecureChannel response;

·      ClientNonce is the Client EphemeralKey from the OpenSecureChannel request;

·      | concatenates sequences of bytes;

·      Salt is a sequence of bytes.

 

Step 2: Extract

   PRK = HMAC-Hash(Salt, IKM)
 

Where

·      HMAC uses a Hash function specified by the KeyDerivationAlgorithm;

·      IKM is the x-coordinate of the shared secret;

·      Salt is calculated in Step 1;

·      PRK is a pseudorandom output with length equal to the Hash size.

 

Step 3: Expand

   N = ceil(L/HashLen)
   T = T(1) | T(2) | T(3) | ... | T(N)
   OKM = first L octets of T
 
   where:
   T(0) = empty string (zero length)
   T(1) = HMAC-Hash(PRK, T(0) | Info | 0x01)
   T(2) = HMAC-Hash(PRK, T(1) | Info | 0x02)
   T(3) = HMAC-Hash(PRK, T(2) | Info | 0x03)
   ...
 

Where

·      HMAC uses a Hash function specified by the KeyDerivationAlgorithm;

·      PRK is the output from Step 1;

·      Info is a sequence of bytes;

·      L is the length of keying material needed;

·      0x01 is the number 1 encoded as a byte.

·      OKM is the output with length equal to L bytes.

 

The client keys are extracted from the keying material created with IKM=shared secret, Salt=ClientSalt and Info=ClientSalt as shown in Table 49a.

Table 49a – Deriving Client Keys from Keying Material

Name

Offset

Length

ClientSigningKey

0

DerivedSignatureKeyLength

ClientEncryptingKey

DerivedSignatureKeyLength

EncryptionKeyLength

ClientInitializationVector

DerivedSignatureKeyLength + EncryptionKeyLength

IntializationVectorLength

 

The server keys are extracted from the keying material created with IKM=shared secret, Salt= ServerSalt and Info=ServerSalt as shown in Table 49b.

Table 49b – Deriving Server Keys from Keying Material

Name

Offset

Length

ServerSigningKey

0

DerivedSignatureKeyLength

ServerEncryptingKey

DerivedSignatureKeyLength

EncryptionKeyLength

ServerInitializationVector

DerivedSignatureKeyLength + EncryptionKeyLength

IntializationVectorLength

 

The SymmetricEncryptionAlgorithm for the SecurityPolicy sets the EncryptionKeyLength and EncryptionBlockSize.

When using Authenticated Encryption, the SigningKey and EncryptingKey are always calculated, however, only one will be used. If the mode is SignAndEncrypt then the EncryptingKey is used. If the mode is SignOnly then the SigningKey is used.

In addition, a unique InitializationVector is needed for each Message. This value contructed from the ClientInitializationVector or ServerInitializationVector where the first 8 bytes are replaced by the values in Table 49c.

Table 49c – Creating a Mask for the Initialization Vector

Name

Bytes

Length

TokenId

4

The TokenId specified in the SecurityHeader of MessageChunk being processed.

It is encoded as a UInt32 as described in 5.2.2.2.

LastSequenceNumber

4

The SequenceNumber specified in the SequenceHeader of last MessageChunk sent in the same direction on the SecureChannel.

This number is 0 for the first message.

It is encoded as a UInt32 as described in 5.2.2.2.

The ClientInitializationVector is used when the Client encrypts or signs and the ServerInitializationVector is used when the Server encrypts or signs.

The LastSequenceNumber is the SequenceNumber from the previously sent Message which normally requires the previous Message to be decrypted. If the receiver processes incoming Messages in parallel it can calculate the expected SequenceNumber based on the order in which the encrypted Messages are received.

When using SignOnly mode it is necessary to have a SigningKey that is unique and unpredictable for each message. The transformation defined for the InitializationVector is applied to the ClientSigningKey (when the Client signs) or the ServerSigningKey (when the Server signs). After applying the transformation, a hash is computed using the Hash function specified by the KeyDerivationAlgorithm. If the hash length is greater than or equal to the SigningKey length then the first SigningKey length bytes from the hash are used. If the hash length is less than the SigningKey length then the first hash length bytes of the SigningKey are replaced with the hash.

Once the keys are derived ECC SecureChannels behave the same as RSA SecureChannels.

6.8.3    UserIdentityToken Encryption

ActivateSession allows a Client to provide an encrypted UserIdentityToken using a SecurityPolicy specified by a UserTokenPolicy supported by the current Endpoint. With ECC, encryption requires that the Client and Server exchange EphemeralKeys and there is no mechanism in the current CreateSession/ActivateSession handshake to do this. For that reason, EphemeralKeys are returned in the AdditionalHeader field of the ResponseHeader of the CreateSession and ActivateSession responses. An overview of the handshake is shown in Figure 11c.

Figure 11c – ECC CreateSession/ActivateSession Handshake

The UserTokenPolicies are returned in the GetEndpoints response. A UserTokenPolicy may specify a SecurityPolicyUri that is different than the SecureChannel, however, all UserTokenPolicies in an EndpointDescription shall specify a SecurityPolicyUri that is valid for all Certificates that are valid for SecurityPolicyUri specified in the EndpointDescription. For example, an EndpointDescription providing an ECC SecurityPolicyUri shall not specify RSA SecurityPolicyUris in the UserTokenPolicies.

When a Client calls CreateSession via a SecureChannel based on an ECC SecurityPolicy the Client specifies the SecurityPolicyUri it plans to use for the UserIdentityToken in the RequestHeader. Server returns an EphemeralKey in the ResponseHeader that can be used for the SecurityPolicyUri specified by the Client. If the SecurityPolicyUri is not valid the Server returns a StatusCode in the ResponseHeader instead of an EphemeralKey.

When the Client calls ActivateSession it creates an EccEncryptedSecret (see OPC 10000-4) using the EphemeralKey provided in CreateSession response. The Server always returns a new EphemeralKey in the ResponseHeader which the Client saves for when it calls ActivateSession again. The SecurityPolicyUri passed in CreateSession is used to determine what type of EphemeralKey to return.

The EphemeralKeys may be used for exactly one key negotiation. After that they are discarded. Each time ActivateSession is called the UserIdentityToken is encrypted using the last EphemeralKey returned by the Server. The EphemeralKey is changed even if the Client did not provide an encrypted UserIdentityToken.

If the Client does not provide SecurityPolicyUri in the call to CreateSession it will not be able to use any UserIdentityTokens that require encryption with ECC SecurityProfiles.

OPC 10000-4 defines AdditionalParametersType which is a list of name-value pairs. An instance of this type is passed in the AdditionalHeader field. Instances of the EphemeralKeyType defined in  OPC 10000-4 are passed as values in the name-value pair list in the response messages. The names used for the parameters defined for the CreateSession/ActivateSession exchange are defined in Table 49d.

Table 49d – Additional Header Key Names

Name

DataType

Description

ECDHEPolicyUri

String

Specifies the SecurityPolicyUri used for the EphemeralKeys.

ECDHEKey

EphemeralKeyType

Specifies an EphemeralKey.

If the EphemeralKey could not be created a StatusCode indicating the reason for the error is used instead of an instance of EphemeralKeyType.

 

6.8.4    ECC Encrypted Secret

OPC 10000-4 defines the layout of EccEncryptedSecret structure which is used to protect secrets with ECC SecurityPolicies. Applying security with ECC requires two EphemeralKeys generated by the sender and the receiver which are used create the symmetric keys need for encryption.

6.8.2 defines a mechanism to allows the sender to acquire the receiver EphemeralKey when using a Session. Using the EccEncryptedSecret in other contexts requires a different mechanism.

Once the sender has the receiver EphemeralKey, it creates its own EphemeralKey. The ECC curve and key length for the EphemeralKeys are specified by the SecurityPolicyUri.

The encryption uses the symmetric encryption algorithm specified by the SecurityPolicyUri. The encrypting key and initialization vector are generated by using the EphemeralKeys to create the shared secret and then derive keys using the algorithm defined in 6.8.2. Step 1 is slightly different and defined as follows:

Step 1: Calculate Salt

  SecretSalt = L | UTF8(opcua-secret) | SenderPublicKey | ReceiverPublicKey

Where

·      L is the length of derived key material needed encoded as a 16-bit little endian integer;

·      UTF8(opcua-secret) is the UTF8 encoding of the string literal ‘opcua-secret’;

·      SenderPublicKey and ReceiverPublicKey are from the PolicyHeader;

·      | concatenates sequences of bytes;

·      Salt is a sequence of bytes.

The encryption keys are extracted from the keying material created with IKM=shared secret, Salt=SecretSalt and Info=SecretSalt as shown in Table 49e.

Table 49e – Deriving Keys from Keying Material

Name

Offset

Length

EncryptingKey

0

EncryptionKeyLength

InitializationVector

EncryptionKeyLength

EncryptionBlockSize

The EncryptionKeyLength and EncryptionBlockSize are specified by the Symmetric Encryption Algorithm for the SecurityPolicy. The Signature is created with the SigningCertificate and is calculated after encryption. Receivers shall validate the SigningCertificate and signature before decrypting the Secret.


 

OPC 10000-7, OPC UA Specification: Part 7 – Profiles

Clause 5.3: Append the following rows to Table 11.

5.3  Transport and communication related features

 

Table 11 – Security

Title

Description

AsymmetricSignatureAlgorithm_ECDSA-SHA2-256

CertificateSignatureAlgorithm_ECDSA-SHA2-256

ECC digital signature algorithm described in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.

The hash algorithm is SHA2 with 256 bits and is described in http://tools.ietf.org/html/rfc6234.

AsymmetricSignatureAlgorithm_ECDSA-SHA2-384

CertificateSignatureAlgorithm_ECDSA-SHA2-384

ECC digital signature algorithm described in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.

The hash algorithm is SHA2 with 384 bits and is described in http://tools.ietf.org/html/rfc6234.

AsymmetricSignatureAlgorithm_PureEdDSA-25519

CertificateSignatureAlgorithm_ PureEdDSA-25519

ECC digital signature algorithm Ed25519 described in

http://tools.ietf.org/html/rfc8032.

AsymmetricSignatureAlgorithm_PureEdDSA-448

CertificateSignatureAlgorithm_PureEdDSA-448

ECC digital signature algorithm Ed448 described in

http://tools.ietf.org/html/rfc8032.

EphemeralKeyAlgorithm_ECC-nistP256

The P-256 curve described in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros. Signatures and keys are 64 bytes.

The ECDHE shared secret is calculated according to RFC8422.

CertificateKeyAlgorithm_ECC-nistP256

The P-256 or P-384 curve described in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros. Signatures and keys are 64 bytes or 96 bytes.

The ECDHE shared secret is calculated according to RFC8422.

EphemeralKeyAlgorithm_ECC-nistP384

CertificateKeyAlgorithm_ECC-nistP384

The P-384 curve described in http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros. Signatures and keys are 96 bytes.

The ECDHE shared secret is calculated according to RFC8422.

EphemeralKeyAlgorithm_ECC-brainpoolP256r1

The non-twisted 256 bit curve described in http://www.faqs.org/rfcs/rfc5639.html.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros.

Signatures and keys are 64 bytes.

The ECDHE shared secret is calculated according to RFC8422.

CertificateKeyAlgorithm_ECC-brainpoolP256r1

The non-twisted 256 or 384 bit curve described in http://www.faqs.org/rfcs/rfc5639.html.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros.

Signatures and keys are 64 bytes or 96 bytes.

The ECDHE shared secret is calculated according to RFC8422.

EphemeralKeyAlgorithm_ECC-brainpoolP384r1

CertificateKeyAlgorithm_ECC-brainpoolP384r1

The non-twisted 384 bit curve described in http://www.faqs.org/rfcs/rfc5639.html.

ECC public key compression is not used.

ECC coordinates are encoded as big endian integers padded with zeros.

Signatures and keys are 96 bytes.

The ECDHE shared secret is calculated according to RFC8422.

EphemeralKeyAlgorithm_ECC-curve25519

CertificateKeyAlgorithm_ECC-curve25519

Curve25519 described in

http://tools.ietf.org/html/rfc7748.

ECC public keys are a single coordinate.

ECC coordinates are encoded as little endian integers padded with zeros.

Signatures are 64 bytes and keys are 32 bytes.

The ECDHE shared secret is calculated according to http://tools.ietf.org/html/rfc7748.

EphemeralKeyAlgorithm_ECC-curve448

CertificateKeyAlgorithm_ECC-curve448

Curve448 described in

http://tools.ietf.org/html/rfc7748.

ECC public keys are a single coordinate.

ECC coordinates are encoded as little endian integers padded with zeros.

Signatures are 114 bytes, EphemeralKeys are 56 bytes and the public key in Certificates is 57 bytes.

The ECDHE shared secret is calculated according to http://tools.ietf.org/html/rfc7748.

KeyDerivationAlgorithm_HKDF-SHA2-256

The HKDF psuedo-random function defined in

http://tools.ietf.org/html/rfc5869.

The hash algorithm is SHA2 with 256 bits and is described in http://tools.ietf.org/html/rfc6234.

KeyDerivationAlgorithm_HKDF-SHA2-384

The HKDF psuedo-random function defined in

http://tools.ietf.org/html/rfc5869

The hash algorithm is SHA2 with 384 bits and is described in http://tools.ietf.org/html/rfc6234.

SymmetricSignatureAlgorithm_HMAC-SHA2-384

A keyed hash used for message authentication which is defined in https://tools.ietf.org/html/rfc2104.
The hash algorithm is SHA2 with 384 bits and described in https://tools.ietf.org/html/rfc4634

SymmetricEncryptionAlgorithm_ChaCha20Poly1305

A symmetric authenticated encryption algorithm defined in

https://tools.ietf.org/html/rfc7539

SymmetricSignatureAlgorithm_Poly1305

An algorithm to create a message authentication code defined in

https://tools.ietf.org/html/rfc7539

ECC-nistP256_Limits

DerivedSignatureKeyLength = 256

EncryptionKeyLength=256

InitializationVectorLength=128

SignatureLength=256

MinAsymmetricKeyLength = 256 (ECC)

MaxAsymmetricKeyLength = 384 (ECC)

SecureChannelNonceLength = 64

ECC-nistP384_Limits

DerivedSignatureKeyLength = 384

EncryptionKeyLength=256

InitializationVectorLength=128

SignatureLength=384

MinAsymmetricKeyLength = 384 (ECC)

MaxAsymmetricKeyLength = 384 (ECC)

SecureChannelNonceLength = 96

ECC-brainpoolP256r1_Limits

DerivedSignatureKeyLength = 256

EncryptionKeyLength=256

InitializationVectorLength=128

SignatureLength=256

MinAsymmetricKeyLength = 256 (ECC)

MaxAsymmetricKeyLength = 384 (ECC)

SecureChannelNonceLength = 64

ECC-brainpoolP384r1_Limits

DerivedSignatureKeyLength = 384

EncryptionKeyLength=256

InitializationVectorLength=128

SignatureLength=384

MinAsymmetricKeyLength = 384 (ECC)

MaxAsymmetricKeyLength = 384 (ECC)

SecureChannelNonceLength = 96

ECC-curve25519_Limits

DerivedSignatureKeyLength = 256

EncryptionKeyLength=256

InitializationVectorLength=96

SignatureLength=128

MinAsymmetricKeyLength = 256 (ECC)

MaxAsymmetricKeyLength = 256 (ECC)

SecureChannelNonceLength = 32

ECC-curve448_Limits

DerivedSignatureKeyLength = 256

EncryptionKeyLength=256

InitializationVectorLength=96

SignatureLength=128

MinAsymmetricKeyLength = 456 (ECC)

MaxAsymmetricKeyLength = 456 (ECC)

SecureChannelNonceLength = 56

 

Clauses 6.6.164, 6.6.165, 6.6.166: Append the following rows to the RSA profiles defined in Tables 184, 185 and 186. 

Title

Description

CertificateKeyAlgorithm_RSA

The RSA algorithm described in http://www.faqs.org/rfcs/rfc3447.html.

EphemeralKeyAlgorithm_None

No EphemeralKeys are used.

 

Clause 6.2: Append the following rows to Table 23.

6.2 Profile list

Profile

Related Category

URI

SecurityPolicy – ECC-nistP256

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP256

SecurityPolicy – ECC-nistP384

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP384

SecurityPolicy – ECC-brainpoolP256r1

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP256r1

SecurityPolicy – ECC-brainpoolP384r1

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP384r1

SecurityPolicy – ECC-curve25519

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_curve25519

SecurityPolicy – ECC-curve448

Security

http://opcfoundation.org/UA/SecurityPolicy#ECC_curve448

 

Add Clauses 6.8.187 through 6.8.192

6.6.187         SecurityPolicy - ECC-nistP256

Table 206a defines an ECC based security policy for configurations with average security needs. It is equivalent to the Aes128-Sha256-RsaOaep policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

NIST curves are widely implemented and offer good performance.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. NIST provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206a – SecurityPolicy – ECC-nistP256

Group

Conformance Unit / Profile Title

Optional

Security

ECC-nistP256_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_ECDSA-SHA2-256

False

Security

CertificateSignatureAlgorithm_ECDSA-SHA2-256

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-256

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_AES128-CBC

False

Security

SymmetricSignatureAlgorithm_HMAC-SHA2-256

False

Security

EphemeralKeyAlgorithm_ECC-nistP256

False

Security

CertificateKeyAlgorithm_ECC-nistP256

False

 

6.6.188         SecurityPolicy – ECC-nistP384

Table 206b defines an ECC based security policy for configurations with very high security needs. It is equivalent to the Aes256-Sha256-RsaPss policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

NIST curves are widely implemented and offer good performance.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. NIST provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206b – SecurityPolicy – ECC-nistP384

Group

Conformance Unit / Profile Title

Optional

Security

ECC-nistP384_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_ECDSA-SHA2-384

False

Security

CertificateSignatureAlgorithm_ECDSA-SHA2-384

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-384

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_AES256-CBC

False

Security

SymmetricSignatureAlgorithm_HMAC-SHA2-384

False

Security

EphemeralKeyAlgorithm_ECC-nistP384

False

Security

CertificateKeyAlgorithm_ECC-nistP384

False

 

6.6.189         SecurityPolicy - ECC-brainpoolP256r1

Table 206c.defines an ECC based security policy for configurations with average security needs. It is equivalent to the  Aes128-Sha256-RsaOaep policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

Brainpool curves are widely implemented, however, offer mediocre performance. They are needed for applications that have explicity prohibited the use of NIST curves.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. NIST provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206c – SecurityPolicy – ECC-brainpoolP256r1

Group

Conformance Unit / Profile Title

Optional

Security

ECC-brainpoolP256r1_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_ECDSA-SHA2-256

False

Security

CertificateSignatureAlgorithm_ECDSA-SHA2-256

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-256

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_AES128-CBC

False

Security

SymmetricSignatureAlgorithm_HMAC-SHA2-256

False

Security

EphemeralKeyAlgorithm_ECC-brainpoolP256r1

False

Security

CertificateKeyAlgorithm_ECC-brainpoolP256r1

False

 

6.6.190          SecurityPolicy – ECC-brainpoolP384r1

Table 206d defines an ECC based security policy for configurations with very high security needs. It is equivalent to the Aes256-Sha256-RsaPss policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

Brainpool curves are widely implemented, however, offer mediocre performance. They are needed for applications that have explicity prohibited the use of NIST curves.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. BRAINPOOL provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206d – SecurityPolicy – ECC-brainpoolP384r1

Group

Conformance Unit / Profile Title

Optional

Security

ECC-brainpoolP384r1_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_ECDSA-SHA2-384

False

Security

CertificateSignatureAlgorithm_ECDSA-SHA2-384

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-384

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_AES256-CBC

False

Security

SymmetricSignatureAlgorithm_HMAC-SHA2-384

False

Security

EphemeralKeyAlgorithm_ECC-brainpoolP384r1

False

Security

CertificateKeyAlgorithm_ECC-brainpoolP384r1

False

 

6.6.191          SecurityPolicy - ECC-curve25519

Table 206e.defines an ECC based security policy for configurations with average security needs. It is equivalent to the Aes128-Sha256-RsaOaep policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

Edward’s curves (Curve25519 and Curve448) are not as widely implemented as some other curves, however, they offer the best performance. They are well suited for embedded applications where CPU cycles are a premium. The number of implementations will increase over time which will eventually make this curve the best choice.

This security Facet specifies ChaCha20-Poly1305 as the symmetric encryption algorithm. This algorithm offers improved performance by combining encryption and authentication into a single algorithm.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. NIST provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206e – SecurityPolicy – ECC-curve25519

Group

Conformance Unit / Profile Title

Optional

Security

ChaChaPoly-Sha256-curve25519_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_PureEdDSA-25519

False

Security

CertificateSignatureAlgorithm_PureEdDSA-25519

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-256

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_ChaCha20Poly1305

False

Security

SymmetricSignatureAlgorithm_Poly1305

False

Security

EphemeralKeyAlgorithm_ECC-curve25519

False

Security

CertificateKeyAlgorithm_ECC-curve25519

False

 

6.6.192         SecurityPolicy – ECC-curve448

This security Facet defines an ECC based security policy for configurations with very high security needs. It is equivalent to the Aes256-Sha256-RsaPss policy, however, the key sizes are much smaller and therefore better suited for embedded systems.

Edward’s curves (Curve25519 and Curve448) offer the best performance. They are well suited for embedded applications where CPU cycles are a premium. The number of implementations will increase over time which will eventually make this curve the best choice.

This security Facet specifies ChaCha20-Poly1305 as the symmetric encryption algorithm. This algorithm offers improved performance by combining encryption and authentication into a single algorithm.

This facet requires a PKI infrastructure. As computing power increases, security policies are expected to expire. NIST provides guidelines for expected expiration dates for individual algorithms. These guidelines provide recommended dates at which the algorithm should be replaced or upgraded to a more secure algorithm. They do not indicate a failure of the algorithm. This security policy has no published end dates as of this time.

Table 206f – SecurityPolicy – ECC-curve448

Group

Conformance Unit / Profile Title

Optional

Security

ECC-curve448_Limits

False

Security

AsymmetricEncryptionAlgorithm_None

False

Security

AsymmetricSignatureAlgorithm_PureEdDSA-448

False

Security

CertificateSignatureAlgorithm_PureEdDSA-448

False

Security

KeyDerivationAlgorithm_HKDF-SHA2-256

False

Security

Security Certificate Validation

False

Security

Security Encryption Required

False

Security

Security Signing Required

False

Security

SymmetricEncryptionAlgorithm_ChaCha20Poly1305

False

Security

SymmetricSignatureAlgorithm_Poly1305

False

Security

EphemeralKeyAlgorithm_ECC-curve448

False

Security

CertificateKeyAlgorithm_ECC-curve448

False

 


 

OPC-10000-12, OPC UA Specification: Part 12 – Discovery

Add Clauses 7.4.19 through 7.4.25.

7.4.19 EccApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC Public Key. Applications which support the ECC profiles (see OPC 10000-7) shall have a Certificate of this type. This type is defined in Table 29a.

Table 29a – EccApplicationCertificateType Definition

Attribute

Value

BrowseName

EccApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the ApplicationCertificateType defined in 7.4.12.

 

7.4.20 EccNistP256ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC nistP256 Public Key. Applications which support the ECC NIST P256 curve profiles (see OPC 10000-7)  shall have a Certificate of this type or a Certificate of the  EccNistP384ApplicationCertificateType defined in 7.4.21. This type is defined in Table 29b.

Table 29b – EccNistP256ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccNistP256ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

7.4.21 EccNistP384ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC nistP384 Public Key. Applications which support the ECC NIST P384 curve profiles (see OPC 10000-7)  shall have a Certificate of this type. This type is defined in Table 29c.

Table 29c – EccNistP384ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccNistP384ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

7.4.22 EccBrainpoolP256r1ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC brainpoolP256r1 Public Key. Applications which support the ECC brainpoolP256r1 curve profiles (see OPC 10000-7)  shall have a Certificate of this type or a Certificate of the EccBrainpoolP384r1ApplicationCertificateType defined in 7.5.23. This type is defined in Table 29d.

Table 29d – EccBrainpoolP256r1ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccBrainpoolP256r1ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

7.4.23 EccBrainpoolP384r1ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC brainpoolP384r1 Public Key. Applications which support the ECC brainpoolP384r1 curve profiles (see OPC 10000-7)  shall have a Certificate of this type. This type is defined in Table 29e.

Table 29e – EccBrainpoolP384r1ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccBrainpoolP384r1ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

7.4.24 EccCurve25519ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC curve25519 Public Key. Applications which support the ECC curve25519 curve profiles (see OPC 10000-7)  shall have a Certificate of this type. This type is defined in Table 29f.

Table 29f – EccCurve25519ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccCurve25519ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

7.4.25 EccCurve448ApplicationCertificateType

This type is used to describe Certificates intended for use as an ApplicationInstanceCertificate. They shall have an ECC curve448 Public Key. Applications which support the ECC curve448 curve profiles (see OPC 10000-7)  shall have a Certificate of this type. This type is defined in Table 29g.

Table 29g – EccCurve448ApplicationCertificateType Definition

Attribute

Value

BrowseName

EccCurve448ApplicationCertificateType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the EccApplicationCertificateType defined in 7.4.17.

 

Replace Clauses 8.5.7 through 8.5.9

8.5.7    KeyCredentialConfigurationType

This ObjectType is the TypeDefinition for an Object that allows the configuration of KeyCredentials used by the Server. It also includes basic status information which report problems accessing the resource that might be related to bad KeyCredentials. It is defined in Table 60a.

Table 60a – KeyCredentialConfigurationType Definition

Attribute

Value

BrowseName

KeyCredentialConfigurationType

Namespace

CORE (see 3.3)

IsAbstract

False

References

NodeClass

BrowseName

DataType

TypeDefinition

Modelling Rule

Subtype of the BaseObjectType defined in OPC 10000-5.

HasProperty

Variable

ResourceUri

String

PropertyType

Mandatory

HasProperty

Variable

ProfileUri

String

PropertyType

Mandatory

HasProperty

Variable

EndpointUrls

String[]

PropertyType

Optional

HasProperty

Variable

ServiceStatus

StatusCode

PropertyType

Optional

HasComponent

Method

GetEncryptingKey

 

Defined in 8.5.4.

Optional

HasComponent

Method

UpdateCredential

 

Defined in 8.5.5.

Optional

HasComponent

Method

DeleteCredential

 

Defined in 8.5.6.

Optional

The ResourceUri Property uniquely identifies the resource that accepts the KeyCredentials.

The ProfileUri Property specifies the protocol used to access the resource.

The EndpointUrls Property specifies the URLs that the Server uses to access the resource.

The ServiceStatus Property indicates the result of the last attempt to communicate with the resource. The following common error values are defined:

ServiceStatus

Description

Bad_OutOfService

Communication was not attempted by the Server because Enabled is FALSE.

Bad_IdentityTokenRejected

Communication failed because the KeyCredentials are not valid.

Bad_NoCommunication

Communication failed because the endpoint is not reachable.

Where possible a more specific error code should be used.

See OPC 10000-4 for a complete list of standard StatusCodes.

 

The GetEncryptingKey Method is used request a Public Key that can be used to encrypt the KeyCredentials.

The UpdateKeyCredential Method is used to change the KeyCredentials used by the Server.

The DeleteKeyCredential Method is used to delete the KeyCredentials stored by the Server.

8.5.8    GetEncryptingKey

GetEncryptingKey is used to request a key that can be used to encrypt a KeyCredential.

This Method requires an encrypted channel and that the Client provides credentials with administrative rights on the Server.

Signature

GetEncryptingKey(

      [in]  String     credentialId,

      [in]  String     requestedSecurityPolicyUri,

      [out] ByteString publicKey,

      [out] String     revisedSecurityPolicyUri

     );

  

Argument

Description

credentialId

The unique identifier associated with the KeyCredential.

requestedSecurityPolicyUri

The SecurityPolicy used to encrypt the secret.

If not specified the Server chooses a suitable default.

publicKey

The Public Key used to encrypt the secret.

The format depends on the SecurityPolicyUri.

revisedSecurityPolicyUri

The SecurityPolicy used to encrypt the secret.

It also specifies the contents of the publicKey.

This may be different from the requestedSecurityPolicyUri.

 

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidArgument

The credentialId is not valid.

Bad_UserAccessDenied

The current user does not have the rights required.

 

Table 60b specifies the AddressSpace representation for the GetEncryptingKey Method.

Table 60b – GetEncryptingKey Method AddressSpace Definition

Attribute

Value

BrowseName

GetEncryptingKey

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

HasProperty

Variable

OutputArguments

Argument[]

PropertyType

Mandatory

 

8.5.9    UpdateCredential

UpdateCredential is used to update a KeyCredential used by a Server.

The KeyCredential secret may be encrypted with the public key returned by GetEncryptingKey. The SecurityPolicyUri species the algorithm used for encryption. The format of the encrypted data is described in 8.4.5.

This Method requires an encrypted channel and that the Client provides credentials with administrative rights on the Server.

Signature

UpdateCredential(

      [in] String     credentialId,

      [in] ByteString credentialSecret,

      [in] String     certificateThumbprint,

      [in] String     securityPolicyUri

     );

  

Argument

Description

credentialId

The unique identifier associated with the KeyCredential.

credentialSecret

The secret associated with the KeyCredential.

certificateThumbprint

The thumbprint of the Certificate used to encrypt the secret.

For RSA SecurityPolicies this shall be one of the Application Instance Certificates assigned to the Server. For ECC SecurityPolicies this field is not specified.Not specified if the secret is not encrypted.

securityPolicyUri

The SecurityPolicy used to encrypt the secret.

If not specified the secret is not encrypted.

 

Method Result Codes (defined in Call Service)

Result Code

Description

Bad_InvalidArgument

The credentialId or credentialSecret is not valid.

Bad_CertificateInvalid

The Certificate is invalid or it is not one of the Server’s Certificates.

Bad_SecurityPolicyRejected

The SecurityPolicy is unrecognized or not allowed.

Bad_UserAccessDenied

The current user does not have the rights required.

 

Table 60c specifies the AddressSpace representation for the UpdateKeyCredential Method.

Table 60c – UpdateCredential Method AddressSpace Definition

Attribute

Value

BrowseName

UpdateCredential

References

NodeClass

BrowseName

DataType

TypeDefinition

ModellingRule

HasProperty

Variable

InputArguments

Argument[]

PropertyType

Mandatory

____________