OATH
A iniciativa OATH (Open Authentication) é um colaboração suportada por diversos membros da indústria de segurança para desenvolver uma arquitetura aberta e interoperável de autenticação forte. Este objetivo é conseguido pela definição de padrões abertos disponíveis para todos.
O ecossistema OATH é composto de fabricantes de dispositivos (tokens, chips, smart cards, computadores, celulares, PDAs, tablets etc), fabricantes de plataformas (serviços web, gerenciadores de identidade, servidores de aplicação, sistemas de federação de identificação etc), fabricantes de aplicações (VPN, CRM, ERP, DRM, comércio eletrônico, roaming, wi-fi etc) e integradores de sistema (ISPs, órgãos de governo, bandeiras de cartão de crédito etc).
Módulo OATH
O HSM pode ser utilizado como gerador de sementes OATH e como autenticador de OTPs (One Time Password). A implementação do HSM está de acordo com os padrões listados abaixo.
Por prover uma fronteira criptográfica segura, ambiente controlado e algoritmos homologados o HSM apresenta vantagens na sua adoção em sistema de autenticação forte.
O módulo OATH do HSM tem três serviços básicos: emissão, autenticação e ressincronização:
Emissão: a emissão consiste da geração da semente pelo HSM, o que promove a emissão de um blob, que é devolvido para a aplicação para guarda em base de dados. Com o blob mantido em base da dados externa ao HSM, o processo de emissão fica bastante flexível, sem gerar carga no HSM, e mantendo o sigilo e a confidencialidade necessária.
Autenticação: o serviço de autenticação do módulo é certamente o mais utilizado no dia a dia da produção. A aplicação quando precisar realizar uma autenticação dever recuperar o blob na base de dados, enviá-lo ao HSM e receber o resultado juntamente com o blob atualizado, para ser devolvido à base de dados.
Ressincronização: o serviço de ressincronização consiste basicamente em abrir a janela de tolerância normal, e solicitar que o usuário informe os OTPs n e n+1.
Cenários de Geração e Autenticação
Nos cenários de geração e autenticação descritos abaixo o que muda é a origem da semente e como ela é recebida pela aplicação para criação do blob e enviada ao usuário (como semente ou embarcada em token físico). Uma vez criado o blob a autenticação em qualquer cenário segue sempre o mesmo formato. Nos cenários abaixo não importa se o token é HOTP ou TOTP.
Cenário I - Hardware Token: a semente é gerada pelo fabricante do token e enviada em formato PSKC
Geração
Aplicação seleciona ou gera uma chave master;
Aplicação recebe arquivo PSKC e chave de transporte;
Aplicação solicita ao HSM tradução do arquivo PSKC para blob;
HSM retorna blob;
Aplicação recebe o blob, cria relação entre blob e usuário e guarda em base de dados;
Aplicação despacha o token físico para o usuário;
Autenticação
Vide abaixo;
Cenário II - Hardware Token: a semente é gerada pelo fabricante do token e enviada em texto claro
Geração
Aplicação seleciona ou gera uma chave master;
Aplicação recebe uma semente em texto claro;
Aplicação prepara uma estrutura de blob OATH;
Aplicação solicita ao HSM criptografia do blob OATH com a chave master;
HSM retorna dado cifrado, que é o blob;
Aplicação recebe o blob, cria relação entre blob e usuário e guarda em base de dados;
Aplicação despacha o token físico para o usuário;
Autenticação
Vide abaixo;
Cenário III - Software Token: a semente é gerada pelo usuário e recebida em texto claro
Geração
Aplicação seleciona ou gera uma chave master;
Usuário gera e exporta semente em sua aplicação OATH (smart phone, desktop, etc);
Usuário envia semente para aplicação;
Aplicação recebe uma semente em texto claro;
Aplicação prepara uma estrutura de dados OATH;
Aplicação solicita ao HSM criptografia da estrutura da dados OATH com a chave master;
HSM retorna estrutura cifrada, que é o blob;
Aplicação recebe o blob, cria relação entre blob e usuário e guarda em base de dados;
Autenticação
Vide abaixo;
Cenário IV - Software Token: HSM gera a semente
Geração
Aplicação seleciona ou gera uma chave master;
Aplicação solicita emissão de blob OATH;
HSM gera semente, prepara blob e retorna para a aplicação;
Aplicação recebe o blob, cria relação entre blob e usuário e guarda em base de dados;
Aplicação envia o blob para HSM e solicita a semente em texto claro;
Aplicação envia a semente para o usuário, normalmente usando algum canal seguro;
Usuário importa semente para sua aplicação OATH (smart phone, desktop, etc);
Autenticação
Vide abaixo;
Autenticação do usuário em qualquer cenário:
Usuário apresenta OTP gerado para aplicação;
Aplicação recupera blob do usuário a partir da base de dados e solicita verificação ao HSM passando blob e OTP;
HSM processa pedido e devolve resultado e o blob processado;
Aplicação recebe o blob e atualiza a base de dados;
Aplicação informa usuário sobre resultado da autenticação;
Glossário
otp: (one time password), senha de uso único
hardware token: dispositivo físico gerador de otp a partir de uma semente, normalmente identificado através de número serial único e com tamanho de um chaveiro. É resistente à violação.
software token: dispositivo gerador de otp em software, normalmente instalado em dispositivo móvel (smart phone). É menos seguro que o token físico.
semente: sequência aleatória de bytes usado como material criptográfico diversificador para a geração de otp. Deve ser mantida secreta, desde a geração até a utilização, incluindo o transporte. Cada hardware token ou software token deve ser associado a uma única semente.
time step: intervalo utilizado como incremento do cálculo TOTP de cada OTP. O tempo em segundos entre cada geração de OTP.
moving factor: intervalo utilizado como incremento do cálculo HOTP de cada OTP. Contado por eventos.
T0: valor UNIX time (segundos desde o EPOCH time) para iniciar a contagem de time steps.
truncation offset: método de truncagem do cálculo HMAC para extração do OTP.
HOTP: (HMAC-based One-time Password Algorithm) padrão de geração de otp a por evento, normalmente disparado pelo usuário, como por exemplo o apertar de um botão no token, ou seja, a cada vez que o usuário pressiona o botão no token, um novo otp é gerado.
TOTP: (Time-based One-time Password Algorithm) padrão de geração de otp por tempo; um novo otp é gerado a cada intervalo definido pelo token, independente de ação de usuário.
blob: (binary large object), estrutura criptografada contendo informações para autenticação de otp. O blob é totalmente opaco fora do HSM. A chave que criptografa o blob é uma AES (128, 192 ou 256 bits). Entre as informações que vão no blob estão a semente, o tipo (HOTP ou TOTP), intervalo de geração e tempo inicial (no caso de TOTP) e mecanismos de proteção contra ataque de replay.
resync: processo de ajuste dos contadores internos de um blob com os valores gerados pelo token físico ou soft token que visa manter a autenticação funcionando corretamente. Normalmente este processo é feito aumentando temporariamente a janela de tolerância e busca de valores de otp pelo HSM, com o usuário informando dois ou mais otps gerados em sequência pelo token.
chave master: chave AES no HSM que criptografa o blob.
chave de transporte: chave que criptografa as sementes correspondentes aos tokens conforme o padrão PSKC, para o transporte entre o fabricante do token e o integrador de sistemas. Normalmente é derivada de senha.
pskc: (Portable Symmetric Key Container), padrão de transporte e entrega segura de sementes, baseado em criptografia simétrica com derivação de chave por senha e formato XML.
tradução pskc: processo de importação das sementes em formato PSKC, decriptografia e geração de _blob_s individuais para armazenamento em base de dados. O processo de tradução da decriptografia do formato PSKC e criptografia no blob é realizado dentro do HSM. Normalmente um arquivo PSKC contém diversas sementes cifradas sob a mesma chave de transporte; a cada semente irá corresponder um blob.
base de dados: estrutura para armazenamento dos blobs gerados pelo HSM. Pode ser por exemplo um sistema de arquivos ou um SGBD (Sistema de Gerenciamento de Banco de Dados). Não há necessidade de proteção adicional para o blob armazenado, pois seu conteúdo só pode ser acessado com a chave master AES no HSM.
Referências
Last updated