The main problem with security gateways is justifying the level of trust that is required to accept their deployment.
Threshold Encryption addresses this problem by distributing the control mechanism across multiple gateways, which then require consensus in order to decrypt the protected data.
There are advanced cryptographic solutions to this problem, but we were hoping to find a simpler solution, which could be implemented using off the shelf software components, even if that means compromising on flexibility to some extent.
One simple mechanism is distributing RAID 6 data stripes across multiple gateways, which each encrypt the data before allowing it to be stored, with the consequence that the original data cannot be recovered without consensus between the gateways, because we require a sufficient number of gateways to decrypt their RAID stripes.
Assuming the gateways are implemented in the cloud, using publicly available services, then we have to assume that the gateway instances will be vulnerable to a variety of external cyber attacks, in addition to any internal risks that might arise from compromise of the service provider.
Threshold encryption does not mitigate the inherent security risks, but is does ensure that multiple cloud services must be compromised concurrently in order to compromise the protected data.
If we assume the gateways are distributed across multiple cloud service providers, such as Microsoft, Google and Amazon, then we would expect the solution to be resilient against major compromise within any individual supplier.
If we further assume the gateways are also distributed across multiple cloud service regions within each supplier, then we would expect the solution to be resilient against major compromise within any cloud service region, and we would further expect the solution could be configured to be resilient against major compromises within entire geographic regions, which potentially affect multiple service providers.
There is residual risk that underlying vulnerabilities in the cloud service provision of all selected cloud service providers might cause the solution to be compromised, but this is mitigated to some extent by the likelihood that differences in the specific implementation and operational practices of each service provider would make such vulnerabilities difficult to exploit.
Whilst such deep rooted systemic vulnerabilities cannot be ignored, it seems much more likely that the solution would be vulnerable to systemic vulnerabilities within the virtual machine implementation, the choice of operating system, programming language or library dependencies.
We therefore propose development of alternate implementations of the Threshold Encryption protocol, based on different virtual machine implementations, operating systems, programming languages and library dependencies.
We also propose development of alternate implementations designed for specialist deployments, where potential user communities might prefer to select specialist cloud service providers, who might potentially restrict access to selected communities, and implement specific hardware security mitigations.
We further propose development of alternate deployment mechanisms, which can be used to deploy implementations in a standardised manner, which can be independently validated. This is probably the most critical security consideration arising from our earlier research, which identifies the existence of human involvement within the deployment process as the single most significant cause of security vulnerabilities.