[146880] in cryptography@c2.net mail archive
Re: [Cryptography] In the face of "cooperative" end-points,
daemon@ATHENA.MIT.EDU (Max Kington)
Sun Sep 8 23:57:23 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <77E6AA7D-C8E2-4B40-82AD-7A3D866E41BC@lrw.com>
Date: Sun, 8 Sep 2013 21:12:41 +0100
From: Max Kington <mkington@webhanger.com>
To: Jerry Leichter <leichter@lrw.com>
Cc: "Marcus D. Leech" <mleech@ripnet.com>, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8983423213587618723==
Content-Type: multipart/alternative; boundary=089e0112c136d3f4e704e5e4e45f
--089e0112c136d3f4e704e5e4e45f
Content-Type: text/plain; charset=ISO-8859-1
This space is of particular interest to me. I implemented just one of
these and published the protocol (rather than pimp my blog if anyone wants
to read up on the protocol description feel free to email me and I'll send
you a link).
The system itself was built around a fairly simple PKI which then allowed
people to build end-to-end channels. You hit the nail on the head though,
control of the keys. If you can game the PKI you can replace someone's
public key and execute a MITM attack. The approach I took to this was that
the PKI publishes peoples public keys but then allows other users to verify
your public key. A MITM attack is possible but as soon as your public key
is rotated this is detected and the client itself asks if you'd like to
verify if out of band (this was for mobile devices so it lends itself to
having other channels to check keys via, like phone your friend and ask
them). The much more likely thing is where someone tries to do a MITM
attack for just a particular user but as the channels are tunnelled end to
end they need to essentially ask the PKI to publish two duff keys, i.e. one
in each direction, Alice's key as far as Bob is concerned and Bob's key as
far as alice is concerned.. In turn the two people who's traffic the
attacker is trying to obtain can in turn ask someone else to double check
their. It means that you need to publish an entirely fake PKI directory to
just two users. The idea was the alarm bells go off when it transpires
that every person you want to get a proxy verification of a public key via
has 'all of a sudden' changed their public key too. It's a hybrid model, a
PKI to make life easy for the users to bootstrap but which uses a web of
trust to detect when the PKI (or your local directory) has been attacked.
Relationships become 'public' knowledge at least in so far as you ask
others in your address book to verify peoples public keys (all be it via
uuids, you could still find out if your mate Bill had 'John's' public key
in his address book because he's asked you to verify it for him). So for
those who want to protect the conversational meta data it's already
orthogonal to that.
Group chat semantics are quite feasible in that all users are peers but you
run into difficulty when it comes to signing your own messages, not that
you can't sign them but that's computationally expensive and the eats
battery life. Again, you are right though, what do you want to achieve?
I certainly built a protocol that answered the main questions I was asking!
As for multiple devices, the trick was always usability. How do you
securely move an identity token of some description from one node to
another. I settled on every device having its own key pair but you still
need an 'owning' identity and a way to 'enrol' a new key pair because if
that got broken the attacked just enrols their own 'device'
surreptitiously. You then get into the realms of passwords through salted
hashing algorithms but then you're back to the security of a password being
brute forced. If you were really paranoid I proposed a smart card
mechanism but I've yet to implement that (how closed a world are smart
cards with decent protection specifications?! but that's another
conversation), the idea being that you decrypt your device key pair using
the smart card and ditch the smart card if needs be, through a typical
office shredder.
Silent Circle was one of the most analogous systems but I'm an amateur
compared to those chaps. As interesting as it was building, it kept
boiling down to one thing: Assuming I'd done a good job all I had done was
shift the target from the protocol to the device.
If I really wanted to get the data I'd attack the onscreen software
keyboard and leave everything else alone.
Max
On Sun, Sep 8, 2013 at 7:50 PM, Jerry Leichter <leichter@lrw.com> wrote:
> On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote:
> > Jeff Schiller pointed out a little while ago that the crypto-engineering
> community have largely failed to make end-to-end encryption easy to use.
> There are reasons for that, some technical, some political, but it is
> absolutely true that end-to-end encryption, for those cases where "end to
> end" is the obvious and natural model, has not significantly materialized
> on the Internet. Relatively speaking, a handful of crypto-nerds use
> end-to-end schemes for e-mail and chat clients, and so on, but the vast
> majority of the Internet user-space? Not so much.
> I agree, but the situation is complicated. Consider chat. If it's
> one-to-one, end-to-end encryption is pretty simple and could be made simple
> to use; but people also want to chat rooms, which are a much more
> complicated key management problem - unless you let the server do the
> encryption. Do you enable it only for one-to-one conversations? Provide
> different interfaces for one-to-one and chat room discussions?
>
> Even for one-to-one discussions, these days, people want transparent
> movement across their hardware. If I'm in a chat session on my laptop and
> leave the house, I'd like to be able to continue on my phone. How do I
> hand off the conversation - and the keys? (What this actually shows is the
> complexity of defining "the endpoint". From the protocol's point of view,
> the endpoint is first my laptop, then my phone. From the user's point of
> view, the endpoint is the user! How do we reconcile these points of view?
> Or does the difference go away if we assume the endpoint is always the
> phone, since it's always with me anyway?)
>
> The same kinds of questions arise for other communications modalities, but
> are often more complex. One-to-one voice? Sure, we could easily
> end-to-end encrypt that. But these days everyone expects to do conference
> calls. Handling those is quite a bit more complex.
>
> There does appear to be some consumer interest here. Apple found it
> worthwhile to advertise that iMessage - which is used in a completely
> transparent way, you don't even have to opt in for it to replace SMS for
> iOS to iOS messages - is end-to-end encrypted. (And, it appears that it
> *is* end-to-end encrypted - but unfortunately key establishment protocols
> leave Apple with the keys - which allows them to provide useful services,
> like making your chat logs visible on brand new hardware, but also leaves
> holes of course.) Silent Circle, among others, makes their living off of
> selling end-to-end encrypted chat sessions, but they've got a tiny, tiny
> fraction of the customer base Apple has.
>
> I think you first need to decide *exactly* what services you're going to
> provide in a secure fashion, and then what customers are willing to do
> without (multi-party support, easy movement to new devices, backwards
> compatibility perhaps) before you can begin to design something new with
> any chance of success.
> -- Jerry
>
>
>
> -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography@metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
--089e0112c136d3f4e704e5e4e45f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This space is of particular interest to me. =A0I implement=
ed just one of these and published the protocol (rather than pimp my blog i=
f anyone wants to read up on the protocol description feel free to email me=
and I'll send you a link).<div>
<br></div><div>The system itself was built around a fairly simple PKI which=
then allowed people to build end-to-end channels. =A0You hit the nail on t=
he head though, control of the keys. =A0If you can game the PKI you can rep=
lace someone's public key and execute a MITM attack. =A0The approach I =
took to this was that the PKI publishes peoples public keys but then allows=
other users to verify your public key. =A0A MITM attack is possible but as=
soon as your public key is rotated this is detected and the client itself =
asks if you'd like to verify if out of band (this was for mobile device=
s so it lends itself to having other channels to check keys via, like phone=
your friend and ask them). =A0The much more likely thing is where someone =
tries to do a MITM attack for just a particular user but as the channels ar=
e tunnelled end to end they need to essentially ask the PKI to publish two =
duff keys, i.e. one in each direction, Alice's key as far as Bob is con=
cerned and Bob's key as far as alice is concerned.. =A0In turn the two =
people who's traffic the attacker is trying to obtain can in turn ask s=
omeone else to double check their. =A0It means that you need to publish an =
entirely fake PKI directory to just two users. =A0The idea was the alarm be=
lls go off when it transpires that every person you want to get a proxy ver=
ification of a public key via has 'all of a sudden' changed their p=
ublic key too. =A0It's a hybrid model, a PKI to make life easy for the =
users to bootstrap but which uses a web of trust to detect when the PKI (or=
your local directory) has been attacked. =A0Relationships become 'publ=
ic' knowledge at least in so far as you ask others in your address book=
to verify peoples public keys (all be it via uuids, you could still find o=
ut if your mate Bill had 'John's' public key in his address boo=
k because he's asked you to verify it for him). =A0So for those who wan=
t to protect the conversational meta data it's already orthogonal to th=
at.</div>
<div><br></div><div>Group chat semantics are quite feasible in that all use=
rs are peers but you run into difficulty when it comes to signing your own =
messages, not that you can't sign them but that's computationally e=
xpensive and the eats battery life. =A0Again, you are right though, what do=
you want to achieve? =A0</div>
<div><br></div><div>I certainly built a protocol that answered the main que=
stions I was asking!</div><div><br></div><div>As for multiple devices, the =
trick was always usability. =A0How do you securely move an identity token o=
f some description from one node to another. =A0I settled on every device h=
aving its own key pair but you still need an 'owning' identity and =
a way to 'enrol' a new key pair because if that got broken the atta=
cked just enrols their own 'device' surreptitiously. =A0You then ge=
t into the realms of passwords through salted hashing algorithms but then y=
ou're back to the security of a password being brute forced. =A0If you =
were really paranoid I proposed a smart card mechanism but I've yet to =
implement that (how closed a world are smart cards with decent protection s=
pecifications?! but that's another conversation), the idea being that y=
ou decrypt your device key pair using the smart card and ditch the smart ca=
rd if needs be, through a typical office shredder.</div>
<div><br></div><div>Silent Circle was one of the most analogous systems but=
I'm an amateur compared to those chaps. =A0As interesting as it was bu=
ilding, it kept boiling down to one thing: Assuming I'd done a good job=
all I had done was shift the target from the protocol to the device.=A0</d=
iv>
<div><br></div><div>If I really wanted to get the data I'd attack the o=
nscreen software keyboard and leave everything else alone.<br></div><div><b=
r></div><div>Max</div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">
On Sun, Sep 8, 2013 at 7:50 PM, Jerry Leichter <span dir=3D"ltr"><<a hre=
f=3D"mailto:leichter@lrw.com" target=3D"_blank">leichter@lrw.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Sep 7, 2013, at 11:16 PM, Marcus D. Leech wrote:<br>
> Jeff Schiller pointed out a little while ago that the crypto-engineeri=
ng community have largely failed to make end-to-end encryption easy to use.=
=A0There are reasons for that, some technical, some political, but it is a=
bsolutely true that end-to-end encryption, for those cases where "end =
to end" is the obvious and natural model, has not significantly materi=
alized on the Internet. =A0Relatively speaking, a handful of crypto-nerds u=
se end-to-end schemes for e-mail and chat clients, and so on, but the vast =
majority of the Internet user-space? =A0Not so much.<br>
</div>I agree, but the situation is complicated. =A0Consider chat. =A0If it=
's one-to-one, end-to-end encryption is pretty simple and could be made=
simple to use; but people also want to chat rooms, which are a much more c=
omplicated key management problem - unless you let the server do the encryp=
tion. =A0Do you enable it only for one-to-one conversations? =A0Provide dif=
ferent interfaces for one-to-one and chat room discussions?<br>
<br>
Even for one-to-one discussions, these days, people want transparent moveme=
nt across their hardware. =A0If I'm in a chat session on my laptop and =
leave the house, I'd like to be able to continue on my phone. =A0How do=
I hand off the conversation - and the keys? =A0(What this actually shows i=
s the complexity of defining "the endpoint". =A0From the protocol=
's point of view, the endpoint is first my laptop, then my phone. =A0Fr=
om the user's point of view, the endpoint is =A0the user! =A0How do we =
reconcile these points of view? =A0Or does the difference go away if we ass=
ume the endpoint is always the phone, since it's always with me anyway?=
)<br>
<br>
The same kinds of questions arise for other communications modalities, but =
are often more complex. =A0One-to-one voice? =A0Sure, we could easily end-t=
o-end encrypt that. =A0But these days everyone expects to do conference cal=
ls. =A0Handling those is quite a bit more complex.<br>
<br>
There does appear to be some consumer interest here. =A0Apple found it wort=
hwhile to advertise that iMessage - which is used in a completely transpare=
nt way, you don't even have to opt in for it to replace SMS for iOS to =
iOS messages - is end-to-end encrypted. =A0(And, it appears that it *is* en=
d-to-end encrypted - but unfortunately key establishment protocols leave Ap=
ple with the keys - which allows them to provide useful services, like maki=
ng your chat logs visible on brand new hardware, but also leaves holes of c=
ourse.) =A0Silent Circle, among others, makes their living off of selling e=
nd-to-end encrypted chat sessions, but they've got a tiny, tiny fractio=
n of the customer base Apple has.<br>
<br>
I think you first need to decide *exactly* what services you're going t=
o provide in a secure fashion, and then what customers are willing to do wi=
thout (multi-party support, easy movement to new devices, backwards compati=
bility perhaps) before you can begin to design something new with any chanc=
e of success.<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Jerry<br>
<br>
<br>
<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Jerry<br>
<br>
_______________________________________________<br>
The cryptography mailing list<br>
<a href=3D"mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><=
br>
<a href=3D"http://www.metzdowd.com/mailman/listinfo/cryptography" target=3D=
"_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</blockquote></div><br></div>
--089e0112c136d3f4e704e5e4e45f--
--===============8983423213587618723==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8983423213587618723==--
