Some observations on the rekey of encrypted.google.com...

(This is a fairly technical post about monitoring changes in PKI infrastructure. Unless that sentence interests you, you probably don't want to read further.)

Since the Comodo CA issue I've been playing around with some of the PKI monitoring infrastructure including Perspectives and the Google Certificate Catalog. So when I heard that encrypted.google.com was rekeyed today, I decided to see what those monitoring infrastructures saw. A couple things surprised me.

First, I happened to have a browser window open to encrypted.google.com from the previous day when it was still using the old certificate. So I saved both the old and new certificates. From the certificates it was clear it wasn't just a new certificate for the same key, but a new key (along with a update of the validity period from 2/2011-2/2012 to 4/2011-4/2012).

Then, I looked at Perspectives, and it showed the new certificate (94:47:cd:b3:15:94:94:0c:f5:fd:5c:1b:b7:3c:ee:ce - the blue below with the purple being the old certificate) as just starting to be seen, no surprise there.

But, looking a little more carefully at the individual notary responses, while two notaries had either not seen it yet or just seen it in the last day, the other two have been seeing the new certificate for a while. hostway.ron.lcs.mit.edu saw the new certificate briefly back in April:

Key = 94:47:cd:b3:15:94:94:0c:f5:fd:5c:1b:b7:3c:ee:ce
 start: Tue Apr 26 02:28:11 2011
 end  : Tue Apr 26 14:28:07 2011
 start: Tue May  3 14:28:41 2011
 end  : Thu May  5 02:28:55 2011

And mvn.ron.lcs.mit.edu:8080 has been seeing it on and off for a week like clockwork:

Key = 94:47:cd:b3:15:94:94:0c:f5:fd:5c:1b:b7:3c:ee:ce
 start: Fri Apr 29 14:12:06 2011
 end  : Sat Apr 30 02:12:06 2011
 start: Sat Apr 30 14:12:05 2011
 end  : Sun May  1 02:12:06 2011
 start: Sun May  1 14:12:06 2011
 end  : Mon May  2 02:12:11 2011
 start: Mon May  2 14:12:18 2011
 end  : Tue May  3 02:12:20 2011
 start: Tue May  3 14:12:17 2011
 end  : Wed May  4 02:12:23 2011
 start: Wed May  4 14:12:22 2011
 end  : Thu May  5 02:12:25 2011 

Then I went and queried Google Certificate Catalog:

$ dig +short 20115245c15b7650f11e23985f117728cc8dcdb2.certs.googlednstest.com TXT
"15079 15098 19"

It has seen the new certificate for 19 days. If you do the math, the first day it saw the certificate works out to be April 14th, which is the day after it was issued (according to the certificate itself). So either it is clued into the issuance, or Google uses the certificate internally for a while before the world sees it.

So what does this mean? If this rekey is any indication, it means these things don't happen in a clean binary manner. Different parts of the network may see new certificates before others, and maybe for short spurts cutting back and forth between new and old. Looking at the detailed responses from Perspectives, previous changes for encrypted.google.com also show a similar bouncing back and forth (particularly with hostway.ron.lcs.mit.edu). This is turn means that certificate checkers using these infrastructures are going to have to be tolerant of this sort of noise during a change over.

Also, looking at Perspectives long term data for encrypted.google.com, it looks like a change happens every two months or so (note, one can't tell from this if they re-key or just create a new certificate):

Sony PSN: Compromised security questions...

I am not a fan of security questions. My big criticism is that they turn an innocent fact about you into a shared secret - you now have to remember that the street you lived on in first grade gets you into your webmail account and not blog about that favorite childhood memory.


Now with the recent Sony Playstation Network compromise, it has raised an even bigger problem with (suspected in this case, they aren't sure) compromise of security questions. What do you do if your password questions get compromised at a site?

First, you probably have no idea what answers you even gave. The idea behind these questions is that you remember the answers naturally, so you don't need to write them down. So you probably have no idea now what questions you were asked and what answers got leaked.

Second, even if you did somehow know what answers you gave Sony (perhaps you signed up two weeks ago and you have a great memory), do you remember all the other sites you gave the same answers to? Time to go site to site checking (except, back to my first point, you probably don't remember what answers you are checking for).

Third, let's say you remember all that. These answers about you have been compromised and you can't change them - it's your history! This is a problem shared with biometrics, once your fingerprint gets out, you're stuck with just having nine left. Once a fact about you is known, you just have to know not to use it anymore as a secret.

So, security questions just went from bad to worse in my book.

My suggestion, fill in random strings (I use a random password generator or "slap on the keyboard"). Write your password down in a good password program like Password Safe or KeePass or use the password saving feature on your browser (I suggest setting a master password if you do so). Or if you do forget your password, most sites will still have some way you can get your password reset the old fashioned way through customer support.

Some interesting work on security questions:

• Evaluating statistical attacks on personal knowledge questions
• It's no secret: Measuring the security and reliability of authentication via 'secret' questions 
• OWASP on Secret questions 
• Messin' with Texas Deriving Mother's Maiden Names Using Public Records (pdf)
• How I Stole Someone's Identity (SciAM article)

And finally xkcd:

 

Registration for 2011 CACR Higher Education Cybersecurity Summit now open

Date: Monday, April 11
Time: 8:00 a.m. - 5:00 p.m.
Location: University Place Conference Center, IUPUI

The Indiana University Center for Applied Cybersecurity Research cordially invites you to attend the 2011 Higher Education Cybersecurity Summit. This year's summit will take place on Monday, April 11, on the IUPUI campus near downtown Indianapolis.

The summit will offer a variety of sessions of interest to security, policy, and privacy officers as well as cybersecurity practitioners. There is no cost to attend the summit.

My new position at IU CACR

Late in January I started my new position at Indiana University's Center for Applied Cybersecurity Research(CACR) as Deputy Director. I'm excited about this opportunity in that I'm joining a great existing team and working with CACR's Director, Fred Cate, who is internationally renown policy and pricacy expert. CACR has a existing education and outreach program that includes an annual cybersecurity summit (coming up again this year on April 11th, save the date) and a unique video-based cybersecurity education program for the general public called SecurityMatters. It is also a pleasure to work closely with staff at IU's Pervasive Technology Institute and the researchers in the informatics department that I've collaborated with remotely over the years.

On top of all that, the position returns me to Bloomington, where I grew up. Though I admit, it's strange coming back home after 22 years away.

My primary contribution to CACR will be to develop and lead a technical applied cybersecurity program to compliment the existing CACR outreach activities and cybersecurity research activities at IU. More on that to come as plans firm up over the coming weeks.

Are cyberattacks an act of war?

An interesting question is what constitutes "cyberwar?" That is war in cyberspace. It wasn't defined a few years ago, and it's still not well defined today.

I was reading Cyberdeterrence and Cyberwar by Martin C. Libicki of RAND today. It's a long document and I've only made it through the dozen or so pages at this point, but he makes a really interesting point (page xvii) talking about the role of cyberdeterrence in preventing cyberwar:

Might retaliation send the wrong message? Most of the critical U.S. infrastructure is private. An explicit deterrence policy may frame cyberattacks as acts of war, which would indemnify infrastructure owners from third-party liability, thereby reducing their incentive to invest in cybersecurity.

In other words, if cyberattacks can be considered acts of war, this would this trigger an Act of War exclusion common in many insurance coverages, allowing parties to escape liability from damage caused by a cyberattack by framing it as a act of (cyber)war?

Your money gets stolen from a bank: sorry, act of cyberwar.

House burned down by a virus attacking your smart meter: sorry, act of cyberwar.

However, the courts have decided 9/11 and similar acts of terrorism are not acts of war:

the courts have consistently held that a “war” within the meaning of an “act of war” exclusion can only exist as between two sovereign or quasi-sovereign governmental entities.

So, despite rhetoric about "war" in various forms, courts have set a pretty high bar for use of the term. Until two countries come out (or one at least) and declares cyberwar explicitly on another country, I doubt we'll see the term hold up in court.

Why security is not THE goal: TSA, built to fail.

There is an old joke in computer security:

Q: How do I make my computer secure?

A: Lock it in a safe and put it at the bottom of the ocean.

The joke being that you've made the computer really safe, but also completely unusable.

But this joke has a good lesson, and that is: Security is never THE goal.

It is a goal, one of many. But it's never the only thing you're trying to accomplish. There are always other goals, e.g. making something useful, perform well, appealing to the senses, or just available to enjoy.

Security is always a trade-off with these other goals. As Bruce Schneier puts very well in his talk (worth watching), the question is not "will it make us safer?" but "was it worth the trade-off?"

Following that logic, I've always thought that making security the goal of single organization, or group in an organization - "the security team", was a bad idea because it let the everyone else off the hook for security, they could assume "the security team has it" and ignore it.

But I've realized lately there is an even stronger reason why it is a bad idea - any organization or team who's sole focus is security will, by nature of doing their job, continuously increase security without regard for anything else.

And, to my point, one of these other things is protecting our civil liberties.

Like many others, I'm very unhappy with the TSA's new body scanners. Their policies to this point have been silly and annoying, but this is now crossing a line, in the opinion of many, myself included, from annoying to violating. (The no-fly list has arguably done so as well for years now.)

How did we get into this mess?

In thinking about this, we've created an organization in the TSA whose sole goal is security. Heck, it's one third of their name and it's baked into their mission:

The Transportation Security Administration protects the Nation’s transportation systems to ensure freedom of movement for people and commerce.

First and foremost is "protect the transportation systems." They started in the right direction with "ensure freedom of movement," but that's stopping far short of ensuring civil liberties, dignity, and privacy.

So fundamentally, "we've" created an organization that only cares about security. Back to Bruce's point, they only ask if something will make thing more secure, not whether it's a good trade-off against privacy, civil liberties, economics, or even if it's just silly. If it increases security, they've done their job.

Add to that the lack of any real oversight, congress is not going to risk looking weak on security, and we've created a department that has a mission to keep protecting the transportation system to a greater and greater degree, with no constraints.

And it will keep protecting that system more and more until we're all flying locked in safes, or worse.

On the Government's request for more wiretapping regulation

The news that the federal law enforcement wants new regulations in order to make wiretapping easier is about a month old now and there are a number of pieces explaining why it's a bad idea, e.g. EFF, Steve Bellovin.

With my engineer's hat on and having designed secure systems, this regulation would be a nightmare. Effectively to add the ability to wiretap a secure system adds so much complexity that it would have a huge negative impact on the security of the system.

Every secure system can be used for good and bad. Yes, there will always be bad guys using them, but there will always be lots more good guys using them for good purposes, and if we weaken the systems we hurt the good guys more than the bad. Usually much more, because good guys obey the law, while bad guys don't.

Installing a backdoor in a system reminds me of the online poker scandal a couple years ago, where a backdoor was built into the online poker games for development was used for cheating. I grant that while the technical details in that case are largely unknown and its likely there could have been better security, but it's an example of how such backdoors get used: if there is something of value to be gained and the backdoor is there, bad guys will figure out how to use it.