En ce qui concerne la sécurité informatique, la technologie quantique est la bombe à retardement qui va casser une grande partie des algorithmes cryptographiques (AES, RSA, ECC, etc.) utilisés dans les systèmes exploités par la majorité des citoyens quotidiennement (communications, banque, protection des données, etc.).

Cette présentation propose une vision de la technologie quantique : son fonctionnement, son utilisation pour améliorer la cryptographie actuelle, mais aussi les attaques quantiques et les solutions à ces attaques.

Is kwantumtechnologie de toekomst van de 21^ste eeuw? Dat is de vraag die talrijke wetenschappers zich momenteel stellen. Ondanks de onzekerheid hierover zijn de meesten akkoord over één punt: kwantumtechnologie gaat een ongeziene wetenschappelijke revolutie teweegbrengen.

Wat de informaticaveiligheid betreft, is kwantumtechnologie de tijdbom die een groot deel onderuit zal halen van de cryptografische algoritmes (AES, RSA, ECC, enz.) die gebruikt worden in systemen die de meerderheid van de burgers dagelijks benut (communicatie, banken, gegevensbescherming…).

Deze presentatie geeft een kijk op kwantumtechnologie: haar werking, het gebruik ervan om de huidige cryptografie te verbeteren, maar ook kwantum-aanvallen en de oplossingen hiervoor.

Presentation

En ce qui concerne la sécurité informatique, la technologie quantique est la bombe à retardement qui va casser une grande partie des algorithmes cryptographiques (AES, RSA, ECC, etc.) utilisés dans les systèmes exploités par la majorité des citoyens quotidiennement (communications, banque, protection des données, etc.).

Les attaques quantiques

Comme déjà expliqué dans un article précédent, les systèmes cryptographiques modernes sont généralement basés sur des problèmes mathématiques dits “durs”, ou “computationally infeasible” en anglais, c’est-à-dire qui n’admettent aucune solution efficace pour résoudre le problème. Par exemple, la sécurité de RSA repose sur le problème de la factorisation entière en nombres premiers : il est facile d’obtenir le produit de deux grands nombres premiers, par contre il est beaucoup plus difficile de trouver les facteurs premiers de celui-ci. Pour visualiser la difficulté du problème, prenons un premier exemple où le produit à factoriser est 91 : il n’est pas trop difficile de retrouver que 91 = 7*13 car ce sont de petits nombres. Maintenant, si nous prenons le nombre appelé RSA-1024 ci-dessous comme deuxième exemple, alors personne à l’heure actuelle n’a été capable de retrouver ses deux facteurs premiers. Jusqu’en 2007, la compagnie RSA Security offrait d’ailleurs 100 000 $ à la première personne réussissant l’exploit.

RSA-1024 = 135066410865995223349603216278805969938881475605667027524485143851526510604859533833940287150571909441798207282164471551373680419703964191743046496589274256239341020864383202110372958725762358509643110564073501508187510676594629205563685529475213500852879416377328533906109750544334999811150056977236890927563

Tout ceci est vrai lorsqu’on utilise des ordinateurs digitaux standards. Or la technologie quantique a complètement changé la donne à ce niveau-là : en effet, il existe aujourd’hui des méthodes exploitant les propriétés mécaniques de la technologie quantique sachant résoudre bon nombre de problèmes dits “durs”. Les deux plus connues sont les algorithmes de Shor et de Grover.

Algorithme de Shor

Cet algorithme a été créé en 1994 par Peter Shor, et il résout le problème de factorisation entière en nombres premiers en un temps polynomial, c’est-à-dire que le problème est considéré comme “faisable”. Ainsi, l’algorithme de Shor est capable de retrouver la factorisation de n’importe quel nombre utilisé par RSA en un temps réaliste. Le système cryptographique RSA est donc complètement cassé avec l’algorithme de Shor.

ALGORITHME DE Grover

Cet algorithme a été créé en 1996 par Lov Grover, et il résout le problème d’inversion de fonction en un temps sous-linéaire. Pour comprendre ce que cela veut dire clairement, prenons un exemple simple: la recherche dans un annuaire. 

Soit X le nom d’une personne, Y=F(X) le numéro de téléphone de cette personne X, et F la fonction qui représente l’annuaire (i.e. l’association d’un nom avec un numéro de téléphone). Avec cet annuaire, il est bien sûr très facile de retrouver Y sachant X : il suffit de chercher directement X, suivant l’ordre alphabétique, et on retrouve Y.

Par contre, ce même annuaire n’est pas trié par numéro de téléphone. Donc si on a un numéro de téléphone Y, alors il est très difficile de retrouver le nom X correspondant. En moyenne, pour un annuaire de 10 000 entrées, il faudra 5 000 essais avant de trouver le nom X. Donc pour N entrées, il faudra N/2 essais.

L’algorithme de Grover, lui, est capable de retrouver le nom X avec seulement √N essais. Donc pour un annuaire de 10 000 entrées, il lui faudra 100 essais ; et pour un annuaire de 25 millions d’entrées, il lui faudra seulement 5 000 essais.

Ce gain de temps est considérable en sécurité informatique. Il permet à l’algorithme de Grover de retrouver de façon très efficace n’importe quelle clé cryptographique utilisée dans les systèmes de chiffrement symétrique supposés sûrs (p.ex. AES) par les agences de sécurité internationales (p.ex. le NIST aux USA).

