Abstract
Introduction
Industrial Internet of Things (IIoT) is a network of field devices, actuator, and intelligent computers that collect and share huge amounts of data in manufacturing. Connectivity is one of the foundational technologies enabling data sharing among participating components of an IIoT system. As a connectivity framework standard, OPC Unified Architecture (OPC UA) facing device interchangeability issues has been used in the manufacturing industry. OPC UA is designed to support multiple transports and can provide a consistent and complete address space and service model, which contains a series of services. The OPC Foundation 1 maintains the OPC UA family of specifications.
The openness of IIoT incurs more threats and risks, and security issues have become the main obstacle to the development of IIoT. In order to ensure the confidentiality, integrity, and availability between client and server, OPC UA specification provides a security framework for the secure and reliable transmission from manufacturing level to production planning or enterprise management level. 2 However, IIoT system components run on a variety of platforms, from small resource-constrained to enterprise-class machines. It is challenging to develop light security mechanism to support the devices being used, in which the computing capability and storage capacity are limited. For the security, it is urgent to design and implement an effective authentication and key agreement mechanism for resource-constrained devices based on OPC UA.
Several previous studies have been conducted on this issue. S Cavalieri and G Cutuli 3 aimed to deal with the performance evaluation of OPC UA, considering both security and subscription mechanisms. A Fernbach and W Kastner 4 aimed to give a discussion about how the structure of the environmental system where OPC UA applications are installed, the resources available, and a request to dependability shall affect the strategy of managing certificates, which provided a theoretical basis for the optimization of OPC UA security mechanism. O Post et al.5,6 discussed the security at device level of automation system and implemented a new authentication-only security policy profile or using OPC UA for data transfer and IPsec for authentication is proposed. KH Wu et al. 7 proposed a new security communication model to provide integrity and authentication in OPC UA; through this model that uses the Whirlpool hash function to check integrity and generates digital signature along with Rivest–Shamir–Adleman (RSA) in message transmission, terminals in the upper layer can communicate with field devices via a channel with high security and efficiency. Given the security of RSA, the key length needs to be increased to enhance the security strength of RSA. 8 It may limit the application of RSA in the system with limited computing capability. Several studies have been conducted on implicit certificates. S Sciancalepore and colleagues9,10 proposed a key management protocol which suitably integrates implicit certificates with Elliptic Curve Diffie–Hellman (ECDH) exchange in the IEEE 802.15.4 protocol. Park 11 proposed an ECQV certificate issuance protocol that addresses the problems of the previous PAuthKey protocol. DA Ha et al. 12 designed and implemented a security scheme based on ECQV Implicit Certificates and compared the execution time of public key extraction operation with the RSA certificates.
At present, with the rapid development of IIoT, a large number of resource-constrained devices with limited communication, energy, and bandwidth are used. According to the security model of OPC UA, it is the key of solving problem to design and implement a low overhead authentication and key agreement mechanism. In this article, according to the security model defined by the OPC UA specification, a new authentication and key agreement mechanism based on implicit certificate is designed for authentication requirements between OPC UA client and server.
OPC UA security mechanism
OPC UA divides system software into clients and servers. The servers usually reside on a device; they provide a way to access the device through a standard “device model.” The servers expose an object-oriented, remotely callable Application Programming Interface (API) that implements the device model. Certificate authority (CA) is responsible for issuing digital certificates for OPC UA clients and servers.
OPC UA security model is proposed in the OPC UA specification part 2. 13 In order to implement the OPC UA security model, five security service functions are provided in the OPC UA security specification, which are related to the security channel and the session.
The establishment of secure channel is the basis of OPC UA security mechanism. The purpose of secure channel establishment is to derive a symmetric key by exchanging private information between OPC UA client and server. Only the connection between the client and the server is established; the message transmission, encryption, and decryption works will be executed. The specific process of establishing a secure channel is shown in Figure 1.

