Posted on 10/04/2017 8:08:22 AM PDT by Red Badger
I'm well aware of how public key crypto works. I've used PGP since it was a DOS-only program somehere around version 1.9 or something like that.
My main problem with any kind of implementation of this is, in fact, the implementation. In short, unless the implementation were absolutely brain-dead simple and almost impossible to screw up or lose the generated keys, it would be a flustr cluck of cosmic proportions. The average person out there has no idea how to securely do anything. They are also apparently incapable of taking any precautions whatsoever to back up their data. People are reallyreally stupid about this stuff.
Even for folks like me who have been dealing with cryptography for literally decades now, it is really difficult to get anyone to actually use it because it takes dedication, understanding, and care to actually do it right.
How are you going to implement a PKI in such a way that a grandmother won't lose her ability to authenticate anything when the hard drive on her computer that she barely knows how to browse the web with, and has no backups of goes TU?
We agree that it’s not a tenable solution.
Again, I think the best we can do at this point is move to more complex alphanumeric SSNs.
Key management is really the hardest thing about PK crypto. Even when you're careful about such things people get confused when you update a key. I generally put a 5-year expiration on my PGP key. Sometime in year 4 it is necessary to generate a new key. Then you sign it with the old key. Then you revoke the old. That keeps the trust between the old and the new. If you have a hard drive crash, and don't have a backup, there is no way to revoke the old. It's now out there forever with no way to call it back. Sure, you can generate a new key, but then you'll run into folks trying to use the old one, and you can't decrypt anything encrypted to the old public key.
Most of the above could be easily dealt with through software, but really can't do much against the inevitable hardware failure unless you are careful about keeping a spare copy of your keyring.
Doesn’t really matter what you call it or how you make it. It will still be a series of numbers that you wind up putting on a bunch of forms which will unlock your entire financial record and be stolen by bad guys.
And technically speaking it is not used for identification purposes. It has no photo or anything so it’s completely useless for that. It’s used for RECORD keeping, which in an entrenched bureaucracy is way more important.
Just making it a hexadecimal number would increase space available for assignment. You can't make the number much larger though, as we know that it is difficult for folks to remember more than 7 digits. That's why the number is typically broken up the way it is. It makes it much easier to remember in chunks (yeah there are other reasons as well). Nine is actually pushing the limits of what the average person can easily deal with. I would really like to see it expanded to a 10 digit hex number anyway, with the last 'number' being a binary check bit. That would give us 68,719,476,735 plus a check bit. That should be enough for a while.
Definite Beatles influence there.
Yup. The only way that I can think of would be to start with your DNA, and have a token generate time-based session keys that you'd use to authenticate against a central database. Of course, that requires the government having a sample of every single person's DNA in a database. (Big can 'o worms there) What would happen in the case of identical twins?
A perfect solution to this probably doesn't actually exist. I think you're ultimately going to have to go to something token-based. But you'd have to be able to guard against it being effectively a bearer instrument. i.e., if this person has this key, he is that person. You need at least two factor authentication.
Given data the government already has by virtue of the 'real-id' act, you could actually implement something like this. Take a digital hash of your fingerprint and use that as a part of the token. The other would be a passphrase or something similar. You could also tie it to a specific phone number that a temporary pin could be sent to.
The problem would be resetting any of this. Let's say that you burned your fingers so that your fingerprint has changed. How do you prove you are you? Or you lose your token. Now you have to go get a new one, and you need to authenticate to get it. Hopefully the fingerprint would do it, but if both were damaged at the same time somehow, authenticating will become much harder for you.
Needless to say the whole issue is really a big can of worms.
I agree. And I think James Madison would as well if were around to apply the observations he made on government to technical systems run by the government:
But what is government itself, but the greatest of all reflections on human nature? If men were angels, no government would be necessary. If angels were to govern men, neither external nor internal controls on government would be necessary. In framing a government which is to be administered by men over men, the great difficulty lies in this: you must first enable the government to control the governed; and in the next place oblige it to control itself. A dependence on the people is, no doubt, the primary control on the government; but experience has taught mankind the necessity of auxiliary precautions.
--from Federalist 51
I remember getting my card circa 1963. “This card and the number cannot be used for Identification. It’s illegal to do so.”
You wouldn't necessarily need the government to do it, but to do need a way to validate keys. We already have an existing PKI infrastructure of sorts, though I've never really depended upon it in the public key servers. I have actually used it as a starting point for certain individuals that I wanted to have the public keys of, but given the way the web of trust works, you still have to manually (i.e., verbally) validate fingerprints. I've often thought the notary public system would actually be something that could be efficiently harnessed for this, but again, you run up into computer literacy/security issues.
And when the .gov’s private key is compromised, and it will be, the whole system collapses.
Remember when the Verisign private key was compromised 5 years ago? Their entire CA was made obsolete, and they had to revoke ALL certs ever issued through it.
“If you can tell me a good reason to require the public keys to be signed by the govt (or anyone else) I’d love to hear it.”
Who is going to be the issuing authority in this scenario? The government is. The government would be signing and issuing citizen IDs, using their private key. They will also use it to provide authentication and non-repudiation of citizens’ keys. (someone is going to need to validate the keys when a citizen attempts to authenticate with it)
Once they private key of the government authority server is compromised, the entire system collapses. Anyone would then be able to issue citizen identifiers. The .gov would have no choice but to revoke all previously issued citizen IDs, and we start from scratch.
My last post on this, because you’re just not getting it.
Good one LOL
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.