La sécurité doit faire l’objet d’une attention particulière lors du choix d’une solution de type cloud. En effet, mettre ses données dans le cloud implique a priori que l’on perd le contrôle sur ces données et que l’on fait confiance au fournisseur de services cloud pour protéger ces données. L’un des aspects de cette protection est la confidentialité : que fait mon fournisseur des données confidentielles (les miennes ou celles de mes utilisateurs) ? Même si le fournisseur a pris les mesures suffisantes pour correctement protéger les données par rapport à des attaquants externes, le fournisseur lui-même a accès à ces données et un gouvernement pourrait exiger qu’il les lui transmette (voir l’exemple du Patriot Act aux États-Unis).

Certains produits récents et innovants offrent des solutions de chiffrement pour les organisations qui souhaitent utiliser des services cloud tout en gardant l’assurance de la confidentialité de leurs données. On peut classer ces produits dans deux catégories : d’une part, des solutions de stockage dans le cloud orientés utilisateur avec chiffrement. D’autre part, les « Cloud Security Gateways », conçues pour utiliser des applications cloud spécifiques comme Gmail ou Salesforce. Dans ces deux catégories, un point important est l’approche utilisée pour chiffrer les données : elles sont chiffrées avant d’être envoyées dans le cloud et avec des clés dont l’utilisateur ou l’entreprise garde toujours le contrôle. Ainsi, le fournisseur cloud n’a jamais accès aux clés et ne peut donc pas déchiffrer les données.

Chiffrement pour stockage cloud orienté utilisateur

Il existe de très nombreux services de stockage cloud orientés utilisateurs. Quelques-un des plus connus sont Dropbox, Google Drive, et Microsoft SkyDrive. Ces services permettent à un utilisateur de stocker ses documents dans le cloud, afin d’y accéder depuis plusieurs appareils, de les partager avec d’autres utilisateurs, ou de disposer d’une forme de backup online. Dans ce domaine, pour protéger la confidentialité des données par rapport au fournisseur cloud, trois approches sont possibles, et le choix d’une approche doit être fait en prenant en compte la simplicité d’utilisation et le niveau de sécurité voulu.

• Utiliser un service cloud comme SpiderOak qui offre de bonnes garanties de sécurité et permet le chiffrement des données localement.

• Utiliser un outil dédié comme BoxCryptor ou CloudFogger qui chiffre les données localement en combinaison avec un service cloud qui synchronise les données.

• Utiliser un outil de chiffrement plus généraliste comme TrueCrypt et synchroniser le container avec le service cloud.  Cette solution offre un excellent niveau de sécurité, mais est plus complexe d’utilisation, et elle limite les possibilités de partage.

Dans tous les cas, c’est l’utilisation via mobile qui est à l’heure actuelle limitée : les applications mobiles permettent seulement de lire les données depuis le mobile mais pas de synchroniser un répertoire présent sur le mobile. Cette situation évoluera certainement très vite.

Chiffrement pour autres applications SaaS

Les Cloud Security Gateways sont des produits conçus pour permettre aux employés d’une organisation d’utiliser des applications SaaS tout en chiffrant tout ou partie des données de l’application. Le principe est d’utiliser un gateway qui est localisé soit dans l’organisation soit chez un tiers. Voici un schéma qui montre le cas où le gateway est dans l’organisation :

Ce marché est en plein essor et de nombreuses solutions sont en train d’apparaître. Certes Networks, CipherCloud, Concealium, Intel, PerspecSys, Symantec sont parmi les principaux acteurs. Chaque produit vise une application SaaS spécifique ; parmi les plus souvent rencontrées, on peut citer Salesforce, Office 365 ou Gmail.

Le choix d’un tel produit permet un gain de sécurité. Les données les plus sensibles sont chiffrées avant d’être envoyées vers le fournisseur SaaS et les clés sont gardées au sein de l’entreprise. La confidentialité de ces données vis-à-vis du fournisseur SaaS est donc assurée.  Par ailleurs, certaines des fonctionnalités de l’application ne sont pas affectées : citons par exemple CipherCloud pour Gmail qui permet de faire une recherche dans ses emails (alors qu’ils sont stockés de manière chiffrée sur les serveurs de Google).

