Authentication of people
Last updated
Identification, Authentication and Authorization
Last updated
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.
One-time passwords (OTP).
A credential that can be used only once.
OTP can be eavesdropped.
Eavesdroppers cannot impersonate the OTP owner.
True for passive eavesdroppers.
False for active attackers!
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 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.
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.
OTP is generated from a timestamp and a shared password.
TOTP is HOTP with timestamps instead of counters.
Clocks need a rough synchronization.
T - initial time
T0 - initial time
Tx - time interval
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.
Authentication credentials are not exposed.
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).
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.
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.
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
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.
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
Uses a shared key instead of a password.
Robust against dictionary attacks.
Requires some token to store the key.
