Browse Prior Art Database

Electronic authorization tokens and how to maintain trust into verifying terminals

IP.com Disclosure Number: IPCOM000194139D
Publication Date: 2010-Mar-18
Document File: 6 page(s) / 37K

Publishing Venue

The IP.com Prior Art Database

Abstract

Consider a user employing an electronic authentication token such as an electronic identity card at a terminal to authenticate. Thereby the card transmits information about the user to the terminal. Such tokens often stores substantial (private) information about the user. When authenticating to the a terminal, the card should however transmit only the information that is necessary for the transaction, e.g., when the user needs to prove that she is of age, the card should only transmit that the user is at least 18 years old, but not her birthdate or even her name and address. Unfortunately, such authentication tokens do typically not have a display and hence the user needs to trust the terminal that it does not ask the card for more information that what is necessary, i.e., the terminal could display to the user that it askes the card to confirm that she is older than 18 years but in reality demands the full information about the user (name, address, sex, etc) from the card. We present a method that allows the user to nevertheless verify what information about her the terminal had requested from the card. The main idea is that the card records transaction details so that the user can inspect them later on in a different environment. The assumption here being that the different environment can be trusted (e.g., at home) or at least has no incentive of cooperation with the enviroment in which the transaction was conducted and hence would display to the user correctly the transaction details for verification. 

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Page 1 of 6

Electronic authorization tokens and how to maintain trust into verifying terminals

Electronic authorization tokens and how to maintain trust into verifying terminalsElectronic authorization tokens and how to maintain trust into verifying terminals

Electronic identification tokens are being deployed in more and more cases, including electronic identity cards, drivers' licenses, toll systems, and e-tickets.

At the core of

many of these transactions is an issuer issuing the tokens (or the certificates stored on the tokens) to users, the users, and some verifying party. The user use the tokens to convince the verifying party of some properties about themselves, e.g., that they are a Swiss citizen, they have bought a tickets, are able to drive a car, or are old enough to be served alcohol. Thus, the tokens store and transmit (certified) personal information about the user to the verifying parties. It has been recognized that in many scenarios, it is vital that the privacy of the user be protected, i.e., that only the minimally necessary information about the user be leaked and protocols and mechanisms have been developed (e.g., IBM's identity mixer....) that allow one to implement such
authentication system in such a way that the cards transmits to, e.g., the bar tender that the user is indeed older that 16 years without any other information that could possibly be used to identify the user.

Now, such electronic identification tokens do typically not possess any user interface

whatsoever as that would render them too expensive. Thus,

token, e.g., at a bar, the user cannot tell whether the token transmits all personal data stored on the card or only the information the user expects the token to transmit (resp.

whether the verifying party requests under the hoods more information from the token

that it has ask the user to provide). This is because the only interface the token typically has is through the verifier. Thus there is a need for a method that allows the user nevertheless to gain trust and to inspect after the fact that the verifier indeed behaved correctly.

The main idea here is that the cards records transaction details so that the user can inspect them later on in a different environment. The assumption here being that the different environment can be trusted (e.g. at home) or at least has no incentive of cooperation with the environment in which the transaction was conducted and hence

would display to the user correctly the transaction details for verification.

We envision different possibilities:
a)

Verification place

a1) verification of the last transaction on the current terminal (this might be sufficient in practice, but needs to be done such that the current terminal does not learns/remember the last transaction). In many cases one can actually assume that most (or all) terminal

will be trustworthy, but the user can of course not verify that - still it would be sufficient if

most terminal are indeed trustworthy to detect...