On 6/14/12 2:10 PM, Michael Rogers wrote:
> On 13/06/12 07:59, Brian Warner wrote:
>> Assuming that Alice and Bob have some way to transfer 16 bytes
>> securely is part practicality and part pragmatism. The practical part
>> is that a targeted attacker (one who knows Alice and Bob and
>> specifically wants to intercept their invitation exchange) has to
>> watch them constantly, via all conceivable transmission channels,
>> waiting for that one moment to strike.
>
> I wouldn't agree that the attacker has to watch all the communication
> channels all of the time - she can watch some of the communication
> channels some of the time and only attack if she sees an invitation
> code. Unreliable or opportunistic attacks are still attacks.
Ok, that's fair. If the attacker is specifically targeting Alice and Bob
(maybe they know that Alice and Bob are interested in the same topics,
and thinks that eventually they'll discover each other, and wants to
intercept their communications), then their chance of success depends
directly upon how much of their communication they watch. If Alice and
Bob connect while they aren't watching, they'll be locked out.
If the attacker isn't targeting them specifically, so they just e.g.
compromise an IRC server and jump on any invitation codes that they see
pass by, then they'll capture more of the sessions, but will have less
control oover whose sessions they get.
>> But if they don't know much about the recipient, they probably aren't
>> in a good position to MitM their traffic, so the most likely attack
>> they could mount would be invitation-stealing, rather than MitM
>> (Alice invited Bob but gets a stranger instead who doesn't even know
>> she's supposed to pretend to be Bob, Bob gets an error and complains
>> to Alice through their outbound channel, Alice deletes the entry and
>> tries again).
>
> Why does Bob get an error? I'm imagining something like this:
>
> * Alice emails the invitation code to Bob
> * Mallory reads the email and joins the channel
> * Alice and Mallory do the invitation dance
> * Alice leaves the channel
> * Bob checks his email and joins the channel
> * Mallory and Bob do the invitation dance
> * Bob leaves the channel
> * Mallory has established keys with Alice and Bob, who think they've
> established keys with each other
>
> What am I missing?
Hm, good point.. if the invitation code can be trivially re-used, then
Mallory can easily do that. And when the code is the root secret (not
derived from anything else), then the only way to prevent re-use is to
rely upon the relay to remember and reject channelids, which is both a
storage burden and not something I want to rely upon.
There's a different protocol I was working on, more asymmetric, which I
dropped because I didn't think the extra complexity was worth it. I'll
need to think about it a bit more, but the basic idea was that Alice
generates a signing/verifying keypair, and gives the verifying key to
Bob as the IC. Alice's messages are signed, and Bob can verify them. Bob
hashes the IC to derive his own signing key, so Alice can verify the
inbound messages came from someone who knew the IC. The relay sees
ChannelIDs derived from the IC as before (so it cannot forge messages).
In that protocol, Mallory (who learns the IC but not Alice's original
signing key) can pretend to be Bob, but she cannot pretend to be Alice.
After Mallory fools Alice, Mallory can re-populate the relay with
messages in the same channel as before, and Bob will see them. But
either she puts fake messages there (and Bob rejects them because the
signature is wrong), or she uses Alice's original messages (and Bob
tries to connect to the real Alice, who is not listening anymore). So
unless she can actually replace the IC that Bob sees, Mallory has no way
to fool Bob into connecting to her instead of Alice.
It might need a key-confirmation step at the end to make sure Bob
terminates with an error or times out instead of believing that he'd
delivered his key to Alice. But if the IC is derived from a secret that
is never published, I think that would prevent *both* sides from being
fooled.
> We should distinguish between an attacker who can read the invitation
> code and an attacker who can replace it with another code.
>
> An attacker who can read the invitation code doesn't seem far-fetched
> to me - she could be sitting on Alice's LAN, for example. The current
> invitation protocol seems to be vulnerable to such an attacker because
> it sends a secret value in plaintext.
>
> On the other hand, an attacker who can replace the invitation code
> with another code seems more far-fetched to me.
Yes, excellent point. So, for some theory, Hoepman[1] examines pairing
protocols in terms of unidirectional channels (between humans Alice and
Bob) that might independently provide Confidentiality(C) and/or
Authentication(A). The conclusion is that, to do it right, you need one
of:
* a unidirectional C+A channel (Alice just gives Bob a shared secret)
* a bidirectional C (not A) channel (both send passwords, run EKE)
* a bidirectional A (not C) channel (commit and do authenticated DH)
Payrin and Vaudenay[2] modeled the interactions between humans and their
devices, by treating Alice and Bob as agents (programs), connected with
a single (human) User. Alice-program and Bob-program can exchange as
much data as they like over the untrusted internet, but Alice-program
and the User have a limited channel (e.g. if Alice is a USB security
token with a LCD display, then there is an authentic+confidential
channel from A->U, but no channel at all from U->A), as do the User and
Bob-program. They came up with a set of scenarios in which secure
operations were possible, and recommended protocols (and communication
costs) for each.
>From a usability point-of-view, I really want a unidirectional protocol:
Alice and her agent create something, send it to Bob, Bob types it in,
protocol completes. Bob (and his computer) have never heard of Alice
(and her computer) before he receives the invitation. That reduces the
need for a real-time interaction, and lets you do offline things like
printing invitations on paper cards. But from those papers, to prove
safety, this channel must provide both authenticity and confidentiality.
The only scenario that tolerates non-confidentiality between the User
and the target agent Bob requires bidirectional communication on that
channel.
So I can't meet my usability goal against even a passive eavesdropper.
You can see why I'm so eager to remove such adversaries from my threat
model :).
> So I think it's worth defending against the read-only attacker even if
> you don't defend against the read-write attacker. For example, could
> Alice and Bob exchange invitation codes derived from their public
> keys, instead of using a secret value?
Yeah, if I broke down on the usability goal, and required Alice and Bob
to exchange values (instead of only requiring Alice to send something to
Bob), then it's possible to achieve security in the face of read-only
eavesdroppers. I don't think a truncated hash of the pubkey is safe,
though, since as soon as Mallory sees that, she can generate a few
million keys until she gets one with a matching code, then replace
Alice's key with her own.
Hoepman proves a working protocol for the bidirectional-A link, but it's
annoyingly interactive: both machines first exchange commitments of
their DH parameters, then the humans are told to exchange codes (weaker
commitments of the same thing), then the machines exchange the real DH
parameters, then they compute the shared key, then they confirm that the
other computed the same thing. So the machines must have a way to find
each other before the humans get involved. That's a nuisance, since in
practice it means the users must have already introduced their computers
to each other somehow (insecurely), and the crypto stage is just to rule
out Mallory. This is handy for sealing an IM channel or graduating from
unencrypted email to secure email, but not as nice for inviting someone
to join your tahoe grid.
So, I'm looking for some compromise.. something that is generally secure
enough, but usable enough to actually get used (which, in my mind, means
a unidirectional channel, and the two computers are not connected to
each other ahead of time).
Hm, maybe some of Payrin+Vaudenay's flows could still meet my usability
criteria, if the reverse channel is expressed as a human-assisted
validation step at the end of the process. Imagine a unidirectional A->B
code (sent over an authenticated but non-confidential channel), running
the protocol I described above, but then following it up with Alice and
Bob comparing strings (or generated images or some other validation
step). This might be usable enough for local-introduction situations
(where you're sitting next to someone on the train and want to add them
to your phone's address book), or the eavesdropper-only cases (where
you're chatting with someone on IRC, run the protocol, probably connect
securely, then both agents tell you a string to paste into IRC and
compare against the other's value to confirm the connection).
Or, maybe the invitation code should be unique but not secret, and used
to establish an insecure channel with *somebody* (i.e. use it in lieu of
an ipaddr+port), and then you do a PAKE protocol over the resulting
channel with a second string (which *is* secret). Connect-then-verify is
pretty usable in a bunch of face-to-face situations. And even in an IRC
context where you never really meet the other participants in person,
it'd be nice to have a button you can hit at any moment to challenge the
other box, and slowly build confidence in the connection (i.e. you know
Bob from IRC, and you *think* your computer is connected to Bob's
computer, but every couple of months, when you run into him on IRC, you
push the button and Bob tells you the code that his computer prints out,
and your computer checks it, and a potential MitM has to be present and
interfering with every single challenge to maintain their position).
hm, much to think about.
cheers,
-Brian
[1]: "The Ephemeral Pairing Problem", Jaap-Henk Hoepman
http://arxiv.org/abs/0802.0834
[2]: "The Pairing Problem With User Interaction", Payrin+Vaudenay
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.230.6262
_______________________________________________
tahoe-dev mailing list
tahoe-dev@tahoe-lafs.org
https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
