Certificate Authentication is Vulnerable

When cracking passwords becomes as difficult as cracking keys, then passwords will be secure.

When it comes to security implementations, there is a big difference between the theoretical and the practical. In the theoretical world all algorithms work flawlessly, there are no infrastructure vulnerabilities, and security protects against every attack. However, in the real world new variables frequently raise their ugly head from places never anticipated. The realization that Certificate Authorities (CA), certificates, and private keys can be compromised rocks the basic foundation of information security. Once the key is compromised, like a password, cybersecurity goes out the window. That’s because IT cannot differentiate between a hacker and a legitimate employee if the correct credentials are presented.

No matter how much a security technology promises, it is only as secure as the weakest link in the overall system. Hackers discover software vulnerabilities developers never thought existed; products are sometimes used in ways never imagined; and, companies frequently fail to discover a disgruntled employee before they steal important data. And the more complex a system is the more attack points there are to exploit.

For example, the firewall requires strong logon passwords, but employees often write their passwords on sticky notes that are placed on their monitors. IT requires complex server passwords, but never locks the door to the server room. Or an employee finds a memory stick in the parking lot and plugs it into their work computer hoping to find its rightful owner, not knowing that it was placed there by a hacker to infect the company’s network. If I had to suggest the number one cause of most data breaches it would be “The Human Element.”

In my first report in the series Passwords are Secure – “When is a Password like a Cypher Key?” I discussed that passwords, biometric templates, and keys are virtually the same when it comes to the computer: a series of 0’s and 1’s. In my second report, “The Similarity of Passwords to Symmetric Keys,” I discussed some of the pros and cons of symmetric encryptions, and stated that if many of the same methods used to protect symmetric keys were used to protect passwords, passwords would be extremely secure. In this third report, I will analyze another very important cryptographic element – asymmetric keys and their use in certificate-based authentication (i.e. PKI).

The realization that Certificate Authorities (CA), certificates and private keys can be compromised rocks the basic foundation of information security.

Methods of Authentication

As cybersecurity gets more complex, the number of vulnerabilities also grows. Certificate based authentication is one of the most complex and convoluted authentication system used today. While theoretically, it offers many advantages over other authentication methodologies, a poor implantation wipes out all those advantages. When it comes to cyber authentication there are three basic technologies:

• User Names and Passwords
• One Time Passwords
• Certificates

Note: I did not include single sign on (SSO) because this is an access management solution and not an authentication solution.

Frequently, passwords are defined as a series of characters that a user has to generate, know and type. OTP requires a person to know, for a brief period of time, and type in a computer generated series of characters. Certificates are a series of characters that a computer generates where the user doesn’t know or type them. Therefore, the best way to improve password security is by following the certificate method where the user never has to generate, remember, type or know any passwords.

Public/Private Key Practices

Public Key Infrastructure (PKI) is the most widely used of all the certificate based security algorithms. PKI incorporates the best of many different technologies and third-party relationships to make everything work securely – at least theoretically. A few components that an IT manager needs to consider before implementation are: certificate and registration authorities, smartcards, secure encryption server modules, symmetric key algorithms, asymmetric key algorithms, hash functions, messages and key exchanges, and the list goes on. PKI has the unique advantages of offering authentication, authorization, data integrity, and non-repudiation, but at what price and at what level of assurances?

PKI is the correct solution for some business and government environments, but it is not appropriate for others. When overhead, time and cost are also considered, PKI is impractical for most small to medium size businesses. Plus, because only a small fraction of computer applications and websites even recognize certificates, it makes their usefulness for cyber access authentication limited.

Asymmetric Cyphers

Asymmetric cyphers like RSA, Elliptic Curve Cryptography, ElGamal, etc. create unique public/private key pairs that are mathematically linked together. The linking allows for one key (say the private) to encrypt a message so that only its corresponding other key (public in this example) can decrypt the message. Different security concerns dictate which key is appropriate for the encrypting and which for the decrypting.

