TurboTas often looks longingly at those secure athenticators from the
likes of RSA or PassGo and thinks that they would massivly enhance
security for online transactions. The expenseof the authenticators puts
them way out of reach for off-the-shelf use though – typically the low
end devices start at £50.
As if that were not off-putting enough, the back end libraries are
proprietary, expensive and don’t necessarily interface very well with
backend systems.
It occurred to TurboTas in the present climate of Open Hardware
design, an open authenticator would not be that hard to design and
produce. More importantly, not that expensive to produce in volumes
either.
The logic goes that if the hardware specs and more importantly
the algorithms were public, then implementation could be left to
individual systems designers/programmers. Application programmers could
write their own code.
Let’s take as an example a hardware authenticator without a PIN
number. The device just cycles through a 6 digit nuber every minute or
so or on response to a button press on the outside of the authenticator
Okay, clearly I’m just making this up as I go along here….
The Authenticator has a reasonably accurate clock (This is
pretty fundamental!). Accurate clocks are not hard these days. Accuracy
to within 15 seconds over the expected 4 year battery life would be
fine.
The authenticator has an internal Identification number (Lets
say 6 bytes for now) and an externally visible serial number. The
numbers are unrelated but at supply time, the internal number and external number are listed
In software, the device runs a very simple (!) process every
minute: It takes the present date and time (dumping the seconds),
appends the internal serial number and produces a one-way hash. This
hash is then reduced using some algorithm to a user friendly 6 digit
number which is in turn displayed to the screen. Something like
28/06/2004 14:23:21 A56FB3A8C0
>2806200403A56FB3A8C0
>23AB76B5A69AD5E8C01BA9D4
>673633
This is passed to the server along with regular credentials in
whatever form are required by the application. At the server end, the
process is repeated (perhaps for 3 timeslices to allow for user
delays/timeslip) and the server can reproduce the 6 digit number that
the authenticatr displayed. Simple check against that provided and
bingo….
The key here is that it is left up to the systemdesigner to
decide how much security is needed: The designer may siply run all the
checks against all the registers tokens and allow the user in if there
is a match (or work out who they are the same way).
Perhaps a 4 digit pin appended to the authenticator number
would give single field signon: 6736331234. Allt hings are possible
once the standard is open.
Addendum: It _may_ be possible to brute the time against serial
numbers, particularly a known ciphertext attack where the time can be
worked out and the auth number is sniffed. To counter this there are
two techniques which occur.
Firstly, authenticator serial numbers should be assigned is a pseudo random fashion at construction time.
Secondly, to mitigate known time attacks it may be pudent to
ship the units in an unpowered state. Time that the unit is activated
would be recorded and the unit internally uses a count from zero timer.
This adds a further stage of lookup on the server (The process has to
have available the time the authenticator was powered).
To give system or organizational security, it may be possible
to set an internal secret string in all tokens which is also used at
Hash calc time.
Althoughy by no means perfect, this approach at least has the
benefit of being open and extensible. The key security tennet is that
it’s hard (Hopefully)( to reduce a hash back to the numbers used to
generate it).
Authentication processes – of course – must take the burden of lockout etc, but the scope is better
Users could purchase their own token and supply relevant credentials to application providers (Serial number, Activation Time)
Further development could see token with 4 buttons: Each button uses a different key.
I Think it’s pretty smart…
Relevant hashing algorithms are: MD5 and SHA although less computationally intnsive ones could be used if necessary.
A second hashing function is needed to reduce the 160 bits down to 6 decimal digits
TurboTas 2004