L’expérience montre toutefois que l’utilisation d’un Cloud Security Gateway présente certains inconvénients :

• Impact sur les performances : l’utilisation entraîne une latence qui dépend notamment de la connexion avec le gateway.
• Impact sur la disponibilité : on devient dépendant de la disponibilité du gateway, en plus de celle du fournisseur SaaS.
• Impact sur les fonctionnalités : certaines sont préservées, mais d’autres ne marchent plus.
• Coût du gateway (licence) qui vient s’ajouter au coût de l’application elle-même et nécessité d’administrer le gateway.
• Limites en termes de sécurité : tout n’est pas caché aux yeux du fournisseur Saas.

Ces produits demandent donc de renoncer à certains des avantages du SaaS ; en contrepartie, ils offrent un réel gain de sécurité. C’est donc un domaine qui a du potentiel et dont il faudra suivre les évolutions.

La sécurité doit faire l’objet d’une attention particulière lors du choix d’une solution de type cloud. En effet, mettre ses données dans le cloud implique a priori que l’on perd le contrôle sur ces données et que l’on fait confiance au fournisseur de services cloud pour protéger ces données. L’un des aspects de cette protection est la confidentialité : que fait mon fournisseur des données confidentielles (les miennes ou celles de mes utilisateurs) ? Même si le fournisseur a pris les mesures suffisantes pour correctement protéger les données par rapport à des attaquants externes, le fournisseur lui-même a accès à ces données et un gouvernement pourrait exiger qu’il les lui transmette (voir l’exemple du Patriot Act aux États-Unis).

Certains produits récents et innovants offrent des solutions de chiffrement pour les organisations qui souhaitent utiliser des services cloud tout en gardant l’assurance de la confidentialité de leurs données.

On peut classer ces produits dans deux catégories : d’une part, des solutions de stockage dans le cloud avec chiffrement. D’autre part, les « Cloud Security Gateways », conçues pour utiliser des applications cloud spécifiques comme Gmail ou Salesforce. Dans ces deux catégories, un point important est l’approche utilisée pour chiffrer les données : elles sont chiffrées avant d’être envoyées dans le cloud et avec des clés dont l’utilisateur ou l’entreprise garde toujours le contrôle. Ainsi, le fournisseur cloud n’a jamais accès aux clés et ne peut donc pas déchiffrer les données.

Lors de cette session d’information, nous présenterons un aperçu du marché et nous ferons la démonstration de certains produits. Nous poserons les questions suivantes : ces solutions sont-elles performantes ? Simples à mettre en œuvre ? Quel niveau de sécurité offrent-elles ? Nous comparerons ces solutions avec le système de stockage de données dans le cloud conçu par Smals basé sur le threshold encryption et faisant actuellement l’objet d’une demande de brevet.

Cloud computing is vandaag een realiteit. De talrijke voordelen ervan, zoals de flexibiliteit bij het gebruik of de verlaging van de kosten, overtuigden veel ondernemingen om voortaan dagelijks cloudtoepassingen als Dropbox, Gmail of Salesforce te gebruiken.

De veiligheid moet bijzondere aandacht krijgen bij de keuze van een oplossing van het cloudtype. Je gegevens in de cloud zetten betekent namelijk a priori dat je de controle over die gegevens verliest en dat je vertrouwt op de leverancier van de cloudservice om die gegevens te beschermen. Eén van de aspecten van die bescherming is de vertrouwelijkheid: wat doet mijn leverancier met de vertrouwelijke gegevens (die van mij of van mijn gebruikers)? Zelfs als de leverancier voldoende maatregelen heeft getroffen om de gegevens correct te beschermen tegen externe aanvallers, heeft hijzelf toegang tot die gegevens en een regering zou kunnen eisen dat hij ze overdraagt (zie het voorbeeld van de Patriot Act in de Verenigde Staten).

Een aantal recente en innoverende producten bieden vercijferingsoplossingen aan voor organisaties die clouddiensten wensen te gebruiken en tegelijk garanties willen krijgen wat betreft de vertrouwelijkheid van hun gegevens.

