Pedigree

Um dos sistemas do Banco Central que mais tinha necessidade de segurança era o SPB (Sistema de Pagamentos Brasileiro), o sistema que permite aos bancos fazerem pagamentos entre si e gerenciarem a chamada conta reserva, a conta que os bancos são obrigados a manter junto ao Banco Central contendo uma certa porcentagem do dinheiro depositado pelos clientes. Na época, o SPB transacionava o equivalente ao PIB do Brasil a cada três dias. O time de segurança tratava de diversos aspectos do sistema, começando pela rede que interliga os bancos ao Banco Central, chamada de Rede do Sistema Financeiro Nacional (RSFN), até alguns aspectos de segurança de sistemas, como a definição dos mecanismos de segurança do protocolo usado na comunicação entre os bancos e o Banco Central.

Quando eu cheguei, o SPB já estava em funcionamento havia alguns anos e os protocolos já estavam definidos e implementados em produção. Com o tempo, alguns aspectos desses protocolos começaram a ficar um pouco antigos, em especial os algoritmos criptográficos usados. O chefe da área percebeu meu interesse e conhecimento em criptografia e nós começamos a conversar sobre possibilidades de melhoria nos protocolos do SPB. Na época, ainda eram usados o DES, o MD5 e o RSA como algoritmos básicos para criptografar e assinar as mensagens, e eles já começavam a ser considerados pouco seguros. A ideia que surgiu não era desenvolver um protocolo completamente diferente, mas simplesmente evoluir o protocolo existente, substituindo as primitivas criptográficas por versões mais modernas.

Um dos princípios básicos da segurança de soluções criptográficas é que as chaves precisam ter um tamanho suficiente para tornar inviáveis os chamados ataques de força bruta, que nada mais são do que tentar todas as possibilidades de chave uma por uma. Se as chaves são pequenas, a quantidade de valores possíveis é exponencialmente menor, tornando esse tipo de ataque factível. Com o aumento da capacidade dos computadores, a cada ano se torna possível testar uma quantidade maior de chaves. Assim, de tempos em tempos, é necessário atualizar os sistemas criptográficos para que usem chaves maiores. Isso pode implicar a substituição de um algoritmo ou simplesmente o aumento do tamanho das chaves usadas, mantendo o mesmo algoritmo.

O SPB usava RSA e DES para cifrar as mensagens e MD5 para gerar os hashes usados nas assinaturas, num modelo muito próximo do usado no PGP que eu já descrevi em um capítulo anterior. O DES já era bastante antigo e não era mais considerado muito seguro, principalmente porque usa chaves de 56 bits. O RSA de 1024 bits ainda era considerado aceitável na época e era o maior tamanho suportado pela maioria dos dispositivos disponíveis. O MD5, por outro lado, era um problema mais sério: já existiam muitos artigos publicados sobre a possibilidade de quebrá-lo em determinadas situações e sobre o fato de que sua quebra completa parecia iminente. Com isso, nossa proposta foi evoluir do DES para o 3DES (ou triplo DES) e substituir o MD5 pelo SHA-1.

Um dos problemas em mexer nos protocolos do SPB é que isso afeta todos os bancos do Brasil, grandes ou pequenos. No início do processo, achamos que os bancos grandes seriam os mais resistentes, já que usam mainframes que possuem hardware criptográfico incorporado. Hardware criptográfico é basicamente um processador especializado que executa apenas as operações necessárias para algoritmos de criptografia. Como são extremamente especializados, para serem mais rápidos, eles não são compatíveis com qualquer algoritmo, o que limita bastante a lista de algoritmos que podem ser usados nos ambientes que dependem desse tipo de co-processador. Para evitar qualquer problema futuro, consultamos a IBM para saber quais algoritmos eram suportados pelos seus mainframes e também confirmamos os tamanhos de chave disponíveis. Assim tivemos certeza de que as propostas seriam compatíveis com o hardware existente nos grandes bancos.

Depois de várias discussões internas, chegou a hora de apresentar a proposta para o grupo de trabalho do SPB que tratava dos assuntos relacionados à segurança. Nós apresentamos não só as mudanças propostas, mas também um cronograma de implementação. O prazo era bastante amplo, justamente para evitar reclamações sobre falta de tempo para adaptação. Para minha surpresa, um dos primeiros apoios veio de um dos maiores bancos privados do Brasil. A fala deles começou com algo como “já estava passando da hora”. Esse apoio foi fundamental para que a proposta fosse aceita integralmente, embora alguns representantes de empresas que desenvolviam software para pequenos bancos tenham reclamado que o prazo estava “apertado”. No final, a proposta foi aprovada e o calendário de alterações definido, embora o prazo final só terminasse no ano seguinte.

