Board index » delphi » Re: Cryptography question

Re: Cryptography question


2003-10-08 12:34:05 AM
delphi172
Quote
Suppose Mallory sets up a server somewhere on the network and tricks
Carol into connecting to this server instead of Sue's. Carol logs in to
Mallory, and Mallory simply forwards the same username and password to
Sue. Now Carol thinks Mallory is Sue, and Sue thinks Mallory is Carol.
Next Carol uploads her public key to Mallory. Mallory stores it and
uploads her own public key to Sue. Mallory will now forward all requests
from Carol to Sue, and decrypt Sue's responses and re-encrypt them
with Carol's key before forwarding them.
This seems like an impossible problem to overcome short of having a
courier carry the keys to the client. Couriers can not be trusted either :)
The only step I can see to avoid this is to embed the server's public key
in the client app and encode the client's public key using the server's
public key before uploading it. Of course someone could still spoof this
by modifying the .exe and spoofing the download server.
Marc
 
 

Re: Cryptography question

Marc Rohloff writes:
Quote
This seems like an impossible problem to overcome short of having a
courier carry the keys to the client. Couriers can not be trusted either :)
It is not an impossible problem to overcome. Please re-read my post from
yesterday.
Quote
1. The server public key should be distributed with the client software.
This key doesn't have to be secret, but has to be kept authentic. It is of course possible to tamper with the client software and e.g. substitute this key, but you have to find ways to prevent that from happening no matter what solution you choose. One method is to use AuthentiCode signatures.
If you use authenticode signatures, it will be possible for the client
user to detect if anyone has tampered with the client exe.
Quote
2. The first thing the client should do is to send a Certification Request to the server. It should contain:
a) The client public key
b) The name of the client user
c) Some information known only to the client and the server
d) The client's signature of (a)-(c)
e) Encrypt (a)-(d) and
f) encrypt the encryption key used at (e) with the server's public key
This is a tried and trusted method for requesting certificates.
Do *exactly* what I decribe above and you will be safe from
man-in-the-middle attacks.
--
Henrick Wibell Hellström,
StreamSec www.streamsec.com
StrSecII security components for Delphi, Kylix and C++Builder
www.streamsec.com/prod_strsec2.asp
 

Re: Cryptography question

Marc Rohloff writes:
Quote
Couriers can not be trusted either :)
That is a completely different kind of security problem. If you can't
find couriers you can trust more than you can trust the integrity of the
network, then you might as well give up right now and keep your secrets
to yourself.
Obviously, a client user who obtains any confidential file from the
secure server might upload it to a public ftp server the next second.
Cryptography will *never* protect you from "trusted" humans who turn out
to be untrustworthy. Cryptography can however protect you from a lot of
things except that.
--
Henrick Wibell Hellström,
StreamSec www.streamsec.com
StrSecII security components for Delphi, Kylix and C++Builder
www.streamsec.com/prod_strsec2.asp
 

Re: Cryptography question

Quote
>c) Some information known only to the client and the server
Ah yes now I remember the problem. Isn't this where the discussion
started?
Marc
 

Re: Cryptography question

Marc Rohloff writes:
Quote
>>c) Some information known only to the client and the server

Ah yes now I remember the problem. Isn't this where the discussion
started?
No, not really. The problem with symmetric encryption keys is that they
have to have the exact same value on both the server side and client
side, or else the decryption will fail.
A Registration Token (which is what we are talking about here) is used
only once and can optionally be verified manually. If it is verified
manually, it could be some human readable text written by the client
user about anything only the client user and server user knows.
--
Henrick Wibell Hellström,
StreamSec www.streamsec.com
StrSecII security components for Delphi, Kylix and C++Builder
www.streamsec.com/prod_strsec2.asp