Establishing the true identity of the other party is a fundamental security principle for IoT developers. Let’s take a dive into the basics.
Authentication has been a challenge ever since humans started to transact with people they didn’t know personally. In a connected world, transactions between unknown parties are commonplace so it’s never been more critical to get it right.
Authentication based on a username and password is the most commonly encountered method, as it’s easy to understand and simple to implement. It aims to establish the identity of the client accessing resources on the server, but with usernames and some passwords relatively easy to crack, establishing the client’s true identity is a long way from guaranteed.
While the server needs to know who is accessing resources on it, the client also needs to know whether the server can be trusted with sensitive information.
A common way of authenticating a server is through digital certificates. The server provides the client with a certificate containing its identity information, public key, and the authority which has issued the certificate.
The server’s identity is established with a third-party entity, as the client connects with the authority to authenticate the certificate itself before making use of the information on it.
The de-facto standard for digital certificates is the ITU Recommendation X.509, the foundation of Public Key Infrastructure (PKI).
Widely known as X.509, it defines the format and contents of digital certificates and provides a framework for obtaining and trusting a public key of an entity in order to verify its digital signature.
X.509 also addresses the need to manage certificates with Certificate Revocation Lists (CRLs), and an infrastructure for managing authorization with Attribute Certificates.
A trust relationship involves at least 3 entities:
The simplest model upon which a trust relationship is based involves 3 parties:
This model applies when there is an established trust between the trust anchor and the RP. An example is an internally-maintained private trust anchor in the same organization as the RP and the Subject.
In the cases that trust is not already established between the RP and the trust anchor, e.g. a public trust anchor, a trust broker comes into play as an agent for the RP to interact with the trust anchor.
In both cases, an implied trust is established between RP and Subject based on the verified Public Key Certificate (PKC).
A PKC, which is also widely known as SSL certificate or X.509 certificate, binds the identity of the Subject with the Subject’s public key. The Subject can be identified with the distinguished name field in the certificate.
Before any information in the certificate is applied, the certificate must be verified with the signature and public key of the issuing certificate authority.
A very important entity defined in X.509 is the Trust Anchor: a public key and associated information that acts as the ultimate authority for verifying the authenticity of the certificates. The process the RP takes to verify certificates with the Trust Anchor is referred to as public-key certificate validation.
In general, an RP starts the process by verifying the certificate with the signing Certificate Authority. The process carries on if other certificates have been issued by other Cas, until the process reaches the Trust Anchor. The path which the whole process took is referred to as the certification path.
One special case is when the Certificate Authority issuing certificates is also the Trust Anchor. These certificates are usually referred to as self-signed certificates. As Trust Anchors are the origin of trust, they are sometimes referred to as root CAs.
Certificate Authority can be maintained in-house or sourced from service providers. In most cases, a professionally managed CA is a better choice as it is a true third-party independent of RPs and Subjects. An internally maintained CA is only trustworthy up to the boundary of the organization maintaining it.
Authentication may be carried out symmetrically or asymmetrically. A username/password combination is an example of symmetric authentication based upon knowledge of single shared secret.
> Read more: Secure IoT commissioning: How hard can it be?In contrast, asymmetric authentication is based on exchanges of partial information, for example public key pairs, or random information generated on-the-fly. ECDSA, a signature verification algorithm based on Elliptic Curve Cryptography, is a widely-adopted standard for asymmetric authentication.
For symmetric authentication processes, the reliance on knowledge of a single piece of shared information introduces a single point of failure to the process. Encrypted storage and an insistence on long, complex passwords is the farthest one can go to guard against attack, but it is inherently difficult to protect passwords aggregated in a single database.
There is also no shortage of challenges for asymmetric authentication processes such as those based on X.509. The Certificate Authority is always a target of attack and any security flaw leads to the potential issue of rogue certificates. This can paralyze an entire organization by breaking down the trust among entities.
For authentication schemes that depend solely on in-band communications, another challenge lies in protecting partial secrets passing through the communication channels. There is an inherent risk of man-in-the-middle (MITM) attacks, which can only be defended against by using Multi-Factor Authentication.
Regardless of the challenges, a sound authentication scheme is the critical first line of defence against malicious attacks. Proper authentication support is a pre-requisite for connected devices in this day and age.