Internet DRAFT - draft-wei-ace-opc-ua-security

draft-wei-ace-opc-ua-security



ACE Working Group                                               M. Wei
Internet Draft                                               QQ. Huang
Intended status: Standards Track                                SY. Li
Expires: July 20, 2017                                         P. Wang
                                                             SD. Zhang
                                               Chongqing University of
                                          Posts and Telecommunications
                                                      January 16, 2017


      The consideration of OPC UA security in constrained environments
                     draft-wei-ace-opc-ua-security-00


Abstract

   OPC Unified Architecture (OPC UA) is a communication protocol for
   industrial automation developed by the OPC Foundation. Compared with
   OPC, OPC UA provides a complete set of security mechanisms to ensure
   data confidentiality, data integrity and data availability. With the
   development of industrial internet of things, more and more nodes
   are expected to be implemented OPC UA, which are resource
   constrained. This draft discusses OPC UA security mechanisms and the
   applicability in a constrained environment. An outline of a
   lightweight security mechanism for OPC UA using in constrained
   device is proposed.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 20, 2017.



Wei, et al.             Expires July 20, 2017                 [Page 1]

 Internet-Draft            ACE OPC UA security             January 2017


Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction ...................................................2
      1.1. Requirements Notation......................................3
      1.2. Terms Used ................................................3
   2. OPC UA security model...........................................3
   3. The security requirements of OPC UA in constrained environments.5
   4. A lightweight security mechanism for OPC UA ....................6
   5. Security Considerations.........................................7
   6. IANA Considerations ............................................7
   7. References .....................................................7
      7.1. Normative References.......................................7
      7.2. Informative References ....................................7

1. Introduction

   With the development of industrialization and information technology,
   the requirement of information sharing is more and more intense in
   industrial automation system. However, there are generally a number
   of equipments from different manufacturers and different information
   exchange standards in the industrial automation system. It is
   difficult to achieve interconnection of information. The problem of
   "Information Island" is easy to cause. In order to achieve cross
   network and platform communication, OPC foundation proposes an OPC
   communication protocol. OPC Unified Architecture (OPC UA) [IEC62541]
   is proposed, which provide a path forward from the original OPC
   communications model (namely, the Microsoft Windows only process
   exchange COM/DCOM) to a cross-platform service-oriented architecture
   (SOA) for process control, while enhancing security and providing an
   information model.




Wei, et al.             Expires July 20, 2017                 [Page 2]

 Internet-Draft            ACE OPC UA security             January 2017


   Multi-platform may implement OPC UA, including portable ANSI C, Java
   and .NET implementations. With the development of industrial
   internet of things (IIoT), more and more constrained nodes are
   expected to be implemented OPC UA in IIoT. The application of OPC UA
   security mechanisms in constrained environment need to be evaluated.
   OPC UA Security consists of authentication, authorization, encryption
   and data integrity via signatures. The authentication uses X.509
   certificates exclusively. It relies on the application developer to
   choose which certificate store the UA application. For instance, it
   is possible to use the public key infrastructure (PKI) of an Active
   Directory, which is a challenge for the constrained IIoT field
   device.

   This draft analyses and evaluates the overhead of OPC UA security
   mechanisms. An outline of a lightweight security mechanism for OPC
   UA using in constrained device is proposed.

1.1. Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2. Terms Used

   Readers are required to be familiar with the terms and concepts
   defined in [RFC4949], including "authentication", "authorization",
   "confidentiality", "integrity", "availability" ,"message
   authentication code", "verify", etc.

   Terminology for constrained environments including "constrained
   network", "constrained node", "class 1", etc. is defined in
   [RFC7228].

   Implicit certificate: It is a variant of digital certificate, such
   that a public key can be reconstructed from any implicit certificate,
   and is said then to be implicitly verified, in the sense that the
   only party who can know the associated private key is the party
   identified in the implicit certificate.

2. OPC UA security model

   OPC UA security model include three layers: application layer,
   communication layer and transport layer, as shown in Figure 1. These
   security layers cover essential data security objectives such as
   integrity, confidentiality, availability, authorization and
   authentication. OPC UA is the application layer protocol of OSI


