Tabellion: A new system for more secure, independently verifiable legal contracts

This post has been republished via RSS; it originally appeared at: Microsoft Research.

Editor’s Note: The author would like to give special thanks to his collaborators, Ardalan Amiri Sani, Professor of Computer Science at UC Irvine, Sung Eun (Summer) Kim, Professor of Law at UC Irvine, and UC Irvine students Saeed Mirzamohammadi, Yuxin (Myles) Liu, and Tianmei Ann Huang.

In addition to my day job at Microsoft Research, I have been an active angel investor in the Seattle startup ecosystem. I have been an assistant fund manager with Seattle Angel, have co-founded the Grubstakes angel network, and have led multiple investment syndicate deals. In this role, I routinely sign and exchange lengthy legal documents. The standard practice is to either use DocuSign or print documents, sign them, and send the signature pages alone by postal mail. Both methods did not sit right with me.

What if someone mistyped my email address in DocuSign, and some random person on the internet signed an important legal document in my name? What if the recipient of my inked signature pages inserts those pages into a contract that I never intended to sign? In high-risk transactions, signatures can be notarized. However, that adds a lot of burden—I have to find a notary, arrange a time to use their services, and pay for their services. A similar burden exists with e-notaries that conduct their business over video calls. I wanted a better way to sign legal documents—a way that is as iron clad as a notarized document, with the ease, simplicity, and low cost of pasting my signature into a PDF.

Our team of researchers has worked to develop a technology that combines the assurance and security of notarized documents with the convenience of electronic signature methods. As our world continues to shift to more digital-centric methods of commerce, we must build systems that enable the formation of secure legal contracts while maintaining trust with all parties involved. Our work resulted in an ongoing research initiative called Tabellion, a prototype system for forming legal contracts that enlists the help of secure primitives to create self-evident contracts. Unlike other systems, Tabellion is designed to provide evidence that a signature is authentic, verify mutual assent to terms in a contract, and confirm that opportunities were provided to both parties to read the contract. The system is optimized for mobile devices, and contracts created with Tabellion can be validated by independent inspectors. Our research is presented in a paper accepted at ACM MobiSys 2020 and is titled “Tabellion: Secure Legal Contracts on Mobile Devices.” We also encourage you to check out The University of California, Irvine Department of Computer Science’s blog post on the Tabellion technology.

Combining expertise in trusted computing and understanding of the law

Working to build this technology required a multidisciplinary approach, combining legal experts and researchers versed in trusted computing technology. At ACM MobiSys 2018 in Germany, I sought out Professor Ardalan Amiri Sani to discuss this problem at length. I knew Ardalan well—he was my intern for a year at Microsoft Research, working with me to improve the cellular data efficiency of the mobile app platform on Windows. His work on using trusted computing to solve mobile systems problems is very innovative, deep, and exceedingly well known, including “Viola: Trustworthy Sensor Notifications for Enhanced Privacy on Mobile Systems,” “Ditio: Trustworthy Auditing of Sensor Activities in Mobile & IoT Devices,” and “SchrodinText: Strong Protection of Sensitive Textual Content of Mobile Applications.”

We immediately started brainstorming and making a plan to understand the problem in more detail and identify potential solutions. We soon realized we would need help and recruited two of Ardalan’s top students—Saeed Mirzamohammadi and Yuxin (Myles) Liu. We needed strong legal expertise to understand requirements from the law of contracts and legal ramifications of design choices, so we recruited the world-renowned expertise of Professor Sung Eun (Summer) Kim of the UC Irvine School of Law and her JD student, Tianmei Ann Huang.

What it takes for a contract to be enforceable under the law

In order to design a system that creates a valid contract, we first had to understand what makes a contract legal. The law of contracts requires many important qualifications for a signed contract to be valid, three of which are particularly relevant to an electronic signature platform:

  1. Signature attribution: a signature must be authentic to the party that it represents.
  2. Mutual assent: both parties must ultimately agree to the same contract, even as a draft contract goes through multiple rounds of offer, counter-offer, acceptance, or rejection.
  3. Reading opportunity: any party to a contract should have ample opportunity to read a contract.

