Cryptography
When we talk about encryption, especially to someone who isn’t familiar with it, we generally get a wide variety of interpretations. Generally, this is often perceived as a form of magic that some three-letter acronym government agency utilizes and can only be conjured and deployed by Stephen Hawking level genius mathematicians. While we could say there is some truth to that, current commercial applications such as Secure Socket Layer (SSL) has come a long way in modernizing that perception. More often than not, any poor implementation can result in a poor perception, and encryption is definitely one that has suffered from this in the past.
In today’s world we see a massive expansion of electronic data storage, personal information being used, and the growth of laws and regulations to help guide and protect it all. As we move through these times of expansion and change as security professionals, we must find ways to protect our customers information and our financial interests by preventing data breaches. We believe that in conjunction with other information security approaches, cryptography will be a very powerful tool for protecting said information. Implementing cryptography in our organization, if deployed correctly, doesn’t need to be a headache.
In today’s world we see a massive expansion of electronic data storage, personal information being used, and the growth of laws and regulations to help guide and protect it all. As we move through these times of expansion and change as security professionals, we must find ways to protect our customers information and our financial interests by preventing data breaches. We believe that in conjunction with other information security approaches, cryptography will be a very powerful tool for protecting said information. Implementing cryptography in our organization, if deployed correctly, doesn’t need to be a headache.
Knowing how and when to apply cryptographic methods within your information system is very important. That said, better understanding your Threat Environment and any applicable laws and regulations for your company is the foundation for basing any cryptographic implementations in your infrastructure. As an example, lets take a look at the Health Care Industry.
Threat Environment
The healthcare industry is one of necessity, as such it is a prime target for malicious users to attack for a multitude of reasons. Those being identity theft, personal gain and political attacks. As a whole the health care industry has seen a drastic increase in data breaches from 2009 to 2015. As noted from the Health Insurance Portability and Accountability Act (HIPPA) journal, “Between 2009 and 2018 there have been 2,546 healthcare data breaches involving more than 500 records. Those breaches have resulted in the theft/exposure of 189,945,874 healthcare records. That equates to more than 59% of the population of the United States. Healthcare data breaches are now being reported at a rate of more than one per day” (HIPAA Journal).
Relevant Laws, Regulations, and Standards
The healthcare industry is heavily regulated, enforced, and most of the technical mechanisms available have federal standards and guidelines to assist in their implementation. For purposes of my example, lets look at what a proposed cryptographic solution might utilize from NIST publications as a guideline:
The healthcare industry is heavily regulated, enforced, and most of the technical mechanisms available have federal standards and guidelines to assist in their implementation. For purposes of my example, lets look at what a proposed cryptographic solution might utilize from NIST publications as a guideline:
Alongside of data breaches, companies also face the threat of unauthorized access and/or disclosure of Personally Identifiable Information (PII). While we generally see hacking as the main cause of breaches, improper and unauthorized access to PII and their disclosure are not far behind. Other threats we find ourselves facing is improper or lack of controls being implemented in our portable electronic devices like laptops and other devices used to store PII. Outside of not following proper cryptographic guidelines we also face threats of our employees not following proper means of disposal of PII, Personal Health Information (PHI), or electronic PHI (ePHI).
These threats come at a cost to not only us but any company in the health industry in the United States. This cost comes in the form of HIPPA Violation Penalties. These threats come at a cost to not only us but any company in the health industry in the United States. This cost comes in the form of HIPPA Violation Penalties.
These threats come at a cost to not only us but any company in the health industry in the United States. This cost comes in the form of HIPPA Violation Penalties. These threats come at a cost to not only us but any company in the health industry in the United States. This cost comes in the form of HIPPA Violation Penalties.
Now that we've touched on a mock threat environment and applicable laws and regulations, lets start to look at what cryptographic techniques we could utilize. To assist in understanding where these techniques are going to be applied, to the left is a sample network diagram for reference.
Block Ciphers
As a guideline for determining what Block Cipher Modes to utilize, based on the HSS recommendations, I focused on NIST publications 800-21, 800-111, and 800-38C. As their guideline suggests, incorporating Advanced Encryption Standard (AES) with block and key size of 128 was acceptable without any major system or network latency. As this is fairly inexpensive to implement and has less impact to the network then a higher key size of say 256, the majority of our components were chosen to utilize this selection where possible. This selection helps us maintain confidentiality as Asymmetric encryption is used to transfer a symmetric key and also to make sure that the other site/person is really who it seems to be.
For systems outside of the corporate infrastructure, we utilize BitLocker for our remote workers to protect any PII as well as any PHI that might be saved locally. Then any access to the corporate network will require VPN access, which while at a higher key of (256bits) than NIST requirements, is less impact as it’s only for external connections. This will help us fall in line with HSS and NIST guidance. That said, while we want to protect our users and providers information, we cannot force encryption upon their systems. However, when they need to access their PII or PHI on our corporate network, we are able to require encryption via SSL and data in motion encryption. Access to our corporate network via Wi-Fi will be protected via AES- Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) as per NIST 800-38C.
Hash Functions and Authentication Codes
As a guideline for determining what hashes and MAC’s to utilize, I based my decisions on HSS recommendations. I focused on Federal Information Processing Standards (FIPS) publication 198-1. As their guideline suggests, incorporating Keyed-Hash MAC or (HMAC) with a hash function using Secure Hash Algorithm (SHA) and a 256-bit key as acceptable without any major system or network latency. As this is fairly inexpensive to implement and has less impact to the network then a higher key size of say 256, the majority of our components were chosen to utilize this selection where possible. This selection helps us maintain integrity as there are no known collision attacks on the MAC value if using in the traditional manner. For systems outside of the corporate infrastructure, we utilize BitLocker, as it utilizes HMAC-SHA-256, for our remote workers to protect any PII as well as any PHI that might be saved locally.
Then any access to the corporate network will require VPN access, which while at a higher key of (256bits) than NIST requirements, is less impact as it’s only for external connections. This will help us fall in line with HSS and NIST guidance. That said, while we want to protect our users and providers information, we cannot force encryption upon their systems. However, when they need to access their PII or PHI on our corporate network, we are able to require encryption via SSL and data in motion encryption. Access to our corporate network via Wi-Fi will be protected via AES- Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) as per NIST 800-38C, which is also utilizing HMAC-SHA-256.
Key Distribution
As a guideline for determining what non-cryptographic controls to utilize, I based my decisions on the NIST Special publication 800-57 on Recommendation for Key management and 800-97 for Establishing Wireless Robust Security Networks as applicable to our system architecture. The continued utilization of FIPS publication 198-1 and others as a means to incorporate Keyed-Hash MAC or (HMAC) with a hash function using Secure Hash Algorithm (SHA) and a 256-bit key or 2048-bit key for Rivest-Shamir-Adleman (RSA), as acceptable without any major system or network latency, we took a step back to identify where we should provide any Pre-Shared Keys (PSK), (RSA) keys, and how to properly manage, place, and secure with NIST recommended algorithms. This guidance was specifically taken from NIST SP 800-57, Table 5: Protection requirements for cryptographic keys.
These areas of consideration were to ensure a single key was used only for one purpose and the use of the same key for two different cryptographic processes was not in our architecture as it may weakling the purpose of the provide security mechanism. For wireless access we avoided any use of Wi-Fi Protected Access Pre-Shared Key (WPA-PSK) as it was not recommended by NIST and should avoid the use of PSKs. As such, the incorporation of using Authentication, Authorization, and Accounting key (AAAK) was used via the Extensible Authentication protocol (EAP) for the authentication to be established. For local LAN authentication we are utilizing a Public Key Infrastructure (PKI) for our users and Kerberos to authenticate both users and computer accounts where PKI is not used.
Public Key Infrastructure
To integrate a conventional PKI system into our environment, I’ve chosen to utilize Microsoft (MS) Server platform as a Certificate Authority (CA) as the Common Off the Shelf Software (COTS) product in conjunction with guidance from NIST Special Publications 800-57 Parts 1-3 and 800-32. The MS servers are already part of our existing infrastructure as central management of authentication for our users, systems, and services from within the company LAN to external facing users. The CA will be locally managed with imported collections of known trust store root certificate collections from Apple, Microsoft, Chrome, and Mozilla. Certificates distributed by the CA will have varying expiration dates dependent upon the need and security level the certificate is being used for. At no time will certificates be issues for a user in excess of 24 hours. Certificates used for systems, like web servers and databases may be exempt from this based on current security policies.
Utilizing a smaller allowable time before a certificate expires will help alleviate the administration overhead of constant management of audits and revocation lists. That being said, we will utilize a Certificate Revocation List (CRL) by utilizing the Online Certificate Status Protocol (OCSP). Our certificates and keys will be protected by utilizing the standard 2048-bit keys and stored on self-encrypting storage arrays. While maintaining our servers by following strict patch management, following security best practices, there will always be some risk. The risk in this case is if our private key and CA is ever compromised, every user and system utilizing those keys are at no longer protected.
Applying Kerberos Server
To integrate a conventional or symmetric cryptographic system such as Kerberos into our environment, I’ve chosen to utilize Microsoft (MS) Server platform as a Domain Controller as the Common Off the Shelf Software (COTS) product. The MS domain controllers (DC) are already part of our existing infrastructure as central management of authentication for our users, systems, and services from within the company LAN to external facing users. The DC, while utilizing Kerberos, works by receiving a ticket granting ticket (TGT) from a client, which the DC verifies and sends the TGT back to the client encrypted. Our clients store that TGT until it expires, at which point the local session manager will request another TGT from the DC. When a client wants to access a resource, they will send the current TGT to the ticket granting server (TGS) with the service principal name (SPN) of said resource. At which point the TGS sends a valid session key for the service to the client then the client forwards the session key to the service for access.
How Cryptographic Mechanisms Enforce Security Policies
Our industry landscape has many challenges, security being at the front lines. As we know cyber-attacks from Ransomware to zero-day exploits of a system happen daily and we can observe the types of attacks based on historical analysis, we need to clearly identify and update our security policies. For our polices it is important that we are able address three key areas; is our policy measurable, repeatable, and is it enforceable? Outside of listing all of our current security policies here, we will instead talk about assumptions for those that are in order of the proposed cryptographic updates above.
Another critical addition to our design is the incorporation of a development test bed. This will allow us to better define the specification process of our software life cycle. Specifically, where our developers can design our software with our chosen encryption implementation after requirements and functional specifications are detailed. This is key as the lack of these definitions can and will lead to vulnerabilities in our software and hinder our encryption techniques. Developing our software around the defined requirements and functional specifications will ensure our software does only what it was designed to do which should simplify our development and architecture overall.
Lastly, I incorporated into our system architecture document the call out to utilizing a Cryptographically Secure Pseudorandom Number Generator (PRNG), specifically Fortuna. While not completely prone to attack, utilizing this specific PRNG does allow some of the design choices to our implementation of it. Again, this will go back to our development process and where we define the requirements and functional specifications. As our PRNG is critical to ensuring our encryption choices remain as secure.
CSOL 510 Reflections
While I've worked with varying cryptographic methods in the past, learning more about the process and importance of better evaluating your environment prior to implementing a solution has been career changing. In fact, encryption can be an enabler to be more flexible with my current implementations while gaining additional security through confidentially, availability, and integrity. Also, it will allow me to comply with data privacy laws and regulations set forth by The U.S. Department of Health and Human Services (HSS), and the National Institute of Standards and Technology (NIST). It is also important to note that there are myths about encryption out there that we able to debunk throughout the course. Of those is encryption causing system performance degradation. Which can be true for any application or operating system. As long as encryption is implemented correctly, our overhead on systems can be minimal. This is more so as you look to introduce hardware specifically designed with encryption in mind. Such as Intel’s Trusted Platform Module (TPM).
Key philosophical discussions were brought up throughout this course as well. Ranging from "is it ethical for companies to provide back-doors or by-pass their encryption for law enforcement". Often these questions aren't thought of on a day-to-day basis when working with cryptographic implementations. At least from my experience. As a long time implementer of security controls for private and public sector companies, 99% of the time I was responsible for implementing those controls and not the one to question if they were correctly satisfying security requirements. Learning more about when certain cryptographic methods are better suited for others has been a key learning point for myself during this course as well.
Key philosophical discussions were brought up throughout this course as well. Ranging from "is it ethical for companies to provide back-doors or by-pass their encryption for law enforcement". Often these questions aren't thought of on a day-to-day basis when working with cryptographic implementations. At least from my experience. As a long time implementer of security controls for private and public sector companies, 99% of the time I was responsible for implementing those controls and not the one to question if they were correctly satisfying security requirements. Learning more about when certain cryptographic methods are better suited for others has been a key learning point for myself during this course as well.
References on Cryptography
Healthcare Data Breach Statistics
NIST Special Publication 800-21 2nd Edition
NIST Special Publication 800-111
Overview of BitLocker Device Encryption in Windows 10
NIST Special Publication 800-38C
NIST Special Publication 800-57
Real-World Work Combating Insider Threats
FIPS Publication 198-1 The Keyed-Hash Message Authentication Code (HMAC)
Healthcare Data Breach Statistics
NIST Special Publication 800-21 2nd Edition
NIST Special Publication 800-111
Overview of BitLocker Device Encryption in Windows 10
NIST Special Publication 800-38C
NIST Special Publication 800-57
Real-World Work Combating Insider Threats
FIPS Publication 198-1 The Keyed-Hash Message Authentication Code (HMAC)