La cryptographie post-quantique

Même si à l’heure actuelle, il n’existe aucun ordinateur quantique permettant d’exécuter de façon efficace les algorithme de Shor et de Grover, la communauté scientifique cherche déjà à se prémunir des attaques quantiques.

Hash-based cryptography

La cryptographie basée sur les fonctions de hachage est une des méthodes les plus intéressantes comme alternative pour des schémas de signature électronique tels que RSA, DSA, ECDSA. En effet, en choisissant des clés cryptographiques suffisamment longues, ce type de cryptographie est résistant à l’algorithme de Grover. Notez qu’il faut quand même doubler la taille des clés pour assurer un bon niveau de sécurité face à la menace quantique.

Les principes de ce type de cryptographie sont détaillés dans la figure ci-dessus. Premièrement, Alice va choisir une clé privée et générer la clé publique correspondante avec une fonction de hachage h qu’elle va communiquer à Bob. Puis Alice va signer un document à l’aide de sa clé privée et envoyer le document signé à Bob. Ce dernier va simplement utiliser la clé publique d’Alice pour vérifier la validité de la signature.

Code-based cryptography

La cryptographie basée sur les codes correcteurs d’erreurs est une méthode assez ancienne (1978 avec le système de chiffrement de McEliece), mais l’intérêt de la communauté scientifique pour cette dernière est relativement récente. En effet, elle est connue aujourd’hui comme étant une alternative intéressante aux chiffrements asymétriques tels que RSA et ECC, tout en étant résistante aux attaques quantiques. Elle aussi nécessite des clés cryptographiques très longues pour résister à l’algorithme de Grover.

Les principes de ce type de cryptographie sont détaillés dans la figure ci-dessus. Premièrement, Bob va choisir une clé privée et générer la clé publique correspondante avec une KDF (Key Derivation Function) h qu’il va communiquer à Alice. Ensuite, Alice va chiffrer un document à l’aide de la clé publique de Bob tout en rajoutant volontairement des erreurs dans le chiffrement. Lorsque Bob va recevoir le document chiffré, il va utiliser sa clé privée pour déchiffrer le document. Comme l’algorithme de chiffrement/déchiffrement est spécialement conçu pour ajouter et enlever correctement les erreurs mises dedans, Bob va tout simplement retrouver le document déchiffré correct.

Il existe bien d’autres méthodes de cryptographie post-quantique. On peut citer la cryptographie multivariate ou la cryptographie basée sur les réseaux (“lattice-based cryptography” en anglais), cette dernière suscitant un grand élan de recherche dans le milieu académique, comme le prouve le site pqcrypto.org fondé par Daniel J. Bernstein et Tanja Lange.

Recommandations

Il est important de bien garder en tête que la technologie quantique n’est plus un rêve à l’heure actuelle. De grandes entreprises et puissances mondiales travaillent d’arrache-pied pour être les premiers à obtenir des résultats probants sur les calculs quantiques, mais aussi (et surtout) sur les attaques quantiques. Le premier qui saura réellement casser RSA-1024 aura acquis un pouvoir considérable dans le domaine de la sécurité informatique moderne.

Considérant donc ces faits comme inévitables, voici quelques recommandations sur comment se protéger au mieux des attaques quantiques.

1) La cryptographie asymétrique doit être post-quantique

Il faut commencer à migrer vers des bibliothèques qui implémentent des méthodes de cryptographie post-quantique. C’est le cas de la bibliothèque C open-source liboqs d’Open Quantum Safe.

2) La cryptographie symétrique doit être plus looooooooongue

Une façon simple et efficace de se protéger de l’algorithme de Grover est d’utiliser des clés cryptographiques très longues.

3) L’utilisation de hash-based crypto doit être réfléchie

Tout d’abord, en cas d’utilisation du schéma de Lamport ou du schéma de Merkle, les clés utilisées ne doivent servir qu’une et une seule fois, sinon il sera plus facile à un attaquant de retrouver les clés et de forger de nouvelles signatures. Aussi, comme ces méthodes sont basées sur des fonctions de hachage, la longueur des clés doit être suffisante, comme pour du chiffrement symétrique. Veillez à doubler la taille des clés pour être résistant aux attaques quantiques.

4) code-BASED CRYPTO est une méthode très lourde

L’utilisation de telles méthodes de chiffrement doit être bien considérée avant toute mise en place car la taille des clés publiques est très grande (> 9 Mbits), pouvant affaiblir fortement les performances de certains systèmes.

5) Lattice-based crypto n’est pas assez mature

En effet malgré leur côté très prometteur, ces méthodes sont trop récentes dans le domaine post-quantique, et il existe peu d’études démontrant leur fiabilité et résistance aux attaques quantiques. Il serait plus judicieux d’attendre quelques années avant de faire dépendre la sécurité de tout un système informatique uniquement sur ce type de cryptographie.

En complément

Pour une vision un peu plus large sur la technologie quantique, son fonctionnement, son utilisation pour améliorer la cryptographie actuelle, mais aussi les attaques quantiques et les solutions à ces attaques, le lecteur intéressé peut consulter les slides suivants.

Méthodes de tokenization

