Imagine if you woke up one morning, and found out that Walmart was now selling a device for $5 that could easily and instantly open almost any deadbolt lock. That’s right – the kind of lock that is supposed to give “extra protection” to just about every door on earth. That’s the magnitude of security problem posed by the Heartbleed Bug.
Contributing columnist Bruce Kleinman wrote the first half of this article and posted it to his “From Silicon Valley” blog on April 6, 2014. The timing of the post was a remarkable coincidence: just 36 hours before the Heartbleed Bug started making headlines.
As the creators of technology, we engineers need to re-think our commitment to security and safety. The systems we design don’t just earn us money – they are often trusted to protect people’s lives, privacy, and assets. This is a solemn responsibility that is all too often overlooked or given short shrift in our ongoing race to get timing closure, first silicon, working prototypes, and volume shipments.
-Kevin Morris
———————————————————-
Serious Security, Serious Implementation
I’ve touched on the lamentable state of security on my “From Silicon Valley” blog and provided some available real-world illustrations of security done right. This article picks up the thread and offers an extremely strong security solution that can be readily implemented today. Sand Hill Road venture capitalists, my offer stands; let’s discuss over lunch at Madera.
The solution I have in mind is a personal security token that turns conventional two-factor authentication on its head. Two-factor is a HUGE improvement over password-only authentication. There are three methods in broad use today:
- A physical token (small enough to be attached to a keychain) that displays a six-digit code that changes every minute or so
- An Android or iOS app that performs the same function as the physical token
- SMS or voice callback: a six-digit code is texted to your mobile or a computer rings you up and reads the code aloud
In all three methods, the six-digit (could be shorter or longer) code is required IN ADDITION TO your username and password to authenticate and login. This is fairly secure and yet not widely adopted. True and recent story: I was struck that my bank did not offer two-factor authentication. Wondering if perhaps they added it while I wasn’t looking, I poked around their website and could find no indication that two-factor authentication was available. Oddly enough, I discovered that it WAS available … thanks to a Google search. Go figure.
Most computer-savvy Silicon Valley types who value security find the modest overhead of two-factor authentication a perfectly reasonable trade-off for greater security. I suspect adoption of two-factor authentication is inversely proportional to distance from Silicon Valley, though that is just a hunch. We need a security solution that is seamless to use AND stronger than conventional two-factor authentication.
Enter my latest idea: the personal security token (PST). The acronym ‘PST’ is clearly unacceptable, what with Pacific Standard Time having laid claim to it quite some time (pun unintended) back; then again, standard time has shrunk to what seems like a ten-week period, so PST could be available if we end up on permanent daylight savings time. But I digress.
The PST is a tiny device WITH NO DISPLAY that attaches to your keychain. It has a low-power radio (Bluetooth-LE for conversation’s sake) and runs for roughly five years on its coin cell battery. It arrives with a pre-assigned, random six-digit PIN; pre-assigned to ensure that you do not use your anniversary, birthday or 123456. I recognize that forcing you to memorize a random PIN is not user-friendly, but honestly, I’m protecting your best interests. Here’s the good news: those six digits are the only password you need, period. For everything: websites, banking … even Starbucks.
Before we peek inside the PST, let me describe the entire user experience:
The PST has one button and one multi-color LED. It communicates with your mobile phone/tablet, PC, bank, and any point-of-sale terminal via RF (Bluetooth-LE for conversation’s sake).
Setting up a new ‘account’ on the PST
(I am assuming that we are in the transition phase from “old authentication” to “PST authentication.”) Use your existing credentials—username, bank card, credit card … Starbucks card—and password/PIN to authenticate. Click the “please setup my PST button” on the website/keypad and enter your new six-digit PIN. The LED on your PST turns yellow to indicate that a new account is about to be set up; click the button on the PST to confirm. The LED blinks three times. That’s it, done. From this point forward, you’ll use your PST to authenticate.
Using the PST to visit a website
Click the “login with my PST” button on the website. Enter your six-digit PIN on the website. The LED on your PST turns green to indicate that you are about to log in; click the button to confirm. That’s it. No username, no unique website-specific password to remember.
Using the PST to perform a financial transaction in person
Walk up to an ATM or point-of-sale terminal. Touch the “login with my PST” button and enter your six-digit PIN. The LED on your PST turns green to indicate that you are about to log in or purchase something; click the button to confirm. That’s it. No wallet full of ATM and credit cards.
On the face of it, this seems criminally INSECURE. A six-digit PIN and “Open Sesame” to your entire electronic wallet? There is QUITE a bit more taking place: “the rest of the story” happens completely behind the scenes, hiding an enormous amount of complexity and an EXTRAORINDARY degree of security. Let’s go inside the PST.
The personal security token consists of a single mixed-signal IC, a tiny RF antenna, and a coin cell battery. The case of the token might be cracked open, the IC can be de-layered – and the security will not be compromised. At the heart of the lone IC is—you guessed it—a physically unclonable function (PUF) with 1 Mbit or more of statistically provable entropy.
A VERY brief summary of PUF fundamentals (see “From Silicon Valley” for more detail):
It boils down to identity; each ‘thing’ must have a digital signature with all of the following guarantees: [a] every signature is completely unique, [b] signatures must be stable over time, and [c] there is no possibility of falsifying signatures.
So your PST has a very long and completely random UNIQUE string of bits; it is stable, and it cannot be observed/read … much less cloned. The lone IC also includes a modest amount of embedded flash that might be compromised by a motivated thief, so it is used in a manner consistent with its potential vulnerability. Rounding out the IC: a 256-bit AES (or other public key encryption scheme) cryptography block and a complete radio subsystem. On a 40nm process, the chip cost is less than two dollars; BOM cost of the entire personal security token is around thee dollars.
The PST assigns chunks of the PUF string to each ‘account.’ For illustrative purposes only, imagine that each ‘account’ is assigned a 1 Kbit chunk of PUF: 512 bits of ‘userid’ and 512 bits of ‘password.’ So with even a modest 1 Mbit PUF, the PST can hold a thousand accounts, each with its own userid and password. This is probably massive overkill, but I did promise “an extraordinary degree of security” some paragraphs back. And we’re just getting rolling …
The aforementioned modest embedded flash is simply a directory: an identifier for the ‘account’ (website, bank, credit card) and a pointer to grab the chunk of PUF assigned to that account. A standalone app can manage these pointers – for example, deleting an account and freeing up the associated block of PUF for re-use (or not, if you’re truly paranoid).
Setting up a new ‘account’ on the PST
A website (via your mobile phone/tablet or PC) or a point-of-sale terminal asks the PST to set up a new account. After checking the embedded flash directory to ensure that an account hasn’t already been set up, a chunk of PUF is assigned and the directory is updated. The cryptography block uses your six-digit PIN plus the 512-bit ‘password’ from the PUF to generate a private/public key pair. The 512-bit userid and the PUBLIC key are sent from the PST back to the phone/tablet or PC or point-of-sale terminal from which they are saved in the cloud. The userid and public key can be sniffed/copied with ZERO loss of integrity. How? The PRIVATE KEY NEVER LEAVES the IC; it is not even saved, rather, it is re-generated each time the account is authenticated.
Using the PST
A website (via your mobile …) or point-of-sale terminal asks the PST for authentication. Your PST looks up the account in the directory and replies with the 512-bit userid. This long random string is your username; you do NOT need to remember the account’s username, bank account number, or credit card number. Using your six-digit PIN and public key (unique to each of your accounts) created and stored in the cloud earlier plus the PRIVATE key of the “place of business,” the server generates a unique-to-this-transaction challenge/response pair. The challenge is sent to your PST, which generates its response using the PRIVATE key (unique to each of your accounts) plus the public key of the place of business. The response is sent to the host where—thanks to the magic of public key encryption—both sides are authenticated. The challenge/response traffic can be sniffed/copied, yet thanks again to public key encryption, this does NOTHING to reveal the private keys.
What happens if you lose your PST? First of all, it is literally on your keychain so I am hoping that is a remote event. A mistyped six-digit PIN is met with a mandatory 10-second delay before retry, so it will take some time to brute-force guess your PIN (thank goodness I didn’t let you pick your anniversary, birthday or 123456). Once you realize that you’ve truly lost your keys, you remote kill the PST … long before your PIN is cracked.
“Hold on,” I hear you thinking, “how do you perform this remote kill? And does that leave me SOL with every one of my websites … AND STARBUCKS?!?! Oh yeah, and what happens when the battery finally dies?” Those are really good questions, and I have a REALLY elegant solution that I’ll happily walk you through AFTER an NDA … and lunch at Madera.
———————————————————-
The second half of this article was written one week later, after the Heartbleed Bug stormed the headlines.
Kevin Morris
———————————————————-
Serious Security Vulnerability: Heartbleed
Let’s not mince words: Heartbleed is a catastrophic security hole, with BOTH terrible impact AND terrible breadth.
IMPACT. That comforting little “padlock” icon in your browser when you are entering financial information? There is a better than even chance that what you thought was a secure HTTPS connection could have been easily compromised, enabling an attacker to see your username, password and the traffic between you and the server. For the past two years. And the vulnerabilities do not stop with your web browser:
- Secure email (using TLS) was open to the vulnerability, enabling an attacker to read your email as it came off the server on its way to your email client.
- SSL-based VPNs that gave you and your IT department a sense of, well, privacy? That may have been compromised as well, enabling an attacker to see the traffic on the VPN.
- Yet-to-be-named hardware was open to the vulnerability. Some gear from Cisco and Juniper has already been identified; it is VERY prudent to assume that LOTS of home Wi-Fi routers use OpenSSL and will prove to be vulnerable.
BREADTH. At least 500,000 sites had/have the Heartbleed Bug. Half. A. Million. And that last bullet on impacted hardware is yet to be scoped and will present a grand challenge to address. (How many people EVER update their Wi-Fi router firmware? My utterly non-scientific guess is 10% at best.)
Good news: PRESENCE of the Heartbleed vulnerability does not automatically mean it was EXPLOITED on the site.
Bad news: if the vulnerability WAS exploited, the nature of the bug makes it a cinch for the attacker to COMPLETELY cover his/her tracks. So if the site had the vulnerability (for the past two years), there is simply no way to know if the website was compromised in general and if your data was compromised specifically.
Paraphrasing “This is Spinal Tap”: How much more bad could it be? None. None more bad.
I am STRONGLY anti-alarmism, but the tone is warranted in this case. If you use the web, you ABSOLUTELY need to take personal responsibility for your security and take action:
- Educate yourself. Start with this stick figure overview (I’m serious) and then the Heartbleed Bug website.
- Consult this list of the Top 100 websites and their vulnerability status.
- Use this tool to check any website—including intranet servers—for the vulnerability.
- Pay special attention to your email provider, as the LAST thing you need is compromised email.
- Once you’ve confirmed that a site HAS PATCHED THE HOLE, change your password on the site. Re-read that: it does NO good to change your password until AFTER the Heartbleed Bug has been patched. And use this opportunity to convert to different, strong passwords on all finance and commerce websites.
Question: I use two-factor authentication on my financial websites. I’ve got nothing to worry about, right?
Answer: kudos for taking security seriously! You still have plenty to worry about. For starters, what makes two-factor authentication effective is—how can I put this?—having two authentication factors. Heartbleed potentially exposed one of those two factors (your password) to an attacker. So you are better off than someone using only a password, but you must assume that Heartbleed reduced your two-factor authentication down to one-factor authentication. It is every bit as important, therefore, that you follow the five steps above.
The Heartbleed Bug opens a hole in one of the foundational elements of web security: Secure Sockets Layer (SSL). While I was completely serious earlier when I declared that you need to educate yourself and take appropriate action, that does not include diving into the workings of SSL. If you are so inclined, however, Wikipedia has a great article (shocking surprise, that) HERE.
A lot of really, really smart people developed SSL. It is based on public key encryption, and we all know how much I admire public key encryption (and not just for the great terminology like “elliptical curves”). Some important elements of SSL:
- The server MUST have a private/public key pair.
- SSL makes provisions for a client private/public key pair; my utterly non-scientific guess is that a client key pair is used less than 1% of the time. That is really too bad, but guess what? Implementing both server and client key pairs would NOT have mitigated the Heartbleed vulnerability.
- WTF you say? After all, I extolled the “extraordinary” security of server + client key pairs in my last post. SSL uses public key (very strong, asymmetrical) cryptography as a “wrapper” to set up simple shared-secret (less strong, symmetrical) cryptography for the entire session.
- WTF you say? If SSL goes to the trouble of implementing asymmetrical cryptography, why not stick with it for the entire session? Because symmetrical cryptography is far less computationally intense and we all like snappy websites. SSL development started 18 years ago and was ratified 15 years ago. No exaggeration: your contemporary mobile phone has roughly an order of magnitude more compute horsepower than a late 1990s personal computer. What was perfectly sound rationale for using asymmetrical cryptography ONLY to set up the shared-secret symmetrical cryptography, to be blunt, doesn’t sound so rational in 2014.
- Lest you think I am letting my bias for asymmetrical cryptography color my judgment – well, the simpler symmetrical cryptography SSL uses for the entire session is an essential element to what makes Heartbleed so catastrophic. The bug enables an attacker to read memory on the server – memory that holds the aforementioned shared-secret. That wonderfully secure public key cryptography “wrapper” is rendered WORTHLESS if an attacker can read the ensuing master shared secret. You might as well have skipped the wrapper entirely and transmitted the shared-secret in plaintext.
It is all right there in the cited Wikipedia article under Description step #7:
Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session.
Let me set one thing perfectly straight: SSL itself is secure. Heartbleed is a BUG in the OpenSSL stack used by those half a million (and counting) websites. With that said … s**t happens, and robust systems should be designed so that when something like the Heartbleed Bug hits the fan, the results are not catastrophic.
I am not only strongly anti-alarmist, I am strongly anti-take-advantage-of-warranted-alarmism. So it is with some trepidation that I connect the dots from the first half of this article to Heartbleed:
- My proposed scheme not only uses asymmetrical cryptography for authentication, it ENFORCES server AND client private/public key pairs.
- As envisioned, my protocol encrypts your 512-bit ‘username’ with the server’s public key. It is decrypted using the server’s private key and stored in memory. A Heartbleed attack—or any attack permitting access to server memory, up to physically hanging a logic analyzer off the memory bus—will be able to read your username in plaintext.
- HOWEVER, as I highlighted, your 512-bit private key NEVER leaves the token. That VERY long private key, you may recall, is your password. Ergo, your password is NEVER on the server. Go ahead, gain physical access to the server and hang a logic analyzer off the memory bus: your password IS NEVER THERE. A gaping hole on the server side CANNOT compromise the integrity of your private key.
- But why leave the server’s private key vulnerable? If we are going to mass produce “personal security tokens” that provide an EXCEPTIONAL degree of security, then, seriously, we need to apply the same level of security on the server side. Build a secure cryptographic engine around a PUF inside the server, and its private key NEVER LEAVES that engine. Go ahead, examine the server memory byte-by-byte … the server’s private key will never be there to observe.
- Although I didn’t specify this in v1.0 of the MRD, it goes without saying that my proposed protocol uses strong asymmetrical cryptography for the ENTIRE session.
- One of many important lessons from Heartbleed: security MUST be implemented on the client AND the server in CONCERT. S**t happens on servers located all over the world: patches may or may not be applied; datacenter cages may or may not be properly secured; employees may or may not be trustworthy. The system outlined above mitigates such serious security breaches and contains the damage.
It is high time that we get serious about security. 2014 is only 14 weeks old, and we’ve seen MORE THAN ENOUGH MOTIVATION: the Target credit card breach, the NSA whatever-the-heck-you-make-of-it, the Heartbleed Bug – just to name the headline makers.
We were given Web 2.0, now it is time for SECURITY 2.0: extraordinary security built upon a foundational root of trust for a truly robust trusted platform.
If someone decided that a popular instant messaging application is worth 14 billion dollars (4 billion if you’re a hard-ass and only count the cash), then a whole TON of people ought to consider what the foundational integrity of the internet is worth. Security 2.0 needs to happen – right now, right here.
About the Author:
Bruce Kleinman is a senior technology/business executive and principal at FSVadvisors and blogs on fromsiliconvalley.com
Leave a Reply
You must be logged in to post a comment.