Re: Australian "calculatorcard"

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

From: David Lesher             \ Internet:    (wb8foz@nrk.com)

To:   amp                      \ Internet:    (alan.pugh@internetmci.com)
cc:   Cees de Groot            \ Internet:    (c.degroot@inter.nl.net)
cc:   cypherpunks              \ Internet:    (cypherpunks@toad.com)

Subject: Re: Australian "calculatorcard"

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

DS> Do these card systems use a window to handle clock-slip?

i'm not sure. i would image so.

DS> I'd think you could have the server safely accept # N, N-60 sec, and
DS> N+60 seconds; and adjust the server's idea of your card's clock speed
DS> from that.

DS> What new risk would that create?

i would figure the server would give a minute or so for slippage.
basically the risk is that it would give someone 3 minutes to do a
brute force attack rather than one. if you have decent security on
the server side, i.e., disallow the card for 5 minutes or more after 3
or so failed attempts, brute attacks would be minimized. however, if
the actual window for a single code is 3 minutes, that increases your
chance of hitting it as 3 separate numbers would be valid for a given
card at any given time.


amp
<0003701548@mcimail.com> (since 10/31/88)
<alan.pugh@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   21:59

On Mon, 1 Jan 1996, amp wrote:

> DS> I'd think you could have the server safely accept # N, N-60 sec, and
> DS> N+60 seconds; and adjust the server's idea of your card's clock speed
> DS> from that.
> 
> DS> What new risk would that create?
> 
> i would figure the server would give a minute or so for slippage.
> basically the risk is that it would give someone 3 minutes to do a
> brute force attack rather than one. if you have decent security on
> the server side, i.e., disallow the card for 5 minutes or more after 3
> or so failed attempts, brute attacks would be minimized. however, if
> the actual window for a single code is 3 minutes, that increases your
> chance of hitting it as 3 separate numbers would be valid for a given
> card at any given time.
> 

    START <attila>

	Bank wire systems over the SWIFT private wire are time synched
    much closer than a minute although I have never been given more of
    an answer than that.

	given that you have a tolerable high speed link, and are not
    dealing with an overloaded concentrator at the telco -> carrier
    inferface or an overloaded server, I believe you can solve most
    of the windowing problem by:

	1.  client sends number and time to server
	2.  server send what it thinks as time to client
	3.  client can place a delta on servers time for local time
	4.  enter PIN, etc. and you are working with a much narrower
	    window.

	the security risk does not appear to increase from the 
    exchange times and entering the PIN and letting the normal
    progression go forward once v. just monitoring a series of
    successive verifications trying to effect a pattern in the
    hash.

	Secure-ID seems to be a one-time time-based single use
    pad; to me, using a time exchange initiator has the advantage
    of a smaller window, and fewer problems with client machines
    running on strange times which require sloppier time windows.

    END <attila>