Skip to content

OATH

The OATH (Open Authentication) initiative is a collaboration supported by various members of the security industry to develop an open and interoperable strong authentication architecture. This goal is achieved by defining open standards available to all.

The OATH ecosystem is made up of device manufacturers(tokens, chips, smart cards, computers, cell phones, PDAs, tablets, etc.), platform manufacturers (web services, identity managers, application servers, identification federation systems, etc.), application manufacturers (VPN, CRM, ERP, DRM, e-commerce, roaming, Wi-Fi, etc.) and system integrators (ISPs, government agencies, credit card brands, etc.).

Module OATH

The HSM can be used as a seed generator OATH and as an OTP(One Time Password) authenticator. The HSM implementation complies with the standards listed below.

By providing a secure cryptographic boundary, a controlled environment and certified algorithms, HSM offers advantages for adoption in strong authentication systems.

HSM 's OATH module has three basic services: issuing, authentication and resynchronization:

  1. Emission: emission consists of the HSM generating the seed, which causes a blob to be emitted, which is returned to the application for storage in a database. With the blob kept in a database external to the HSM, the issuing process is very flexible, without generating a load on the HSM, and maintaining the necessary secrecy and confidentiality.
  2. Authentication: the module's authentication service is certainly the most used in day-to-day production. When the application needs to perform an authentication, it must retrieve the blob from the database, send it to the HSM and receive the result together with the updated blob, to be returned to the database.
  3. Resynchronization: The resynchronization service essentially involves opening the normal tolerance window and requesting the user to provide OTPs n and n+1.

Generation Scenarios

In the generation and authentication scenarios described below, what changes is the origin of the seed and how it is received by the application for blob creation and sent to the user (either as a seed or embedded in a physical token). Once the blob is created, authentication in any scenario always follows the same format. In the scenarios below, it does not matter whether the token is HOTP or TOTP.

Scenario I

Scenario I: Hardware Token. The seed is generated by the token manufacturer and sent in PSKC format.

  • Generation

    1. Application selects or generates a key master;
    2. Application receives PSKC file and transport key;
    3. Application asks HSM to translate PSKC file into blob;
    4. HSM returns blob;
    5. Application receives the blob, establishes a relationship between the blob and the user, and stores it in the database;
    6. Application dispatches the physical token to the user;
    ---
title: OATH - Geração Cenário I
---

%%{init: {
    'themeVariables': {
        'noteBorderColor': 'red'
        }
    }
}%%

sequenceDiagram
    autonumber
    participant factory as Fabricante<br>do Hardware Token
    participant app as Aplicação
    participant hsm as HSM
    participant db as Base de dados

    factory ->> factory: Geração da Seed
    note over factory: Seed
    factory ->> factory: Envelopa Seed
    destroy factory
    factory ->> app: PSKC +<br>Tranport Key
    app ->> hsm: PSKC +<br>Tranport Key
    app ->> hsm: Seleciona<br>Master Key
    hsm ->> hsm: Tradução<br>PSKC p/ blob
    destroy hsm
    hsm ->> app: blob
    app ->> app: seta relação<br>blob x user
    app ->> db: blob

  • Authentication: see below.

Scenario II

Scenario II: Hardware Token. The seed is generated by the token manufacturer and sent in clear text.

  • Generation

    1. Application selects or generates a key master;
    2. The application receives a seed in clear text;
    3. Application prepares a blob structure OATH;
    4. The application asks the HSM to encrypt the blob OATH with the key master;
    5. HSM returns encrypted data, which is the blob;
    6. Application receives the blob, establishes a relationship between the blob and the user, and stores it in the database;
    7. Application dispatches the physical token to the user;
    ---
title: OATH - Geração Cenário II
---

%%{init: {
    'themeVariables': {
        'noteBorderColor': 'red'
        }
    }
}%%

sequenceDiagram
    autonumber
    participant factory as Fabricante<br>do Hardware Token
    participant app as Aplicação
    participant hsm as HSM
    participant db as Base de dados

    factory ->> factory: Geração da Seed
    note over factory: Seed
    destroy factory
    factory ->> app: Seed<br>em texto claro
    app ->> hsm: Seleciona<br>Master Key
    app ->> app: Prepara<br>blob OATH aberto
    app ->> hsm: blob aberto
    destroy hsm
    hsm ->> app: blob cifrado
    app ->> app: seta relação<br>blob x user
    app ->> db: blob cifrado

  • Authentication: see below.

Scenario III

Scenario III: Software Token. The seed is generated by the user and received in clear text.

  • Generation

    1. Application selects or generates a key master;
    2. User generates and exports seed in their application OATH (smart phone, desktop, etc.);
    3. The user sends the seed to the application;
    4. The application receives a seed in clear text;
    5. Application prepares a data structure OATH;
    6. The application asks the HSM to encrypt the data structure OATH with the key master;
    7. HSM returns an encrypted structure, which is the blob;
    8. Application receives the blob, establishes a relationship between the blob and the user, and stores it in the database;
    ---
title: OATH - Geração Cenário III
---

%%{init: {
    'themeVariables': {
        'noteBorderColor': 'red'
        }
    }
}%%

