Security and TOFU

Tue Nov 15 20:32:40 UTC 2016

In my view QR code is just one way of sharing a secret in a secure
manner  (the secret could be a whole certificate, a hash or some
passphrase). The same way entering passphrase manually serves the same
purpose - sharing a secret. NFC could also be used. I see several
issues however:

* Enetering passphrase would be most universal as every device could support it
* However passphrase should be short enough, so it is not suitable to
share big secrets such as certificates
* Different methods could be use based on device type or user
preference, however this could complicate both: the protocol and the
UI

On Tue, Nov 15, 2016 at 9:01 PM, vineet garg <grgvineet at gmail.com> wrote:
> 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