Dezembro 26, 2020
Articles
Sem comentários

Existe uma especificação para o formato “ BEGIN RSA PRIVATE KEY ”?

Até agora não encontrei uma especificação (RFC ou semelhante) para o formato de arquivo que usa o prefixo BEGIN RSA PRIVATE KEY e o sufixo END RSA PRIVATE KEY . Onde está definido? Existe um nome oficial para ele? Parece estar pelo menos relacionado à série de RFCs PEM.

Estou procurando informações de referência sobre os detalhes do tratamento de espaços em branco, detalhes de base64 , junção de chaves diferentes em um arquivo, etc.

Esta pergunta NÃO é sobre a codificação ASN da carga útil.

Comentários

  • A especificação OpenPGP descreve formatos ASCII-Armor semelhantes.
  • tls.mbed.org/kb/cryptography/asn1-key-structures-in- der-and-pem
  • A maioria dos formatos PEM (também diferentes da chave privada RSA) estão documentados em RFC 7468: Codificações textuais de Estruturas PKIX, PKCS e CMS . Existem, por exemplo, algumas orientações sobre o tratamento de espaços em branco. Esse RFC basicamente observa esses detalhes variam de acordo com o analisador.
  • Graças ao user4982: Este é o tipo de fonte que estou procurando. No entanto, RFC 7468 contém informações sobre o rótulo ” CHAVE PRIVADA CRIPTOGRAFADA “, mas não ‘ t para ” chave privada RSA “.
  • PEM é definido em RFC 1421 que descreve o formato geral do cabeçalho, etc. Mas não consegui ‘ encontrar sobre o ” CHAVE PRIVADA RSA “. Este artigo de 1997 já menciona o uso do OpenSSL.

Resposta

Estou aqui porque estou me perguntando a mesma coisa que o OP.

PKCS # 1 (RFC 3447) define a estrutura ASN.1: RSAPrivateKey, permitindo a expressão de uma chave privada RSA apenas.

PKCS # 8 (RFC 5208) define a estrutura ASN.1: PrivateKeyInfo, permitindo a expressão de qualquer chave privada. (Para uma chave privada RSA, PrivateKeyInfo é algumas informações de pacote e uma reutilização de RSAPrivateKey de PKCS # 1).

PEM (Privacy Enhanced Mail), é um método extinto para email seguro. Porém, seu formato de contêiner foi emprestado para empacotar itens criptográficos.

RFC 7468 (Introdução): “ Por razões que basicamente se resumem a não coordenação ou desatenção, muitas bibliotecas PKIX, PKCS e CMS implementar uma codificação baseada em texto que seja semelhante – mas não idêntica à – codificação PEM . “

Que se lê como: Hum, as pessoas decidiram usar pedaços de PEM para empacotar seus arquivos criptográficos . Aqui, temos um grande esforço para tentar formalizar que …

Infelizmente, a RFC 7468 esclarece o pacote PKCS # 8 / PrivateKeyInfo como “BEGIN PRIVATE KEY”. Mas não o pacote de PKCS # 1 / RSAPrivateKey como “BEGIN RSA PRIVATE KEY”.

O pacote “BEGIN RSA PRIVATE KEY” às vezes é chamado de: “formato SSLeay” ou “formato tradicional” para chave privada. O que, pelo menos, nos dá um nome para esse formato, mas, como você, não consigo encontrar, e gostaria de receber, algo que se aproxima de uma descrição formal desse formato. Suspeito que isso não exista.

Comentários

  • I'm here, because, I'm asking myself the same question as the OP. – – Para esclarecer: esta é sua resposta para a pergunta feita acima ou você está realmente se perguntando a mesma coisa?

Resposta

O formato do conteúdo base64 dentro: 

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

está documentado em RFC3447 – Apêndice A.1.2 – Sintaxe de chave privada RSA : 

RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponent INTEGER, -- e privateExponent INTEGER, -- d prime1 INTEGER, -- p prime2 INTEGER, -- q exponent1 INTEGER, -- d mod (p-1) exponent2 INTEGER, -- d mod (q-1) coefficient INTEGER, -- (inverse of q) mod p otherPrimeInfos OtherPrimeInfos OPTIONAL }

Você já sabe como codificar isso usando o DER sabor de ASN.1; e a questão é sobre como realmente gravar esses dados binários DER em um arquivo.

