Security and TOFU

Tue Nov 15 19:01:24 UTC 2016

On Nov 15, 2016 11:40 PM, "Ismael Castiñeira Álvarez" <isma.casti at gmail.com>
wrote:
>
> We could make a pairing system similar to Whatsapp's: the computer will
show a pairing QR code. Then the user scans the code using the phone to
authenticate.

What about desktop to desktop pairing ?

>
> This way an attacker needs to have code running on the computer to
manipulate the QR code; the pairing code is never transmitted nor trusted
over the network.
>
> PD: I'm not sure if this email will be accepted, first time writing on
this list.
>
> 2016-11-15 18:17 GMT+02:00 Albert Vaca <albertvaka at gmail.com>:
>>
>> Bluetooth has the same problem, and even though it uses a simpler "hash"
to compare before pairing (a 6-digit number, IIRC), probably most users
will ignore it anyway. I don't think we can do much to help in this case.
Any ideas?
>>
>> On Tue, Nov 15, 2016 at 10:12 AM, vineet garg <grgvineet at gmail.com>
wrote:
>>>
>>> On Nov 15, 2016 2:26 PM, "Giedrius" <iksius at gmail.com> wrote:
>>> >
>>> > On Tue, Nov 15, 2016 at 10:46 AM, vineet garg <grgvineet at gmail.com>
wrote:
>>> > > On Nov 15, 2016 2:01 PM, "Giedrius" <iksius at gmail.com> wrote:
>>> > >>
>>> > >> On Mon, Nov 14, 2016 at 6:41 PM, Aleix Pol <aleixpol at kde.org>
wrote:
>>> > >> > On Mon, Nov 14, 2016 at 4:07 PM, Giedrius <iksius at gmail.com>
wrote:
>>> > >> >> What I am thinking about is not security of SSL or encryption
>>> > >> >> algorithms but rather trust-on-first-use method. As I
understand this
>>> > >> >> method mostly relies on users ability to check and validate
>>> > >> >> certificate fingerprints. It might be ok for SSH where users
can be
>>> > >> >> expected to be IT and security savvy, but in my opinion it is
not ok
>>> > >> >> for a regular user. First of all certificate validation is not
>>> > >> >> enforced in any way, so the average user most often would just
ignore
>>> > >> >> this step. Also, certificate fingerprints are quite complicated
and
>>> > >> >> can make validation error prone or may discourage the
validation step
>>> > >> >> altogether  (I am not sure how feasable it is, but an attacker
could
>>> > >> >> try to generate its own certificates which would produce similar
>>> > >> >> fingerprints). Are such my wories invalid?
>>> > >> >>
>>> > >> >> As I said, I am not security expert and I would be very glad if
>>> > >> >> someone corrected me :)
>>> > >> >>
>>> > >> >> Giedrius
>>> > >> >>
>>> > >> >>> Nothing in this life is completely fail- or hack-proof, but I
think
>>> > >> >>> KDE
>>> > >> >>> Connect security is, at this point, pretty decent :)
>>> > >> >>>
>>> > >> >>> Since the recent version 1.0, it uses SSL and
trust-on-first-use, like
>>> > >> >>> SSH
>>> > >> >>> (which you could say is not hack-proof either, nothing is). Of
course,
>>> > >> >>> SSH
>>> > >> >>> has likely been audited way more than kdeconnect, so if you
are a
>>> > >> >>> security
>>> > >> >>> specialist and want to check kdeconnect for implementation
errors or
>>> > >> >>> other
>>> > >> >>> security flaws, it would be of great help!
>>> > >> >>>
>>> > >> >>> Albert
>>> > >> >>>
>>> > >> >>> On Sun, Nov 13, 2016 at 6:50 PM, ixius ixius <iksius at gmail.com>
wrote:
>>> > >> >>>
>>> > >> >>> > Hello,
>>> > >> >>> >
>>> > >> >>> > I am concerned about security aspect of the kde-connect
pairing
>>> > >> >>> > procedure.
>>> > >> >>> > I am no expert in security but as I understand the pairing
of the
>>> > >> >>> > devices
>>> > >> >>> > currently is not completely fail-(or hack-)proof. Am I right
or am I
>>> > >> >>> > missing something? And if I am not wrong, I wonder if there
are any
>>> > >> >>> > plans
>>> > >> >>> > to solve the issues?
>>> > >> >>> >
>>> > >> >
>>> > >> >> As I understand this
>>> > >> > method mostly relies on users ability to check and validate
>>> > >> > certificate fingerprints
>>> > >> >
>>> > >> > How did you get to this conclusion?
>>> > >> >
>>> > >> > If the certificates aren't properly paired, it won't be possible
to
>>> > >> > communicate both devices.
>>> > >> >
>>> > >> > Aleix
>>> > >>
>>> > >> I am not talking about intercepting communications when devices are
>>> > >> already paired, but rather about pairing itself. One scenario I am
>>> > >> thinking about could be like this:
>>> > >>
>>> > >> 1. There are two paired devices in the network with names
(deviceName)
>>> > >> let say A and B
>>> > >> 2. There is a malicious actor connected to the same network who can
>>> > >> see device names as they are announced publicly
>>> > >> 3. This malicious actor can make a connection to device A using its
>>> > >> own unique deviceId, its own self-signed certificate but with
>>> > >> deviceName of the other device - B
>>> > >
>>> > > Since A and B are already paired, it means A already has B's
certificate,
>>> > > certificate from malicious user will not match and will lead to
connection
>>> > > failure. Certificates are not compared only by name but public key
and
>>> > > signatures are compared too. So malicious user will not even
connect with
>>> > > B's identity. So A won't even receive pairing request. If malicious
user
>>> > > tries to resend B's captured certificate, it does not have the
private key
>>> > > needed for SSL procedure so connection would fail again.
>>> > >
>>> > > That's is why it is called "trust on first use", once you trust a
device it
>>> > > will be always secure for future transactions. Though the first use
is
>>> > > vulnerable and susceptible to attacks. That's why in case of doubt
you can
>>> > > always confirm fingerprint.
>>> > >
>>> > >> 4. When connected, the malicious actor could request pairing on
that
>>> > >> device
>>> > >> 5. A user on device A would see a message that a device with name B
>>> > >> wants pairing
>>> > >> 6. At this place a smarter user would simply decline pairing as he
>>> > >> would understand that something fishy is happening. However if
user is
>>> > >> not so smart, or maybe distracted or in a rush, he could think that
>>> > >> this is some glitch in software (maybe previous pairing got somehow
>>> > >> broken or something like that) and would accept the pairing
request.
>>> > >> 7. If the pairing is accepted, a malicious actor becomes trusted
and
>>> > >> could access sensitive information like clipboard content. The user
>>> > >> might now see two paired devices with same name and may choose to
>>> > >> unpair them, but at this point it might be already too late
>>> > >
>>> > > Again since malicious user cannot connect with B's identity, all
above
>>> > > points seems invalid.
>>> > >
>>> > > Regards
>>> > > Vineet
>>> >
>>> > I think you misunderstood me. To make the situation simpler, instead
>>> > of "malicious actor" let say there is another standard kde-connect
>>> > device C. On that device C I can change its name to B and request
>>> > pairing on device A. The user on device A would see name B and would
>>> > think that this request came from device B while actually it is from
>>> > C. If he accepted the pairing request, he would be trusting device C
>>> > he didn't actually inteded to trust
>>>
>>> Yeah that's what trust on first use is, you have to carefully trust on
first use, compare keys and signatures on both devices etc.. After that it
is completely secure(integrity, authenticity, confidentiality and non
repudiation is maintained).
>>>
>>> I agree on that point that a normal user might ignore this step or make
some error. There should be some enforced user friendly hash comparison
method.
>>>
>>> @albert what do you say?
>>>
>>> Regards
>>> Vineet
>>
>>
>
>
>
> --
> ---------
> Ismael Castiñeira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20161116/e0c5b23b/attachment-0001.html>