Pular para conteúdo

Integração via PKCS#11

Introdução

PKCS#11 (Public Key Cryptography Standards número 11) define uma API também chamada de Cryptoki (Cryptographic Token Interface Standard) que é utilizada para gerenciar ciclo de vida de chaves e realizar operações criptográficas dentro de um dispositivo.

Estas APIs padronizadas permitem que aplicações utilizem serviços de criptografia independentemente dos fornecedores de dispositivos.

A PKCS#11 Dinamo permite a integração entre uma aplicação que utilize o padrão e o HSM. Esta Cryptoki é construída sobre a API nativa do HSM e disponibiliza os algoritmos presentes no HSM.

A partir da versão 3.1.0 da suíte cliente do HSM e da versão 3.9.0.0 do firmware a implementação foi atualizada em sua arquitetura.

Atenção

É necessário que a versão da biblioteca PKCS#11 e do firmware do HSM estejam compatíveis para fazer a migração para esta nova versão.

Se você possui versões anteriores à 3.1.0 do cliente, 2.0.0.0 da biblioteca PKCS#11 Dinamo e/ou versão do firmware do HSM Dinamo anterior à 3.9.0.0 e quer migrar para a nova versão, por favor entre em contato com o suporte do seu fornecedor.

Visão Geral

Inicialmente, com o aumento do uso de dispositivos de criptografia portáveis (SmartCards, Tokens, PCMCIA...) foi identificada a necessidade de uma API (Application Programming Interface) padrão de criptografia que permitisse a interoperabilidade entre aplicações e os diversos dispositivos e fabricantes.

A PKCS#11 veio para resolver esse problema de forma simplificada, portável e com APIs de alto nível, definindo interfaces e comportamentos básicos de tokens.

Com o passar do tempo a PKCS#11 foi largamente utilizada e se tornou padrão de mercado para dispositivos que guardam e performam operações criptográficas e passou a ser utilizada inclusive com HSMs.

Os objetivos da PKCS#11 são:

  • Visão simples e voltada para objetos criptográficos.
  • Independência de tecnologia. Poder usar qualquer dispositivo.
  • Compartilhamento de recursos. Múltiplas aplicações podem usar múltiplos dispositivos. Permite o uso de tokens criptográficos diferentes sem alterar o código da aplicação.
  • Visão lógica comum do dispositivo, chamado de "Token Criptográfico".
  • Portabilidade. Funciona em diversos sistemas operacionais.
  • Definir tipos de objetos e seus atributos.
  • Definir operações criptográficas.

Informações da API Cryptoki PKCS#11:

  • Linguagem: ANSI C
  • Nome da API: Cryptoki, PKCS#11
  • Mantenedor: OASIS
  • Formato: Biblioteca (pode ser dinâmica ou estática)
  • Headers: pkcs11.h inclui os arquivos pkcs11t.h e pkcs11f.h

Modelo Geral

Passos para uma aplicação executar uma operação criptográfica no modelo PKCS#11:

  1. Carrega uma biblioteca Cryptoki (uma dll no windows ou um so no linux);
  2. Faz uma chamada à alguma de suas APIs;
  3. Essa chamada passa por um Slot;
  4. E finalmente acessa chega ao token.
---
title: Modelo Geral Cryptoki
---

%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%

