A partir dos relatos de ex-funcionários de um banco, segue como que ele passou a utilizar recursos criptográficos em seus sistemas. Foi usada uma placa criptográfica integrada a um computador IBM, no geral semelhante aos coprocessadores criptográficos que a IBM utiliza em seus computadores de grande porte – IBM PCIe Cryptographic Coprocessors, cuja documentação está nesse link. Pelo que se recorda, a placa já vinha instalada no computador ou fazia parte do conjunto de equipamentos e serviços alugados pelo banco. Tanto o hardware quanto o software criptográfico integravam essa solução.
1. A criação da Master Key
Para iniciar a utilização do sistema, foi necessário criar uma Master Key (chave mestra), que servia como elemento fundamental da hierarquia de chaves criptográficas. Sua função era proteger as demais chaves utilizadas nas operações de criptografia, de modo que elas pudessem ser armazenadas e utilizadas com segurança, sem que precisassem ficar expostas em sua forma original.
Para isso, foi estabelecido um procedimento formal denominado Cerimônia de Criação da Master Key. Embora o nome pudesse parecer pomposo, tratava-se de um processo de segurança destinado a garantir que a criação da chave mestra ocorresse sob controle rigoroso, com a participação de mais de uma pessoa e a proteção dos componentes utilizados em sua composição.
O procedimento previa a utilização de um terminal conhecido como terminal burro, isto é, um dispositivo sem capacidade significativa de processamento próprio, utilizado basicamente para entrada e saída de dados. Esse terminal era conectado diretamente ao computador por meio de um cabo, sem utilizar qualquer tipo de rede. A IBM também dispunha de um microcomputador com recursos criptográficos próprios para esse tipo de serviço, mas, naquela ocasião, foi utilizado o terminal.
O ex-funcionário não se recorda do tamanho exato da Master Key, mas lembra que ela era obtida a partir da operação lógica XOR entre três chaves, escolhidas por três funcionários diferentes. O XOR (exclusive OR, ou “ou exclusivo”) é uma operação lógica que combina dois conjuntos de bits e produz um resultado no qual cada bit depende dos bits correspondentes das entradas. Aplicada sucessivamente a três componentes, essa operação permite compor uma chave a partir das contribuições individuais.
Cada funcionário registrava sua chave em um documento, que era depositado por ele próprio no cofre de uma agência bancária. Os três documentos ficavam guardados em agências diferentes. Sua retirada só poderia ocorrer mediante a assinatura do funcionário responsável pelo depósito ou de um diretor do banco. Nesse último caso, a assinatura deveria ser conferida com base em um cartão de assinaturas do respectivo diretor, mantido pela agência.
Dessa forma, a segurança não dependia apenas da proteção física oferecida pela placa criptográfica. A própria composição da chave mestra estava sujeita a controles administrativos e físicos, distribuindo a responsabilidade entre diferentes funcionários e locais. Consequentemente, uma eventual alteração da Master Key exigiria a realização de um novo procedimento de composição a partir dos três componentes, conforme o processo descrito.
2. A integração da criptografia aos sistemas do banco
As operações de criptografia e descriptografia eram realizadas por meio de chamadas às APIs (Application Programming Interfaces) disponibilizadas pelo software da placa criptográfica. Uma API é um conjunto de funções e interfaces que permite a um programa utilizar os recursos de outro componente de software ou equipamento sem precisar implementar diretamente todas as operações internas.
No banco, essas APIs eram encapsuladas por rotinas escritas em COBOL, linguagem de programação bastante utilizada em sistemas corporativos e bancários. Assim, os aplicativos do banco podiam solicitar operações criptográficas por meio dessas rotinas, enquanto a execução dos procedimentos era delegada ao software e ao hardware especializados.
Essa arquitetura permitia integrar os recursos criptográficos aos sistemas já existentes, sem que cada aplicação precisasse implementar por conta própria os algoritmos e os mecanismos de proteção das chaves.
3. As aplicações da criptografia
A criptografia era empregada em diferentes tipos de comunicação utilizados pelo banco. Entre os exemplos lembrados pelo ex-funcionário estavam as conexões entre o mainframe — o computador central de grande porte que processava parte significativa das operações bancárias — e os servidores das agências, os servidores do serviço de Banco por Telefone, os servidores dos serviços de internet, que ainda estavam em seus estágios iniciais, e os terminais instalados nas agências.
Também eram protegidas as comunicações relacionadas à autorização de operações com cartões de débito e as trocas de informações com as operadoras de cartões de crédito.
O emprego da criptografia nesses diferentes pontos tinha como objetivo proteger os dados transmitidos entre os sistemas, dificultando que informações sensíveis fossem compreendidas por terceiros que eventualmente conseguissem interceptar as comunicações.
4. O estabelecimento de canais seguros de comunicação
Como o custo computacional da criptografia assimétrica era muito elevado, o procedimento adotado consistia em estabelecer um canal seguro para cada conexão. Nesse processo, as duas extremidades da comunicação — por exemplo, um computador central e um servidor de uma agência — trocavam uma chave simétrica, cuja autenticidade era estabelecida por meio de mecanismos baseados em criptografia assimétrica.
A criptografia assimétrica utiliza um par de chaves relacionadas matematicamente: uma chave pública e uma chave privada. A chave pública pode ser compartilhada, enquanto a chave privada deve permanecer sob controle de seu titular. Esse tipo de criptografia permite, entre outras aplicações, estabelecer mecanismos de autenticação e proteger a troca de informações necessárias à criação de uma sessão segura.
Já a criptografia simétrica utiliza a mesma chave secreta, ou chaves derivadas dela, para cifrar e decifrar os dados. Em geral, ela apresenta um custo computacional menor e é mais adequada para processar grandes volumes de informação.
Assim, uma vez estabelecido o canal seguro e compartilhada de maneira protegida a chave simétrica da sessão, o tráfego de dados entre as duas extremidades passava a ser criptografado e descriptografado por meio dessa chave. A combinação dos dois métodos permitia aproveitar a capacidade da criptografia assimétrica para estabelecer a confiança e proteger a troca inicial de chaves, utilizando a criptografia simétrica para a comunicação subsequente.
5. Os algoritmos utilizados
A criptografia assimétrica utilizada era baseada no algoritmo RSA, enquanto a criptografia simétrica usava DES. O RSA é um algoritmo de criptografia assimétrica que se baseia em propriedades matemáticas relacionadas à fatoração de números inteiros grandes. O DES (Data Encryption Standard) foi um algoritmo de criptografia simétrica amplamente utilizado em sistemas comerciais e financeiros. Seu sucessor evolutivo, o 3DES (Triple-DES), aplica o DES repetidamente para aumentar a segurança em relação à versão original. O AES (Advanced Encryption Standard) é um algoritmo simétrico mais moderno, que viria a substituir amplamente o DES e o 3DES futuramente.
Modernização da infraestrutura criptográfica do banco
Em 2000, durante uma auditoria realizada, foi apontado que o banco utilizava um algoritmo criptográfico considerado fraco, implementado exclusivamente por software, e que as chaves criptográficas não estavam armazenadas de forma suficientemente segura. Segundo a apresentação do projeto, essas condições representavam um risco para a segurança das operações e para a ocorrência de fraudes.
Diante desse diagnóstico, foi constituída uma equipe envolvendo a área de Segurança do banco, a IBM, os auditores e representantes das áreas de aplicação. Entre os setores envolvidos estavam os sistemas de cartões de crédito e débito, as agências bancárias e os canais de automação. O grupo estudou soluções disponíveis no mercado, visitou outros bancos e entrou em contato com a IBM para avaliar alternativas que elevassem o nível de proteção da infraestrutura criptográfica.
A proposta resultante foi investir em criptografia baseada em hardware, utilizando o algoritmo Triple-DES e estabelecendo procedimentos para a troca periódica das chaves. A iniciativa não se limitava à substituição de um algoritmo: envolvia também a proteção física e lógica das chaves, a padronização do acesso aos recursos criptográficos e a criação de procedimentos operacionais e administrativos para controlar seu ciclo de vida.
1. A adoção do hardware criptográfico e do ICSF
A solução utilizava um módulo criptográfico de hardware da IBM instalado no ambiente de mainframe: Host Secure Module (HSM). O objetivo era transferir operações criptográficas sensíveis para um componente especializado, em vez de depender exclusivamente de rotinas executadas por software convencional.
O HSM era integrado ao ambiente por meio do ICSF (Integrated Cryptographic Service Facility), serviço da IBM que disponibilizava funções criptográficas para os sistemas executados no mainframe. Por intermédio de suas interfaces de programação, as aplicações podiam solicitar operações de cifração e decifração, cálculo de códigos de autenticação e execução de funções específicas dos sistemas de cartões, entre outras tarefas.
Eram três recursos criptográficos principais: Triple-DES, para cifração simétrica; RSA, para criptografia assimétrica; e SHA-1, para funções de resumo criptográfico (hash). Esses recursos atendiam a necessidades diferentes e complementares. O Triple-DES era utilizado para proteger informações por meio de chaves compartilhadas; o RSA permitia operações baseadas em pares de chaves públicas e privadas; e o SHA-1 produzia resumos utilizados em determinados mecanismos de integridade e autenticação.
Quanto aos mecanismos de proteção contra tentativas de violação do equipamento, o HSM possuía recursos destinados a apagar informações protegidas caso detectasse ataques físicos ou lógicos. Essa característica fazia parte da estratégia de impedir que alguém obtivesse as chaves simplesmente acessando o equipamento.
A implantação, entretanto, dependia de condições que iam além da aquisição do hardware. No ambiente de mainframe IBM utilizado pelo banco, era necessário solicitar a ativação do HSM. Em 2002, esse processo teria levado aproximadamente um ano, em razão da autorização necessária por parte do governo dos Estados Unidos. A análise considerava a empresa, o país e a atividade comercial envolvida. Esse episódio evidencia que a adoção da tecnologia também dependia de procedimentos de autorização externos ao banco e ao fornecedor.
2. Organização e proteção das chaves criptográficas
Um dos aspectos centrais do projeto era a organização hierárquica das chaves e a definição de mecanismos para protegê-las. As Master Keys (MKs), utilizadas para proteger outras chaves, das Working Keys (WKs), empregadas nas operações criptográficas realizadas pelas aplicações. Working Key ou Chave de Trabalho é uma chave criptográfica usada operacionalmente para proteger dados ou transações. Por ser uma chave importante, ela geralmente não é conhecida por uma única pessoa. Em vez disso, ela é dividida em partes chamadas componentes, que ficam sob a custódia de pessoas diferentes.
Quanto aos domínios criptográficos associados às partições lógicas do mainframe (Logical Partitions, ou LPARs), o HSM dispunha de 16 domínios, correspondentes ao número máximo de LPARs considerado naquela configuração. Cada domínio podia manter uma LMK (Local Master Key) e uma AMK (Asymmetric Master Key). A LMK era utilizada na proteção de chaves simétricas armazenadas no CKDS (Cryptographic Key Data Set), enquanto a AMK protegia chaves assimétricas armazenadas no PKDS (Public Key Data Set).
Esses conjuntos de dados continham chaves protegidas, e não simplesmente valores em texto aberto disponíveis para qualquer aplicação. Existiam cópias desses conjuntos em uma área de endereçamento protegida e mecanismos de propagação das atualizações dentro de uma mesma LPAR. Quando os conjuntos eram compartilhados entre diferentes partições, era necessário considerar a atualização das cópias correspondentes em cada ambiente.
Essa organização permitia separar a proteção das chaves utilizadas pelas aplicações da utilização direta das chaves mestras. Em termos práticos, uma aplicação podia solicitar uma operação criptográfica identificando a chave de trabalho pertinente, enquanto o ambiente criptográfico cuidava dos procedimentos necessários para utilizar essa chave de maneira protegida.
3. A cerimônia de entrada da Master Key
A entrada das chaves mestras era tratada como um procedimento formal, com responsabilidades distribuídas entre diferentes custodiantes. A Master Key era composta por três componentes aleatórios, inseridos separadamente por pessoas distintas. A separação tinha como finalidade evitar que uma única pessoa conhecesse ou controlasse, isoladamente, todos os elementos necessários para formar a chave.
Cada componente possuía um custodiante e um substituto. Os componentes eram registrados em formulários, colocados em envelopes lacrados e assinados e mantidos em cofre, sob controle de acesso duplo. Também eram preparados envelopes de reserva, submetidos a procedimentos semelhantes de guarda.
O documento identifica representantes de três áreas como responsáveis pelos componentes: a área de Segurança da IBM no Brasil, a área de Segurança de Tecnologia da Informação do banco e a área de Soluções de Tecnologia da Informação do banco. A participação de áreas diferentes reforçava a segregação de responsabilidades e reduzia a possibilidade de que uma única equipe controlasse todo o processo.
A entrada dos componentes era realizada por meio de um terminal 3270 conectado diretamente a um controlador, com o objetivo de evitar a interceptação dos componentes da chave durante a transmissão. A operação utilizava uma ferramenta do ICSF no ambiente TSO (Time Sharing Option).
Após a entrada dos três componentes, o ICSF combinava seus valores por meio de uma operação XOR (exclusive OR), formando a Master Key. O procedimento incluía o armazenamento temporário da nova chave em um registrador auxiliar. Em seguida, eram solicitadas a recifragem dos conjuntos de dados e a atualização das chaves de trabalho protegidas pela chave mestra anterior. Por fim, a nova Master Key era transferida do registrador auxiliar para a posição permanente.
Esse processo demonstra que a troca de uma chave mestra não era uma simples substituição de um valor. Era uma operação coordenada, que exigia preservar a capacidade de utilizar as chaves já existentes, atualizar sua proteção e controlar a transição entre a chave antiga e a nova.
4. As Working Keys e os controles de custódia
As chaves de trabalho também eram inseridas segundo procedimentos de custódia, podendo ser compostas por dois ou três componentes, conforme o caso. Quando eram utilizados dois componentes, um ficava sob responsabilidade da área usuária e o outro da área de Segurança de Tecnologia da Informação do banco. Nos casos de três componentes, os dois primeiros provinham da área usuária, enquanto o terceiro era fornecido pela área de Segurança de Tecnologia da Informação.
Assim como no procedimento das chaves mestras, os componentes eram submetidos a controles de registro, lacre e guarda. Havia uma aplicação desenvolvida em PLI e executada no ambiente ISPF/TSO para realizar a entrada das Working Keys. PLI (Programming Language One) é uma linguagem de programação da IBM, derivada do PL/I, utilizada em ambientes corporativos de grande porte para desenvolver aplicações e rotinas executadas no mainframe. ISPF/TSO é o ambiente interativo do mainframe IBM em que o TSO (Time Sharing Option) permite executar comandos e programas, enquanto o ISPF (Interactive System Productivity Facility) oferece uma interface baseada em menus e painéis para facilitar tarefas de desenvolvimento e administração, como a execução da aplicação utilizada para inserir as chaves criptográficas.
Houve uma evolução planejada para esse procedimento: a adoção do TKE (Trusted Key Entry), uma estação de trabalho especializada, dotada de recursos criptográficos próprios, que poderia ser conectada à rede local. A proposta permitiria substituir a conexão direta do terminal 3270 ao controlador por uma solução específica para a administração e a entrada segura de chaves.
A cerimônia de entrada, a distribuição dos componentes entre custodiantes, a guarda dos envelopes e a existência de substitutos mostram que a segurança pretendida dependia tanto dos mecanismos criptográficos quanto dos controles humanos e administrativos. A proteção não era tratada apenas como uma propriedade matemática do algoritmo, mas como um processo que abrangia pessoas, equipamentos, registros e procedimentos.
5. A padronização do acesso criptográfico pelas aplicações
A implantação do HSM e do ICSF exigia que as aplicações do banco pudessem utilizar os serviços criptográficos de forma consistente. Para isso, foram desenvolvidas aproximadamente 60 rotinas destinadas a padronizar o acesso das aplicações ao ambiente criptográfico.
Essas rotinas ofereciam funções como cifração e decifração, cálculo de hash e de códigos de autenticação de mensagens (MAC), geração e verificação de valores relacionados a senhas de cartões, geração de PINs, conversão entre ASCII e EBCDIC (Extended Binary Coded Decimal Interchange Code, sistema de codificação de caracteres de 8 bits criado pela IBM), geração e armazenamento de chaves, exportação e troca de chaves, tradução entre formatos criptográficos, geração de pares de chaves públicas e privadas, assinaturas digitais e comunicação segura entre plataformas.
No contexto dos cartões bancários, eram usadas funções como PVV (PIN Verification Value), CVV (Card Verification Value) e CVC (Card Verification Code). Esses mecanismos estão associados à verificação de informações utilizadas em operações com cartões e senhas. O uso de rotinas padronizadas permitia que as aplicações recorressem às funções criptográficas sem precisar implementar individualmente toda a lógica de acesso ao HSM.
Veja o exemplo do sistema de cartões de débito: para armazenar um PIN de forma protegida no banco de dados, a aplicação chamava uma rotina de codificação, fornecendo o PIN e o identificador da chave de dados a ser utilizado. A rotina intermediava a operação com a infraestrutura criptográfica, concentrando em um ponto padronizado a lógica de acesso e o uso da chave correspondente.
Essa arquitetura favorecia a reutilização das funções, a uniformidade entre sistemas e a centralização dos controles criptográficos. Em vez de cada aplicação desenvolver sua própria implementação, os sistemas podiam utilizar um conjunto comum de rotinas e serviços.
6. Governança e conformidade
A área de Segurança da IBM no Brasil teve a responsabilidade de documentar a “Cerimônia de Entrada da Chave”, assinar os envelopes lacrados e acompanhar a política e os procedimentos relativos à Master Key. O projeto também buscava atender às políticas da VISA International, com o objetivo de obter certificação para as atividades de emissão e adquirência de cartões.
A preocupação com a conformidade ajuda a compreender o alcance da iniciativa. A adoção de algoritmos mais robustos e de um HSM era acompanhada por regras de custódia, segregação de funções, documentação, controle de acesso e procedimentos para a entrada e a substituição de chaves. O objetivo era estabelecer um ambiente em que as operações criptográficas fossem protegidas por mecanismos técnicos e por uma estrutura formal de responsabilidades.
Os funcionários também conheceram experiências de outros bancos com soluções de hardware criptográfico. Um dos estabelecimentos visitados utilizava um equipamento RACALL em uma plataforma de menor porte e avaliava a adoção de um HSM IBM, em razão de dificuldades relatadas de suporte e desempenho. O Banco do Brasil foi o primeiro banco brasileiro a implementar com sucesso o HSM da IBM. Essas informações aparecem como parte do levantamento realizado durante a avaliação das alternativas tecnológicas.
Arquitetura de gerenciamento de chaves em um ambiente IBM Z, mostrando como as Master Keys (MK) e Working Keys (WK) são inseridas e protegidas. A entrada das chaves pode ser realizada por meio do TKE (Trusted Key Entry), do painel TSO (Time Sharing Option) com funções do ICSF (Integrated Cryptographic Service Facility) ou pelos utilitários KEYXPART/DIXPART para entrada de componentes de chaves. O ICSF atua como a camada de software que controla as operações criptográficas e se comunica com o HSM (Hardware Security Module), onde ficam armazenadas as chaves-mestre. As chaves simétricas são mantidas no CKDS (Cryptographic Key Data Set) e protegidas pela LMK (Local Master Key), enquanto as chaves assimétricas são armazenadas no PKDS (Public Key Data Set) e protegidas pela AMK (Asymmetric Master Key).
Formulário de Custódia
O Formulário de Custódia do Componente WK (Working Key) é um documento de segurança utilizado para registrar e controlar a guarda de um componente de chave criptográfica. Ele identifica quem é o custodiante da parte da chave, qual componente ele possui e os dados necessários para validação da chave. Veja essse exemplo:
A primeira página do formulário contém:
- Identificação do componente da Working Key (1º, 2º ou 3º componente).
- Dados do custodiante (área e nome).
- Nome da chave (Key Name/Label).
- Tipo da chave (Key Type).
- Campos para registrar os valores dos componentes da chave.
- Campo para o KCV (Key Check Value), que serve para verificar a integridade da chave (funciona como uma “impressão digital” curta).
- Campo de KCV Combinada, resultante após a combinação de todos os componentes da chave (preenchido exclusivamente pela área de Segurança da Informação).
- Empresas onde a chave foi digitada ou utilizada.
As páginas seguintes apresentam grades com caracteres hexadecimais (0-9 e A-F) para que o custodiante marque os dígitos do seu componente de chave, sem escrever diretamente o valor da chave em texto livre. São previstas até três partes:
- 1ª parte (Single Length) – Possui 16 caracteres hexadecimais (8 bytes).
- 2ª parte (Double Length) – Possui 32 caracteres hexadecimais (16 bytes).
- 3ª parte (Triple Length) – Possui 48 caracteres hexadecimais (24 bytes).
Esse tipo de formulário é comum em ambientes financeiros, meios de pagamento, HSMs e gestão de chaves criptográficas. A ideia é que uma chave importante seja dividida em componentes e cada parte fique sob a responsabilidade de um custodiante diferente, reduzindo o risco de uma única pessoa conhecer ou controlar a chave completa.