# 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

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FvyCXMhZQBf3P6otETifz%2Fimage.png?alt=media&#x26;token=7f0bb35a-b9d5-421c-a68f-a2dc50639a48" alt=""><figcaption><p>Optical</p></figcaption></figure>

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FleEMhsm8er1rkTnfat0C%2Fimage.png?alt=media&#x26;token=b073aa37-0cd0-4b68-a59d-dc0fa30a74d4" alt=""><figcaption><p>Ultrasonic</p></figcaption></figure>

## 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-_&#x6C;ong 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.

$$
C_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.

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2Fc8UuTLCMcEvCD4h97Djf%2FScreenshot%20from%202024-04-08%2016-34-34.png?alt=media&#x26;token=64f2b2e2-6d27-4755-9f57-003d13e09023" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="https://3490214077-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAHT7avzIVwxfPJ4pkhhO%2Fuploads%2FOeZVWhUePsS62XrSLODk%2FScreenshot%20from%202024-04-08%2016-41-06.png?alt=media&#x26;token=be4a1e9f-5e3a-4545-902b-9f634a4ed8a7" alt=""><figcaption></figcaption></figure>

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.
