The Internet was never engineered with security in mind. IPv4 was built for resilience and reliability, not security. There are a lot of bad people who take advantage of this fact and plenty of good people who simply make mistakes. The software and security industries set about to fix this problem by encrypting communications with protocols like SSL/TLS, HTTPS, SSH, SLADP, DNSSEC, IPSec, etc. Problem solved, right? Wrong. Unfortunately these protocols on their own do not move the needle very far, and maybe even move us in the wrong direction. As it turns out, adding encryption to communications is the easy part. Adding trust, on the other hand, has to this point been an intractable problem.
Why is there a problem with trust? Two reasons: First, currently, access to apps and IPv4 communications are both tied to the same piece of information: the IP address. We do not have a cryptographic identity to use for communications, which is why we have to login to every “secure” application like banks, email, and medical records. Second, there is no good way to manage trust relationships. Trust on the Internet is largely a leap of faith.
Sure, the communications are encrypted. But with whom are they encrypted? Does it matter if you encrypt your password over the network if it’s going directly to an adversary? Attribution on the Internet is nearly impossible today. The browser-based trust model of hundreds of trusted CA certificates does little to assert trust and assurance for the underlying communications. Case in point is the Diginotar CA hack.
Imagine for a few minutes that there is a ‘Facebook for Internet communications’. You become “friends” with services you trust. Think about the act of becoming friends – it is a very intentional, willful act. And this relationship can be broken at will when the friendship changes. What if you were only friends for a very specific point in time in order to accomplish a specific task, such as coordinating a time and place to exchange critical information? On Facebook, a friend’s profile gives you a lot more information than just a name or a phone number; you get photos, friends of friends, a past history of events (in some of which you were a participant), you get a profile with sufficient context that it becomes much more difficult to spoof. (OK, social media profiles are spoofed all the time so this metaphor only goes so far, but ultimately we’re talking about cryptographic identity “profiles” that are much, much harder to spoof.) The point being is that we need a social media-like way to express and manage the way we trust and communicate with other entities on the Interwebs.
The easy argument is that bad stuff will still make its way into our computers, and this will certainly be true for some time to come. But we need a path forward, and I have zero confidence in a “flag day” when everyone will flip over to a secure version of the Internet. We need a migration path that lets us begin to move on from the limitations of number-based (IPv4) communications to identity-based (e.g. context-based) cryptographic profiles. The good news is that there is precedence for this new behavioral model. Who uses a phone book to look up a friend anymore? We use social media and the contexts and tight relationships that are defined in this realm.
At Tempered Networks, we are building the foundational elements of a secure Internet. We are doing this by inserting a cryptographic identity into the communications stack: the Host Identity. This on its own only gets us so far. The exciting but challenging step is orchestrating trust between these identities. We do this today for securing critical infrastructure and information, but it will soon be coming to all communications near you. We will bring encryption and trust to your Internet of Important Things.