RenatoMartini.Net

Category: smartcards

IV Seminário Nacional de Certificação Digital será realizado em junho

O IV Seminário Nacional de Certificação Digital, evento que apresentará os usos e benefícios da certificação digital no padrão da Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil, será realizado nos dias 15 e 16 de junho, em São Paulo, paralelamente a 21ª Cards Payment & Identificantion, maior feira de tecnologia para o setor de cartões, meios eletrônicos de pagamento, identificação e certificação digital da América Latina.

Como nos anos anteriores, o evento, realizado pelo Instituto Nacional de Tecnologia da Informação – ITI e pela Associação Brasileira das Empresas de Tecnologia em Identificação Digital – Abrid, contará com a participação de palestrantes dos mais variados setores que vão apresentar soluções que fazem uso do certificado ICP-Brasil e os benefícios alcançados com o uso desta ferramenta.

Para o diretor-presidente do ITI, Renato Martini, o evento já está consolidado e faz parte da agenda de todos que têm interesse no setor de certificação digital. “O Seminário Nacional de Certificação Digital já é um evento aguardado por todo o mercado de certificação digital, indústria, usuários e desenvolvedores, quando todos participam do evento para conhecer mais sobre as melhores práticas no setor de certificação digital, além dos usos e benefícios da tecnologia”, afirmou Martini.
Em breve, estarão disponíveis no sítio do ITI mais informações sobre o IV Seminário Nacional de Certificação Digital, como a programação completa, data de início das inscrições, que serão gratuitas, e horários do evento.

IV Seminário Nacional de Certificação Digital
Local: Expo Center Norte – Pavilhão Azul. Rua José Bernardo Pinto, 333 – Vila Guilherme
São Paulo – SP
Contato: Assessoria de Comunicação – ASCOM/ITI
E-mail: comunicacao@iti.gov.br
Telefone: 55 (61) 3424-3892

--Fonte: www.iti.gov.br

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

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

Copyright © 2017 RenatoMartini.Net

Theme by Anders NorenUp ↑