We kunnen die producten indelen in twee categorieën: enerzijds oplossingen voor opslag in de cloud met vercijfering. Anderzijds “Cloud Security Gateways”, ontworpen om specifieke cloudtoepassingen als Gmail of Salesforce te gebruiken. Een belangrijk punt in die twee categorieën is de aanpak die gebruikt wordt om de gegevens te vercijferen: ze worden vercijferd vooraleer zij naar de cloud gestuurd worden en met sleutels waarover de gebruiker of de onderneming altijd de controle behoudt. Zo heeft de cloudleverancier nooit toegang tot de sleutels en kan hij de gegevens dus niet ontcijferen.

Tijdens deze infosessie zullen wij een overzicht van de markt geven en zullen wij een aantal producten demonstreren. We zullen de volgende vragen stellen: zijn deze oplossingen performant? Eenvoudig te implementeren? Welk veiligheidsniveau bieden zij? We zullen deze oplossingen vergelijken met het door Smals ontworpen systeem voor gegevensopslag in de cloud dat gebaseerd is op threshold encryption en waarvoor een octrooiaanvraag loopt.

Presentation

La sécurité doit faire l’objet d’une attention particulière lors du choix d’une solution de type cloud. En effet, mettre ses données dans le cloud implique a priori que l’on perd le contrôle sur ces données et que l’on fait confiance au fournisseur de services cloud pour protéger ces données. L’un des aspects de cette protection est la confidentialité : que fait mon fournisseur des données confidentielles (les miennes ou celles de mes utilisateurs) ? Même si le fournisseur a pris les mesures suffisantes pour correctement protéger les données par rapport à des attaquants externes, le fournisseur lui-même a accès à ces données et un gouvernement pourrait exiger qu’il les lui transmette (voir l’exemple du Patriot Act aux États-Unis).

Certains produits récents et innovants offrent des solutions de chiffrement pour les organisations qui souhaitent utiliser des services cloud tout en gardant l’assurance de la confidentialité de leurs données.

On peut classer ces produits dans deux catégories : d’une part, des solutions de stockage dans le cloud avec chiffrement. D’autre part, les « Cloud Security Gateways », conçues pour utiliser des applications cloud spécifiques comme Gmail ou Salesforce. Dans ces deux catégories, un point important est l’approche utilisée pour chiffrer les données : elles sont chiffrées avant d’être envoyées dans le cloud et avec des clés dont l’utilisateur ou l’entreprise garde toujours le contrôle. Ainsi, le fournisseur cloud n’a jamais accès aux clés et ne peut donc pas déchiffrer les données.

Lors de cette session d’information, nous présenterons un aperçu du marché et nous ferons la démonstration de certains produits. Nous poserons les questions suivantes : ces solutions sont-elles performantes ? Simples à mettre en œuvre ? Quel niveau de sécurité offrent-elles ? Nous comparerons ces solutions avec le système de stockage de données dans le cloud conçu par Smals basé sur le threshold encryption et faisant actuellement l’objet d’une demande de brevet.

Cloud computing is vandaag een realiteit. De talrijke voordelen ervan, zoals de flexibiliteit bij het gebruik of de verlaging van de kosten, overtuigden veel ondernemingen om voortaan dagelijks cloudtoepassingen als Dropbox, Gmail of Salesforce te gebruiken.

De veiligheid moet bijzondere aandacht krijgen bij de keuze van een oplossing van het cloudtype. Je gegevens in de cloud zetten betekent namelijk a priori dat je de controle over die gegevens verliest en dat je vertrouwt op de leverancier van de cloudservice om die gegevens te beschermen. Eén van de aspecten van die bescherming is de vertrouwelijkheid: wat doet mijn leverancier met de vertrouwelijke gegevens (die van mij of van mijn gebruikers)? Zelfs als de leverancier voldoende maatregelen heeft getroffen om de gegevens correct te beschermen tegen externe aanvallers, heeft hijzelf toegang tot die gegevens en een regering zou kunnen eisen dat hij ze overdraagt (zie het voorbeeld van de Patriot Act in de Verenigde Staten).