Il existe essentiellement deux méthodes de tokenization.

1. Vault-based tokenization

Avec cette méthode, il n’y a aucune relation mathématique, ni aucune logique entre la donnée originale et le token correspondant. C’est donc un mapping aléatoire unique “donnée-token”.

Pour chaque type de données, un mapping est généralement stocké dans une table, nommée lookup table (p.ex. figure 1 ci-dessous). Toutes les lookup tables sont alors stockées sur un serveur de tokens, comme représenté dans la figure 2 ci-dessous.

Cette méthode peut être problématique quand la quantité de données à tokeniser augmente perpétuellement. En effet, si les lookup tables ne font que grossir, alors (1) la taille du serveur de tokens doit sans cesse être augmentée, et (2) il est difficile de répliquer un serveur de tokens de taille trop grande ailleurs.

La vault-based tokenization est donc la méthode la plus basique, à utiliser de préférence pour un ensemble de données assez petit, qui ne varie pas ou n’augmente pas beaucoup.

2. Vaultless tokenization

L’autre méthode de tokenization consiste en créer une ou plusieurs lookup tables génériques par type de données, comme illustré dans la figure 3 ci-dessous. Pour une base de données simple, on peut ainsi seulement créer une lookup table pour les nombres, et une pour les mots. Ces lookup tables sont pré-calculées à l’avance et bien sûr randomisées. Elles sont donc d’une taille fixe, préférablement plus petite que les tables de la méthode vault-based.

Avec ces tables pré-calculées, il est alors possible de tokeniser les données correspondantes. Par exemple, la figure 4 ci-dessus illustre une tokenization d’un numéro de carte de crédit. Notons que cet exemple de tokenization très simple est montré ici pour son aspect didactique. Il est tout à fait possible d’imaginer une tokenization plus élaborée, plus complexe, par exemple qui se servirait de 2 lookup tables de nombres (au lieu d’une), et/ou qui mélangerait davantage les nombres (au lieu d’un simple bloc-par-bloc).

La vaultless tokenization est donc la méthode la plus adéquate lorsqu’on souhaite tokeniser des ensembles de données grands et dynamiques.

Pourquoi la tokenization est-elle une méthode intéressante?

Tout d’abord, le critère unique et aléatoire d’une tokenization est très intéressant : il empêche tout attaquant de détokeniser et de retrouver la donnée originale à partir du token sans avoir les lookup tables correspondantes. Ces dernières sont en fait l’équivalent d’une clé cryptographique “super-puissante” dans un système standard de chiffrement. Donc le niveau de sécurité d’une tokenization est très élevé. Bien sûr, ceci est valable que lorsque les lookup tables sont stockées de manière protégée. Aussi, les données, même tokenisées, sont utilisables “as-is”. il est donc possible de faire des SEARCH et des SORT dans une base de données tokenisées. Un des seuls points négatifs est la taille des lookup tables, qui peut s’avérer très grande si l’on utilise la mauvaise méthode de tokenization. Donc le lieu de stockage des tables doit être pensé en fonction de cela.

La tokenization est déjà utilisée dans plusieurs domaines où la sécurité est primordiale. Le plus courant est le milieu bancaire. Par exemple, la tokenization est souvent utilisée pour protéger les données stockées, comme demandé par le standard PCI DSS (Payment Card Industry Data Security Standard). Autre exemple : en mars 2014, EMVCo (consortium des grandes firmes bancaires telles que Europay Mastercard Visa) a publié une méthode de tokenization pour les paiements EMV. On peut aussi retrouver la tokenization dans les systèmes de données médicales, ou encore pour les casiers judiciaires.

En fin de compte, c’est une technologie très intéressante, qui n’est qu’à ses balbutiements en terme de déploiement pratique, mais qui s’annonce être une petite révolution dans la protection des données.

De webpagina World’s Biggest Data Breaches geeft een interactief overzicht van alle security breaches die sinds 2004 aanleiding hebben gegeven tot de meest in het oog springende dataverliezen.

Dans un précédent blog, j’évoquais la problématique du “batch signing” (“signature en lot” en français). Lorsqu’un utilisateur souhaite signer 100 documents avec sa carte eID belge, soit il tape manuellement son code PIN 100 fois, soit il utilise un logiciel qui met en cache son code PIN, ce dernier étant ensuite utilisé automatiquement par le logiciel pour signer un à un chaque document.

Smals Research a décidé proposer une alternative avec le logiciel SmalsBeSign. En effet, ce dernier calcule une signature digitale pour un ensemble de documents, en utilisant la carte eID belge. Le code PIN de l’eID, tapé une seule fois par l’utilisateur, n’est pas mis en cache : il est simplement utilisé une et une seule fois par SmalsBeSign pour calculer ladite signature. L’utilisateur a donc le contrôle total de son eID, de son code PIN et de sa signature.

Pour une explication fonctionnelle sur l’utilisation de SmalsBeSign, je vous propose de regarder la vidéo suivante.

Le logiciel SmalsBeSign ainsi que toute l’explication sur son fonctionnement sont disponibles sur la page web dédiée.

Bien que le modèle de sécurité Data-Centric amène un nouvel espoir pour l’avenir de la sécurité des données, je souhaite tempérer nos aspirations vis-à-vis du modèle en nuançant quelque peu ses bienfaits. C’est pourquoi je souhaite récapituler dans ce blog les points d’attentions et conclusions émises à la fin des deux présentations au sujet du modèle de sécurité Data-Centric.

