Authentication, authorisation and the chain of trust

I recently walked by my old college.  There was a sign outside: Closed to visitors.  I realised that two cards in my wallet would get me in, which made me think of some security concepts: the difference between authentication and authorisation, and the chain of trust.  I’ll go into those a bit in this article, as they’re generally useful concepts.

The scenario

I had two cards in my pocket: the photo card part of my driving licence, and a card issued by my college with my name on it and the date when I started at the college.

The driving licence would generally establish that I was who I claimed to be.  My college card would then say that I was a former student at the college, and the porters (the members of college staff responsible for security, among many other things) would let me in.

That’s it described at the everyday level, so with that as context we’ll dive a bit deeper because that’s where the potentially useful security nuggets lie.

Driving licence – my photo id

We’ll first look at my driving licence, because that’s where the process starts.  The driving licence has two jobs, only one of which is important here:

1. Asserts that there’s a person for whom the four facts on the card are all true: what they look like, their name, their address and their signature;
2. Asserts that the person in the previous assertion is allowed to drive cars and some other vehicles in the UK.

We’re interested in only the first one here, because we’re not discussing driving, and we’re not really interested in the signature part.

As a diagram, it’s:

It’s important to think why a driving licence is trusted.  The UK government issues them, and takes measures to see that they’re not issued wrongly and can’t be forged.  Because they’re the UK government, most people will think they’ll do a good enough job of this.  However spies and criminals will still try to forge them – either creating their own forgeries, or exploiting a corrupt member of staff at the organisation that issues cards so that a genuine card can be issued ‘wrongly’.

When I present my driving licence, it proves my identity for most purposes.  By that it means someone else can trust that my name (and address and signature) are as on the card.  They do this by checking my face against the photo on the card.  As a diagram, it’s:

If I’d had a nasty accident such that my face was covered in bandages, this would break down.  The other person couldn’t check my face against the card’s photo, and so I would have to put effort into convincing them that it’s my driving licence, and not one I’d picked up off the floor or stolen from someone.  This check is also a topic of spy thrillers and so on, where people have plastic surgery or wear disguises so that they can look like someone else, and use the other person’s identity documents to then be allowed to act as them.

Also note that this is a very crude biometric security check.  Instead of a computer checking a digital encoding of my fingerprints or retina against a list of stored encodings of valid fingerprints or retinas, the other person is looking at my whole face and checking it against a photo on a plastic card.

Chain of trust

This is now beginning to build a chain of trust, although that will get more obvious when we add the second card shortly.  The basic idea is that if there are two things that I already trust, this gives me confidence to trust a third thing.  In this case the two things are:

1. This is a valid driving licence for Bob;
2. This person’s face is genuine, and not the result of plastic surgery or a disguise.

The two of them together mean that this new statement can be trusted:

3. This person is Bob.

As a diagram:

The chain can be built out of more links than this, and we will be adding another link soon.  In the case of security certificates, there are often 4 things joined with 3 links:

1. Root certificate
2. Intermediate certificate
3. Server certificate
4. Program

College card

We’ll now add the college card, which makes the claim that Bob is a former student at the college.  This is a lower-security card, with no photo and no security devices like holograms.  However, its claim is a weaker one than the claim made by the driving licence – Bob is a former student at the college, rather than this is Bob.  The cost of the security, in terms of things (cards, card readers etc.) and inconvenience (how many steps you need to go through to assert that a claim is true) need to be appropriate for the situation.

This is a more obvious extension of the chain of trust.  We are combining:

1. This person is Bob;
2. Bob is a former student at the college.

To assert:

3. This person is a former student at the college.

As a diagram:

So far, we have been working in the area of authentication, which is helping someone to decide who someone else is.  The two cards together, plus my face, would let someone have a reasonable amount of confidence that I am a former student at the college.  These are all to do with my identity.

Authentication vs authorisation

If, instead of presenting my two cards to a stranger, I present them to a college porter, then we can start getting potentially useful authorisation stuff done.

The porter can, as we’ve already established, build enough confidence that I am a former student at the college.  They then consult some rules (which are probably in their head) that say that former students at the college are allowed in.  What you are and aren’t allowed to do is authorisation, which depends on authentication as a previous step.

You could think of authorisation as a series of X => Y rules, where X is a condition that might or might not be true, and Y is a consequence that happens if X is true.  For instance:

• Person is a former student at the college => person can enter the college but not go into any buildings.
• Person is a current student at the college => person can enter the college and go into any buildings that current students are allowed in.
• Person is a lecturer at the college => person can enter the college and go into nearly any building.
• Person is the President (head of the college) => person can enter the college and go anywhere.
• Person is a cleaner for the college => person can enter the college and go anywhere.

Authorisation is applying the relevant rules, based on which left-hand-sides of the rules are true.  Authentication is getting a reasonable amount of confidence in which of the left-hand-sides are true: what kind of person is this?

The college could decide to change its rules, such that former students are no longer allowed in.  This is a change that affects authorisation – I would still be a former student (authentication) but what I’m allowed to do (authorisation) has changed.

Alternatively, it could be that I lied on the application to the college, and when this is discovered the college decides to expunge my membership.  I would no longer a former student of the college (which is a change to the results of authentication).  Even though former students would still be allowed to visit (authorisation rules), I would still not be allowed in because my authentication as a former student would fail.

More sophisticated and realistic example

I realise that this is a simple example that I have really laboured.  However, I hope it gives some concepts that are useful when you look at proper computer security.  For instance, refer to the article on Single Sign-On using SAML.  A key part of SAML is the use of X509 certificates to sign the SAML messages.

The effect of this is that a message’s recipient can trust that the message came from the person / program who claims to have sent it (and that the message hasn’t been tampered with since).  This is a claim about the message’s identity – it is a message from person / program X.  Therefore, it’s authentication.  Once the authentication of the message has been accomplished, its contents can be trusted.  The message asserts that the user mentioned in the message should be allowed into the system (into the Service Provider), and possibly asserts other things about them such as a user group that they belong to.

There’s therefore a chain of trust – I as the recipient of the message trust the message, and the message says that I should trust user X, therefore I trust user X.

Once the message has been authenticated, and hence the user has been authenticated, then authorisation can happen.  Based on the properties of the user included in the message (such as the user’s group), the system will allow them to do log in and do the correct set of things for the kind of user they are.

Summary

Authentication, authorisation and chain of trust are useful security concepts.  Authentication is deciding who someone is.  Authorisation is deciding what someone can do, once you know who they are via authentication.  A chain of trust happens when trusting two things means that you can trust a third thing.  This process can be compounded, so that more and more things can be trusted.