RenatoMartini.Net

Tag: certificado digital (page 2 of 2)

CertForum Brasília: fórum de certificação digital

Gostaria de divulgar nosso evento, o Fórum Nacional de Certificação Digital, que começará amanhã, aqui na capital federal. O CertForum é o maior evento do gênero em nosso país, e está na sua 11a. versão. Começamos a fazê-lo em 2003 e é hoje um espaço privilegiado de debate e mostra de soluções de nosso Sistema Nacional de Certificação Digital, a ICP-Brasil.


Dia 11/09 – Quarta-feira
8h às 9h – Credenciamento

09h – Abertura
Renato da Silveira Martini: Diretor-Presidente do ITI
Célio Ribeiro: Presidente-Executivo da Abrid

09h40 – Mesa 1 – ICP-Brasil e cidadania
Projeto “Cartão Cidadão”: Alexandre Matarangas – analista de TI do PRODEST (confirmado)
Projeto “Cartão São Paulo”: Alexandre Araújo – Imprensa Oficial do Estado de São Paulo (confirmado)
Coffee-break

10h50 – Mesa 2 – Certificação ICP-Brasil e o Judiciário Nacional
Processo Judicial Eletrônico no TRT: Denilson Bandeira Coelho – Juiz do TRT 10º Região (confirmado)
Certificação Digital no TJSP: Fernando Tasso – Juiz assessor da presidência do TJSP (confirmado)
A legalidade do processo eletrônico assinado com certificados ICP-Brasil: Renato Ópice Blum (confirmado)
O profissional do direito e o processo eletrônico: Luiz Cláudio Allemand – Presidente da Comissão Especial de Direito da Tecnologia e Informação do Conselho Federal da OAB (confirmado)

-Almoço-

14h – Mesa 3 – Implementações ao Sistema Nacional de Certificação Digital
Autoridade de Carimbo do Tempo:	Wander Blanco – Gerente Nacional de Certificação Digital da CEF (confirmado)
Os Certificados de Atributos no âmbito da ICP-Brasil: Celso Fukushima (confirmado)
Assinador digital registral de documentos eletrônicos: Flauzilino Araújo dos Santos – ARISP (confirmado)

15h20 – Mesa 4 – Certificação digital em aplicações do Fisco
Certificação Digital no Agronegócio Brasileiro:	Marcelo de Mesquita – Gerente de Informações Sefaz-GO (confirmado)
Malha DF – Sistema de Gestão da Regularidade Fiscal: Wilson de Paula – Auditor Fiscal – Sefaz-DF (confirmado)
O Certificado digital como ferramenta tecnológica do Fisco: Sérgio Fuchs – Auditor Fiscal da Receita Federal (confirmado)

Coffee-break de encerramento

Dia 12/09 – Quinta-feira
8h às 9h – Credenciamento

09h20 – Mesa 1 – Certificados Digitais ICP-Brasil na área da Saúde
Prontuário eletrônico e a modernização da saúde no Brasil: Roberto Luiz d´Avila – presidente do Conselho Federal de Medicina – CFM (confirmado)
Atestado médico eletrônico: Paulo Tadeu Falanghe – Diretor de Previdência e Mutualismo da Associação Paulista de Medicina – APM (confirmado)
Certificado ICP-Brasil como boa prática da medicina brasileira:	Kaio Bin – ICESP (confirmado)

Coffee-break

10h40 – Mesa 2 – A Infraestrutura de Chaves Públicas Brasileira: números, projetos e perspectivas
Projeto ‘AR Biométrica’: Eduardo Lacerda – Assessor Técnico do ITI (confirmado)
ICP-Brasil em números: Pedro Paulo Lemos Machado – Diretor de Auditoria, Fiscalização e Normalização do ITI (confirmado)
Mapa Brasil da Certificação Digital: Carlos Victorino – Diretor de Tecnologia da Fenacon (confirmado)

-Almoço-

14h00 – Mesa 3 – ICP-Brasil em Aplicações de Governo
Certificados digitais na entrega de medicamentos de alto custo:	Keli Regina Dela Torre Soler – IMESP (confirmado)
Gestão Eletrônica de Documentos no governo carioca: Marco Antônio Horta Pereira – Subsecretário de Gestão da Casa Civil do estado do RJ (confirmado)
Diploma Eletrônico com certificação ICP-Brasil:	Leandro Fregnani – Departamento de Informática da Coordenadoria de Administração Geral da USP (confirmado)

15h40 – Mesa 4 – Certificado ICP-Brasil à serviço do trabalhador brasileiro
CAGED e RAIS: Maria Emília Piccinini Veras – Ministério do Trabalho e Emprego
Homolognet: Admilson Moreira dos Santos – Assessor do Secretário de Relações do Trabalho e Auditor fiscal do Trabalho da SRT/MTE

