RenatoMartini.Net

Category: asn.1

Cripto: opções de algoritmos

Fiz um levantamento sem maiores pretensões, diga-se logo, e sem o rigor necessário, o rigor científico requerido para este tipo de levantamento. Mas apenas é ilustrativo de certas tendências na adoção de algoritmos criptográficos para sessões SSL. Se observarmos as maiores empresas de tecnologia da informação, sites de redes sociais e bancos, poderemos, de imediato, perceber que a criptografia de curvas elípticas (ECC) é ainda bastante minoritária. E, por outro lado, o RSA como solução é fortemente dominante.

A tabela abaixo apresenta uma singela amostragem de uso de soluções de algoritmos usados para criptografar uma sessão web e o algoritmo usado para troca de chaves1. O levantamento foi feito basicamente de empresas de Tecnologia da Informação (IBM, Google, Microsoft, HP, etc.), Bancos (Chase, Santander, etc.) e redes sociais (Facebook, Twitter, etc.). A abordagem do OpenSSL ajuda bastante a captura das informações básicas e detalhes de uma sessão SSL, usando o comando openssl s_client -connect URL:PORTA. Por exemplo aqui o site da empresa HP usando um certificado digital Verisign:

[wc_box color="inverse" text_align="left"]

$ openssl s_client -connect www.hp.com:443 CONNECTED(00000003) depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority verify return:1 depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign Class 3 Secure Server CA - G3 verify return:1 depth=0 C = US, ST = CALIFORNIA, L = Palo Alto, O = Hewlett-Packard, OU = Operations, CN = www.hp.com verify return:1 [...]

[/wc_box]

Eliminamos aqui boa parte das informações ecoadas na tela. Ali pode-se capturar como dissemos o certificado do servidor propriamente dito, e até mesmo o "tíquete" da sessão TLS... Aqui vemos informações como o algoritmo suportado (RC4 com SHA), tamanho de chave, etc.

[wc_box color="inverse" text_align="left"]

SSL handshake has read 4932 bytes and written 563 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 9CEA3B3DDE8014D70A31D2D77F1D6E409E6F5A84CF18A7B4A65CE2909EA8A79D Session-ID-ctx: Master-Key: 858E070479836EC29D9E9CF9059C1768FBC10DBE919A5B4194941ECA4BB9D9B233732E6508EF7CCB1848ACF713DB97E

[/wc_box]

Este recurso do OpenSSL permite uma captura automatizada da sessão criptografada, que nossos browsers geralmente apresentam, ainda que em parte e sem grande detalhes técnicos, de modo gráfico. Por exemplo, o dumping do certificado digital do Google, um dos poucos a usarem ECC em seu site web, permite-nos observar o OID da curva utilizada como comentamos em outro artigo. Vejamos uma parte da estrutura em ASN.1 do certificado Google; aqui aparecem dois OIDs do (1) ecPublicKey e o (2) prime256v1:

[wc_box color="inverse" text_align="left"]

249 89: SEQUENCE { 251 19: SEQUENCE { 253 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 262 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) : } 272 66: BIT STRING : 04 02 B6 50 59 6D 64 3E 1E A4 D1 CB B2 12 67 69 : FE DE AF FC 6C 2A 0A 58 75 14 2D 01 7E 35 8B 7B : DF 86 7D BF 13 A2 54 16 44 A5 CF 88 EE C2 2C 93 : F8 E6 AD FD 82 4E 3D E2 14 E4 DF 8D D7 03 80 EA : 49 : }

[/wc_box]

O OID "1 2 840 10045 3 1 7" identifica uma curva de 256-bit da família prime padronizada pelo "Accredited Standards Committee X9" ANSI X92, designada pelo OpenSSL como sendo prime256v1: X9.62/SECG curve over a 256 bit prime field. Note-se que, portanto, o Google não usa aqui uma curva NIST... Abaixo a representação do certificado Google no browser chrome.

Apresentação do certificado Google...

Apresentação do certificado Google...

