Part 1 of this two-part series on encryption introduced the basic premise of cryptology: converting plain text into cypher text. Only the intended recipient knows what encryption method was used and has the secret key to decrypt the message. Therefore, the intended party should be the only one able to decrypt or recover the plain text. This simple idea has been around for years.
Many available encryption algorithms use mathematical functions to make decryption difficult. The most widely known use a key system to enable the encrypting function. The keys add mathematical variables into the function in such a way that the decryption function cannot work without the key.
Symmetric or Asymmetric?
In general, encryption keys are used with one of two methods: symmetric and asymmetric. Symmetric methods use the same key to encrypt and decrypt the data. These are typically ephemeral keys, used for one connection session.
With asymmetric methods, encryption keys are typically static. That is, they can be reused for multiple sessions.1 As explained in part 1 of this series, asymmetric encryption uses one key to encrypt and a related key to decrypt. Called Public Key Infrastructure (PKI), this method entails sharing the encrypting key—the public key—with anyone who wants to send you encrypted information. You hold a mathematically related private key, which is the only key that can decrypt. If you need to return a message to the sender, you’ll in turn use that person’s public key.
Normally, an asymmetric transaction is used to set up a symmetric connection. Therefore, the key must be encrypted and have its own key—the key-encryption key. This may also be referred to as the key wrapper or container.2
Key Management
Key management is a nontrivial task. That may be one reason that cybersecurity professionals seem to pay more attention to perimeter security. Things like firewalls, cloud connection security, and controlled access to network-attached storage devices seem to get all their attention. However, keys are just as important as the data they are trying to keep private.
You can imagine how the number of keys can grow quickly, especially if you want to generate a set of new keys for every transmission. To address this challenge, the BITS Security Working Group has developed a list of concerns and activities that must be addressed to manage keys (see sidebar below).3 As the BITS list indicates, it is just as important a policy task to retire or revoke keys. It may also be advisable to use separate keys for each cryptographic function—including data encryption, key encryption, message authentication, and digital signatures—to prevent someone who gets access to one of the keys from compromising other cryptographic functions.3
Digital Certificates
One important thing to be absolutely sure of is that the senders of public keys are who they say they are. This is where digital certificates come into play.
A commonly used standard for PKI is X.509. It defines formats for public key certificates and provides a number of other details, such as certification revocation lists and extended attribute certificates. The X.509 standard stems from the X.500 directory service protocol, where the entire network is viewed in a hierarchical or tree format. It assumes a strict hierarchical structure in the certificate authorities (CA).4
CAs are the entities that issue the certificates for a fee. (There are a few that offer the service free, but with fee-based added functionality.) Approved CAs have the responsibility to authenticate the digital certificate with the requesting party. It’s supposed to impart a warm fuzzy feeling that the secure connection you’re about to engage is legitimate. The commonly employed Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), use X.509 certificates.
An organization’s trusted root certificate can be preloaded into your browser, thus preauthenticating secure connections. SSL or OpenSSL certificates from the bigger online vendors get the communication fast track, since you already have their CA’s root certificate. This is what you’re using when you see “HTTPS” instead of “HTTP” in your browser search bar. HTTPS is not an encryption protocol in itself, but is layered onto the upper layers of SSL and TLS. It simply calls on the security aspects that come with SSL and TLS.5
One of the functions of the certificate is to provide nonrepudiation. This is where senders cannot later deny that they sent a particular message.6
The certificate itself is about 1 KB in size and includes the certificate version, serial number, algorithm ID, issuer, time frame of validity (start date to end date), subject, subject public key information, and the public key algorithm used. All this is summed up by the certificate signature algorithm and certificate signature itself.
Check Your Digital Certificates
Using Internet Explorer 9, you can see the certificates and tell whether you have a certified secure connection. While using HTTPS, you’ll see a small gray padlock icon on the right side of the URL address bar. The padlock changes color when you hover over it. Click on it, then on the “view certificates” link. You will see the certificate and all the attributes mentioned above by then clicking the “details” tab that appears.
You may also notice that sometimes a site from a large online vendor will make the address bar turn green. Green is good. It means that you have a 100% certified and secure connection using the extended validation set of attributes (AKA EVSSL). You won’t get the green bar if the site uses HTTP and HTTPS to show content.
You also won’t get a green bar if the site doesn’t comply with the entire set of standard extended validation attributes. Be aware that most of the time, a blue bar means that you don’t have a 100% secure connection. (I say “most of the time” because color codes change between browsers, and even between different versions of the same browser.7)
Note that certification doesn’t prevent exploits like that involved with the now-famous Heartbleed episode. See the sidebar below for a technical overview of what happened—and is still happening to those that haven’t updated their OpenSSL process!
Conclusion
Encryption applies to data in motion, whether during processing or while being transmitted. Encryption also applies to data at rest or in storage. It can be applied at the user end point as well, which is what Kaiser Permanente is doing. Kaiser chief security officer and chief technology risk officer Jim Doggett explains the rationale:
“For healthcare companies we have a unique challenge because the nature of electronic health records is complex, with patient’s privacy and data security being the paramount concern. The focus is not just about protecting the data, but at looking at the impact to electronic health records and patient care. We are always looking at security from the consumer perspective, and this is when we can best meet the business need.”10
Healthcare cybersecurity professionals in general should reconsider the use of encryption. One way to get started with an encryption implementation plan is to locate the data you’re trying to protect, whether it’s in motion or at rest. That will make it easier to determine an encryption implementation plan that fits best in your organization.
Don’t reinvent the wheel. Take some time researching how other healthcare facilities have implemented encryption. In the end, it can be difficult to prevent the loss or theft of devices containing data. But if those data are encrypted, they are still protected.
Jeff Kabachinski is the director of technical development for Aramark Healthcare Technologies in Charlotte, NC. For more information, contact [email protected].
Sidebar: Enterprise Key Management Program Critical Success Factors
To ensure effective and efficient deployment of key management across the enterprise, an enterprise key management program should be developed and maintained. According to the BITS Security Working Group, such a program should consist of the following elements3:
Governance and Business Management Oversight
- Meet business, regulatory and legal requirements
- Define, maintain and enforce policies, standards and common practices
Well-Defined Key Management Life Cycle
- Key Generation
- Key Distribution
- Key Usage
- Key Storage
- Operational Storage
- Backup Storage
- Archive Storage
- Key Recovery
- Key Reissue
- Key Escrow
- Key Retirement
- Key Replacement (Rollover, Update and Renewal)
- Key Deregistration
- Key Revocation
- Key Deletion
Sidebar: The Basics of Heartbleed
In April 2014, a serious fault now known as Heartbleed was found within the OpenSSL protocol versions 1.0.1 through 1.0.1f. (Previous and later versions of the open protocol are not vulnerable to this issue.)
The problem is a result of ignoring bounds checking. OpenSSL uses a “heartbeat” (hence the moniker Heartbleed) or a keep-alive notification to maintain a secure link. Trying to keep the connection active, the client will send the server a message from time to time asking, in essence, “Are you still out there?”
It formats the message using the data length field and the payload area of the data packet: “Server, if you’re there, send me the five-letter word idiot.” Thus, the data length is five, and the payload is the word idiot. The server responds with the identical five-letter word idiot, and the client knows that the connection is still alive.
The problem occurs when a client says, “Server, if you’re still out there, send me the 500-letter word idiot.” The server does not do bounds checking to verify that the payload size matches the data length field size reported. Thus, it sends back both the word idiot along with 495 other characters it happens to have in active memory. The extra characters could be a private key or a clear-text password exchange.
While hackers cannot predetermine what the server will have in memory at any one moment, over time they could assemble enough information to find a way into your server and network. Hackers and cyber criminals are very patient.5
The National Security Agency (NSA) says that reports claiming they knew about the exploit long before it was publicly found out are false. Word was that the NSA wanted to use the exploit in its own work. In fact, antimalware researchers in turn used the same Heartbleed exploit to access secret forums used by cyber criminals. That’s cyber righteousness for you!8
Note: You can see the Heartbleed Hit List detailing which major sites have switched to a safer version of OpenSSL at mashable.com.9
References
1. National Institute of Standards and Technology. (2012). NIST Special Publication 800-57: Recommendation for Key Management – Part 1: General (Revision 3). Gaithersburg, MD 20899-8930: US Department of Commerce.
2. Microsoft Corporation. (June 24, 2014). Generating Keys for Encryption and Decryption. Retrieved from Microsoft Developer Network: msdn.microsoft.com/en-us/library/5e9ft273(v=vs.110).aspx. Accessed July 7, 2014.
3. BITS Financial Services Roundtable. (May 2008). Enterprise Key Management. Retrieved from BITS the Technology Policy Division of the Financial Services Roundtable: www.bits.org/publications/security/BITSEnterpriseKeyMgmtMay2008.pdf. Accessed July 7, 2014.
4. Cooper M D. Y. (2005). RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building. Retrieved from Tools from the Internet Engineering Task Force: tools.ietf.org/html/rfc4158. Accessed July 7, 2014.
5. Wikipedia. (June 24, 2014). Various: x.509, Certificate Authority, Transport Layer Security. Retrieved from Wikipedia: en.wikipedia.org/wiki/Secure_Sockets_Layer. Accessed July 7, 2014.
6. IBM. (2007). TCP/IP Tutorial and Technical Overview. ibm.com/redbooks. Accessed July 7, 2014.
7. Weber C. (May 2, 2011). How Web browsers display a standard SSL connection compared with an EVSSL connection. Retrieved from Lookout.net: www.lookout.net/2011/05/how-web-browsers-display-standard-ssl.html. Accessed July 7, 2014.
8. Riley M. (April 12, 2014). NSA Said to Exploit Heartbleed Bug for Intelligence for Years. Retrieved from Bloomberg: www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-bug-exposing-consumers.html. Accessed July 7, 2014.
9. Mashable Team. (April 9, 2014). The Heartbleed Hit List: The Passwords You Need to Change Right Now. Retrieved from mashable.com: mashable.com/2014/04/09/heartbleed-bug-websites-affected. Accessed July 7, 2014.
10. McCann E. (May 14, 2014). How Kaiser does privacy and security: Compliance is Everyone’s Job. Retrieved from Healthcare IT News: www.healthcareitnews.com/news/how-kaiser-does-privacy-security. Accessed July 7, 2014.
