Pedigree

One of the Central Bank systems with the greatest security requirements was called SPB (Brazilian Payment System), the system that allows banks to make payments between one another and manage what is known as the reserve account, an account banks are required to maintain at the Central Bank. At the time, the systems that made up the SPB moved amounts roughly equivalent to Brazil’s GDP every three to four days. The security team handled various aspects of the system, starting with the network connecting the banks to the Central Bank, known as the National Financial System Network (RSFN, from the Portuguese name), all the way to some system-security aspects, such as the definition of the security mechanisms for the protocol used in communication between the banks and the Central Bank.

When I arrived, the SPB had already been running for a few years, and all its protocols had been defined and deployed to production. Over time, some aspects of those protocols started to get a bit dated, especially the cryptographic algorithms used. My boss noticed my interest and knowledge in cryptography, and we began talking about possible improvements to the SPB protocols. At the time, DES, MD5, and RSA were still being used as the base algorithms for encrypting and signing messages, and some of those choices were starting to be considered insecure. The idea that came up wasn’t to develop a completely different protocol, but simply to evolve the existing one, replacing the cryptographic primitives with more modern versions.

One of the basic principles of cryptographic security is that keys need to be long enough to make so-called brute-force attacks infeasible. Such attacks are nothing more than trying all possible keys one by one. If the keys are small, the number of possible values is exponentially smaller, making this kind of attack feasible. With the increase in computing capacity, each year it becomes possible to try a larger number of keys. So, from time to time, it’s necessary to update cryptographic systems to use larger keys. This may mean replacing an algorithm or simply increasing the size of the keys used while keeping the same algorithm.

The SPB used RSA and DES to encrypt messages and MD5 to generate the hashes used in signatures, in a model very close to the one used by PGP that I already described in an earlier chapter. DES was already pretty old and no longer considered very secure, especially because it uses 56-bit keys. 1024-bit RSA was still considered acceptable at the time and was the largest size supported by most available devices. MD5, on the other hand, was a more serious problem: many papers had been published about the possibility of breaking it in certain situations and about the fact that its complete downfall seemed imminent. So our proposal was to move from DES to 3DES (or triple DES) and replace MD5 with SHA-1.

One of the problems with changing SPB protocols is that it affects every bank in Brazil, big or small. At the beginning of the process, we thought big banks would be the most resistant, since they used mainframes with built-in cryptographic hardware. Cryptographic hardware is basically a specialized processor that runs only the operations needed for cryptographic algorithms. Because it is highly specialized for speed, it is not compatible with all algorithms and significantly limits the algorithms that can be used in environments that depend on this kind of coprocessor. To avoid any future problems, we consulted IBM to find out which algorithms were supported by their mainframes and also confirmed the available key sizes. That way, we were sure the proposals would be compatible with the hardware in the big banks.

After several internal discussions, the time came to present the proposal to the SPB working group that handled security-related matters. We presented not only the proposed changes but also an implementation timeline. The deadline was pretty generous, precisely to avoid complaints about lack of time to adapt. To my surprise, one of the first approvals came from one of Brazil’s largest private banks. Their representative said something like “it was about time!” That support was fundamental for the proposal to be fully accepted, although some representatives of companies that developed software for small banks complained that the deadline was “tight.” In the end, the proposal was approved and the change calendar was defined, though the final deadline was set for the following year.

The Bacen development teams didn’t have much trouble changing the software, since the libraries they used could handle the new algorithms. One of the problems we encountered was the system that validated the banks’ digital certificates. When a bank joined the system or needed to replace its certificate, that certificate had to be submitted to the Central Bank, which validated and published the certificate on a list of all currently valid certificates. That list was generated by a program written in C that ran on a Linux partition of a mainframe. The developer who had written that code had already left the bank, and no one had ever done maintenance on it. It fell to me to update that system. In the end, I rewrote everything in Java, which was the language officially used by the Central Bank at the time. It took a bit more work, but it would make future maintenance easier.

An interesting development occurred when the new code began to check the validity start date of the certificates. Every digital certificate has a start date and an expiration date, but the previous code only checked the end date. When we started also checking the start date, we discovered a curious case: some certificates were issued with validity starting only at midnight. Don’t ask me why. So it was common for a certificate to be issued mid-morning, but only become valid at the start of the next day. In some cases, the bank submitted that certificate to the Central Bank immediately after issuing it. That meant the certificate was not yet valid at the time of submission. The new code detected that situation and rejected the certificate, which left the technicians on the other side quite worried and unable to understand what the problem was. We had some calls in which we had to explain that they just needed to wait for the certificate to become valid before submitting it. In practice, they just had to wait until the next day and everything would work normally.

Some time later, I saw a call for federal government agencies to participate in several working groups related to information security. By that point, I was already taking part in a community called RENASIC (National Network for Information and Communications Security), which brought together participants from various public administration agencies, universities, and companies to discuss security topics. That network was coordinated by the Institutional Security Bureau of the Presidency of the Republic, which is the same agency that issued the call for participation. One of the topics included was cryptography. I talked to my boss and he authorized me to engage with the working groups. Our main interest was to make sure any regulation coming “from above” would not affect the protocols used in the SPB.

So, after the necessary bureaucracy, I was formally appointed to take part in the working group that was going to write a standard on the use of cryptography by all entities in the federal administration. The group was coordinated by CEPESC, which is the agency that concentrates the federal government’s cryptography specialists. Off I went to the first meeting, held at the headquarters of ABIN (the Brazilian Intelligence Agency). I remember there was a convoluted protocol to enter the building and that cell phones, for instance, weren’t allowed. The group’s coordinator was a CEPESC researcher who was doing a PhD in cryptography at UnB, and that’s how I discovered there was such a research group at that university.

At the start of the work, the coordinator took almost complete control of the discussions and had a strong tendency to disregard opinions or suggestions from others. That bothered me a bit, but I kept trying to contribute. He also had the habit of justifying that his ideas were better simply because he was finishing a thesis in the area. I don’t much like showing up “crowing” that I’m a graduate of this or that, or that I studied at university A or B, but in this case I ended up losing my patience a bit. I sent an email to the coordinator explaining my suggestions on how the work should be structured and added a section detailing my background in cryptography.

Suddenly, everything changed. Not only did the coordinator know my advisor’s name well, but he also knew the reputation of the Unicamp cryptography group, which was one of the most prominent in Brazil at that time. Where I expected conflict, I found openness. That’s how I discovered that some people work mostly on the basis of pedigree: if you studied or worked in certain well-known places or with certain well-known people, that weighs more than the technical arguments presented.

With that, we were able to move forward and deliver a proposed cryptography standard for the federal government. The process took a few years, but a simplified version of the text we produced was finally published and continues to be referenced by Brazilian federal agencies. From the Central Bank’s side, everything worked out because the standard focused on “classified information,” which usually means state secrets. The Central Bank deals primarily with financial information, which requires confidentiality, but isn’t considered classified information. That outcome left my boss happy, since the SPB protocols wouldn’t be affected.

As I began to hear more about the people in Brasília who worked with or dealt with cryptography, it ended up creating an opportunity for me to get close to that community again. But that’s a story for another chapter.