Aplicativo

Um aplicativo é executado dentro de um espaço de endereço único. Todos os encadeamentos de controle estão em execução no aplicativo. Um aplicativo se torna um aplicativo Cryptoki chamando a função de Cryptoki C_Initialize de um dos encadeamentos. Depois que essa chamada for feita, o aplicativo poderá chamar outras funções de Cryptoki. Quando o aplicativo termina de usar o Cryptoki, ele chama a função Cryptoki C_Finalize e deixa de ser um aplicativo do Cryptoki.

Se você estiver executando um aplicativo Java PKCS #11 usando o provedor SunPKCS11 na plataforma IBM Z (s390x), certise-se de usar a mais recente JVM IBM Semeru e especificar a opção -Xjit:noResumableTrapHandler Java ao iniciar sua aplicação. Você pode baixar a versão mais recente do s390x da JVM do IBM Semeru alterando o campo de filtro Architecture para s390x na página IBM Semeru Runtime Downloads.

Usuário

O padrão PKCS #11 define dois tipos de usuários para login: um oficial de segurança (OS) e um usuário normal.Se um usuário não efetuar login usando a função de Cryptoki C_Login, ele também será conhecido como um usuário anônimo. Somente o usuário normal pode acessar objetos privados no token, e esse acesso é concedido somente após o usuário normal ser autenticado. Na implementação do PKCS n.º 11 dos Hyper Protect Crypto Services, os responsáveis pela segurança e os usuários normais são autenticados por chaves de API. Os usuários anônimos também são suportados.Para obter instruções sobre como configurar os tipos de usuário do PKCS n.º 11, consulte Melhores práticas para configurar os tipos de usuário do PKCS n.º 11.

Sessão

A API Cryptoki requer que um aplicativo abra uma ou mais sessões com um token para obter acesso aos objetos e funções do token. Uma sessão fornece uma conexão lógica entre o aplicativo e o token. Uma sessão pode ser uma sessão de leitura/gravação (R/W) ou uma sessão somente leitura (R/O).

Para obter acesso aos objetos privados do token, o usuário normal precisa efetuar login e é autenticado Consulte PKCS #11 Cryptographic Token Interface Usage Guide para obter uma visão detalhada das sessões.

Objeto de chave

Os objetos de chave são armazenados no keystore na memória que reside no aplicativo PKCS #11 ou em um keystore com suporte de banco de dados.Se o atributo CKA_TOKEN for configurado como true para o objeto chave, este será armazenado no keystore suportado por banco de dados. Caso contrário, o objeto chave será armazenado no keystore na memória.

Os objetos de chave no keystore na memória não são girados automaticamente após a rotação da chave mestra. Se os armazenamentos de chaves PKCS #11 estiverem ativados em sua instância de serviço, será necessário reiniciar todos os aplicativos PKCS #11 ativos para limpar o keystore na memória após a rotação da chave mestra ser concluída.

Como mostrado no diagrama a seguir, um objeto chave do PKCS n.º 11 é um exemplo de uma classe de objeto do PKCS n.º 11:

• Dados: um objeto de dados é definido por um aplicativo.
• Certificados: um objeto de certificado armazena um certificado.
• Chaves: um objeto chave armazena uma chave criptográfica. A chave pode ser uma chave pública, uma chave privada ou uma chave secreta. Cada tipo dessas chaves tem subtipos para uso em mecanismos específicos.
  • Chave pública: o componente público de um par de chaves que é usado por qualquer pessoa para criptografar mensagens destinadas a um destinatário particular que tenha acesso à chave privada do par de chaves. A chave pública também é usada para verificar assinaturas criadas pela chave privada.
  • Chave privada: o componente privado de um par de chaves que é usado para decriptografar mensagens. A chave privada também é usada para criar assinaturas.
  • Chave secreta: uma chave secreta é um fluxo gerado de bits que é usado para criptografar e decriptografar mensagens simetricamente.

Cloud Identity and Access Management

O IBM Cloud Identity and Access Management (IAM) fornece autenticação de usuário e controle de acesso para a implementação da API PKCS n.º 11. Usando chaves de API, a biblioteca PKCS #11 obtém tokens de portador que são usados para executar chamadas de API Cryptoki.

