Re: Australian "calculatorcard"

Cees de Groot (cg@bofh.toad.com) tore himself from the tube to tell us: CG> Yesterday, on UK Discovery, there was an item in the programme CG> Beyond 2000 about an Australian card which implements a CG> challenge-response protocol and can be used for banking, etcetera. CG> Basically, you give your card number (over the phone), get a CG> challenge number, enter your pin and the challenge, and then give the CG> response. All in CC format... Could be one of seven or 8 vendors of so-called "challenge/response" tokens or calculators. Most of those sold in the US and Australia use straight DES (and a token-specific key) to encrypt the "random" challenge number in the token -- but it could be any secret-key algorithm. Actually, the particular environment described -- phone authentication -- is often used as the most notable example of a market where so-called "time-synchonous" tokens hold a notable advantage over challenge/response token. A TS token generates its pseudo-random token-codes continuously and automatically: no buttons, no input. With TS tokens, exact time and a token-specific key are used in a keyed hash to generate a token-code displayed on an LCD on the token for 30 or 60 seconds. The authentication server uses its database record of the token-specific key, time, and the hash to generate the same token-code for a match. This allows a PIN and token-code two-factor authentication to be submitted by touch-tone phone, and it avoids a lot of the hassle (listen/tap/calculate/touch-tone) associated with C/R authentication. As amp <Alan.Pugh@internetMCI.COM> noted, the most prominent international vendor of time-synch tokens is a US firm called Security Dynamics, Inc. I've done consulting projects for SDI, off and on, for years.
sounds like the card i use for remote dialup to certain non-public systems i use at work. it has a six digit number on the front that changes every 60 seconds. the card is registered to me. when i enter my username/password i'm prompted for the number.
SDI's token is called a SecurID. <http://www.securid.com> SDI uses a <sigh> proprietary hash. The most common app uses a SecurID in a protocol which prepends the PIN, in the clear, to the PRN token-code. (In client/server environments, of course, all communication between an SDI ACE/Client and the ACE/Server is fully encrypted.) SecurIDs can also be loaded with up to three different seeds or keys -- with a pressure-point in one corner to switch between each series of key-based PRNs. For greater security in open networks, SDI sells a PinPad token with a keypad that allows a PIN to be "added" to the PRN token-code -- so the LCD displays a 6-8 digit number (or alphanumeric) which still offers two-factor authentication, without exposing a PIN.
it's Pretty Good (tm) security, but like anything not biometric, it is vulnerable to black-bag attacks. physical possession being all that is required.
Actually, all ACE/Server or ACE software modules _require_ a user-memorized PIN. Physical possession of a stolen token is not enough to gain illicit access.
if you know the algorithm and the serial number of the card and the time, even that isn't necessary.
Bleep! Earth to amp! Check your voltage, lately? The token's serial number has nothing whatsoever to do with the generation of a SecurID's PRN token-code. Just because SDI ships its SecurIDs pre-loaded (most token vendors ask the buyers to program their authentication tokens) SDI embosses a serial number on the back of the token to manage shipping and distribution. The serial number stuck to the back of a SecurID after it is programmed with its secret key -- a unique PRN "significantly longer" than 56 bits -- but they are not the same thing. The cpu in a SecurID doesn't even "know" the serial number stuck on the back of the token. (It would be Pretty Stupid <TM> to glue or emboss a secret on the back of the damn token, wouldn't it?) I should note that Alan is just regergitating one of the most widely circulated rumors about SecurIDs -- which like any popular crypto device attracts a lot of wiLd & w00ly speculation. Getting the algorithm for SDI's one-way hash is no big deal, given that it sits in software in thousands of SDI customer installations, protected only by contract and trade secret status. (The integrity of the product -- the unpredictability of the token-code PRN series, and the secrecy of a specific token's seed or key -- rightly depends cryptographic strength of the hash, not the secrecy of the algorithm.) Getting a token-specific secret key would hopefully be a much greater challenge. CG> Can anybody provide me with pointers to more in-depth information CG> about this device and the algorithm(s) behind it ?
i don't know if there are any net sources for them, but i'd be suprised if not. my card references "security dynamics" of cambridge massachusetts.
Suerte & Happy New Year to all, _Vin <*><*>< Vin McLellan + The Privacy Guild + vin@shore.net ><*><**> Heed, fellow citizens, Justice Felix Frankfurter (Butler v. Michigan): "The State insists that, by thus quarantining the general reading public against books not too rugged for grown men and women in order to shield juvenile innocence, it is exercising its power to promote the general welfare. Surely this is to burn the house to roast the pig.... The incidence of this enactment is to reduce the adult population of Michigan to reading only what is fit for children."
participants (1)
-
vin@shore.net