RenatoMartini.Net

Category: ICAO

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. []

Brasil e o PKD/ICAO

Recebemos esta semana a feliz notícia da enfim adesão de nosso país ao ICAO Public Key Directory (PKD). A ICAO é a agência especializada das Nações Unidas que promove a segurança e padroniza os aeroportos e passaportes no mundo. Agora sua missão é a padronização dos passaportes eletrônicos, os ePassports, para tanto ela organizou um Diretório de Chaves Publicas, ICAO Public Key Directory (PKD), o sistema ICAO PKD foi estabelecido para dar o devido suporte a interoperabilidade na validação de ePassports agindo como um "centralizador", ou um central broker para gerir de forma confiável a troca de certificados e listas de certificados revogáveis dos país aderentes.
Há tempos vinhamos debatendo no seio do Comitê Gestor da ICP-Brasil1 como adequar a ICP-Brasil, o sistema nacional de certificação digital. O Itamaraty, Serpro e o DPF junto com o ITI tiveram papel decisivo nesta preparação técnica e institucional.

http://www.icao.int/Security/mrtd/PKD%20Documents/MapofICAOPKDStates/Pkd-Map.pdf http://www.icao.int/Security/mrtd/Pages/icaoPKD.aspx

 
Revisão v. 1.14
 
  1. Em especial a reunião do Comitê Gestor - 09/10/2013, disponível em vídeo aqui... []

Copyright © 2017 RenatoMartini.Net

Theme by Anders NorenUp ↑