RenatoMartini.Net

Tag: asn.1

Smartcards & certificados digitais (Parte 1)

Apesar do suporte sofrível que o Linux tem para este tipo de hardware, -- seja usando a dupla PCSC Lite1 + OpenSC2 --, ou com um produto comercial tradicionalíssimo no mundo Windows, o Safesign3 da AET holandesa, é possível usar tais ferramentas para a investigação do mundo dos cartões eletrônicos.

As muitas aplicações no Brasil que usam certificados digitais da cadeia ICP-Brasil usam em geral os certificados gerados e armazenados em dispositivos criptográficos, tokens ou cartões, também chamados de ICC ou integrated circuit card, que seguem o padrão ISO/IEC 7816 (partes 1-6).



Documentos do padrão ISO7816:	

• ISO 7816-1	 Physical characteristics
• ISO 7816-2	 Dimensions and location of the contacts
• ISO 7816-3	 Electronic signals and transmission protocols
• ISO 7816-4	 Industry commands for interchange
• ISO 7816-5	 Number system and registration procedure for application identifiers
• ISO 7816-6	 Interindustry data elements

 

Foi sobretudo com a popularização do chamado eCPF ou eCNPJ4 pela Receita Federal do Brasil que impulsionou e amarrou de certa forma as aplicações a usarem obrigatoriamente cartões ou tokens5. Um cartão eletrônico é sobretudo mais seguro, depois, mais portável, as pessoas estão mais acostumadas e, por fim, dá um pouco de "materialidade" (ou concretude) a um certificado e a assinatura digital. Mas a decisão sobre usar esta ou aquela ferramenta tecnológica deve ser sempre de quem implementa a solução e, portanto, conhece melhor que ninguém as suas necessidades.

Como disse, o leitor deve considerar que no Linux o suporte para cartões e leitores é bastante precário, geralmente boa parte de cartões não é suportada pela suíte OpenSC, que é um manipulador do cartão, e pelo PCSC, que faz o papel de middleware — outro item a ser instalado é o driver CCID6.

Quem vai se aventurar no mundo dos cartões eletrônicos saiba de antemão que talvez seja um dos terremos menos interoperáveis da tecnologia...

 

Após carrega o daemon "pcscd" (geralmente em /etc/rc.d... ou ele já é por default iniciado, dependerá da distro Linux). Depois observe se o pcscd "viu" o seu leitor/cartão:

$ opensc-tool -v -a
Using reader with a card: C3PO LTC31 (80000000) 00 00   
Connecting to card in reader C3PO LTC31 (80000000) 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...  

Note-se a detecção da leitora modelo C3PO LTC31, e o envio/resposta ds APDUs (Smart card application protocol data unit) ‐ que resumidamente é uma espécie de comando & resposta ‐ para o cartão com êxito, que um cartão GD Burti com SO STARCOS. Mas deixemos de lado os protocolos de comunicação entre a leitora e o cartão, definidos na ISO/IEC 7816 Part 4: "Interindustry command for interchange", e vamos falar um pouco do seu sistema de arquivos.


A estrutura lógica de arquivos de um cartão ISO/IEC 7816 compliance é bem simples, composta de dois tipos de arquivos: (1) o "Dedicated file" (DF) e (2) o "Elementary file" (EF). O DF possui por sua vez um arquivo obrigatório que forma a raiz (root) desta estrutura. Ele é chamado de Master file, sendo a presença de outros DFs opcionais. O que forma a seguinte estrutura hierárquica7 :

  Master file   Dedicated file (DF)     Elementary file (EF)

Um EF também se qualifica, se subdividindo entre um "Internal EF" (iEF) que armazenam dados interpretados pelo cartão, dados usados por ele com o escopo de gerir e controlar e um "Working EF" (wEF), estes EFs armazenam dados não interpretados pelo cartão, e que serão usados exclusivamente no mundo fora do smartcard.

  Master file   Dedicated file (DF)     Elementary file (EF)   iEF   e wEF  

Os arquivos são sempre referenciados por um "identificador" de 2 bytes, um file identifier (FI). Por exemplo, o MF é obrigatoriamente referenciado no valor 3F00, ‐ e 2F00 é também reservado para armazenar application identifiers (AIDs) e caminho das aplicações associadas. E a concatenação destes identificadores formam o path do sistema de arquivos do cartão.

Trabalhando agora no console do Linux podemos observar um pouco este tópico, aqui apresentado resumidamente. Vamos fazer um dumping dos objetos internos do cartão com uma das ferramentas do OpenSC ("pkcs15-tool -D..."):

$ pkcs15-tool -D
Using reader with a card: ACS ACR 38U-CCID 00 008
PKCS#15 Card [Renato Martini                  ]:
        Version        : 0
        Serial number  : 2091222300122C13
        Manufacturer ID: A.E.T. Europe B.V.
        Flags          : Login required, EID compliant

(...) etc...

