Obrigado pelos seus comentários.

Como usamos o formato JWE

Esta seção descreve como esperamos que o JWE seja criado como entrada para os dispositivos, para que você possa criar sua própria ferramenta para criar os blobs a partir de seus certificados e chaves.

Consulte JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 e JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Usamos a serialização compacta de um documento JSON para criar blobs JWE. Os parâmetros que você precisa incluir ao criar os blobs do JWE são:

• Cabeçalho JOSE (protegido). No cabeçalho JSON Object Signing and Encryption, você DEVE incluir os seguintes pares de valores-chave:

  • “alg”: “dir”

    O algoritmo direto é o único que suportamos para criptografar a carga, e você deve usar o segredo inicial do cliente do dispositivo.

  • “enc” :"A128GCM” ou “enc” :"A256GCM”

    Oferecemos suporte a esses dois algoritmos de criptografia.

  • “cisco-action”: “adicionar” ou “cisco-action”: “preencher” ou “cisco-action”: “ativar” ou “cisco-action”: “desativar”

    Essa é uma chave proprietária e quatro valores que ela pode assumir. Introduzimos essa chave para sinalizar a finalidade dos dados criptografados para o dispositivo de destino. Os valores são nomeados de acordo com os comandos xAPI no dispositivo em que você está usando os dados criptografados.

    Nós o chamamos de cisco-action para mitigar possíveis conflitos com futuras extensões do JWE.

  • “cisco-kdf”: {“versão”: “1", “salt”: “base64URLencodedRandom4+bytes”}

    Outra chave proprietária. Usamos os valores que você fornece como entradas para derivação de chave no dispositivo. A versão deve ser 1 (a versão da nossa função de derivação de chave). O valor de salt deve ser uma sequência codificada em URL base64 de pelo menos 4 bytes, que você deve escolher aleatoriamente.

• Chave criptografada JWE. Esse campo está vazio. O dispositivo o deriva do ClientSecret inicial.

• Vetor de inicialização do JWE. Você deve fornecer um vetor de inicialização codificado em base64url para descriptografar a carga. O IV DEVE ser um valor aleatório de 12 bytes (estamos usando a família de cifras AES-GCM, que exige que o IV tenha 12 bytes de comprimento).

• JWE AAD (dados autenticados adicionais). Você deve omitir esse campo porque ele não é suportado na serialização compacta.

• Texto cifrado do JWE: Essa é a carga criptografada que você deseja manter em segredo.

  A carga pode estar vazia. Por exemplo, para redefinir o segredo do cliente, você precisa substituí-lo por um valor vazio.

  Existem diferentes tipos de cargas úteis, dependendo do que você está tentando fazer no dispositivo. Comandos xAPI diferentes esperam cargas diferentes, e você deve especificar a finalidade da carga com a chave cisco-action, da seguinte forma:

  • Com “cisco-action” :"populate”, o texto cifrado é o novo ClientSecret.

  • Com "“cisco-action” :"add”, o texto cifrado é um blob PEM que carrega o certificado e sua chave privada (concatenada).

  • Com "“cisco-action” :"activate”, o texto cifrado é a impressão digital (representação hexadecimal de sha-1) do certificado que estamos ativando para verificação da identidade do dispositivo.

  • Com "“cisco-action” :"deactivate”, o texto cifrado é a impressão digital (representação hexadecimal de sha-1) do certificado que estamos desativando de ser usado para verificação de identidade do dispositivo.

• Tag de autenticação JWE: Esse campo contém a tag de autenticação para verificar a integridade de todo o blob JWE serializado de forma compacta

Como derivamos a chave de criptografia do ClientSecret

Após o primeiro preenchimento do segredo, não aceitamos nem exibimos o segredo como texto simples. Isso é para evitar possíveis ataques de dicionário por alguém que possa acessar o dispositivo.

O software do dispositivo usa o segredo do cliente como entrada para uma função de derivação de chave (kdf) e, em seguida, usa a chave derivada para decodificação/criptografia de conteúdo no dispositivo.

O que isso significa para você é que sua ferramenta para produzir blobs JWE deve seguir o mesmo procedimento para derivar a mesma chave de criptografia/descriptografia do segredo do cliente.

Os dispositivos usam scrypt para derivação de chave (consulte https://en.wikipedia.org/wiki/Scrypt), com os seguintes parâmetros:

• CostFactor (N) é 32768

• BlockSizeFactor (r) é 8

• O fator de paralelização (p) é 1

• Salt é uma sequência aleatória de pelo menos 4 bytes; você deve fornecer esse mesmo sal ao especificar o parâmetro cisco-kdf.

• Os comprimentos das chaves são 16 bytes (se você selecionar o algoritmo AES-GCM 128) ou 32 bytes (se você selecionar o algoritmo AES-GCM 256)

• O limite máximo de memória é de 64 MB

Esse conjunto de parâmetros é a única configuração do scrypt compatível com a função de derivação de chave nos dispositivos. Esse kdf nos dispositivos é chamado de “versão” :"1", que é a única versão atualmente usada pelo parâmetro cisco-kdf.

Exemplo resolvido

Aqui está um exemplo que você pode seguir para verificar se o processo de criptografia do JWE funciona da mesma forma que o processo que criamos nos dispositivos.

O cenário de exemplo é adicionar um blob PEM ao dispositivo (imita a adição de um certificado, com uma string muito curta em vez de uma chave cert + completa). O segredo do cliente no exemplo é ossifrage.

1. Escolha uma cifra de criptografia. Este exemplo usa A128GCM (AES com chaves de 128 bits no modo contador de Galois). Sua ferramenta pode usar o A256GCM se você preferir.

2. Escolha um sal (deve ser uma sequência aleatória de pelo menos 4 bytes). Este exemplo usa (bytes hexadecimais) E5 E6 53 08 03 F8 33 F6. base64URL codifique a sequência para obter 5eZtcap4m_y (remova o preenchimento base64).

3. Aqui está um exemplo de chamada scrypt para criar a chave de criptografia de conteúdo (cek):

   cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

   A chave derivada deve ter 16 bytes (hexadecimal) da seguinte forma: 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac, que base64url codifica para LZ66bdeiaqv4_mqdinj_ra.

4. Escolha uma sequência aleatória de 12 bytes para usar como vetor de inicialização. Este exemplo usa (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83, que base64url codifica para nlnd3v9te68tkPwd.

5. Crie o cabeçalho JOSE com serialização compacta (siga a mesma ordem de parâmetros que usamos aqui) e, em seguida, codifice-o em base64url:

   {"alg” :"dir”, "cisco-action” :"add”, "cisco-kdf”: {"salt” :"5eztcap4M_y”, "version” :"1"}, "enc” :"A128GCM "}

   O cabeçalho JOSE codificado em base64url é EYJHBGCIOIJKAxiIlcjjaxnjby1hy3rpb24ioijhzgqilcjjaxnjby1rzgyionsic2fsdci6ijvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoedqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoedqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoedqva0tv9ziiwidmvyc2lvbii6ijeifsWizw5jijoDTsJ9

   Esse será o primeiro elemento do blob do JWE.

6. O segundo elemento do blob do JWE está vazio, porque não estamos fornecendo uma chave de criptografia do JWE.

7. O terceiro elemento do blob do JWE é o vetor de inicialização NLND3v9te68tkPwd.

8. Use sua ferramenta de criptografia JWE para produzir uma carga e uma tag criptografadas. Neste exemplo, a carga não criptografada será o falso blob PEM, este é um arquivo PEM.

   Os parâmetros de criptografia que você deve usar são:

   • Carga útil é este é um arquivo PEM

   • A cifra de criptografia é AES 128 GCM

   • O cabeçalho JOSE codificado em base64url como Dados Autenticados Adicionais (AAD)

   Base64url codifica a carga criptografada, o que deve resultar em F5llVuwnfkfmzyco1yjFodHQ

   Esse é o quarto elemento (texto cifrado do JWE) no blob do JWE.

9. base64URL codifica a tag que você produziu na etapa 8, o que deve resultar em pe-wdfwgxffbeo928cfz1Q

   Esse é o quinto elemento no blob do JWE.

10. Concatene os cinco elementos do blob JWE com pontos (joseHeader.. iv.ciphertext.TAG) para obter:

    eyjhbgcioijkaxiiLcjjaxnjby1hy3rpb24ioijhzgqilcjjaxnjby1rzgyionSIC2fsdci6ijvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoeddtsj.. 9nlnd3v9te68tkpwd.f5llvuwnfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1q

11. Se você derivou os mesmos valores codificados em base64url que mostramos aqui, usando suas próprias ferramentas, você está pronto para usá-los para proteger a criptografia E2E e a identidade verificada de seus dispositivos.

12. Na verdade, esse exemplo não funcionará, mas, em princípio, sua próxima etapa seria usar o blob JWE que você criou acima como entrada para o comando no dispositivo que adiciona o certificado:

    Certificados de segurança do XCommand Adicione eyjhbgcioijkaxiiLcjjaxnjby1hy3rpb24ioijhzgqilcjjaxnjby1rzgyionsic2fsdci6ijvlwlrdqva0tv9ziiwidmvyc2lvbii6ijeifswizw5jijoiqteyoEddtsj. 9nlnd3v9te68tkpwd.f5llvuwnfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1Q