Improving KDEConnect encryption.

[vineet garg]

Hi,

Here is the first implementation of sending payload using SSL on github(
https://github.com/grgvineet/kdeconnect-android/tree/ssl).
It currently uses hard coded keystore which needs to saved on sdcad, but
working quite fine. Speed also quite fast and payload is fully encrypted,
tested with a text file and wireshark, no plaintext appeared.
This is just a test so may be code is little bit dirty :P


On Wed, Mar 4, 2015 at 11:30 PM, vineet garg <grgvineet at gmail.com> wrote:

> Hi,
>
> I want to work to improve KDEConnect encryption in this GSOC. I am
> thinking to implement following scheme:
> 1. Instead of using normal TCP we can use SSL/TLS to create session.
> 2. SSL/TLS, certificate for each device will be generated programmatically
> upon first use of application.
> 3. Instead of sharing public key on pairing, we can share certificates
> which will be stored on other device like we currently store public key.
> 4. Using a three way pairing so that user can verify other device's
> certificate by just verifying SHA fingerprint.
>
> What we will be results :
> 1. Full packet encryption.
> 2. No need to encrypt manually, SSL will take care.
> 3. No replay attacks, due to nonces in SSL.
> 4. No man in the middle attack, because fingerprint will be changed if
> there is attack in pairing or certificates will not match if there is
> attack afterward.
> 5. Fast, as asymmetric cryptography only used for SSL handshake, after
> that symmetric cryptography will be used which is quite fast.
> 6. Payload encryption, as it is fast.
>
> How I will do this:
> 1. Android supports SSL sockets and SSL server sockets throught
> Bouncycastle library.
> 2 We can generate certificate using Bouncycastle based on devices
> information programmatically.
> 3. Apache mina supports SSL filter over session.
> 4. QCA supports SSL/TLS.
> 5. We may implement openSSL (if possible, currently not sure).
>
> I have already started working on it and look forward to further improve
> it and to discover vulnerabilities in this scheme.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150305/da9be2dc/attachment.html>