Closed Source

This scheme is intended to be used in a scenario where multiple users are using a storage system to store data.

This tool behaves like a classic fuzz tester, by supplying mutated input to a program and observing its behaviour. Often, mutated input leads to crashes, and the crashes reveal ways of exploiting the program. Standard fuzzers however do not take into account the distributed nature of some of the software that powers the cloud. The distributed fuzzer will be optimized for distributed programs and components. The output is a series of crash reports including back-traces and the developer/tester can manually intervene to fix the bug and harden the code.

This mechanism includes a wide set of tools that ensures that an attacker has the smallest amount of resources at its disposal to attack a system. This is valuable because several zero-day exploits target unused features of the kernel.

Files are encrypted on the client side before being uploaded to the cloud, and will be decrypted on the client side after being downloaded to local. The encryption key is kept by the clients. The encryption keys are acquired by the clients from some remote entity, in a privacy-preserving way that the remote entity is not able to infer or distinguish the file content from the requests from all clients, but this remote entity will ensure that the same file content will derive the same encryption key. Thanks to this feature, files across multiple clients can be de-duplicated.

The encryption primitive encrypts and partitions the file, in a way that the file can be decrypted only when all the partitions of the encrypted data as well as the decryption key are available.

Proofs of Retrievability (PoR) are cryptographic proofs that enable a cloud provider to prove that the tenant can retrieve his file in its entirety. A tenant can ask the cloud provider to provide such proofs of a requested file without the need to download the file The aim of providing the PoR primitive is to provide strong assurance of storage integrity to the tenants.

If data is deployed on a server in an untrusted environment (e.g. the cloud), the data owner might be afraid of honest-but-curious database administrators or other personnel or external attackers who have access to the server. Our processing mechanism uses adjustable query-based encryption: The data is encrypted in so called onion encryption layers where the weakest encryption schemes are the innermost layers, which are then encrypted with other encryption schemes.

This tool allows cloud customers to migrate relational SQL databases into the cloud such that confidentiality is provided against the service provider but the database can still be queried.

This primitive could be used to prove the user/citizen/customer that some processing (like the liveness detection) has indeed been computed on the authentication data, thus enabling to check the conformance to (e.g. governmental) rules/standards.

This primitive could be offered as a service to perform biometric authentication on trusted servers while preserving the privacy of the data. It could also be simply adapted to validate ID doc against trusted data sources