The Government’s Certificate Authority: Why you shouldn’t worry

Well, yesterday, I made a nice long response to a blogger I follow who was confused and upset over this idea to have the government as a TLS client certificate authority, much like Thawte or CACert, but with its own system of identity verification. He apparently refused to post the comment, and instead opted to post comments from other people who don’t understand how the public-key infrastructure works. Here are the gems of intellect:

This angers me, and it seems like ever since he started working for FOX News, almost all his posts are hugely politically motivated, and most of the discussion about gun rights, which I enjoyed, has deteriorated into weekly updates on successful gun usage. While this is a bit interesting, it’s not worth reading all the ignorance, and having your completely well-reasoned responses ignored. I think I’ll be unsubscribing.

Just the facts, ma’am.

The article specifically states/quotes the following:

There’s no chance that “a centralized database will emerge,” and “we need the private sector to lead the implementation of this,” he said.

So, that being true, it will probably be handled the correct way, which is something I’ve been waiting for. If this were not mentioned, I would be concerned that a central database would be necessary. Even if that were true, only people without social security numbers should be concerned, as that is already a central database with tons of vital information about you.

How is this going to work?

I assume they are planning to create a certificate authority which will sign certificates generated for people by the private sector or individuals. What this means is that you, the citizen, can generate a public key and a private key (a key-pair) for use in encryption and digital signatures. You can then submit a certificate signing request to the government, who can use their private key, guarded behind lock and key, to sign the certificate without ever having seen it. Because of this, they still have no ability to decrypt any document encrypted with your public key. You can keep your private key on a computer that doesn’t have any ability to connect to the internet and use sneakernet to encrypt and sign documents if you like. Most people just resort to symmetric encryption of the private key (password protection) instead, since this is easier practically, but a bit less secure as most people’s passwords aren’t the greatest. If you want a good password, see my post here – and don’t use the first command, use the crazy perl one.

This is how server certificates currently work on the internet. Say you’re a bank, and you need to have SSL work for your customers. You create a TLS key-pair, make a CSR (certificate signing request), ship that off to any of about 40 different companies/authorities for identity verification and usually payment (see CACert for an alternative to payment), and eventually receive a signature for your key from that company.

Most browsers have these 40 or so certificate authorities (to use their correct name) embedded in their guts, so whenever a public key is encountered when making a secure connection, your browser can verify its signature to test its authenticity. What this means is that your security is currently in the hands of these 40 or so companies/authorities (Verisign, the Chinese government, the US government, etc. – a full list is here). If someone’s malicious site obtains a signed certificate from just one of them, your browser will have little closed locks and green colors all over it, saying it’s 100% secure. For those who are less technically inclined, this is a bit confusing – even though the connection is secure, your personal information is not.

Anyway, with personal certificates, the validation and signing process is essentially the same. The metadata attached to the certificate might have some of your vital information (social security number?) since that would be required to validate the certificate at the government’s CA. Let’s say I obtained one of these government-signed certificates – what would that mean? Well, it would mean I would be able to use it on any site that trusts the government! If your site doesn’t trust the government, you don’t have to recognize them as a signing authority – it’s that simple. Of course, that might limit your audience a bit, since they’ll have to authenticate some other way. Also, if the social security number is included in the metadata for the public key, I have a feeling most people won’t be using it in daily browsing because of security concerns, and rightfully so. Where this makes sense is any official interaction with the government that occurs online – things like doing your taxes. Imagine, you have one of these certificates, and so does your tax preparer if you use one. Both of you can sign the digital document that contains your taxes, and submit it to the government. This is much more authoritative that a signature in ink (I mean, seriously, that is the worst form of authentication). The government can mathematically prove that your key was used to sign it, meaning either someone figured out how to steal your key or you actually did the deed. This brings up another interesting point.

What if my key is compromised?

The government, as a certificate authority, would have to maintain a revocation list. This is a list of certificates signed by that authority that are invalid for some reason. Maybe they were compromised like I suggested above, maybe by using a bad password on the private key. Then, anyone needs to be able to obtain an updated copy of this list from the certificate authority.

Why is this better than a social security number?

The real win here is hidden under the surface. If this is implemented, one’s parents could generate them a key-pair at birth, have it signed, and that person’s “social security number” is just the hash value of that public key, which is a completely public number! If it needs to be verified, fine! The person just signs whatever document needs to be verified with a key-pair that matches that hash! It’s like if your social security number had a piece that was never visible to the public, but could verify your authenticity as a citizen. Applying for credit-based accounts would be ridiculously easy if you used your certificate to verify your authenticity. Got phone calls about debt collection and they don’t believe you’re who you say you are? Just sign a document they provide and send it back to them. That should be a lot easier than arguing over the phone. The possibilities are numerous. Actually, buying a gun might even be easier since most of the forms could be completed online in one’s home by clicking and typing rather than sitting in a dealer’s shop in person for an hour. Just load up your private key, which fills out all your vital information for you, click some radio buttons, submit to the state police, receive a signed (!!!) response, forward it to your gun dealer, go pick up your gun. It’s so easy, and the PKI (public-key infrastructure) makes it possible.

Also, there should be no limit to the complexity of the keys other than generation time. If you want a super secure key, use a natural source of entropy for a long period of time, and create something very very large. Right now, the standard secure personal key seems to be 2048-bit, but 4096-bit is quickly becoming the new standard. Soon, 8192-bit will be the thing to have, and so on. Since these hypothetical USKeys (I just made that up – it totally should be called that) need to be extremely secure, software may have to be updated to accommodate their size. Were they to be created today, at least 8192 of not 16384 bits should be used to make them last at least 20 years (barring huge advancements in public key encryption attacks).

Sadly, there is a possible issue with this system. Quantum computing might pose a threat to some of the algorithms currently used for public-key infrastructure. Luckily, the math world is beginning to bring us answers. Regardless of the implementation, the high-level idea is still the same – users generate a key of some sort, authorities sign a piece of it, users submit that signed piece to places, identities are verified, information is encrypted, everything is happy.

In summary, I really think that this could change a lot of the non-secure protocols in the government’s operation, and almost definitely the operation of many businesses that depend on valid identities. I just hope they don’t screw it all up, which knowing the government, they very well could.

2 thoughts on “The Government’s Certificate Authority: Why you shouldn’t worry

  1. darkwalk

    Problem is, this will confuse the heck out of people. I can imagine my parents handing over their private key to anyone who ask, or they might start signing documents with both keys. The revocation list will become so large and unwieldy over time. Not sure what the solution should be though.

  2. Erik Post author

    Yeah, the inherent complication of PKI is enough to confuse most of the population. It’s easier if hardware is used – key fobs or cards. The military has the CAC card, which can be used as a secure identifier for PKI. Of course, that’s less feasible politically since the government would have to issue the cards/devices, and people are paranoid about national ID cards. Since anyone can generate a software key, and the government only has signing power, it’s less upsetting.

    The revocation list would be large, and I’m wondering how Verisign and others manage this problem, since I’m sure they’ve issued millions of certs. Good question.

Comments are closed.