The advantage of an asymmetric cypher is key management. As long as the private key remains secure, any communications system can use the same public/private keys to reduce key management headaches, like those found in symmetric cyphers. Theoretically, a single key pair can be assigned to every individual and machine and it can last for years without having to change it. Through this key pairing, an individual would have access to websites, applications, servers, computers, etc. anywhere in the world, and the authorities would know that that single individual was the only one allowed access. As you will see, what goes on in the real world has little resemblance to the theoretical.

The security concerns regarding any asymmetric cypher are that the private key is secure from:

• Brute-force attack
• Discovery from the public key
• Duplication from a similar public key
• Theft

That is why so many different technologies and products focus on private key security. The safeguarding of private keys should be no different than the safeguarding of symmetric keys or passwords. Secure authentication, no matter the means, is only as secure as the protection of its secrets.

Key Generation

The complex mathematics that goes into generating a key pair is beyond the scope of this document. What is important is understanding the amount of computation overhead required to generate some keys. For example, RSA cryptograph uses prime numbers and logarithms. As the number sequence increases, the difficulty of finding new prime numbers also increases. While there might not be a finite number of prime values, the size of a prime number may be too large for effective use. The second issue with RSA is the intense mathematical processing required for logarithmic and anti-logarithmic calculations. This is often compounded when many requests come in at the same time which overloads a normal server. To solve this problem, advance mathematic co-processors or specialized mathematical server blades are required.

Another popular asymmetric algorithm is Elliptic Curve Cryptography (ECC). The premise is, given a random curve with an infinite number of points and a known point on that curve, it’s very difficult to find its correct reflection point. Granted I am over simplifying the explanation here, but the beauty of ECC is that it requires no prime numbers and uses basic algebraic calculations that any simple computer processor can do. ECC generates keys faster and stronger, with less computational overhead than RSA. Reportedly, a 256-bit ECC key is comparable to a 3072-bit RSA key in strength and magnitude, as well as being faster to calculate.

The purpose of this series is to demonstrate the security of passwords and how they are not that different from cypher keys. There is a similar pairing in password-based authentication: User Name and Password. When logging into an account, if the user name and password do not correspond, then access is denied. The issue with User Name and Password authentication is that they are not mathematically tied together. In other words, one is not generated from the other. But why not? Remember, a password is something that a person or thing knows. There is no requirement that it has to be manually typed in by a human.

Most user names are an individual’s email address. Something most everyone knows or can find, similar to a public key. The password is the secret or the one thing only the correct user knows – essentially a private key. If a password was generated by the computer using an algorithm similar to ECC and the user’s email was the known entity, then the password would be identical to a private key. Therefore, a public/private key pair could be a User Name and Password. Just something to think about.

Furthermore, if the computer-generated password is stored in a smartcard or HSM so the user never has to generate, remember, type or know it, how is that any different than an asymmetric private key? Remember my comment in my first part of this series: a password, secret key, biometric template and private key all look alike to a computer because they are just a long series of zero’s and one’s.

Finally, if this new password generating algorithm is such that the password cannot be discovered from the user name, then I dare say that a password and a private key are identical.

Key Length

One of the major concerns in determining key length is the ability to discover the private key in a reasonable amount of time by means of a brute force attack. The limited number of available prime numbers, high computational speeds of computers, and increasing number of certificate requests also contribute to the ever increasing key length. That’s why the accepted length of an RSA generated private key today is now 2048-bits (or 256 characters). It may not be that far off when the acceptable length becomes 4096-bits. Key length also affects the time to generate a digital signature, more memory storage on a smartcard, and higher costs for the smartcard.

Passwords do not need to be as large as an RSA key. A 256-character password using all the available 128 ASCII characters would generate approximately 2.8×10^539 (128^256) combinations. In other words, a really, really big number. To add a reference point as to the size, there are approximately 3×10^11 stars in the Milky Way. With such a large number of possibilities and no need to rely on prime numbers or advanced math co-processors, a password can be much smaller than a private key. A smaller password also allows a much less expensive smartcard because there is less storage capacity required.

