Require feedback on GSOC proposal (Improving KDE connect encryption)

[vineet garg]

*Improve KDE Connect encryption*
*GSOC Proposal*

*1. Introduction :*

KDE connect is a leading software amongst different KDE and Android users
and continuously emerging to be a fully cross platform to work on as many
as platforms as possible.It give power to devices to talk to each other,
devices talk to each other in a language that no one can understand, i.e.
communication between devices are fully encrypted using RSA encryption.Yet
there is a possibility that other might hear what devices are talking or
may impersonate to other devices. So I will implement TLSv1.2 protocol,
currently the most secure protocol, over the communication of KDE connect
with different devices.

*2. Project Goals :*

The goal of this project this project is to implement TLSv1.2 protocol over
the normal TCP session on which device communicates.

Implementing TLSv1.2 will achieve the following goals :

1. *Full packet encryption* : Use of TLSv1.2 over TCP layer, TLSv1.2 will
take care of all the encryption by itself and there is no need encrypt data
manually. Since TLSv1.2 will encrypt data by itself, so all the data will
be encrypted (i.e. no traces that this data belongs to KDE connect). So a
eavesdropper can't know which data is of KDE connect's unless he guesses
the TCP port which will also be hidden if user is behind a NAT.

2. *Authentication *: Certificates of users will be generated
programmatically, and will be used for authentication purposes so that no
user may impersonate as other.

3. *Integrity checks* : Use of MAC in TLSv1.2, i.e. generating hash from
data from and
signing it with private key ensures that the data sent is not changed
during transmission and the data is not sent by any other person
impersonating as other, as he can't sign the hash with users private key..

4. *Increase in speed* : As RSA an exponentiation based algorithm, it takes
a huge amount of time. TLSv1.2 uses Diffie-Hellman or RSA only for key
exchange and afterwards AES is generally used or the best common algorithm
both parties support which all are xor based algorithm and quite fast.

5. *Increased security* : Since TLSv1.2 is developed over a long period and
reviewed by a large number of cryptographers in the community, it can be
considered as very secure. It's scheme will protect users from
Man-in-the-Middle(MitM) attack, replay attacks, Bleichenbacher
attacks(padding oracle attack on plain RSA with PKCS#1 padding scheme) and
many more attacks that can be done on plain RSA.

Below are the links of screenshots where test text file sent from one
Android device to another Android devices.
First image shows the data sent by using normal TCP socket and server
socket. An eavesdropper can view file contents by just few clicks in
Wireshark.
Where as in second image, the text file is sent using TLSv1.2 over TCP. The
text in the file is fully encrypted and no body can understand the file
contents.
Illustration 1:
<https://drive.google.com/file/d/0B7UrqqDErPX4SDY2Q3U2bnp4anc/view?usp=sharing>
Text file sent using normal TCP connection
Illustration 2:
<https://drive.google.com/file/d/0B7UrqqDErPX4VmZjb29DQldoX3c/view?usp=sharing>
Text file sent using TLSv1.2 over TCP connection

*3. Implementation :*

*On KDE side :*

1. In KDE version, QCA library will be further explored.
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.
3. Certificate will also be stored in PEM format side-by-side with the key.
4. TcpServerSocket needs to be replaced with WebServerSocket, both are
nearly same but WebServerSocket provides functionality to integrate TLSv1.2.
5. SslConfiguration which contains user certificate and key will be applied
to server socket to establish a fully encrypted session.
6. Same will be applied while sending payload.

*On Android side:*

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.
2. Same as with KDE version, when new RSA keys are generated, a certificate
will be generated for the device with values automatically fetched from the
device and the certificate will then be signed with users private key.
3. The certificate will be stored where private data is stored i.e. on
internal storage with various shared preferences files.
4. This certificate will be used when applying TLS filter over session
created by Apache Mina.
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.
7. This provides a backward compatibility in Android version of KDE connect.
8. Since much of the code in SslLanLink and SslLanLinkProvider with
corresponding LanLink and LanLinkProvider will be same, I decided to go
with some code duplication so that future removal of LanLink and
LanLinkProvider will be easier.
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.

The certificates used will serve as way for authentication of users,
encryption of data that we send to communicate with each other will be
taken care by TLSv1.2, so we don't need to worry about encrypting data at
all. Both key exchanging algorithm and data encryption algorithm will be
decided during TLS handshake with other device and best algorithm that both
devices support will be chosen by the devices automatically.

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.

*4. Timeline :*

Present Date – 30 April : Getting to know more about Backends, Bouncy
Castle, QCA and resolving any query with mentor.

1 May – 20 May : End Semester Exams of college. Can respond to any queries
but won't be able to work. Community bonding work will be done beforehand.

21 May – 24 May : Speeding up to start working on Android version, covering
any gap caused by exams.

25 May – 31 May : Refactoring code and abstracting LanLink so that it
maintains its own encryption and pairing process.

1 June – 7 June : Writing code to generate certificate and integrating it
with sessions to establish a encrypted session which trusts any certificate.

8 June – 14 June : Managing pairing process of TLS LanLink to store
certificate on pairing and using them afterwards to establish a secure
connection.

15 June – 21 June : Testing the application by running it on various
devices(using different images in emulator) and testing TLS connection
using nogotofail (a tool developed by Google to test SSL/TLS connections).

22 June – 26 June : Cleaning up code and writing documentation.

26 June – 3 July : Submitting mid-term evaluation. A working version of KDE
connect
among different Android devices using TLS.

4 July – 10 July : Generating certificates for KDE version of KDE connect
and saving it
along with the key in PEM format.

11 July – 17 July : Integrating certificates with session to establish a
encrypted connection which trusts any certificate.

18 July – 24 July : Modifying pairing process to store certificate on
pairing and using them afterwards to establish a secure connection.

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.

1 August – 7 August : Testing whole network and conducting attacks, like
Man-in-the-Middle attack etc. and finding any bugs in the implementation.

8 August – 17 August : Cleaning up code and writing documentation.

18 August – 25 August : Submitting final evaluations i.e. KDE connect that
now uses TLSv1.2 to communicate with other devices.

*5. About me:*

My name is Vineet Garg, I'm currently studying Computer Science at the
Delhi Technological University in Delhi, India and I'm 20 years old. I'm a
huge fan of open-source as it gives a lot of power to user to modify
software according to needs and developers to help in improving the
product. I have been learning programming since 1.5 years, where I have
learned C, C++, JAVA and comfortable with Python also. Developing Android
applications from 6 months where I have developed a game Ball Blast, a
sticky notes widget and many other applications developed for
learning purposes.

I previously have worked with KDE Connect and have submitted 3 major
patches ( File
download progress in notification bar, File upload progress in notification
bar, Notification filter support in notification plugin ) and pointed out
some minor bugs and reported directly to Albert in Android version.

Email : grg.vineet at gmail.com
IRC nick : vineet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150317/f330f992/attachment-0001.html>