1. La mise en place du modèle peut s’avérer délicate

Pour mettre en place une telle sécurité, un minimum de re-engineering est nécessaire au niveau des applications par où transitent les données. Pour des applications qui (de base) sont bien conçues, cet effort va être généralement minimal (quelques lignes de code à rajouter). Dans les autres cas, cela peut malheureusement vite devenir un casse-tête. Dans tous les cas, l’utilisation d’un tel modèle de sécurité au niveau des applications est une méthode légèrement intrusive.

2. La classification des données est une opération pesante

Comme je l’ai expliqué durant les présentations, la première étape pour mettre en place un tel modèle de sécurité est la classification des données : quelles sont les données sensibles? où sont-elles stockées? qui y a accès? etc. Toutes ces questions doivent être posées pour ensuite déterminer quelles données doivent être absolument protégées. Cette classification est un travail lourd et obligatoire. Notons néanmoins que, sauf grand changement dans une organisation, la classification des données ne doit finalement être effectuée qu’une et une seule fois (au début de la mise en place du modèle), et elle doit seulement être maintenue à jour par la suite. Donc ce lourd travail n’est finalement qu’exceptionnel.

3. Les opérations sur les DB peuvent se compliquer

Lors des présentations, j’ai expliqué qu’une protection des données Data-Centric nécessite que cette protection se fasse au niveau applicatif, dès que la donnée rentre dans un système informatique. Ceci a des implications au niveau des opérations faites sur les bases de données. Tout d’abord, l’accès direct aux bases de données n’est plus compatible avec la protection Data-Centric : par exemple, il n’est plus possible de modifier directement une donnée dans une base de données ; il faut passer par la couche applicative pour le faire. Par contre, les opérations en batch sur les bases de données peuvent toujours s’effectuer (la nuit par exemple), mais elles devront aussi nécessairement passer par l’application correspondante.

4. Les DBA sont toujours capables de faire leur job

Le point précédent n’empêche pas les DBA de faire leur travail. Avec un modèle de sécurité Data-Centric, les DBA ont toujours la possibilité de modéliser et d’optimiser les bases de données, de changer leur structure, de dimensionner les espaces de stockage, de gérer les désastres, etc. Comme les données ne sont plus stockées en clair dans les bases de données, le seul changement est que les DBA n’ont donc plus accès aux données en clair.

5. La problématique de la qualité des données est toujours là

Lors des présentations, j’ai expliqué que les meilleures méthodes de protection Data-Centric sont le format preserving encryption et la tokenization. Dans ces deux méthodes, une donnée protégée va être “transformée” (c’est-à-dire chiffrée ou tokenisée) de façon unique. Si les données ne sont pas de bonne qualité, alors la transformation ne sera pas de bonne qualité non plus. Par exemple, la donnée “tania” (sans majuscule) peut être transformée en “cYjzL” et la donnée “Tania” (avec majuscule) peut être transformée en “OWpzN“. Ceci peut donc être problématique dans un système informatique où la qualité des données n’est pas primordiale, comme par exemple ne pas tenir compte de la casse des mots.

6. Il faut protéger un système, pas seulement une DB, ni toutes les données

Comme je l’ai expliqué durant les présentations, le but d’un modèle de sécurité Data-Centric n’est pas de se focaliser sur la protection d’une base de données, mais de voir plus large et de protéger un système informatique dans sa globalité. En effet, cela ne sert à rien de protéger une base de données si, à côté, on retrouve les mêmes données non protégées. Pour ce faire, il est aussi important de se rendre compte que protéger toutes les données n’a pas de sens. Il suffit de protéger les données sensibles (telles que définies dans la classification) et les données qui donnent malgré tout de l’information sensible sans s’en rendre compte. Par exemple, même si elle n’est reliée à aucune personne, la taille donne beaucoup d’information personnelle : généralement si elle est inférieure à une certaine borne (p.ex. 1,20 mètre), on pourra considérer que c’est un enfant, sinon on pourra s’imaginer un adulte ou adolescent. Il faut donc protéger ces données partout dans le système informatique cible.

7. Le partage inter-institutionnel de données est difficile

A l’heure actuelle, il est très difficile d’imaginer la mise en place d’un modèle de sécurité Data-Centric dans plusieurs organisations collaboratrices. Ceci est principalement dû au fait qu’il faudrait désigner un unique security officer capable de gérer la politique de sécurité centralisée pour toutes les organisations. Néanmoins, si chaque organisation fait l’effort de mettre en place un même modèle de sécurité Data-Centric, avec les mêmes paramètres de protection des données, alors le partage inter-institutionnel de données serait clairement faisable.

8. Le prix d’un tel déploiement est élevé

Aujourd’hui, tenter l’aventure Data-Centric a un coût non négligeable. Tout d’abord, il faut investir dans différents produits commerciaux pour classifier, surveiller, auditer, alerter, protéger, etc. les données. Ensuite, il faut former les employés d’une organisation à utiliser les produits achetés, car les employés vont devoir changer leur manière de travailler et utiliser ces nouveaux produits. Enfin, il faut adapter les applications déjà déployées pour y intégrer la protection Data-Centric offerte par les produits choisis. Bref, tout cela a un prix.

9. Le modèle de sécurité data-centric augmente la protection de la vie privée

Finalement, la mise en place d’un tel modèle ne se résume pas juste à l’achat d’outil(s) supplémentaire(s). La protection Data-Centric est clairement complémentaire aux défenses périphériques déjà en place autour d’un système informatique. Elle met la donnée au centre de la protection, ce qui favorise la protection des données à caractère personnel, donc de la vie privée. Il y a fort à parier qu’un tel modèle soit d’une grande aide pour une organisation qui souhaite être compatible avec la GDPR.

Pour moi, le modèle de sécurité Data-Centric améliore grandement les systèmes informatiques, en se protégeant d’une manière tout à fait originale et innovante. C’est au final le futur de la protection des données vers lequel les organisations devraient se tourner petit à petit.

Notons que le modèle de sécurité Data-Centric peut être vu dans un contexte plus large qu’on appelle le Data-Centric IT. Pour les lecteurs intéressés, mon collègue Koen Vanderkimpen explique dans son blog d’avril 2016 comment mettre en place une telle technologie avec REST.

]]> https://www.smalsresearch.be/data-protection-2-0/ Wed, 29 Jun 2016 09:01:11 +0000 https://www.smalsresearch.be/data-protection-2-0/

Devenues reines des systèmes informatiques, les données sont le cœur de toute entreprise ou organisation. Elles sont rentrées, collectées, scannées, traitées, analysées, stockées, imprimées, transmises tous les jours, tout le temps. Bref, elles sont le pouvoir et bien souvent la chose la plus précieuse qu’une entreprise ou organisation possède. Et les données sont stockées dans divers lieux : bases de données, data warehouses, fichiers, cloud, etc.

A l’heure actuelle, on s’attarde plus à protéger ces lieux de stockage que les données elles-mêmes. Les organisations déploient ainsi tout un arsenal de défenses périphériques, avec tant des murs physiques que des murs virtuels, pour protéger les lieux de stockage. Malgré cet effort de protection, la plupart des spécialistes en sécurité ne cessent de le répéter : « La question à se poser n’est pas ‘si’, mais ‘quand est-ce qu’une cyberattaque va avoir lieu dans votre organisation ! ». Et ces mêmes spécialistes s’accordent à dire que les défenses périphériques n’amèneront qu’un retard à la réussite (certaine) d’une cyberattaque.

Durant la session d’information, nous présenterons un modèle de sécurité centré sur les données : le ‘data-centric security model’. Contrairement aux autres méthodes de protection mentionnées ci-dessus, ce modèle se focalise sur la protection des données elles-mêmes. Il a pour but de protéger toute donnée dite sensible partout et à tout moment, dès qu’elle est introduite dans le système informatique d’une organisation, que la donnée soit utilisée, en transit ou stockée. Il permet donc de déployer une sécurité globale et homogène dans l’organisation.

Nous parcourrons les six étapes à déployer pour mettre en place le modèle. Nous expliquerons entre autres en quoi la classification des données est importante pour mettre en place une protection ‘data-centric’ efficace. Nous détaillerons également les différents mécanismes cryptographiques qui peuvent être utilisés dans le modèle ‘data-centric’. Le tout sera illustré via des exemples sur base d’un produit concret.

Data zijn tegenwoordig het koninginnestuk van de informaticasystemen en vormen het hart van elke onderneming of organisatie. Elke dag worden ze ingebracht, verzameld, gescand, verwerkt, geanalyseerd, opgeslagen, afgedrukt en overgedragen. Ze zijn met andere woorden het symbool voor de macht en zijn vaak het belangrijkste bezit van een onderneming of organisatie. Data worden ook op verschillende plaatsen opgeslagen: databases, datawarehouses, bestanden, in de cloud, etc.

Momenteel houdt men zich meer bezig met het beschermen van deze opslagplaatsen dan de data zelf. Organisaties ontwikkelen op die manier een hele uitrusting aan perifere verdedigingen, met zowel fysieke als virtuele muren om de opslagplaatsen te beschermen. Ondanks deze inspanning om ze te beschermen blijven veiligheidsexperten herhalen dat: “de vraag niet is of, maar wanneer er een cyberaanval zal gebeuren in uw organisatie”!  En diezelfde experten zijn het met elkaar eens dat perifere verdedigingen een cyberaanval weliswaar kunnen vertragen maar niet kunnen stoppen of verhinderen.

Tijdens de infosessie zullen we een veiligheidsmodel voorstellen dat focust op data, het ‘data-centric security model’. In tegenstelling tot de andere beschermingsmethodes die hierboven vermeld worden, richt dit model zich op de bescherming van de data zelf. Het heeft als doel om elk gevoelig gegeven eender waar en op welk moment ook te beschermen zodra dit gegeven in het informaticasysteem van een organisatie terechtkomt, of het nu om een gebruikt gegeven, een gegeven in transit of een opgeslagen gegeven gaat. Hiermee kan dus een globale en homogene veiligheid op poten gezet worden in de organisatie.

