RenatoMartini.Net

Tag: ECC (page 1 of 2)

ICP-Brasil passa a operar a V4, nova cadeia de certificação digital

Dando sequência a implementação de soluções em Curvas Elípticas (ECC) na ICP-Brasil, já documentada fartamente no blog. O ITI emitiu semana passada uma nova raiz usando o conjunto de curvas chamadas brainpool. De imediato, esta nova raiz emitida com ECC será usada na nova Autoridade Certificadora do Ministério das Relações Internacionais, para assinar os dados contidos no passaporte eletrônico do país, obedecendo dinamicamente os padrões da ICP-Brasil e do organismo internacional que regula os documentos de viagens, a ICAO.

---


"A Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil iniciou as atividades de sua nova cadeia de certificação, a v4. A emissão do novo Certificado ocorreu na tarde desta quinta-feira, 23, em Brasília. Trata-se de um momento importante para a ICP-Brasil uma vez que a nova versão de raíz com algoritmo criptográfico é diferente do comumente utilizado RSA. O novo algoritmo segue a lógica da criptografia assimétrica, no entanto faz uso da tecnologia europeia de Curvas Elípticas – brainpool e usa chaves criptográficas menores e mais robustas.

Recém inaugurada, a v4 já emitiu, momentos depois de efetivada, o certificado de Autoridade Certificadora do Ministério de Relações Exteriores – AC MRE, viabilizando a assinatura do novo passaporte brasileiro, aderente ao diretório Public Key Directory – PKD da Organização da Aviação Civil Internacional – ICAO, agência especializada das Nações Unidas que promove a segurança e padroniza os aeroportos e passaportes no mundo.

No próximo Boletim Digital traremos uma cobertura completa do tema e entrevista com o diretor da Infraestrutura de Chaves Púbicas Brasileira do ITI, Maurício Coelho. Se você ainda não recebe o Boletim Digital, envie um e-mail para comunicacao@iti.gov.br".

Consultar: http://www.iti.gov.br/noticias/indice-de-noticias/4797-icp-brasil-passa-a-operar-a-v4-nova-cadeia-de-certificacao-digital

 
Revisão v. 1.0a
 

O módulo FIPS do OpenSSL versão 2.0

A suite OpenSSL, que dispensa apresentações, possui um importante módulo para aqueles que desejam suportar em sua aplicação, ou hardware, o padrão FIPS 140-21. O chamado "FIPS Object Module" versão 2.0 suporta também todo o conjunto de algoritmos criptográficos conhecidos como "Suite B" criados pela NSA norte-americana, que também podem ser usados exclusivamente com estas extensões.

A Suite B requer um nivel de segurança de 128-bit e note-se que impossibilita o use do TLS lesser abaixo da versão 1.22, pois as versões anteriores usavam ainda a solução MD5-SHA1, sabidamente já obsoletos, como função pseudo-randômica.

O modo FIPS é iniciado pela chamada de função FIPS_mode_set().

  1. int FIPS_mode_set(int ONOFF);

Com FIPS_mode_set(0) ele abandonará o modo FIPS, e retorna 1 se com êxito. Já com o valor diferente de zero ele entrará no modo FIPS. O valor "2" está reservado para restringir as operações aos algoritmos da Suite B. Diferentemente da documentação que está disponível no Wiki do projeto OpenSSL, o Manual do Módulo FIPS documenta o uso de outra função para restringir à Suite B: "An argument of FIPS_SUITEB(2) will restrict the available algorithms to those
allowed by the Suite B specification
".

Exemplo de uma chamada direta da função:

  1. #ifdef OPENSSL_FIPS
  2. if(options.no_fips <= 0)
  3. {
  4. if(!FIPS_mode_set(1))
  5. {
  6. ERR_load_crypto_strings();
  7. ERR_print_errors_fp(stderr);
  8. exit(1);
  9. }
  10. else
  11. fprintf(stderr,"*** IN FIPS MODE ***\n");
  12. }
  13. #endif

Um tema importante para aqueles que ainda querem adotar a padronzação ECC feita pela NSA é o das patentes. O item 6.5 "ECC and the NSA Sublicense" é portanto leitura obrigatória para o desenvolvedor.

