D5.2b: ID-related Crime: Towards a Common Ground for Interdisciplinary Research

Title: IDENTITY MANAGEMENT

A second way of limiting the risks of ID-related crimes, is identity management. Both in online- and offline transactions, users are asked, and tend to reveal significantly more information than necessary for the transaction. If a user is requested to prove she is over 18 years of age (for example to get access to a bar), she normally has to present her identity card, which reveals her exact birthday, full name, address, and various other data that are of no relevance to the patron of the bar. Worse, Internet sites that demand a proof of the user’s age tend to obtain this by demanding a credit card number (assuming that only 18 year olds have credit cards). It is obvious that such a situation is paradise for identity thieves, who can obtain volumes of information about a user by simply claiming to check her age. 

One of the main means in protecting a user’s identity from being stolen is to be as restrictive as possible with revealing identity related information. In each transaction, the transaction partner has to be provided with exactly the information needed to complete the transaction, and nothing more.

Identity management systems typically provide one or more of the following capabilities. 

A pseudonym system allows a user to use different, unlinkable identities for different transactions. A simple, homemade way

There are a number of open issues involved to maintain the unlinkability of the pseudonyms, especially at the interface between the Internet and the real world. For example, a user may still want to be able to pay for a service. Although some credit card companies work on one-time credit card numbers, this usually still requires a unique link to the user.  

Also, there are attacks possible on the lower protocol and network layers; while different email addresses can help against an attacker that tries to obtain information about a user by means of search engines, users still tend to access all their accounts from the same computer. Unless anonymous network access is provided, a sufficiently sophisticated attacker can abuse this to determine the link between the pseudonyms. Even the fact that many private users make use of randomly assigned IPs (by ISPs), this no longer guarantees unlinkability given the fact that even low level TCP/IP messages contain unique fingerprints due to machine specific delays (Kohno et al 2005).  

Finally, the main task a good pseudonym system has to do is to help a user to manage all her pseudonyms – if users take their anonymity seriously, they will have more pseudonyms than transaction partners, which is more than one can expect a person to handle. A nice example for such a system is the cookie cooker, a local web proxy that generates and manages passwords, removes traces (such as cookies), and even fills out web-forms with plausible fantasy data. 

A Credential System (e.g. Camenisch and Lysvanskaya 2001) assists a pseudonym system if the user is supposed to prove that she satisfies some properties. Suppose again that a website requires a user to prove she is over 18 years of age. If pseudonyms are used, the user would need some trusted entity to certify that this pseudonym belongs to a person age 18 or higher, and she has to be prevented from “lending” her pseudonym to a third party. With a credential system, a user can get credentials on certain properties, and later prove possession of those credentials without revealing any user related information. This property allows the user to prove properties independent of the pseudonym she currently uses; all certification has to be done only once. Instead of showing the credential (i.e., a signature from the credential issuer) itself, the user can prove that she knows this signature. Using new zero knowledge techniques, this can be done in a way that the verifier at the end is convinced she knows the signature, without having any more information about it. Especially, if the same user is to show the same credential again, the verifier will not be able to link the two credentials to the same person. 

Trusted Platform Module

While a number of techniques exist that allow a user to authenticate herself, most of these techniques come with a number of problems. Unless an authentication device is used that has some computing power on its own, a user transmits all information needed for the authentication every time the authentication process is required. This allows a rogue to obtain this information not once, but every time authentication takes place. This makes often used identifiers, such as credit card numbers and the American social security number particularly vulnerable for misappropriation, and hence if someone presents these data it actually does not authenticate at all as virtually anyone may have obtained the data. Furthermore, some authentication information carries sensitive information; an iris scan, for example, may reveal information on the user’s health status. Even if smartcards are used, the problem is not solved; as smartcards can easily be lost or stolen, secondary authentication is needed if this technology is used. 

Figure . Keys managed by the TPM.

Trusted Computing is a relatively new concept that can assist current authentication methods by securing the infrastructure used for authentication. The essential goal of this technology is to create trust in computing platforms (which may be Personal Computers, but also smartcard readers). To this end, a consortium of about 100 major IT companies has defined a standard for an small, cheap, and more or less tamper resistant security module (Trusted Platform Module, TPM). This module can protect keys, execute some cryptographic functions, and – most importantly – can attest some information about the platform to outside parties.  

Secure key storage

