Securing LAN Connected Devices in Industrial Sites with TLS and Multicast DNS

Transcription

1 Securing LAN Connected Devices in Industrial Sites with TLS and Multicast DNS Tero Keski-Valkama May 28, 2015 Version 1.0 Abstract This whitepaper outlines a more flexible and more secure user interface architecture for browsers for industrial site networks based on proven web and LAN technologies, TLS and multicast DNS. Outotec Oyj and Cybercom Finland Oy

2 2 TERO KESKI-VALKAMA 1. Introduction In this whitepaper we separate two roles: The Provider who develops connected devices, and the Customer, who buys and arranges the installation of the devices provided by the Provider. The devices are installed in LANs owned by the Customer. Currently, a typical industrial site network consists of statically configured LANs, with weak or no encryption for the connections. These networks are minimally secured by restricting their connectivity to other site networks and to the internet. When the Customer s industrial site consists of devices from multiple different device suppliers, these device suppliers usually set up their own local networks separate from the networks of the other device suppliers, because there is little standardization in the site network topologies between sites. This leads to an increase in integration costs and in the complexity of site networks. In industrial networks we generally cannot make assumptions for the set of services available, such as support for Dynamic DNS, or Active Directory, for example. The organic approach leads to a layered network architecture where the networks closer to the core networks are kept increasingly isolated from the outside world, and nominally "more secure". However, as the industrial devices are getting more connected, this architecture is increasingly punctured by all kinds of ad-hoc methods to support the required connectivity and integration. Typically the connectivity is implemented by custom static routing, VPNs, sneakernet, and multi-homed VNC servers, for example. This makes industrial plant networks increasingly complex and the security increasingly difficult to guarantee, especially as there are more and more attacks against such networks. As the trend of industrial web progresses and specifically rich, mobile and interoperable user interfaces are increasingly being developed with web technologies like HTML5, there becomes a distinct need to secure the connectivity between the user s browser and the local LAN connected industrial device serv-

3 TLS AND MDNS IN INDUSTRIAL LANS 3 ing the management, administration or diagnostic user interfaces. This whitepaper outlines a more flexible and more secure user interface architecture for browsers for industrial site networks based on proven web and LAN technologies, TLS [1] and multicast DNS [2]. Since electronic attacks against industrial segment are increasing in frequency and sophistication, modern and proven web scale security technologies must be taken into use in the industrial segment as well. Existing security solutions concentrate on the industrial bus layer, and do not solve the local user interface layer in a flexible and secure way. Using the solution outlined in this whitepaper, modern HTML5 user interfaces can be used in a local industrial network environment securely and flexibly, in a dynamic auto discovery architecture. 2. Overview We propose a solution where the device deployed to the industrial site network administered by the Customer can be connected securely on the common and shared site LAN network in line with zero configuration principles. Users can access the devices using mdns domain names with common browsers over HTTPS, secured by proper TLS certificates. The devices can connect to each other using LAN connectivity and M2M bus while authenticating each other with the same TLS certificates. TLS and X.509 certificates [3] are a good solution for securing the connectivity between clients and servers. For example, a de-facto industrial plant networking standard OPC UA [4] uses TLS and X.509 certificates for securing the connectivity between devices and servers. TLS connectivity in statically configured LANs is challenging to implement properly because the certificates are bound to host addresses which might be unknown at the time of signing the certificates before actual deployment. The IP addresses might also change during the lifetime of the device because of site reconfigurations. Typically the hosts are configured to use insecure self-signed

4 4 TERO KESKI-VALKAMA certificates for this reason. The self-signed certificates are missing the chain of trust, which exposes distinct vulnerabilities in these kinds of networks. Multicast DNS (Avahi) is a technology for discovering host names in the local area network. The common mdns domain consists of mdns addresses in the form of <HOSTNAME>.local, where <HOSTNAME> is a DNS part: A label. Many browsers and operating systems support mdns name discovery, and it is commonly used for example in printers and similar devices with dynamic LAN connectivity. While the focus of this whitepaper is in securing user interfaces used with a browser, the established X.509 certificates can be reused for M2M authentication and encryption also. The first part of this whitepaper describes the TLS certification scheme for an industrial site environment. The second part describes the mdns HTTPS interface discovery and its binding to TLS scheme. 3. The Difference between Web TLS and Industrial LAN Security Standard web root DNS TLS certificate authorities do not support LAN mdns schemes and related trust. *.local certificates are being phased out by standard web root TLS certification authorities, and the existing certificates will be revoked. This is because such globally valid certificates for *.local addresses would cause a leaky trust scheme where devices certified for any network in the world would automatically be trusted in other LANs, possibly in other sites. In general, WWW TLS certificate authorities should only certify unique names that are accessible from the global web. The trust model for the World Wide Web and for industrial LANs are fundamentally different in requirements and in related solutions. In the solution described in this whitepaper, we mitigate this risk by using

