Authentication 101: A Question of Trust

By Ken Lam August 15, 2018

iot-authentication-trust

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.

Passwords: Simple yet flawed

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.

Unilateral authentication

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 foundation of public key infrastructure

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.

Key authentication terms

A trust relationship involves at least 3 entities:

  • Relying Party (RP): The entity requesting access to a resource on another entity
  • Public-Key Certificate Subject (Subject): The entity that is being authenticated
  • Certificate Authority (CA): The authority that issues certificates to Subjects and the place the RP goes to verify a certificate

The simplest model upon which a trust relationship is based involves 3 parties:

 

Authentication Model 1

 

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.

 

Authentication Model 2

 

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.

 

Authentication Model 3

 

The ultimate authority over trust

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.

How is the authentication carried out?

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.

IoT Authentication challenges

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.

The first line of defence

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.

 

Entering the Internet of Things: Opportunity, Risks & Strategy Download the free eBook now

 

Topics: security, authentication


Ken Lam's photo

By: Ken Lam

Ken has joined Nordic Semiconductor in Hong Kong as a Field Applications Engineer in 2015. In addition to providing technical advice to customers before and after sales, Ken is also actively involved in various marketing activities including seminars, trade shows and training.

Følg på Facebook

Følg på LinkedIn

Følg på Twitter

Epost

Comments

Get Connected Blog

This blog is for you who are new to the connected world of the Internet of Things (IoT) - whether you are a senior executive, in product development, or simply a curious soul.

Our goal is to inform you, keep you updated and help you understand the opportunities and challenges of IoT for your industry.

If you are a developer, you may want to check out our blogs and developer guides in the DevZone

Visit www.nordicsemi.com

New Call-to-action

Latest Posts