GSoC 17 : Client Side File Crypto : Week 2

Note: This is a repost of the original Blog post during GSoC ’17. As my AWS instance went down, I’ve been migrating my old blog posts here.
Originally posted on: 14th June 2017

This blog post summarizes the second week of coding with Drupal in Google Summer of Code 2017

Rephrasing the Project title

After the last week’s check-in meeting, there was a discussion on the project group suggesting that the name of the project should be rephrased to remove the term “zero-knowledge” where Colan and Talha reasoned why using the term “zero knowledge system” is inappropriate for the project. The term ‘zero knowledge proof’ or protocol is an academic term in cryptography. According to Wikipedia, it’s described as “a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.” This module does not exactly comply with this exact definition of “Zero-Knowledge”. Here’s a link justifying the same.

Key Manager

A major part of this week’s work was building the key manager for the module. After completing all the storage systems last week, it was necessary to be able to store and retrieve these keys using an appropriate method, for the same purpose the key manager was built this week. It is one of the two very important parts of the module, the other one being the encryption/decryption engine in JS.

The key manager is built in as a REST Resource plugin and currently accepts requests over the GET method.

The path that the REST resource is available is at /keys/{action}/{key_param}. The values in place of the curly braces are stored in $action and $key_param variables by symphony’s routing system where $action holds the desired REST resource action to be performed and the $key_param holds the parameter that is required for the action to be performed. The $key_param variable holds different purposes for different actions to be performed. The various actions to be performed by this REST resource are defined inside the KeyManager class which extends the core ResourceBase. The get() function handles all the get requests with the parameters as $action, $key_param. The $action variable is then used in a switch case statement to select the desired action to be performed.

The various methods built into the get() function are:

  • putPubKey : The parameter key_param here is the public key that is to be stored.
    This function registers the supplied public key in the $key_param variable in the GET request to the currently logged-in user’s user entity custom field ‘pub_key’ that was set-up on installation of the module.
    This request requires basic authentication.
    Example request URL: localhost:8000/keys/putPubKey/randomPublicKeyHere/?_format=json
    Example response in JSON:
  • getPubKey : The parameter key_param here is the UID of the user whose public key is desired.
    This method returns the public key stored in the custom user entity field “pub_key” for any user.
    Example request URL: localhost:8000/keys/getPubKey/1/?_format=json
  • getAccessKey: The parameter key_param here is the role name of which the current logged in user is a part of whose access key is desired.
    This method returns the access key for the currently logged in user by the role name as requested.
  • checkPubKey: The parameter key_param here is the UID of any user.
    This method returns a boolean of whether or not a user has registered their public key.
  • getPending: This method does not take any parameters.
    Returns an array of all pending access key requests belonging to roles that the current user is a part of.
    Example request URL: localhost:8000/keys/getPending/1/?_format=json 
    Example JSON response:
  • putPending : parameter : an array of all access keys that were encrypted using the public keys returned in the previous method.
    This action takes in an array of multiple access keys and stores them on the database.

Post login redirection

Several functions of the module will need to be triggered on user login. This was one of the parts that required quite a bit of searching the internet. Using the user_login hook and implementing a redirection on it didn’t work like I thought previously as the hook_user_login doesn’t support redirections. This was carried out by using another hook hook_form_user_login_form_alter. 
I’ve used a conditional redirection where, if a user has a public key already registered, they are redirected to a controller at a different route and for a first time login, the redirection is to the key generation page.

Generating the asymmetric (RSA) keys

Last week, I had set up the JS libraries that would be required to bind the controller render arrays. Now that all the work for now in PHP is done, I moved to writing the JS scripts.
The first part of the JS scripts was to generate the keys and send them to the server over the REST resources that I had built.

Now that all the backend work is done, I’ll be working with the key generation and key handling part on different hooks on the client side apart from implementing a few more hooks like user registration, adding a new role, adding users to roles, removing them from roles, adding a few more actions on install and some more hooks that are yet to be implemented.