Een aantal recente en innoverende producten bieden vercijferingsoplossingen aan voor organisaties die clouddiensten wensen te gebruiken en tegelijk garanties willen krijgen wat betreft de vertrouwelijkheid van hun gegevens.

We kunnen die producten indelen in twee categorieën: enerzijds oplossingen voor opslag in de cloud met vercijfering. Anderzijds “Cloud Security Gateways”, ontworpen om specifieke cloudtoepassingen als Gmail of Salesforce te gebruiken. Een belangrijk punt in die twee categorieën is de aanpak die gebruikt wordt om de gegevens te vercijferen: ze worden vercijferd vooraleer zij naar de cloud gestuurd worden en met sleutels waarover de gebruiker of de onderneming altijd de controle behoudt. Zo heeft de cloudleverancier nooit toegang tot de sleutels en kan hij de gegevens dus niet ontcijferen.

Tijdens deze infosessie zullen wij een overzicht van de markt geven en zullen wij een aantal producten demonstreren. We zullen de volgende vragen stellen: zijn deze oplossingen performant? Eenvoudig te implementeren? Welk veiligheidsniveau bieden zij? We zullen deze oplossingen vergelijken met het door Smals ontworpen systeem voor gegevensopslag in de cloud dat gebaseerd is op threshold encryption en waarvoor een octrooiaanvraag loopt.

SSL Pulse est un site web dédié à évaluer la sécurité pratique des implémentations de SSL. SSL Pulse permet d’une part une vue globale de la sécurité de l’implémentation de SSL sur les sites les plus populaires et d’autre part de tester un site en particulier. Le site est très simple à utiliser.

Dans le cas des algorithmes de chiffrement symétrique, la taille des clés à choisir est directement liée à la complexité d’une recherche exhaustive. Par exemple, pour retrouver une clé du DES (ancien standard de chiffrement), soit 56 bits, il y a 2⁵⁶ clés possibles. En 1977, date de l’adoption du standard, les essayer toutes était impossible et c’est resté le cas pendant 20 ans ; mais en 1997 pour la première fois le groupe DESCHALL Project a réussi une recherche exhaustive de clés. En 2001 le nouveau standard AES a été adopté ; il utilise un design différent du DES et permet des clés plus longues (de 128 à 256 bits). Pour retrouver une clé AES de 128 bits, vous aurez besoin d’essayer 2¹²⁷ clés en moyenne (il y a 2¹²⁸ clés possibles et en moyenne vous trouverez la bonne au bout de la moitié de vos essais). Même en investissant de gros moyens techniques (cloud computing, hardware dédié) et financiers, je parie que vous n’y arriverez pas!

Dans le cas des algorithmes de chiffrement asymétrique et des algorithmes de signature digitale, la taille des clés à choisir dépend des propriétés mathématiques de l’algorithme et il existe de bien meilleures attaques que la recherche exhaustive. Par exemple, dans le cas de RSA, factoriser le module N de la clé publique permet de retrouver la clé privée. A l’heure actuelle, la taille minimum acceptable pour de telles clés est 1024 bits et la taille recommandée est de 2048 bits (à adapter en fonction de la durée de vie souhaitée de la clé).

Il est déjà arrivé qu’un choix de clé trop courte permette qu’un système sécurisé soit attaqué. Un exemple qui a fait grand bruit en France est celui de l’affaire Humpich. En 1998, l’ingénieur français Serge Humpich parvient à casser la Carte Bleue, carte bancaire à puce, et à fabriquer une fausse carte.  Au cœur de son attaque réside le fait que la clé publique utilisée pour l’authentification de la carte (l’étape lors de laquelle le terminal vérifie que la carte est authentique grâce à une signature digitale stockée dans la carte) était une clé RSA de 320 bits. Pour casser cette clé (c’est-à-dire retrouver la clé privée correspondante), il fallait factoriser un entier de 320 bits, ce qui était relativement rapide à faire en 1998 avec un logiciel adéquat et un ordinateur de l’époque. Une fois la clé privée retrouvée, facile de générer une signature digitale falsifiée…