The process of establishing a secure channel.
RSA algorithm is used for signing or encryption in OPC UA. However, a large number of numerical operations using RSA algorithm are needed in the process of calculation of encryption, decryption, signature, and verifying signature. In addition, OPC UA relies on the Public Key Infrastructure (PKI) to manage keys used for symmetric and asymmetric encryption, which requires complex certificate management, high computing, and storage overhead. It is difficult to be implemented and used in the resource-constrained and highly real-time environment.
Security authentication and key agreement mechanism
Authentication and key agreement mechanism based on implicit certificate
In this article, an authentication and key agreement scheme-based implicit certificate is proposed, which consists of two parts: the generation of implicit certificate and the establishment of secure channel. The symbols used in this scheme are described in Table 1.
Symbols.
UA: Unified Architecture; RSA: Rivest–Shamir–Adleman.
The generation of implicit certificate
The generation process of implicit certificate is similar to digital certificates. First of all, OPC UA client or server generates the material used to construct the public key and transfers the public key material and the identity information ID to the CA. Then, CA begins to verify the identity information ID; if the verification is successful, the next operation is performed, otherwise the interaction is terminated. According to the public key material, CA constructs an implicit certificate which contains the parameters to reconstruct the public key. The specific process is shown in Figure 2, which includes three steps:
CA generates a random number According to the implicit certificate factor, an implicit certificate is constructed, Calculate the abstract value of implicit certificate
Finally, CA generates a response message for an implicit certificate, which is sent to requestor U.
Private key:
Public key:

The issuance process of implicit certificate.
Establishment of secure channel
An authentication and key agreement scheme based on implicit certificate is proposed in this section. It ensures OPC UA secure channel can be successfully established. It is assumed that the OPC UA client is A and the server is B in IIoT. The specific scheme is shown in Figure 3, which includes four steps:
OPC UA client A reads the endpoint information of OPC UA server B by GetEndpoints request service. Not required if OPC UA client A is preconfigured with knowledge of server policies.
After OPC UA server B receives the GetEndpoints request service, the security configuration information is sent to OPC UA client A by GetEndpoints response service. The security configuration information includes server certificate, security mode, and security policy.
In the two-way authentication step, the process includes calculating temporary public key and validating integrity check codes for both sides:
Calculate temporary public key
After OPC UA client A receives the GetEndpoints response service, OPC UA client A generates a random number R1. Moreover, the temporary public key of OPC UA client A is calculated as shown in formula (1)
According to hash function, an integrity check code is calculated,
Validate
After OPC UA server B receives the message
If
where
A random number
Validate
After OPC UA client A receives the message
If
where
A random number
Validate
After OPC UA server B receives the message
If
where
Validate
After OPC UA server B receives the message
If
OPC UA server’s public key is extracted according to the implicit certificate
where
Whereafter,
If the two-way authentication is completed, a symmetric key that can be used for message encryption or signature in the session service can be derived based on ECDH key exchange protocol, as shown in formula (11)

The process of secure channel establishment.
Scheme testing and result analysis
Testing platform implementation
In order to verify the authentication and key agreement scheme which has been designed and developed in this article, the testing platform is built, as shown in Figure 4.

The testing platform.
For the purpose of performance evaluation, we run the implementation of the proposed scheme in the following platform: RT5350 device (360 MHz MIPS24KEc CPU core, 32 MB RAM), CA runs on a resource-rich computer with Intel® Core(5) Quad CPU Q9400 2.6 GHz and 4 GB RAM, and implicit certificate application client run on a resource-rich computer with Intel Core(3) Quad CPU Q9400 1.8 GHz and 2 GB RAM. PC plays the role of OPC UA client and RT5350 plays the role of OPC UA server. Wireshark is used to sniff the interaction message between OPC UA client and server. OPC UA stack includes OpenSSL 14 library that provide the API of many algorithms.
The proposed scheme adopts ECC (Elliptic Curve Diffie–Hellman) 160 algorithm. The hash algorithm is implemented by invoking the SHA-1 using the OpenSSL library [OpenSSL 2014] on PC. And we use our own software to implement HASH SHA-1 on RT5350 device.
According to the testing platform, the authentication and key agreement scheme designed in this article is implemented.
This scheme mainly contains the following:
GetEndpoints request service and GetEndpoints response service.
Two-way authentication between OPC UA client and server.
The purpose of the test is to make sure that this authentication and key agreement scheme works in accordance with the design process. GetEndpoints request message information, GetEndpoints response message information, and four authentication messages are captured by Wireshark capture tool. The result is shown in Figure 5.

