Análise aprofundada do princípio e prática das chaves RSA

I. Introdução

Depois de passar pelos momentos mais sombrios de sua vida, você leu este artigo, vai se arrepender e até ficar com raiva: Por que você não escreveu este artigo antes? !

Seus momentos mais sombrios incluem:

1. Seu projeto precisa estar conectado ao banco e a outra parte precisa que você forneça um certificado de criptografia. Você só tem um certificado CET-6 em inglês e não tem certeza se isso atende às necessidades da outra parte. Por não ter conseguido entregar o atestado correto, o projeto foi adiado, o plano de aumento salarial foi arruinado, a mensalidade foi cortada e sua namorada se separou, você sente que sua vida acabou.

2. Você tem 2 meses de idade e finalmente entendeu o certificado de formato .crt. Junte-se ao novo projeto, o projeto está passando por uma transformação de tutela de certificado. Haha, vou fazer isso, que é carregar o arquivo do certificado para o sistema de hospedagem. Você grita para os membros da equipe do projeto, larguem esses certificados e me deixem ir! Aperte e veja que é um projeto antigo. Não há nenhum certificado. Naquela época, as chaves públicas e privadas eram usadas. Como as chaves públicas e privadas se tornam certificados ... Como você não conseguiu fornecer o certificado correto, o projeto foi adiado , O plano de aumento de salário foi arruinado, a mensalidade foi cortada e a namorada se separou Você sente que sua vida acabou.

3. Você passou 3 meses tentando entender os meandros do certificado SSL. Sentindo-se confiante para ingressar em um novo projeto, você contou ao gerente de projeto uma história dolorosa de sangue e lágrimas. Depois dessa batalha, você se tornou um especialista em certificação de segurança. O gerente de projeto ficou muito feliz. Acontece que o projeto estava passando por uma transformação de segurança de dados. O banco de dados precisava ser habilitado com SSL. Era hora de chegar. Não se preocupe, apenas forneça alguns arquivos importantes antes do trabalho amanhã. Quanto mais amanhã, meia hora antes do final do trabalho, você caminha lentamente até o gerente de projeto, "As mercadorias que você deseja chegaram", e três certificados são liberados. Este é o arquivo de chave, este é o arquivo de chave pública e este é o arquivo de certificado. O gerente de projeto assentiu e balançou a cabeça.O que eu quero é um arquivo JKS. Você disse que estará disponível amanhã. Quanto mais amanhã, meia hora antes do trabalho, você entrega o arquivo no formato JKS ao gerente do projeto. O gerente do projeto assentiu e balançou a cabeça. E a senha? E se não houver senha? Por não ter conseguido entregar o atestado correto, o projeto foi adiado, o plano de aumento salarial foi arruinado, a mensalidade foi cortada e sua namorada se separou, você sente que sua vida acabou.

Este artigo revelará os segredos pouco conhecidos dos arquivos de chave RSA nas seguintes partes:

• Base matemática do algoritmo RSA
• Modelo de seis camadas do sistema de chave RSA
• Uso de ferramenta RSA
• Cenários de uso de chave RSA

Nota: Embora a chave e o certificado não sejam idênticos no sentido estrito, para conveniência de apresentação, o termo chave neste artigo abrange os conceitos de chave pública, chave privada, certificado, etc., a menos que especificado de outra forma.

2. Base matemática do algoritmo RSA

O algoritmo RSA é baseado na teoria dos números.A complexidade do algoritmo RSA é baseada no fato de que a decomposição de números primos de um grande número é um problema NP, que é muito difícil de decifrar. Conceitos matemáticos relacionados ao algoritmo RSA:

Para qualquer número x, y pode ser calculado:

Por meio de y, x pode ser calculado:

Em outras palavras, depois que x gerar y por meio do par de números (m, e), você pode reduzir y para x por meio do par de números (m, d).

