security concern: key management flaw with silc-client

[Pekka Riikonen]

: Obviously, the example above is facetious.  But weak authentication
: effectively undermines strong encryption, simply because one endpoint
: of a communication channel (no matter how secure) has no way of
: knowing who is at the other end.
: 
: Alice represents my current understanding of best practices for how to
: use silc securely.  But i don't see a way around this scenario for
: her, short of never caching anyone's keys who she might ever want to
: keep a secret from, which seems frankly unrealistic.
: 
The issue here is of course the lack of association with nicknames and 
public keys.  The association is done with fingerprints.  This can have 
multiple different solutions.  Some or all of the following can be done to 
address the situation, but not eliminate it if users are not careful when 
accepting public keys.

1) GETKEY could display information from the key it verified:

[23:28] *** Verified successfully user Bob's (Daniel Kahn Gillmor) cached 
        public key

The name is the real name from the public key.  In addition it could 
display the email address from the public key:

[23:28] *** Verified successfully user Bob's (Daniel Kahn Gillmor 
        dkg-silc at fifthhorseman.net) cached public key

2) key accepted with GETKEY could be associated with nickname and 
fingerprint.  This would mean that when GETKEY is issued the nickname user 
specified to the command is the associated nickname in the retrieved 
public key.  This would also mean that if the remote user decides to 
change their nickname the GETKEY would not find the cached key but would
create new association with the new nickname.  Since the fingerprint is 
also part of the association you could still have multiple Bob's public 
keys that are actually different people (or same).

3) WHOIS -details could cache the remote user's signature, which would 
then later be verified with GETKEY.  The signature would be associated 
with the nickname and fingerprint of the public key.  In this case GETKEY 
would retrieve the key, verify the key, verify the signature and report 
the result to end user:

[23:28] *** Verified successfully user Bob's (Daniel Kahn Gillmor 
        dkg-silc at fifthhorseman.net) cached public key and digital 
        signature


When verifying user's identity you should also give WHOIS and/or WHOIS 
-details command in addition to the GETKEY.

	Pekka
________________________________________________________________________
 Pekka Riikonen                                 priikone at silcnet.org
 Secure Internet Live Conferencing (SILC)       http://silcnet.org/