<div dir="ltr"><div style="text-align:center"><b><font size="4">Improve KDE Connect encryption</font></b></div><div style="text-align:center"><b>GSOC Proposal</b></div><div style="text-align:center"><b><br></b></div><div><b>1. Introduction :</b></div><div><b><br></b></div><div>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.</div><div><br></div><div><b>2. Project Goals :</b></div><div><b><br></b></div><div>The goal of this project this project is to implement TLSv1.2 protocol over the normal TCP session on which device communicates.</div><div><br></div><div>Implementing TLSv1.2 will achieve the following goals :</div><div><br></div><div>1. <u>Full packet encryption</u> : 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.</div><div><br></div><div>2. <u>Authentication </u>: Certificates of users will be generated programmatically, and will be used for authentication purposes so that no user may impersonate as other.</div><div><br></div><div>3. <u>Integrity checks</u> : Use of MAC in TLSv1.2, i.e. generating hash from data from and</div><div>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..</div><div><br></div><div>4. <u>Increase in speed</u> : 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.</div><div><br></div><div>5. <u>Increased security</u> : 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.</div><div><br></div><div>Below are the links of screenshots where test text file sent from one Android device to another Android devices.</div><div>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.</div><div>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.</div><div><a href="https://drive.google.com/file/d/0B7UrqqDErPX4SDY2Q3U2bnp4anc/view?usp=sharing">Illustration 1:</a> Text file sent using normal TCP connection</div><div><a href="https://drive.google.com/file/d/0B7UrqqDErPX4VmZjb29DQldoX3c/view?usp=sharing">Illustration 2:</a> Text file sent using TLSv1.2 over TCP connection</div><div><br></div><div><b>3. Implementation :</b></div><div><b><br></b></div><div><u>On KDE side :</u></div><div><u><br></u></div><div>1. In KDE version, QCA library will be further explored.</div><div>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.</div><div>3. Certificate will also be stored in PEM format side-by-side with the key.</div><div>4. TcpServerSocket needs to be replaced with WebServerSocket, both are nearly same but WebServerSocket provides functionality to integrate TLSv1.2.</div><div>5. SslConfiguration which contains user certificate and key will be applied to server socket to establish a fully encrypted session.</div><div>6. Same will be applied while sending payload.</div><div><br></div><div><u>On Android side:</u></div><div><u><br></u></div><div>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.</div><div>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.</div><div>3. The certificate will be stored where private data is stored i.e. on internal storage with various shared preferences files.</div><div>4. This certificate will be used when applying TLS filter over session created by Apache Mina.</div><div>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.</div><div>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.</div><div>7. This provides a backward compatibility in Android version of KDE connect.</div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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</div><div>future.</div><div><br></div><div><b>4. Timeline :</b></div><div><b><br></b></div><div>Present Date – 30 April : Getting to know more about Backends, Bouncy Castle, QCA and resolving any query with mentor.</div><div><br></div><div>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.</div><div><br></div><div>21 May – 24 May : Speeding up to start working on Android version, covering any gap caused by exams.</div><div><br></div><div>25 May – 31 May : Refactoring code and abstracting LanLink so that it maintains its own encryption and pairing process.</div><div><br></div><div>1 June – 7 June : Writing code to generate certificate and integrating it with sessions to establish a encrypted session which trusts any certificate.</div><div><br></div><div>8 June – 14 June : Managing pairing process of TLS LanLink to store certificate on pairing and using them afterwards to establish a secure connection.</div><div><br></div><div>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).</div><div><br></div><div>22 June – 26 June : Cleaning up code and writing documentation.</div><div><br></div><div>26 June – 3 July : Submitting mid-term evaluation. A working version of KDE connect</div><div>among different Android devices using TLS.</div><div><br></div><div>4 July – 10 July : Generating certificates for KDE version of KDE connect and saving it</div><div>along with the key in PEM format.</div><div><br></div><div>11 July – 17 July : Integrating certificates with session to establish a encrypted connection which trusts any certificate.</div><div><br></div><div>18 July – 24 July : Modifying pairing process to store certificate on pairing and using them afterwards to establish a secure connection.</div><div><br></div><div>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.</div><div><br></div><div>1 August – 7 August : Testing whole network and conducting attacks, like Man-in-the-Middle attack etc. and finding any bugs in the implementation.</div><div><br></div><div>8 August – 17 August : Cleaning up code and writing documentation.</div><div><br></div><div>18 August – 25 August : Submitting final evaluations i.e. KDE connect that now uses TLSv1.2 to communicate with other devices.</div><div><br></div><div><b>5. About me:</b></div><div><b><br></b></div><div>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</div><div>learning purposes.</div><div><br></div><div>I previously have worked with KDE Connect and have submitted 3 major patches ( File</div><div>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.</div><div><br></div><div>Email : <a href="mailto:grg.vineet@gmail.com">grg.vineet@gmail.com</a></div><div>IRC nick : vineet</div></div>