Tresorit offers an authentication and encryption platform (ZeroKit), that is unique in terms of the level of security among other solutions on the market. We employ zero-knowledge techniques in our stack to provide the highest available security, while maintaining a simple, easy to use interface for application developers. We solve problems for:

  • Companies who handle healthcare, financial or personal data and wish to remain compliant and safely store the data of their customers.
  • For application providers as they no longer have to trust the cloud provider and can be sure that application developers cannot make mistakes with leaking important data.

Our SDK allows application developers to encrypt the data at the moment of creation - right in the browser or mobile device of the end-user. The data never travels to the cloud in a non-encrypted form; thus neither your cloud provider, nor your application developer, nor Tresorit, nor potential hackers are able to interpret the data, even if they gained access to it. Our goal is to provide a holistic answer to data encryption: covering user identity, password and key management, data encryption on client devices, in transit and at rest.

Based on the industry standard practices, we can define "levels" of security that a cloud file storage provider can offer to its customers:

  1. No encryption at all: Fortunately this is not common, but an example of this would be an FTP server.
  2. (Transport) channel encryption: The communication channels between the end user's device and the service provider's server are encrypted, most commonly by utilizing HTTPS (SSL/TLS) communication protocol. This way malicious people cannot eavesdrop the communication (for example by listening to public WiFi hotspot communications). However, your data is stored on the servers in plain text. So the employees of the company can access files, or much worse, if hackers can break into their systems, they could also access all data.
  3. At rest encryption: This adds encryption to the server side: the service provider encrypts the data after receiving it and before storing it. This gives additional protection against hackers, because it would not be enough for them to access stored files, but they would have to obtain the encryption keys as well. This is not impossible, but makes hacking harder. Note, that in this model the encryption keys are handled by the service provider, so their administrators, scripts, etc. are still able to see files in an unencrypted format.
  4. Client side encryption: The encryption happens on the end-users device, only they have access to the encryption keys. The files are protected throughout the whole journey: they leave the computer, get transferred to the server, stored there and finally downloaded again to another device. Please note that this alone would leave channel and at rest encryption unnecessary. Also, it's clear that client side encryption is secure only if the encryption keys are handled properly. Sending or sharing the encrypted keys in any insecure manner (eg. via email or unprotected transport channel) would be equivalent of sending the files the same insecure way. Managing and sharing encryption keys securely becomes a challenge with client side encryption.
  5. Zero knowledge encryption: This scheme does not add additional security in the common sense, but rather guarantees that client side encryption is used properly. Zero knowledge algorithms and protocols ensure that no keys, passwords, files, or any sensitive material ever get transferred in an unencrypted or reversible form. There is no point in time when encryption keys or unencrypted files are visible to the servers or service administrators. This rules out another attack factor: the service provider.

The ZeroKit SDK offers zero-knowledge encryption, because the keys and passwords of the end-users never leave their computer in a way that it would be readable to eavesdroppers, service administrators or even the developers of the application.

Suggested architecture

The ZeroKit tenant server provides basic user management with authentication, an internal zero-knowledge key management service, and an OpenID Connect identity provider. This is not a full application, only a building block that an integrating application can use. It's important to know, that the tenant server doesn't store any user data besides the minimum required for authentication and encryption. The application backend must store all additional data on it's own. This data usually consists of at least the needed tokens for the registration flow (Common flows), the username-userid mapping, list of tresors, the structure of shared tresors and all application specific encrypted data.

The ZeroKit Web SKD (referred to as zkit_sdk in the source) is hosted on the tenant server by default but can be hosted on the application server as well.

results matching ""

    No results matching ""