We overlopen de zes stappen die geïmplementeerd moeten worden om het model in te voeren. We leggen onder andere uit waarom dataclassificatie belangrijk is om voor een efficiënte ‘data-centric’ bescherming te zorgen. We zullen eveneens de verschillende cryptografische mechanismen bespreken die gebruikt kunnen worden in het “data-centric” model. Alles zal geïllustreerd worden via voorbeelden op basis van een concreet product.

Presentation

Un des mécanismes les plus connus pour assurer l’intégrité d’un message est la signature électronique. Le blog du 8 mars 2016 de mon collègue Bert Vanhalst explique déjà les opportunités et obstacles de la signature électronique. La figure ci-dessous dépeint comment le schéma de signature fonctionne. Reprenons l’exemple d’Alice qui souhaite envoyer un message (“data” dans la figure ci-dessous) à Bob. Pour ce faire, Alice a tout d’abord besoin d’une paire de clés publique/privée et d’un certificat électronique contenant la clé publique d’Alice et attestant que la paire de clés d’Alice est authentique.

Alice signe son message de la façon suivante :

1. Tout d’abord, elle applique une fonction de hachage à son message et obtient ainsi un hash du message.
2. Ensuite, elle chiffre le hash avec sa clé clé privée (connue d’elle seule) et obtient la signature de son message.
3. Enfin, elle attache la signature et son certificat au message, et envoie le tout (i.e. “digitally signed data” dans la figure ci-dessous) à Bob.

Lorsque Bob reçoit le “digitally signed data”, il vérifie la signature de la façon suivante :

1. D’un côté, il applique la fonction de hachage sur le message en clair d’Alice (i.e. “data”), et obtient un hash que nous nommeront H₁.
2. De l’autre côté, il vérifie la signature d’Alice en déchiffrant la signature avec la clé publique d’Alice (qui se trouve dans le certificat joint), et il recouvre le hash contenu dans la signature.
3. Enfin, il vérifie si ce hash est égal à H₁. Si tel est le cas, alors la signature est vérifiée, ce qui veut dire que le message original envoyé par Alice a gardé son intégrité.

Nous ne détaillerons pas dans ce blog ni les certificats électroniques, ni les fonctions de hachage. Pour plus d’information à ce sujet, le lecteur intéressé trouvera de plus amples informations ici pour les certificats électroniques et ici pour les fonctions de hachage.

En Belgique, tout citoyen a la possibilité de signer électroniquement des messages ou documents grâce à sa carte d’identité électronique, ou eID. En effet, l’eID est une carte à puce qui intègre tous les standards technologiques de cryptographie à clé publique (i.e. Public-Key Infrastructure (PKI) en anglais). Chaque eID possède donc une paire de clés publique/privée et un certificat électronique qui identifie et authentifie de façon unique chaque citoyen.

Lorsqu’un citoyen souhaite signer un document, il rentre simplement son code PIN et la démarche expliquée dans la figure ci-dessus s’applique. S’il souhaite signer 100 documents (méthode appelée “signature en lot”, ou “batch signing” en anglais), il doit taper 100 fois son code PIN. Ceci n’est clairement pas ergonomique. Malheureusement à l’heure actuelle, la seule autre solution facilitant le processus du citoyen est d’utiliser un logiciel qui met tout bonnement en cache le code PIN tapé et qui réutilise ce cache pour signer automatiquement les 100 documents. Ceci n’est clairement pas acceptable en terme de sécurité. En effet, l’utilisateur perd la maîtrise du code PIN, et plusieurs scénarios catastrophes sont imaginables. Par exemple, un logiciel malveillant pourrait s’en servir pour signer des documents autres que les 100 documents désignés par le citoyen. Ou bien le cache contenant le code PIN pourrait être volé et utilisé à mauvais escient.

Il n’existe à l’heure actuelle aucun standard pour le batch signing où le citoyen ne doit rentrer qu’une seule fois son code PIN tout en en gardant sa maîtrise. Si une solution fait surface, nous vous la présenterons dans un prochain blog.

UPDATE 06/10/2016 : Depuis la publication de ce post, Smals Research a publié SmalsBeSign, un software qui résout le problème évoqué ci-dessus. Le logiciel SmalsBeSign ainsi que toute l’explication sur son fonctionnement sont disponibles sur la page web dédiée.

La YesCard : le début des fraudes

La première fraude connue sur les cartes bancaires est la YesCard, une fausse carte bancaire française qui accorde un transfert d’argent (i.e. dit “oui”) peu importe le code PIN tapé par l’utilisateur. Avant d’expliquer comment l’attaque fonctionne, il est important de comprendre comment le protocole de paiement fonctionne.

Le protocole de paiement par carte bancaire francaise

Le protocole pour le paiement par carte bancaire à un terminal de paiement (p.ex. chez un commerçant) a été mis au point au début des années 1990. Sa version de l’époque (simplifiée ici) se compose des étapes suivantes.

1. Authentification de la carte. Comme illustré dans la figure ci-dessous, le terminal demande à la carte de s’authentifier. Pour cela, la carte va renvoyer deux valeurs qui sont stockées en clair dans sa mémoire :
   1. ses données nom, prénom, numéro carte, date de validité, et
   2. une signature de ses données qui a été faite par une clé cryptographique secrète appartenant au Groupe des Cartes Bancaires de France.

   Le terminal va ensuite vérifier que la signature est correcte.