A próxima etapa está documentada em RFC 1421 – 4.3.2.4 Etapa 4 : Codificação para impressão

  • eles documentam a codificação dos dados binários em base64
  • codificando a saída como linhas de texto
  • com cada linha ( exceto o último) contendo exatamente 64 caracteres imprimíveis
  • e a linha final contendo 64 ou menos caracteres imprimíveis

Existe então o “Limite de encapsulamento” (EB), usado para delimitar mensagens PEM encapsuladas.

  • a string pré-EB é: -----BEGIN PRIVACY-ENHANCED MESSAGE-----
  • a string pós-EB é: -----END PRIVACY-ENHANCED MESSAGE-----

Era o padrão Privacy Enhanced Mail que usava:

  • cinco hífens (-----)
  • BEGIN something
  • cinco hífens (-----)

seguido por

  • cinco hífens (-----)
  • END something
  • cinco hífens (-----)

Essas convenções PEM foram transportadas para chave pública, chave privada e certificados, mas com texto alterado: 

-----BEGIN RSA PUBLIC KEY----- ...base64 encoded DER ASN.1 RSAPublicKey... -----END RSA PUBLIC KEY-----

  

-----BEGIN RSA PRIVATE KEY----- ...base64 encoded DER ASN.1 RSAPrivateKey... -----END RSA PRIVATE KEY-----

  

-----BEGIN PUBLIC KEY----- ...base64 encoded DER ASN.1 SubjectPublicKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN PRIVATE KEY----- ...base64 encoded DER ASN.1 PrivateKeyInfo... -----END PUBLIC KEY-----

  

-----BEGIN CERTIFICATE----- ...base64 encoded DER ASNl.1 Certificate... -----END CERTIFICATE-----

Resposta

Sim. RFC7468 – Codificações textuais de estruturas PKIX, PKCS e CMS

Este documento articula as regras de fato pelas quais as implementações existentes operam e as define para que as implementações futuras possam interoperar.

Aqui “um trecho relevante:

10. Uma chave assimétrica e a codificação textual de informações da chave privada PKCS # 8

Estruturas de sintaxe de informações de chave privada PKCS # 8 não criptografadas (PrivateKeyInfo), renomeadas para Pacotes de chaves assimétricas (OneAsymmetricKey), são codificadas usando o rótulo “PRIVATE KEY”. Os dados codificados DEVEM ser um BER ( DER preferencial; consulte o Apêndice B) estrutura ASN.1 PrivateKeyInfo codificada conforme descrito em PKCS # 8 [RFC5208], ou uma estrutura OneAsymmetricKey conforme descrito em [RFC5958]. Os dois são semanticamente idênticos e podem ser distinguidos pelo número da versão. 

-----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ -----END PRIVATE KEY-----

Comentários

  • Estou perguntando sobre a ” CHAVE PRIVADA RSA “, não sobre ” PEDIDO DE CERTIFICADO “. A propósito, eu esperaria PKCS # 8 ou PKCS # 1, não PKCS # 10. O Capítulo 10 estaria mais perto. Mas não ‘ não especifica RSA no rótulo, portanto, faz sentido usar PKCS # 8 aqui. Como o algoritmo da chave seria especificado de forma redundante, poderia ser OK (e eu vi exemplos) colocar PKCS # 1 em uma ” RSA PRIVATE KEY ” arquivo.
  • @Como eu já disse, estou procurando por ” chave privada RSA “, não para ” CHAVE PRIVADA “. Portanto, mesmo o capítulo 10 não é aplicável e RFC7468 é uma resposta errada.
  • @Gustave I ‘ estou ciente de que você escreveu ” RSA PRIVATE KEY “, no entanto, especificar o formato da chave privada no cabeçalho é desnecessário e a especificação é relevante.
  • O ABNF lê < < textualmsg = preeb * WSP (…) > > e < < preeb = ” —- -BEGIN ” rótulo ” —– ” (…) > >. Então, por que você acha que o cabeçalho é desnecessário?
  • PKCS # 1 ( tools.ietf.org/html/rfc8017#apêndice-A.1.2 ) não ‘ t especifica qualquer codificação ASCII base64 e também não ‘ t especifica o -----BEGIN RSA PRIVATE KEY----- cabeçalho. PKCS # 8 também não ‘ t especifica qualquer codificação ASCII base64. O Capítulo 10 realmente especifica -----BEGIN PRIVATE KEY-----. Você tem um link para um padrão que especifica o cabeçalho -----BEGIN RSA PRIVATE KEY-----?

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *