Encryption-Key Security Thwarts Lurking Threats

If you and I need to communicate sensitive informatio

n to each other, we can encrypt it. Using one of the asymmetric public key methods, you can send me a message that only can be decrypted using my private key, and similarly, I can send you a reply that only you can decrypt with your private key. But, how does either of us know for sure that we are communicating with the other person and not an imposter?

Secure digital signatures are the answer. The Digital Signature Standard (DSS) is described in the federal information processing standards publication FIPS PUB 186-4. To generate a digital signature, I first apply a hash function to the message to obtain a so-called message digest—a much shorter version. Next, I would encrypt the message digest using my private key, producing the digital signature. Then, I send you the original message along with the digital signature.

You would first apply the public key to decrypt the digital signature, resulting in the message digest. If you get an identical result by applying the hash function to the original message, you will have verified that I sent it. The keys specified by FIPS PUB 186-4 are only to be used to generate digital signatures.¹

In one example, two entities—such as people, companies, organizations, countries—are negotiating a deal that they ultimately will agree to. The intermediate exchanges are encrypted using a separate public key scheme but not necessarily accompanied by a digital signature. The final messages that are being agreed to continue to be encrypted but also are accompanied by a digital signature developed using a separate private-public key pair.

Hashing

In contrast to encryption, which requires a corresponding decryption capability to be useful, hashing is designed to be one way only. When used as part of a security scheme, hashing compresses a message of any length into a unique fixed-length result. FIPS 180 specifies hash functions approved for generation of digital signatures.

Typically, the input data stream is divided into blocks that the hash function operates upon. In the case of the 1995 secure hash algorithm (SHA-1) standard, a succession of logical and mathematical operations works with 512-bit blocks and compresses the input data stream into a 160-bit output. In addition to exclusive and inclusive OR operations, the algorithm includes lookup-table substitution and logical bit shifting. A good hash function should exhibit sensitivity to all the input bits. In particular, it is desirable to produce an avalanche effect in which changing only one bit in the message results in a significantly different hash result.

Some weaknesses in SHA-1 have been found, and according to DigiCert, a Certificate Authority (CA) in Lehi, UT, “SHA-2 is a cryptographic hashing algorithm developed by the National Institute of Standards and Technology (NIST) to replace SHA-1. The NIST required that all federal agencies stop using SHA-1 certificates by Jan. 1, 2011, due to mathematical weaknesses in SHA-1.” The site also notes that secure sockets layer (SSL) certificates based on SHA-1 will begin to flag up warning messages starting near the end of 2014.

Specifically, starting in January 2015, Chrome will begin showing warnings for SHA-1 SSL certificates expiring during 2016. On Jan. 1, 2016, Microsoft will end trust of SHA-1 code signing certificates without time stamps. And, on Jan. 1, 2017, both Microsoft and Mozilla will end trust for all SHA-1 SSL certificates.²

Trust

Because of the computing power it requires, asymmetrical encryption isn’t suitable for encrypting all online shopping and banking information. However, it is used initially to set up an SSL (https) link or more recently a transport layer security (TLS) link between your browser and the server handling the website you want to access. This kind of interaction depends on the public key infrastructure.

According to DigiCert, five steps are completed before secure communications can take place:

Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
Server sends a copy of its SSL Certificate, including the server’s public key.
Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.
Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
Server and browser now encrypt all transmitted data with the session key.³

Rather than your browser trying to verify that a server and website really are what they appear to be, browsers are written to expect third-party server verification. This is where the CA comes in. To establish a secure SSL or TLS link, the server must create a certificate-signing request that is sent to a CA for verification. The CA reviews the information and issues a SSL or TLS certificate based on the public key. The server always retains the corresponding private key. The secure shell (SSH) network protocol provides a secure means of exchanging data with a remote computer.

Having a CA issue the symmetrical key means that now there are three entities that know the session key, not just your browser and the server you are communicating with. The recent NSA security leak made clear that the CA is a weak link in the system because proper operation of the session key entirely depends on the CA being trusted.

As described in a Venafi blog, “In one of the first and most powerful demonstrations of what attacking the trust established by keys and certificates can accomplish, the NSA is reported to have helped carry out the Stuxnet attacks on Iranian nuclear facilities. Using stolen digital certificates from unknowing Taiwanese companies, the architects of Stuxnet, identified by [Edward] Snowden to include the NSA, were able to launch the Stuxnet attacks with trusted status. These and other attacks provided Snowden a blueprint for attack: compromise the trust established by keys and digital certificates.”

The blog entry emphasized, “…just like the NSA, most enterprises have little to no awareness of the keys and certificates used to create trust—the authentication, integrity, and privacy on which almost all IT security is built. In fact, the Ponemon Institute surveyed 2,300 large organizations and reported that these organizations have, on average, more than 17,000 keys and certificates in their core infrastructure alone. This number doesn’t include mobile apps or the SSH keys that administrators use to access systems. Ponemon also reported that 51% of organizations don’t know where and how these keys and certificates are used. And industry experts agree, this number is grossly underreported.

“All these facts clearly applied to the NSA before Snowden breached the agency’s security and stole data,” the blog continued. “The NSA had no awareness of the keys and certificates in use, no ability to detect anomalies, and no ability to respond to an attack. Because of these deficiencies, General Alexander [General Keith Alexander, ex-NSA director] believes strongly that the NSA must use automated machine intelligence to improve its ability to detect and respond to threats”

The blog concluded with a simple warning from Forrester Consulting, “Advanced threat detection provides an important layer of protection but is not a substitute for securing keys and certificates that can provide an attacker trusted status that evades detection.”⁴

References