Securing Municipal IDs

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)

The risk introduced by municipal IDs

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.

Mitigating risks

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 info@datamade.us.

Here’s the memo on Securing Municipal IDs:

Securing Municipal IDs

Download (PDF)

Requirements

Typically, ID programs collect information about people for three reasons.

1. Certification — the person is eligible for an ID
2. Authentication — an issued ID is authentic and belongs to the person bearing the ID
3. Renewal — the person’s ID will soon expire, and we should notify them

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.

1. Certification

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.

1.1 Fingerprints

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.¹

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.²

Neither the fingerprint, nor its identifying features should ever be stored, just the hash.³

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.⁴

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.⁵

2. Authentication

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.⁶ 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.

3. Renewal

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.⁷

Security Audits

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.

---

Footnotes