5 TLS AND MDNS IN INDUSTRIAL LANS 5 separate trusted certificate authorities for each site and for each device, so that any Customer administering a network can select the proper trust domains and respective certification authorities to trust so that they are capable of signing only addresses related to a specific Provider, specific sites and specific devices. Obviously networked services that can be published in the World Wide Web securely over HTTPS, as opposed to local services, can be published using normal DNS and web root TLS certification methods. 4. Trust between Organizations The solution described in this whitepaper assumes that the Customer site can trust the relevant certification authorities of the device Provider. Establishing this trust is straight-forward, because it means that the browsers in the Customer LANs gain a proper added benefit of being able to validate devices provided by a trusted Provider. If this trust is not established, then the scheme falls back gracefully to operation similar to commonly used self-signed certificate model where each user needs to accept the server certificate for each device at the first connection. If the trust chain is established, the browsers can validate the proper TLS certificate trust chain in a similar fashion as with normal World Wide Web HTTPS sites. 5. Authentication in Machine-to-Machine Interfaces The devices deployed by the Customer network provided by the same Provider implicitly trust the Provider certificate authorities. This means that they can authenticate and encrypt HTTPS REST (or SOAP) connections securely using the certificates the devices were deployed with. The devices can optionally allow only a subset of their machine-to-machine APIs to other devices of certain

6 6 TERO KESKI-VALKAMA types from the same Provider. The established X.509 certificates for the devices can be reused for securing other kinds of M2M service buses like OPC UA also. The devices between different Providers can expose APIs to each other in a similar fashion, but of course a certificate trust must be established in these cases for example device-by-device basis manually by the Customer for example through device administration user interfaces. 6. Distributing Public Certificates and Certificate Revocation Lists The public TLS CA certificates of the Provider can be distributed through normal World Wide Web from a public TLS secured HTTPS site of the Provider. This guarantees the authenticity of the public CA certificates and links the trust chain to the standard WWW TLS certification authorities. If a certificate is leaked or lost, then it must be revoked by the certificate authority. Distributing the certificate revocation lists can be done in conjunction with distributing public certificates. Certificate and revocation list provisioning can be attached to the software update processes and co-managed in the same management processes. 7. Certificate Chain and Mapping to mdns Names The typical hierarchical organization for a family of products and sites they are licensed to follows a scheme where the Provider s root certificate is configured with an ability to sign *.local mdns addresses. After this root level, the trust domains must be provisioned into segments so that software development teams developing software for certain devices only have access to a certification authority certificate capable of signing addresses related to these devices and for the sites the devices are licensed to. Conversely, the Customer administering a

7 TLS AND MDNS IN INDUSTRIAL LANS 7 Figure 1: The certificate hierarchy certain site with devices from the Provider must have the option to only trust the certificates intrinsically capable of signing only mdns addresses related to this Provider and the devices licensed to a certain site. This means that the certificate chain roughly follows the hierarchy depicted in Figure 1. The development team developing software for a certain device licensed to certain customers and sites therefore only have the certificate authority capable of signing certificates for a certain Provider, for a set of certain Customers, for a set of certain sites, and for a certain device type. Conversely, the Customer site can trust a CA that is capable of signing certificates only for a certain Provider, a certain Customer and for this certain Site. Optionally the Customer can additionally enumerate all the device types that are trusted in Customer s LAN. For clarity, we leave out details of certificate expiration settings and their relation to the certificate chain. This certificate chain is for guidance only and does not necessarily reflect implementation specific details. Certificate expirations can be bound to the expiration of software licenses and co-managed in the same management processes. While TLS supports multiple certification authority levels separated by the domain name wildcards and hierarchy of labels, common mdns usage requires that the DNS names are in the form of <HOSTNAME>.local, where <HOSTNAME> is a label. Specifically, normal browsers only follow the.local mdns domain, and do not see other domains without explicit configuration. This introduces a

8 8 TERO KESKI-VALKAMA Table 1: Definitions of the parts of the mdns name Placeholder <DEVICE_TYPE> <SITE> <CUSTOMER> <PROVIDER> Description The name of one type of device. Generally the first device of a certain type deployed to the network should reserve this mdns address. E.g. "device". The name of the Customer s site. The naming is customer-specific and generally uniquely identifies a certain LAN. The name of the Customer. This must not collide with the assigned names of other customers, and these are managed and registered by the Provider. The name of the Provider. Generally this can be the same as the label registered to standard WWW HTTPS certification authorities without the TLD part for the sake of brevity. complication, because we cannot use the common WWW TLS method of separating different levels of certificate authorities by a hierarchy of DNS labels and wildcards. In this whitepaper, we suggest structuring the mdns host name so that it includes the relevant labels and hierarchy. This is done by using the hyphen as the delimiter between labels instead of period. The TLS certificate trust domains are mapped to mdns naming structure. The mdns names are structured as parts separated by hyphens as follows: <DEVICE_TYPE>-<SITE>-<CUSTOMER>-<PROVIDER>.local. The descriptions of the parts are shown in the Table 1. The resulting mdns names are long, but they can be automatically and securely redirected to from shorter DNS addresses or by using portals and link lists if necessary. The labels forming the parts of the names should be kept relatively short for obvious reasons.