Les serveurs SSL aussi ont besoin de clés (clés de chiffrement RSA) et étant donné leur prolifération ils permettent une étude intéressante. Grâce au site SSL Pulse créé par le Trustworthy Internet Movement, on peut avoir des statistiques précises sur les clés utilisées sur les sites les plus populaires. Au 23 mai 2012, sur 200 000 sites testés, seuls 5 sites utilisaient encore des clés de moins de 1024 bits ; 16% utilisaient des clés de 1024 bits, et les 83,9% restants utilisaient des clés de 2048 bits ou plus. On voit donc que, si la sécurité de ces serveurs laisse parfois à désirer comme le révèle SSL Pulse, ce n’est pas à cause de la taille de clés mais plutôt à cause de problèmes de configuration (support de versions anciennes de SSL, mauvais choix de suites de chiffrement, etc..).

En pratique, si vous devez choisir une taille de clés et que vous avez le moindre doute, faites appel à un expert en cryptographie. Cet expert pourra se référer au site KeyLength.com qui compile différents travaux sur le sujet. Ces travaux ont étés effectués par des organisations comme le NIST (National Institute for Standards and Technology) américain, le BSI (Bundesamt für Sicherheit in der Informationstechnik) allemand, le réseau européen d’excellence ECRYPT et d’autres. Sur ce site, à l’aide de différents tableaux, on peut recevoir une recommandation de taille de clés en fonction de plusieurs paramètres, comme le type d’algorithme, la durée de vie de la clé souhaitée, et le niveau de sécurité voulu.

Un navigateur doit, pour pouvoir établir une connexion SSL avec un serveur web, obtenir la clé publique de ce serveur. Il doit, en plus, avoir confiance en cette clé publique, c’est-à-dire s’assurer qu’elle est l’authentique clé publique de ce serveur. Pour cela, on utilise des certificats. Le serveur possède un certificat et l’envoie au navigateur. Ce certificat est un fichier qui contient entre autres l’identifiant du serveur, la clé publique du serveur et des dates de validité. Le tout est signé par un tiers de confiance, appelé Autorité de Certification (Certificate Authority ou CA), qui joue un rôle fondamental. Le navigateur maintient une liste des clés publiques des CA en lesquels il a confiance ; grâce à ces clés publiques, il peut vérifier l’authenticité du certificat du serveur.

Ce modèle repose donc sur la confiance en une liste déterminée de CA. Or, l’actualité récente montre une certaine fragilité de cette approche. En effet, a plusieurs reprises, des brèches de sécurité ont permis à des hackers de compromettre des CA, le cas le plus parlant étant celui de DigiNotar, aujourd’hui en faillite après que des attaquant aient réussi à forger de nombreux faux certificats.

Certains chercheurs étudient donc des alternatives. Il ne s’agit pas d’alternatives au protocole SSL en lui-même mais bien d’approches différentes pour établir la confiance. Le problème du modèle actuel basé sur les Autorités de Certification est qu’il n’est sûr que si toutes les autorités sont sûres ; autrement dit, il suffit qu’une seule autorité soit compromise et le système ne garantit plus une bonne sécurité.

L’une de ces alternatives est Convergence, proposée par Moxie Marlinspike, expert en sécurité. Le principe est simplement de remplacer les CA par un réseau de notaires et de donner à l’utilisateur le choix de faire confiance ou non à certains notaires. Chaque notaire décide de donner sa confiance à un site ou non. Lorsque le navigateur arrive pour la première fois sur un site en https, il demande le certificat du site, puis demande à tous ses notaires de confiance d’attester de l’authenticité du certificat. Si tous les notaires répondent “oui”, alors le navigateur considère le certificat comme valide. Il s’agit donc d’une approche distribuée de la confiance ; avec Convergence, il n’y a plus de Single Point Of Failure.

