I work in information security and would like to provide a business perspective on the difficult questions this committee is addressing. Security implementations must resolve whether the measures are to protect honest people from honest problems or are to provide ironclad solutions. The answer makes a big difference in what we implement. In addition, we are chasing technology. If I were trying to subvert a secure system, I would wait for the next communications protocol to be implemented or the next revision to the operating system to be installed. We have unlimited opportunities with computer systems to change whatever works today into something that will not work tomorrow.
8.1 THE PROCESS OF IDENTIFICATION
I will approach identification and authentication from the perspective of the individual, that is, how a child or person is identified to a system. We prove who we are in a number of ways, such as with a driver’s license, passport, badge, signature, or fingerprint. When I provide an identifier to you (or tell you who I am), that identifier needs to be authenticated. In the computer world, we use something you know (e.g., a password), something you have (e.g., a credit card with a magnetic stripe), or something you are (e.g., a face, a fingerprint, a retinal scan) to authenticate an identity. Note that, usually, my possession of an identifier does not authenticate my identity.
Some authenticators are much more secure than others. We all know and love our four-digit personal identification number (PIN) and pass-
word authenticators. However, administrators of multigigabyte or terabyte databases have password authenticators that are necessarily 20 or 30 characters long. The authenticator, whether weak or strong, needs to be verified.1 This is where we tend to run into trouble. The process of verifying the authenticator requires a trusted source. In the example of a driver’s license, we trust the Department of Motor Vehicles (DMV). The picture on your driver’s license is the authenticator. To identify a person you look at the picture on the license, you look at the person presenting it, and say, “Yes, I have authenticated that this is your license and I now believe your identity.” The reason this works is that I trust the license because I trust the DMV. If we did not trust the DMV licensing process, then we would not use a license for identification.
If you sign something to authenticate yourself, I have to verify that signature against a trusted copy of your signature. The trusted copy I use to verify it against gives me the confidence that you are who you say you are. For example, a bank’s trust is based on properly issued signature cards.
A token typically is not a sufficient authenticator by itself because it can be passed around—it is too mobile. But if implanted permanently in someone’s head, that token probably would have some validity. If I have a microchip embedded in my skull at birth by a National Security Agency (NSA) surgeon, and the NSA verifies the chip when I walk through magnetic readers, then I would trust it. But I cannot think of anything less draconian that would suffice to make a token a valid independent authenticator (we tend to use them in conjunction with other authenticators such as PINs).
In summary, the ability to identify a person depends on confidence. You have to have confidence in the authenticator, the issuer and issuing process of the authenticator, the source of the information used to verify the authenticator, and the process used to verify the authenticator. A system that identifies millions of people must have very high confidence. For example, in the case of automated teller machine transactions, a very small error rate in identification would make them unacceptable. If you do not have enormous confidence in the identification process, it is not
appropriate for use by a large population (including some who may be trying to defeat the system).
8.2 CHALLENGES AND SOLUTIONS
In the digital world today, technology is rarely the problem. Technology is changing so fast that, if a problem is not solved today, then it will be solved next week. Note that the opposite is also true. A technology that is secure today may not be secure tomorrow. Today we have very high confidence in digital signatures based on public key cryptography.2 The digital signing processes are good. We are able to identify, authenticate, and verify a person and his or her age very easily using digital signatures. However, the authentication and verification processes are problematic. If they really worked, then the banking community, the brokerage community, and the rest of the financial world would have implemented them years ago. We have the technology to create digital signatures that we all trust, but we do not have an infrastructure in place that makes this process workable.
The private key that you use to create your digital signature will be 1,000 to 2,000 characters long. Where will you put it? It has to be stored in an automated device of some sort. To date, smart tokens, or smart cards, are the best answer. Note that if I put my private key in my computer, we would be authenticating the computer, not me. What I want is something that, wherever I am, can be plugged into any machine to identify me. I do not want it to identify the machine, because then others using that machine could also identify themselves as me if they knew how to use the signing software, which, if they have possession of the machine, they can figure out how to do.
If we use cards, there must be universally compatible software, card readers, and signing processors. I have been involved in writing American National Standards Institute (ANSI) standards for banking, and “universally compatible” is more difficult to accomplish than it is to specify in a standard. We rarely achieve it. In software today, the signature process is fairly standard but the interfaces tend to be different.
Another thought is that if I have my secret key in a personal device (smart card), then I can use that secret key to create a signature. To au-
thenticate the person using that card to the signing system, we typically require a PIN (usually four or six digits). Remember, security is only as good as its weakest link. We have sophisticated software, complex technology, and great cryptography, and it all depends on a PIN.
Then we need a trusted authority to verify the digital signature, someone to say, “Yes, that really is Ed Zeitler’s signature.” Since it is a digital signature, it must be something more than comparing one piece of paper to another piece of paper. You would go to the agency that issued the secret key and ask, “Is this signature based on this person’s secret key?” The agency would respond. Note that I have to trust that agency.
If I am the agency giving you a private key to use to create your signature, I had better know to whom I have given it. So far, the only way we have found to accomplish this is in person. That is how you get a driver’s license. Banks want some verifiable form of identification from you in their branch office. In the financial world, there are many stipulations that you know your customer. However, in the online world, banks and brokerage firms do not strongly verify the identity of their customers anymore; they have necessarily resorted to less secure verification processes.
A very secure process and database are necessary to assign cryptographic keys. The people who assign those keys had better have them locked up tight and require strong authentication of a person requesting them. A digital signature cannot be created with a four-digit PIN for authentication. If we do not have a lot of trust in this process, it becomes a house of cards that comes apart, regardless of the zippy technology used.
Today we have digital signature software on all browsers, which is great. We were all applauding when that happened. But we still do not have card readers. We do not have a practical way to issue private keys to millions of people or a practical way to store those keys. The NSA and National Institute of Standards and Technology (NIST) have ventured into this area and have not been successful.
We do not have a trusted party to issue cryptographic keys and verify digital signatures at the national level. U.S. government intelligence agencies would not be satisfactory to the private sector. The trusted party does not have to be a government agency, but what other organization has the presence? When we started developing public key cryptography, we talked about the U.S. Postal Service issuing keys. There are also liability issues. For example, if the Post Office managed the keys and a major break-in occurred and the whole country lost the ability to process public keys (or digital signatures), whom would you sue? On the other hand, if it were a private concern, that probably would be the end of that private concern. What type of liability do companies such as Verisign, which issues cryptographic keys to the public, have? They have been addressing this issue for years and are comfortable that they have a workable
solution. But I am not comfortable with that, because if Verisign’s data centers were to blow up, people would have little recourse.
Despite the security flaws, electronic banking works fairly well. I worked in a retail company as the chief technology officer years ago, and I moved to a bank from there. I was amazed to find that the retail databases and systems had much more security than the banking systems at that time. Interbank wire transfers and the like were done in a rudimentary fashion. Anyone who knew the system could break it or cause damage. But the reality is that there was very little loss. There were reciprocal agreements between banks. If I sent you a $100 million transfer and realize this afternoon that, oops, it was fraudulent, then the receiving bank will give it back, in most cases. In banking, when you get to the top, only a few people are necessary to make a phone call to gain agreement that, “Yes, we’ll take care of that.” Although real attacks have been made against our systems, if you want to steal a million dollars, it is still much easier to make friends with the branch manager than to figure out how to break into the automated money transfer systems. Security technology has tended to stay a step ahead of what is practical in the world of financial fraud.
To get back to the beginning of this talk, the definition of “good enough” security depends on the problem to be solved—four-digit PINs may be sufficient in many cases. However, for the purpose of this study, limiting the solution to school or public library computers is vastly different from the problem of identifying a 9-year-old using any computer to access the Web. Most of the computers to which children have access probably will not be run by federal, state, or local governments.3 A strong identification process will be required.