9 TLS AND MDNS IN INDUSTRIAL LANS 9 8. mdns Collisions Avahi detects an mdns collision when multiple devices in the same LAN attempt to broadcast the same mdns names. This collision detection can be used for advantage in cases where multiple devices of the same type are installed to the same network. The first device that is able to reserve the mdns name can subsequently serve the common interface for all similar devices in the network, and function as a kind of a portal representing all the devices of the similar type in the same network. It is possible to use only one mdns name usable from browsers, and aggregate the other devices together inside the same portal user interface using a separate M2M bus with autodiscovery. This M2M bus can be secured using the same X.509 certificates and trust chains. 9. Mobile Support and Adapting Multicast DNS to Unicast DNS At least Android OS has a very limited support for mdns at the time of writing. In practice, all the browsers utilize the Android OS DNS resolver which has no support for mdns, so at the moment no browser can resolve *.local addresses properly. However, there are several utilities available in the Android market, such as Bonjour Browser [5], which allows discovering the published services from the local network. Current applications do not support opening a browser to the discovered IP address, but implementing such a client application is trivial. Of course, using IP addresses in the browser negates some of the security benefits described in this whitepaper, and the connection security would be analogous to self-signed certificates. Apple ios devices support mdns natively. Some mobile browsers and operating systems with no support for mdns can also be accommodated by adapting the mdns names in the local network to be published in the local DNS infrastructure. This is can be done by utilizing

10 10 TERO KESKI-VALKAMA DNS UPDATE [6] queries to a local DNS server as typically done in DDNS, or using a hybrid mdns-udns like one in an IETF draft Hybrid Unicast/Multicast DNS-Based Service Discovery [7]. Since the Provider does not know the configuration of such an infrastructure on the Customer s site, it remains Customer s responsibility to implement such an adapter if considered necessary. 10. Security Domain Separation using Certificate Sets Because the root certificate has a trusted capability to sign all *.local domain names, it is necessary to keep this certificate secured to maintain this trust. However, it is still necessary to sign new certificates for new devices and for new sites. In this whitepaper we propose a TLS-based domain separation scheme to mitigate the risks. The security domains are limited in the mdns names their respective certificates are capable of signing. They form a normal certificate chain, or more accurately a tree, based on the root CA. In this whitepaper we suggest a scheme where all the possible mdns names for each successive certification authority level are enumerated to work around the lack of suitable wildcard support in TLS for intra-label structuring. In practice TLS certificates can contain an enumerated list for all names they are able to sign, but in practice certain technical limitations limit the length of these lists. For the implementation of the scheme described in this whitepaper, we suggest maintaining Certificate Sets for each level of certificate authority, so that each certificate can only sign certificates with one certain name. The Certificate Sets then include certificates capable of signing a cartesian product of all the possible enumerations of allowed label values for the respective certification authority. This means that the certificate authority just under the Provider root *.local

11 TLS AND MDNS IN INDUSTRIAL LANS 11 certificate authority should contain the largest number of distinct certificates limited by the cartesian product shown in the Equation (1). Customers CustomerSites DeviceT ypes (1) For a reasonably sized Provider this could result in for example: 1, = 5,000,000 certificates. When one certificate takes for example around 4 kb of space this results in 20 GB, which is reasonable in the light of current consumer-grade disk sizes. One Customer Site would generally either trust the singular Provider root CA, or optionally trust a Certificate Set for one customer site limited by the number of device types. For the previous example this would result in 100 distinct certificates to trust per site. A standard Firefox desktop browser comes with an in-built list of trusted CA certificates with over 170 certificates, so this number is reasonable even for mobile browsers. The root certificate must be kept secure and its exposure must be limited to a simple API with limited operations allowed so that all operations are securely logged. For example, signing a set of certificate signing requests is only allowed if the names in the certificate signing requests match the enumerations of allowed labels. 11. Adding New Customers, Sites and Device Types In a continuous business new customers, sites and devices must be added to the scheme while the existing trust relations must not be invalidated. Obviously if the trust has been established for a certain Customer site limited for certain device types only, the new certificates related to the new device types need only be generated by the Provider only for the new device types. The existing certificates are maintained, thus maintaining the existing trust relations.

12 12 TERO KESKI-VALKAMA 12. Summary This whitepaper describes a practical method for establishing secure and flexible networking for LAN connected devices and their HTML user interfaces especially in industrial networks using standard web technologies, specifically multicast DNS and TLS. The scheme described in this whitepaper has been implemented as a proofof-concept and it s practical usability has been validated with common desktop browsers and operating systems. References [1] RFC 5246 The Transport Layer Security (TLS) Protocol. [2] RFC 6762 Multicast DNS. [3] ITU-T Recommendation X.509 (10/12). [4] OPC Unified Architecture (UA). [5] Bonjour Browser for Android. [6] RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE). [7] Hybrid Unicast/Multicast DNS-Based Service Discovery.