O RFC 44923 introduz uma série de algoritmos para troca ou agreements de chaves. A tabela abaixo mostra a série de algoritmos de troca de chaves e suas verientes segundo o RFC citado:

[wc_box color="inverse" text_align="left"]

Algoritmos de troca de chaves Descrição
ECDH_ECDSA ECDH fixo com certificados assinados ECDSA.
ECDHE_ECDSA ECDH efêmero com assinaturas ECDSA.
ECDH_RSA ECDH fixo certificados assinados RSA.
ECDHE_RSA ECDH efêmero com assinaturas RSA.
ECDH_anon ECDH anônimo, sem assinaturas.

[/wc_box]

Eles podem usar, por exemplo, um certificado de servidor RSA com chaves de longa duração, mas durante o TLS/SSL handshake em vez de enviar send over numa chave pública transiente (por isso ECDH + ephemeral) para fazer a negociação de chaves. Por isso a autenticidade de longo termo é confirmada através do certificado do servidor RSA, todavia as chaves transientes/efêmeras são derivadas atras de chaves ECC, que por sua vez irão gerar a chave simétrica4.

[wc_tabgroup][wc_tab title="(1) Cripto"] [wc_skillbar title="AES_CBC_256" percentage="45" color="#6adcfa"] [wc_skillbar title="RC4_128" percentage="36" color="#d3e8da"] [wc_skillbar title="AES_128_GCM" percentage="13" color="#f2ccbb"] [wc_skillbar title="3DES_EDE_CBC" percentage="1" color="#fdff9b"] [/wc_tab][wc_tab title="(2) Troca de chaves"] [wc_skillbar title="RSA" percentage="81" color="#6adcfa"] [wc_skillbar title="DHE_RSA" percentage="4.5" color="#d3e8da"] [wc_skillbar title="ECDHE_ECDSA" percentage="4.5" color="#f2ccbb"] [wc_skillbar title="ECDHE_RSA" percentage="9" color="#fdff9b"] [/wc_tab][/wc_tabgroup]

 
Revisão v. 1.30
 
  1. Ver: "Comparison of TLS implementations". []
  2. "The Accredited Standards Committee X9, Inc. or more simply X9, is the leader in developing technical financial industry standards. Our mission is to develop, establish, maintain and promote standards for the Financial Services Industry to facilitate delivery of financial services and products": http://x9.org. []
  3. "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". []
  4. "The ECDH_RSA mechanism requires a server to acquire an ECC certificate, but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the keys of trusted certification authorities accepted by TLS clients. The ECDH_ECDSA mechanism requires ECC keys for the server as well as the certification authority and is best suited for constrained devices unable to support RSA", RFC 4492, p.4. []

FIPS_mode()… Não obrigado

D.3 FIPS_mode() NAME FIPS_mode – returns the current FIPS mode of operation. SYNOPSIS #include int FIPS_mode() DESCRIPTION FIPS_mode() is used to determine the FIPS mode of operation of the running program. FIPS_mode() currently returns 1 to indicate FIPS mode. Future return values might include 2 to indicate exclusive use of the NSA's Suite B algorithms.1

Geramos tempos atrás um novo certificado digital para a AC-Raiz brasileira baseado não mais no RSA como algoritmo, mas já usando a chamada criptografia de curvas elípticas (Elliptic Curve Cryptography - ECC). Chamamos a esta "raiz" de "versão 3" ou na forma curta de v32.Num dumping da v3 podemos ver algumas característica do certificado. Tais como versão, número de série, tipo de algoritmo com o hash usado (ecdsa-with-SHA512), data de validade:


Certificate:3
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: ecdsa-with-SHA512
        Issuer: C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia da Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v3
        Validity
            Not Before: Jun 21 19:45:40 2010 GMT
            Not After : Jun 21 19:45:40 2023 GMT
        Subject: C=BR, O=ICP-Brasil, OU=Instituto Nacional de Tecnologia da Informacao - ITI, CN=Autoridade Certificadora Raiz Brasileira v3
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)

