Stories I’m hearing of Black Friday sales being interrupted by outages at NICS, PICS, and other state POC systems raises the question of whether we could do better. Can we think up systems that work better, overall, than the NICS/POC system? I should note that I absolutely agree that background checks are a feel-good measure, and we’d be better off without them. See Clayton Cramer’s research that shows they are essentially useless. But for the foreseeable future, we’re stuck with them.
I’ve argued previously that I think there are issues with BIDS system, because it offers counter arguments to our opponents when trying to argue with lawmakers that we ought to modernize the system. But I think BIDS is an interesting system that I’m going to use as a basis for one of two ideas about how to make a less intrusive and more reliable system.
Modified BIDS
The chief problem with the BIDS system, as it is explained, is that in order to be able to uniquely identify a person, you generally need a least the person’s name and date of birth. If you have a common name, often that will not be enough, so you might need other data, such as a driver’s license number, or social security number as well. The problem is the more data you distribute, the more opportunity you give to identity thieves. Encryption is no solution, since if the BIDS client can decrypt the database, the key for decrypting it is in that system somewhere, and someone will find it. If everyone who was in the system was an axe murderer, maybe that wouldn’t be too much of a concern. But as we all know, there are plenty of people who end up prohibited for technical and often petty offenses.
The solution is not encryption, but hashing. Hashing allows you to go one way, but not back. If you had the NCIC, for every prohibited person, generate two hashes, one of first name, last name, date of birth, and the other the same plus a DL/ID number, you would effectively eliminate the identity theft problem. You wouldn’t even need to encrypt the data because there would be no way to take the hashes back to personalized data. This would solve the privacy issue with BIDS.
But BIDS, being a distributed system, still has a lot of other potential faults that are hard to counter. Here are arguable points opponents of this will use when trying to persuade lawmakers:
- The government doesn’t know who is buying guns, but they also don’t know when prohibited people are buying guns in order to prosecute them. You and I both know this never happens, but it will likely persuade lawmakers, especially the tough on crime, law and order types.
- There is no means by which to certify the dealer actually ran the check. You could propose a certification program, which would allow certified BIDS apps to give unique verification, but the distributed nature of the system would make this problematic, since you’d also be distributing the means by which to forge certifications.
- The nature of the distributed system creates a lot more potential for false negatives, meaning people passing a check when they shouldn’t. You can do a lot technologically to mitigate this, but much of what you’d need to do would make the system frustrating for dealers. The distributed nature of the system would mean more points of failure. That can’t be argued against.
- Right now all dealers need to run checks is a functioning telephone, copies of ATF Form 4473, and a working pen. With BIDS, they will also need a functioning PC and a reliable and constant connection to the Internet. Also consider that for ever 10 million prohibited persons, you’re talking about a database that is about 2.5 gigabytes. Today this is a lot easier than it was when people thought up the BIDS system, but this would be a problem for rural FFLs.
One possible solution is to maintain the call in system for dealers that have to use it. You could have certified call centers, run by private parties, that process a call in using BIDS data on their end.
Modified Hashing NICS
An alternative to a distributed system like BIDS is to have a the NCIC generate the same hashes, except only distribute them to NICS. In this case NICS public facing interface would accept only hashes, would check those hashes against its database, and would clear or deny a person. If the person is cleared, the system would return back a cryptographically signed response. The FBI would publish API code for running background checks, and certify applications that are permitted to act as a front end for NICS. Basically if you can pass FBI’s unit testing, you can get a certification. All the API code and unit tests would be open source, so you can be sure there isn’t any funny business going on. You could build background checks into any FFL software, or Smart Phone App. You could have certified third parties that run call centers for rural FFLs, and mail them the certificates for people who clear for the dealer’s records.
Because the FBI never sees anything except a hash, they have no idea who’s buying guns, unless the person who is buying matches a hash in the prohibited list. This would preserve the possibility of prosecution for felons who try to buy guns, which would be a key argument our opponents would use against BIDS. While it’s true that a hash doesn’t allow you to go backwards, NCIC could still identify the person who’s data matches the hash.
Here’s how it would work in a sale. I believe it’s important to preserve the ability for an uninitiated person to walk into a gun shop and walk out with a purchase. So dealers can run a background check on a person right there, and print them a check certificate, to be ultimately retained by the seller. Alternatively, you could use a certified app to run your own check and print out a cryptographically signed certificate, which can be presented to and authenticated by the dealer when you go to buy, or can be presented and authenticated by anyone who has access to an certified app by which to authenticate your certificate.
You make the certificate valid for a period, say 30 days, after which it will no longer verify. It’s possible to revoke cryptographic signatures, so if the hash comes into the system, it would be possible to revoke the signature on an outstanding hash do it won’t authenticate when the seller checks it.
The big downside to this system is that the feds have the information to make a hash on everyone if they wanted to. Using a hashing system would raise the bar to keeping tabs on everyone buying guns, but it would not make it impossible. Storing the needed SHA512 hashes for everyone in the US would only be about 75 gigabytes, which is hardly big data by today’s standards. I’ve always thought this was something that could be dealt with by publishing NICS source code, and doing third party auditing of the NICS system to ensure there’s no funny business going on.
Conclusion
There are certainly better systems one can think up than what we have now, and one could imagine hybrids of the two systems I mentioned. The trick would be convincing lawmakers, who don’t understand any of this stuff, that it would work as well, and actually far better than the current system.
You would also need to deal with the state Point of Contact (POC) systems to integrate with the federal system, or do an outright preemption of state laws to eliminate the Point of Contact system entirely. In the new system, POCs would be the certified apps, which any non-governmental party could create. The biggest problem you’re going to have in any technically sophisticated system is that you’re dealing with implementation needing to be done by a government that can’t even get a website working. I also wouldn’t be surprised to find NCIC computers and the software that runs them were essentially silicon fossils. A regularly scheduled rehashing of up to 10 million names in the system might be far more than it can handle. Maybe you can’t bring in a DL/ID number with criminal records. Nonetheless, it wouldn’t be hard for volunteers to come up with an API specification that would allow a system like this to function. Technically, this is not complicated, but conceptually, it might be a bit hard for non-technical people to understand.
