In May, Edward Snowden — once a contractor for the U.S. National Security Agency — leaked information related to top-secret mass surveillance programs conducted by the United States and the United Kingdom to the U.K. newspaper The Guardian. The report states that through a program called PRISM, the NSA has been able to obtain direct access to the systems of major U.S. Internet and technology companies such as Apple (NASDAQ:AAPL), Google (NASDAQ:GOOG), Yahoo (NASDAQ:YHOO), Microsoft (NASDAQ:MSFT), and others.
The clandestine ability of the government to monitor digital communications and collect information was born out of the Foreign Intelligence Surveillance Act of 1978, “An Act to authorize electronic surveillance to obtain foreign intelligence information.” PRISM itself is more directly a product of the FISA Amendments Act of 2008. Given the benefit of the doubt, the measures seem to be the product of a desire to enhance the government’s ability to identify and thwart threats to national security. But as these things go, what may have started with good intentions was perverted over time.
Through the PRISM program, the government’s ability to monitor and collect information was expanded beyond what most Americans deem reasonable. The content the NSA was able to collect — or at least observe — includes search history, emails, online conversations, and file transfers.
There are two big issues here that have become fodder for the international debate now raging over data protection and privacy. One is the issue of how and why government officials gained the legal authority to implement mass surveillance programs; two, how they actually went about gaining access to the systems of major U.S. Internet and technology companies. Once officials are given the green light and flip the switch on a surveillance program, how do they actually go about gaining access to all the encrypted data that people once thought secure?
Part of the answer may be that they simply rooted around and found the rough equivalent of discarded and forgotten spare keys.
Over the past several decades the issue of digital data protection has moved from the periphery of the corporate world right to its heart. Information is money — sometimes literally, like in the form of credit card information; sometimes figuratively, like in the form of patents — and hackers have long had incentives to try to break into the systems of businesses large and small. Firms have naturally adopted various security protocols to protect their information.
Different systems use different security protocols, but one of the most popular is Secure Shell, or SSH. SSH was developed in 1995 by Tatu Ylonen, then a researcher at the Helsinki University of Technology and a mad genius in his own right, and that same year, he founded SSH Communications Security. Fast forward nearly two decades and a version of SSH comes standard on every Linux, Unix, and Mac OS X machine, and it is also used on many mainframe operating environments.
Major corporations that use SSH include Exxon Mobil (NYSE:XOM), HSBC (NYSE:HBC), Capital One (NYSE:COF), Barclays (NYSE:BCS), and Staples (NASDAQ:SPLS). Even government agencies like NASA and the courts system use SSH to encrypt data. At the core of all of these corporations is a massive computer network that is critical for pretty much every operation performed by any actor within the company.
Entities within the network can generally be placed into one of two buckets: a person or a machine. With this comes two relevant types of interactions — when a person interacts with the the system, and when a machine interacts with another machine on the system (a machine here could perhaps be more accurately taken to mean any discrete process).
Within the system, the right to access certain functions, execute commands, and access data is largely controlled by keys. The way keys regulate permissions within SSH was described in a white paper published by IDC:
“SSH keys consist of a private and public key pair that is used to prove a user’s identity during the SSH authentication process. SSH supports a self-service model for key deployment. Anyone can produce a matching pair of SSH keys. The SSH key pair is not synonymous with a public key certificate. There is no information about the key that would be contained within a certificate (such as date created, originator, or owner). The public key is published on all remote systems that the holder (user, device, or automated process) of the matching private key is allowed to connect with. For example, a systems administrator will publish his or her public key to all servers within his or her scope of responsibility. Private keys are controlled by and should be accessible to only the key owner.
“When a user, a device, or an automated process attempts to connect, the private key is used to verify the relationship between the published public key and the private key. While authentication is based on the private key, the key itself is never transferred through the network during authentication. SSH private keys can be protected with a passphrase, but this type of protection is often not implemented or enforced for interactive SSH users (e.g., systems administrators) or for automated application-to-application processes.”
While this system can be used to create a highly secure environment, if it is not properly managed, a huge number of keys can slip through the cracks. With an enormous amount of interaction occurring within a system at any given time involving a large number of people, hundreds of thousands, if not millions, of keys need to be created.
The amount of communication that takes place between machines is increasing as well, and likely at a much faster rate than person-to-person or machine-to-machine communication. In fact, within some systems — say, the one at the heart of a financial institution — the majority of the communications that take place that could be considered sensitive (i.e., contains some sort of nonpublic data such as credit card information) takes place between machines.
That means it is largely automatic, part of the infrastructure or the ecosystem, and is curated only by systems administrators or other information technology professionals. As much as 80 percent of total activity within the network of a company with a foot in the payment card industry — such as Capital One, HSBC, or Barclays — may fall into this category.
At a glance, it is easy to under-appreciate the significance of this, but machine-to-machine interactions still require keys to gain permission to use the parts of the system they need access to. This adds to the total number of keys and agitates the problem of keeping track of them all.
As the person responsible for managing a system like this, you have a few priorities. First, you need to figure out how to find out how many keys already exist, what they have access to, and who has access to the them — we can call this discovery. Part of this process would be identifying which keys are in use and by whom, and which keys are not. Keys that are not in use are at best clutter and at worst a liability. So, second, you would need a way to remove “extra” keys that have fallen through the cracks.
Third, in order to ensure that the entire organization can continue to perform its day-to-day functions, you need to be able to create or assign existing keys to specific entities, such as a new employee or machine. We could call this deployment for new keys and rotation for existing keys. You would want to do this in a way that did not allow keys to fall through the cracks, so the last thing you need is a way to monitor the entire mechanism.
Without a system like this in place, companies run the risk of their security systems simply not being tight enough. Keys — and therefore access to information — can make it through the cracks. It’s important to point out that this issue is not necessarily a problem with SSH itself. It’s more precisely a problem with key management. The “steel envelope” that SSH provides to protect data is secure, but the keys that open that envelope can be difficult to keep track of.
Right now, the issue of key management may be most important in the payment processing field, affecting companies such as Capital One, HSBC, and Barclays. Regulators require the payment card industry to follow certain encryption standards — IDC estimates that as much as 80 percent of spending on identity and access management is driven by compliance requirements — but as it stands, the regulations on the books don’t address this issue of key management. They simply require that organizations with security requirements, such as those in the payment card industry, use the keys.
Fortunately, security auditors have stepped up to the plate and have adopted their own standards for measuring key management. IDC points out that “The majority of auditors have adopted Control Objectives for Information and related Technology (COBIT) as the framework for measuring SOX [the Sarbanes-Oxley Act] compliance. A specific component of COBIT is section DS 5.18, which covers cryptographic key management. Many regulatory bodies have become more aware of the importance of key management, and auditors are becoming more stringent in how they review key management processes.”
Unfortunately, the regulatory infrastructure in place doesn’t necessarily address the growing issue of key management for automated processes, or machine-to-machine communication. Most of the literature deals explicitly with human interaction with a system, not with the machines that interact with each other in the system. This, according to the team behind SSH, is a huge oversight.
Don’t Miss: Can Nokia Continue to Explode to the Upside?