2. Vérification du code PIN. Le terminal demande ensuite au client de rentrer son code PIN, et transmet en clair le résultat à la carte. Cette dernière va simplement comparer la valeur reçue avec la valeur stockée : si les deux valeurs sont identiques, alors la carte répond OK au terminal.
3. Authentification en ligne. Nous ne détaillerons pas cette étape ici car elle n’est d’aucune utilité pour la compréhension de la YesCard. Sachez néanmoins que cette étape ne s’exécute que pour certaines transactions, typiquement pour des montants supérieurs à 100€. Le terminal va alors jouer le rôle de relais pour une authentification entre la carte et un centre de contrôle se trouvant à distance.

Retour sur la YesCard

En 1998, Serge Humpich, ingénieur informaticien de profession, fait la une des journaux français. En effet, il met en avant deux failles de sécurité importantes du protocole de paiement par carte bancaire de l’époque.

• Faille logique. Les informations renvoyées par la carte lors de l’étape 1 d’authentification, “Données” et “Signature(Données)”, sont écrites en clair sur la carte. Notons qu’il est aussi tout à fait possible de créer une fausse carte bancaire qui répond OK pour n’importe quel code envoyé (une simple YesCard). Donc avec ces deux éléments, Humpich prouve qu’il est possible de cloner n’importe quelle carte bancaire valide, et abuser n’importe quel terminal pour les étapes 1 et 2.
  Sachant que la majorité des terminaux n’exécutent que ces étapes-là, Humpich fait la démonstration de sa trouvaille en achetant un carnet de tickets de métro à une borne automatique.
• Faille cryptographique. Le système de chiffrement utilisé par les cartes bancaires n’est autre que le célèbre chiffrement asymétrique RSA. Le problème est qu’en 1998 les clés utilisées par le système bancaire ne font que 320 bits de long, c’est-à-dire que les clés se sont pas du tout sûres, et ce depuis 1988. Grâce à cette faille, Humpich retrouve très simplement et rapidement la clé secrète du Groupe des Cartes Bancaires de France utilisée pour signer les données de n’importe quelle carte. Il est donc en mesure de fabriquer une fausse carte bancaire, sans avoir besoin de partir des informations d’une carte bancaire valide.

Humpich est traîné en justice pour “falsification de cartes bancaires et introduction frauduleuse dans un système automatisé de traitement”. Le Groupe des Cartes Bancaires de France a néanmoins pris en compte ses découvertes, et ainsi amélioré et standardisé le protocole de paiement. C’est dans ce but que le consortium EMV (Europay, Mastercard et Visa) est né. Maintenant, le monde entier suit le standard EMV pour les transferts d’argent via carte bancaire.

Skimming aux distributeurs

Un autre type de fraude très développé consiste en la méthode dite du skimming, qui consiste en copier la piste magnétique de la carte bancaire à l’aide d’un lecteur mémoire appelé skimmer. Le modus operandi de l’attaque est d’une simplicité déconcertante. Typiquement, les malfaiteurs viennent en premier lieu repérer les terminaux de paiement cibles dans les magasins, en tant que clients. Une fois les renseignements récoltés, ils reviennent et passent à l’action : généralement les escrocs profitent d’un moment d’inattention du personnel pour échanger le terminal cible du magasin par un autre terminal parfaitement identique mais pourtant trafiqué. La seule différence est que le faux terminal est équipé de la technologie Bluetooth, d’un skimmer, et éventuellement d’une caméra dont le but est de filmer les code PIN tapés par les utilisateurs. Après quelques heures ou jours, en fonction du nombre de clients dans le magasin, un des escrocs revient sur les lieux du crime et se place à proximité du faux terminal. En quelques secondes, il transfère toutes les données enregistrées par le faux lecteur sur son smartphone via Bluetooth grâce à une simple application. Une fois les coordonnées bancaires et les codes PIN recueillis, des clones de ces cartes sont fabriqués et utilisés partout dans le monde sans aucun blocage.

Ces attaques menées contre les terminaux de paiement sont finalement la menace la plus importante et la plus efficace. Par exemple, une telle attaque contre Home Depot aux Etats-Unis en 2014 a permis aux malfaiteurs de récolter les données de 56 millions de cartes bancaires en l’espace de quelques mois. En 2013, une attaque similaire contre la chaîne de supermarchés Target a compromis plus de 40 millions de cartes bancaires. L’ultra sécurisation des protocoles de paiement n’a donc aucun effet à ce niveau-là, les escrocs arrivant simplement à exploiter les faiblesses logicielles des terminaux de paiement.

Attaques par relais

Les cartes bancaires sont également victimes des attaques dites “par relais”, à l’origine un type de fraude plutôt destiné aux communications sans fil (p.ex. RFID, Bluetooth, WiFi). L’attaque par relais permet simplement au malfaiteur de relayer les messages entre deux entités, le but étant d’usurper l’identité ou les droits d’un utilisateur. La figure ci-dessous illustre les différents types d’attaque par relais.

