Project Description
What is information escrow?
An Information Escrow Agreement is used to ensure access to business-critical information that is not proprietary to a company, such as manufacturing manuals, design blueprints, hardware manufacturing documentation and other confidential documents. In case a manufacturer, in general licensor, files for chapter 11 or is acquired by another company this would represent an escrow event and the information is released to the licensee.
CLIENT PROFILE
Our client is a global electrical systems manufacturer and full-service provider with applications in Aerotech, Nautics, Defense, Transportation and Security Markets.
| Industry | Electrical Systems |
| Employees | 50.000+ |
| Year founded | 2000 |
| Publicly listed | Yes |
CHALLENGE
The company required a solution to securely store & instantly provide access to licensed manufacturing blueprints it designed and provided to its clients, e.g. a transportation company. Immutable and resilient access controls were most critical for the escrow solution.
PROCESS
The project was organized in three distinct steps:
1. DISCOVERYIn several discovery sessions with both senior management and technical experts, we detailed the initial scope of the on-site workshops:
|
|---|
2. WORKSHOPDuring the workshops we covered the following aspects:
Findings from both the workshops and system audits were modulated in the feasibility report. |
|---|
3. FEASIBILITYIn the feasibility report we covered all PoC-relevant aspects:
|
|---|
SOLUTION
We designed an integrated software solution for document integrity testing, build verification, data upload, access control, the definition of release events and secure private key transfer in R3 Corda.
RESULTS
In case of a release event, the licensee can instantly access the critical blueprints. Based on the document hash, the private key is automatically transferred to the licensee when a release event is triggered and the data listed in the contract can be accessed on a secure file server.
DETAILS
Click on the toggles to find out more about the specific project details:
Historically, the company shied away from escrow agreements as often as possible due to the cumbersome nature and legal efforts involved in setting up escrow and ensuring the data transfer in case a release event is triggered. Therefore, the company employed escrow only when legally required, e.g. when contracting with the public sector or regulated companies within the private sector.
When depositing information in escrow the company needed to perform a lot of manual steps and take into account interests from several actors across departments, clients, contractors and eventually the escrow provider.
With the DLT-based escrow solution the company can manage their information escrow in a single solution tieing it all together and automating all aspects herein, such as retention times, contracts terms, verification needs, integrity test, etc. The configure the access control list and an auditlog is kept tracking every action/event/request in order to comply with the existing revision safeguard codes.
In summary, the company's goal was to develop a DLT-based information escrow solution with the objective to provide the following functionality to its subsidiaries and partner companies:
- Secure and scalable DLT-based storage and access control solution
- Information escrow application
- Multiple encryption layers & secure data transfer and sharing
- Client & partner management
Management actors
The management actors are involved in user creation, archiving use & management and processes management. For our purpose, we defined the following management roles: super admin, KYC administrator, document administrator, storage administrator, process administrator, release event administrator, security administrator and notary.
Non-management actors
Partner users are defined as users that can submit data for verification, but cannot store and archive any assets on the platform. Corporate users are validated users that are directly associated with the licensor or licensee and can perform several read and write transactions within the platform.
Escrow beneficiaries
In case a release event is triggered, the beneficiary users receive the private key to immediately retrieve the critical blueprints.
The following core functionality was researched, evaluated and designed in the feasibility report:
- Secure and scalable private, permissioned distributed ledger solution
- Access control lists and definition of release event taxonomy
- Notarisation function for stored documents and corresponding release events
- Encrpytion prerequisites
- Encryption of code
- Encryption of transport
- Encryption of file
- Encryption of storage
- User accounts lifecycle management: account registration, account login/logout, KYC management, ban and recovery
- Store file operations management
- Storage read request operations management
- Document lifecycle management: business logic imposition for each type of document, transfer of documents between users' accounts on the platform
- Web & mobile interfaces
In order to grant document access to external parties, an ACL is stored on the blockchain, which is queried when an external party requests a file. The ACL is required to be signed by the data owner beforehand and can therefore only be updated by him. Combined with the document recognition aided by AI, documents could additionally be stored according to a specific classification scheme, allowing a more granular ACL. This allows a definition on which properties accessible documents must have (type, date, confidentiality, etc.). To receive documents the external party needs to provide the storage layer with the cryptographic proof that the external party is currently authorized to access the requested documents. As the ACL is maintained on-chain the user is not necessarily required to take part in the document exchange. The general process of a request for a document from a legitimate requestor as described in the figure below can unfold as the following:
- External party gets data owner signed access rights.
- External party receives signed access rights.
- External party provides storage layer with document request and proper signatures.
- Storage layer provides the requestor with the requested document.
Because the storage layer is designed to be fully customizable it is possible to extend the document exchange protocol with additional security mechanisms. The data owner can encrypt the documents before uploading them to the storage layer if it should not be trusted for any reason. Although this would make it necessary to involve the data owner in the document exchange as it is necessary that the document is again decrypted before it is provided to the external partner. Also, the storage layer can be configured to get the access signature stored on-chain to make sure it is still valid. Alternatively, signatures can be provided with a time and or usage limit.
The feasibility was completed within 12 weeks and included several workshops:
- Discovery workshop
- System audit & process workshop
- Solution design workshop
- Feasibility kick-off
- Final presentation