Why are there two versions of the OpenSSL FIPS Object Module 2.0? At least some implementations of Elliptic Curve Cryptography (ECC) are perceived to be encumbered in the United States by a complex set of patents. Concern about the possible risks of patent infringement have been a significant disincentive to more widespread use of ECC. In order to counter such concerns for the ECC necessary to implement the Suite B algorithms, the NSA established a process for sub-licensing the patents for that subset of ECC (see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). The OSF has obtained such a sublicense (http://opensslfoundation.com/testing/docs/NSA-PLA.pdf). However, that sublicense only covers the specific patents presumed relevant to the prime curve ECC used for Suite B. It does not cover other possible types of ECC such as binary curves which are implemented in OpenSSL. Judging the risks of a patent infringement lawsuit is difficult, and not only because the patents themselves are usually incomprehensible to the software developer. The mere threat of a patent lawsuit can be crippling to even a medium sided enterprise, regardless of the legitimacy of the accusation of infringement. It is the considered opinion of the OpenSSL team that the implementation of ECC in OpenSSL, both primary and binary curve, does not infringe any patents 46 However, some potential users are still concerned about the risk of patent litigation, understandably so given the extent to which such litigation has been used as an offensive commercial tactic in recent years. For the OpenSSL software such users can use built-time options to omit specific algorithms of concern from the resulting binary code.

FIPS140 Files Here you can find a number of FIPS140 related files including the user guide and test vectors. Bytes Timestamp Filename ________ ____________________ ____________________________ 1707577 Sep 29 14:15:31 2013 UserGuide-2.0.pdf 464520 May 20 20:40:51 2013 SecurityPolicy-2.0.pdf 223576 Jun 28 15:42:31 2012 UserGuide.pdf 925694 Jun 27 02:45:21 2012 UserGuide-1.2.pdf 82787660 Feb 3 19:45:56 2012 fips-2.0-tv.tar.gz 399521 May 12 14:55:47 2011 SecurityPolicy-1.2.3.pdf 5628 May 10 12:52:17 2011 incore2 645167 Dec 8 20:19:25 2010 SecurityPolicy-1.2.2.pdf 1936 Jan 12 23:34:27 2010 incore.gz 860211 Nov 20 16:26:39 2009 SecurityPolicy-1.2.pdf 429420 Feb 10 19:28:55 2008 SecurityPolicy-1.1.2.pdf 681420 Dec 13 21:11:03 2007 UserGuide-1.1.1.pdf 8947798 Oct 10 23:21:37 2007 testvectors-linux-2007-10-10.tar.gz 9112982 Oct 10 00:56:58 2007 testvectors-XP-2007-10-09.zip 1395381 Feb 6 22:03:20 2007 SecurityPolicy-1.1.1.pdf 5700115 Jul 19 13:30:25 2005 rsp.SuSE.2005-07-01.tar.gz 5699128 Jul 19 13:30:17 2005 rsp.SuSE.2005-06-30.tar.gz 5660011 Jul 19 13:30:03 2005 rsp.HP-UX.2005-07-01.tar.gz 4249118 Jun 10 12:26:55 2005 testvectors.SuSE.tar.gz 4149860 Jun 10 12:26:43 2005 testvectors.HP-UX.tar.gz

 
Revisão v. 1.0
 
  1. Obviamente que a compilação do módulo em questão não gerará de forma imediata uma como que aceitação do padrão NIST, como o próprio OpenSSL avisa: "OpenSSL has been configured to generate a fipscanister.o object module. That compiled module is NOT FIPS 140-2 validated or suitable for use in satisfying a requirement for the use of FIPS 140-2 validated cryptography UNLESS the requirements of the Security Policy are followed exactly (see http://openssl.org/docs/fips/ or http://csrc.nist.gov/cryptval/)." []
  2. Consultar: http://tools.ietf.org/html/rfc5246: "The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256." []

O tal padrão de criptografia maculado pela NSA

Interessante matéria divulgada no Portal Convergência Digital, ver o link abaixo, Brasil abandona padrão de criptografia maculado pela NSA, sobre debates ocorridos recentemente em nosso CertForum em Brasília.

Muito me perguntaram sobre o tema após a matéria citada. Basicamente repeti os argumentos desenvolvidos em um artigo.

Ainda uma vez, alerto o leitor interessado em aprofundar o tema, a ler então um longo artigo que coloquei aqui no blog, chamado "FIPS_mode()… Não obrigado". É uma descrição mais técnica que norteou a decisão brasileira de revogação da chave criptográfica que usara o padrão de curvas elípticas definido pela NSA/NIST/IETF, chamado comumente de Suite B, e, no mesmo passo, a adoção de novos padrões europeus para curvas elípticas, que também serão usados no passaporte eletrônico brasileiro.

http://convergenciadigital.uol.com.br/cgi/cgilua.exe/sys/start.htm?infoid=36860&sid=11#.U43myCh4ZY4

 
Revisão v. 1.1a
 

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

Copyright © 2018 RenatoMartini.Net

Theme by Anders NorenUp ↑