Goal: a protected entity must be accessible but only to authorised entities. There is a process for confirming authority which involves three steps.

1. Identification: present/request identity
2. Authentication: check validity of the identity
3. Authorisation: check access of the valid identity

Describes the presenting of an identity.

• In computers and networked systems, it is usually a set of credentials (username and password) but it may also be complemented with additional factors.

Describes the process of determining someone or something are indeed who/what they claim to be.

• In computers and networked systems, the credentials must be a matching set, e.g. the password must be correct for the username.

Describes the process of determining whether an authenticated entity has the authority to access the protected entity.

• In computers and networked systems, users would have access to certain entities - not to all entities!
• In the border example, authorisation to enter is granted to nationals of the country and Visa holders only. If entry is denied, that does not mean the officer did not know who you are.

Claims refer to certain attributes of a user like:

• Name or username
• Email address

In simple authentication the credentials are the only claim, yet more complex mechanisms exists.

In most cases, the protected entity is large and segmented to smaller, also protected, entities:

• A country is large, some parts are not accessible
• A website has many areas, some are not available to all authorised users – e.g. administrator panel

Each confirmed identity or role may or may not have authority to access every segment.

• Role: the group where the confirmed identity belongs
• Access rights: the set of rights to access various protected areas – may be by single identity or by role

Users

• Usually people but one person may hold more than one set of credentials and vice versa
• Typically authenticated with credentials
• Other mechanisms exist (e.g. claims)

Data

• Whether data are indeed originating from claimed source and whether they have been altered during transmission – or at rest
• Typically authenticated with hash functions

Devices

• Whether a device is the one it claims to be
• Possibly authenticated with a secure token sent to the device

Servers

• Whether a server is the one it claims to be
• Typically authenticated with a certificate

Humans use passwords, biometric authentication etc

Machines use cryptographic authentication

• Proving ownership of key/token
• Do you own the right key? Then you’re the right machine
• The key distribution scheme is therefore important

Key ownership proves identity

Once an entity have a key they can authenticate by proving they own it

• Happens for example in WPA/WPA2
• The system is secure, if the key remains secret
• And if it has arrived securely in the first place
• Better be a unique key for each authenticating entity
• Otherwise all the entities are compromised, if the single key is lost

So, we can ensure good authentication, only with a good “key distribution” scheme

Public-Key cryptography (D-H, RSA)

• Establish a secure session over an insecure connection

Pre-shared key

• Load the key before deployment

Probabilistic key distribution

• Have many keys, load some of them only

• Known as key-exchange protocols because their objective is to exchange a secret key
• Anyone can join the network i.e. any HTTPS browser can see a website
• Website is authenticated but needs a whole PKI infrastructure behind it
• Imagine what it would take to have the same infrastructure for clients as well
• As done by PGP – a bit impractical

Just agree to a key between all clients

• How do you agree securely?

When using just one shared key …

• What if that key is leaked?

Why not use many keys?

• How many? Half as many keys as devices
• Not appropriate for IoT and WSN
• 30M cars in the UK, that’s ~500MB would be needed in every car to communicate with every other car in the UK
• Nevermind driving to Europe

• Create a pool of many keys
• Randomly load some keys to each node
• There is a chance that nodes will share one or neighbourhood nodes will share one
• Leaked keys have a smaller impact on network

MAC means Message Authentication Code.

• Alternative name is MIC (Message integrity Code)
• Don’t confuse with networking’s Medium Access Control

MACs may be produced by

• HMAC: with a cryptographic hash function like SHA-1
• CMAC: with a cipher (e.g. AES) in a “MAC” mode of operation
• The correct input, i.e. what needs to be authenticated
• The unique key
• The data (payload)
• Metadata (e.g. the source address)
• An Initialisation Vector, aka nonce or salt (sometimes)

MACs ensure the …

• Data authenticity– the sender identity is true
• Data integrity – no data alterations while in transit

MACs are sent with the packet, along the payload and the other fields, sometimes with the IV in plaintext

• The receiver validates the MAC to confirm data integrity and authenticity

The MAC has similar function but is different than digital signatures (used with PKC), because MACs are generated and verified using the same key

HMAC is the simplest way to create a MAC

• Used in IPSec and TLS
• It is an agreed “standard”

Uses a normal hash function e.g. (SHA1 or MD5) in a standardised procedure

• Ensures the key affects and thus protects all input data
• Requires breaking of the data in key-sized blocks
• It is terribly inefficient
• Every block needs more than one cryptographic operation
• Hash functions are meant to be slow and inefficient

Note: HMAC-SHA1 means the HMAC standard procedure was followed and the hash function SHA1 was used within it

CMAC is an efficient way to create a MAC

• Produces a MAC with a cipher and a “cost” equal to encrypting the message (plus a some overhead)
• Significantly more efficient, equally secure as HMAC
• Ciphers are meant to be fast and efficient
• CMAC is based on the now insecure CBC-MAC

It is a complicated algorithm, the short version is:

• Derive keys K1, K2 using the cipher and secret key
• Encrypt the message in CBC mode
• XOR the final block with either K1 or K2 (T&C’s apply)
• Encrypt XOR-ed final block – this is the MAC material

• Produce a MAC and Encrypt the message with one pass of the cipher
• Possibly more secure, because authentication is integrated
• Definitely more cost-efficient
• A current research topic
• CMAC can do this already, it would only require a bit more complexity on the design
• But the security of CMAC is not fully understood, thus the security of the Authenticated Encryption would not be either
• CAESAR is an AES-type project on Authenticated Encryption: http://competitions.cr.yp.to/caesar.html

A single authentication method is not enough for applications where security is important

• E.g. a Student Card is enough to enter the Library, but not enough to log-on to the computers there

Therefore, more than one authenticating pieces like the above may be required for a specific task

• These authenticating pieces are called factors
• Requiring more than one factor is multi-factor authentication

Refers to authentication with two or more authentication factors

There are three kinds of factors presentable:

• The knowledge factor: something the user knows
• Credentials, a PIN, a passphrase, a shared secret
• The possession factor: something the user owns
• A Staff Identity card, a bank card, a SIM card
• The inherence factor: something the user is
• a biometric property

Two factors are enough for most multi-factor authentication, but three factor kinds are required for “true” multi-factor authentication

• A special kind of multi-factor authentication commonly used on the web
• The possession factor is validated through an OTP generated at the time of authentication
• The OTP is sent to the user through a distinct communication channel
• Verifies possession of the entity at the end of the distinct communication channel (e.g. a SIM card)
• It is not true true multi-factor, since it involves two factors only

Examples

Website log-in:

• A user attempts to log-in to a site with credentials
• The site sends a unique, one-off, ID to the users mobile phone
• The user is asked to enter this ID before he is fully authenticated

Online banking:

• A user logs-in to online banking using a username password
• The system issues a unique number to be entered to the user’s card reader, along with their physical bank card & PIN
• The card reader generates a response number by hashing the Card’s number, the Card’s PIN and the unique number

In that case, the possession factor is satisfied by the user possessing the card while use of the username, password and card PIN satisfy the knowledge factor.