Re: Simple resource protection with public keys
From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 04/28/03
- Next message: Paul Rubin: "Re: Simple cipher program help"
- Previous message: Paul: "Simple cipher program help"
- In reply to: Tim Goodwin: "Simple resource protection with public keys"
- Next in thread: David Wilson: "Re: Simple resource protection with public keys"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 28 Apr 2003 14:36:16 +0200
On Mon, 28 Apr 2003 11:34:08 +0100, Tim Goodwin wrote:
> I'd welcome any comments on the following.
>
> I have a server, which holds a resource. I wish to restrict access to
> this resource.
>
> The server knows public keys for clients who may be authorized to
> access the resource. Since I need these keys anyway (for another part
> of the system), I would like to use them for this case too.
>
> The channel between server and client is not necessarily encrypted. I
> would like to minimize round trips. The value of the resource is
> small: I want to protect it from casual mischief-makers, but I'm not
> worried about opponents with serious resources.
>
> I have devised the following protocol.
>
> The client sends a message comprising (the client's idea of) the
> current time to 1-second resolution, and a signature over that
> timestamp made with the client's private key.
>
> The server verifies the signature, and checks that the timestamp
> is within a small delta of (the server's idea of) the current
> time. If both tests pass, access to the resource is granted.
>
> The signature algorithm I intend to use is SHA1 + DSA.
>
> I like the simplicity of this, but I worry that the timestamp message
> is: i) short, and ii) predictable. Is there any value in adding a few
> bytes of output from a CSPRNG to the client message?
No, because the server cannot verify that they were actually
generated by the CSPRNG.
Like Henrick already pointed out this protocol is
vulnerable to replay attacks, you should record the
most recent time-stamp per client.
Also the protocol is vulnerable to a man-in-the-middle
attack.
Another point, in general it is difficult to have
synchronized clocks, so your protocol should also
consider how to handle an unsynchronized client.
Why don't you use SSL/TLS? It avoids all of these
problems.
greetings,
Ernst Lippe
- Next message: Paul Rubin: "Re: Simple cipher program help"
- Previous message: Paul: "Simple cipher program help"
- In reply to: Tim Goodwin: "Simple resource protection with public keys"
- Next in thread: David Wilson: "Re: Simple resource protection with public keys"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
