Knock, knock. "Who's there?"
This simple question is at the core of all security efforts. Without establishing the identity of those who request access to your sensitive and valuable data, you cannot extend your trust. And system security is predicated on a system's ability to establish that trust.
How do you decide whom to trust? Because there are unscrupulous people in the world, how do you determine that requesters are who they say they are?
Follow along as we discuss three ways to determine user identity -- two of them are old (in computer-industry terms), "trusted" friends and one relies on relatively new technologies.
At first glance, establishing a requester's identity seems simple. It is predicated on answering one or more of these three basic questions:
- What do you know? Knowledge is a traditional pass key into a secure system. The ubiquitous username and password prompt is the most common identity challenge; even when computers communicate with other computers, they typically start by verifying knowledge of some previously agreed-upon bit of information. This passphrase method of identification is much older than computers -- it is a "social" means of identification.
- What do you have? The lowly key, the foundation of security since ancient times, is a form of ownership challenge. Any person possessing the key to a lock can open that lock. Now, ATM and credit cards fulfill similar purposes. It is a "material" means of identification. (This question extends beyond simple identification into several other areas of security.)
- What are your characteristics? When speaking in general terms, using relatively immutable physical characteristics as identifiers (biometrics) is the oldest form of identifier; it comes from pre-verbal society. Case in point: before a newborn can speak (or even focus its sight or understand the concept of ownership), it recognizes its mother by the tone of her voice -- it is a "biological" means of identification. In terms of technology, biometrics is a relatively new method of identification. Efforts abound to make it readily available, though, because it can be the most reliable means of identification -- it is exceptionally difficult to change or counterfeit your physical characteristics.
In all their myriad forms and formats, these three questions can help verify a person's identity to any level of certainty you require. The specific question or questions asked and the form in which the challenge is presented determine how difficult it is to fool the system and how reliable the identification is.
Let's examine each question in detail.
Passwords, secret gestures, hidden signals, secret codes. All of these are answers to the question "What do you know?" That this question is necessarily overt makes it the one most often associated with security.
There are many ways to challenge a user on the basis of shared knowledge:
- The most common way is simply to ask the user to repeat the shared item, whether it is a password, a secret phrase, or some other hidden bit of information.
- The next most common method is to refuse to acknowledge any request that doesn't embody the secret knowledge.
- Another means is to make the existence of the secured entity itself the shared secret.
Each of these challenges has its own strengths and weaknesses; each is appropriate in different situations.
Simply asking the user is the most common method of knowledge challenge. The simplicity and overtness of this method ensures that nobody attempts to access the secured entity without knowing that it is, indeed, restricted; it simultaneously reduces the burden on the persons creating and maintaining the system.
This method is not terribly resistant to attack. Malicious users can monitor communications in hopes of catching another user entering a response, attempt random responses until one works, or use a wide variety of other techniques to guess or obtain a valid response.
For this reason, this method should never be the only means of authentication used in a sensitive system. Other means of identification, including other methods of knowledge challenge, should be used as a secondary verification. While the ubiquitous password prompt is the prime example of this method of knowledge challenge, there are other options, including some of the questions asked during a Diffie-Hellman key-agreement sequence between secure systems.
Refusing to acknowledge any request that does not embody the shared secret is another common method for establishing a knowledge challenge. This method involves establishing the format of the request, the source and/or destination, or some other characteristic in advance.
If a request comes in that does not fit the expected profile, then the request can be ignored, refused, or re-routed. Business-to-business transactions often use this means because each can establish stable source IPs and agree on fixed and obscure formats (obscure to humans).
While this is a fairly effective means of knowledge challenge, it suffers from a serious weakness. If the shared secret is ever deduced by an attacker, the security breach can be exceptionally difficult to detect.
The use of a secret handshake -- common among secret societies -- is one example of this type of challenge. Another example is the use of restricted source-addresses in many B2B systems.
Hiding the existence of the secured entity, often referred to as security through obscurity, is used commonly in the physical realm. This method relies on the fact that it can be difficult to find something if you don't know that it exists.
While this can be an effective technique, it is almost never adequate by itself. The prudent designer will add at least one additional identity check before permitting access to the secured entity, just in case someone stumbles across it unintentionally. In electronic systems it is even more crucial that additional authentication be included, because it is relatively common to use automated search tools to find locations not previously known.
Knowledge challenges on the Java platform
The Java platform provides some interesting support for knowledge challenges and some interesting challenges as well.
The support provided includes a wide variety of cryptographic functions that can both generate highly complex shared secrets and protect those secrets in transit. Additional support is available through the JNDI API (see Resources). This API provides access to directory services, the most effective place to store the shared secrets for knowledge challenges.
The Java platform also provides some challenges for systems that rely on knowledge challenges as well: the Jini network initiative (see Resources) provides facilities for the automatic discovery of systems on a network; the availability of portable code provides additional avenues for would-be thieves; and the wide breadth of the Java platform is adding intelligence to devices that would never have been imagined a decade ago.
All of these capabilities, while enabling solutions to previously intractable problems, also make it ever more difficult to prevent an attacker from obtaining access to shared secrets.
Each of the various methods of knowledge challenge has strengths and weaknesses. All of them, however, share certain common characteristics.
Knowledge is rather difficult to obtain by force, usually requiring extended time and resources to get what you don't know. Knowledge is easy to share -- and change; if the secret is compromised it can be changed quickly to prevent a more serious breach.
The most significant weakness of knowledge challenges is that knowledge is easily copied. The secret can become known to an attacker without the breach being noticed and without harm to any individual. In this situation, an attacker could access a system without anyone knowing for some time. Knowledge challenges are also particularly susceptible to human factors that can significantly compromise the security of the system.
For the above reasons, I recommend that at least one additional means of identification be used for any system with significant value. The easiest, most common, means used in this situation is to challenge the user for something owned.
Keys, badges, credit cards -- all of these objects exist to answer the question "What do you have?"
Knowledge challenges can be both subtle and effective, but they suffer from some fairly serious drawbacks. Token challenges can be an effective means of compensating for those issues.
The defining characteristic of a token challenge is the possession of some physical item. The most common token is a simple key.
The key is constructed such that it is relatively unlikely that any given lock will respond to any key other than the correct one. This is an important point -- token challenges are an exercise in probability. You will have to balance the cost and complexity of the token with the probability that the token can be duplicated or will match another, invalid, token.
There are several varieties of tokens currently available, but each of them operates on one of two principles -- basic storage or active response.
Basic tokens -- also called dumb tokens -- are the most common of all token types. Everything from a door key to a credit card falls into this category. Their central attribute is that they simply encode data in some form.
A key encodes the data in a pattern of ridges or teeth; a credit card encodes it on a magnetic strip. This simplicity is valuable because it makes these tokens inexpensive (usually much less than $1US), which firmly places them in the mass-market realm. Because basic tokens only encode data, however, they are susceptible to counterfeit or bypass.
It is a simple matter for a skilled professional to bypass all but the most complex locks, and it is even easier to access a credit account once the number is known. If you need to defend against this type of misuse, you need a more substantial token.
Active tokens -- also called smart tokens -- are much more complex than basic tokens. Active tokens incorporate some form of embedded intelligence. They are both harder to counterfeit and much harder to bypass than basic tokens.
A smart token can verify its validity by actively changing some provided nonsense value (commonly referred to as a nonce) in a way that, while difficult to duplicate, is easy to verify.
Cryptographic smart cards, common in Public Key Infrastructures, can do this by digitally signing the nonce. This enables the secured system to verify that the token is the same entity that it claims to be. Because active tokens frequently make use of highly unique internal characteristics to modify the nonce -- and because most active tokens will self-destruct if the integrity of their packaging is violated -- active tokens are very difficult to counterfeit.
Because they actively change the nonce, active tokens are extremely difficult to bypass, especially if the nonce changes with each challenge. The difficult-to-bypass feature is why some luxury vehicles now use active tokens embedded in the vehicle ignition key to prevent vehicle theft. If the ignition key doesn't properly authenticate to the engine computer, the engine simply will not run.
One interesting characteristic of active tokens is that they can be permanently installed within a server. Once such a token is installed, it can be used to identify the system to other systems in business-to-business transactions with the same characteristics that make tokens useful in identifying people.
Ownership challenges on the Java platform
The Java platform provides more support for ownership challenges than perhaps any other platform. The most important part of this support is embodied in the JavaCard specifications.
JavaCard specifications describe a platform for Java technology embedded in smart cards. This integral support for smart cards enables Java developers to take advantage of the most effective tokens available within the same familiar platform as their enterprise applications.
Further support from the Java platform is provided by the Java Cryptography Extensions (JCE), the Java technology in the Open Card Framework, and Jini network technology (see Resources) to support automatic discovery of card devices. All major card-reader vendors, as well as most smart-card vendors, provide support for the Java platform and JavaCard technology (see Resources). The reason for such broad support is the vast capability and multi-application flexibility of JavaCard technology and the corresponding benefits in securing a high-stakes system.
There is one major problem with all token challenges. They only verify that the user owns the token involved. Because it is entirely possible for a malicious user to obtain another user's token, it is still possible to misidentify the user.
This problem is alleviated to a certain degrees with active tokens by preventing the counterfeit or duplication of the token and, frequently, by adding a knowledge challenge into the token. However, the problem still exists.
It would be a marvelous security measure to be able to ensure that the individual who possesses the token is, in fact, the unique individual to whom the token was assigned. ID cards, US drivers licenses, and a few credit cards use a picture to perform this function.
Computers need more than a picture, though, and the emerging science of biometrics is providing a solution.
Fingerprints, voice prints, iris patterns, facial geometry, retinal scans -- all of these are means of answering the question "What are your characteristics?"
Biometrics is the science of measuring the unique physical characteristics of individuals. These techniques offer the promise of delivering a long-dreamed-of level of security -- a computer system that recognizes a user more accurately than people recognize each other. The ideal still doesn't exist, but systems are available today that can dramatically increase security by presenting a physical characteristics challenge.
There are different ways to present physical characteristics challenges, but a common thread is that all of these challenges work by reducing a raw measurement -- quite often an image of a face, fingerprint loops and whorls, capillary vectors in the retina -- to a numeric template. Then the system attempts to match the requester template to stored templates until a match is found or all templates have been examined.
Each biometric system possesses a probability rate associated with both failure to reject an imposter and failure to recognize the user. These attributes, called false acceptance rate (FAR) and false rejection rate (FRR), must be balanced to meet the usability and security needs of your solution.
The false acceptance rate describes how frequently the system may be expected to recognize someone incorrectly, allowing access under a different identity. The false rejection rate describes how frequently the system may be expected to fail in identifying a user, refusing access to a user who is validly permitted to access the system.
Many systems permit these two values to be balanced, one against the other. By adjusting how carefully the system checks a template against those stored internally, the FAR can be reduced with a corresponding increase in FRR, or the FAR can be increased in order to reduce the FRR. This ability to adjust the sensitivity of the system is important because higher FRR rates reduce the usability of the system, while higher FAR rates reduce security. If both FRR and FAR are inadequate, then the only option is usually to choose a different characteristic.
Believe it or not, biological characteristics that were once considered to be unique to an individual may not be. Each characteristic has an expected level of recurrence within a population.
One of the more unique biometrics is facial geometry. However, most people have seen two people with faces so similar that they are difficult to tell apart; there are a limited number of ways the face can be expected to form and remain a human face.
Each individual's characteristics will be identical to a certain number of people. Fingerprints are known to be unique to 1 person per 100,000. The pattern of an iris may be unique to 1 person per 10 million.
The uniqueness of the actual characteristic must be taken into account when selecting a biometric for a secure system.
Java technology in characteristic challenges
Java technology is noticeably absent in the characteristics challenge space. The relatively new and untried nature of biometrics is part of the reason for this. Another reason is that biometric vendors have yet to define a standard means of interacting with biometric hardware and this is necessary before the Java platform can offer a language interface.
The one bright light in this situation is that many vendors provide a set of Java classes for interacting with their devices that permit the creation of biometric authentication services for Java applications with minimal difficulty.
Characteristics challenges are generally considered to be the most accurate and reliable of the three primary means of identification. They are not, however, perfect. If you've seen one of those spy movies in which the bad guy (and sometimes the good guy) has whacked off a hand or plucked out an eye just to fool a security system, you'll agree that biometrics systems can be fooled. (In fact, some fingerprint systems can be fooled by a high-quality photograph.)
So, as with all security measures, it is recommended that security system designers consider using as many additional challenges as cost, the human factor, and the system's operation will allow.
I've focused on each challenge type, generally assuming the need to identify human users and not other computer systems. That is not always the case.
Computers may also communicate with other computers over insecure links. When identifying other computer systems, there is considerably more freedom to enable strong security because the human factor can be removed.
Computer systems can:
- Remember the most complex answers to the knowledge challenge
- Possess exceptionally complex active tokens that are permanently installed
- Own unique physical characteristics that can be tested across certain types of network connections
Some of these unique characteristics can include the phase-frequency characteristics of the network transceiver or the frequency variation of their internal crystal oscillator.(And, though these characteristics sound quite exacting, each possesses the same benefits and weaknesses that apply to identifying people.)
The greatest advantage when authenticating computer systems is that the smaller number of systems means you can use much more complex techniques without much concern for unit cost.
Another advantage is that computers never complain about usability, so multiple challenges can be issued without concern and characteristic challenges can be adjusted to maximize FAR without fear that the resulting high FRR will cause users to stop using the system.
When dealing with high-stakes systems, a single identity challenge or challenge type is usually not secure enough. When the security needs of a system exceed the security available with one challenge type, it is necessary to implement multiple challenges. Figure 1 ranks the approaches for security.
Figure 1. Best to worst rankings of all approaches
Both of the most common multiple-challenge duos involve the knowledge challenge -- using it with a characteristics challenge and with a token challenge. (Why is the knowledge element the common thread? Simple -- it is the easiest to carry, implement, and use.) While these two combinations certainly improve the security of a system, they are not the most secure.
The most secure combination is to use all three challenges. The next most secure is to combine token and characteristic challenges by storing the characteristic on an active token and having the token validate the characteristic before authenticating to the secure system; adding the internal biometric template into the response to an authentication challenge makes this even more secure. Having a token authenticate a biometric is not possible with most current active tokens, but it is expected to become possible within two product generations.
Some users cannot provide an answer to all challenge types. If making your system accessible to as many valid users as possible is important, then it is important to implement multiple challenge methods while requiring that only one challenge be met.
For example, some cannot respond to a fingerprint challenge due to a lack of fingers. For these people it would be wise to permit a token challenge so that they could still use the system. Some users, due to injury or youth for example, cannot be expected to remember an adequately complex shared secret. For these users a characteristic or token challenge would enable them to use the system without having to remember a complex shared secret.
The key concept is that the designer must take into account those persons who may not be able to work with the selected system, then determine if the security concerns outweigh the needs of those persons to access the system or if another challenge type should be implemented for them.
Authentication with the Java 2 platform
The Java 2 platform provides one of the most comprehensive sets of APIs for accessing the various means of identification available. The Java platform further provides a service API for interacting with various authentication systems, the Java Authentication and Authorization Service (JAAS) API. With this API, you can implement your high-security authentication as a service provider and allow JAAS to provide the general interface to applications that want to use that means of authentication.
The Java Cryptography Extensions provide a number of methods for working with knowledge challenges to both generate shared secrets and to reduce the chance of those secrets becoming available to attackers.
The JavaCard standard provides APIs and an environment specifically designed to run within an active token, as well as enabling the designer to provide identification, information, and a variety of other services for multiple secure systems all within a single active token.
There aren't any specific APIs that support characteristic challenges yet, but most biometric vendors provide a Java-language interface.
- Details regarding IPSec key-agreement protocol can be found in the IETF document RFC 2409.
- Details regarding the IPSec protocol set are at the IETF Web site.
- Security magazine provides a wide-ranging discussion covering many security techniques and technologies, including computer security in high-stakes systems.
- The United States Navy hosts a number of security-related forums, including the Center for High Assurance Computer Systems.
- Princeton University has a research effort on Secure Internet Programming.
- The Electronic Privacy Information Center is an excellent source for information on privacy issues.
- The United States National Institute of Standards and Technology hosts a high-quality security resource center.
- The Computer Security Institute is always an excellent source for security issues.
- IBM offers the SmartCard Security Kit for those interested in key-based security options for desktops and portables.
- The Java Authentication and Authorization Service is a Java API that lets services authenticate and enforce access controls on users. There is more on JAAS in this white paper, "User Authentication and Authorization in the Java Platform."
- The Java Cryptography Extension provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code algorithms.
- Download JavaCard Developer Kit and enhance your Java security.
Joseph Sinclair is a Solution Architect with Integrated Information Systems, Inc. in Tempe, Arizona. He has been working with computers and microelectronics in a wide variety of roles for well over 10 years. You can contact Joseph at JosephS@iisweb.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
