Interoperabilidade
de hardware e
software
Sergio Regado
SPB primeiro grande usuário
No Brasi, o primeiro grande usuário de certificação
digital foi o SPB (Sistema de Pagamentos Brasileiro),
como não havia padrões no Brasil para a utilização de
PKI (depois fez pequenas alterações para utilizar os
certificados da ICP-Brasil), o SPB definiu o seu próprio
padrão:
• Todas as mensagens possuem um header de
segurança binário, seguido do conteúdo da
transação que pode estar em XML ou TXT.
• Todas as mensagens são assinadas e opcionalmente
criptografadas.
• Como meio de comunicação, adotou-se o IBM MQ
Series para a troca de mensagens entre as diversas
plataformas do sistema financeiro.
Fluxo Operacional SPB
Legado
Procedimentos de segurança
STR
Parser XML
DTD
Converte código
Assinatura digital
Msg
assinada
LOG
Certificado digital da IF/C
LOG
Cifragem
Certificado digital BC
Msg assinada e cifrada
Fluxo Operacional SPB
Legado
Procedimentos de segurança
STR
Parser XML
DTD
Converte código
Msg
assinada
LOG
LOG
report
Confere assinatura
Certificado digital BC
Decifra
report
Certificado digital IF/C
Msg assinada e cifrada
Recomendação Técnica Febraban
Em seguida, alguns bancos passaram adotar a
certificação digital para autenticar usuários e assinar
transações em seus Internet bankings, mas sem nenhum
padrão em comum, onde cada IF criou seu próprio
padrão.
Para resolver o problema de repúdio, fraudes e agilizar a
troca de documentos entre IFs, a FEBRABAN tomou a
iniciativa de definir os requisitos mínimos para a troca
de documentos assinados digitalmente entre IFs
(Assinatura Digital Recomendações Técnicas e
Operacionais Versão 1.02).
Recomendação Técnica Febraban – cont.
Principais recomendações:
• Algoritmos de criptografia (3DES ou AES), hash
(SHA-1) e assinatura (RSA)
• Formato da mensagem (PKCS#7)
• Conversão para caracter (BASE64)
• Compactação (ZLIB)
• Formato do conteúdo da mensagem (XML ou TXT)
• Meio físico para a troca das mensagens (SSL ou VPN).
• Utilizar certificados tipo A3 (geração e
armazenamento de chaves em hardware).
Resolução técnica ITI
Mesmo assim, perdurava o problema da
incompatibilidade dos dispositivos de hardware e
software que fazem o armazenamento das chaves
privadas e certificados digitais.
Da forma que estava, o usuário acabaria tendo “n”
certificados digitais, já que os dispositivos que
armazenam as respectivas chaves privadas são
incompatíveis entre si, além disso, para se desenvolver
um ATM, por exemplo, deveria-se ter um leitor de
SmartCard para cada cartão disponível no mercado!!
Para resolver esse problema, veio à resolução técnica do
ITI sobre os requisitos mínimos de hardware e software
para armazenamento de chaves privadas e certificados
digitais, que está atualmente em consulta publica
(http://www.iti.br/).
Resolução ITI – Repositório em Software
• API para acesso ao repositório deve ser compatível com:
• Padrão PC/SC versão 1.0
• Padrão CSP (plataforma Microsoft)
• Padrão PKCS # 11
• Mídias de armazenamento, desde disquetes, CD´s, até
códigos de barras bidimensional (Ex.: PDF247).
• Pacote de software deverá ser homologado pelo ITI ou
entidade por este designada.
• Prevê a existência de dois tipos de solução: offline, em
que o usuário fornece a senha para ter acesso a chave
privada e online em que um serviço central
(possivelmente uma CA) faz a validação da senha e
libera um segredo complementar para a liberação da
chave privada do usuário. Neste modo, semelhante a um
smart-card, o ponto central controla o número de
tentativas para acertar a senha, podendo bloquear o
repositório definitivamente.
Resolução ITI – Repositório em Hardware
Dispositivos tipo Smart Card
• Seguir o padrão ISO 7816 partes 1 a 6.
• Ser compatível com leitoras que suportem os padrões:
ISO 7816-3, PC/SC e EMV96.
• Permitir conexão com leitoras com protocolo T=0, T=1.
• Possuir interface T=0 com velocidade mínima de 4.800
baud.
• Possuir interface T=1 com velocidade mínima de 4.800
baud.
Resolução ITI – Repositório em Hardware
(cont)
Dispositivos tipo Token USB
• Possuir conector USB (Universal Serial Bus) tipo A,
versão 1, ou superior;
• Possuir indicador luminoso de estado do dispositivo;
• Permitir conexão direta na porta USB sem necessidade
interface intermediária para leitura.
API para acesso ao repositório deve ser compatível com:
• Padrão PC/SC versão 1.0;
• Padrão CSP (plataforma Microsoft)
• Padrão PKCS # 11
O que falta?
Uma vez colocadas em prática as recomendações
anteriores, o próximo passo seria padronizar a
comunicação bancos / clientes, o chamado SPB2.
Apesar da tentativa de se padronizar os layouts, via
FEBRABAN 240, na prática o que verificamos e um
enorme conjunto de layouts e os mais variados meios
físicos de comunicação. Padronizar as transações em
XML e o meio físico representa uma grande redução de
custos em infra estrutura e desenvolvimento para os
bancos e seus clientes. Uma solução dessas, permitirá o
desenvolvimento de aplicativos genéricos que trocarão
mensagens com qualquer banco onde o cliente possua
conta, fazendo conciliação de extratos, pagamentos de
contas, cobrança, etc. As mensagens trafegarão
assinadas e criptografadas e os bancos, por sua vez,
farão o controle de acesso e alçadas, utilizando os
respectivos certificados dos clientes.