Wei, et al.             Expires July 20, 2017                 [Page 3]

 Internet-Draft            ACE OPC UA security             January 2017


   model, but the mentioned security layers are different from the OSI
   model layers.

  +---------------------------+           +---------------------------+
  |       OPC UA Client       |           |       OPC UA Server       |
  | +-----------------------+ |           | +-----------------------+ |
  | |   Application Layer   | |           | |   Application Layer   | |
  | | +-------------------+ | |           | | +-------------------+ | |
  | | |User Authentication| | <--Session--> | |User Authentication| | |
  | | |User Authorization | | |           | | |User Authorization | | |
  | | +-------------------+ | |           | | +-------------------+ | |
  | +-----------------------+ |           | +-----------------------+ |
  |                           |           |                           |
  | +-----------------------+ |           | +-----------------------+ |
  | |   Communication Layer | |           | |   Communication Layer | |
  | | +-------------------+ | |           | | +-------------------+ | |
  | | | App Authentication| | |   Secure  | | | App Authentication| | |
  | | | App Authorization | | <--Channel--> | | App Authorization | | |
  | | |   Confidentiality | | |           | | |   Confidentiality | | |
  | | |      Integrity    | | |           | | |      Integrity    | | |
  | | +-------------------+ | |           | | +-------------------+ | |
  | +-----------------------+ |           | +-----------------------+ |
  |                           |           |                           |
  | +-----------------------+ |           | +-----------------------+ |
  | |    Transport Layer    | |           | |    Transport Layer    | |
  | | +-------------------+ | |   Socket  | | +-------------------+ | |
  | | |   Availability    | | <-Connection->| |   Availability    | | |
  | | +-------------------+ | |           | | +-------------------+ | |
  | +-----------------------+ |           | +-----------------------+ |
  +---------------------------+           +---------------------------+
                     Figure 1. OPC UA security mode

   In Figure 1, in the application layer, the session provides user
   authentication and authorization by using a logical connection
   between OPC UA server and OPC UA client. User authentication can be
   achieved by username/password, digital certificates or WS-Security
   token. The authorization for authenticated user depends on the
   implementation of the OPC UA server by each manufacturer.

   The communication layer provides confidentiality, integrity and
   application authentication. The secure channel is built to ensure
   real-time data exchanged in security between OPC UA client and OPC
   UA server in a session. In order to obtain application
   authentication, the communication layer can use encryption, digital
   signature and security digital certificate.



Wei, et al.             Expires July 20, 2017                 [Page 4]

 Internet-Draft            ACE OPC UA security             January 2017


   The transport layer uses socket connection, here, error recovery
   techniques are used to maintain the availability of services in
   transport layer. Therefore, system accessibility is enhanced.

3. The security requirements of OPC UA in constrained environments

   The security requirements of OPC UA will be analyzed from the
   following three aspects.

   Firstly, the implementation of OPC UA security is based on
   traditional public key infrastructure (PKI) technology. However, PKI
   requires high computation and storage overhead, furthermore, digital
   certificates management is complex. For constrained node, the
   storage of certificates and certificate revocation lists increase
   the storage cost, and the application and revocation of certificates
   increase the communication cost. When opening a secure channel, the
   certificate is verified by local or remote certification authorities
   (CAs). In e-commerce environment, it is very common that a waiting
   time of 5-10s until the Web server hosting a Web shop has validated
   the certificate of the customer. However, the waiting time 5-10s is
   a very long interval for industrial devices located at the field
   level of the automation pyramid. Industrial applications are
   featured by many applications, which must be connected to a server
   for short period of time; furthermore, these applications must
   access to the server when needed without any delays.

   Secondly, the security policies in the OPC UA specification (such as
   Basic128Rsa15 and Basic256Sha256) are based on RSA public key
   algorithm. The algorithm is realized by the large prime
   decomposition problem, which involves a large number of exponential
   power operations and modulo operations. It has a large number of
   complex operations, which will seriously affect the real-time
   requirements of IIoT. Furthermore, the security strength of RSA
   public key algorithm is guaranteed by the key length. The current
   technology has been able to decipher 512 bits RSA key in the
   effective time. Considering the security of the system, the RSA key
   length must be increased. However, with the increase of RSA key
   length, the computation will be more and more complex, which will
   seriously affect the efficiency of the RSA algorithm and the
   performance of IIoT.

   Thirdly, the following scenarios have been considered during
   performance evaluation of the OPC UA security:

   (1) Data exchange with no security mechanisms.

   (2) Use of the Secure Channel with no use of certificate.


