Security and TOFU

Tue Nov 15 16:17:23 UTC 2016

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20161115/a47dd3ae/attachment.html>