Re: Pin generation algorithm question

From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 04/26/04 

Date: Mon, 26 Apr 2004 13:37:20 +0200

On Sat, 24 Apr 2004 21:15:25 +0100, Peter Fairbrother wrote:

> Ernst Lippe wrote:
>
>> On Sat, 24 Apr 2004 02:48:21 +0100, Peter Fairbrother wrote:
>
>>> You have to have a big, valuable target somewhere, you can't avoid it. How
>>> are keys better?
>>
>> There is a major difference between securing an entire database and
>> securing a single key.
>
> You have to secure a number of keys in this instance, not a single key. Not
> that it makes much difference.
That should not be a problem. Virtually all crypto hardware can
store multiple keys, and in this case the number of different keys
is limited.

> If you want to use crypto hardware, you can use the hardware to encrypt the
> tokens in the database with a secret key cipher, or better a keyed hash, and
> encrypt/hash then check requests.
When you have crypto hardware that only allows encryption but prevents
decryption, it would be slightly better to use encryption than hashing.
The problem with hashing is that there is a tiny possibility of
collisions. If you ever get one, it will probably take a lot of
effort to find out what caused this problem. All developers will
have assumed that the hashed value is a unique key, and it will
be difficult to predict how the system will behave when this
assumption fails. On the other hand, the trap-door nature of
hashes is attractive.

> The database does not require secrecy,
> even if it is a database of tokens in issue.

But then there is not much difference with my proposal, you also have to rely
on the secrecy of certain keys (in your case the keys that are used to encrypt
the database.)

Both approaches are vulnerable to certain attacks on the database,
e.g. there are probably attacks that will allow the attacker
to recycle numbers that have already been marked as "used".

There is one attack against your system for which I see no equivalent in my
proposal. Assume that an attacker can monitor requests and observe the
encrypted values, and at a certain point in time is able to make modifications
to the database. The attacker can track all attempts to verify "wrong"
numbers, e.g. because the user has made a mistake while entering the
number. Because such mistakes will probably happen quite frequently, the
attacker can collect a long list of wrong numbers and their encrypted
values. When the attacker can insert these encrypted numbers in the database,
he has a list of known numbers that have now become valid. I see no equivalent
attack against my system.

> All the authentication server does is accept a request, check to see whether
> it (or it's hash) is are on the list, and answer "yes" or "no". Plus keep
> non-secret logs. When new tokens are required, they (or their hashes) are
> added to the list. You can just do that in secure hardware, or you can use
> crypto modules if you prefer.
Traditional crypto boxes are not suited for storing and manipulating
such large databases, so I don't think that it will be easy to
find "secure hardware". Of course this depends on your definition
of secure, but because of the large sums of money that are involved
in this case, you should probably use rather high standards.

>> When the load of the system is too high for any single server
>
> Ain't going to happen. The average rate is about 2 authentication requests
> per second. An authentication request is a few cycles and a lookup, and you
> could do a whole lot of those in a second with a P133.
Yes, that's probably true. The main reason that I mentioned possible high
loads, was that Kees's argument for having a quick-check, was to
reduce the load on the verification server, so I assumed that
performance might be a problem.

> You might want a few servers to handle the request traffic, but not the
> authentication, which should be done on one dedicated secure server only.
>
>> Also for
>> disaster recovery, you will need another set of hot stand-by servers at a
>> different location.
>
> Keep a backup list of issued tokens in a bank vault, and an updated list of
> used tokens (the authentication server's log) somewhere offsite. In a
> disaster you accept all requests (unless the rate gets abnormally high)
> until you can get to the bank and regenerate the list.

There are several other services for which they need disaster back-up
facilities (e.g. the services that determine if the phone is allowed on their
network). They will probably already have some mechanisms/policies for
replicating data for these facilities, and I assume that the data for the
verification server will use the same path.

Ernst Lippe

Relevant Pages

  • Re: What can I do about breakin attempts?
    ... are not just more secure, but also much easier to manage/handle; ... is a potential attacker). ... as long as there are no serious security flaws known about ... Passwords are simply not as secure as encrypted keys. ...
    (comp.os.linux.security)
  • Encryption approach to secure web applications
    ... how to store passwords and keys in a shared web server. ... I can serialize the object, and store in the database, but this is not ... Assuming that I can find a good and secure place where to store the ... First of all, I need a secure way to keep database passwords secure, so ...
    (SecProg)
  • Passphraselessly protecting dictionary relations
    ... following scheme for a non-protected database. ... secure symmetric encryption function using K as the key ... This is a Term=Description dictionary, where the attacker ... From the fact that this CGI program has been written in Haskell, ...
    (comp.security.misc)
  • Re: Key attributes with list values was Re: What are the differences ...KEY
    ... Jane Harper is married. ... And a constraint that states that single people cannot become divorced. ... database, or users, for that matter, to distinguish between them. ... That's the whole point of keys. ...
    (comp.databases.theory)
  • Re: Pin generation algorithm question
    ... the keys would be a big ... Suppose that we have a database that contains all valid numbers, ... load among several servers that all need access to this database. ... So the only real problem is which systems are accessing this crypto box. ...
    (sci.crypt)