When developing an application that manipulates medical data in a document exchange or chat platform, how do you protect this data in order to make it available to users such as practitioners, patients, pharmacists or insurance managers?
With the digital transformation of society - which has accelerated since the Covid-19 health crisis - many exchanges between patients and healthcare professionals can no longer take place face to face and are now done through dedicated digital solutions. The same applies to other activities handling medical data (insurance, credit, etc.).
The data exchanged is extremely sensitive for several reasons:
- such a data breach would be extremely damaging to the reputation of the service provider;
- the non-sovereign hosting of this data can be risky for politically exposed persons;
- it is personal data subject to the GDPR in the EU;
- they are medical data subject to medical secrecy under Article 226-13 of the Penal Code in France and subject to HIPAA in the US.
While the first two reasons may be considered speculative, the last two are associated with dissuasive pecuniary and penal sanctions (huge fines, imprisonment, etc.) that have already been applied in the past.
Protecting these data is therefore a strategic issue!
How to protect them effectively?
In France, it is necessary (Article L1111-8 of the public health code) to store health data on a certified health data hosting provider (HDS) (list of certified hosting providers), and on a HIPAA certified hosting provider in the US. Is this really sufficient?
Compliant hosting provider
HDS or HIPAA certified hosting providers offer a certain level of guarantee in terms of physical or logical access security to the servers and in terms of continuous improvement of security. However, this is not sufficient to ensure a satisfactory level of data protection: the data stored there would be readable by any attacker who managed to compromise the server.
If, moreover, the hosting provider is a foreign company, one can legitimately wonder about the sovereignty of the data!
Apart from the technical and geopolitical aspects, the use of an HDS does not meet the requirement of Article 32-a of the GDPR, which states that personal data must be anonymized, pseudonymized or encrypted.
In addition to an HDS, it is possible to use server-side encryption systems (with KMS, HSM or a key configured in the application). These are commonly offered by Cloud providers themselves. Are they really effective? What do they really protect against?
They reduce the attack surface. For example, if an attacker manages to compromise only the storage bucket, or the database, but not the application server, he will not be able to decrypt the data.
However, if the application server is compromised (which has all the pieces of the puzzle to reconstruct the data in clear text): the attacker would have access to everything. This kind of attack happens, even to companies that were thought to be tamper-proof!
The GDPR does not specify whether such an encryption solution meets the requirements of Article 32 or not, it remains deliberately vague by letting the cut-off point of the obligation of result fall in case of a leak.
The real solution to this problem is to ensure that servers no longer have access to sensitive data with client-side encryption, known as "end-to-end" encryption. Thus, if an attacker were to compromise the servers, he would not be able to access the data, since the keys to decrypt the data are not accessible to the server, and therefore not to any attacker either.
With the Seald SDK you can directly integrate end-to-end encryption into your applications on the data you want to protect, whether it is documents, database entries, etc.
The advantages of the Seald SDK are :
- its robustness: the Seald SDK has been audited by a third-party company and is in the process of being certified by ANSSI, thus ensuring that you use robust encryption primitives and key exchange protocols;
- its flexibility: it is possible to modify the persons authorized to decrypt a data a posteriori without modifying the stored data and to set up recovery mechanisms in case of loss of user keys (forgotten password, etc.);
A Rest API is obviously available to administer users, associate their Seald identity with the application identity and trace the activity (opening, modification of rights, etc.) of each user.
Protecting the medical data we collect, store and send is a strategic issue in today's digital world. The arsenal of possible solutions can sometimes stun decision-makers who must make a decision with a false sense of the security that the chosen solution provides.
Implementing true encryption solutions that protect user data from end to end is a daunting task, especially if you don't have any expertise in applied cryptography.
That's why Seald provides a turnkey SDK allowing you to integrate such technologies effortlessly and quickly without expertise in your solutions.