Essa implementação do PKCS n.º 11 equivale a uma chave de API com o PIN de um usuário. Para obter mais informações sobre como configurar o ID de serviço e a chave de API correspondente, consulte Criar IDs de serviço para o usuário do SO, o usuário normal e o usuário anônimo.

Serviço de criptografia

Como parte do processo de inicialização da biblioteca PKCS n.º 11, uma conexão gRPC é feita da biblioteca PKCS n.º 11 para a IBM Cloud. A conexão gRPC facilita a biblioteca PKCS #11 para chamar funções Cryptoki, como C_Encrypt, C_Decrypt, C_Sign e C_Verify, que requer o uso de um Hardware Security Module (HSM).

Keystore

Dois tipos principais de keystores estão disponíveis:

• Keystores na memória: armazena objetos de chave temporariamente na memória. Os objetos chave que são armazenados no keystore na memória também são conhecidos como objetos de sessão. Os objetos de sessão em uma sessão específica são destruídos quando você chama a função C_CloseSession para aquela sessão. Os objetos de sessão em todas as sessões são destruídos depois que a função C_Finalize é chamada.
• Keystores com backup no banco de dados: armazena objetos de chave em bancos de dados. Os objetos chave que são armazenados no keystore suportado por banco de dados também são conhecidos como objetos de token. Se o parâmetro sessionauth estiver ativado e uma senha para o keystore estiver configurada, o keystore apoiado pelo banco de dados será criptografado e autenticado. Por padrão, o parâmetro sessionauth é desativado.. Para cada instância de serviço, um máximo de cinco keystores autenticados são suportados. É possível ativar o parâmetro sessionauth para criptografar as chaves geradas no keystore ou para descriptografar a chave antes de usá-la. A senha pode ser de 6 a 8 caracteres.

As senhas do keystore não são armazenadas na instância de serviço. Você, como administrador do keystore, é responsável por manter uma cópia local das senhas. Se uma senha for perdida, é necessário entrar em contato com a equipe de suporte para redefinir o keystore, o que significa que todos os dados no keystore serão limpos.

Tanto os keystores na memória quanto os keystores com backup no banco de dados são compostos pelos tipos de keystores seguir:

• Keystore público: armazena chaves que são menos sensíveis e que devem ser acessadas por quaisquer tipos de usuário.
• Keystore privado: restaura chaves que criptografam dados sensíveis e que devem ser acessadas somente por usuários normais.

Dependendo dos tipos de usuário e configurações de atributos de chave, as chaves geradas são armazenadas em keystores diferentes. A lista a seguir resume os critérios de como as chaves são armazenadas:

• O valor de atributo CKA_TOKEN decide se a chave gerada é armazenada em um keystore na memória ou em um keystore com backup no banco de dados.

  Se você quiser armazenar a chave no keystore com backup no banco de dados, configure CKA_TOKEN para TRUE em modelos de geração de par de chaves ou de chave. O processo de inicialização da biblioteca PKCS n.º 11 estabelece uma conexão do gRPC com a IBM Cloud, o que facilita o armazenamento e a recuperação de objetos chave do keystore suportado por banco de dados. Por padrão, o CKA_TOKEN é configurado como FALSE, o que significa que o objeto chave é armazenado em um keystore na memória dentro do espaço de endereço do processo do aplicativo PKCS #11.

• O valor de atributo CKA_PRIVATE decide se uma chave que é gerada por usuários normais deve ser armazenada em um keystore público ou privado.

  Por padrão, se um usuário tiver efetuado login como um usuário normal, as chaves geradas serão armazenadas nos keystores privados, exceto caso o CKA_PRIVATE seja configurado como FALSE. Se um usuário tiver efetuado login como um usuário do S.O. ou não tiver efetuado login (conhecido como um usuário anônimo), as chaves geradas serão sempre armazenadas nos keystores públicos. Se um usuário do SO ou um usuário anônimo especificar CKA_PRIVATE para TRUE nos modelos de geração de chaves, um erro será retornado do servidor.

  Para um par de chaves assimétrica, é necessário configurar o atributo CKA_PRIVATE separadamente para as chaves públicas e privadas, o que significa que os pares de chaves podem ser armazenados em keystores diferentes.

Consulte a tabela a seguir para obter explicações detalhadas da relação entre os tipos de usuário, os atributos de chave e os keystores e como as chaves são armazenadas.