Os times de desenvolvimento do Bacen não tiveram muita dificuldade para alterar o software, já que as bibliotecas que utilizavam já estavam preparadas para os novos algoritmos. Um dos problemas que tivemos apareceu no sistema que validava os certificados digitais dos bancos. Quando um banco entrava no sistema ou precisava trocar seu certificado, esse certificado precisava ser submetido ao Banco Central, que fazia uma validação e publicava o certificado em uma lista com todos os certificados válidos. Essa lista era gerada por um programa escrito em C que rodava em uma partição Linux de um mainframe. O desenvolvedor que havia escrito esse código já tinha saído do banco e ninguém nunca havia feito manutenção nele. Acabou sobrando para mim evoluir esse sistema. No final, eu reescrevi tudo em Java, que era a linguagem oficialmente usada pelo Banco Central na época. Deu um pouco mais de trabalho, mas facilitaria a manutenção no futuro.

O mais curioso é que o novo código passou a verificar também a data de início de validade dos certificados. Todo certificado digital tem uma data de início e uma data de fim de validade, mas o código anterior só verificava a data final. Quando passamos a verificar também a data inicial, descobrimos um caso curioso: alguns certificados eram emitidos com validade começando apenas às zero hora do dia seguinte (meia noite). Não me pergunte por quê. Assim, era comum um certificado ser emitido no meio da manhã, mas sua validade só começar no dia seguinte. Em algumas situações, o banco submetia esse certificado ao Banco Central imediatamente após recebê-lo. Isso significava que o certificado ainda não estava válido no momento da submissão. O novo código detectava essa situação e rejeitava o certificado, o que deixava os técnicos do outro lado bastante preocupados e sem entender qual era o problema. Tivemos algumas ligações em que precisávamos explicar que bastava esperar o certificado entrar em vigor antes de submetê-lo para validação. Na prática, era só esperar o dia seguinte e tudo funcionava normalmente.

Algum tempo depois, vi uma chamada para participação de órgãos do governo federal em alguns grupos de trabalho relacionados à segurança da informação. Nessa altura eu já participava de uma comunidade chamada RENASIC (Rede Nacional de Segurança da Informação e Comunicações), que reunia participantes de vários órgãos da administração pública, universidades e empresas para discutir temas relacionados à segurança. Essa rede era coordenada pelo Gabinete de Segurança Institucional da Presidência da República, que foi justamente o órgão responsável pela chamada. Um dos temas mencionados era criptografia. Conversei com meu chefe e ele me autorizou a participar. Nosso maior interesse era garantir que qualquer norma que viesse “de cima” não fosse afetar os protocolos do SPB.

Assim, depois de passar pela burocracia necessária, fui formalmente indicado para participar do grupo de trabalho que iria escrever um padrão sobre o uso de criptografia na administração pública federal. O grupo era coordenado pelo CEPESC, que é o órgão que concentra os especialistas em criptografia do governo federal. Lá fui eu para o primeiro encontro, realizado na sede da ABIN (Agência Brasileira de Inteligência). Lembro que havia todo um protocolo para entrar no prédio e que era proibido levar celulares, por exemplo. O coordenador do grupo era um pesquisador do CEPESC que estava fazendo doutorado em criptografia na UnB, e foi assim que descobri que existia um grupo de pesquisa nessa área na universidade.

No início dos trabalhos, o coordenador assumiu o controle praticamente completo das discussões e tinha uma forte tendência a não aceitar opiniões ou sugestões vindas de outras pessoas. Aquilo me incomodou um pouco, mas continuei tentando contribuir. Ele também tinha o hábito de justificar que as ideias dele eram melhores simplesmente porque estava terminando uma tese na área. Eu não gosto muito de chegar “cantando de galo” e dizendo que sou formado nisso ou naquilo ou que estudei em determinada universidade, mas nesse caso acabei perdendo um pouco a paciência. Mandei um e-mail para o coordenador explicando minhas sugestões sobre como o trabalho deveria ser estruturado e acrescentei uma parte detalhando minha formação na área de criptografia.

De repente, tudo mudou. Não só o coordenador conhecia bem o nome do meu orientador, como também sabia da reputação do grupo de criptografia da Unicamp, que já era um dos mais importantes do Brasil naquela época. Onde eu esperava conflito, encontrei abertura. Foi assim que descobri que algumas pessoas funcionam muito na base do pedigree: se você estudou ou trabalhou em determinados lugares ou com determinadas pessoas, isso pesa mais do que os argumentos técnicos apresentados.

Com isso, conseguimos avançar e entregar uma proposta de padrão de criptografia para o governo federal. O processo levou alguns anos, mas uma versão simplificada do texto que produzimos acabou sendo publicada e ainda hoje é usado no âmbito da administração federal. Do lado do Banco Central, tudo funcionou bem porque o padrão focava em “informação classificada”, o que normalmente significa segredos de Estado. O Banco Central lida principalmente com informação financeira, que exige sigilo, mas não é considerada informação classificada. Esse resultado deixou meu chefe satisfeito, já que os protocolos do SPB não seriam afetados.

À medida que comecei a ouvir mais sobre as pessoas de Brasília que trabalhavam ou lidavam com criptografia, isso acabou abrindo uma oportunidade para me reaproximar dessa comunidade. Mas essa já é uma história para o próximo capítulo.