Towards Dynamic Relationship Security
Once upon a time....
The cryptographic systems that drive the Internet today came together in the late 1980s and early 1990s. RSA and other public key cryptographic techniques became widely known and deployed in early Netscape, MOSAIC, and other browsers and web servers. At the time, the biggest consumer of cryptography was really the US government led by NSA and NIST*.Things were different. The "big" public / private security program was to move email away from SMTP to X.400 with the classified world focused on the Defense Messaging System (DMS).
It didn't happen ...we are still using SMTP as the basis of email today and the X.509 certificate format may be the only vestige of those days.
But, many of the assumptions that drive our security systems came from those times and those concerns.
Two of which are causing us real problems today:
1. The focus on "confidentiality" and using encryption to protect it.
2. The core model of "trusted" or hardware based encryption.
Data disclosure vs. Identity Integrity
The underlying thinking of Cold War cryptography is about protecting sensitive data from an enemy for short or long periods of time.War plans, intelligence, ... all sorts of secrets.
The keys that drive the cryptography might be compromised, but the systems are reliably managed by a central national authority (for the classified world in the US, NSA, the original idea for the unclassified world, something like the Post Office or NIST).
Basically, these systems are very hierarchical, centrally managed and control with the idea that the system itself, being the government, was inherently trustworthy and inherently secure.
The government, as it has always done for military systems, would "know" when keys had been compromised (such as a military position being overrun) and use its control of communication and security systems to remove the bad guys from the system.
... the problems begin to emerge:
- Today, there are around 50 "certificate authorities" who issue the long term certificates in your browser. These systems are highly variable and the only thing you can say is that, at best, someone's credit card cleared somewhere when a certificate was issued... maybe.
- While "confidentiality" is nice, our biggest problems are not "data in transit" - the real-time collection of sensitive information, but "data at rest" - the harvesting information from a server where access controls have been defeated and so any encryption that is used is irrelevant.
The problem isn't an outside "bad guy", but a subverted "good guy".
- Also, we are often more concerned about subversion of identity - if an access control failure occurs, that it doesn't spread and if a key is compromised, that it isn't used elsewhere.
Basically, I care more about you using my stolen credit card number than I do about you having a copy of my Amazon purchases for January.
Our systems are designed assuming long term keys are stored securely
,,. and they aren't.Back in the late 1980s and early 1990s, most cryptographic systems were still implemented in dedicated, hardware devices. Computing was expensive and cryptography, at the time, was very processor intensive, so it made sense that cryptography would be housed in a dedicated device as it had been since there were widgets that could do cryptography at all.
In the US, for DMS (and unclassifed email at the time), the idea was to use the FORTEZZA card. A PCMCIA (later PC card) peripheral which did all the cool crypto stuff.
As we now know, the plummeting price for hardware in the 1990s and since virtually eliminated the need for special purpose processors except for video. While there were cryptographic peripherals, the growing demands for ecommerce and pervasive need for some level of security essentially moved almost all commercial security implementations into software. Computing capability got way ahead of our ability to consume it... so ... why not implement security in software? It's "free" after all.
BUT, in most server environments, cryptographic keys are in software... and servers are where we've seen our major data breaches.
While I never gave my credit card to Yahoo, I certainly did to Target and Home Depot, yet somehow, their breaches never triggered a replacement for my credit card and change of my credit card number.
ASIDE: Things continue to change... hardware has finally gotten so inexpensive that dedicated security processors and peripherals are now economically viable in many environments (see the chip and PIN credit cards) though the ever reducing cost of general purpose processors will continue to challenge them.
Those keys that businesses hold.. the public key certificates that encourage us to "trust" online firms... are at real risk.
After all, when a data breach occurs, it is rarely found immediately, the problem often festers for months.
We have built up our security systems to solve a set of problems that don't reflect our needs or vulnerabilities.
Towards Dynamic Relationship Security
And it isn't just our cryptographic systems. Our access control methods (username and password, username and token, or username and biometrics) have similar vulnerabilities to server breaches as do our credit card, checking, and other payment systems.Our main requirements are:
- Protecting the relationship between parties for future actions
- Protecting ourselves in the face of (nearly) inevitable breaches of individual's secrets, private keys, and identity and authorization information
* NOTE: I worked at NSA during part of this period and I had some involvement in the security of some the systems at the time. Nothing here is even vaguely classified. This narrative is a colorful recollection and reconstruction and should not be considered authoritative, but a "good security story" to scare kids and CISOs.
Get more No BS security insights and help
If you are interested in more articles like this, check out my Patreon and become a supporter. If you have a security question, ask me!
Become a Patron!
No comments:
Post a Comment