Security and TOFU

Tue Nov 15 18:10:22 UTC 2016

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.

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/20161115/64617a9f/attachment-0001.html>