Require feedback on GSOC proposal (Improving KDE connect encryption)

[Albert Vaca]

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?


> 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?


> 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?


> 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 :)


> 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.


> 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.


> 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).


> 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.


> 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.

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.

That's all!
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150317/05705658/attachment-0001.html>