Browse Prior Art Database

Sign-on/authorization using WLAN enabled mobile phones Disclosure Number: IPCOM000029070D
Original Publication Date: 2004-Jun-15
Included in the Prior Art Database: 2004-Jun-15
Document File: 3 page(s) / 50K

Publishing Venue



This article relates to a sign-on / authorization process using WLAN enabled mobile phones.

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

Page 1 of 3

Sign-on/authorization using WLAN enabled mobile phones

Access to computer systems, network services, world wide web services and other systems for various reasons often needs to be controlled and only possible for authenticated individuals: for example, confidential data have to be protected, access to pay-per-use services or subscription services has to be granted, or financial payments have to be authorized.

A common approach is the use of secrets: to authenticate herself the user of the service has to prove that she is in possession of a secret token. Often the secret token is a password that the user has chosen before or that has been assigned to her; in its crudest form the authentication process consists of the user entering her name - often called user identification or user ID for short - and her plain-text password which approach is, for example, used with the Unix terminal login process as well as for a number of interactive Internet services such as telnet, rlogin but also for Internet services such as the POP3 mail retrieval service. The advantage of such approach - easy to implement - presents at the same time its biggest disadvantage: The authentication information is revealed everytime the service is invoked; while this might still be acceptable for loggin in at a PC or laptop system, when done over an unprotected network connection essentially everyone with access to the network can "listen in" and retrieve all necessary information to steal the identity of the authentic user.

A more secure solution uses public key cryptography to carry out a challenge--response protocol with the user, respectively, a device under control of the user: the public key of the user is known and stored on the service providing system, which system is also called service provider for short. To authenticate the user, the service provider generates a random string sequence - also called "challenge" - and sends it to the user; the user encrypts the challenge with her private key and sends it back to the service provider - this process is also called "response"; the service provider can now use the known public key to decrypt the received response and verify that the decrypted response is the same as the challenge that the service provider generated earlier. Thus, the user has proven that she is in possession of the secret private key --- but in contrast to the plaintext password solution, she did not have to reveal her secret. As only the authentic user has the private key associated with the known public key, only she can encrypt the challenge to produce a response that can be decrypted by her public key. To prevent man-in-the-middle attacks a two-way challenge--response exchange can be carried out.

As the challenge--response based authentication solution is much more secure than the plaintext password system, it's being used increasingly for authenticating users. However, as it irequires a series of cryptographic operations - such as publ...