Aqui, realmente demonstramos o processo matemático de criptografia e descriptografia RSA. Por meio da fórmula (1), o processo de cálculo de y a partir de x é criptografia e, por meio da fórmula (2), o processo de cálculo de x a partir de y é a descriptografia.

Em aplicações práticas, o algoritmo RSA usa a chave pública para criptografar e a chave privada para descriptografar, portanto, o número de pares (m, e) é a chave pública e (m, d) é a chave privada.

Na verdade, para aumentar a velocidade de descriptografia da chave privada, a chave privada salva alguns resultados intermediários, como p, q, e e assim por diante.

Portanto, em aplicações práticas, a chave pública pode ser derivada da chave privada.

Três, modelo chave RSA de seis camadas

Para facilitar a compreensão do princípio das chaves RSA, inventei de forma criativa o conceito do modelo de seis camadas das chaves RSA. Cada camada define suas próprias responsabilidades e limites: quanto mais baixo o nível, mais abstrato e teórico o conteúdo que representa; quanto mais alto o nível, mais as aplicações práticas são representadas.

• Dados: a camada de dados define os conceitos matemáticos das chaves RSA (m, e, p, q, etc.) ou entidades participantes (assunto, emissor, etc.).
• Serialização: a camada de serialização define um método para serializar estruturas de dados complexas.
• Estrutura: A camada de estrutura define a forma de organização dos dados das chaves RSA em diferentes formatos.
• Texto: a camada de texto define o método de conversão da chave binária em texto.
• Apresentação: camada de apresentação , que define a forma de apresentação da chave de formato de texto.
• Aplicação: a camada de aplicação define vários cenários para o uso de chaves RSA.

Cada camada será explicada em detalhes abaixo.

3.2 Camada de dados

Do exposto acima, a chave secreta é uma estrutura de dados, cada estrutura contém 2 ou mais membros (a chave pública contém mee, e a chave privada contém m, d, e e alguns outros resultados intermediários). Para salvar essas estruturas de dados em um arquivo, você precisa definir um formato para serializar a chave secreta.

3.3 Camada de serialização

Atualmente, os formatos comuns para definir estruturas de dados incluem formatos de texto como JSON e XML.

Por exemplo, teoricamente, podemos definir a chave pública como JSON:

Chave de formato JSON

{
    "m":"15",
    "e":"3"
}

Ou você pode definir a chave privada como um XML:

<?xml>
<key>
    <module>15</module>
    <e>3</e>
    <d>3</d>
    <p>3</p>
    <q>5</q>
<key>

Mas quando o RSA foi inventado, nenhum desses dois formatos ainda existia. Portanto, os cientistas escolheram ASN.1, o formato de sintaxe mais popular na época.

3.3.1 ASN.1

O nome completo de ASN.1 é Abstract Syntax Notation ponto um, (a primeira edição de Abstract Syntax Notation). O número 1 é adicionado à parte de trás do ASN pela ISO para manter a abertura do ASN, permitindo que o ASN mais poderoso seja denominado ASN.2 no futuro, mas ainda não apareceu.

ASN.1 descreve um formato de dados para representar, codificar, transmitir e decodificar dados. Ele fornece um conjunto de formatos formais para descrever a estrutura dos objetos, independentemente de como a linguagem é executada e da referência específica desses dados, e não precisa se preocupar com o tipo de aplicação.

3.3.2 Regras de codificação ASN.1