X.509 Certificate [RENATO MARTINI's Autoridade Certificadora da Casa da Moeda do Brasil ID]
        Object Flags   : [0x2], modifiable
        Authority      : no
        Path           : 3f0050154300  
        ID             : 3230383733363636283734362d346635326236353266623339
        GUID           : {05106e64-ec4d-bf1e-8d8e-b276346e5289}
        Encoded serial : 02 10 32303130303631303134303234373732

 

Aqui está o path...

O OpenSC possui uma ferramenta interativa chamada "opensc-explorer", ali podemos visualizar a estrutura lógica aqui descrita, e fazer várias operações como apagar o cartão, criar e apagar EFs, mudar PIN/PUK, enviar comandos APDUs, etc., consulte a ajuda no SO.
Dentro do shell do opensc-explorer, digite "find", use-o sem argumentos para varrer todos os arquivos e assim nos mostrar os arquivos presentes, mas pode ser usado varrendo blocos de arquivos desejados entre 0000 até FFFF:

OpenSC [3F00]> find
FileID  Type  Size
[5015]    DF     0
OpenSC [3F00]> cd 5015

 
O opensc-explorer de imediato nos jogará no MF EF00. Mas se já conhecemos o path, podemos ir direto para ele:

 
$ opensc-explorer --mf 5015
 

Encontramos o path "3F00/5015"9, exatamente o MF "3F00", e mudamos para o DF "5015". Dentro dele podemos ver os vários wEF, mais uma vez find:

OpenSC [3F00/5015]> find
FileID  Type  Size
 4300    wEF 10037
 4301    wEF   202
 4400    wEF  2298
 4401    wEF  1500
 4404    wEF  3860
 4407    wEF   600
 4408    wEF   255
 4601    wEF   932
[5015]    DF     0
 5031    wEF    48
 5032    wEF   117
 5033    wEF   324
 5342    wEF   576
 5362    wEF    64

Num cartão por mim inicializado10, podemos ver no opensc-explorer o outro arquivo reservado pelo padrão ISO: o 2F00 que mostra a aplicação/fabricante que manipulou o cartão. O OpenSC usa o standard PKCS#15 que aqui aparece identificado:

OpenSC [3F00]> cat 2F00
00000000: 61 21 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 a!O. ...cPKCS-15
00000010: 50 0B 4F 70 65 6E 53 43 20 43 61 72 64 51 04 3F P.OpenSC CardQ.?
00000020: 00 50 15 00 00 00 00 00 00 00 00 00 00 00 00 00 .P..............
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Anteriormente já tínhamos visto o path para o certificado digital em "3F00/5015/4300"; agora ele aparece aqui listado entre outros wEF:

FileID  Type  Size
 4300    wEF 10037  

Podemos dentro do shell, visualizá-lo e mesmo fazer um dumping em formato ASN.1. Por exemplo, use o comando "cat" para mostrar a estrutura do certificado e também no shell "asn1 4300" para apresentá-lo na notação ASN.1, mais legível. Pode-se por fim gravar num arquivo fora da estrutura do smartcard, no seu HD, aqueles arquivos que podem ser lidos, bem entendido.

OpenSC [3F00/5015]> cat 4300
00000000: 30 82 05 77 30 82 04 5F A0 03 02 01 02 02 10 32 0..w0.._ ......2
00000010: 30 31 30 30 36 31 30 31 34 30 32 34 37 37 32 30 0100610140247720
00000020: 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 60 ...*.H.÷......0`
00000030: 31 0B 30 09 06 03 55 04 06 13 02 42 52 31 13 30 1.0...U....BR1.0
00000040: 11 06 03 55 04 0A 13 0A 49 43 50 2D 42 72 61 73 ...U....ICP-Bras
00000050: 69 6C 31 3C 30 3A 06 03 55 04 03 13 33 41 75 74 il1<0:..U...3Aut
00000060: 6F 72 69 64 61 64 65 20 43 65 72 74 69 66 69 63 oridade Certific
00000070: 61 64 6F 72 61 20 64 61 20 43 61 73 61 20 64 61 adora da Casa da
00000080: 20 4D 6F 65 64 61 20 64 6F 20 42 72 61 73 69 6C  Moeda do Brasil
00000090: 30 1E 17 0D 31 30 30 36 31 30 31 34 32 38 34 35 0...100610142845
000000A0: 5A 17 0D 31 33 30 36 30 39 31 34 31 39 32 30 5A Z..130609141920Z
000000B0: 30 81 B4 31 0B 30 09 06 03 55 04 06 13 02 42 52 0.´1.0...U....BR
000000C0: 31 13 30 11 06 03 55 04 0A 13 0A 49 43 50 2D 42 1.0...U....ICP-B
000000D0: 72 61 73 69 6C 31 3C 30 3A 06 03 55 04 0B 13 33 rasil1<0:..U...3
000000E0: 41 75 74 6F 72 69 64 61 64 65 20 43 65 72 74 69 Autoridade Certi
000000F0: 66 69 63 61 64 6F 72 61 20 64 61 20 43 61 73 61 ficadora da Casa
00000100: 20 64 61 20 4D 6F 65 64 61 20 64 6F 20 42 72 61  da Moeda do Bra
00000110: 73 69 6C 31 12 30 10 06 03 55 04 0B 13 09 43 45 sil1.0...U....CE

(...) etc etc ...

 
Revisão v. 2.1.1
 

 

  1. Projeto PCSC []
  2. OpenSC - tools and libraries for smart cards []
  3. AET Europe []
  4. http://www.receita.fazenda.gov.br []
  5. Uma exceção é o aplicativo ConectividadeSocial da CEF para comunicação do FGTS, que permite o uso do certificado A1, ou seja, gerado e armazenado em software, como os chamados PKCS#12 []
  6. Driver genérico USB CCID []
  7. Consultar: ISO/IEC 7816-4, cap.5 "Basic organizations"; e W. Rankl & W. Effing.Smart Card Handbook: Wiley & Sons, 3a. ed. []
  8. http://www.bit4id.com/en/ []
  9. O DF 5015 é padrão para o PKCS#15... []
  10. No jargão significa uma "formatação" e uma criação do sistema de arquivos do smartcard... []

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 © 2018 RenatoMartini.Net

Theme by Anders NorenUp ↑