Assim este certificado ECC convive com as outras versões RSA, ainda que sem uma presença forte em aplicações. Mas fica como sinalização e, sobretudo, uma redundância, caso alguma falência, quebra, do RSA aconteça. Já em 2001 o matemático Johannes Buchmann em seu manual asseverara que os criptossistemas de curvas elípticas são a mais importante "alternativa aos sistemas RSA", e "tais alternativas são necessárias, — conclui —, uma vez que um dia o RSA pode se tornar inseguro"4.

Por que também a sinalização?

Uso da ECC já se mostra hoje importante, ainda que não seja dominante em termos de mercado, mas ela possui algumas características que imporão por certo seu papel: tais como o uso menor de processador e memória, por conseguinte, pode ser embarcado num chip menor, e menos agressivo no consumo de células de bateria, fato que se torna importante num mundo que rapidamente caminha para a mobilidade, com o uso intensivo de telefones celulares e tablets. Em suma, a ECC possui o padrão equivalente segurança relativamente aos sistemas tradicionais RSA, entretanto usando menos bits. A documentação especializada5 nos diz que uma chave RSA de 4096 bits tem seu equivalente ECC numa chave apenas de 313 bits. E, também, a geração de uma chave RSA de 512-bit, por exemplo, num pequeno dispositivo hand-held, demora 3.4 minutos, já em contrapartida uma chave ECC de 163 bits leva apenas 0.597 segundos. O tema já é bastante documentado, ainda que sempre ressalte o overhead do RSA em relação à criptossistemas EC em termos de geração de chaves, mas não em termos de verificação de uma assinatura digital ECC vis à vis RSA6. A tabela abaixo (NIST/ANSI X9) demostra bem este comparativo ECC versus RSA7:

Diretrizes NIST para Tamanhos de Chaves AES
Tamanho de chave ECC (bits) Tamanho de chave RSA (bits) Proporção Tamanho de chave AES (bits)
163 1024 1:6
256 3072 1:12 128
384 7680 1:20 192
512 15360 1:30 256

Escrevi anteriormente sobre a adesão de nosso país ao PKD, o sistema de diretório confiável mantido e regulado pela Organização de Aviação Civil Internacional - ICAO, visando a manutenção de certificados digitais e LCRs para uso no ePassport8. Para dar sequência a tal adesão o Ministério da Relações Exteriores se credenciará na ICP-Brasil como uma Autoridade Certificadora de primeiro nível, nos termos regulados pela Resolução 101, outubro 20139. Com a necessidade do país aumentar a duração de seu passaporte para 10 anos, decisão governamental, é muito provável que o certificado da AC Itamaraty — chamemos assim — tenha um certificado emitido com ECC, e partir daí gerar os documents signer para assinar os dados do passaporte eletrônico do país. Por isso mesmo, a Resolução 99 (Art. 1)10 autorizou o ITI a gerar uma Raiz de 20 anos exclusivamente com ECC:

"O formato de todos os certificados emitidos pela AC Raiz está em conformidade com o padrão ITU X.509 ou ISO/IEC 9594. O certificado da AC Raiz é o único certificado autoassinado da ICP-Brasil, com validade máxima de 20 (vinte) anos quando da utilização de criptografia de Curvas Elípticas, ou 13 (treze) anos para os demais casos, podendo este prazo ser revisto de acordo com as definições estabelecidas pelo CG da ICP-Brasil."