Coffee-break de encerramento

Esquecer senhas e PINs?

Para fazer frente ao esgotamento do par "login-senha" e o problema quase insolúvel do roubo de identidades1, a Sociedade da informação vai se virando. É o que mostra matéria recente "Forget passwords and PINs: Nymi bracelet replaces logins, keys and even wallets with your own HEARTBEAT", — e para resolver também os problemas da biometria tradicional, refiro-me a "impressão digital", a saber, o fato dela ser um falso segredo, um dado compartilhável, como o são senhas e PINs, que esta engenhoca é pensada.

O tal bracelete captura o ritmo cardíaco (HeartID) que mede a quantidade de força elêtrica gerada pelo coração humano, isto é, o ritmo cardíaco que é aferido num tradicional eltrocardiograma. Um algoritmo deve extrair algum tipo de frequência ou dados que nos individualizaria, que é efetivamente o que se quer. Ao aproximar-se de uma fonte que demanda a identificação, um terminal de pagamento, por exemplo, o bracelete por sua vez dispara o processo de medição, e, então, se comunica com o hardware demandante por bluetooth.

Sinceramente? Não indicaria uma solução dessas para ninguém. No entanto, podemos extrair alguns aprendizados.

  1. Soluções para identificação existem várias: senhas, biometria, certificados digitais. Cada um cumpre um papel, são mais ou menos robustas — combinadas tanto melhor.
  2. Soluções de identificação devem ser baseadas em padrões abertos: seus alrotimos de conhecimento da sociedade, implementáveis por qualquer fabricante; jamais segredo de uma única empresa, numa espécie de ambiente anti-concorrencial.
  3. Soluções de identificação devem usar padrões interoperáveis.
  4. Não existem soluções definitivas e absolutamente seguras em tecnologia — lembre-se do Titanic2, seus engenheiros o chamaram de unsinkable.

Referência:

http://www.dailymail.co.uk/sciencetech/article-2409992/Forget-passwords-PINs-Nymi-bracelet-replaces-logins-keys-wallets-HEARTBEAT.html?ito=feeds-newsxml

  1. Falo aqui um pouco sobre os problemas da identificação civil no Brasil []
  2. http://www.britannica.com/titanic/article-9072642. []

Smartcards & certificados digitais (Parte 2)

Os smartcards são ferramentas poderosas sobretudo pelo tamanho, o chip possui um SO, sistema de arquivos e cripto-processamento, como aqueles capazes de PKI, ‐ e obedecem um padrão industrial. Isso tudo pode ser usado em sistemas de pagamentos, na saúde pública, no fisco, etc. Ou seja, qualquer aplicação que necessita de uma forma de identificação inequívoca. A tecnologia do cartão de circuito integrado nasceu exatamente para se aproveitar da capacidade distribuída do chip, quando se backend era tão caro.1
 

No post passado abordamos de forma resumida a estrutura lógica de arquivos nos smartcards, usando o OpenSC como ferramenta de demonstração. Vejamos agora um pouco do protocolo de comunicação dos cartões.

 

Aviso: usar comandos de força bruta (CLA e INS) em dispositivos tipo FIPS140 podem gerar contra medidas que travem totalmente o smartcard!

 

O protocolo de comunicação é definido pelo ISO/IEC 7816-42 é chamado de APDU: "Application Protocol Data Unit". É basicamente um protocolo de enviar um comando e receber de volta uma resposta: "command APDUs" → "response APDUs"3.

Este processo de pergunta e resposta começa quando o terminal ativa o cartão/token, energizam-se os contatos do smartcard, é enviado um reset.
E este a seu turno responde com uma ATR4 de até 33 bytes (Answer To Reset), usando uma ferramenta da suíte OpenSC, teremos:

 
$ opensc-tool -v --atr
 
Connecting to card in reader ACS ACR 38U-CCID 00 00...
Using card driver STARCOS SPK 2.3/2.4.
Card ATR:
3B B7 94 00 81 31 FE 65 53 50 4B 32 33 90 00 D1 ;....1.eSPK23...

O parâmetro "--atr" mostra a ATR do cartão: 3B B7 94 00 81 31 FE 65 53 50 4B 32 33 90 00 D1. Ali estará presente de forma obrigatoria se o protocolo usado será "T=0" (byte-oriented) ou "T=1" (block-oriented), informações sobre o fabricante, informações sobre o SO e ROM do cartão, o último byte XOR de checksum e a taxa de baud suportada para I/O (deve ser enviado entre 400 e 40.000 clock cycles). A partir daí todas as comunicações serão via APDU, que se configuram como uma sequência de bytes seguindo
a definição ISO. De forma que:


  o terminal envia um comando APDU
  e o cartão atende com APDUs de respostas

 

