Re: Pin generation algorithm question
From: David Eather (eather_at_tpg.com.au)
Date: 04/24/04
- Next message: Douglas A. Gwyn: "Re: Odd little factorization result"
- Previous message: Peter Fairbrother: "Re: Public Key, Set-(bi)partition"
- In reply to: Peter Fairbrother: "Re: Pin generation algorithm question"
- Next in thread: Ernst Lippe: "Re: Pin generation algorithm question"
- Reply: Ernst Lippe: "Re: Pin generation algorithm question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 24 Apr 2004 12:21:45 +1000
Isn't this a hash function problem?
To manufacture the cards:
Generate a long secret key at random (128 bit would be ample). Also
generate a batch number for the card - this should be an nonce - it has to
be unique to each particular batch of cards. Associate this batch number
with generated secret key.
Have the cards in each batch are also numbered with the batch number and
with a nonce ...001 ...002 etc is fine. So the cards end up with a number
like 45600...001, 45600...002 etc which is the cards serial number.
Calculate the pin for the card. Use the secret key assigned to the batch
number concatenated with the card serial number and put that through a CS
Hash function like SHA-1. Convert the hash output to decimal and use those
digits (truncated to 16 digits) as the pin. Print that on the card. You do
not need to store the pin or serial number..
For card activation:
The user inputs his serial number. The prefix part of the number allows the
system owner to retrieve the correct secret key for that batch. The owner
then concatenates the secret key and the user supplied serial number to
generate (with the hash function) the pin . You need to keep the secret keys
for the batch numbers secure and secret.
The user then enters his pin number and is either rejected or validated
based on agreement with the hash output.
You then hash the user supplied serial number and add the hash to the valid
"in use" data base. Hashing this number stops anyone just grabbing a copy
of the "in use" database and using it as is - but there is a problem
mentioned later. Hashing also stops operator picking a number and giving it
to friends - but if the friend is a hacker he will try brute force the
serial number from the hash. He can do that because the 16 digits only give
2**48 protection. At the moment that is probably enough but it won't be in
10 years.
In use:
The user enters his pin. That is hashed and compared to the database. If
it is valid he's good to go.
Attacks:
The case of a hacker trying to brute force a single hash is mentioned above.
Of more danger is the possibility of having the database stolen. If that
happens the 16 digits are not enough security so you have physical security
issues in your system.
The more users you have the less secure the system becomes. To stop a
individual hacker just "phoning in" random numbers until he hits the jackpot
add short delays and voice prompts to the to the "use" procedure.
You also need to keep the valid "in use" pins hash secure (so no one
maliciously deletes a valid card ). The data base of expired cards also
needs to be kept secure (so no one deletes an entry and then re-validates
his card in a replay attack). When a batch date expires you delete
everything relating to it (no more chance of replay since the secret key to
validate the card is gone).
As for collisions you will need about 100000000 in use cards before it
becomes a problem.
I think that's about everything.
David Eather
- Next message: Douglas A. Gwyn: "Re: Odd little factorization result"
- Previous message: Peter Fairbrother: "Re: Public Key, Set-(bi)partition"
- In reply to: Peter Fairbrother: "Re: Pin generation algorithm question"
- Next in thread: Ernst Lippe: "Re: Pin generation algorithm question"
- Reply: Ernst Lippe: "Re: Pin generation algorithm question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