sequenceDiagram
    autonumber
    actor user as Usuário
    participant app as Aplicação
    participant hsm as HSM
    participant db as Base de dados

    user ->> user: Geração da Seed
    note over user: Seed
    destroy user
    user ->> app: Seed<br>em texto claro
    app ->> hsm: Seleciona<br>Master Key
    app ->> app: Prepara<br>blob OATH aberto
    app ->> hsm: blob aberto
    destroy hsm
    hsm ->> app: blob cifrado
    app ->> app: seta relação<br>blob x user
    app ->> db: blob cifrado

  • Authentication: see below.

Scenario IV

Scenario IV: Software Token. HSM generates the seed.

  • Generation

    1. Application selects or generates a key master;
    2. Application requests blob issue OATH;
    3. HSM generates seed, prepares blob and returns to application;
    4. Application receives the blob, establishes a relationship between the blob and the user, and stores it in the database;
    5. Application sends the blob to HSM and requests the seed in clear text;
    6. The application sends the seed to the user, typically using a secure channel;
    7. User imports seed into their application OATH (smart phone, desktop, etc.);

    ---
title: OATH - Geração Cenário IV
---

%%{init: {
    'themeVariables': {
        'noteBorderColor': 'red'
        }
    }
}%%

sequenceDiagram
    autonumber
    actor user as Usuário
    participant app as Aplicação
    participant hsm as HSM
    participant db as Base de dados

    app ->> hsm: Seleciona<br>Master Key
    app ->> hsm: Solicita blob
    hsm ->> hsm: Gera Seed
    note over hsm: Seed
    hsm ->> app: blob
    destroy hsm
    hsm ->> app: Seed
    app ->> app: seta relação<br>blob x user
    app ->> db: blob
    app ->> user: Seed
    user ->> user: Importa Seed<br>na app local
    - Authentication: see below.

Authentication

User authentication in any scenario follows the same script.

  1. The user presents the generated OTP to the application;
  2. The application retrieves the user's blob from the database and requests verification from the HSM by passing the blob and OTP;
  3. HSM processes request and returns result and processed blob;
  4. The application receives the blob and updates the database;
  5. The application informs the user about the authentication result;
---
title: OATH - Autenticação
---

sequenceDiagram
    autonumber
    actor user as Usuário
    participant app as Aplicação
    participant hsm as HSM
    participant db as Base de dados

    user ->> app: OTP
    db ->> app: blob
    app ->> hsm: blob +<br>OTP
    hsm ->> hsm: Verifica e<br>atualiza blob
    destroy hsm
    hsm ->> app: Resultado +<br>blob atualizado
    app ->> db: blob atualizado
    app ->> user: Resultado

Glossary

  • OTP: (One-Time Password), a single-use password
  • Hardware Token: A physical device that generates OTPs from a seed, typically identified by a unique serial number and keychain-sized. It is tamper-resistant.
  • Software Token: A software-based OTP generator, typically installed on a mobile device (smartphone). It is less secure than a physical token.
  • Seed: A random sequence of bytes used as diversifying cryptographic material for OTP generation. It must be kept secret from generation to use, including during transport. Each hardware token or software token must be associated with a unique seed.
  • Time Step: The interval used as an increment for the TOTP calculation of each OTP. It represents the time in seconds between each OTP generation.
  • Moving Factor: The interval used as an increment for the HOTP calculation of each OTP. It is counted by events.
  • T0: The UNIX time value (seconds since Epoch time) used to initiate the time step count.
  • Truncation Offset: The truncation method of the HMAC calculation used for OTP extraction.
  • HOTP: (HMAC-based One-Time Password Algorithm), an event-based OTP generation standard typically triggered by the user, such as pressing a button on the token; meaning that each time the user presses the button on the token, a new OTP is generated.
  • TOTP: (Time-based One-Time Password Algorithm), a time-based OTP generation standard; a new OTP is generated at each interval defined by the token, regardless of user action.
  • blob(binary large object), an encrypted structure containing information for otp authentication. The blob is completely opaque outside the HSM. The key that encrypts the blob is AES (128, 192 or 256 bits). The information contained in the blob includes the seed, type (HOTP or TOTP), generation interval and start time (in the case of TOTP) and protection mechanisms against replay attacks.
  • resync: the process of adjusting a blob 's internal counters to the values generated by the physical token or soft token in order to keep authentication working correctly. This process is usually done by temporarily increasing the tolerance window and searching for otp values by the HSM, with the user informing two or more otps generated in sequence by the token.
  • key master: AES key in the HSM that encrypts the blob.
  • Transport Key: The key that encrypts the seeds corresponding to the tokens according to the PSKC standard, for transport between the token manufacturer and the system integrator. It is typically derived from a password.
  • PSKC: (Portable Symmetric Key Container), a standard for secure seed transport and delivery, based on symmetric encryption with password-derived keys and an XML format.
  • pskc translation: process of importing the seeds in PSKC format, decrypting them and generating individual blob_s for storage in the database. The translation process of decrypting the PSKC format and encrypting the _blob is carried out within the HSM. Normally a PSKC file contains several seeds encrypted under the same transport key; each seed will correspond to a blob.
  • database: structure for storing the blobs generated by the HSM. This could be, for example, a file system or a DBMS (Database Management System). There is no need for additional protection for the stored blob, as its contents can only be accessed with the master AES key in the HSM.

References

Trade Name

See the Modules topic for the current commercial name of the module; it will be used in presentations, marketing and promotional material, commercial proposals, and contracts.

License

See the Licenses and Modules topics for information on whether a specific license is required to use the module's APIs and what the name of this license is.

API OATH

Specific API documentation for the OATH module, with functions, classes and examples.