Key Storage

The safest private keys are those that are generated and stored in secure hardware like Hardware Security Modules (HSM) or smartcards. In these cases, the private key never leaves the device. Another way to look at this is that the user doesn’t know the private key.

A secure password manager can use similar technologies to generate and store passwords. By taking the human element out of the security equation, security is able to remove its biggest vulnerability.

If the private key inside an HSM cannot be exported or hacked then the only way to steal the keys is to physically steal the HSM unit. This type of attack is less likely to go unnoticed. Plus, some HSM units have an auto-destruct mechanism. If power is removed or the unit tampered with, all the unit’s memory is wiped out.

Smartcards are easier to lose or get stolen. That is why most require additional authentications like a PIN or biometric before access is granted. For additional security in some smartcards a fuse inside the chip is blown to permanently disable the smartcard after too many wrong entries. Smartcards also include other security features that makes probing for data far more expensive than the value of the information. Hackers prefer to take the easiest and least expensive path.

When passwords are stored in similar devices, they are just as secure as a private key. Security is not defined by the methodology but the secure management of the methodology. When passwords are just as difficult to crack as a private key, then they are just as secure.

Digital Certificate

A digital certificate is the combination of different cryptographic functions (symmetric and asymmetric ciphers, hashing, digital signature, etc.) with infrastructure components (Registration and Certificate Authorities, encryption acceleration hardware, key management, HSM, smartcards, etc.) to generate an electronic passport for individuals, computers and organizations to securely exchange information over networks. In the theoretical world, the creation and management of digital certificates capitalizes upon the best of each cypher and component while negating their weaknesses. That is why certificate authentication (i.e. PKI) offers authentication, authorization, data integrity and non-repudiation.

While we have already said that you can’t directly compare passwords to certificates, there are vulnerabilities that are similar to those facing passwords. A fraudulent certificate breaks the chain of trust. A compromised key breaks the chain of trust. And, an attack within the infrastructure breaks the chain of trust. Like passwords, correct identification of the certificate user is paramount.

My Conclusion: I have highlighted two important components that make up certificate based authentication – the asymmetric cypher’s public/private key pair, and the digital certificate’s proof of ownership of those keys. The security of an asymmetric cipher is dependent upon protecting the private key. The protection of the digital certificate is based on the security of the certificate infrastructure.

The complexity of certificate authentication technology, infrastructure and maintenance has to be well understood before implementation. Let’s now discuss some of the known vulnerabilities and how poor security management will compromise any cyber security system no matter how secure it looks theoretically.

PKI – A lock is only as secure as its key

The following high level diagram demonstrates the complex architecture of certificate based systems. It does not drill down into the architecture of each component, but I think it is fair to say that each component also has their own unique vulnerabilities, as well as the components within the components. I bring this up because hackers will target any vulnerability within the chain of trust, no matter how small or insignificant it may first seem. Hackers build off and leverage one successful penetration to then discover the next to create a chain of events that will eventually the collapse a network. The hacker’s chain of events are as complex, if not more complex, than the actual certificate network.

Can you trust the Certificate Authority?

Let’s look at the process of obtaining a digital certification. The certificate begins at the Registration Authority (RA) and Certificate Authority (CA). For two companies or agencies to securely communicate and trust each other, they first have to trust the same certificate issuing company. While there can be different hierarchal levels and location of CA’s, eventually a single entity, or trusted third-party, validates all the lower level CA’s.

The “chain of trust” through a convoluted network of certificate authorities increases the odds of hackers discovering a vulnerability. It only takes one successful exploitation to break the trust chain. I will keep the following example simple.

An employee will submit a request from their IT administrator for a digital certificate. The IT administrator contacts their familiar RA and submits all the required documentation (like the employee’s driver’s license, birth certificate and/or passport) to verify the identity of the employee. After reviewing and approving all the documents, the RA submits a request for certificate from a CA. Once reviewed, the CA takes the personal information supplied by the RA and issues a certificate and frequently the public/private key pair as well. This process seems simple and should be error free, but as the following Case in Point highlights, security is only as good as the infrastructure.

