Australian "calculatorcard"

[amp]

-- [ From: amp * EMC.Ver #2.3 ] --

From: Vin McLellan             \ Internet:    (vin at shore.net)

> 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.

VM>        Actually, all ACE/Server or ACE software modules _require_ a
VM> user-memorized PIN.  Physical possession of a stolen token is not
VM> 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.

VM>         Bleep!  Earth to amp! Check your voltage, lately?  The token's
VM> serial number has nothing whatsoever to do with the generation of a
VM> SecurID's PRN token-code.

hmmmm, let me see... yup. you are right. voltage low. give me a
second to plug back in...

VM> and distribution.  The serial number stuck to the back of a SecurID
VM> after it is programmed with its secret key -- a unique PRN
VM> "significantly longer" than 56 bits -- but they are not the same
VM> thing.  The cpu in a SecurID doesn't even "know" the serial number
VM> stuck on the back of the token.

VM>         (It would be Pretty Stupid <TM> to glue or emboss a secret on
VM> the back of the damn token, wouldn't it?)  I should note that Alan is
VM> just regergitating one of the most widely circulated  rumors about
VM> SecurIDs -- which like any popular crypto device attracts a lot of
VM> wiLd & w00ly speculation.

actually, i was speaking pretty much off the top of my head. it's
been a while since i registered it, but all i basically had to tell
the server the first time i used it was the s/n. and yes, i think it
would be Pretty Damn Stupid to have the s/n have anything to do with
the actual seed or pin. 

VM>         Getting the algorithm for SDI's one-way hash is no big deal,
VM> given that it sits in software in thousands of SDI customer
VM> installations, protected only by contract and trade secret status. 
VM> (The integrity of the product -- the unpredictability of the
VM> token-code PRN series, and the secrecy of a specific token's seed or
VM> key -- rightly depends cryptographic strength of the hash, not the
VM> secrecy of the algorithm.)  Getting a token-specific secret key would
VM> hopefully be a much greater challenge.

one would certainly hope so. <g> personally, i like the card. it
offers pretty good security and thus gives me remote access to
systems my employer would otherwise laugh in my face for access to
(and did, more than once before we got these things). its main
weakness would be a black bag job where someone gains physical
posession. at that point, all bets on its securty are off for obvious
reasons. luckily, because of the nature of the device, i can simply
report it as stolen and it quickly becomes a rather worthless piece
of silicon.


amp
<0003701548 at mcimail.com> (since 10/31/88)
<alan.pugh at internetmci.com>
PGP Key = 57957C9D
PGP FP = FA 02 84 7D 82 57 78 E4  E2 1C 7B 88 62 A6 F9 F7 
December 31, 1995   22:15