Existing electronic contract signature platforms have run afoul of one or more of these requirements. For example, in a 2016 California bankruptcy case, the court questioned whether an electronic signature created using a popular e-signature platform was adequate as it could be manipulated or forged with ease, asking specifically what would happen if a debtor denied signing a document based on the claim that someone else had access to their computer and clicked the “sign here” button.

In another example, a plaintiff in a 2010 case challenged the validity of an arbitration agreement by arguing that the document signing system they used did not include an audit trail, and therefore it could not be determined when the agreement had been signed.

Finally, in a 2007 case against a retail chain, a plaintiff argued that there had not been a disclosure revealing that they would be charged for a magazine subscription upon signing an electronic signature pad. According to case documents, the question was not about whether there had been disclosure. Instead, what mattered was the fact that the store couldn’t prove the customer saw and approved the disclosure.

Understanding security risks: Attacks against electronic signature systems

Beyond the legal considerations of this technology, there are numerous security concerns that we needed to address when designing the Tabellion system. We identified three different attacks that existing electronic legal contract platforms can be susceptible to:

  1. Repudiation attack: a party to a contract denies having signed a contract. They may claim that they never signed it, or that they signed a different version of a contract, or that they were not given an opportunity to read the contract.
  2. Impersonation attack: someone impersonates a party to a contract and signs it. The attacker may spoof the victim’s identity or acquire access to their digital devices or services.
  3. Confusion attack: an attacker fools a victim into signing a contract that is different from what is eventually claimed. In a special form of this attack, called the Dalì attack, the attacker uses a contract file which shows different content on the offeror’s and offeree’s devices. We have demonstrated this attack with a specially crafted PDF file that shows some text in a contract in DocuSign’s mobile app, but the same contract shows different text on a desktop PDF viewer.

Tabellion: Inside the secure system for submitting and signing legal contracts

Tabellion is based on four secure primitives, as defined by our research team, that a legal contract platform should have in order to both meet the requirements of contracts under the law and defend against the aforementioned attacks.

  1. Tamper-proof camera-capture photo (secure photo): photos or videos of the user and their identification documents should be captured securely, such that they cannot be tampered with.
  2. Tamper-proof global timestamp (secure timestamp): a tamper-proof timestamp is needed to order events between parties to a contract to ensure mutual assent.
  3. Tamper-proof user-confirmed screenshot (secure screenshot): proof that the user had opportunity to read the contract and exactly what contract the user agreed to must be captured in a tamper-proof manner.
  4. Secure notarization of the contract: all the evidence of a contract produced by these secure primitives need to be assembled and bound together so that nothing can be added or altered and so that components cannot be re-used in other contracts.

The figure below shows a high-level architecture of our solution and where the primitives are implemented. The green boxes show the entirety of the Trusted Computing Base (TCB) in Tabellion. Here, the TCB includes all the software that is being trusted in Tabellion to function correctly and is not vulnerable to attacks. Minimizing the size of the TCB was an important goal in our design.

High level software architecture of Tabellion. The Tabellion client on mobile devices includes large amounts of untrusted code, which includes the user-facing Tabellion app and the mobile operating system, along with small amounts of trusted code that run Primitives I, II, III on the mobile TEE. On the Tabellion server, Primitive IV runs on the server TEE which is Intel SGX in our implementation. We also rely on an external secure time server for Primitive II.

The figure below shows the protocol that parties to a contract must follow in Tabellion. First, each party must register using the secure photo primitive. The Tabellion app captures the user’s photo (or video), optionally with the user’s identity documents. Cryptographically signed images are then sent to the Tabellion server, along with the user device’s TEE (Trusted Execution Environment) certificate and a certified hash of the TCB code. The first time that a user uses the Tabellion app, the client TEE creates a per-user, per-device key pair. It uses the private key of this pair to sign the user’s photo (Primitive I) and uses the same key later to sign the screenshots captured of the content of the contract (Primitive III). It also sends the public key to the Tabellion server for verification. We use secure biometric authentication on the local device to confirm user actions.

When an offeror submits a contract, they submit it to the Tabellion server in Markdown format. The server then renders the contract as readable images for each user device, ensuring that all text is readable and that there is no computer-interpretable content that can change after rendering. Each party receives the contract as properly formatted for their device screen dimensions. Each party must confirm every single page of the contract with their biometric authentication, which uses Primitive III to cryptographically sign each screenshot. Also at play here is Primitive II, which protects against timing attacks that can prevent mutual assent. Finally, the Tabellion server uses Primitive IV to produce a single contract with all the evidence from all the parties that can be independently verified as correctly formed.