Case in Point:
On July 19, 2011 DigiNotar, a Dutch digital certificate authority (CA), confirmed it was breached and several dozen fraudulent digital certificates were issued. Earlier this year, Comodo Inc. warned that they too had issued fraudulent certificates. It is surmised that the hacker impersonated a Registration Authority to request the certificates. These fraudulent certificates affected the operating systems, applications and browsers of such industry giants as Google, Microsoft, Yahoo, Mozilla, and others.

How the attacker actually fooled the CA is still under investigation, but one possible explanation starts with the use of an individual’s stolen personal information from identity theft. The hacker submits to the CA the stolen personal information and requests a certificate. When the CA checks the background all the information looks legitimate so a certificate is issued.

The theft of personal information is more than stealing credit card numbers. On the internet, personal information, also called credentials, is used to create a trail of seemingly legitimate information. This trail creates “breeder documents” to start more advanced hacks into more important networks. Next, the theft of unsecure passwords also allows hackers to change an individual’s profile information and re-route notices without the user’s knowledge. The reason I bring these two points up is for you to understand the degree to which hackers go to break into networks.

Without too much technical jargon, fake certificates allow for man-in-the-middle attacks to occur. The attacker can intercept, read and alter correspondences. Software patches and updates might be intercepted and then infected with malware before being passed on. Web browsers can inject any code into any network in a trusted manner, all without the user’s knowledge. Don’t we always trust that security patch or software update from a trusted vendor?

To mitigate the damage, DigiNotar and other companies claim that the fake certificates have been revoked, but revocation isn’t a sure thing. The rogue certificates could be used for one-off, targeted attacks, and therefore would be tough to pinpoint. Even with these notices, companies are dependent on browser updates for full protection. If a fraudulent certificate and malware is inserted it’s not too far of a stretch to ask if the malware blocked the actual revocation cleanup? It’s also unsure if every rogue certificate was discovered.

CA issued certificates are at the heart of Secure Socket Layer (SSL) and PKI security. These certificates create a chain of trust back to the certificate authority’s root certificate. The security and implementation of certificates is only as good as the root’s security. If the root is compromised, all of the issued certificates are in turn also compromised.

Case in Point:
One of the components that allowed Stuxnet to infiltrate the Iranian nuclear enrichment system was the use of what Windows thought was a valid certificate. This certificate weakness example demonstrates an administrative problem and not whether certificate based systems offer viable authentication. Which is not that dissimilar from improperly administering password security.

The certificate process is only as viable as the verification process of the individual and as secure as the CA operation. In the past, many CA’s just took a person’s email address and credit card number to identify the individual. A good RA/CA requires driver license, birth certificate, passport and additional trusted third-party verification. If a company wants to accept a certificate, they first must trust the certificate authority before they can trust an individual. Always research the CA and fully understand their verification process before accepting them.

My Conclusion: It’s not the process that is flawed, but rather the management of the infrastructure. Companies must do their security due diligence before accepting certificates from any CA.

Where to keep your keys

After the verification is complete and a certificate is created the next phase is the public/private key generation and secure private key storage. It is where and how a private key is stored that determines the security and trust of the entire certificate system.

Debbie Deutsch and Beth Cohen in their article, “Public Key Infrastructure: Invisibly Protecting Your Digital Assets,” summed up the security of the private key as follows:

PKI operation depends on protecting [the] private keys. Sometimes keys are generated by a computer and stored in memory and on disk. This is acceptable for everyday security. However, it is possible for someone to break into the computer — perhaps in person, perhaps over a network — and retrieve the private key. As a result, very sensitive information or resources need greater protection. Specialized hardware peripheral devices can provide stronger security by generating keys, signing, and decrypting information, so the private key never leaves the device. Protecting the key then becomes a matter of protecting the device from unauthorized use. It may be carried by its owner, locked up, password protected, etc.

