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