Mas há alguns pontos com sombras nas escolhas a serem feitas nos criptossistemas EC. A mídia não especializada especialmente a norte-americana chegou a falar sobre o tema11. Vejamos. As propriedades matemáticas de uma curva elíptica são exploradas para produzir o par de chaves ECC (pública e privada), e assim realizar as operações tradicionais de um sistema PKI: encriptar, assinar, etc. Entretanto, para se encriptar e decriptar usando ECC se faz necessário que as plataformas que trocam dados que estão cifrados compartilhem reciprocamente o conjunto de parâmetros que define a curva a ser usado. Sem este conhecimento mútuo, não haveria interoperabilidade nos sistemas que querem usar ECC. Por conseguinte, ela requer a especificação de parâmetros de domínio de curvas. Comparativamente ao RSA, enquanto este no seu parâmetro de geração de chaves, seleciona um grupos de primos, o ECC seleciona pontos numa curva elíptica num campo finito12. Como a robustez da curva escolhida pode variar dependendo da forma da mesma curva, várias curvas foram pré definidas, usando métodos e padrões que têm sido nos últimos anos recomendados por organizações. Há dois conjuntos de curvas elípticas pré definidas e bastante padronizados e que cobrem "quase todas as curvas usadas de forma corrente na indústria"13, a saber: (1) as do NIST - National Institute of Standards and Technology, adotadas também pela IETF, mas sob o patrocínio da NSA que ali definiu um conjunto de curvas chamadas de "Suite B"14. (2) O padrão Brainpool de curvas e geração de curvas que foram definidas no RFC 563915. Um padrão tipicamente norte-americano (1), sob orientação de seus organismos de padronização, e outro (2) tipicamente europeu, consórcio de empresas europeias (GD, Gemplus, Siemens, Sagem Orga e outras) e Universidades alemãs16, além do BSI, agência federal alemã de segurança da informação. Ressalte-se que o brainpool é hoje a escolha alemã para a utilização de ECC em seus passaportes eletrônicos. Assim, cada uma dos conjuntos de curvas, definidas por tais padronizações, possui o seu parâmetro de domínios: seu nome e um object identifier (OID), para garantir sua manipulação em sistemas de informação. Assim poderíamos localizar uma curva NIST de nome secp192r1 com o seu OID17, o mesmo se passa com as curvas Brainpool. Como mostra a tabela:

Curvas NIST e Brainpool: Curvas NIST recomendadas e OIDS secp192r1 1 2 840 10045 3 1 1 secp224r1 1 3 132 0 33 secp256r1 1 2 840 10045 3 1 7 secp384r1 1 3 132 0 34 secp521r1 1 3 132 0 35 Curvas Brainpool recomendadas e OIDS brainpoolp160r1 1 3 36 3 3 2 8 1 1 1 brainpoolp192r1 1 3 36 3 3 2 8 1 1 3 brainpoolp224r1 1 3 36 3 3 2 8 1 1 5 brainpoolp256r1 1 3 36 3 3 2 8 1 1 7 brainpoolp320r1 1 3 36 3 3 2 8 1 1 9 brainpoolp384r1 1 3 36 3 3 2 8 1 1 11 brainpoolp512r1 1 3 36 3 3 2 8 1 1 13

Apenas muito tardiamente a suite OpenSSL colocou suporte para as curvas Brainpool. De fato apenas o snapshot da versão 1.0.2 do OpenSSL, mas já uma versão estável, com o código fonte disponível via ftp. Usando o comando "openssl ecparam -list_curves" se pode observar todas as curvas suportadas pela suite nesta versão 1.0.2:

...curvas NIST secp112r1 : SECG/WTLS curve over a 112 bit prime field secp112r2 : SECG curve over a 112 bit prime field secp128r1 : SECG curve over a 128 bit prime field secp128r2 : SECG curve over a 128 bit prime field secp160k1 : SECG curve over a 160 bit prime field secp160r1 : SECG curve over a 160 bit prime field secp160r2 : SECG/WTLS curve over a 160 bit prime field secp192k1 : SECG curve over a 192 bit prime field secp224k1 : SECG curve over a 224 bit prime field secp224r1 : NIST/SECG curve over a 224 bit prime field secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field ... Curvas Brainpool brainpoolP160r1: RFC 5639 curve over a 160 bit prime field brainpoolP160t1: RFC 5639 curve over a 160 bit prime field brainpoolP192r1: RFC 5639 curve over a 192 bit prime field brainpoolP192t1: RFC 5639 curve over a 192 bit prime field brainpoolP224r1: RFC 5639 curve over a 224 bit prime field brainpoolP224t1: RFC 5639 curve over a 224 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP320r1: RFC 5639 curve over a 320 bit prime field brainpoolP320t1: RFC 5639 curve over a 320 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field brainpoolP512r1: RFC 5639 curve over a 512 bit prime field brainpoolP512t1: RFC 5639 curve over a 512 bit prime field