A sintaxe específica do ASN.1 pode referir-se à Wikipedia (https://zh.wikipedia.org/wiki/ASN.1 ), aqui está apenas uma breve descrição.

A representação do tipo de dados em ASN.1 está na forma de TLV: os primeiros 2 bytes representam o tipo de dados, os próximos 2 bytes representam o comprimento do byte e V representa o valor específico. Os tipos básicos comuns incluem Integer, UTF8String e as estruturas compostas incluem SEQUENCE, SET. Tanto a chave secreta quanto o certificado são do tipo SEQUENCE, e o tipo de SEQUENCE é 0x30 e o comprimento é maior que 127, portanto, o segundo byte é 0x82. Os dados representados pela codificação ASN.1 são dados binários, que geralmente são convertidos em uma string por BASE64 e armazenados em um arquivo pem, e 0x3082 é codificado por BASE64, é a string MI, então os primeiros dois caracteres da chave secreta armazenados em todos os arquivos PEM É MI.

BER, CER, DER são regras de codificação ASN.1. Entre eles, DER (Distinguish Encode Rules) é uma regra de codificação inequívoca para garantir que os resultados de serialização produzidos pela mesma estrutura de dados também sejam os mesmos.

ASN.1 apenas define o método de serialização de dados abstratos, mas a codificação específica precisa de definição adicional.

A rigor, ASN.1 não é um formato de definição de dados, mas um padrão gramatical, de acordo com esse padrão, vários formatos podem ser formulados.

3.4 Camada estrutural

De acordo com as diferentes finalidades do arquivo de chave, os padrões a seguir definem diferentes estruturas para codificar os dados de chave no ASN.1. De modo geral, diferentes formatos de chaves implicam em diferentes estruturas.

• pkcs # 1 é  usado para definir a chave pública RSA e a estrutura de chave privada
• pkcs # 7 é  usado para definir a cadeia de certificação
• pkcs # 8 é  usado para definir as chaves públicas e privadas de qualquer algoritmo
• pkcs # 12 é  usado para definir o certificado de chave privada
• X.509  define certificados de chave pública

Para as diferenças específicas entre esses formatos, consulte 3.5.2 abaixo

3.5 Camada de apresentação

Você pode ver que ASN.1 e suas regras de codificação (BER, CER, DER) definem regras binárias, que também estão em formato binário quando armazenadas em um arquivo. Como o padrão de e-mail naquela época não suportava a transmissão de conteúdo binário, se o arquivo de chave secreta for transmitido por e-mail, o arquivo binário precisa ser convertido em um arquivo de texto. Esta é a origem do PEM (Privacy-Enhanced Mail). Portanto, o conteúdo da chave secreta salvo no arquivo PEM é o conteúdo binário gerado pela codificação ASN.1 e, a seguir, o texto codificado em base64.

Além disso, para facilitar ao usuário a identificação do formato, uma linha de texto indicando a identidade é adicionada ao início e ao final do arquivo chinês. Um arquivo PEM geralmente contém três partes: a primeira linha de rótulos, dados de texto codificados em BASE64 e a última linha de rótulos.

-----BEGIN <label>-----
<BASE64 ENCODED DATA>
-----END <label>-----

Para formatos diferentes, o valor de <label> é diferente.

3.5.2 Resumo do formato de arquivo PEM

3.6 Camada de aplicação

No uso real, não é apenas necessário usar chaves públicas e privadas para criptografar e descriptografar dados, mas também resolver a distribuição e verificação de chaves de acordo com diferentes cenários de uso. A seção 5 lista alguns cenários comuns de uso de chaves RSA.

Quatro, ferramentas

4.1 openssl

Nota: As opções -RSAPublicKey_in e -RSAPublicKey_out nos comandos a seguir precisam ser suportadas pelo openssl1.0 ou superior. Se um erro for relatado, verifique a versão do openssl.

4.1.1 Criar um arquivo de chave

# 生成 pkcs#1 格式2048位的私钥
openssl genrsa -out private.pem 2048

#从私钥中提取 pkcs#8 格式公钥
openssl rsa -in private.pem -out public.pem -pubout

#从私钥中提取 pkcs#1 格式公钥
openssl rsa -in private.pem -out public.pem -RSAPublicKey_out

4.1.2 Conversão de formato de arquivo de chave secreta

#pkcs#1 公钥转换成 pkcs#8 公钥
openssl rsa -in public.pem -out public-pkcs8.pem -RSAPublicKey_in

#pkcs#8 公钥转换成 pkcs#1 公钥
openssl rsa -in public-pkcs8.pem -out public-pkcs1.pem -pubin -RSAPublicKey_out

#pkcs#1 私钥转换成 pkcs#8 私钥
openssl pkcs8 -in private.pem -out private-pkcs8.pem -topk8

#pkcs#8 私钥转换成 pkcs#1 私钥
openssl rsa -in private-pkcs8.pem -out private-pkcs1.pem

4.1.3 Ver informações do arquivo principal

#查看公钥信息
openssl rsa -in public.pem -pubin -text -noout

#查看私钥信息
openssl rsa -in private.pem -text -noout

4.1.4 Certificado

Certificado RSA

#从现有私钥创建 CSR 文件
openssl req -key private.pem -out request.csr -new

#从现有 CSR 文件和私钥中创建证书,有效期365天
openssl x509 -req -in request.csr -signkey private.pem -out cert.crt -days 365

#生成全新证书和私钥
openssl req -nodes -newkey rsa:2048 -keyout root.key -out root.crt -x509 -days 365

#通 过 现 有 证 书 和 私 钥 （作 为CA ） 为 其 他 CSR 文 件 签 名
openssl x509 -req -in child.csr -days 365 -CA root.crt -CAkey root.key -set_serial 01 -out child.crt

#查看证书信息
openssl x509 -in child.crt -text -noout

#从证书中提取公钥
openssl x509 -pubkey -noout -in child.crt  > public.pem

4.1.5 JKS

#将CA证书转换成JKS格式
keytool -importcert -alias Cacert -file ca.crt  -keystore truststoremysql.jks -storepass password123

#将client.crt和client.key转换成PKCS#12格式
openssl pkcs12 -export -in client.crt -inkey client.key -name "mysqlclient" -passout pass:mypassword -out client-keystore.p12

#将PKCS#12格式转换成JKS格式
keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 -srcstorepass mypassword -destkeystore clientstore.jks -deststoretype JKS -deststorepass password456

Cinco, cenários de uso de chave RSA

Autenticação unilateral 5.1 HTTPS

Como o protocolo HTTP é uma transmissão de texto simples, para garantir que a mensagem HTTP não vaze e seja adulterada, o HTTPS criptografa e descriptografa a mensagem HTTP por meio do protocolo SSL / TLS.

Para simplificar, o protocolo HTTPS requer que, durante o processo de estabelecimento de uma conexão entre o cliente e o servidor, uma chave de sessão seja trocada primeiro e, em seguida, a chave de sessão seja usada para criptografar e descriptografar a mensagem de comunicação. Todo o processo de comunicação é o seguinte:

1. O servidor cria o certificado RSA server.crt e a chave privada server.key através do método mostrado em 4.1.4, e os configura no servidor WEB.

2. O cliente estabelece uma conexão com o servidor e o servidor envia o certificado server.crt para o cliente.

3. O cliente verifica o certificado do servidor e gera aleatoriamente uma chave de sessão, criptografa a chave de sessão com o certificado do servidor e a transmite ao servidor.

4. O servidor descriptografa a chave de sessão criptografada por meio de server.key para obter o texto original da chave de sessão.

5. O cliente criptografa a mensagem HTTP com a chave de sessão e a transmite ao servidor.

6. O servidor descriptografa a mensagem criptografada HTTP usando a chave de sessão para obter o texto original da mensagem HTTP.

7. O servidor criptografa a mensagem de resposta HTTP com a chave de sessão e a retorna ao cliente.

8. O cliente usa a chave de sessão para descriptografar a mensagem de resposta HTTP para obter o texto original da mensagem de resposta HTTP.

(Figura 1. Autenticação HTTPS unilateral)

5.2 Autenticação mútua HTTPS

O cenário HTTPS descrito na Seção 5.1 é um cenário geral. Todo o processo consiste apenas em o cliente verificar o servidor, ou seja, após o cliente obter o certificado do servidor, ele verificará a validade do certificado, como se está assinado por uma CA e se ainda está dentro do período de validade. Espere lá dentro. Essa verificação unilateral não é um problema em cenários como o acesso do navegador, porque esse serviço foi projetado para fornecer serviços a dezenas de milhares de usuários. No entanto, em alguns cenários, como fornecer serviços apenas para empresas e comerciantes específicos, o servidor precisa verificar o cliente, e o cliente confiável que passa na verificação pode ser normal.

Ao acessar o servidor, a autenticação HTTPS bidirecional é necessária.

O processo de autenticação HTTPS bidirecional visa aprimorar a autenticação do servidor para o cliente com base na autenticação HTTPS unilateral. A ideia da solução é que o cliente salve o certificado do cliente client.crt, mas o certificado do cliente não é assinado pelo próprio cliente ou assinado pela CA, mas sim pela root.key do servidor. Durante o processo de autenticação bidirecional HTTPS, o cliente precisa enviar o certificado do cliente client.crt para o servidor, e o servidor usa root.key para verificar se está correto antes de prosseguir com a comunicação subsequente; caso contrário, o cliente é um cliente não confiável. O servidor se recusa a fornecer serviços de acompanhamento.

O processo de comunicação específico é o seguinte:

1. O servidor cria o certificado RSA server.crt e a chave privada server.key através do método mostrado em 4.1.4, e os configura no servidor WEB.

2. O cliente estabelece uma conexão com o servidor e o servidor envia o certificado server.crt para o cliente.

3. O cliente verifica o certificado do servidor e o processo subsequente continua depois que a verificação é aprovada; a conexão é desconectada se a verificação falhar e o processo termina.

4. O servidor envia uma mensagem ao cliente solicitando que ele envie um certificado de cliente.

5. O cliente envia o certificado do cliente ao servidor.

6. O servidor verifica o certificado do cliente por meio de root.key, e a verificação está correta para o processo subsequente; caso contrário, a conexão é desconectada e o processo termina.

7. O cliente gera aleatoriamente uma chave de sessão, criptografa a chave de sessão com o certificado do servidor e a transmite ao servidor.

8. O servidor descriptografa a chave de sessão criptografada por meio de server.key para obter o texto original da chave de sessão.

9. O cliente criptografa a mensagem HTTP com a chave de sessão e a transmite ao servidor.

10. O servidor descriptografa a mensagem criptografada HTTP usando a chave de sessão para obter o texto original da mensagem HTTP.

11. O servidor criptografa a mensagem de resposta HTTP com a chave de sessão e a retorna ao cliente.

12. O cliente usa a chave de sessão para descriptografar a mensagem de resposta HTTP para obter o texto original da mensagem de resposta HTTP.

Pode ser visto que, em comparação com o processo de autenticação HTTPS unilateral, o processo de autenticação HTTPS bidirecional aumentará o cliente para enviar o cliente do certificado do cliente para o servidor após o cliente verificar o certificado do servidor e antes de enviar a chave de sessão criptografada para o servidor. .crt, o processo de verificação do certificado pelo servidor.

(Figura 2. Autenticação HTTPS bidirecional)

5.3 MySQL habilita SSL

O princípio de que o MySQL fornece SSL é semelhante ao HTTPS. A diferença é que o serviço fornecido pelo MySQL não terá como alvo milhares de usuários comuns, portanto, a demanda por CA não é alta.

Portanto, o certificado CA real geralmente é gerado pelo próprio servidor.

Semelhante ao HTTPS, o MySQL fornece duas formas de mecanismos de autenticação SSL: autenticação unilateral e autenticação bidirecional.

5.3.1 Autenticação SSL unilateral do MySQL

(1) Arquivos de configuração do servidor: ca.crt, server.crt, server.key, onde server.crt é gerado pela assinatura de ca.crt.

(2) Arquivos de configuração do cliente: ca.crt, ca.crt é o mesmo que ca.crt no lado do servidor.

(3) Cliente gera arquivo JKS

keytool -importcert -alias Cacert -file ca.crt -keystore truststoremysql.jks -storepass password123

(4) Configurar opções SSL e arquivos JKS por meio da string jdbc

verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststoremysql.jks&trustCertificateKeyStorePassword=password123

5.3.2 Autenticação SSL bidirecional MySQL

(1) Arquivos de configuração do servidor: ca.crt, server.crt, server.key, onde server.crt é gerado pela assinatura ca.crt.

(2) Arquivos de configuração do cliente: ca.crt, client.crt, client.key, onde ca.crt é o mesmo que ca.crt no lado do servidor e client.crt é gerado pela assinatura de ca.crt.

(3) O cliente gera o arquivo trustKeyStore

keytool -importcert -alias Cacert -file ca.crt -keystore truststore.jks -storepass password123

(4) O cliente gera o arquivo clientKeyStore

keytool -importcert -alias Cacert -file ca.crt -keystore clientstore.jks -storepass password456

(5) Configurar opções SSL e arquivos JKS por meio da string jdbc

verifyServerCertificate=true&useSSL=true&requireSSL=true&trustCertificateKeyStoreUrl=file:./truststore.jks&trustCertificateKeyStorePassword=password123&clientCertificateKeyStoreUrl=file:./clientstore.jks&clientCertificateKeyStorePassword=password456

Para obter mais detalhes sobre a certificação SSL do MySQL, consulte:

• https://www.howtoforge.com/tutorial/how-to-enable-ssl-and-remote-connections-for-mysql-on-centos-7/

• https://www.cnblogs.com/ccgood/p/13034426.html

Apêndice A codificação ASN.1 em diferentes formatos

A.1 pkcs # 1

A.1.1 Chave pública

RSAPublicKey ::= SEQUENCE {
    modulus INTEGER , -- n
    publicExponent INTEGER -- e
}

A.1.2 Chave privada

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
}