Case in Point
Cloudflare, a popular off-site storage hosting service, launched “The Heartbleed Challenge.” They tasked the hacking community if the “Heartbleed” virus could steal the private Secure Socket Layer (SSL) keys off their nginx servers running the OpenSSL framework. The results of the challenge surprised even Cloudflare.

Nine hours later, software engineer Fedor Indutny and Ilkka Mattila at NCSC-FI had obtained the server’s private keys. Cloudflare announced that it is possible to expose the SSL private encryption keys. Both Indutny and Mattila sent numerous pings (2.5 million and 100,000 respectively) requesting the private key. The next day two other hackers were able to get in. It seems that when a server reboots there is a period of time when these keys are vulnerable and Cloudflare rebooted the server about six hours into the challenge.

The web implications of retrieving an SSL private key is significant. In cybersecurity, anyone possessing a compromised SSL private key can use it to host an impostor site that is virtually impossible to detect. The same https prefix and padlock icon accompanying the site’s authentic server would still appear, giving the visitor a false sense of security.

The challenge showed that there is an SSL private key vulnerability, even when a specially prepared server was configured for the test and monitored by IT administrators aware that their servers were going to be attacked. If hackers were able to penetrate a closely monitored server, how does a company with limited IT resources focused on daily network operations and re-setting forgotten passwords expect to secure their keys?

The recommended fix is to revoke and replace the old certificates as soon as possible because the compromised private keys can continue to be used to access user data. This is a good suggestion but does not take into account the time and cost to a business to do this. Changing keys is not as simple as changing passwords.

“If every site revoked its certificates, it would impose a significant burden and performance penalty on the Internet,” wrote CloudFlare in a Friday blog post. “At CloudFlare the scale of the reissuance and revocation process could break the CA [Certificate Authority] infrastructure.”

A new certificate means a new key pair. Information that was encrypted with an old key cannot be decrypted by the new key. This forces companies to keep both keys, which in turn lengthens their vulnerability. Also the first recommendation that everyone change their passwords would be useless if the company did not first change their certificates. The hackers would see the changes.

Besides the importance of protecting the private key, Ms. Deutsch and Ms. Cohen have shown there is a PKI hierarchy based upon the sensitivity of the information. Choosing between software based private keys versus hardware private keys is determined by the sensitivity of the data. This is my argument with secure password manager. It’s not that passwords/PKI are competitive but rather complementary based upon the threat/risk assessment. For example, do the employees on the loading docks need an expensive hardware-based PKI solution to enter shipping information? Or would a secure password manager sufficiently manage the risks at a fraction of the cost?

My Conclusion: The complexity of computer networks for even something as simple as powering up a server introduces either human or machine errors. These errors are not an indictment of the effectiveness or value of authentication methodologies like passwords or PKI, but rather a reminder about how clever hackers can be and that security can never be taken for granted.

How much is security worth?

A more secure and usually more costly private key protection method is the Hardware Security Module (HSM) or Trusted Platform Module (TPM). These physical security devices are installed within a locked server room that’s protected from unauthorized access. The level of information these devices are protecting will determine the amount and costs of the physical security. An HSM with Common Criteria EAL 4+/5+/6+ levels of certifications on hardware and firmware lets an IT administrator know the level of security they are purchasing.

In researching the security threats on HSMs, I found 2006 and 2009 articles about PIN vulnerabilities attributed to hacking an HSM. While the following case in point may be old it does highlight why HSM devices are advertised as “attack resistant” and not “attack proof” because the flaw can lie outside the technology.

Case in Point
When a customer pays for a purchase with an ATM or Debit card, they have to type in a PIN. PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple HSMs across multiple bank networks before it reaches the customer’s bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey. Depending on who and how well these HSMs are configured and managed, determines how secure the entire process is. The most common method criminals are using to get the PINs is to tricks the application programming interface (or API) of the hardware security module (HSM) into providing the encryption key. This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device.

