Siemens has implemented authentication servers (ACE Server) and tokens (SecurID) from RSA Security Inc. as the authentication mechanisms. More information about their products can be founds at www.rsa.com.

A SecurID is a "smart" token. It contains a full CPU: a microprocessor, memory, and an output display. Machine intelligence allows the token to hold on to its secrets (since the microprocessor is designed to erase its memory if the token's casing is breached or otherwise subject to attack.) The microprocessor also allows the token to be an active, rather than merely passive, device, and to generate a unique one-time password (OTP) each time the token is used.

Built into the face of a token's sealed casing is a small LCD screen, which displays -- automatically, continuously, and apparently unpredictably -- a "token-code" which changes every 60 seconds. All SecurID tokens are capable of providing continuous token-code displays for up to four years, roughly four to eight million sequential calculations -- but each is also programmed to self-destruct at a pre-determined hour and date, chosen by the buyer.

The token-code displayed by a token is a pseudo-random number (PRN.) That is to say, no one can calculate, guess, or otherwise determine the next or future token-codes from a record of past token-codes. In mathematical terms, it is computationally unpredictable by someone who doesn't know the numbers that were used as input for the so-called "one-way function," the proprietary hash algorithm that calculates the token-code.

The user interacts with a remote authentication server capable of processing the tokencode -- in a procedure that is both elegant and simple.

There is no "token-reader"; no special hardware; no wires; no plugs. The process depends upon the user it authenticates to submit the token-code to an authentication server via a standard workstation keyboard. When a user wishes to access a restricted computer, he submits his name (or an employee number) and then -- just like a long traditional password -- he types in his PASSCODE: in sequence, his memorized PIN ("personal identification number") and the token-code currently being displayed on his token.

At the authentication server, if the user's PASSCODE (PIN and token-code) is found to be valid, timely, and current, the user's claim to an known and authorized identify is acknowledged and authenticated.

The authentication server knows the security algorithm and current time, and has a database record of the secret key (the numeric "seed") used in this particular token. When it receives the authentication call, it retrieves the user's PIN from its database and independently computes the token-code for that user's token -- for this moment in time. It then matches the computed token-code, and its record of the user's PIN, against the two-part PASSCODE being submitted to it. A token-code is valid but once, and then only for a very brief interval.

Once authenticated, the user is then given access to system or network resources -- subject to any additional restrictions the system administrator may have placed on that user's privileges.

Literally, a "Personal Identification Number." The term PIN is widely accepted as referring to a digital or alphanumeric password. For this service the PIN is the first part of a two-factor authentication process. A user's PIN is between four and eight characters long. A PIN can contain any alphanumeric characters.

Human nature being what it is, a person can make the same mistake an indefinite number of times. However, the authentication server will automatically disable any user account when it has received ten consecutive invalid token-codes...even when it is accompanied by a valid user's PIN.

No. A stolen token alone will not allow a thief to gain illicit access to a protected computer or network. If, however, a thief can obtain the Internet URL, the user's PIN, and the token, then he can successfully masquerade as the legitimate user and gain access to restricted system or network resources.

No. A PIN alone is useless. A thief (or wiretapper) must also obtain the user's token to gain illicit access to resources protected by an authentication system.

If the authentication server detects repeated login attempts with an invalid PIN but valid token-codes, the system assumes that an unauthorized user has obtained the token and is trying to guess the user's PIN. After receiving three invalid PINs (with valid token-codes,) the authentication server automatically disables the token.

Yes, it can. A token in daily or regular use is constantly reporting to the authentication server on the relative "drift" of its clock (i.e., whether it is slower or faster, as compared to the system clock.) When a token is not used for months, sometimes only weeks, however, the authentication server may lose track of the drift in a token's clock-chip.

A PASSCODE which uses an out-of-range token-code is never be accepted as valid, but every authentication server has a programmed routine to minimize the number of "false rejections" for valid but little-used tokens. If a particular token has not been used recently -- and if the authentication server receives a valid PIN with an invalid token-code -- the server will automatically run a search program to determine if it has lost track of the "clock drift" for that particular token.

If a match is found in Search Mode, it sets up the user for a subsequent request for another token-code from his token. The server updates its database (on the relative drift associated with that token) and requests another token-code from the user. That second token-code is then used in a new formal authentication cycle.

If the user is then authenticated, the two sequential token-codes allow the server to re-synch (in the server's database) that token to the system clock supporting the authentication server.

With a big enough hammer, you can break anything. The token is designed to terminate itself and erase its stored data if it detects any attempt to breech the token's sealed casing or if it detects any one of several other potential physical or electronic attacks on the token.

Yet, even so....the purpose of any security system is to raise the cost (in time, money, skill, and technology) of penetrating it to a point sufficiently high to make a technical attack on it unlikely, unreasonable, and obvious (at least to the victim, in this case, the assigned user). A SecurID token does this.

Penetrating a token to obtain its secrets would likely be a time-consuming and intricate task -- and the token-holder's report of a lost and stolen token would invalidate and make worthless anything that could be obtained if the token was opened and its secrets somehow salvaged.

The internal secrets of one token might possibly open up that user's on-line account, with whatever privileges he has - but nothing learned in such an attack would directly aid the bad guy to penetrate other users' accounts...certainly not those which are protected by other tokens.

Anything is possible, given a major investment in the task -- but to the knowledge of RSA Security Inc., it has never been done successfully.

A token that is not functioning properly can be returned to Siemens for a replacement as long as it is still under warranty. (The expiration date should be listed on the back of the token.)

A token that has physical damage to the case, i.e. the key ring holder is broken or the LCD screen is cracked, is NOT covered under the warranty.

Please return the (safely packaged*) token(s) to:

Siemens Health Services
51 Valley Stream Parkway
Attn: Larry Concio, Mail Code C05
Malvern, PA 19355

* Ensure the token(s) is (are) protected from physical damage as there can be no distinction between damage caused prior to shipment and damaged incurred while in transit.