Agora vamos gerar uma chave privada com ECC, usando os parâmetros de uma curva Brainpool, com 521-bit:

OpenSSL> ecparam -out ec_BP512r1.pem -name brainpoolP512r1 -genkey

Depois vamos converter o arquivo que nomeamos como "ec_BP512r1.pem", codificando-o para DER18, e assim com o formato binário fazer um dumping com o software dumpasn1 de sua estrura ASN.1:

OpenSSL> ec -in ec_BP512r1.pem -outform DER -out ec_BP512r1.der read EC key writing EC key (...)

Então podemos observar em destaque o object identifier correspondente a uma curva brainpool...

$ ./dumpasn1 -a ec_BP512r1.der 0 218: SEQUENCE { 3 1: INTEGER 1 6 64: OCTET STRING : 25 EC 76 3D 68 26 91 6D D2 24 E7 75 7E 7A BA 6E : ED CB 20 B5 B7 6C 07 02 00 97 40 FF 05 0A 79 6A : 97 D8 A5 FE BD 55 95 0A 98 5C 73 37 16 E4 B9 21 : C4 29 A0 71 D8 B7 EF 53 62 E5 A9 32 01 E7 BD 3D 72 11: [0] { 74 9: OBJECT IDENTIFIER brainpoolP512r1 (1 3 36 3 3 2 8 1 1 13) : } 85 133: [1] { 88 130: BIT STRING : 04 4D 17 9B 7D FC CA 13 FC AB 83 EC 70 8B C8 FB : 30 C5 7C FC D1 E6 B4 8A 44 A0 91 4F 04 28 04 F8 : 87 40 A4 D6 54 BA 1E 1E 84 D0 8B 07 F8 15 54 EE : 37 C6 1F 34 3C 64 E7 A0 62 A6 55 23 80 71 56 7D : 4F 1A 5E D2 54 6E 58 28 46 1E E1 E8 72 F6 01 7F : 85 98 E4 AC E1 F8 12 FC 4D 66 4F 56 F0 A5 D4 1A : 04 68 48 79 17 11 28 FB 0A C1 5F EF 63 BA 8F EF : 18 51 A0 7E 54 F4 23 48 3B 33 67 62 36 29 DE D0 : 4F : } : } 0 warnings, 0 errors.

Falamos anteriormente em sombra na padronização de curvas do mundo dos sistemas de curvas elípticas. Um conjunto de pesquisadores da IBM de certa forma adiantaram o problema: o Brainpool nasce "em resposta a falhas (shortcoming) das curvas recomendadas pelo NIST"19. Falhas? Lacunas? Quais lacunas? Os parâmetros que foram usados para geração de curvas aceitas pelo NIST, a "Suite B", não são completamente conhecidos, isto é, a sua aleatoriedade não foi totalmente publicada e suas constantes jazem sem a devida explicação, o que é grave em se tratando de criptossistemas. Isto minará a robustez de um sistema que as adote, assim como pode ser atingido pelo uso irregular de curvas que possam vir a estar patenteadas, já que não sabemos exatamente os critérios usados. Todos sabemos que a aleatoriedade é um problema de enorme complexidade matemática, uma coisa é escolhermos aleatoriamente, randomicamente, números ou letras, ou nomes de frutas, outra radicalmente diferente é demostrar matematicamente que uma sequência qualquer é de fato aleatória. E se há vicio na randomicidade de um qualquer sistema, por exemplo , num simples sorteio, este sistema já não mais se sustentará. Por isso, pode-se afirmar que "geradores de números pseudo-randômicos ou inseguramente randômicos são talvez a causa mais comum de ataques em sistemas criptográficos"20. Ainda no caso da ECC, há uma outra interessante aleatoriedade a ser inserida nestes criptossistemas, trata-se da escolha randômica de parâmetros de domínio de curva elíptica, método especificado no ANSI X9.62:

"Um refinamento atraente da ideia da seleção randômica de parâmetros de domínio de curva elíptica é a ideia de seleção de parâmetros de domínio de curva elíptica verificada randomicamente. Isto envolve a seleção de parâmetros randomicamente de uma semente de tal forma que eles não podem ser pré-determinados. Isto é atraente porque a semente dá evidência que pode ser verificada por qualquer um, que 'trapdoors' foram colocados nos parâmetros."21

Por isso boa parte das críticas devastadoras feitas recentemente a interface de geração de números aleatórios da NSA, também padronizada pelo NIST, o Dual_EC_DRBG22. Alçapões e portas traseiras se encontram exatamente nestas fragilidades.

Dr. Fabiano Menke em seu trabalho referência sobre assinatura digital23 chama atenção para um aspecto essencial numa plataforma criptográfica: ela é uma cadeia de confiança. A aceitação do NIST como órgão de padronização, já tão tradicional como fora no mundo de segurança em tecnologia da informação, queda com sombras, e desacredita fortemente a adoção de suas curvas. O NIST sempre foi referência no campo dos criptossistemas civis, como o é uma plataforma como a da ICP-Brasil, usada intensamente na economia, no mundo bancário-financeiro e na própria vida civil, como é o caso de um documento de viagem. Aqui só se pode falar em regras claras e transparentes, e onde viceja a confiança.

A ECC continua sendo a mais aceitável alternativa ao RSA, mas as curvas NIST devem ser postas de lado, pela problemas apontados pela comunidade de segurança. O uso crescente da ECC parece inevitável, reforçados pela ubiquidade das redes e a mobilidade, e a agência norte-americana já o percebeu. Schneier comentou que a NSA está empurrando o uso da ECC, ao fazer todo este esforço de padronização, porque de fato já o pode quebrar24.

 
Revisão v. 3.146
 
  1. User Guide - OpenSSL FIPS Object Module v2.0: http://www.openssl.org/docs/fips/UserGuide-2.0.pdf []
  2. http://www.iti.gov.br/icp-brasil/certificados/188-atualizacao/4530-ac-raiz. []
  3. Uso: "openssl x509 -in ICP-Brasilv3.pem -text -noout"... []
  4. J. Buchmann. Introduction to Cryptography. Heidelberg, Springer-Verlag, 2001 (2ª ed.), p. 282. []
  5. Cf. L. Washington. Elliptic Curves: Number Theory and Cryptography. Boca Raton, Chapman & Hall, 2008 (2a. ed.), p.169. []
  6. Cf. L. Loeb. Secure Electronic Transactions: Introduction and Technical Reference. Boston-London, Artech House, 1998, p. 44. []
  7. Citado por: T. VanAmeron. Implementing efficient 384-bit NIST elliptic curves over prime fields on an ARM946E [dissertation, Rochester Institute of Technology], 2008, p.2. []
  8. Regulamentado nos seguintes documentos: Doc 9303, Machine Readable Travel Documents, Part 1, Machine Readable Passports, volume 2, sixth edition e Machine Readable Travel Documents, Guidance Document, PKI for Machine Readable Travel Documents, version 1.0. []
  9. Consulte-se: http://www.iti.gov.br/images/legislacao/resolucoes/Resolucao_101_-_Autoriza_Procedimento_Especifico_para_Passaporte.pdf. []
  10. http://www.iti.gov.br/images/legislacao/resolucoes/Resolucao_99_-_Altera_validade_certificados.pdf. []
  11. Especialmente, NYT: "Secret Documents Reveal N.S.A. Campaign Against Encryption", e ainda no Ars Technica: "New York Times provides new details about NSA backdoor in crypto spec" e o The Guardian: "Revealed: how US and UK spy agencies defeat internet privacy and security". []
  12. Cf. Piper, Blake-Wilson & Mitchell. Digital Signatures: Security and Controls. Rolling Meadows, IL, ISACF, 1999, p.107. []
  13. Ch. Giraud & V. Verneuil. "Atomicity Improvement for Elliptic Curve Scalar Multiplication". In: D. Gollmann, J-L. Lanet & J. Iguchi-Cartigny (ed.). Smart Card Research and Advanced Applications: 9th IFIP WG 8.8/11.2 Proceedings. Hamburg, Springer-Verlag, 2010, p.81. E consulte-se também o site: "SafeCurves: choosing safe curves for elliptic-curve cryptography", como referência geral: http://safecurves.cr.yp.to/. []
  14. Suite B Cryptography / Cryptographic Interoperability: http://www.nsa.gov/ia/programs/suiteb_cryptography/. []
  15. Cf. http://www.ecc-brainpool.org/ e http://tools.ietf.org/html/rfc5639; e o Technical Guideline TR-03111. []
  16. Consultar os membros em http://www.ecc-brainpool.org/members.htm. []
  17. Para as curvas NIST/Suite B consulte o RFC 6318: Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) []
  18. Cf.: http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf. []
  19. Karan Singh et alii. System z Crypto and TKE Update. IBM Redbooks, maio 2011, p. 249. []
  20. STANDARDS FOR EFFICIENT CRYPTOGRAPHY - SEC 1: Elliptic Curve Cryptography, September 20, 2000, Version 1.0, p.65 []
  21. Idem, p.63. []
  22. NIST Special Publication 800-90A: Recommendation for Random Number Generation Using Deterministic Random Bit Generators. []
  23. Cf. Assinatura Eletrônica no Direito Brasileiro. São Paulo, Revista dos Tribunais, 2005, p.130 []
  24. "Certainly the fact that the NSA is pushing elliptic-curve cryptography is some indication that it can break them more easily": The NSA's Cryptographic Capabilities. []