Another vulnerability occurs when the HSM communicates with the issuing bank’s mainframe to process the transaction. Here the PIN and the customer’s 16-digit account number are briefly held unencrypted in the mainframe’s system memory waiting for authorization of the transaction. It is here that hackers use “scraper” malware to capture the data. It is estimated that as much as a third of all PIN theft cases involve scrapers.

In a Cambridge University paper published in 2003, a researcher presented how attacks, with the help of an insider, would yield PINs from an issuer bank’s system. Then in 2006, two Israeli computer security researchers devised a much more sophisticated attack that also required the assistance of an insider. With access to the HSM and the API, knowledge of the HSM configuration, and knowledge of the network’s architecture, it is possible for a hacker to acquire bank PINs.

Brian Phelps, director of program services for Thales, emphasizes that the problem is how systems are configured and managed. “It’s a very difficult challenge to protect against the lazy administrator,” Mr. Phelps said “Out of the box, the HSMs come configured in a very secure fashion if customers just deploy them as is. But for many operational reasons, customers choose to alter those default security configurations — supporting legacy applications may be one example — which creates the vulnerabilities.”

As the vulnerabilities to HSM devices rises, the PCI Security Standards Council has been at the forefront in testing, issuing industry standards, and enforcing physical and logical requirements for the protection of sensitive data. While PINs many never be 100% secure, organizations like the PCI Security Standards Council offer the industry a high level of assurances and companies should only purchase products that have gone through the PCI Council certification.

My Conclusion: IT administrators and engineers can make the technology safe, but lax OS security, a bad web request front end, or a rouge admin can thwart even the best controls.

Don’t change the key, change the lock

Smartcards are also used to generate and store private keys. Because of their mobility and accessible only when the user requires it, they offer a good alternative to a server based HSM. The processing power and security mechanisms deployed keeps the private key in a very controlled container. Some smartcards can even generate their own key pair internally, thus never allowing the private key out of its secure container. Or so it is thought. But even with the advances in smartcard technologies, hackers still find system vulnerabilities in obscure areas.

Case in Point
When the Sykipot, a zero-day Trojan, is combined with a keylogger malware, thieves were able to steal a smartcard’s PIN and read the stored certificate. While the smartcard was never actually cracked, Sykipot capitalizes on a weakness found in the computer’s operation system and applications that allowed the hacker to take control of the smartcard as if they were the owner

The U.S. Department of Defense (DoD) uses one of the most advanced and expensive PC/SC x.509 deployed multi-factor smartcard infrastructures to date. In 2011 the DoD claimed that Chinese hackers infected their computers with the Sykipot virus and stole the PIN of many government employee’s smartcards. With the PIN these hackers used the stored certificates to access files and networks. The DoD has yet to publicly disclose what information was accessed nor the sensitivity of the data.

In an attack like this, the user is unaware of the compromise. While this is not a direct attack on the smartcard, it is an attack on the infrastructure. “One way is to add another layer of authentication, such as a one-time password,” says Jaime Blasco Director AlienVault Labs.

Am I the only one that sees the irony here? He is saying that the best way to protect against the Sykipot attack of a certificate is with a PASSWORD! This is at the time when White House cybersecurity coordinator Michael Daniel stated at the 2014 Identity Ecosystem Steering Group’s conference, “I often say that one of my key goals in my job that I would really love to be able to do is to kill the password dead.”

My Conclusion: Again, these attacks had nothing to do with theoretical aspects of PKI but rather hackers exploiting flaws in operating systems, operations and peripheral components that lead to the certificate. Passwords and private keys are only as secure as the infrastructure protecting them, and insiders are a major threat to protecting sensitive information.

Surrender your Private Keys by order of a Judge.

There is a key recovery recommendation to address lost or forgotten private keys, or when an employee leaves the company and their encrypted emails and documents need to be recovered. It is known as “Key Escrowing.”

