Security and TOFU

Tue Nov 15 18:22:03 UTC 2016

On Tue, Nov 15, 2016 at 6:17 PM, Albert Vaca <albertvaka at gmail.com> wrote:
> 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
>
>

As I understand different bluetooth versions and different bluetooth
security levels work very differently. For example looking at
https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=86173
paper, it seems that "8.2.3 PASSKEY ENTRY TASK FLOW" chapter describes
a pairing method which could be quite good for kde-connect