flowchart TD

    classDef red_s stroke:#f00
    App1[Aplicação 1]
    Appk[Aplicação k]
    p11.1[Biblioteca PKCS#11<br>#40;CryptoKi#41;]
    p11.2[Biblioteca PKCS#11<br>#40;CryptoKi#41;]
    sync[Contenção/Sincronização]
    slot1[Slot 1]
    slotk[Slot k]
    token1[Token 1<br>#40;Device 1#41;]
    tokenk[Token k<br>#40;Device k#41;]

    App1 --> p11.1
    Appk --> p11.2
    p11.1 --> sync
    p11.2 --> sync
    sync --> slot1
    sync --> slotk
    slot1 --> token1
    slotk --> tokenk

O Slot corresponde a um leitor físico (ex.: uma leitora de smart cards). O token corresponde a um dispositivo (ex.: um smart card).

Slots e tokens são representações lógicas.

A biblioteca Cryptoki da PKCS#11 é definida em C. Para acessar a Cryptoki a partir de outra linguagem (Java, .Net etc) é necessário que se faça uma interface entre as linguagens. Há no mercado várias integrações PKCS#11 em diversas linguagens, são fáceis de encontrar e algumas delas são inclusive nativas.

Nota

O Dinamo tem apenas um Slot que é o de número 1.

Visão Lógica do Token

A Cryptoki divide os objetos em 3 classes:

  • Dados
  • Certificados
  • Chaves

As chaves podem ser:

  • Públicas
  • Privadas
  • Secretas
---
title: Hierarquia de Objetos
---

%%{ init: { 'flowchart': { 'curve': 'bumpY' } } }%%

flowchart TD

    classDef red_s stroke:#f00
    obj[Objeto]
    data[Dado]
    key[Chave]
    cert[Certificado]
    pubk[Chave Pública]
    privk[Chave Privada]
    seck[Chave Secreta]

    obj --> data
    obj --> key
    obj --> cert
    key --> pubk
    key --> privk
    key --> seck

    linkStyle 0,1,2,3,4,5 stroke-width:1px;

Os objetos também podem ser divididos:

  • Por tempo de vida
  • Objetos de token: são persistentes. Permanecem no token mesmo se a sessão for fechada;
  • Objetos de sessão: são temporários. O objeto deixa de existir quando a sessão, que o criou, é fechada.
  • Por nível de acesso
    • Objetos privados: podem ser acessados apenas se o usuário estiver autenticado;
    • Objetos públicos: podem ser acessados até com uma sessão não autenticada.

O Dinamo não permite acessar um objeto sem que o usuário esteja devidamente autenticado. Todos os objetos são, arquiteturalmente, privados.

Objetos também possuem atributos específicos de acordo com cada tipo, como por exemplo, o módulo ou expoente de uma chave RSA.

As implementações de Cryptoki não são obrigadas a implementar todos os objetos e mecanismos. É esperado que haja uma adequação lógica da implementação da Criptoki para se adequar às particularidades das definições na PKCS#11.

Usuários

A PKCS#11 define 2 tipos de usuários:

  • Security Officer - faz as operações administrativas, como inicializar o token, definir o PIN de um usuário normal e possivelmente manipular objetos públicos.
  • Usuário comum - tem acesso aos objetos privados (apenas quando o usuário está autenticado).

No Dinamo usuários operadores e comuns podem criar e utilizar objetos privados. Não há distinção de tipos.

O usuário que será utilizado pela Criptoki é definido via configuração ou alternativamente via parâmetro de senha.

A operação de inicialização de token não é suportada via Criptoki e por isso pode ser desconsiderada. No HSM a inicialização é feita via console local.

A definição de PIN não é suportada via Criptoki e por isso pode ser desconsiderada. A criação/alteração do PIN é feita apenas no momento da criação do usuário ou quando alterado pelo próprio usuário.

Threads

Atenção: Afinidade Sessão-Thread

As sessões do HSM possuem afinidade sessão-thread. O que significa que a mesma sessão não pode ser utilizada em várias threads ao mesmo tempo.

As sessões podem fazer apenas uma operação por vez. Isso significa que não se pode fazer múltiplas chamadas simultâneas à Criptoki utilizando a mesma sessão. O recomendado é abrir uma sessão por thread ou garantir que a sessão seja utilizada para fazer apenas uma operação por vez.

A Criptoki Dinamo utiliza mecanismo de locking próprio.

Sessão

As sessões podem ser Read-Only (R/O) ou Read-Write (R/W). O Read-only se refere aos objetos de token.

  • Read-Only: é possível apenas ler objetos de token.
  • Read-Write: é possível criar, ler, escrever e destruir objetos de sessão e de token.

No Dinamo não há distinção de sessões Read-Only e Read-Write. O usuário sempre tem permissão total sobre o seus objetos.

As sessões podem ser autenticadas ou não autenticadas.

  • Autenticada: O usuário tem permissão sobre os objetos públicos e privados.
  • Não-Autenticada: O usuário tem permissão apenas sobre os objetos públicos.

No Dinamo apenas se visualiza os objetos do próprio usuário, e ele deve ser autenticado.

Detalhes Adicionais

Chaves privadas e chaves secretas podem ser marcadas como sensitive ou unextractable:

  • sensitive: a chave pode ser exportada, mas apenas de forma encriptada.
  • unextractable: a chave não pode ser exportada de nenhuma maneira.

O Dinamo apenas tem a opção de a chave ser exportável ou não, independente da forma de exportação. As opções da PKCS#11 extractable e sensitive são relacionadas com a opção de chaves exportáveis no HSM. Ex.: uma chave sensitive não pode ser exportada nem mesmo de forma encriptada.

PKCS#11 HSM Dinamo

De acordo com as definições da PKCS#11 não é esperado que uma implementação Criptoki suporte todas as opções. A Criptoki do Dinamo irá disponibilizar as operações que o HSM oferece e que são suportadas pela especificação PKCS#11.

Os mecanismos suportados pelo HSM podem ser vistos aqui.

Algumas detalhes de implementação Dinamo foram resumidas abaixo.

  • Compatível com a versão v2.40 da PKCS#11;
  • Permite uso de usr:senha@ip no lugar da senha, caso a opção esteja habilitada.
  • Tem apenas um Slot (número 1).
  • Label do token fixo como "Dinamo HSM".
  • Permite o acesso à objetos apenas por sessões autenticadas.
  • Usuários operadores e comuns podem criar e utilizar objetos privados. Não há distinção de tipos.
  • A Criptoki Dinamo utiliza locking próprio.
  • Inicialização de token e definição de PIN podem ser desconsiderados. São feitas via configurações no próprio equipamento.
  • O usuário que será utilizado pela Criptoki é definido via configuração ou alternativamente via parâmetro de senha.
  • O usuário sempre tem permissão total sobre os seus objetos. Não há distinção entre sessão Read-Only e Read-Write.
  • Não há opção de sessões não autenticadas.
  • Veja a lista de possíveis configurações da Criptoki Dinamo para mais detalhes.
  • Chaves apenas tem a opção de serem exportáveis ou não, independente da forma de exportação. As opções extractable e sensitive são relacionadas com a opção de chaves exportáveis. Ex.: uma chave sensitive não pode ser exportada nem mesmo de forma encriptada.

Referências