In my previous article, I discussed how blockchain helps create legally enforceable trust across organizations. By providing a distributed digital signature capability, enterprise blockchains like Hyperledger Fabric give us a strong foundation to build on.
However, this impressive technology is involved and, depending on the use case, could be a perfect fit or overkill. FIDO devices that are being adopted for user authentication can also be used to digitally sign business transactions, providing a low-cost and easy-to-deploy alternative. Let’s explore in more detail how such solutions might look.
Let’s consider a large company that’s conducting business electronically with a smaller vendor. The company, let’s call it ABC, is designated as a “holder of records” for mutually signed digital transactions. Based on the nature of the business, the risk of company ABC deleting the records and claiming that no agreement was ever reached is considered immaterial, but both companies want to ensure that the details of the agreed-upon transactions cannot be disputed.
First, a quick background on FIDO. The goal of FIDO is to eliminate passwords by introducing new authentication technology based on biometrics and/or special hardware tokens. It may come as a surprise that most of us already have FIDO-enabled devices. Every Android 7.0+ or iOS 13.3 phone, Windows 10 or Mac OS computer is a FIDO-enabled device. Most FIDO hardware tokens cost less than $50. The Chrome, Edge, Firefox, and Safari browsers already have built-in support for FIDO through WebAuthn standard. As such, it’s easy for software vendors to add support for FIDO devices, and it’s a low-cost option for organizations to enable their users to use FIDO devices.
While there is a lot of information online about FIDO as authentication technology, we are going to focus on a less-known capability of FIDO devices to digitally sign any information we want — in our case, business transactions.
FIDO devices can generate a virtually unlimited number of private/public key pairs that can be used for various purposes. Private keys never leave the FIDO device, and public keys are shared with the target application (e.g., an ERP system). A typical authentication use case involves an application sending a user browser a random string (challenge), asking a user to sign it using the private key within a FIDO device. The application can then verify the signature by using the public key stored for that user. If the signature is valid, it proves that a user is in a possession of the originally registered FIDO device and, in the case of biometric-based devices, the FIDO device successfully verified the biometrics (e.g., fingerprints on a phone).
However, we can easily modify the above flow and replace a random challenge with the data we want to digitally sign from our business transaction. More specifically, we can follow the same overall approach as used in blockchain ledgers: Combine all the business data we need to sign using JSON, XML or any other format. Generate a hash of that business data, and then send that hash to a FIDO device to be digitally signed. We can then store our business data along with a hash and its digital signature, thus creating our own digital ledger.
Almost done, but it’s important not to lose track of our final objective: creating trust by making transactions legally enforceable. We can now verify that the transaction was signed by a user with a given FIDO device, but if the dispute goes to court, then we need to undeniably tie it to the organization that a user belongs to (i.e., prove that the company agreed to both this user and this particular FIDO device being used for signing transactions on behalf of the company).
This can be done by creating a file with a user public key and a statement authorizing the user to use it on behalf of his company. After being signed with a corporate certificate the file can be uploaded into an ERP system to prove that a public key is tied to the user’s company. This is a one-time registration process that each user has to go through.
Let’s review how the process would look from an end user perspective:
• A user representing a vendor is set up in company ABC’s ERP system with FIDO authentication. To make it more specific, let’s say a user is using a Windows 10 laptop with facial recognition.
• The system generates a file (could be a PDF, CSR, etc.) that includes the user’s public key.
• A user signs the file with their company (vendor) certificate. This can be done in more than one way. For example, a user may already have a company-issued certificate and use Adobe UI to sign a PDF file. Alternatively, a user may forward the file to legal or the IT team for a signature.
• A user uploads a signed file into the ERP.
• A user logs in into the ERP, picks a transaction and clicks on the “sign” or “approve” button.
• Windows 10 confirms the user’s identity through facial recognition and digitally signs a transaction.
• Company ABC’s ERP stores a transaction with a digital signature.
In case of a legal dispute, company ABC, as an agreed holder of records, has to produce a transaction along with both parties’ digital signatures. A transaction is digitally tied to a user with a given FIDO key, and that FIDO key is digitally tied to the vendor’s corporate certificate, thus creating a digital chain directly from the business transaction to the vendor compa