Como é a estrutura abstrata de um comando APDU? Vejamos a representação gráfica:

Cabeçalho/Corpo APDU

Cabeçalho/Corpo APDU

 

O cabeçalho de quatro bytes (CLA INS P1 P2) é de presença obrigatória numa mensagem APDU, já o corpo pode ter tamanho variável e será sempre opcional. Portanto aquele consiste de "class" (1 byte), "instructions" (1 byte), segue-se o "primeiro parâmetro" (1 byte) e o "segundo parâmetro" (1 byte). Já o corpo possui os seguintes campos opcionais: "Lc" ("length command"5 que será representado pela quantidade de bytes do "campo de dados", e, portanto, note-se que serão sempre concatenados, os dados (data field) e, por fim, o "Le", length of expected data, que possui o tamanho dos bytes que se espera numa resposta ADPU.

Nosso primeiro exemplo prático demonstrará porque há opções em que não há sentido em envio de dados no "corpo" do APDU.

$ opensc-tool -v --send-apdu 00:84:00:00
Using reader with a card: ACS ACR 38U-CCID 00 00
Connecting to card in reader ACS ACR 38U-CCID 00 00...
Using card driver STARCOS SPK 2.3/2.4.
Sending: 00 84 00 00
Received (SW1=0x90, SW2=0x00):
B1 63 11 6E 66 7C 63 05 .c.nf|c.

 
Num cartão eletrônico Oberthur:

Using reader with a card: SCM SCR 355 [CCID Interface] 00 00
Connecting to card in reader SCM SCR 355 [CCID Interface] 00 00...
Using card driver Oberthur AuthentIC.v2/CosmopolIC.v4.
Sending: 00 84 00 00
Received (SW1=0x90, SW2=0x00):
4C 84 8B 05 12 4F A7 09 A7 A8 F4 B6 33 A0 F2 44 L....O......3..D
0B C5 83 80 18 D9 9F 8C C8 56 95 E0 B0 74 23 11 .........V...t#.
45 06 FF A5 29 73 A4 16 15 92 18 EB 25 F3 6B 2A E...)s......%.k*
85 44 B3 22 70 29 D4 D4 36 21 8E 9F 9B 3A 2C 6C .D."p)..6!...:,l
28 BC A9 0E E0 29 EE 8A 1C 43 90 68 A8 7D 65 10 (....)...C.h.}e.
FC 6D 5B 9E 4A B2 50 F6 7F F0 50 BD 01 27 57 DB .m[.J.P...P..'W.
79 8D 3A 7C FE 87 52 C4 C6 6D BB F7 53 60 D2 B5 y.:|..R..m..S`..
70 E7 12 17 A8 D3 97 A9 CA 23 67 E4 BE C3 67 C7 p........#g...g.
8A 0D 9F 1D CE AE 4D B5 87 7D F1 BA 91 26 14 DF ......M..}...&..
B7 9F 82 62 A3 86 34 1A B1 EB 73 2C C3 7B 70 AE ...b..4...s,.{p.
33 B7 56 70 5C 3E B1 91 E6 90 78 72 4A 5E 95 19 3.Vp\>....xrJ^..
13 67 A9 DE 76 CC 20 25 27 61 AA 68 AD B7 8B C9 .g..v. %'a.h....
F5 A7 D5 D3 20 0C 78 B7 53 AC 1E 1D 3F DB BB EF .... .x.S...?...
D7 71 6C 71 47 CF 4B CD BC 9B 9D 42 C2 7B 50 80 .qlqG.K....B.{P.
B6 39 7C 78 26 73 C2 4C 9E CF 9C 44 07 0A D4 27 .9|x&s.L...D...'
3A 41 E1 ED 91 38 C0 AD BC 93 22 1C BA EA 3A 7C :A...8...."...:|

Aqui pode-se ver o envio e o recebimento de mensagens APDU. Enviamos o pedido "00:84:00:00", isto é, CLA=00, INS=84 e P1 e P2 "00". A instrução "84" é pré-fixada pelo padrão ISO, assim como outras como se pode ver na tabela abaixo. Ela significa "get challenge"6, isto é, pedimos ao cartão que faça a geração de números aleatórios. E é exatamente por isso não há parâmetro algum a ser enviado, e da mesma maneira não há dados a serem encaminhados.

Em nosso exemplo, pedimos "get challenge" (INS=84) e recebemos um "Okay", com os dados randômicos "X" gerados na memória do cartão. O campo "class byte" (CLA), que antecede INS, é o responsável por referenciar às aplicações e os comandos específicos, implementando alguns casos de uso, ou seja, APDUs específicas para cartões ISO 7816, EMV, GSM, etc.7

  Classe   Aplicação
0X Cartões padrão ISO 7816
80 Cartões padrão EN 1546-3
8X Comandos específicos para uso das empresas
8X Cartões EMV
A0 Cartões GSM 11.11

 

Abaixo a tabela com os valores fixos para o campo INS8:
 

 Valor  Nome do comando
0E ERASE BINARY
20 VERIFY
70 MANAGE CHANNEL
82 EXTERNAL AUTHENTICATE
84 GET CHALLENGE
88 INTERNAL AUTHENTICATE
A4 SELECT FILE
B0 READ BINARY
B2 READ RECORD(S)
C0 GET RESPONSE
C2 ENVELOPE
CA GET DATA
D0 WRITE BINARY
D2 WRITE RECORD
D6 UPDATE BINARY
DA PUT DATA
DC UPDATE DATA
E2 APPEND RECORD

Este "Okay" estão exatamente em "SW1=0x90, SW2=0x00" que referenciam a chamada "resposta APDU"; o status 0x90 significa que o comando foi executado com sucesso e completamente. Status word ou status bytes consiste assim num "corpo" opcional e de tamanho variável e um trailer obrigatório de 2 bytes (SW1 SW2) que funciona na base de um "command-response pair" e que finaliza o processo. Em suma: numa "resposta APDU" o envio de dados é opcional, mas não os código de status (SW1-SW2), que combinados geram mais de 50 mensagens... Que podem ser resumidos da seguinte maneira:


  okay, processo normal: 61xx, 9000
  processo com avisos: 62xx, 63xx
  erro de execução: 64xx, 65xx
  erro de código: 67xx, 6Fxx

Resumo esquemático para os return codes de SW1-SW29:

Esquema SW1-SW2

Esquema SW1-SW2

Noutro caso usamos o comando INS "A4" para selecionar um arquivo, porém num cartão não incializado:

$ opensc-tool -v --send-apdu 00:A4:00:00:04:3F:00:50:15
Using reader with a card: Teo by Xiring 00 00
Connecting to card in reader Teo by Xiring 00 00...
Using card driver STARCOS SPK 2.3/2.4.
Sending: 00 A4 00 00 04 3F 00 50 15
Received (SW1=0x62, SW2=0x84)

 
Agora enviamos um novo comando APDU com o opensc-tool:

 

00:A4:00:00:02:3F:00:50:15
 
 
INS A4(select file) com Lc de 4 bytes para o data field 3F005015
 
...e recebemos
 
SW1=0x62 & SW2=0x84
 

O formato do cabeçalho é 00 para ISO 7816, A4, select file e concatenamos o campo Lc (02) com o path, correspondendo precisamente ao tamanho de 4 bytes, ‐ se quiséssemos por exemplo apenas o raiz 3F00 seriam 2 bytes, etc. Enviado o comando recebemos na tela a seguinte condição de status para o comando: "Received (SW1=0x62, SW2=0x84)". Significa tão-somente comando processado com aviso: ..."estrutura de arquivos não formatada".10

Por exemplo, uma aplicação qualquer começaria selecionando arquivos (A4) e, depois, obtendo e escrevendo dados ('D0' read binary/'DA' put data) no sistema de arquivos do cartão.


 Terminal:RESET   ...  ATR recebido ... SELECT FILE  DF   EF 0   EF 1   READ BINARY 'D0'...

 
Revisão v. 1.1
 

 
Referências na Web:

Most Used Smart Card Commands – APDU

Interindustry Smart Card Commands (ISO 7816-4)

ISO/IEC 7816 Parte 4

 

  1. Explico um pouco desta história no meu último livro: Tecnologia e Cidadania Digital. Rio de Janeiro: editora Brasport. []
  2. ISO/IEC 7816-4:item 5.3 APDU message structure []
  3. Consulte-se as referências na Parte 1 do post e R. Sánchez Reíllo. "Tarjetas de Identificación". Tecnologías Biométricas aplicadas a la Seguridad. Mexico: Alfaomega & Ra-Ma []
  4. ISO 7816-4: "Elementary file which indicates operation characteristics of the card". []
  5. Mas por muitos chamado também de P3 []
  6. Rankl & Effing, p. 458: "It is used to request a random number from the card. This number is subsequently used during authentication. When DES authentication is used,
    the length of the number is typically eight bytes, but it may be different for other cryptographic algorithms
    ". []
  7. Ver EN 1546-3:1999 "Identification card systems - Inter-sector electronic purse - Part 3: Data elements and interchanges, ETSI GSM 11.11 e EMV []
  8. Definidos no cap. 5.4.2, "Instruction byte", do ISO 7816-4 []
  9. Ver Rankl & Effing, p. 425 []
  10. "SW1='62' with SW2=
    - '83': Selected file invalidated
    - '84': FCI not formatted according to 5.1.5
    ". []

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

Newerposts

Copyright © 2018 RenatoMartini.Net

Theme by Anders NorenUp ↑