(a) The message information of GetEndpoints request, (b) the message information of GetEndpoints response, (c) first authentication message information, (d) second authentication message information, (e) third authentication message information, and (f) fourth authentication message information.
GetEndpoints request service is implemented correctly according to Figure 5(a); GetEndpoints response service is also implemented correctly according to Figure 5(b); similarly, two-way authentication service is implemented correctly according to Figure 5(c)–(f).
Result analysis
In order to evaluate the authentication and key agreement scheme, some performance indices are chosen, which are classified into security and effectiveness according to Fan and Lu 15 and Yang et al. 16 The security performance indices include forward security, known key security, non-key control, zero knowledge of interaction information, and the ability to resist attacks; the effectiveness performance indices include computing overhead, communication overhead, and storage overhead. Next, this scheme will be discussed in terms of security and effectiveness.
The security analysis
This scheme ensures that IIoT has the forward security, the known key security, the zero knowledge of interaction information, and the non-key control ability; meanwhile, this scheme can resist the attack of the middleman attack, replay attack, and so on.
In this scheme, different random values are used in each key agreement process, such as temporary public key
Even though attackers know last session key, owing to the change in temporary public key
Meanwhile, the attacker is unable to calculate the symmetric key by these interaction information. Thus, this scheme has zero knowledge of interaction information. The symmetric key generation depends on the temporary public key of OPC UA client A and server B, long-term public keys
The middleman attack is the biggest security vulnerability of the ECDH key exchange protocol, and the reason is lack of the identity authentication of the participants. In this scheme, if communication parties want to establish communication, the identity authentication must be performed. In the process of identity authentication and key agreement, some private parameters are used, such as random numbers
The effectiveness analysis
The performance analysis of authentication and key agreement scheme based on implicit certificate mainly consists of three parts: computation overhead, communication overhead, and storage overhead. Furthermore, this article also increases the comparison with other schemes.
Computational overhead analysis
First of all, the computational overhead of this scheme is compared with OPC UA scheme. The theoretical comparison result is shown in Table 2.
Computational overhead comparison result.
UA: Unified Architecture.
As can be seen from Table 2, the computational overhead is the sum of 4E
Second, the actual computational cost of OPC UA server is also tested using the testing platform (see Figure 4). The main function of the scheme is to establish a secure channel, that is to say, the execution time of the program can be used to quantify the computational complexity of secure channel establishment. Therefore, time point
Similarly, the computational overhead for the IoT device to establish secure channel can be obtained as shown in Figure 6.

