Implementing Municipal IDs without creating registry of undocumented immigrants
Published on Jan 04, 2017
The City of Chicago, like many other sanctuary cities, is planning a municipal ID program for its residents. The main purpose of the program is to provide government-issued identification to the undocumented immigrants that make up about 7% of our city.
Immigrant rights organizations have advocated for municipal id programs for years. The IDs can be accepted as valid identification required by law enforcement, banks, and social service programs. A municipal ID program can provide undocumented immigrants access to important goods and services.
Naomi Schor Library ID (Wikipedia)
Unfortunately, the standard way of implementing this type of program means creating a government database of everyone who has been issued an ID. Since the program is mainly provided for undocumented immigrants, this means creating a registry of people who are likely to be undocumented immigrants.
A registry of likely, undocumented immigrants creates many risks. Federal agencies may attempt to access the registry to facilitate the deportation of immigrants in the country illegally. Politically motivated computer hackers may target the registry for public release. Aggrieved city employees might attempt to use the list to find harmful information about their personal enemies.
Some of these risks can be mitigated by good law, good policy, and good IT security practices. However, the best way to protect against a database breach is to avoid storing dangerous information in the first place.
As designers of data systems, DataMade has prepared a whitepaper on how a municipal ID program might be implemented without creating a registry that could cause harm if it was released.
If you know anyone advocating for a municipal ID program or working on implementing one, please share this with them.
This memo has benefited tremendously from feedback from experts in the digital security and government sectors, and we would love to hear from you, too. Send your feedback to email@example.com.
Here’s the memo on Securing Municipal IDs:
Typically, ID programs collect information about people for three reasons.
Below I describe a system that enables certification and authentication of IDs while storing identifying information in a manner that is secure. By secure, I mean that the release of stored information would not provide identifying information about people who have been issued IDs.
Certification consists of two tasks: establishing that an applicant is eligible for an ID and ensuring that the applicant has not already been issued an ID.
First, an official or officials must review any required material that verifies that a person is eligible for an ID. This could be a passport, mail, driver’s license, lease, etc. If the officials are satisfied, we only need to record the officials’ decision, and do not need to store any of the documentation. This does require us to trust the front-line officials, but this is what we normally do anyway.
Second, at any given time we want each person to have one and only one municipal ID. There are a number of ways this might be done.
Using a computer program that is similar to the ones that unlock smartphones, we can extract identifying features from an applicant’s fingerprint. We can then use another special program to take these identifying features and turn them into a long, unique string of letters called a “hash.” The same fingerprint will always produce the same hash, but you can’t figure out the features of the fingerprint from a hash.1
Before issuing an ID, the fingerprint hash can be sent to a central server. If there is already a record of an issued ID with the same hash then the new ID is either not issued or the old ID is marked as invalid.2
Neither the fingerprint, nor its identifying features should ever be stored, just the hash.3
Unfortunately, this approach may introduce too much cost. Additionally, immigrants may not believe that their fingerprint is being stored in a secure manner and refuse the entire municipal ID program altogether out of concern of fingerprinting. As a fallback, we can use a hash of other identifying information used for certifying eligibility.
1.2 Documented information
In an unsecure system, we would try to check that an applicant didn’t already have an ID by by looking up the name and address of the applicant in a database of issued IDs. If it matches, we would either deny the new ID or mark the old ID as invalid.
In a secure system, we can do basically the same thing, but instead of storing the name and address, we will store a hash of the name, address, and other uniquely identifying information.4
When we are issuing IDs we can see if the fingerprint of the applicant’s information matches any existing ID. If it does we know that someone with the same information has already been issued an ID, and can take the next appropriate action.5
After an ID is issued, we may want to later verify that 1. this is a valid ID, and 2. that the person holding the ID is the person to whom the ID was issued.
Historically, most ID systems accomplished this by making the physical ID difficult to counterfeit and by including a signature, physical description, or image of person on the physical ID. This approach means that creating IDs would be more expensive, but will not require storing any sensitive information in database.
If physical measures are not sufficient to safeguard against counterfeiting, then we can store physically identifying information in a remote database, but lock that information away with a password that is only stored on the physical ID. That way, only people with physical access to the ID would be able to access information about the ID holder stored in the central database.
One way that this authentication could be done is to store an encrypted image of the person’s signature and have the password for unlocking the image on the physical ID.6 If a government official needs to validate an ID, they can use a computer program that requests that the encrypted image be sent to their device, the signature can be unlocked using the password on the physical ID, and compared with person’s signature. Without the password, the images are not viewable. The password could be encoded in a barcode or magnetic strip, for convenience.
In this secure system, it will not be possible for the ID issuer to send renewal notices to expiring IDs, because the issuer doesn’t have access to that information in their database.
It would be possible for the issuer to publish an up-to-date list of ID numbers that are soon to expire. An app could be built that would let ID holders subscribe to that list and be notified on their device about an impending expiration.7
The protections that a system is designed to have are often compromised in implementation. Any system that contains very sensitive information should be audited regularly, at least annually, by a third-party security firm that includes penetration testing. This means that the firm attempts to break into the system and recover the information that we hope to protect.
If the firm is able to break the system, then we know that our system is not currently safe and needs to be enhanced. If they cannot break the system, then we have some assurance that the system is capable of withstanding attacks from people who are as skilled as the firm. Without this kind of testing, then we just have hope that our system works as designed.
Care must be taken to make sure that the fingerprint feature extractor has enough entropy to avoid dictionary attacks of the hashed values. ↩
The idea of using a fingerprint to check for existing ids is due to an anonymous reviewer. ↩
If an adversary already had a database of fingerprints, as many security contractors and law enforcement agencies do, then she may be able to cross reference if someone in her database was issued a municipal ID. Knowing someone was issued an ID implied that they lived in a city during some time period.
In addition to a person’s fingerprints, the adversary would have to have 1.) access to the municipal ID database of hashed fingerprints and 2.) be able to access or reproduce the software that extracts features from fingerprints and produces the fingerprint hash.
This concern was raised by B_meson of Lucy Parson Labs ↩
While a cryptographic hash alone provides some protection, the simplest implementation would be vulnerable to a dictionary attack. For example, there are are around 600,000 addresses in Chicago and there are very common names within our immigrant communities. If an attacker had access to the database, she could compare the hash of every combination of addresses and common names. If an attacker was able to generate a hash that appeared in the database, then the attacker would know that someone with that name and address has an ID.
These vulnerabilities can be mitigated by repeated rounds of hashing or by using a very large pool of hashing salts.
These mitigations were suggested by an anonymous reviewer ↩
Unfortunately, this scheme will only will tell us if someone with the exact same information has been issued an ID. This system is not tolerant to nicknames or misspellings. ↩
The idea of using the signature for authentication is due to an Jeremy Gillula, Electronic Freedom Foundation. ↩
This idea of an app is due to an anonymous reviewer. ↩