Wei, et al.             Expires July 20, 2017                 [Page 5]

 Internet-Draft            ACE OPC UA security             January 2017


   (3) Use of the Secure Channel with local verification of the
   certificates.

   (4) Use of the Secure Channel with remote validation of the
   certificates.

   According to [CaCh2013], the time overhead required to establish a
   secure connection is shown below:

   For scenarios (1), the time overhead is the least 0.054s, however,
   scenario (1) has no security functions; For scenarios (2), the time
   overhead is 0.16s, however, because IT technology is applied to IIoT,
   scenario (2) can easily be compromised; For scenarios (3), the time
   overhead is 0.31s, however, scenario (3) is only suitable for small
   scale; For scenarios (4), the time overhead is 14s, therefore, the
   scenario (4) has no value for IIoT.

   In summary, the implementation of current OPC UA security mechanism
   in constrained environments is a big challenge.

4. A lightweight security mechanism for OPC UA

   In order to deal with OPC UA security requirements in constrained
   environments, a lightweight security mechanism is proposed as shown
   in Figure 2. The lightweight security mechanism mainly use implicit
   certificates and elliptical curve cryptography (ECC), the main
   reasons are as follows:

   Digital certificates can represent a substantial investment, both in
   infrastructure, memory (to store and manipulate the certificate),
   and bandwidth (in repeatedly transferring the certificate to various
   entities). Implicit certificates are smaller and faster than digital
   certificates. Implicit certificates can enable a low-resource trust
   model for resource-constrained settings.

   ECC is a public key encryption technique based on elliptic curve
   theory that can be used to create faster, smaller, and more
   efficient cryptographic keys. Compared with RSA, ECC can obtain the
   same security performance by using shorter key. Therefore, ECC can
   establish equivalent security for constrained nodes.








Wei, et al.             Expires July 20, 2017                 [Page 6]

 Internet-Draft            ACE OPC UA security             January 2017


        +--------+                                   +--------+
        | OPC UA |   --- Implicit Certificate--->    | OPC UA |
        | Client |   <--- Implicit Certificate---    | Server |
        +--------+                                   +--------+
              |                                            |
              |                                            |
              v                                            v
      +-----------------+                        +-----------------+
      | Server's public |                        | Client's public |
      |        key      |                        |       key       |
      +-----------------+                        +-----------------+
              |                                            |
             ECC                                          ECC
              |                                            |
              v                                            v
      +------------------+                        +-----------------+
      |   Symmetric keys |                        |  Symmetric keys |
      +------------------+                        +-----------------+
               \                                            /
                \                                          /
                 \Used for signing and encrypting messages/
            Figure 2. The proposed security mechanism of OPC UA

5. Security Considerations

   TBD.

6. IANA Considerations

   This memo includes no request to IANA.

7. References

7.1. Normative References

7.2. Informative References

[IEC62541] IEC, "OPC UA, OPC unified architecture, IEC 62541", 2015,
           <https://webstore.iec.ch/searchform&q=IEC%2062541>.

[RFC2119]  Bradner, S.," Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC2119, March 1997.

[RFC7228]  Bormann, C.," Terminology for Constrained-Node Networks",
           ISSN: 2070-1721, RFC7228, May 2014.




Wei, et al.             Expires July 20, 2017                 [Page 7]

 Internet-Draft            ACE OPC UA security             January 2017


[RFC4949]  Shirey, R.," Internet Security Glossary, Version 2", RFC4949,
           August 2007.

[CaCh2013] Cavalieri S, Chiacchio F.," Analysis of OPC UA performances",
           Computer Standards & Interfaces, June 2013.











































Wei, et al.             Expires July 20, 2017                 [Page 8]

 Internet-Draft            ACE OPC UA security             January 2017


Authors' Addresses

   Min Wei
   Chongqing University of Posts and Telecommunications
   2 Chongwen Road
   Chongqing, 400065
   China

   Email: weimin@cqupt.edu.cn

   QingQing Huang
   Chongqing University of Posts and Telecommunications
   2 Chongwen Road
   Chongqing, 400065
   China

   Email: huangqq@cqupt.edu.cn

   ShuaiYong Li
   Chongqing University of Posts and Telecommunications
   2 Chongwen Road
   Chongqing, 400065
   China

   Email: lishuaiyong@cqupt.edu.cn

   Ping Wang
   Chongqing University of Posts and Telecommunications
   2 Chongwen Road
   Chongqing, 400065
   China

   Phone: (86)-23-6246-1061
   Email: wangping@cqupt.edu.cn


   ShuaiDong Zhang
   Chongqing University of Posts and Telecommunications
   2 Chongwen Road
   Chongqing, 400065
   China

   Email: 18983976906@163.com






Wei, et al.             Expires July 20, 2017                 [Page 9]