A.2 pkcs # 8

A.2.1 chave pública pkcs # 8

PublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier ,
    PublicKey BIT STRING
}
AlgorithmIdentifier ::= SEQUENCE {
    algorithm OBJECT IDENTIFIER ,
    parameters ANY DEFINED BY algorithm OPTIONAL
}

A.2.2 chave privada pkcs # 8

OneAsymmetricKey ::= SEQUENCE {
    version Version ,
    privateKeyAlgorithm PrivateKeyAlgorithmIdentifier ,
    privateKey PrivateKey ,
    attributes [0] Attributes OPTIONAL ,
    ...,
    [[2: publicKey [1] PublicKey OPTIONAL ]],
    ...
}
PrivateKey ::= OCTET STRING
    -- Content varies based on type of key. The
    -- algorithm identifier dictates the format of
    -- the key.

A.3 X.509

Certificado A.3.1 X.509

Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate ,
    signatureAlgorithm AlgorithmIdentifier ,
    signatureValue BIT STRING
}

TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber ,
    signature AlgorithmIdentifier ,
    issuer Name,
    validity Validity ,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo ,
    issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL ,
        -- If present , version MUST be v2 or v3
    subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL ,
        -- If present , version MUST be v2 or v3
     extensions [3] EXPLICIT Extensions OPTIONAL
        -- If present , version MUST be v3
}

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

Validity ::= SEQUENCE {
    notBefore Time,
    notAfter Time
}

Time ::= CHOICE {
    utcTime UTCTime ,
    generalTime GeneralizedTime
}

UniqueIdentifier ::= BIT STRING

SubjectPublicKeyInfo ::= SEQUENCE {
    algorithm AlgorithmIdentifier ,
    subjectPublicKey BIT STRING
}

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER ,
    critical BOOLEAN DEFAULT FALSE ,
    extnValue OCTET STRING
        -- contains the DER encoding of an ASN.1 value
        -- corresponding to the extension type identified
        -- by extnID
}

Autor: Zhu Ran, da equipe de tecnologia da Internet vivo