GSoC 2021. Digital Signatures: My experience

Post by Sanket Shevkar.

Problem Statement

The problem statement I chose was digital signatures for Templates and Contract Instances. This can be then divided into two different problems i.e. signature for Templates and signatures for Contract Instances.

Template Signatures

There was a need to verify and authenticate the developer/author of a template. The template developer/author can sign the template. This signature would help organisations to verify who has developed the template.

Contract Instance Signatures

In the real world all the parties involved in an agreement sign the contract. Even the Smart Legal Contract Instances required the ability for the parties to sign the Contract Instances, which can be verified before executing those Smart Legal Contracts.

Need of digital signatures

While executing legal contracts, generating trust within the participating organisations becomes extremely crucial. Digital signatures can help in generating this trust. Even in paper-based agreements, contract signing plays a crucial role. Standard ink-based signatures cannot be used here in digital Smart Legal Contracts. So, using cryptography, these digital signatures can be implemented. This would ensure that the contents of the Smart Legal Contract like the model, logic and data cannot be altered, and if altered the signatures would become invalid. 

Implementing this project would provide an easy, robust and secure alternative to this whole process. Since the signing and verification process involved in this project is similar to TLS protocols. The whole process can be trusted and is more secure.

This will lead to an increase in the adoption of the Accord Project as signing documents is a very crucial part of the legal industry when it comes to agreements. Digital signatures would always be more secure and fool-proof as compared to ink-based signatures due to the cryptography involved.

Basics of digital signatures

The developer/author needs to have their own private key and public key. Using the public Certification Authority can generate X509 certificate for the developer/author and also the parties who are going to sign the Contract Instance. The Private Key and the X509 certificate is stored in a PKCS#12 Keystore which is a password protected file.

The content hash is generated from the model, logic and data of the Template or Contract Instance. This hash is then signed using the Private Key of the signatory. The verifier can verify this signature by using the Public Key of the signatory. While verifying, the verifier first generates the content hash on his/her side and verifies using the signatory’s Public Key. If the hash changes the signatures should not get verified and deemed invalid.

To implement this I found the following libraries helpful: crypto, node-forge. Crypto is a default module that comes with Node.js. It’s also been used in the cicero-core package to generate content based hash for the Template instance. I found crypto’s documentation really easy to understand and well-maintained. Crypto is being used to sign the templates and contracts and verify those signatures.  Node-forge is a native implementation of TLS using javascript. Forge is being used to implement a PKI like infrastructure that would help in importing PKCS#12 keystores and deriving X509 certificates, public keys and private keys from those keystores.

Template Signatures

To implement contract signatures, two new methods were added to the Template class in the cicero-core module they are,  

• signTemplate() method is utilised while creating an archive. If the developer wants to sign the template while creating an archive, he/she can do it. This would add the signature.json file to the .cta archive. This holds the template hash, timestamp, signature and the signatory’s X509 certificate.

• While loading the template archive using the methods in TemplateLoader class, this signature is then verified using the verifyTemplateSignature() method.

• The signature is stored in the Template object in a property called authorSignature.

Contract Signatures

Contract Signatures itself is a new concept in the Accord Project. Contract Instances are still under development. During my discussions with Martin, Nikolay and Jerome, I got to see the design process that was being followed to implement Contract Instances. The main features that Contract Instance should have are: 

• It should be instantiated by data in either JSON or markdown format.
• The contract should be able to track the changes/operations done with it in its lifecycle, so the state of the Contract Instance has to be maintained.
• The parties involved in the Contract agreement should be identified while instantiating so only those parties are allowed to sign.
• If a party signs the contract, the contract should enter an immutable state, if some malicious party tries to change the contract data, logic or model the older signatures should become invalid and also the new signature should be blocked to add itself to the Contract Instance.

During the design process, two approaches were compared. One was Martin and Nikolay’s approach and the other was Jerome’s approach.

In Martin and Nikolay’s approach, the contract data, the state, the signatures, the template archive’s were being stored in different folders.

In Jerome’s approach, the file structure was similar to a .cta archive but has an additional folder for signature and while instantiating the contract the data for that contract needs to be passed using a JSON file.

Since Jerome’s POC for Contract Instance was ready we decided to move on with it, also I had extended his POC to try to incorporate the other approach. But since at the time Jerome’s POC seemed more concrete we chose it.

The new Contract Instance archive has a .slc extension. A new ContractInstance class has been created which extends the Instance class. The same class gets inherited for Clause Instances.

While creating a new Contract Instance, the first job is to parse the template with the data markdown which generates the JSON file of the data present in the markdown file.

Also, we needed to fix the problem to pull out the party name from the data of the contract. For this Jerome suggested a temporary fix of using annotators to pull out party names using the model and the data.

The next step is to instantiate the Contract Instance. This creates a new .slc archive.

Next, the parties involved would sign the contract.

Four new methods are created in the ContractInstance class

• signContract(): first verifies the existing signatures if present, and then signs the instance instance hash by calling the sign function and returns an archive buffer of the signed contract archive.
• sign(): signs the instance hash and returns an object with instance hash, timestamp, signature and signatory’s certificate.
  

  

• verifySignatures(): maps over the contractSignatures property in the ContractInstance object which contains all the contract signatures.
• verify(): verifies the individual contract signatures.

Experience

I got to meet some amazing people whose expertise and experience made my GSoC process smooth and memorable. My mentor Martin was always there to help me whenever I got stuck and he made sure I never got overwhelmed during my time at GSoC. I am sure that the strict coding practices I saw Jerome implement at the Accord Project will help me in my future projects and also the code and the documentation was very neat and on point. It made it easy for me to learn and understand the concepts and understand the code. Also, Nikolay’s insights and contribution to the contract instance design phase and at the weekly meetings were deemed to be very valuable. Special thanks to Matt for administering the GSoC program smoothly at the Accord Project.

I’ll continue to contribute to the Accord Project and will try to add more developers to the community. Also, I wish to continue to work on Contract Instances as it’ll be a very valuable experience for me to bring a concept from just an idea to life and developers using it.