Author: Kanti Kalyan Arumilli

In the world of computing, we are familiar with and understand the need for secure communications and secure data transfer. When using public-private keypairs, the public key is provided and the data is encrypted using the public key, transmitted and then the private key is used for decryption.

In this article, we will discuss an approach for securely pairing two clients that can’t communicate directly and for securely communicating with the clients using a server. In this example, let’s say we have a web server, two instances of an application that has some offline data (data not stored on the server), the two clients have to pair anonymously without providing much information to the server and need to transfer some sensitive data.

This is a sample tech implementation that can be implemented in SimplePass for synchronization between devices, without exporting file, copying file and importing. Remember, SimplePass does not need any account creation, so what the application server knows about you is absolutely nothing. SimplePass does not even collect emails. Assuming complete safety, privacy are needed for applications, this blog post suggests a way to get this accomplished. This approach requires minimal server processing and memory needs and no information is stored on the server. This feature is not implemented in SimplePass yet and I don’t have any plans of implementing in the near term, but thought of sharing the idea.

For this example, we will say the first instance of the client application that needs to send data as “sender”, the client application that needs to receive data as “receiver”, a web server capable of sending push notifications or being able to hold some key-value pairs in memory.

The tasks that need to be accomplished are:

1. Securely pair the sender and receiver without giving away too much information to the server but with the server’s help.
2. Securely communicate data from sender to helper with the server’s help.

1. When the user of “sender” needs to send data, they need to pair with the target “receiver”. They would open a section of the client application, generate a random code – for example “abcd1234” and synch with the server.
2. A request to the server is sent with the client ID, and the generated random code. The server would hold a unique ID for this transaction and a data structure with the client ID, unique ID as properties and some kind of a time-out let’s say 15 minutes. If the random code exists in the server’s dictionary, the request would be rejected.
3. The user would use the second device -“receiver” and enter the unique ID from the “sender” device, generates another “receiver” specific random code And synchs with the server. For example let’s say “zxcv0987” is the “receiver” random code.
4. The “receiver” would also generate a public/private key-pair, and uploads the public key-pair to the server.
5. The server looks up its internal data dictionary for the “sender” requested random code, the “sender” random code has to exist and there can be multiple “receiver” random codes, but the “receiver” random codes need to be unique. The server holds each “receiver”‘s random code and public key in memory.
6. The “sender” application displays the list pairing request “receivers” random code, here in this case – “zxcv0987”. The “sender” would approve the “receiver” random code. If an unknown “receiver” random code gets visible, the user can safely assume his communications and activities are being monitored by hackers such as Uttam, Thota Veera, Thota Bandhavi, Cuban Michael or Ray, Karan/Diwakar/Karunakar and whoever is an “is”, “already”, “ek”, “es” or any other hacker or any other spy, and the user can deny the unrecognized codes.
7. Steps 3 – 5 can be done when trying to synchronize with multiple devices and the same level of security and privacy can be applied.
8. Now the “sender” would click something like export. The “sender” application receives the list of public keys for each approved “receiver”. The “sender” encrypts data using the public key for each “receiver” and sends the data to the server, the “receiver” receives the data and decrypts using its own private key for the session.
9. The “receiver” after decrypting data, tells the server to clean up and all related resources for the “receiver” can be cleaned up.
10. All of the above steps need to be performed within the set time-out, to minimize the resource usage on the server.

In the above scenario, the server is holding some data that it can’t even read because the server does not have a private key. The only processing happening on the server are some key lookups – very minimal computing. Even the memory requirements for holding the ID, random codes and public key are minimal. In the approach described above complete privacy, security, and hacker-proof are maintained with minimal memory and CPU usage.

There is a flaw in today’s OTP/Authentication codes i.e if server side apps are not checking for one time usage and even if there s one time use checking what if the hackers or spies enter the OTP / Authetication code before the actual user? More and more implementations should become hacker-proof and thwart the onLINE hacking/spying/hate/propaganda group.

If the data being transferred is being held in memory, the memory load cannot be predicted.

I think this is a very simple and nice approach for synchronizing data among applications like SimplePass that maintain the privacy of users and don’t need any kind of accounts and can still synchronize data across devices in a secure way.