Authentication of people

Direct approach with biometrics

People get authenticated using body measurements.

  • Biometric samples or features.

  • Common modalities.

    • Fingerprint.

    • Facial recognition.

    • Palm print.

    • Iris scan.

    • Voice recognition.

    • DNA.

Measures are compared with personal records.

  • Biometric references (or template).

  • Registered in the system with a previous enrolment procedure.

Fingerprint sensor

Direct approach with OTPs

One-time passwords (OTP).

  • A credential that can be used only once.

Advantages

  • OTP can be eavesdropped.

  • Eavesdroppers cannot impersonate the OTP owner.

    • True for passive eavesdroppers.

    • False for active attackers!

Problems

Interactors need to know which password they should use on different occasions.

  • Requires some form of synchronization.

People may need to use extra resources to maintain or generate one-time passwords.

  • Paper sheets.

  • Computer programs.

  • Special devices, etc.

OTPs and secondary channels

OTPs are codes sent through secondary channels.

  • A secondary channel is a channel that is not the one where the code is going to be used.

  • The secondary channel provides the synchronization.

    • Just-in-time provision of OTP.

Two authentications are possible.

  • Confirm the ownership of a secondary channel provided by a profile owner.

  • Authenticate the owner of a profile, which is bound to a secondary channel.

OTPs produced from a shared key

HOTP (Hash-based One Time Password, RFC 4226)

Numeric OTP computed from shared key K and synchronized counter C.

  • Hash the key with the counter, and increase the counter.

  • From hash, get a (floating) portion of 31 contiguous bits.

    • Dynamic Binary Code (DBC).

  • Compute a d-long decimal number (d >= 6).

Issues:

  • Counter synchronization upon a failure. Exhaustive search attacks are viable if the authenticator keeps it after a failure. If the authenticator always increments it, DoS attacks are possible.

  • Acceptance windows.

    • Mitigates minor desynchronizations, but decreases security.

TOTP (Time-based One Time Password, RFFC 6238)

OTP is generated from a timestamp and a shared password.

TOTP is HOTP with timestamps instead of counters.

Clocks need a rough synchronization.

CT=(TT0)/TXC_T = \lfloor (T-T_0) / T_X \rfloor
  • T - initial time

  • T0 - initial time

  • Tx - time interval

Challenge-response approach

The authenticator provides a challenge.

The entity being authenticated transforms the challenge.

  • With its authentication credentials.

The result (response) is sent to the authenticator.

The authenticator checks the response.

  • Produces a similar result and checks if they match.

  • Transforms the result and checks if it matches the challenge or a related value.

Advantage

Authentication credentials are not exposed.

Problems

People may require means to compute responses.

  • Hardware or software.

The authenticator may have to have access to shared secrets and how can we prevent them from using the secrets elsewhere?

Offline dictionary attacks against recorded challenge-response dialogues which can reveal secret credentials (passwords, keys).

Selection of challenges

Challenges cannot be repeated for the same entity.

  • Same challenge → same response.

  • An active attacker can impersonate a user using a previously recorded protocol run.

Challenges should be nonces.

  • Nonce: number used only once.

  • Stateful services can use counters.

  • Stateless services can use (large) random numbers.

  • Time can be used but with caution.

  • Because one cannot repeat a timestamp.

Challenge-response with smartcards

Authentication credentials.

  • The smartcard.

    • e.g. Citizen Card

  • The private key is stored in the smart card.

  • The PIN to unlock the private key.

The authenticator knows.

  • The corresponding public key.

  • Or some other personal identifier related to a public key through a (verifiable) certificate.

Signature-based protocol.

  • The authenticator generates a random challenge, or a value not used before.

  • The card owner cyphers the challenge with their private key.

    • PIN-protected.

  • The authenticator decrypts the result with the public key, if the output matches the challenge, the authentication succeeds.

Encryption-based protocol.

  • Possible when private key decryption is available.

Challenge-response with memorized password

Authentication credentials.

  • Passwords selected by people.

The authenticator knows.

  • All the registered passwords; or

  • A transformation of each password.

    • Preferable option

    • Preferably combined with some local value (salt).

    • Preferable using a tunable function (e.g. iterations).

The authenticator generates a random challenge.

The person computes a function of the challenge and password.

  • e.g. a joint digest: response = digest (challenge, password).

  • e.g. an encryption response = E_password (challenge)

The authenticator does the same (or the inverse).

  • If the output matches the response (or the challenge), the authentication succeeds.

Examples.

  • CHAP, MS-CHAP v1/v2, S/Key

Generation of OTPs with challenges

OTPs can be produced from a challenge received.

  • The fundamental protocol is password-based.

    • But passwords are OTPs.

  • OTPs are produced from a challenge.

  • One can use several algorithms to handle OTPs.

OTPs selected from shared data

Advantage:

  • Shared data can be random.

  • No long-term short secrets to protect.

OTPs are built from printed data.

  • Example: online bank codes.

Selection of an OTP from a printed/saved list

Challenge-response with a shared key

Uses a shared key instead of a password.

  • Robust against dictionary attacks.

  • Requires some token to store the key.

Last updated