Segurança de comunicação interna

Comandos entre os hosts de serviço ou operadores AWS KMS e HSMs são protegidos por meio de dois mecanismos exibidos em Sessões autenticadas: um método de solicitação assinado por quórum e uma sessão autenticada usando um protocolo de host de serviço HSM.

Os comandos assinados por quórum são projetados para que nenhum operador único possa modificar as proteções de segurança críticas fornecidas pelos HSMs. Os comandos executados nas sessões autenticadas ajudam a garantir que apenas operadores de serviço autorizados possam executar operações envolvendo chaves KMS. Todas as informações secretas vinculadas ao cliente são protegidas na infraestrutura AWS.

Estabelecimento de chaves

Para proteger as comunicações internas, o AWS KMS usa dois métodos de estabelecimento de chave diferentes. O primeiro é definido como C(1, 2, ECC DH) na Recomendação para Esquemas de Estabelecimento de Chave em Par usando Criptografia de Logaritmo Discreto (Revisão 2). Este esquema tem um iniciador com uma chave de assinatura estática. O iniciador gera e assina uma chave efêmera curva elíptica Diffie-Hellman (ECDH) destinada a um destinatário com uma chave de acordo ECDH estática. Este método usa uma chave efêmera e duas chaves estáticas usando ECDH. Essa é a derivação do rótulo C(1, 2, ECC DH). Este método, às vezes, é chamado de ECDH de uma passagem.

O segundo método de estabelecimento de chave é C(2, 2, ECC, DH). Neste esquema, ambas as partes têm uma chave de assinatura estática e geram, assinam e trocam uma chave ECDH efêmera. Este método usa duas chaves estáticas e duas chaves efêmeras, cada uma usando ECDH. Essa é a derivação do rótulo C(2, 2, ECC, DH). Este método é, por vezes, chamado ECDH efêmero ou ECDHE. Todas as chaves ECDH são geradas na curva secp384r1 (NIST-P384).

Limite de segurança do HSM

O limite interno de segurança do AWS KMS é o HSM. O HSM tem uma interface proprietária e nenhuma outra interface física ativa em seu estado operacional. Um HSM operacional é implantado durante a inicialização com as chaves criptográficas necessárias para estabelecer sua função no domínio. Materiais criptográficos sensíveis do HSM são armazenados somente na memória volátil e apagados quando o HSM sai do estado operacional, incluindo desligamentos ou reinicializações intencionais ou não.

As operações da API do HSM são autenticadas por comandos individuais ou por uma sessão confidencial mutuamente autenticada estabelecida por um host de serviço.

Comandos assinados por quórum

Comandos assinados por quórum são emitidos por operadores para os HSMs. Esta seção descreve como os comandos baseados em quórum são criados, assinados e autenticados. Estas regras são bastante simples. Por exemplo, o comando Foo requer dois membros da função Bar para ser autenticado. Há três etapas na criação e verificação de um comando baseado em quórum. A primeira etapa é a criação inicial do comando; a segunda é o envio a operadores adicionais para assinar e a terceira é a verificação e execução.

Com a finalidade de introduzir os conceitos, suponha que existe um conjunto autêntico de chaves públicas e funções do operador {QOS_s} e um conjunto de regras de quórum QR = {Comando_i, Regra_{{i, t}}} onde cada Regra é um conjunto de funções e número mínimo N {Função_t, N_t}. Para que um comando satisfaça a regra de quórum, o conjunto de dados de comando deve ser assinado por um conjunto de operadores listados em {QOS_s} de forma que atendam a uma das regras listadas para esse comando. Como mencionado anteriormente, o conjunto de regras de quórum e operadores são armazenados no estado de domínio e no token de domínio exportado.

Na prática, um signatário inicial assina o comando Sig₁ = Sign(dO_p1, Comando). Um segundo operador também assina o comando Sig₂ = Sign(dO_p2, Comando). A mensagem duplamente assinada é enviada para um HSM para execução. O HSM executa o seguinte:

1. Para cada assinatura, ele extrai a chave pública do signatário do estado do domínio e verifica a assinatura no comando.

2. Ele verifica se o conjunto de signatários satisfaz a uma regra para o comando.

Sessões autenticadas

Suas principais operações-chave são executadas entre os hosts AWS KMS e os HSMs. Esses comandos dizem respeito à criação e uso de chaves criptográficas e geração de números aleatórios seguros. Os comandos são executados em um canal autenticado por sessão entre os hosts de serviço e os HSMs. Além da necessidade de autenticação, essas sessões exigem confidencialidade. Os comandos executados nessas sessões incluem o retorno de chaves de dados de texto não criptografado e mensagens descriptografadas destinadas a você. Para garantir que essas sessões não possam ser subvertidas por meio de man-in-the-middle ataques, as sessões são autenticadas.

Este protocolo executa um contrato de chave ECDHE mutuamente autenticado entre o HSM e o host do serviço. A troca é iniciada pelo host do serviço e concluída pelo HSM. O HSM também retorna uma chave de sessão (SK) criptografada pela chave negociada e um token de chave exportado que contém a chave de sessão. O token de chave exportado contém um período de validade, após o qual o host de serviço deve renegociar uma chave de sessão.

Um host de serviço é um membro do domínio e tem um par de chaves de assinatura de identidade (DHOs_i, QHOS_i) e uma cópia autêntica das chaves públicas de identidade dos HSMs. Ele usa seu conjunto de chaves de assinatura de identidade para negociar com segurança uma chave de sessão que pode ser usada entre o host de serviço e qualquer HSM no domínio. Os tokens de chave exportados têm um período de validade associado após o qual uma nova chave deve ser negociada.

O processo começa com o reconhecimento do host de serviço que requer uma chave de sessão para enviar e receber fluxos de comunicação confidenciais entre ele e um membro do HSM do domínio.

1. Um host de serviço gera um par de chaves efêmero ECDH (d₁, Q₁) e o assina com sua chave de identidade Sig1 = Sign(dOS,Q₁).

2. O HSM verifica a assinatura na chave pública recebida usando seu token de domínio atual e cria um par de chaves efêmero ECDH (d₂, Q₂). Em seguida, ele conclui a troca de chaves ECDH de acordo com a Recomendação para Esquemas de Estabelecimento de Chave em Par usando Criptografia de Logaritmo Discreto (Revisado) para formar uma chave AES-GCM de 256 bits negociada. O HSM gera uma nova chave de sessão AES-GCM de 256 bits. Ele criptografa a chave de sessão com a chave negociada para formar a chave de sessão criptografada (ESK). Ele também criptografa a chave de sessão sob a chave de domínio como um token de chave EKT exportado. Finalmente, ele assina um valor de retorno com seu par de chaves de identidade Sig₂ = Sign(dHsK, (Q₂, ESK, EKT)).

3. O host do serviço verifica a assinatura nas chaves recebidas usando seu token de domínio atual. O host de serviço conclui, então, a troca de chaves ECDH de acordo com a Recomendação para Esquemas de Estabelecimento de Chave em Par usando Criptografia de Logaritmo Discreto (Revisado). Em seguida, ele desencripta o ESK para obter a chave de sessão SK.

Durante o período de validade no EKT, o host de serviço pode usar a chave de sessão negociada SK para enviar comandos criptografados com envelope para o HSM. Cada service-host-initiated comando sobre essa sessão autenticada inclui o EKT. O HSM responde usando a mesma chave de sessão negociada SK.