The comparison results of computational overhead.
The computational overhead cost is 310 ms when the security policy is chosen as Basic 256. The time cost of this proposed scheme is 390 ms using this ECC 160. In comparison, this proposed scheme computational overhead is higher than the Basic 256 security policy. As shown in Table 3, in Ha et al., 12 which is implemented in Beaglebone black revision C boards (1 GHz ARM Cortex-A8, 512 MB RAM), the time that is needed for the IoT device using ECDH-ECQV to finish secure key establishment phase is 49.964 ms, and the time for DHE-RSA is 827.463 ms. Therefore, the handshake overhead of the proposed scheme is better than DHE-RSA and worse than the ECDH-ECQV in Ha et al. 12
Scheme description.
However, the security strength of ECC 160 is better than the Basic 256 security policy, and the key with 1024 bits length is no longer security for RSA algorithm.17,18 Meanwhile, the IIoT devices rarely need to perform this phase. Therefore, the proposed scheme is still a valid replacement for the scheme from OPC UA even though more computational overhead is costly. We will consider the ECDH-ECQV and other possible algorithms to be introduced in OPC UA and compare the work with them in same platform in the future.
Storage overhead analysis
First of all, the storage overhead of this scheme is compared with original OPC UA scheme. The theoretical storage overhead of OPC UA server mainly considers some security material discussed in this above section. The theoretical comparison result is shown in Table 4.
Storage overhead comparison result.
UA: Unified Architecture.
As can be seen from Table 4, the storage overhead of OPC UA server is about 66 bytes in this scheme; the storage overhead of original OPC UA server is about (384+
Second, the actual storage overhead of OPC UA server is also tested using the testing platform (see Figure 4). The actual storage overhead mainly refers to the comparison of the code storage in two cases including the security mechanism and without the security mechanism. The specific testing process is as follows:
Compile the OPC UA protocol stack without the security mechanism to view code storage.
Compile the OPC UA protocol stack including the security mechanism to view code storage.
Compare the results from (1) and (2).
As shown in Figure 7, the code storage without the security mechanism is 468.5 kB, and the code storage with this scheme is 481.2 kB. The implementation for this proposed scheme based on implicit certificates requires 12.7 kB of ROM, whereas the protocol based on implicit certificates 9 requires 12.240 kB of ROM, and the protocol implementation based on X.509 explicit certificates 9 for benchmarking purposes uses 15.192 kB of ROM. The overhead in ROM for the proposed scheme is acceptable.
Communication overhead analysis

The storage overhead analysis result.
The communication overhead of OPC UA server mainly comes from the message interaction in the authentication phase. Under the condition of security level 80, that is, the key length of ECC is 160 bits, the key length of RSA is 1024 bits. The communication overhead of the two schemes is compared as shown in Table 5.
Communication overhead comparison result.
UA: Unified Architecture.
As can be seen from Table 5, the communication overhead of OPC UA server is about 166 bytes in this scheme; the communication overhead of OPC UA server is about 512 bytes in original OPC UA security scheme. In summary, compared with the OPC UA scheme, this scheme has better performance. The actual communication overhead of OPC UA server is also tested using the testing platform (see Figure 4). The specific testing process is as follows:
When OPC UA protocol is not added to this scheme, the message information sent by OPC UA server is counted by Wireshark.
When OPC UA protocol is added to this scheme, the message information sent by OPC UA server is counted by Wireshark.
Compare the results from (1) and (2).
As can be seen from Figure 8, the communication overhead of this scheme is less than the communication overhead of OPC UA scheme in the GetEndpoints phase and authentication phase.
Comparison analysis with other schemes

The communication overhead analysis result.
In order to verify adequately the feasibility and superiority of this scheme, the scheme is also compared with other schemes. In terms of performance, the comparison result is shown in Table 6.
Scheme comparison result.
As can be seen from Table 6, comparing with Hafizul Islam and Biswas, 19 twice hash and point addition operations are reduced in this scheme and one time scalar multiplication operation is added; as a whole, there is little difference in performance between this scheme and Hafizul Islam and Biswas. 19 Comparing with Yang, 20 one time hash operation is reduced in this scheme. Comparing with Liao and Hsiao, 21 one time point addition operation is added, but one time hash and three times scalar multiplication operations are reduced in this scheme. In summary, comparing with other schemes, this scheme has better performance.
In terms of security, Hafizul Islam and Biswas 19 and Liao and Hsiao 21 do not support two-way authentication. And there is little difference in security between this scheme and Yang. 20
Conclusion and future work
In order to guarantee the security of IIoT especially for the resource-constrained environment, an authentication and key agreement mechanism based on implicit certificate is proposed based on OPC UA security model in this article. The implicit certificate is based on ECC cryptosystem. In the process of establishing secure channel, the lightweight ECC encryption algorithm is adopted to ensure the security of data transmission in the communication process. The mechanism is implemented and the test platform shows that this mechanism could be used in resource-constrained environments. In the future work, in order to further validate the feasibility of this scheme in resource-constrained environments, this scheme will be tested in practical applications. Currently, there are some studies on key agreement and authentication mechanism for constrained device in the IEEE 802.15.4 protocol stack.10,11 Some device based on IEEE 802.15.4 supporting OPC UA has been implemented in our laboratory. The proposed scheme will be considered and additional implementation will be added in platform (such as STM32F103) in the future.
