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 basically consists of opening the normal tolerance window and asking the user to enter 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 to create the blob and sent to the user (as a seed or embedded in a physical token ). Once the blob has been created, authentication in any scenario always follows the same format. In the scenarios below, it doesn't 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 blob, creates relationship between blob and user and stores in database;
    6. The application sends 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. 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 blob, creates relationship between blob and user and stores in database;
    7. The application sends 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. User sends seed to application;
    4. 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 blob, creates relationship between blob and user and stores in 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 blob, creates relationship between blob and user and stores in database;
    5. Application sends the blob to HSM and requests the seed in clear text;
    6. The application sends the seed to the user, usually 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. User submits generated OTP to 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. Application informs user of 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), one-time password
  • hardware token: physical device that generates otp from a seed, usually identified by a unique serial number and the size of a keychain. It is tamper-resistant.
  • software token: device that generates otp in software, usually installed on a mobile device(smart phone). It is less secure than the physical token.
  • seed: random sequence of bytes used as diversifying cryptographic material for generating otp. It must be kept secret from generation to use, including transportation. Each hardware token or software token must be associated with a single seed.
  • time step: interval used to increment the TOTP calculation for each OTP. The time in seconds between each OTP generation.
  • moving factor: interval used as an increment in the HOTP calculation for each OTP. Counted by events.
  • T0: UNIX time value (seconds from EPOCH time) to start counting time steps.
  • truncation offset: method of truncating the HMAC calculation to extract the OTP.
  • HOTP: (HMAC-based One-time Password Algorithm) standard for generating otp per event, usually triggered by the user, such as pressing a button on the token, i.e. each time the user presses the button on the token, a new otp is generated.
  • TOTP: (Time-based One-time Password Algorithm) standard for generating otp by time; 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: 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 usually derived from a password.
  • pskc: (Portable Symmetric Key Container), a standard for the secure transport and delivery of seeds, based on symmetric cryptography with password key derivation and 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

API OATH

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