A TPM can – comparable to a smartcard – securely store users’ keys. As a TPM is platform rather than user bound, and may be utilized by various applications, the number of keys it has to maintain can be rather high. As the chip has to be as cheap as possible, while permanent storage of keys on such a chip is rather expensive, this presents designers with contradictory requirements. To solve this problem, the TPM does not store all keys in its internal memory. Rather, it stores one master key (the Storage Root Key, SRK), which is generated once the chip is initialized (owned) by the user.

Each key is stored alongside with a number of properties that define its usage. Most prominently, a key can be marked as migratable or non-migratable. The later keys are bound to the platform, and cannot be copied anywhere else; it is impossible to steal such a key (even with the users consent) without stealing the entire computing platform.

Self- and remote authentication

One of the core ideas in the trusted computing concept is that the TPM offers trustworthy information on what is going on a user’s machine. Currently, every attacker that gains access to a machine can make himself at home there – tools exist for both Windows and Linux to create backdoors that are practically undetectable. Thus, even if the keys are protected and cannot be removed from the platform, the attacker can freely use them at any time (provided he stole the authentication information as well). 

In the TCG (Trusted Computing Group) concept, the BIOS (and ideally, the operating system as well) report checksums of the start-up sequence to the TPM, which stores them in a secure way. By the time a malicious application gains control, its existence has already influenced the checksums stored in the TPM, which allows detection of the imposting code. To utilize the checksums, the TPM can now sign and output them (which can be used to convince an external party that the platform has not been compromised). Also, it is possible to seal keys with these checksums; if the platform does not boot into the state defined at key generation, the TPM will refuse to use the corresponding key.  

ID-Management

As mentioned previously, one of the prime weapons against identity theft is the use of pseudonym systems – if a user can prove attributes (e.g., being over 18 years of age) without revealing any other information relating to her identity (e.g., her address or credit card number), it becomes much harder to carry out identity theft. The TPM can be used to provide for the proper credentials to facilitate this scheme. 

For privacy reasons (and as a result of the bad experience with Intel’s processor serial numbers) the TPM has two build in mechanisms to support pseudonyms. 

The first mechanism is rather straightforward and uses a trusted third party (TTP). The TPM sends its certificates, a pseudonym, the public EK and auxiliary data to the TTP. The TTP then verifies the data and issues a certificate for the pseudonym. This certificate is then encrypted using the public part of the endorsement key, so that only the TPM can decrypt it. The result is a pseudonym that is not linkable to the identity of the TPM by anyone but the TTP, but cannot be used by anyone but the TPM. 

Figure . Use of pseudonyms certified by a Trusted Third Party and encrypted using the TPM

As a second mechanism, especially to handle pseudonyms in situations where no trusted third party is available, the latest version of the TPM specification also defines a zero-knowledge based protocol to maintain pseudonyms, the Direct Anonymous Attestation protocol. This protocol allows the TPM to prove that it is a real TPM without revealing its identity to any party at all. In principle, it is thus possible to obtain certificates and create pseudonyms without revealing ones real identity even to the issuer. Unfortunately, as the protocol is not designed to demonstrate anything but the origin of the TPM, the actual implementation of such a scheme still requires some research.

Shortcomings

Key migration 

If a key is marked as non-migratable – which may well be the case for critical identity related keys -

A related problem is a user who uses multiple platforms, for example a home PC, a laptop and a cell phone. As the keys are bound to a platform rather than a user, some auxiliary mechanisms may be needed for roaming users. 

Key revocation 

As mentioned above, the TPM does not store most of its keys itself, but delegates this task to the operating system. While this helps to keep the costs down and allows for a practically unlimited number of keys, it also takes away some control over the keys – mainly, the TPM is not capable of reliably deleting keys unless it deletes the Storage Root Key (and thus renders all keys maintained by that TPM useless). For individual keys, however, anyone who has a copy of the encrypted key, the necessary authorization information and access to the TPM (which is well plausible for a machine with several users) can use this key. 

Secure operating systems 

While Trusted Computing can be used to solve a lot of issues around device security, it is still insufficient as long as the higher level operating system is insecure. The whole design only makes sense if used as the lowest security layers, with further secure systems building on top of it. The next step towards real security is to build a Trusted Computing enabled microkernel operating system (as done, for example, in the European Multilateral Computing Base). Those systems can provide users with a trusted viewer (so they know, they authenticate to the system, they think, they authenticate to, unlock their smartcard, they think etc),   which can not be interfered with by other applications running on the same machine.