Key escrowing is a proactive means by which third parties like businesses, third-party entities or government agencies can access an individual’s encryption keys (secret or private keys) to decrypt encrypted data or private communications. Supposedly, only under carefully controlled circumstances like a court order. However, with some of the recent reports of government spying on its citizens, hacks into major corporations, and nation-sanctioned cyber espionage, one has to be concerned if legal safeguards and protections are strong enough to protect the private keys.

Remember back in 1993 and the introduction of the “clipper chip” where manufacturers would be required to place this chip in phones, computers and any other type of communications device? The controversy was about a backdoor cryptographic key stored in an escrow account. After a government agency “established their authority” to monitor a suspects communication, then the key would be surrendered to that government agency. However, many advocacy groups who monitor unlawful surveillance were in an uproar fearing citizens subjected to increased and possibly illegal government surveillance. By 1996, the Clipper chip was no longer relevant mainly due to widespread encryption tools like Pretty Good Privacy (PGP) and the chip’s poor security protocols. However, the U.S. government continues to press for key escrow.

Following the Snowden disclosures, Apple and Google announced in Sept 2014 that their new smartphones would include unbreakable encryption features to protect stored data. This new direction prompted strong reactions from different law enforcement authorities. Attorney General Eric H. Holder Jr. said this could imperil investigations in kidnapping and other cases; FBI Director James B. Comey asked, why would companies “market something expressly to allow people to place themselves beyond the law.” Suggestions are being made for another backdoor that requires a special key to unlock the data only after a warrant has been issued.

Key escrow systems are risky to the overall security of PKI since a third party also has the most important component in certificate authentication: the private key. Now questions arise on how secure is the escrow system from a data breach. These keys are the modern day holy grail. The more people and companies involved in a security implementation, the more likely there will be a breach.

Case in Point
I recently came across a case in July of 2013 where the United States Department of Justice (DOJ) demanded and subpoenaed a privately held company, Lavabit LLC, to surrender the private encryption keys of their 410,000 customers. What is particularly disconcerting about the Lavabit case is that the DOJ believes that they can take away the privacy of innocent civilians in order to investigate one nefarious suspect.

Putting the privacy rights argument aside, there is a vulnerability with the security of private keys. The logic follows that a subpoena assumes that an IT administrator has the ability to gain access to the private keys. Access confirms that the private keys are vulnerable. Since the keys are vulnerable they will be targeted by hackers, organized crime, nation-states, hacktivists, etc. If they are targeted, they are susceptible to compromise. If compromised, the security of that PKI installation is destroyed. If the PKI installation is destroyed, untold damages and cost incurred with lost R&D, manipulation of data, technology replacement costs, etc. that may be too high for a company to bare. High recovery and legal costs leads to bankruptcy and employee layoffs.

My Conclusion: If secrets are made accessible they can be always vulnerable to theft. While there are very good reasons why the “good guys” feel they need to request and recover private keys, those same abilities can be exploited.

Conclusion

This report does not compare passwords to certificates, but rather the importance of protecting both passwords and private keys. The suggestion that eliminating passwords as the solution to secure networks is wrong. Cyber security requires multiple barriers and means of authentication. While the value of x.509 certificates is that they offer additional user identification and protections from Denial-of-Service (DNS) attacks, passwords still offer the best solution for fast changes, low cost of ownership, and compatibly with 94% of all computers, websites and applications. Passwords required the same security features that safeguards private keys.

No cyber security or cyber authentication method is 100% secure no matter how good it sounds theoretically. It is during the actual implementation that the Human Element can undermine even the best corporate or government IT administrator’s intentions. The more complex a system becomes, the greater the likelihood of a security breach. Cyber security requires layering of protections, changing of keys/passwords, and monitoring for irregularities.

Here are a few other conclusions I want you to draw from this report:

• Certificate authentication offers advantages that other authentication systems don’t.
• Certificate authentication has a hefty price tag and implementation period.
• The security of certificate authentication relies on the security of the private key
• The security of the private key relies on the security of the implementation
• The Human Element, either accidently or on purpose, can jeopardize the best security plans.
• When password security is constructed with similar considerations as key security, then passwords will be just as safe as any cypher key.