We have implemented the Tabellion client on Android on a HiKey LeMaker development board. The TEE in this board is the Xen hypervisor (version 4.7) and the OPTEE OS (version 3.3) running in ARM’s TrustZone secure world. We implement Primitives I and III (other than the cryptographic signatures) in the Xen hypervisor. We implement cryptographic signing operations as well as Primitive II in OPTEE. We use RSA with 2048 bit keys for digital signatures in the client. We also have an implementation of the client for commodity mobile devices, where the TCB is significantly larger.

We have implemented the Tabellion server’s notary enclave in an Azure Confidential Compute Standard DC4s virtual machine (VM). This VM runs on top of the 3.7GHz Intel XEON E-2176G processor, which supports Intel SGX. We program the enclave using the open-source Confidential Consortium Framework (CCF). For the measurement of the TCB and the enclave certificate, we use the Intel SGX Data Center Attestation Primitives (DCAP) libraries, which leverage Elliptic Curve Digital Signature Algorithm (ECDSA). We use RSA with 4096 bit keys for digital signatures by the notary in the enclave.

There are many subtle challenges in securely implementing our primitives to prevent attacks. The figures below show an overview of how we implement Primitives I and III.

Overview of how Primitive I works in Tabellion. Rather than include the entire camera driver in the TCB, our key idea in Tabellion is to protect the camera photo buffer in memory from the time that the camera is about to capture the photo until when it is cryptographically signed. Tabellion write-protects the buffer pages before the camera device populates them with the photo data using Direct Memory Access (DMA). To prevent the untrusted OS from storing a fake image in the camera photo buffer before protection, Tabellion zeroes out the buffer right after protection.

Overview of how Primitive III works in Tabellion. Rather than include the entire display software stack in our TCB, our key idea in Tabellion is to secure the buffer used for displaying content (that is the framebuffer) in the TEE. When invoked by the Tabellion app, the TEE freezes the framebuffer, not allowing any more updates. It then waits for the user’s authentication using biometrics. Once the user confirms, the TEE signs a copy of the framebuffer and unfreezes it. This guarantees that the displayed content and the authentication are atomic.

 

TCB size and user study results

An important metric is the size of the TCB. Larger TCBs with more API calls and arguments increase the attack surface and make it harder to independently validate functionality. Our implementation of Tabellion adds only 826 lines of code to the TCB, as summarized in the following figure. This is a small fraction of the total 14,925 lines of code in Tabellion. The TCB is small enough that independent entities can audit it.

In section 8.2 of our paper, we include a detailed security analysis of our system to demonstrate its ability to protect against all three attacks we have identified.

We performed a 30-person user study, where users were asked to sign a variety of real-world legal contracts in DocuSign and Tabellion, and they were then asked a series of questions about the contracts that they signed. In the results shown below, users’ ability to understand and recall what they signed, ease of reading, convenience of signing, and duration of effort while using Tabellion are quite comparable to DocuSign.

Above: Users’ recollection of answers

Above: Users’ perceived convenience and readability using a Likert scale

Above: Time required for using each system

Working toward a future of mobile friendly, trusted contract signing

We believe that the future of legal contract signing is mobile friendly and trustworthy. We can achieve this goal by carefully understanding legal requirements and prior cases and implementing secure primitives in a novel way on trusted computing in mobile devices and in the cloud. Doing so does not need to come at the expense of usability—this is one situation where security and user experience concurrently improve.

However, some challenges remain. Our secure prototype with a small TCB was built on a development board—we do not yet have the ability to program the TEE on commodity smartphones. We need an open ecosystem that allows for programmability, deployment and attestation of code running in the TEE. Although Tabellion remains a research initiative for the time being, it creates a distinct path forward for improving the security and usability of electronic signature systems on mobile devices.

The post Tabellion: A new system for more secure, independently verifiable legal contracts appeared first on Microsoft Research.

REMEMBER: these articles are REPUBLISHED. Your best bet to get a reply is to follow the link at the top of the post to the ORIGINAL post! BUT you're more than welcome to start discussions here:

This site uses Akismet to reduce spam. Learn how your comment data is processed.