Data security: how does encryption work? The Kls example

5 minutes de lecture
3/5/25 9:51 AM
Data security: how does encryption work? The Kls example
8:23

In a world where data confidentiality is a major concern, safeguarding and securing it is becoming a priority. File encryption is proving to be an essential shield for protecting the security of sensitive information. Through this article, we explore the different types of encryption, and present how, at Kls, we implement the measures necessary to preserve the confidentiality of our users' data on our platform.

The different types of encryption

Data encryption relies on algorithms, i.e. a set of rules and procedures for converting data into a format unreadable by anyone who doesn't have the corresponding decryption key. There are two main families: symmetrical, asymmetrical.

Symmetric encryption

In symmetric encryption, one and the same key is used to both encrypt and decrypt data. It's like having a single key to lock and unlock a safe. This method is very fast and effective for securing large amounts of data. However, it presents a major security challenge: managing and protecting that key. If someone intercepts this key, they can easily access all the data secured with it. This is why symmetric key security is of paramount importance.

Asymmetric encryption

Asymmetric encryption works with a pair of keys. A public key is generally used to encrypt the data, while decryption is usually done using a private key. You can compare this to a safe in which anyone can deposit something inside using the public key, but only the owner of the safe (who has the private key) can open and access the objects inside. This method is more secure, as the private key remains secret and is never shared with other parties. However, it is often slower than symmetrical encryption due to the complexity of the calculations involved. This is the system on which the encryption of most Internet exchanges (notably the HTTPS protocol) is based.

End-to-end encryption

Today, a large number of messaging services (iMessage, Signal, WhatsApp...) feature end-to-end encryption of messages. This is a method that ensures that only the sender and recipient can access the data, as it is encrypted from the moment it is created and decrypted only at its final destination. In general, this system is based on asymmetrical encryption.

This involves advanced management of keys, which in essence must be accessible only to the sender and recipient. It is therefore ruled out that keys can be stored on a central server that would involve a third party.

The Kls case: context

Our platform enables the exchange of documents between authorized persons, within different credit institutions, as well as with their customers.

As part of their activities, our users need to add and remove access to certain data throughout its lifecycle.

Challenges

  • End-to-end encryption would require:
    • on the one hand, that data be encrypted directly on users' workstations before being stored on our servers.
    • on the other hand, that the decryption keys be known to all current and future users who will need to access the data, without these keys being stored on our servers.
  • Encryption on users' workstations is not a problem, but decentralized key exchange is.
  • It would be necessary to communicate the decryption key each time new access is given to a user so that he can store it on his workstation.
  • It would also be necessary for keys to be retained when a user changes a computer, for example.

While there are solutions to some of the challenges identified, key management remains complex with an impact on the platform's ease of use. As the Kls Desk is in essence a platform that enables information to be centralized, securely and simply, it's up to us to carry the burden of complexity by providing security and comfort to our users in managing keys throughout their lifecycle.

Solutions

With all data encryption and decryption carried out on our infrastructure, and the keys known only to us, we are opting to use a symmetrical encryption algorithm to gain in simplicity and speed.

These include DES, AES and Blowfish. These algorithms generally offer several variants. In our case, we chose to use AES (Advanced Encryption Standard) with 256-bit keys, which is currently the highest level of encryption recommended in particular by the NIST (National Institute of Standards and Technology) and the ANSSI (Agence nationale de la sécurité des systèmes d'information).

Data and key storage

Once the data has been encrypted, several elements need to be put together to be able to decrypt and read it. It's similar to putting together a jigsaw puzzle. For Kls to decrypt the data, we need the encrypted data and its encryption key.

The golden rule

The first security measure is to never store encrypted data and its decryption key in the same place. In this way, data and encryption keys are stored in separate locations within our infrastructure, and only pass through the memory (encrypted, too) of our servers, without being stored there.

Limiting the risk

To limit the impact that leaking a key or encrypted data could have, each file uses a different encryption key (DEK in the animation below).

Let's take an example with the theft of a malicious actor:

  • If he manages to recover a key, he would only be able to decrypt the information in a single file, not the entire data set.
  • Inversely, if it were to recover all the encrypted data, it would then have to find as many keys as files to decrypt.

To illustrate:

Encryption

"One more thing"

In order to add a level of security to the encryption keys themselves, we've set up a system that relies on a master key that encrypts all the unique keys (KEK in the animation above). This master key allows us to add a piece to the puzzle that encrypts documents by adding a third factor located in a third place in our infrastructure.

Infrastructure encryption

Like most hosting providers, ours integrates encryption mechanisms on most of the services it offers. This is particularly the case for cold storage services, databases or web servers.

In addition to the encryption we apply specifically to our users' data, at Kls we have chosen to encrypt everything within our infrastructure itself.

Thus, our hard disks, server memory, storage spaces, databases and backups are encrypted "at rest" ("encryption at rest"). This means that if someone had "physical" access to these items, they would still not be able to see the underlying documents (encrypted by us) as they would not be recognizable.

Similarly, data is encrypted "in transit", i.e. during communications between the various elements of the infrastructure. So, even if someone could "read" the data in transit on the network, they would still not be able to access the information.

All these measures ensure the security of our data and that of our customers by preventing any third party from accessing the content of our data, even with direct access to the servers.

Data location

We are particularly sensitive to data protection and data sovereignty. As a French and European player, we have chosen to store all our platform data exclusively in France and Ireland. What's more, our hosting provider is ISO 27001 certified, enabling us to rely on a solid, verified foundation.

Conclusion

As a platform provider enabling the exchange of sensitive and confidential information, we have a duty to provide the highest level of security not only to our customers, but also to all our users. We are therefore implementing all the measures appropriate to this challenge, encrypting our entire infrastructure and applying additional encryption according to an advanced system involving several factors distributed in several places.

If we can consider that today, Kls offers a high level of security, we mustn't forget that cybersecurity is a constantly evolving subject. Both technologies and the knowledge of malicious actors are constantly improving, and we must continue to keep pace with market developments. Certain technologies, such as quantum computing in particular, are likely to call into question data security as we know it today. Certain players such as the French and German central banks have begun experiments with this type of encryption.