Que penser de Convergence ? A l’heure actuelle, on manque de notaires (une cinquantaine environ), or une masse critique de notaires sera bien sûr nécessaire pour que le système fonctionne. Et ce système pose des questions : comment vont travailler les notaires ? A l’heure actuelle, l’administrateur d’un site web qui veut obtenir un certificat peut choisir une autorité de certification pour passer commande d’un certificat. Mais comment enregistrer ce certificat auprès des notaires ? Enfin, pour l’instant, Convergence pour l’utilisateur est uniquement disponible pour le navigateur Firefox, sous la forme d’un add-on. Celui-ci ne fonctionne pas “out-of-the-box”; après un rapide test, mon navigateur ne connaît que deux notaires et n’arrive plus à se connecter en https à mes sites favoris… Utiliser Convergence va demander plus de travail de configuration à l’utilisateur, et l’on peut s’imaginer qu’il va d’abord convaincre les utilisateurs les plus avancés et sensibilisés à la problématique des certificats.

L’idée de Convergence est séduisante. Mais il va donc falloir lui laisser un peu de temps pour se développer.

En pratique, ces fonctions servent à calculer une empreinte d’un message ou document, et on traite cette empreinte comme si elle était unique (puisqu’il est impossible de trouver un autre message ou document qui aurait la même empreinte).

Les fonctions de hachage sont très utilisées en cryptographie. Elles servent par exemple dans les algorithmes de signature digitale pour condenser le message avant de transformer ce résultat en signature à l’aide de la clé privée.

Parmi l’ensemble des fonctions de hachage existantes, deux ont été particulièrement utilisées dans de nombreuses applications : MD5 et SHA-1. Mais leur sécurité a été remise en cause par les progrès récents des recherches en cryptographie. Dans le cas de MD5, dont les empreintes font 128 bits, des chercheurs ont trouvé une collision en 2004 (elle n’est donc « plus » résistante aux collisions !), et dans le cas de SHA-1, des vulnérabilités ont été décelées dès 2005. Ces vulnérabilités n’ont pas encore permis de trouver des collisions. Il n’y a pas à paniquer si vous utilisez une application qui implémente SHA-1, mais les architectes doivent désormais plutôt choisir une fonction de la famille SHA-2 (SHA-224, SHA-256, SHA-384, ou SHA-512). Et, à long terme, c’est une bonne idée d’anticiper et de concevoir une fonction de nouvelle génération appelée à devenir le prochain standard, SHA-3.

C’est le NIST (National Institute of Standards and Technology), organisme d’état qui dépend du ministère du Commerce des Etats-Unis, qui a lancé une compétition internationale pour choisir quelle sera cette fonction de hachage SHA-3. Cette fonction sera inscrite dans le « Federal Information Processing Standard (FIPS) 180-3, Secure Hash Standard ». La procédure en plusieurs tours est comparable à celle que le NIST avait auparavant employée pour le choix d’AES (Advanced Encryption Standard). Elle a consisté  à lancer un appel en novembre 2007, auquel n’importe quelle personne ou organisation pouvait répondre pour suggérer une fonction de hachage. Beaucoup d’équipes de chercheurs en cryptographie ont répondu à l’appel. Ensuite, à chaque tour, certaines fonctions sont choisies, selon des critères de performance et de sécurité.

• Lors de la clôture de l’appel, le 31 octobre 2008, 64 candidatures avaient été reçues.
• Le premier tour a commencé le 1^er novembre 2008. Au 5 décembre 2008, il restait  51 fonctions qui satisfaisaient aux exigences minimales. Après une conférence et plusieurs débats, 14 parmi ces 51 ont été retenues pour le deuxième tour.
• Le deuxième tour a commencé le 24 juillet 2009. Les performances et la sécurité des candidats restants ont été examinées pendant un an par la communauté internationale et une conférence a été organisée en août 2010. Le 9 décembre 2010, cinq candidats ont été retenus pour le troisième tour.

A l’heure de ce message, le troisième tour est en cours. Il reste donc 5 finalistes, nommés BLAKE, Grøstl,  JH, Keccak et Skein, et nous sommes dans la période lors de laquelle le public peut s’exprimer sur ces finalistes (par exemple, s’il trouve une faille de sécurité dans l’un des candidats). Au printemps 2012 aura lieu la dernière conférence SHA-3 et le choix du vainqueur sera annoncé plus tard en 2012.

Nous connaîtrons donc bientôt une nouvelle fonction de hachage standard, SHA-3, dont la sécurité et les performances auront été validées par une communauté internationale d’experts en cryptographie.