security concern: key management flaw with silc-client

[Daniel Kahn Gillmor]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi SILC folks--

I'm using silc-client 1.0.4.1 at the moment, monolithic build (not
irssi-plugin).  I'm concerned that there is a serious security flaw in
the model used for silc-client's management of clientkeys.  I'm hoping
that someone can explain to me what i'm doing/thinking wrong, and how
silc-client (or some other SILC client?) can help a reasonable user to
avoid this scenario.

The basic problem is that it seems impossible (or extremely difficult)
to actually differentiate between two different users whose keys i've
verified before.  This permits anyone whose key you have ever cached
to impersonate anyone else whose key you have also cached.

It also means that a single compromised key compromises the security
of everyone who has ever cached that key.

Here's an example use case as i understand it, including an exploit:

- ---------------------------------------------------------

Alice, Bob, and Charlie are all friends.  They communicate via silc.
When they started communicating with silc, they were all in the same
room as each other, connected to a silc server.  They decided to cache
their keys so that they could be sure they were talking to each other
online.

Alice and Bob both do (in silc): 
    /getkey Charlie

while Charlie uses his shell to do: 
    silc -S ~/.silc/public_key.pub

Charlie reads out the babbleprint of his key, which Alice and Bob
check right then.  It matched, so they both accepted and cached
Charlie's key.

This procedure repeats also with Alice and Bob taking turns reading
their babbleprints, so all three people cache the two other's keys.

So far, so good.  Now, when Alice connects, she can be sure she's
talking to Bob by first doing "/getkey Bob" and verifying that the key
matches her cached copy.

Or can she?  Months later, Alice and Bob are planning a surprise party
for Charlie.

Charlie suspects as much, but neither Alice nor Bob are saying
anything.  Charlie notices that Bob isn't currently logged in to their
preferred SILC cell, so he cooks up a plan:

 * Charlie creates a local user account on his home computer, named
   "Bob", and transfers a copy of his own SILC keypair to ~Bob/.silc/

 * From the new "Bob" account, Charlie connects to the silc cell like
   this:
     silc -c silc.example.org -n Bob

Alice is already connected to the silc.example.org.  She sees "Bob"
enter their common chatroom, and checks to make sure that it's him
with:

  /getkey Bob

the answer that comes back is:

[23:28] *** Verified successfully user Bob's cached public key

Suddenly, Alice gets a signed message from Bob:

[23:29] *** Starting query in silc with Bob
[23:29] *[S]Bob* How's Charlie's party planning coming?

She replies with:

/smsg Bob Good!  The weasels and the barrel of gin are on their way,
   and should be at the door when i get home!  He'll never know what to expect!

Oh, but he will now, Alice.  He will now.

- ---------------------------------------------------------

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.

I'm hoping that someone can help me see what Alice is doing wrong
here, or why the scenario above isn't actually a serious flaw in the
silc-client key management at all.

To be clear, i don't think this is a problem with the SILC network
protocol, as such.  I just think it's a problem with the key
management at the endpoint.  The Gaim/Pidgin SILC plugin had even
worse problems with key management last time i looked (maybe due to
the UI/transport abstraction layers of that project), but i won't go
into those here.

Thanks for thinking this over.  I look forward to any responses.

Regards,

        --dkg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFGS9QdiXTlFKVLY2URApvxAKD+PLaei82d1aT9+OoD4A6hFtdRBACfZbJf
ajpPpB9YohmkE02Gf/t7WtU=
=eWnK
-----END PGP SIGNATURE-----