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 STR Parser XML Converte código Procedimentos de segurança 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 STR Parser XML Converte código LOG report Procedimentos de segurança DTD Parser XML Converte código Msg assinada LOG report LOG Confere assinatura Certificado digital BC report Decifra 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.