Security Primer 1- Client Authentication
This is the first in a series of primers on security.
Internet-of-Things devices communicate with each other and with various service backends. To make the communication secure and trustworthy, devices and service backends need to know with whom they are communicating. Only then does securing and sending actual data make sense. Devices shouldn’t send even encrypted data to unauthorized, potentially fraudulent devices. Therefore, devices will need to endorse the following elements:
While authorization can be provided to an entity which has not been authenticated (aka anonymous), most authorization control system are based on proper authentication of a person’s or device’s identity. In computer systems, a Web client connects to a Web server, e.g. to access a Web service, or more generally to exchange data. Authentication enables one side to verify the identity of the other side.
Authentication can go both directions. Server Authentication allows a client to validate the identity of a server. This prevents a client from exchanging data with an invalid, potentially fraudulent server. This is specifically important if the client is also receiving control commands from a server. Client authentication allows a server to validate the identity of a client. In contrast to providing an anonymous service, client authentication allows a server to distinguish data received from Client A from data received from Client B.
Whether one or both sides need to be authenticated depends on the type of service and the type of device. Some services allow anonymous use, e.g. a Web search, whereas others require mutual authentication, e.g. an online banking service. Use of authentication may also be enforced by regulators. They will define rules targeting sensitive communication within crucial industries. One example is the electric grid.
Distributed Energy Resources (DER) systems communicate with a utility. This allows the utility to control smart inverter system directly or indirectly via an aggregator, and to receive status information from them. Correct and secure functioning of DER systems is crucial to the stability of the electric grid. Communication between the utility (the server) and the smart inverters (the clients) may include:
Utility servers are required to maintain a list of authorized DER Clients that can communicate with the server. Servers are required to close the communication connection with any un-authenticated client. Mutual authentication, i.e. server and client authentication, is required for all devices implementing the Common Smart Inverter Profile (CSIP) for California Rule 21.
Client and server authentication function independent of the underlying transport mechanism. It cannot be limited to only private networks. Additionally, authentication must be robust in the presence of man-in-the-middle attacks and fraudulent servers and clients aiming to masquerade as legit devices.
Server Authentication Implementation
Server authentication, allowing a client to validate the server’s identity, is in many cases certificate based; i.e. the identity of the server is contained within a digital certificate, which is signed by a trusted entity. A Certificate is an electronic document which proves ownership of a public key. It includes information about the identity of its owner (aka the subject). Therefore, these certificates are referred to as identity certificates or public key certificates. A certificate may also contain additional information about the owner, like an email, a DNS entry, or other identifying information. The certificate owner may use its private key to sign messages, proving that messages have been generated from the certificate owner.
The certificate is signed by a trusted entity (aka the issuer). The signature prevents a possible adversary from changing the certificate’s content, and therefore manipulating the owner’s identity or associated information. The client can validate the certificate with the public key of the trusted certificate issuer. For many Web services, companies like Symantec, GoDaddy and others are the trusted certificate issuer. Their public keys (the trust root) are already included in many modern Web browsers, allowing them to validate a website’s certificate.
Within IoT, the challenge exists that at the time of manufacturing the trust root is unknown- it is dependent on the trust root used by the end customer’s server which is yet to be determined. Additionally, a device can be repurposed during its lifetime which can require a new trust root. For example, a manufacturer of a farm sensor may not know which farm is going to buy the sensor. If different farms have different root certificates the manufacturer does not know which ones to put into the device.
Client Authentication Implementation
Client authentication, which allows a server to validate the client’s identity, can be implemented differently depending on the ability of the client.
Username/password: Client authentication for many Web services is based on user name and password. The user name acts as the end-user’s unique identifier and the (secret) password provides the proof that the end-user is who he or she claims to be. Many moderns Web services allow for additional 2-factor-authentication, e.g. using a separate communication channel like SMS. The password must be available (or entered from the user) in clear text on the Client side. It is sent encrypted from the client to the server.
Client Certificates: like with server authentication, the IoT device contains its own unique client certificate. The certificate contains identifying information, like a UUID number. Signing of individual client certificates from a trusted Root certificate authority (CA) is impractical, therefore an intermediate CA is used, which itself has its own certificate signed by a trusted root CA. To validate a client certificate, the Server only needs access to the public key of the root CA. Certificates have an expiration date. Certificates can also be revoked during their lifetime. Dedicated mechanisms, like OCSP or CRL, exist, which allow a server to check whether a certificate has been revoked. Client certificates can be enabled using mutual authentication with TLS. This is the way regulations like California Rule 21 require client authentication.
Pre-Shared Key: Using a pre-shared key (PSK), an IoT device links to a shared secret which has been exchanged prior to the establishment of a connection. In contrast to user name/password, the PSK is not sent from the server to the client. It is used instead to start an encrypted symmetric session. Server’s not having access to the same PSK will not be able to decrypt the session. The pre-shared key must be available in clear text form on both sides.
User Name/Password is a standard mechanism for end-user Web Services, like online Banking, online purchasing etc. It is not practical for IoT devices. Use of client certificates for client authentication is the preferred mechanism. Nevertheless, the use of asymmetric cryptography may cause implementation or deployment problems in case bandwidth limited communication systems are used. PSK based client authentication uses less bandwidth.
As an aside, being able to uniquely identify a client poses challenges to manufacturing. Producing millions of devices, each with a unique identity which can be validated by the server, requires control and trust of the manufacturing process so that credentials get created correctly and keys don't get stolen on the factory floor. Addressing these challenges is core to what Wivity does, but this is a discussion for another day.
Client authentication is an important element of securing the communication of IoT devices. Individual control of IoT devices requires a Server to uniquely identify it. To prevent any fraudulent client harming the system, client identification must be validated by the server.
By Jörg Brakensiek on May 22, 2018