Improving KDEConnect encryption.

[Albert Vaca]

Hi,

I like your proposal and even though I'm not really into security and
will need a second pair of eyes to review it, I'm sure it would be a
nice GSOC proposal. I believe this is one of the most important things
missing in KDE Connect right now and I'm actually waiting for this to
happen before releasing a "1.0" version.

There is one thing, though, that I would like you to take into
account, and it is retro-compatibility. I think that we can implement
a brand new protocol in the next (Plasma) version of KDE Connect, and
just remove the old implementation, but for Android I would like to
have support for both versions of the protocol at the same time (and,
hence, a way to determine which one to use). The reason is that, since
we can update the Android app very fast (people will get notified on
their phones and they will just need to press a button), desktop users
are usually tied to distribution releases, and they might be stuck
with an old version of KDE Connect for long.

Then, my goal would be that, regardless of the version of KDE Connect
you have on your desktop, your phone should always be compatible with
it. I think that however we plan to achieve this should be part of the
proposal.

Albert

On Thu, Mar 5, 2015 at 1:19 AM, vineet garg <grgvineet at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> KDEConnect mailing list
> KDEConnect at kde.org
> https://mail.kde.org/mailman/listinfo/kdeconnect
>