E2E Encryption Prescription Is Bad Medicine
By Kevin M. Nixon, Information-Security-Resources.com Security Editor
“We need end-to-end encryption…”
I have heard that statement repeated many times as customers, colleagues, and press quickly point out that it is necessary for consumers and companies to conduct business on the Internet.
For a security practitioner, ironically, it is a very bad idea.
The Problem
Before you shoot me for saying it’s a bad idea, end-to-end encryption should be defined first as to set the backdrop for my arguments.
End-to-end’s definition is the means utilized when a computer communicates with the server from which or to which it is sending information, using some encryption technology.
By way of example, VPN software on a laptop communicates with the VPN server internally to build the IPSEC tunnel, and end-to-end encryption starts on the desktop VPN client and ends at the VPN server.
A second example is a web browser using SSL to transport traffic to/from a web site, whereby the end-to-end encryption starts at the browser and finishes at the web server.
A key point: the traffic is at its destination before it is evaluated and therein is the problem.
The Concern
Current best practice methodology states that security is best practiced with a Defense-In-Depth security strategy. Defense- in-Depth recommends that more than one “layer” be used in the defense of the protected assets in question.
One example of an added layer in a network topology is filtering unnecessary traffic at an ingress network point through, say, the IP Access Lists.
If a network is protected by access-lists alone protection is limited at best, given that so many attacks are conducted over “acceptable or trusted” IP ports.
Defense- in-Depth requires taking at least one additional step, frequently the use of a firewall.
Traffic which passes the first layer, and that has successfully matched the allowed traffic rules for the network’s designated IP characteristics, is then secondarily evaluated at a firewall for protocol compliance so as to avoid exploits utilizing buffer overflows or overly lengthy data requests.
Oftentimes a third step is implemented: as traffic is traversing the security checkpoints, intrusion detection engines monitor the ‘knocking on the door’ attempts and alert based on various situations.
Lastly, traffic checks occur on the destination host to ensure that the data matches what is expected before being processed.
“End-to-end” encryption circumvents some of these steps under the accepted definition.
Since the traffic has characteristics that allow it through the filtering (it has a TCP destination port 443 (SSL), for example), the next two protection depths are the Intrusion Detection engines and the Firewall… but since the traffic is encrypted, these two technologies all too frequently can’t read the traffic!
It is here that we undermine a defense in depth strategy, and here that end-to-end as good practice takes on bad characteristics.
As a result of encryption, the new set of simple attacks is targeting encrypted web sites, VPN servers, or extranet sites.
Why? Because the traditional methods for stopping these attacks are rendered useless by encryption. Traffic cannot be reviewed except under the most basic conditions, such as IP header data, which we have already established is not enough by itself.
The scenario plays out as follows: When web traffic was unencrypted, it was reviewed by firewalls for protocol compliance, header fields, and others. With that same web traffic tunneled over SSL, the payload (which is the same HTTP traffic as before, encrypted) cannot be analyzed.
In short, SSL in a very odd way is assisting the hacking community, not impeding it.
Another example is secure email. Since S/MIME is on the rise, the contents of email will be more and more difficult to analyze until decrypted, and as a result, the contents of those emails will have to be analyzed/controlled on the desktop.
This change will undermine the virus mail firewall scanners that currently aide us, for example, which then lowers our overall protection.
The Solution(s)
As an advocate for best practice, end-to-end encryption takes on a different meaning for me.
The encryption termination point (one “end”) is a device that peels off the encryption layer, perhaps even temporarily, allows the payload and previously encrypted traffic to be analyzed as defense in depth dictates, and if approved, then and only then does the firewall allow it to continue - in short, the traffic is decrypted and then the defense in depth methodology is instituted as if the traffic were never encrypted.
The change in architecture has a cost, e.g. “another” device is involved, but the benefits outweigh the costs. The defense in depth strategy is enforced while still maintaining the needed design confidence.
The existing generation devices and designs fall into three categories.
The first category terminates encrypted traffic on a front-end device, decrypts and analyzes the traffic in the clear, and if approved, sends it on in the clear to the back-end devices.
Oftentimes, this is the approach of the all- in-one vendors whereby the traffic is terminated on a VPN tunnel and/or SSL tunnel, sent to the virus and IDS scanning engine in the device, and then passed on into the back end network in the clear.
The all in one device is a security proxy. This design has strengths in defense in depth, but weaknesses in defense in exposure as the information is in the clear for too long.
The second category terminates the traffic similarly on a front-end device, decrypts and analyzes the traffic in the clear, then re-encrypts the traffic on another device and sends it to the back-end.
To address the weaknesses inherent in the previous all- in-one example, network administrators “work around” and create minimalist networks (which is good) that meet the ideological goal of end-to-end. This approach has similar strength in defense in depth, and marginal (but better) strength in defense in exposure since the traffic is re-encrypted.
The third category is evolving in the technology industry today. In this category, traffic is decrypted on a device, analyzed on the same device, and then re-encrypted on the same device and sent on.
This design ensures a minimal exposure, while still retaining the multi-tiered security capabilities. This has the now-familiar strength of defense in depth, as well as the highest strength for defense in exposure.
Conclusion
Encrypted traffic cannot be analyzed by a firewall unless either decrypted permissively or decrypted forcibly.
The same traffic cannot be cleansed of viruses, or worm signatures, or attack characteristics (IIS URL length overflow) until the traffic is decrypted on the host.
Clearly, traffic should never hit a multi-purpose operating system until after all of this happens.
End-to-end encryption is what we want, but not at the price we’d have to pay. Protection of data during creation, transmission, processing and storage or End-to-End-Defense-in-Depth is what we really want, as it ensures the defense in depth best practices are not lost.
Without it, break-ins will increase not decrease, and we again lose.
Kevin has testified as an expert witness before the Congressional High Tech Task Force, the Chairman of the Senate Armed Services Committee, and the Chairman of the House Ways and Means Committee. He has also served on infrastructure security boards and committees including the Disaster Recovery Workgroup for the Office of Homeland Security, and as a consultant to the Federal Trade Commission.
The Author gives permission to link, post, distribute, or reference this article for any lawful purpose, provided attribution is made to the author and to Information-Security-Resources.com
Stay Informed With RSS Feeds or Email Alerts Here:
Filed under: Breach, D&O Liability, FEATURE ARTICLE, Financial, Government, Kevin M. Nixon, PCI, Sarbanes-Oxley, Uncategorized, hackers, identity-theft, malware, privacy
Comments
7 Comments on E2E Encryption Prescription Is Bad Medicine
-
Ken Mages on
Tue, 24th Mar 2009 7:34 pm
-
Mark Bower on
Thu, 26th Mar 2009 11:23 am
-
Encrypted email not for everyone on
Fri, 27th Mar 2009 5:38 am
-
Arshad Noor on
Mon, 6th Apr 2009 11:30 am
-
pligg.com on
Sat, 11th Apr 2009 8:16 am
-
Patty Bates on
Mon, 13th Apr 2009 6:51 pm
-
Is “End-To-End Encryption” Realistic? Part 1 « PCI Guru on
Thu, 28th Jan 2010 12:44 pm
Spot on and well written. I agree 100%
http://information-security-resources.com/2009/03/24/e2e-encryption-prescription-is-bad-medicine/
Full disclosure: I work for an encryption vendor.
The points raised above certainly hold valid for pipe and container level encryption and traditional approaches to encryption and key management. However, there are now very different and practical techniques to make end to end encryption completely viable - and this requires a different approach.
Agreed: traditional encryption not only gets in the way of content inspection (firewalls, IDS, DLP etc), but also gets in the way of e-discovery and recovery - quite a common challenge in today’s climate of breaches, forensic investigations, M&A, acquisitions, bankruptcy, court proceedings and so on: all getting more and more demanding especially with more content exchanged with third parties and a myriad of privacy regulations to boot.
However, the article has not taken into account several key innovations in key management and cryptography that make end to end protection entirely practical in terms of cost and security and compatible with the needs of contemporary enterprises with sophisticated security defense and countermeasure layers and systems as noted.
One technique I am referring to in particular is often referred as “data centric protection” - and there are technologies now available that permit this vision to be real.
For example, AES Format Preserving Encryption - FPE for short - permits data fields and sub fields to be directly encrypted in place without expansion, referential integrity problems, and retaining validity of information.
FPE permits encryption of say an SSN resulting in a field that behaves, looks and feels like an SSN - without compromising encryption strength. An encrypted date to a valid date range for example, or I could also take a 15 or 16 digit credit card and encrypt sub fields - first 6, last 4, middle 8 - whatever I want - whilst preserving the integrity and structure of the data - e.g. Luhn Checksum.
FPE can also permit encryption in place in existing structures e.g. data protocols with fixed internal structures and so on - common in legacy systems. Take VSAM packed data on the mainframe for example, or a point of sale payment protocol expecting PAN, Track 2, etc - all this can be directly encrypted without increasing length, affecting data structures etc.
For those wishing to look at the NIST US Government AES Mode’s site it’s FFSEM mode AES.
It’s very unlikely that a firewall or DLP system is going to inspect data beyond the fact that the data does not contain malware, inappropriate content, i.e. ” this data looks like an SSN inside a spreadsheet with a HIPAA disease code structure therefore encrypt to recipient, or quarantine”, badly formatted packets or sequences of data indicating a breach - the tool is not going to need to test if SSN 123-456-7890 maps to John Doe at 123 Smith St, Breachtown, VA.
So, FPE still permits inspection without needing decryption - for end to end encryption the critical fields can now be encrypted without change impact to other security policies or the systems and data structured themselves – and most applications simply operate on encrypted data as is. Of course, trusted systems need the ability to decrypt and that’s where our company has solutions that permit practice FPE at scale. I won’t go into more here - interested readers can scan our site.
So, with techniques like FPE, there are different ways of looking at End to End encryption - and for once, End to End can mean exactly that - End to End from capture to use by trusted systems.
Lastly, techniques like Identity Based Encryption (IBE per RFC 5091) also provide secure and auditable electronic supervision over bulk content - for example emails/files etc. So beyond the ease of use and ad-hoc secure end to end protection capabilities, IBE based solutions thus permit appropriate and controlled supervisory access to systems or people (e.g. forensic examiners) - under the strict control and strong authentication of the data owners. We are running a web seminar on this for interested readers (”Integrating Encryption with Archiving and eDiscovery”).
I think it’s worth looking beyond the complicated legacy approaches to encryption and key management in light of these developments which do exhibit exactly the challenges outlined - and 10 years ago I would have been in total agreement.
However, the newer data centric techniques I outlined have now been around for several years and are deployed in very significant commercial and government organizations at scale -and address head on the challenge of information privacy in a world where encryption was once an inhibitor, not an enabler as it can be today.
Best Regards,
Mark
Mark Bower
Director of Information Protection Solutions
Voltage Security
[...] Authors Posts (105) on March 27, 2009 Kevin Nixon ran a fascinating article on encryption at Information Security Resources yesterday, disputing the need for end-to-end encryption, saying that it’s not such a great [...]
I’m afraid I must disagree with this article. (I am in the business of Enterprise Key Management and, thus, my comments may appear to be biased, but I’ll try to be objective as much as I can).
First, neither IPSec nor SSL/TLS can be classified as end-to-end encryption. The classic definition of end-to-end encryption is when the terminating application - whether it’s a word-processor, Mail User Agent (such as Outlook) or some business application - performs the cryptographic operations itself (or by a linked library) rather than handing it to the OS for encryption somewhere else in the stack (as occurs with all other forms of encryption).
Secondly, end-to-end encryption (E2EE) assumes you are dealing with a trusted entity and that you’ve implemented controls in relevant areas to ensure your trust is not violated. Let’s see how IPSec/SSL/SMIME do not support this assumption:
1) With a web-server using SSL/TLS (without Client SSL Authentication), anyone can POST anything they want to the web-server over the encrypted pipe. Since you have implicitly (though your SSL configuration) chosen to accept content from anyone connecting to the web-server, they can bypass all the classic network defenses (IDS, IPS, Firewalls, etc.) you have in place. The fault here, is not with encryption, but with the choices you made in how to configure SSL. With SSL ClientAuth, you eliminate an entire class of attacks and probably 95-98% of attackers.
2) Most IPSec implementations I’ve seen use software-based keys on the client. A simple copying of the appropriate files allows an attacker to masquerade as a legitimate client on a VPN, allowing them to now send malicious content to wherever the VPN takes them inside the company network. Once again, the problem here is not with the encryption technology, but with the decision IT managers make in how they’ve chosen to implement IPSec. Again, with appropriate counter-measures (TPM, smartcard, etc.), a whole class of attacks would be nullified.
3) With few exceptions, most S/MIME implementations I’ve seen have all been one-way - i.e. a person inside a company can send digitally-signed e-mails and receive encrypted e-mails, but rarely do they receive digitally-signed e-mails themselves unless its from someone within their own company who is using it as part of a process. As a result, most S/MIME recipients leave themselves open to attack since any attacker who has a copy of the recipients’ digital certificate can send encrypted malicious content to them. To some degree, I will also blame MTA vendors who do not make the same level of cryptographic trust available in SSL-based server applications, available in their MTA software products.
In the E2EE model that we espouse, encryption occurs only between trusted clients and server applications. What do I mean by that? Within an Enterprise Key Management Infrastructure (EKMI), every client and server is issued with a digital certificate. These certificates authenticate them strongly (when used in conjunction with TPM/smartcard/HSM/etc.) to a Symmetric Key Services (SKS) server that issues symmetric encryption keys. ALL messages between these clients are digitally signed and all responses are encrypted from the server.
Applications requesting symmetric keys, can use the symmetric keys for encrypting data within the application (through the help of a linked library) and send the ciphertext to anyone, with just a Global Key Identifier (GKID) of the symmetric key in the message. The key itself is never sent with the ciphertext.
The receiver, upon receiving the data, MUST get the same key (as identified by the GKID) from the SKS server to decrypt the ciphertext. This key will be sent only after the requester is strongly authenticated and determined to be authorized to receive the requested key.
While all this does bypass firewalls, IDS, AV, IPS, etc., the point is that all participants in this architecture are known and trusted. Untrusted and unknown entities CANNOT participate in these cryptographic operations. With such a premise, an entire class of attacks/attackers are eliminated. While there are other vulnerabilities in the system, the scope and scale of the attack vector has now changed permanently.
In the scheme I’ve identified, network-based attack-detection is redundant, because you’ve changed the premise: untrusted clients/servers cannot participate in the encryption scheme, so there can be no casual attacks. While it’s still possible to send encrypted malware from a trusted entity, the receiving side will know exactly where it came from. Additionally, depending on the protection used for the sender’s private-key, it will also be possible to know exactly what got compromised, and perhaps, how.
E2EE is the only long-term, viable security that has a chance of protecting data - everywhere. However, applications have to change, and people’s assumptions about trusted clients/servers have to change. Once they do, then it will be possible to realize better security without network-based defenses.
E2E Encryption Prescription Is Bad Medicine : Information Security Resources…
Encrypted traffic cannot be analyzed by a firewall unless either decrypted permissively or decrypted forcibly. The same traffic cannot be cleansed of viruses, or worm signatures, or attack characteristics (IIS URL length overflow) until the traffic is …
Kevin, Mark and Arshad, you have all made excellent points which have provided a very nice overview of the available solutions for E2E.
It seems to me that each of you is right. And that each of you is also wrong, if you are suggesting your preferred approach is a one-size-fits all. These are different solutions that fit into the context of particular services, and particular budget/resource constraints.
Kevin’s decryption/re-encryption discussion is correctly aimed at the services that provide for anonymous access SSL to websites, or SSL VPNs. Mark’s solution is great if you have specific applications where you know what fields you need to encrypt. No doubt, FPE will be the answer to replace SSL for many web applications, but I don’t see how it is going to replace an SSL VPN that supplies access to enterprises for home users - we’re back to Kevin’s solution for that. Arshad, while your utopian world of trust is the holy grail of of security, it is in my opinion unrealistic to think that it is manageable on a large scale, with so many different CAs and applications that won’t talk to each other, or that large scaled implementations of trusted end users won’t contain a significant share of insider threats. As you said “applications have to change, and people’s assumptions about trusted clients/servers have to change.” I think true E2EE will continue to spread amongst agreeing business or public sector partners, and that’s it.
[...] response to Mr. Carr’s call for end-to-end encryption, Kevin Nixon argues in a March 24 article that end-to-end encryption is “bad medicine.” So, what is meant by end-to-end encryption, the [...]
Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!
