Require feedback on GSOC proposal (Improving KDE connect encryption)

Tue Mar 17 14:52:03 UTC 2015

On Tue, Mar 17, 2015 at 12:33 PM, Albert Vaca <albertvaka at gmail.com> wrote:

> Looks good. Some questions and comments:
>
> 2. When RSA keys for the application are generated, a certificate for the
>> user will also be generated which contains user data, fetched automatically
>> from his system like user name, country etc. and certificate will be self
>> signed with user's private key.
>>
>
> Just a question to see if I understood this correctly: Is this private key
> you talk about something similar to the keys pairs that we currently
> exchange during the pairing? Are we also going to exchange these keys
> during the pairing with the new protocol?
>

Yes, they are the same key pairs that we are currently using, certificate
sharing is a sharing of public keys, but certificates are used each time to
verify the peer during TLS handshake procedure to avoid any
Man-in-the-Middle attack.

>
>> 4. TcpServerSocket needs to be replaced with WebServerSocket, both are
>> nearly same but WebServerSocket provides functionality to integrate TLSv1.2.
>>
>
> What's the difference between QWebSocket and QSslSocket and why did you
> choose WebSocket in this case?
>

I wrote WebServerSocket which analogous to SslServerSocket, as there is no
such class called SslServerSocket. QSslSocket is analogous to QTcpSocket,
so QSslSocket will replace QTcpSocket and QWebSocketServer will replace
QTcpServer.

>
>
>> 1. Android by default uses Bouncy Castle(BC) library and JAVA library for
>> various encryption purposes, BC will be further explored to generate
>> certificates with the key.
>>
>
> Just another question to see if I understand: The new kind of sockets will
> do all the encryption/decryption, and BC and QCA are now going to be used
> only to generate the needed keys and certificates?
>

Yes, BC and QCA are just used to generate keys and certificates, as native
JAVA and Qt library doesn't support generation of certificate, but good
part is they are already included in our project and we don't need to add
something.

>
>
>> 4. This certificate will be used when applying TLS filter over session
>> created by Apache Mina.
>>
>
> Good call to use Mina so we get to reuse some stuff, and also shows you
> have documented about the current code works :)
>

I spent quite some time to figure out to make minimal changes to apply
this. :)

>
>> 5. As pointed out by Albert, that KDE application upgrades are not as
>> frequent as Android's, so a new LanLinkProvider (SslLanLinkProvider) will
>> be used. So we will have two link providers in Android version of
>> application.
>> 6. Each link provider decide itself whether to create a link with other
>> device based on its identity package which contains a field called
>> isSslSupported.
>>
>
> This does not scale very well when we add other protocol (eh: Bluetooth,
> direct USB connection, over the cloud...). I would try to simply
> instantiate always both protocols and one will fail to connect and the
> other will succeed, so we will use the one that succeded. If this doesn't
> work for some reason, maybe we can have an array like "supportedProtocols:
> ["ssl", "bluetooth"]", but anyway not a boolean per protocol.
>

Yes, may be we could just use that in identity package that which Links the
device support and choose the best amongst them. Like with order SSL,
normal, bluetooth, wired

>
>
>> 9. Since SslLanLink does encryption of data itself, so LanLink should
>> also do it. So encryption of network package will be moved to LanLink from
>> Network package so each link manages its own encryption scheme.
>>
>
> Perfect, handling the encryption should be done inside the link, and not
> in higher level classes like Device as we do now. It would be nice to do
> this in the KDE side as well, even though we will only have one protocol
> for now.
>

Alright, symmetry will make further development easy.

>
>> The use of TLSv1.2 follows Public Key Infrastructure(PKI), where there
>> are some trusted parties and they verifies the certificate,i.e. these
>> trusted third parties sign the certificate with their own private key. User
>> can authenticate certificates by using the public key of third party. Since
>> we cannot use third parties here and we assume that user trusts himself
>> most, so during pairing process hash of public key will be shown to user to
>> verify it manually to avoid any Man-in-the-Middele(MitM) attack. Once the
>> pairing process is done, other party's certificate will be saved and we
>> will use that certificate for any future communication. This method ensure
>> no MitM attack in the future.
>>
>
> Showing a hash doesn't seem very user friendly. Maybe we can reduce that
> to a short pin (like the 4-digit numbers in bluetooth pairing).
>

May be we could use just some initials of hash, as git does while showing
history. I first thought of showing an Identicon , but later thought that
It will go out of scope. Maybe in future we could do this.

>
>> 15 June – 21 June : Testing the application by running it on various
>> devices(using different images in emulator)
>>
>
> And fixing bugs :) You probably don't need to test it on many virtual
> devices, I have three phones I can use to test and you probably have one,
> so that should be enough. This way you can save time to use fixing bugs,
> because assume there will be bugs, and that they will take longer than
> expected to fix.
>
>

A wrong implementation sometimes leads to Handshake failure without showing
cause, it is hard to debug it sometimes. Also I need to test a lot with
using Wireshark using SSL private key to ensure the implementation is
alright and all data is encrypted correctly.

4 July – 10 July : Generating certificates for KDE version of KDE connect
>> and saving it
>> along with the key in PEM format.
>>
>
> One week seems a lot of time to do this.
>

Ok, I will use this time to refactor code to abstract Link, and merge it
with next week's work.

> 25 July – 31 July : Integrating both Android and KDE version with each
>> other. Handling any problems caused due to difference in APIs and their
>> implementation.
>>
>
> One week seems quite short for this. You probably want to compact the
> previous tasks a bit so you have more time for this part.
>
>
All though they are universally accepted, their should not be any problem
in integrating it.  But I kept it for some safe side cause once they are
working with same type of devices like Android version is working fine by
itself and so do KDE version, they should automatically work fine with each
other.

That's all!
> Albert
>
>
Alright, so at the time where I was generating certificates in KDE version,
which seems too short to you, I will refactor code for Link abstraction,
and generate certificate and integrate with session on next week,
Instead of showing hash, some initials of hash will be shown for
verification of the user.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150317/81363e46/attachment-0001.html>