Un exemple simple avec les cartes bancaires est le cas où un escroc voudrait faire payer un objet de luxe à une victime, alors que la victime pense payer un objet peu coûteux. Imaginons que la personne cible voudrait payer son repas à la cafétéria de son entreprise. Lorsqu’elle présente sa carte au faux lecteur d’un employé-escroc, celui-ci relaie la transaction via un laptop connecté au réseau à un complice situé chez un bijoutier. Ce dernier est lui-même équipé d’une carte bancaire contrefaite et d’un smartphone pouvant relayer les informations reçues par son complice. En synchronisant l’achat d’un bijou de luxe avec le paiement du repas, la victime valide donc sans le vouloir l’achat des escrocs alors qu’elle pense être en train de payer le prix raisonnable de son repas. Un article scientifique a démontré la réalité de cette attaque en 2008.

A l’heure actuelle, les seules contre-mesures connues pour les attaques par relais sont les protocoles de distance-bounding. Ces protocoles sont une solution développée pour les systèmes sans fil de type RFID (voir aussi mon Techno sur “Le b.a.-ba de la RFID“), car ils s’assurent que la carte RFID est physiquement dans le rayon d’action proche du lecteur RFID. Ceci se fait en calculant le temps de réponse d’une carte RFID quand elle est en communication avec un lecteur. Ce n’est malheureusement pas applicable aux cartes bancaires classiques car ces dernières sont des cartes “avec contact”, c’est-à-dire qu’on insère la carte dans le lecteur et que la puce est directement en contact avec le lecteur. Mais cela pourrait résoudre les problèmes soulevés dans la section suivante.

NFC : encore des failles dans le protocole de communication

De nos jours, le monde bancaire se veut de plus en plus sophistiqué. Les utilisateurs veulent que les paiements soient de plus en plus faciles et modernes. De là est née l’idée d’incorporer la technologie NFC (Near Field Communication) dans les cartes bancaires. Cette nouvelle technologie permet à un utilisateur de payer des petits achats en passant simplement sa carte bancaire devant un lecteur NFC. Le paiement se fait via une communication sans fil, et l’utilisateur n’a plus besoin de taper son code PIN pour valider l’achat.

Et ce dernier point est la grande faiblesse de ce nouveau moyen de paiement, comme l’ont démontré cinq chercheurs en sécurité de l’université britannique de Newcastle. L’exemple est simple : imaginez un escroc se baladant dans le métro avec un smartphone dans la main ; à chaque fois que le smartphone se trouve à une faible distance (quelques centimètres) d’une carte bancaire NFC (situation complètement réaliste aux heures de pointe), il valide un paiement bancaire pouvant aller jusqu’à 999.999,99€ ! Cela parait complètement fou, mais pourtant c’est ce que les chercheurs ont trouvé. En analysant le protocole EMV pour la communication sans fil, ils ont trouvé une importante faille qui permet de contourner la limite définie pour les transactions NFC. Celle-ci est de 20£ au Royaume-Uni (20€ dans le reste de l’Europe). Pour dépasser cette limite, il suffit de faire une transaction dans une monnaie autre que celle de la carte en question. Les chercheurs ont pu valider leur attaque sur des cartes Visa avec un montant maximum de 999.999,99€ et 999.999,99$. De plus, ces transactions peuvent se faire en offline, c’est-à-dire sans être connecté en direct à un centre de contrôle distant (autorisé par le standard EMV). L’escroc peut ainsi collecter tranquillement en offline des transactions auprès de ses victimes. Ensuite, les chercheurs ont montré que l’on pouvait décharger ces transactions sur n’importe quel système de paiement d’un marchand complice affilié au réseau EMV, pour les envoyer ensuite aux banques des victimes. Il suffit pour cela d’ajouter aux transactions stockées les données relatives à ce marchand. Cela est possible car les données du marchand ne sont pas utilisées par la carte NFC pour valider la transaction.

Notons que les cartes Mastercard ne sont pas vulnérables à cette attaque, car elles n’autorisent pas le mode offline pour les transactions en monnaie étrangère. Notons aussi que l’attaque a été publiée à CCS 2014 et les groupes bancaires ont rajouté des contre-mesures pour se prémunir de ce type d’attaques.

En conclusion…

Il est difficile de tirer une conclusion positive de la thématique. En effet, ce blog n’a expliqué que les attaques les plus connues et répandues sur cartes bancaires. Mais soyez certains qu’il en existe encore beaucoup d’autres. Faite très attention au skimming, qui est l’attaque la plus répandue et la plus dangereuse. Pour cela, ne mettez votre carte que dans des lecteurs “de confiance”, et cachez bien votre main lorsque vous tapez votre code PIN. Pour les cartes NFC, un moyen efficace de se protéger au quotidien contre des transactions non voulues (pour les plus paranoïaques) est de mettre sa carte dans un portefeuille RFID-blocker, sorte de cage de Faraday qui bloque les ondes électromagnétiques. Dans tous les cas, la vigilance doit être de mise quand vous utilisez votre carte bancaire.

Het is onmogelijk om de voordelen van de cloud te ontkennen. Om er slechts enkele te noemen: vermindering van de kosten, een grotere evolutiviteit, een betere mobiliteit, een sneller deployment en instant updates. De veiligheidsrisico’s vormen echter nog steeds de voornaamste reden waarom organisaties en bedrijven de cloud niet volledig omarmen. Deze research note heeft als doel de gekende en bestaande cryptografische mechanismen voor te stellen waarmee de gegevensopslag en -verwerking beschermd kunnen worden in de cloud-omgevingen.