ASN.1: interoperabilidade pura

ASN.1 ou "Abstract Syntax Notation number One" é na definição de um dos seus patrocinadores, a ITU-T, uma notação formal usada para descrever, representar, codificar/decodificar, dados a serem  transmitidos em protocolos de telecomunicação -- sua criação data de 1984 (CCITT X.409:1984; ver aqui) -- e, mais presentemente, redes de computadores. É esta capacidade de descrever abstratamente tipos e valores que faz (e sempre fez) do ASN.1 uma poderosa ferramenta de interoperabilidade, tão útil em nossas dias conectados.

Type Tag number
(decimal)
Tag number
(hexadecimal)
INTEGER 2 02
BIT STRING 3 03
OCTET STRING 4 04
NULL 5 05
OBJECT IDENTIFIER 6 06
SEQUENCE and SEQUENCE OF 16 10
SET and SET OF 17 11
PrintableString 19 13
T61String 20 14
IA5String 22 16
UTCTime 23 17

...alguns tipos e suas tags

A tabela mostra alguns tipos presentes na notação, e eles curiosamente estão presentes no dia-a-dia de um certificado digital ICP-Brasil v.3. Se fizermos um dumping em notação ASN.1 ou uma radiografia do certificado da raiz brasileira, por exemplo, os encontraremos um importante object identifier (OID) nesta última versão da AC Raiz brasileira (o leitor interessado pode fazer esta decodificação on line):

OBJECT IDENTIFIER 1.2.840.10045.4.3.4

Ele mostra a adoção da ECDSA no lugar do algoritmo RSA, o OID significa "ecdsaWithSHA512", ANSI X9.62, ou seja, a última chave -- versão 3 -- da AC Raiz foi gerada com o algoritmo de curvas elípticas com o hash sha512 (considerando-se a obsolência do MD5 e do SHA1). Os OIDs (também mantidos pela ITU-T & ISO/IEC) jogam um papel essencial na transferência de dados em rede, pois designam de forma persistente qualquer tipo de objeto, conceito ou "coisa", de forma única (não- ambígua). Possuindo uma forma de árvore hierárquica a "OID tree". Há um repositório on line onde pode-se descobrir facilmente estas árvores de OIDs. O OID acima está em "notação pontual", se escrito em ASN.1 ficarão mais claras as suas inter-relações: {iso(1) member-body(2) us(840) ansi-x962(10045) signatures(4) ecdsa-with-SHA2(3) ecdsa-with-SHA512(4)}.

Continue reading

Copyright © 2017 RenatoMartini.Net

Theme by Anders NorenUp ↑