La Lettre du CERT-Solucom

Dimension: px
Commencer à balayer dès la page:

Download "La Lettre du CERT-Solucom"

Transcription

1 n 2 - janvier 2014 La Lettre du CERT-Solucom Dossier PKI : quel paradigme pour la confiance numérique? La médiatisation de nombreuses attaques, de la compromission d autorités de certification à la contrefaçon de systèmes de signature, en passant par la mise à mal de systèmes de vote électronique, met en lumière l enjeu fondamental que représente la confiance dans un monde numérique ; confiance dont l importance est à mesurer à l aune des profondes transformations insufflées par la transition vers une économie et une société aujourd hui massivement informatisée. Dans ce contexte se pose la question de la mise en place de ce système de confiance et de son paradigme : un modèle unique et étendu est-il possible? Au contraire, est-il nécessaire de segmenter et d adapter ce modèle en fonction de l environnement auquel il est appliqué (particulier, entreprise, gouvernement, etc.)? Finalement, se pose aussi la question de la confiance que l on peut porter au modèle actuel. Dans un premier temps nous présenterons les bases de la confiance numérique actuelle ainsi qu un rappel des fondamentaux techniques, puis dans un second temps nous étudierons les limites de ce système et enfin proposerons quelques pistes de définition d un paradigme où une confiance numérique effective peut être mise en place. à lire également P13 Extrait d actualité : octobre / décembre 2013

2 PKI : Quel paradigme pour la confiance numérique? 1. La confiance à l heure du numérique L ère numérique se caractérise par la constante augmentation de la dématérialisation des usages : achats, déclarations d impôts, signatures de contrats, etc. Chacun de ces actes ordinaires prend une toute autre dimension dans le monde virtuel. Comment s assurer qu un acheteur numérique est bien le propriétaire de la carte de crédit utilisée? Comment connaître qui est véritablement le signataire d un contrat numérique? Ces exemples mettent en évidence le lien fort qui existe entre la notion d identité numérique et celle de confiance numérique. En effet, il est impossible d établir une relation de confiance avec un tiers si son identité n est pas reconnue. La confiance dans notre vie de tous les jours est imposée par un ensemble de facteurs comme la possibilité d identifier de visu un interlocuteur, d entrer physiquement dans les bureaux d une entreprise, de présenter une pièce d identité ou de disposer d une copie papier d un contrat. La confiance numérique ne peut pas se baser sur ces éléments tangibles. Les facteurs disponibles dans le monde réel, notions souvent subjectives, se traduisent alors par de nouveaux termes dans le monde virtuel : disponibilité, intégrité, confidentialité et preuve (DICP). Chacun de ces critères se décline ensuite différemment en fonction du point de vue. Prenons par exemple le cas d un service bancaire en ligne du point de vue de l utilisateur : Sera-t-il accessible lorsque je devraisréaliser un virement urgent? Si je réalise un virement en ligne, le destinataire effectif de la transaction sera-t-il celui souhaité? Suis-je le seul à pouvoir consulter mes informations bancaires? En cas de litige, comment pourrais-je prouver la date à laquelle j ai souscrit à un nouveau contrat en ligne? Du point de vue de la banque fournissant le service, les interrogations sont différentes : Tous mes clients peuvent-ils bien accéder à leurs services en ligne lorsqu ils en ont besoin? L ordre de virement reçu de mon client est-il bien celui qu il a demandé de réaliser? Le client consultant son compte bancaire est-il bien celui qu il prétend être? Comment puis-je m assurer que le contrat signé numériquement par mon client est irréfragable devant les tribunaux? Pour répondre à ces nouvelles problématiques, des normes ont été rédigées pour définir un ensemble de processus et de moyens techniques permettant de s assurer que chacun des critères DICP est respecté. Ces nouveaux outils permettent aujourd hui d assurer une continuité de service pour l accès à des données dont l intégrité et la confidentialité sont préservées tout en maintenant la traçabilité des traitements sur ces dernières. 2. Le certificat : un outil unique pour la confiance numérique Comme nous venons de le voir, la confiance numérique repose sur les notions d identité numérique, de disponibilité, d intégrité, de confidentialité et de preuve. Cette section rappelle les fondamentaux techniques liés à ces notions Public Key Infrastructure Selon le RGS [1], une PKI est un «ensemble de composants, fonctions et procédures dédiés à la gestion des clés cryptographiques asymétriques et de leurs certificats utilisés par des services de confiance». Cette définition se traduit par l agencement de briques techniques, de processus et d une organisation pour garantir le niveau de sécurité attendu, chacun de ces éléments y participant à niveau égal (voir figure 1 : éléments d une PKI). Afin de pouvoir mettre à disposition des services de sécurité, l utilisation d une PKI requiert la coordination de nombreuses entités (voir figure 2 : schéma fonctionnel simplifié d une PKI) dont les principales sont les suivantes : Autorité d enregistrement : traite les demandes relatives aux certificats numériques (validation de l identité du demandeur, demande de délivrance / renouvellement / révocation, remise du certificat). Demande de certification Authentification / Vérification des attributs Création et signature du certificat Expiration du certificat / Renouvellement Remise au demandeur et publication éventuelle Exploitation du certificat Révocation Révocation Suspension Figure 1 : éléments d une PKI 2 La Lettre CERT-Solucom N 2 janvier 2014

3 Figure 2 : schéma fonctionnel simplifié d une PKI Autorité de certification : signe les demandes de certificats numériques validées par l autorité d enregistrement ainsi que les listes de révocation. Autorité de séquestre : assure la sauvegarde sécurisée des bi-clés (clé publique et clé privée) Service de publication : publie les listes de révocation de certificats et dans certains cas les certificats utilisateurs. Autorité de validation : permet de vérifier en ligne et en temps réel le statut d un certificat numérique. Une fois que les moyens pour assurer les services de la PKI sont opérationnels, les porteurs qu ils soient humains ou matériels peuvent obtenir des certificats numériques qui permettront d établir un lien entre leur identité et leur clé publique. Ce certificat s apparente à une pièce d identité «électronique» (voir figure 3 : parallèle entre certificat numérique et carte d identité nationale). En effet, le lien entre le porteur de la clé privée et son certificat public est établi par l Autorité de Certification sur la base d une vérification initiale fiable (assurée par l Autorité d Enregistrement). Il est à noter que le certificat, s il permet de prouver l identité du porteur, ne détermine pas les habilitations de celui-ci. Le certificat ne vaut pas droit! 2.2. Signature électronique Signer électroniquement un document consiste à rendre le document infalsifiable en y apposant une preuve numérique de son intégrité. Cette signature apporte également une preuve de l identité du signataire qu il ne pourra pas renier (non-répudiation). Pour cela, il est nécessaire de coordonner 5 briques fonctionnelles (voir figure 4 : composants mis en jeu lors de la création d un document signé) : Outil de création de document Service d horodatage (signature d une contremarque de temps permettant d apporter la fiabilité d une date et d une heure) Système de création de signature Service de validation de signature (vérification de la validité d une signature) Service d archivage sécurisé de documents (conservation pérenne des documents et des preuves associées) Chacune de ces briques fonctionnelles repose notamment sur les services offerts par une PKI ou utilise les certificats qu elle délivre : Mise à disposition de certificats numériques Mise à disposition des informations de révocation de certificats numériques (CRL [3], ARL, OCSP [4] ) Le processus de signature électronique d un document peut donc techniquement se traduire par les étapes suivantes : Obtention d un certificat de signature auprès d une PKI (Certificat dont le Key Usage nonrepudiation est positionné) Création du document dont le contenu doit être signé Obtention d un jeton d horodatage [2] auprès d un service respectant les protocoles techniques et juridiques d horodatage (voir figure 5 : processus de création d un jeton d horodatage) Constitution de la signature du document dans un format tel que CAdES, XAdES, PAdES [5], XML DSIG [6], en y incluant le jeton d horodatage, les informations de révocation ainsi que la chaîne de certification (voir figure 6 : mécanisme de signature d un document) Chiffrement Chiffrer des données permet de rendre la compréhension de celles-ci impossible à toute personne ne connaissant pas le secret de la transformation mathématique opérée. Le chiffrement peut être opéré sur des données statiques (fichiers) ou sur des flux de données (échanges de données entre applications). Dans ces deux cas, deux types de chiffrement peuvent être utilisés. Le chiffrement symétrique : les clés de chiffrement et de déchiffrement sont identiques et le processus est, avec les algorithmes actuellement utilisés, peu consommateur en temps et en ressources. Le chiffrement asymétrique : les clés de chiffrement et de déchiffrement sont distinctes mais liées mathématiquement. Le pro- La Lettre CERT-Solucom N 2 janvier

4 Figure 3 : parallèle entre certificat numérique et carte d identité nationale cessus de chiffrement est plus long et plus consommateur en ressources comparativement aux algorithmes symétriques actuellement utilisés. Les algorithmes RSA, El-Gamal et Diffie-Hellman font partie des algorithmes les plus utilisés actuellement. Les protocoles et les solutions de chiffrement mettent souvent en œuvre une combinaison de ces deux mécanismes : utilisation du chiffrement asymétrique pour négocier une clé de session symétrique régulièrement renouvelée. La sécurité et la rapidité des opérations sont alors optimisées (voir figure 7 : exemple de mise en place d un système de chiffrement hybride) Cas du protocole SSL/TLS Le protocole SSL/TLS est aujourd hui le protocole le plus répandu à l échelle d internet pour assurer la confidentialité et l intégrité des échanges. C est par exemple sur ce dernier que repose le protocole HTTPS. Lorsqu un utilisateur accède à un site web sécurisé en HTTPS, un ensemble de mécanismes de vérification de l identité du serveur est déclenché de façon transparente (voir figure 8 : vérification de l identité d un serveur web). Le contrôle de l identité du serveur passe notamment par la vérification du statut de révocation de la chaîne de certification ayant délivré le certificat du serveur web. Pour ce faire, le poste de travail de l utilisateur (ou son navigateur) télécharge récursivement (étape 3 et 4) les listes de révocation correspondant aux certificats feuille et d autorités intermédiaires pour contrôler s ils y sont présents. Une fois ces vérifications faites, le poste de travail de l utilisateur (ou son navigateur) initie la connexion SSL avec le serveur et réalise le chiffrement des communications. 3. La confiance a ses limites? Même s il est souvent question aujourd hui des avantages théoriques liés à la mise en œuvre d une PKI dans une organisation ou à l échelle d Internet, les limitations techniques existantes ou les erreurs de conception des processus sont moins souvent abordées. L objectif de cette section est de mettre en évidence les limitations et erreurs pouvant influencer le niveau de confiance dans la solution de gestion de clés mise en œuvre ou celui des usages qui en découlent. 13 octobre Propriété de Solucom, reproduction interdite 3.1. Un niveau de confiance impacté par une mauvaise implémentation Limite technique Comme souvent en informatique, le niveau de sécurité d une solution dépend beaucoup de son implémentation technique. La PKI ne fait pas exception à ce constat, Comodo [7] et Diginotar [8] en sont deux exemples récents. Courant 2011, Comodo et Diginotar, deux opérateurs de PKI et fournisseurs de certificats numériques, ont vu leur système d information compromis par une attaque ciblée. Les certificats émis frauduleusement ont été utilisés dans le cadre d attaques à l encontre des utilisateurs de Google ou Yahoo [9]. L attaque à l encontre de Comodo aurait été menée par la compromission du compte d une entreprise revendeuse à partir duquel 9 certificats aux noms de 7 domaines différents ont été émis (dont login.yahoo.fr, login.live.com). Le compte du revendeur ayant le rôle d autorité d enregistrement, il semble qu aucun contrôle n ait été réalisé par Comodo avant d autoriser la signature des certificats frauduleux. À la suite de cet incident, outre la révocation des certificats frauduleux, Comodo a pris la décision de renforcer le mécanisme d authentification sur son module d autorité d enregistrement. Cet exemple met en lumière la nécessité de mettre en œuvre des moyens techniques et des processus adaptés malgré le contrat de confiance qui peut lier l autorité d enregistrement à l autorité de certification. L entreprise Diginotar a, quant à elle, subi un préjudice beaucoup plus grave et a vu un nombre important de ses autorités de confiance compromises. L attaque a été initiée depuis internet au travers d un système de gestion de contenus (CMS) non mis à jour et vulnérable. Une fois le premier serveur piraté, l attaquant a pénétré plus en profondeur dans le SI en rebondissant sur une base SQL puis en obtenant les mots de passe de comptes à privilèges. Avec les accès ainsi obtenus, l attaquant aurait réussi à créer un total de 531 certificats frauduleux (dont des certificats aux noms de *.google.com, login.live. com ou encore login.yahoo.com). Même si Diginotar a immédiatement révoqué les certificats concernés, les principaux éditeurs de navigateurs Internet (Google [10], Microsoft [11], Mozilla [12] ) ont mis sur liste noire les certificats d autorité de l opérateur. À la suite de cet incident, Diginotar a fait faillite [13]. Un autre exemple récent est l erreur du service informatique du ministère des finances français qui a utilisé un certificat d AC signé 4 La Lettre CERT-Solucom N 2 janvier 2014

5 par l IGC/A (PKI racine des administrations françaises reconnues de confiance sur Internet Explorer et Firefox) dans un pare-feu applicatif (WAF) afin de contrôler le trafic SSL interne et sortant du ministère 14]. Google ayant identifié la création de certificats non légitimes pour certains de ses noms de domaines a rapidement contacté l ANSSI pour signaler le problème [15]. L ANSSI a pris la décision de révoquer le certificat d AC en question. En complément de l ajout de l AC concernée dans la liste noire de son navigateur, Google a pris la décision de limiter la validité des certificats issus de la chaîne d AC de l IGC/A à la liste des domaines de premier niveau TLD liés à l état français :.fr,.gp (Guadeloupe),.gf (Guyane),.mq (Martinique), etc. L interception et le contrôle du contenu de flux SSL sont fréquents en entreprise mais ils doivent être réalisés dans une zone de confiance exclusivement limitée à l entreprise. On voit se dessiner là un premier paradigme dans lequel la confiance numérique peut s inscrire Limite organisationnelle Outre les limites techniques, la confiance peut souvent être mise en défaut à cause de processus organisationnels peu ou mal adaptés ou à cause de la mauvaise application des procédures définies. L opérateur de PKI TurkTrust a ainsi fait face à un incident de sécurité ayant permis la délivrance de deux certificats d AC à la place de certificats finaux [16]. L incident a été provoqué par une erreur procédurale interne suite à la réalisation d une mise en production inappropriée. Lors de celle-ci, des gabarits d AC de tests ont été importés en production remplaçant des gabarits de certificats finaux. L erreur a été rapidement détectée grâce au signalement du problème par un client. TurkTrust a dès lors pu révoquer les certificats en question et corriger la configuration de son environnement de production. En complément, des contrôles complémentaires en milieu et fin du processus de délivrance afin de vérifier la concordance du certificat à la demande réalisée par le client ont été mis en place Une coordination indispensable des toutes les composantes Ces exemples mettent en évidence que le niveau de sécurité d une PKI ne se définit pas simplement par l avancée technologique des moyens techniques mis en œuvre (ex : nouveaux algorithmes cryptographiques). Comme présenté précédemment, une PKI résulte de la coordination d un socle technique, d un ensemble de procédures et d une organisation. Par conséquent, si un de ces éléments fait défaut, sa défaillance abaissera sensiblement le niveau de sécurité global de l infrastructure mise en place. Pour les aspects techniques, au-delà des recommandations classiques sur les socles (contrôle d accès restrictif avec revue régulière des habilitations et application des patchs de sécurité) des préconisations spécifiques à la PKI doivent être respectées autant que faire se peut : Protéger les secrets cryptographiques des Autorités de Certification dans un HSM. Réaliser des sauvegardes des secrets d un HSM en utilisant des quorums de porteurs (n porteurs d une partie du secret parmi m sont nécessaires à la reconstitution de celui-ci). Si approprié, mettre en œuvre des Autorités de Certification de type «hors-ligne». Effacer définitivement les secrets cryptographiques utilisés sur des supports temporaires. Figure 4 : composants mis en jeu lors de la création d un document signé La Lettre CERT-Solucom N 2 janvier

6 Quel niveau de sécurité dois-je assurer pour protéger les clés privées des porteurs finaux? Dans chacun de ces cas un processus différent doit être mis en place. La délivrance d un certificat d AC intermédiaire nécessitera par exemple un contrôle d identité très strict de son porteur impliquant notamment un face-à-face lors de la remise de ce dernier. Souvent, les difficultés lors de l application des processus proviennent du manque de visibilité ou d anticipation lors de la phase projet de conception générale de la PKI. Il est essentiel, lors de cette phase, de pouvoir référencer l ensemble des populations utilisatrices (internes et externes à l entreprise) et des usages des certificats à court, moyen et long terme. Cela permettra de pérenniser les processus courants et exceptionnels définis. Figure 5 : processus de création d un jeton d horodatage Réaliser une ségrégation physique des serveurs d Autorité de Certification dans une salle requérant un niveau d autorisation d accès élevé et une traçabilité importante. Mettre en œuvre un cloisonnement réseau spécifique aux serveurs d Autorité de Certification. Si possible utiliser un réseau physique séparé pour tous les composants de la PKI. Réaliser une isolation électromagnétique des serveurs afin de se prémunir de la mise en place de ponts 3G ou d attaques de type TEMPEST [17]. Prévoir un environnement de qualification ou de pré-production indépendant de la production. Les procédures quant à elles doivent être adaptées au contexte de déploiement de la solution. En particulier, une réponse doit être apportée aux questions suivantes : Les certificats seront-ils délivrés en interne de mon entreprise ou à destination de clients pour un usage sur internet? Dois-je délivrer des certificats finaux ou des certificats d AC intermédiaires? Finalement, l organisation doit permettre de mettre en œuvre les processus définis précédemment en assurant la séparation des rôles nécessaires. Le RGS préconise que les rôles suivants soient portés par des personnes distinctes : responsable de sécurité et ingénieur système / opérateur contrôleur et tout autre rôle ingénieur système et opérateur Mais ces exclusions peuvent être étendues en fonction de contraintes spécifiques. Il est par exemple possible de séparer le rôle de 1 er opérateur d enregistrement en charge de la demande de signature de certificat auprès de l AC du rôle de 2 nd opérateur en charge de contrôler la conformité du certificat signé avec la demande initiale du client. Par ailleurs, pour assurer un niveau de fiabilité et d expertise élevé des équipes, il est aussi recommandé pour chaque poste de rédiger des fiches mission et de former régulièrement les équipes aux procédures à suivre et aux outils qu elles manipulent. Un aspect complémentaire à la mise en place d une PKI à ne pas négliger est la capacité à assurer l application des choix retenus dans le temps. En effet, il n est pas rare de rencontrer des entreprises n étant pas en mesure d appliquer concrètement des certaines exigences techniques et organisationnelles assurant théoriquement un niveau de sécurité maximum. Pour éviter ce désagrément toutes les décisions doivent être adaptées aux contraintes opérationnelles de l entreprise ainsi qu à son niveau de maturité. Finalement, la réalisa- Figure 6 : mécanisme de signature d un document 6 La Lettre CERT-Solucom N 2 janvier 2014

7 Figure 7 : exemple de mise en place d un système de chiffrement hybride tion régulière d audits techniques internes et de vérification du respect des procédures par l autorité de contrôle est essentielle. 3.2.Des limitations inhérentes aux protocoles Cependant, même lorsque les principes de sécurité de base sont respectés certaines limitations inhérentes aux protocoles existent toujours et sont difficilement contournables Respect de la RFC 5280 Dans un 1 er temps, comment s assurer du respect strict de la RFC 5280 par les produits du marché utilisant des certificats? Nous avons vu précédemment que lorsqu un utilisateur se connecte à un serveur web en HTTPS, son navigateur doit théoriquement valider la chaîne de certification ayant émis le certificat du serveur. Il doit en être de même pour la vérification du certificat client par le serveur en cas d authentification mutuelle. Si par défaut, l ensemble des navigateurs internet récents vérifie les CRL pour les sites web visités, il n en va pas de même pour les serveurs eux-mêmes. Le serveur httpd d Apache doit par exemple être explicitement configuré pour vérifier les CRL des certificats client présentés (voir la configuration des directives SSLCARevocationFile ou SSLCARevocationPath [18] ). En Juillet 2011, les chercheurs Paul Kehrer (Trustwave SSL) et Nicholas Percoco (SpiderLabs) ont mis en évidence la possibilité de réaliser une interception SSL de type Man-in-the-Middle sur un iphone [19] en utilisant un certificat final signé par un autre certificat final. L iphone ne réalisant pas correctement les vérifications nécessaires sur l attribut «basicconstraints» des certificats, le certificat final frauduleux était considéré comme valide par le téléphone (voir figure 9 : interception des communications SSL sur iphone). La faille a depuis été corrigée par Apple. Du côté d Android cette fois-ci, un groupe de chercheurs universitaires a réalisé une étude [20] comprenant un focus sur environ 6300 applications issues du Google s Play utilisant le protocole SSL. Leurs travaux ont démontré que parmi ces applications, 1074 étaient vulnérables à une attaque Man-in-the-Middle. Les causes sont multiples : utilisation de certificats auto-signés sur le serveur, erreurs de développement au niveau SSL, aucun avertissement affiché à l utilisateur en cas d interception du flux, etc. Les exemples décrits ci-dessus mettent en évidence des problèmes de deux natures différentes : Peut-on faire confiance aux administrateurs système? Peut-on faire confiance aux implémentations éditeurs? S il peut être aisé de faire confiance à ses administrateurs ou à défaut d en contrôler le travail, il est nettement plus complexe de demander aux éditeurs des garanties sur la qualité de leurs produits voir d en réaliser un audit. Dans ce dernier cas, les solutions envisageables sont assez limitées : Utilisation de produits open-source et réalisation d un audit du code? Réalisation d une étude de rétro-ingénierie coûteuse, souvent non exhaustive et parfois illégale selon les législations locales? Établissement de garanties sur la base d un contrat d assurance avec l éditeur ou un tiers Utilisation des certificats intermédiaires délivrés Cependant, le respect de la RFC 5280 n entraîne pas automatiquement une confiance totale. En effet, le principe de la chaîne de certification comporte ses propres insuffisances. Lorsqu une entité présente son certificat numérique, il est nécessaire de vérifier récursivement si l on fait confiance aux autorités constituant la chaîne de certification. Dans ce cas, et si le certificat racine de la chaîne est établi comme sûr, alors le certificat feuille peut lui aussi être considéré de confiance. Si nous acceptons de faire confiance aux opérateurs de PKI pour délivrer un certificat à son porteur légitime, comment s assurer de ce que va faire ce porteur avec son certificat? La question se pose tout particulièrement pour les entreprises disposant de certificats d AC dont les signataires sont des autorités commerciales auxquels nos postes de travail font confiance. Pour des entreprises telles que Google, Dell, Vodafone (entre autres) qui disposent de certificats d AC dont l émetteur est considéré comme de confiance par nos postes de travail, rien de plus simple que de réaliser une attaque de type Man-in-the-Middle. En prenant le cas d Etisalat, prise la main dans le sac en 2009 en ayant tenté d espionner les utilisateurs de BlackBerry [21]. Même si l attaque menée n impliquait pas l utilisation de sa propre autorité de certification, la La Lettre CERT-Solucom N 2 janvier

8 Figure 8 : vérification de l identité d un serveur Web volonté d espionnage d utilisateurs par l entreprise était clairement démontrée. Dans ces conditions, l AC dont dispose Etisalat perd immédiatement son niveau de confiance (voir figure 10 : certificat SSL légitime émis par l AC intermédiaire Etisalat). En 2012 Trustwave [22] est d ailleurs rapidement revenu sur sa décision de délivrer des certificats d AC intermédiaire de cette nature en comprenant les conséquences et les implications d un tel acte. Ces éléments démontrent très simplement que même si la RFC 5280 est respectée à la lettre, la confiance apportée aux infrastructures de PKI ne doit pas être inconditionnelle. Malheureusement, les solutions envisageables pour se prémunir contre ce type de problème sont difficilement applicables à grande échelle. Une solution simple envisageable, appelée «certificate pinning», consiste à associer à un nom de domaine le certificat attendu. Ainsi seul le certificat attendu sera accepté par le client. Il n est dès lors plus question de se reposer sur les mécanismes de vérification de chaînes de confiance Cette solution nous renvoie à l utilisation de l équivalent de certificats auto-signés et à la gestion individuelle des certificats. En 2011, Moxie Marlinspike a présenté les principes d un nouveau modèle de confiance [23] à la base de l implémentation de l application Convergence [24]. Le modèle présente un système de confiance décentralisé basé sur des entités appelées «notaires». Chaque notaire offre une liste de noms de domaine et de certificats associés (assimilable à une liste de «certificate pinning»). En disposant d un nombre suffisant de sources, un utilisateur peut alors comparer les certificats associés aux noms DNS par chacun des notaires et s assurer qu aucune attaque SSL n est en cours pour le site qu il consulte. En cas de discordance entre les listes des notaires, l utilisateur est alors averti qu une attaque est peut-être en cours sur sa connexion. Cette solution reste actuellement à l état de preuve de concept. En 2012, Moxie Marlinspike et Trevor Perrin ont aussi soumis un draft à l IETF proposant une extension au protocole TLS pour y inclure un procédé faisant porter au serveur le mécanisme de «pinning» [25]. La solution proposée reste toujours vulnérable aux attaques de type Man-in-the-Middle lors de la première connexion à un serveur Limitations cryptographiques Nous avons parcouru les limitations existantes dans l implémentation de la RFC 5280 dans les produits du marché, mais il ne s agit pas du seul écueil de la confiance numérique. En effet, la sécurisation des informations grâce aux certificats numériques repose aussi sur une brique essentielle : les protocoles cryptographiques. Avec la volonté toujours grandissante de protéger ses données sur internet, de nombreux chercheurs se sont penchés sur les algorithmes et outils cryptographiques existant afin d en étudier le niveau de sécurité et les mauvaises surprises sont nombreuses. En complément de ces travaux, les récentes révélations d Edward Snowden sur les activités de la NSA nous ont apportés un éclairage nouveau sur le sujet. Les problèmes liés à la sécurité cryptographique des données sont de plusieurs natures : Évolution des connaissances de cryptanalyse ; Évolution de la puissance de calcul des systèmes informatiques ; Erreur d implémentation technique d un algorithme ; Erreur de conception du protocole cryptographique ;Insertion de portes dérobées dans les systèmes cryptographiques. 8 La Lettre CERT-Solucom N 2 janvier 2014

9 Nous ne détaillerons pas ces différents types de problèmes, mais nous pouvons néanmoins citer quelques exemples significatifs : Projet BULLRUN de la NSA [26] : ajout de portes dérobées dans certains systèmes, utilisation de supercalculateurs pour tenter de déchiffrer les données protégées (SSL, IPSEC, SSH, etc.), entre autres choses. Bug Openssl Debian [27] : erreur d adaptation de Openssl à Debian limitant l entropie de son PRNG à 15 bits. Influence des standards NIST par la NSA [28] : ajout «d erreurs de conception» volontaires dans l algorithme Dual_EC_DRBG par la NSA permettant de prédire les clés générées. AC ou certificat pirate signé en MD5 [29] [30] : création d une AC ou d un certificat pirate considéré comme valide en provoquant une collision MD5. Porte dérobée sur les NAS QNap [31] : lorsqu un utilisateur chiffre une donnée celle-ci est chiffrée avec une clé de «recouvrement» non protégée. Pour chacun de ces cas, les conséquences sont plus ou moins importantes, les menaces variant d un bug exploitable par le commun des mortels à l espionnage étatique requérant des moyens matériels et financiers importants. Afin de pallier à ces problèmes, les contre-mesures suivantes peuvent être envisagées : Utiliser des clés de déchiffrement de grande taille (le RGS [32] recommande des clés RSA de 2048 bits pour les algorithmes asymétriques et pour une utilisation ne dépassant pas 2030). Utiliser des algorithmes de hash toujours considérés comme robustes (le RGS recommande notamment la génération d empreintes de 200 bits pour une utilisation ne dépassant pas 2020). Utiliser des implémentations et des outils de chiffrement éprouvés par la communauté informatique. Si possible, privilégier l utilisation de standards ayant fait l objet d études et de validations par les communautés informatique et mathématique. Même si l application de ces contre-mesures peut paraître simple, l évolution de la cryptanalyse peut du jour au lendemain battre en brèche ces principes. De plus, certaines entreprises pourront rencontrer des problèmes avec des applications historiques ne supportant pas des tailles de clés importantes ou des algorithmes de hachage récents (support de la suite SHA-2 par exemple). Dans tous les cas, il est et restera toujours difficile de s assurer que les produits éditeurs utilisés sont exempts de toute porte dérobée cryptographique. Le protocole S/MIME, par exemple, applique un principe de chiffrement hybride proche de celui décrit précédemment. Dans le scénario classique, une paire de clé RSA est utilisée pour chiffrer une clé symétrique générée par le client S/MIME permettant ensuite de chiffrer le contenu du mail envoyé. Si cette clé symétrique est prédictible, peu importe la robustesse du chiffrement asymétrique appliquée, la communication pourra être facilement déchiffrée. Dans ce type de cas, l audit de code, la rétro-ingénierie, ou l utilisation de garanties auprès de l éditeur restent les seules solutions. 4. Un problème entre le clavier et internet Il est de coutume de dire que l utilisateur est fautif, et que le problème se situe entre la chaise et le clavier, mais cette dernière partie vise à dédouaner l utilisateur au détriment de son dispositif de connexion (souvent son poste de travail, son smartphone ou sa tablette). Comme nous avons pu le démontrer à plusieurs reprises auparavant, le dispositif de l utilisateur a sa part de responsabilité dans la confiance numérique, nous allons essayer de voir dans quelle mesure Magasin de confiance ou presque Comme expliqué précédemment, le protocole de vérification de la validité d une chaîne de certification repose sur la constitution d un magasin de confiance. Dans le cas d un poste de travail, plusieurs de ces magasins sont disponibles, l utilisation de chacun d eux dépendant de l application utilisée. Les plus couramment consultés sont les suivants : Figure 9 : interception des communications SSL sur iphone La Lettre CERT-Solucom N 2 janvier

10 Un autre point intéressant est que la mise à jour de ces différents magasins est implicite et non-sollicitée. Pour Java, l élément déclencheur est la mise à jour de la JRE. Pour Mozilla, la mise à jour automatique des applications provoque le même résultat. Du côté de Windows, la mise à jour est automatique lors de l application des correctifs mensuels ou à la volée lorsqu un utilisateur rencontre pour la 1 ère fois une nouvelle AC non présente dans son magasin mais reconnue par le programme Microsoft. Figure 10 : certificat SSL légitime émis par l AC intermédiaire Etisalat Magasin de confiance Mozilla : utilisé par les applications développées par la fondation Mozilla. Magasin de confiance Java : utilisé par les applications utilisant la machine virtuelle Java (appelé aussi TrustStore). Magasin de confiance Windows : utilisé par toutes les applications Microsoft ainsi que toutes les applications utilisant les API cryptographiques de Windows. Ces différents magasins contiennent un ensemble de certificats d AC racine auxquels les applications qui les utilisent vont faire confiance. Ceux-ci sont donc à la base de la sécurité des échanges sur internet. Si une AC racine malveillante y est présente, mon application y fera aveuglément confiance. Le magasin de certificat s impose donc comme une pierre angulaire de la confiance numérique. Or il nous réserve une importante surprise Au moment de la rédaction du présent article, le magasin Windows [33] contient 354 AC racines, celui de Mozilla [34] 166, et celui de Java seulement 78. La disparité est importante et nous nous y sommes particulièrement intéressés. Le premier constat vient du fait que le magasin Java ne contient que les certificats des acteurs majeurs et reconnus de la PKI, parmi eux : Entrust, Equifax, Geotrust, Globalsign, Keynectis, Thawte, Verisign. À l inverse, certaines autorités que l on retrouve dans les magasins Windows ou Mozilla font beaucoup moins référence dans le domaine de la PKI et appartiennent à de nombreux opérateurs «régionaux». Le niveau de confiance de ces dernières est très complexe à évaluer. De plus, certaines autorités de certifications sont beaucoup plus exotiques, comme les certificats des gouvernements autrichien, brésilien, chinois, français, indien, coréen, japonais, taïwanais, américain, tunisien, Au total, ce sont plusieurs dizaines de certificats gouvernementaux ou appartenant à des organismes assimilés que l on peut lister (majoritairement chez Microsoft, Mozilla n en ayant que quelques-uns). À l heure des révélations des secrets de chaque état sur les écoutes internet, la présence de ces certificats dans les magasins peut poser un problème éthique. Il est cependant peu probable que les AC étatiques soient directement utilisées pour réaliser des interceptions. Si des interceptions doivent être perpétrées, il est préférable de compromettre une autorité sans lien avec un gouvernement national telle que Comodo ou Diginotar puis de l utiliser pour générer de faux certificats. À la vue de ces éléments, on comprend rapidement la nécessité de nettoyer les différents magasins. Pour autant, le choix des Autorités à conserver et de celles à supprimer n est pas simple. Pourrait-on, par exemple, supprimer les certificats des gouvernements américain ou chinois? Même si cela nous prémunirait d une attaque par ces gouvernements, l usage de la chaîne de certification peut être légitime pour les utilisateurs naviguant sur les sites institutionnels de l état. Ce principe de précaution peut évidemment s appliquer à tous les certificats présents dans les magasins et rend le nettoyage extrêmement complexe. Les autres réponses au problème pourraient être le «certificate pinning» (si le nombre de noms DNS à sécuriser est limité) ou les solutions de Moxie Marlinspike présentées précédemment Sécurité des certificats numériques Nous avons jusqu à présent beaucoup parlé de l utilisation des clés et des certificats sans aborder la façon dont ils sont stockés sur les postes de travail et surtout comment les clés privées sont sécurisées. Les magasins de confiance ne listant que la partie publique des certificats, seule l intégrité du magasin a besoin d être assurée. Par contre, il est nécessaire d assurer à la fois l intégrité et la confidentialité des clés privées qui ne doivent être connues et utilisables que de leur seul porteur. Le dispositif de sécurisation le plus simple est la protection logicielle des clés via les API cryptographiques du système. Dans ce cas, la protection est souvent assurée par un code PIN ou par un mot de passe utilisateur. Au-delà du niveau de sécurité hasardeux que cela peut apporter, dès que l accès aux clés privées est déverrouillé par l utilisateur, plus rien n empêche une application malveillante de voler ou d utiliser les clés en question. Cette protection minimaliste est loin d être suffisante pour les clés exigeant un niveau de sécurité moyen ou important. Des solutions beaucoup plus robustes, mais aussi beaucoup plus contraignantes, requièrent l utilisation de puces TPM (puce électronique installée sur les cartes mères d appareils équipés) ou de cartes à puce. Ces deux composants physiques possèdent le même avantage : ne pas permettre la divulgation des clés privées qu ils hébergent. Mais ces solutions sont matérielles et leur déploiement peut s avérer extrêmement complexe. Lors de la distribution de certificats sur carte à puce, comment s assurer de la transmission du support et du code PIN associé dans des conditions de sécurité suffisantes? Si la remise de la carte à puce est effectuée à distance, comment puis-je m assurer de l identité de la personne la recevant? Puis-je envoyer la carte à puce et le code PIN dans la même enveloppe? Si la puce TPM ou la carte à puce d un utilisateur est bloquée (trop de codes PIN erronés tapés), comment mettre en place un processus sécurisé de déblocage? 10 La Lettre CERT-Solucom N 2 janvier 2014

11 4.3.Sécurité du poste de travail Même en mettant en œuvre des dispositifs matériels comme vu précédemment, il ne faut pas oublier que la sécurité du poste de travail reste un point essentiel. En exemple, partant de l hypothèse qu un attaquant dispose d un accès à un poste de travail corrompu, Max Moser et Thorsten Schröder ont pu démontrer en 2010 la capacité à pirater l utilisation du dispositif cryptographique SuisseID [35]. S il est difficile de maîtriser la sécurité du poste de travail d un utilisateur en dehors du domaine de l entreprise, une partie de la réponse au problème peut être l utilisation de dispositifs cryptographiques utilisant des claviers intégrés par exemple (Pinpad Reader). Cette solution pourrait prévenir de l utilisation malveillante d une carte à puce en obligeant le pirate à disposer d un accès physique au lecteur. Mais d autres menaces techniquement moins compliquées et tout aussi efficaces existent : les attaques de type Man-in-the-Browser [36]. Dans le cas d une attaque Man-in-the-Browser ou de la corruption du poste de travail de l utilisateur, le chiffrement des communications via SSL/TLS n est d aucun secours. En effet dans ce scénario le pirate a pris le contrôle d un point de terminaison SSL, il est donc en mesure d intercepter les données avant chiffrement ou après déchiffrement. La qualité d une signature électronique n est pas non plus assurée, dans ces conditions il est impossible d assurer le WYSIWYS (What You See Is What You Sign). Le pirate pourrait aisément choisir de modifier les données affichées à l écran et inciter l utilisateur à signer en réalité un tout autre document. 5. Un niveau de confiance imposé à l utilisateur L article a pu mettre en évidence toutes les difficultés rencontrées à mettre en place une vraie confiance numérique. Une fois n est pas coutume, ces difficultés n impliquent pas l utilisateur qui la plupart du temps se contente de se fier au petit cadenas présent à côté de l URL dans son navigateur. Il est évident qu aujourd hui la confiance numérique, notamment sur internet, est bâtie sur un écosystème technique et organisationnel unique, fragile, complexe et friable. L utilisateur n a d autre choix qu un niveau de confiance tout relatif. 6. Conclusion Le système de confiance actuellement en place peine à remplir ses fonctions : le foisonnement d autorités de certification permet à de nombreux gouvernements ou à des pirates ayant pu compromettre l une de ces autorités d intercepter les communications de citoyens, d entreprises ou même de gouvernements. D autre part les failles d implémentation peuvent invalider un système. Si la mise en place d un système de confiance numérique unique, étendu et ubiquitaire dans un paradigme unique n est à l heure actuelle pas possible compte tenu d erreurs fondamentales de conception et des très nombreux problèmes d implémentation, il est cependant possible de définir des paradigmes plus restreints dans lesquels une confiance relative peut être établie. Une entreprise peut par exemple se doter de sa propre PKI pour sécuriser ses échanges de données en interne, assurant un niveau de confiance adéquat pour cet usage. Le plus important est d être conscient des limites intrinsèques aux technologies et de leurs implémentations pour être en mesure d évaluer le risque résiduel et de déployer des contre-mesures organisationnelles adéquates. «Le trop de confiance attire le danger» [37] Michel Girier et Kévin Guerin Consultants en sécurité La Lettre CERT-Solucom N 2 janvier

12 Références : [1] Référentiel Général de Sécurité version Annexe A2, [2] Internet X.509 Public Key Infrastructure Time-stamp Protocol (TSP), [3] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, [4] Online Certificate Status Protocol Algorithm Agility, ietf.org/rfc/rfc6277.txt [5] ETSI Electronic Signature, technologies-clusters/technologies/security/electronic-signature [6] XML Signature Syntax and Processing (Second Edition), [7] Comodo Report of Incident, Fraud-Incident html [8] Black Tulip - Report of the investigation into the DigiNotar Certificate Authority breach, documenten-en-publicaties/rapporten/2012/08/13/black-tulipupdate/black-tulip-update.pdf [9] Fraudulent Google certificate points to Internet attack, news.cnet.com/ _ /fraudulent-googlecertificate-points-to-internet-attack/ [10] An update on attempted man-in-the-middle attacks, [11] Microsoft Releases Security Advisory , technet.com/b/msrc/archive/2011/08/29/microsoft-releases-securityadvisory aspx [12] Fraudulent *.google.com Certificate, security/2011/08/29/fraudulent-google-com-certificate/ [13] VASCO Announces Bankruptcy Filing by DigiNotar B.V., vasco.com/company/about_vasco/press_room/news_archive/2011/ news_vasco_announces_bankruptcy_filing_by_diginotar_bv.aspx [14] Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI), [15] Further improving digital certificate security, html [16] TurkTrust incident details, [17] Electromagnetic Eavesdropping Risks of Flat-Panel Displays, [18] Module Apache mod_ssl, mod_ssl.html [19] Trustwave s SpiderLabs Security Advisory TWSL , https://www.trustwave.com/spiderlabs/advisories/twsl txt [20] Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security, p50-fahl.pdf [21] Researcher: Middle East Blackberry Update Spies on Users, [22] Clarifying The Trustwave CA Policy Update, [23] SSL And The Future Of Authenticity, org/blog/ssl-and-the-future-of-authenticity/ [24] Convergence, [25] Trust Assertions for Certificate Keys, draft-perrin-tls-tack-02 [26] N.S.A. Able to Foil Basic Safeguards of Privacy on Web, [27] Bulletin d alerte Debian - DSA openssl -- Générateur de nombres aléatoires prévisible, dsa-1571 [28] The Many Flaws of Dual_EC_DRBG, [29] Creating a rogue CA certificate, research/rogue-ca/ [30] Analyzing the MD5 collision in Flame, com/resources/flame-md5.pdf [31] Mitre CVE , cgi?name=cve [32] Référentiel Général de Sécurité version Annexe B1, [33] Windows and Windows Phone 8 SSL Root Certificate Program (Member CAs), articles/14215.windows-and-windows-phone-8-ssl-root-certificateprogram-member-cas.aspx [34] Mozilla Included CA Certificate List, projects/security/certs/included/ [35] SuisseID and npa Weaknesses, articles/suisseid_and_npa_weaknesses/index.html [36] Man-in-the-browser, [37] Pierre CORNEILLE, Le Cid, Acte II scène VI 12 La Lettre CERT-Solucom N 2 janvier 2014

13 Extrait d actualité Sélection octobre / décembre 2013 De la désinformation en matière de systèmes cryptographiques S il est une leçon à retenir des révélations du New York Times du 5 septembre dernier [NYT] sur le travail de sape effectué par la NSA et ses consœurs sur un grand nombre de systèmes et de standards de chiffrement, c est que l illusion de sécurité est autrement plus dangereuse que l insécurité elle-même. De la condamnation de Marie Stuart au Télégramme Zimmermann (ayant précipité l entrée en guerre des USA en 1914) en passant par le décryptage des communications de l armée allemande durant la seconde guerre mondiale, l Histoire regorge de cas où une confiance aveugle en un système de chiffrement a eu des conséquences décisives. Scénario fiction : quelles méthodes pour intercepter des communications chiffrées? Note : le présent article n affirme aucunement qu une telle action ait été réalisée par les différents acteurs de ce domaine, mais explore, de façon purement théorique, cette possibilité et les conséquences en découlant. Contournement des systèmes de chiffrement Supposons que nous soyons une entité chargée d intercepter une grande partie des communications mondiales. Une très grande partie des échanges n est pas chiffré, les données sont directement exploitables ; et sur le peu restant une très grande partie interagit avec des serveurs sous notre juridiction, auquel cas un accès direct aux données en clair est possible (google, apple, facebook, skype, etc. via PRISM). Il reste donc une quantité relativement faible à cibler par différentes méthodes [NYT] : la mise en place de backdoors logicielles ou matérielles, avec ou sans la coopération des entreprises ciblées (obligation légale, influence économique, intrusion informatique ou manipulation humaine), des attaques ciblées et l influence des standards (sans oublier bien sur l usage de supercalculateurs ou des avancées mathématiques). Si les attaques ciblées sont efficaces elles restent coûteuses et la solution optimale serait de pousser les cibles à utiliser des solutions backdoorées. et désinformation Afin de créer cette illusion de sécurité, 3 ingrédients de base pourraient être, entre autres, intéressants à combiner. Des arguments techniques : Un subtil équilibre entre des preuves techniques complexes (à base d algorithmes et/ou des brevets) et des arguments facilement compréhensible («les clefs sont sous votre contrôle», «nous ne générons pas les clefs», «vous pouvez utiliser des cartes à puces de fabrication nationale») mais omettant certaines nuances techniques. Des exemples du bon fonctionnement de cette approche, de préférence relayée par des médias généralistes de référence : Distiller discrètement des informations dans la presse indiquant que ces méthodes fonctionnent (de préférence indiquant que les forces de l ordre n ont pas réussi à obtenir l information, dans des médias alternatifs en proposant des conseils aux «hacktivistes», ou indiquant que le gouvernement utilise ces mêmes solutions pour ses données sensibles). Des alternatives coûteuses ou contrôlées : Influencer le marché de sorte à ce que les alternatives soient coûteuses (financièrement ou en termes d usage) et contrôler les concurrents. La question de savoir si les entreprises seraient prêtes à utiliser des systèmes potentiellement backdoorés en toute connaissance de cause, ne se pose plus dans le contexte actuel. Mises à part quelques entreprises et organisations étatiques traitant de données particulièrement confidentielles, la grande majorité des entités vont aujourd hui se reposer sur des smartphones souvent interfacés avec un NOC étranger (et ce malgré les nombreux avertissements du SGDSN et les polémiques dans la presse depuis près de 10 ans), avec dans le meilleur des cas un VPN, un canal SSL et une solution de MDM, le tout d origine anglo-saxonne. Quelques cas concrets Il n est évidemment pas certain du caractère volontaire de certaines conceptions, ni de l usage explicite par la NSA de ces biais, mais à la lumière des récentes actualités, certaines interrogations demeurent. La Lettre CERT-Solucom N 2 janvier

14 Extrait d actualité Apple imessage Le cas d imessage d Apple est particulièrement intéressant. CNN titrait en avril dernier (soit avant la révélation de l affaire PRISM) «Apple s imessage is the DEA s worst nightmare». On peut lire en particulier que l usage du produit permet d éviter les écoutes et affirme via un document interne que l agence est incapable d intercepter ces communications («Apple s seemingly innocuous imessage app is giving the U.S. Drug Enforcement Agency endless amounts of grief, because law enforcement is not able to trace and track text message conversations sent via Apple s service.»). Bien que quelques experts aient contredit ces déclarations [CE], l article est repris par de nombreuses sources et l information est largement diffusée. Puis viennent les révélations de Snowden, l entreprise fait partie des sources nourrissant PRISM. La réponse d Apple est de nier son implication dans PRISM et d indiquer que les communications sont protégées par un chiffrement de bout en bout [APP1] : «We do not provide any government agency with direct access to our servers, and any government agency requesting customer content must get a court order. [ ] For example, conversations which take place over imessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them. Apple cannot decrypt that data.» Or des chercheurs de Quakslab ont présenté [QL] à la conférence HITB en octobre dernier, une étude du protocole imessage indiquant que contrairement aux affirmations d Apple, ceux-ci sont bien techniquement en mesure d intercepter ces messages. Les chercheurs mettent en avant le fait que l infrastructure de gestion de clefs est intégralement gérée par Apple (et qui donc peut remplacer à la volée les clefs) et que le ceritficate pining n est pas utilisé pour les communications SSL : un gouvernement ou une entité ayant un influence sur un des certificats racine reconnus par l iphone peut intercepter la couche SSL. S/MIME Dans le cas de S/MIME, la plupart des entreprises insistent pour générer elle-même les bi-clefs de chiffrement et dans certains cas de les stocker sur carte à puce («la clef privée ne pouvant quitter la carte, elle ne peut être volée»). Or dans de nombreux cas de systèmes hybrides de chiffrement, si le chiffrement asymétrique est bien opéré sur la carte, la génération de la clef symétrique et la partie symétrique du chiffrement est directement opérée sur le poste de travail (souvent pour des raisons de performances). Se pose alors la question de savoir dans quelle mesure le PRNG utilisé peut-il être considéré comme fiable et si le logiciel de messagerie peut faire fuiter la clef par un canal caché inclus dans le message sortant? (souvenons-nous que le gouvernement américain aurait fait placer une porte dérobée dans le système de chiffrement de Lotus Notes à la fin des années 90 [LO] ) Au-delà des aspects cryptographiques : le cas des brouillons Pendant des années de nombreux sites terroristes ont préconisé d utiliser les brouillons afin d éviter les écoutes : les deux destinataires créent une adresse jetable sur gmail / yahoo / hotmail, rédigent leurs messages et les sauvegardent dans les brouillons. Le message n étant pas émis, il ne serait pas sujet à interception. Sauf si bien sûr l agence a un accès complet aux données sur le serveur et peut accéder aux brouillons. Quelles solutions? Puisque suite aux dernières révélations du New York Times, Spiegel, Washington Post ou encore du Guardian, tout produit «closed source» doit être considéré comme backdooré, il ne reste que deux alternatives : les produits de conception nationale et les produits open source. Pour autant peuvent-ils être considérés de confiance? Produits nationaux Bien que les produits nationaux peuvent présenter des vulnérabilités, que l entreprise les produisant puisse être pénétrée par une agence de renseignement étrangère, s appuyer sur des briques logicielles tierces elle-même compromises (réutilisation d interfaces cryptographiques du système d exploitation et de composants open-source) ou encore qu ils puissent s appuyer sur des standards ayant fait l objet d influences, la seule solution reste de s appuyer sur l évaluation effectuée par le gouvernement. Produits open source Deux facteurs sont à prendre en compte : Un produit open source n est pas immunisé face aux portes dérobées ou aux erreurs de programmation. L une des exemples les plus flagrant est la vulnérabilité dans le PRNG d OpenSSL dans Debian en 2008 qui a n a été détecté qu un an et demi après [OpenSSL] ; En pratique, très peu d audits du code et de l implémentation sont réalisés. 14 La Lettre CERT-Solucom N 2 janvier 2014

15 Extrait d actualité Si l on considère les produits de chiffrement généralement reconnus comme étant de qualité et utilisable par des non experts, la liste est assez réduite. La liste conseillée par Bruce Schneier, sur la façon de se protéger face aux écoutes (GPG, Silent Circle, Tails, OTR, TrueCrypt) présente un nombre encore plus restreint de produits. Si certains de ces logiciels sont écrits par des experts reconnus dans le domaine (comme GPG ou OTR) pour d autres, l auteur en est inconnu, c est en particulier le cas de Truecrypt. Des portes dérobées dans Truecrypt? La sécurité de tels produits est primordiale et les données révélées par Snowden sur les difficultés de la NSA à effectuer une analyse massive des communications Tor montre à quel point un système de chiffrement bien implémenté peut compliquer une attaque. Pourtant, mises à part quelques analyses ponctuelles effectuées par l ANSSI, Bruce Schneier & Al ou par l Ubuntu Privacy Remix Team [UB] aucune analyse approfondie et complète du code source et de la modalité de génération et distribution des binaires n a été réalisée. C est à cette tâche que voudrait s atteler Matthew Green [MG] qui a lancé en octobre 2013 une levée de fond pour faire procéder à un audit complet de ce produit. Matthew Green n affirme aucunement que Truecrypt est backdooré, il pointe certains éléments pouvant poser question. En particulier le fait que la version Windows de Truecrypt à partir de la 7.0,qui remplit un header avec des valeurs aléatoires alors que celles-ci sont des zéros chiffrés sous Linux, pourrait être utilisé comme canal caché pour faire fuiter une clef de chiffrement. Ce dernier souhaiterait procéder à un audit afin de confirmer le degré de confiance accordé à ce produit. Conclusion Même si un système de chiffrement ne peut en soi suffire à empêcher une mise sous écoute par une agence de renseignement, il peut néanmoins en augmenter fortement le coût. Outre les solutions nationales, les solutions open source présentent une bonne alternative, encore faut-il qu elles soient auditées en profondeur, ce qui n est aujourd hui malheureusement pas toujours le cas. Ainsi, dans un contexte sensible, la meilleure possibilité reste-t-elle encore de croiser plusieurs couches indépendantes de chiffrement, tout en restant conscient d éventuelles interactions entre elles. Références : [NYT] [CE] [APP1] [OpenSSL] [OpenVPN NL] https://openvpn.fox-it.com/ [UB] https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-en.pdf [MG] [QL] [LO] Explosion du Bitcoin : attention aux malwares de minage «Bitcoin est une monnaie électronique distribuée. Elle permet le transfert d unités appelées bitcoins à travers le réseau internet. Les Bitcoins ainsi échangés ont vocation à être utilisés en tant que devise monétaire et comme moyen de paiement dans cette devise.» (Wikipédia) Cette e-monnaie ne dépend d aucune banque centrale ni d aucune institution monétaire. Vendredi 29 Novembre, le Bitcoin a dépassé la valeur d une once d or alors qu il y a trois ans le bitcoin ne valait même pas 1 $. Oui, ce serait une bonne idée d aller récupérer vos vieux disques durs [1] Pourquoi une telle envolée? Parce que la valeur du Bitcoin est régie par le simple principe de l offre et de la demande amplifié par un phénomène de bulle spéculative. Pourquoi parler de Bitcoin? Avant tout, revenons au principe de génération et de contrôle de Bitcoin. Comme évoqué précédemment, Bitcoin est une monnaie distribuée. Cela signifie que les paiements via Bitcoin ne sont pas contrôlés par une seule et unique source mais par de nombreuses sources différentes. Or, ces sources de contrôle sont tout à fait anonymes et n importe quel système informatique peut devenir un «contrôleur». Pour cela, ce système va effectuer ce que l on appelle du «minage» de Bitcoins (Bitcoin mining) : il s agit de «troquer» du temps CPU pour effectuer les contrôles des transactions financières contre rémunération sous forme de Bitcoins. Avec autant de sommes en jeu et une possibilité de se «forger» son propre argent, il est compréhensible que certaines personnes malveillantes souhaitant faire du profit rapidement se penchent sur le cas Bitcoin. Ajoutons à cela le côté «underground» historique du Bitcoin et on comprend rapidement pourquoi on trouve de plus en plus de systèmes infectés devenant des zombies Bitcoin miners.... dans la lettre CERT? Le CERT-Solucom est récemment intervenu suite à la compromission d un serveur client. Nous passerons l exploitation d une faille PHP5 (CVE dont un exploit a été rendu publique récemment) pour nous intéresser aux outils déposés par l attaquant. L analyse de la mémoire du système nous a permis d identifier plusieurs processus suspects : Après récupération (dump du processus) de l exécutable, nous avons recherché sa présence sur le système de fichiers. En analysant les différents fichiers adjacents, nous avons pu découvrir d autres outils suspects notamment «m64» et «rsyslogd» (déjà vu dans la liste des processus lancés sur la machine). Il est à noter que peu de moteurs antiviraux sont en mesure de détecter ces fichiers comme malveillants. Liste des processus La Lettre CERT-Solucom N 2 janvier

16 Extrait d actualité Fichier suspect : m64 Détection Virustotal : 3/47 Nom : BitcoinMiner Fichier suspect : Minerd Détection Virustotal : 7/47 Nom : BitcoinMiner Fichier suspect : Rsyslogd (fichier équivalent à minerd, simplement renommé) Détection Virustotal : 7/47 Nom : BitcoinMiner Outre ces exécutables, nous avons également pu mettre la main sur un fichier de configuration des miners : { «url» : «stratum+tcp://xxx.xxx.xxx. xx:3333», «user» : «xxxxxxx», «pass» : «yyyyyyy», «algo» : «scrypt», «no-longpoll»: true, «background»: true, «quiet» : true } Le site de destination, ici anonymisé «xxx.xxx.xxx.xx», permet de s enregistrer comme ressources pour le minage de bitcoins au sein d un pool de serveurs «contrôleurs». Autre caractéristique intéressante, la date de soumission et de dernière analyse des binaires sous VirusTotal : tous les scans datent de moins de 10 jours (le plus ancien datant du 22 novembre). Cela signifie que les outils de minage que nous avons pu détecter sont récents et qu il est fort à parier qu une infection à plus large échelle est en cours. Ainsi, en plus des Webshells classiques déposés par les robotsscanneurs d internet, il y a de grandes chances pour que nous découvrions de plus en plus de «Bitcoin miners» sur les systèmes infectés. Sources : [1] BRUCON 2013 Du 23 au 27 septembre derniers se tenait en Belgique, à Ghent, la 5 ème édition de la conférence de sécurité BruCon. Retour sur cet événement. Nous avons commencé la semaine par trois jours de formation «Pentesting Scada and Smartgrid», dédiés à la sécurité des systèmes industriels. On retiendra en particulier l excellente keynote de Dan Guido, de la société Trails of bits, qui nous a présenté de manière décomplexée une analyse des attaques informatiques, à la fois côté exploit packs disponibles commercialement et côté campagnes d APT. Sur les exemples qu il a pu recenser, les «exploits» étaient plutôt simples, et peu fiables ; ceux de la campagne APT «Elderwood», par exemple, ne fonctionnent en effet qu environ une fois sur deux. Des étudiants en université sont capables, après une semaine de formation, de produire des exploits de meilleure qualité que ceux utilisés dans les campagnes APT. Java reste la cible privilégiée des attaquants car cela facilite l exploitation, en contournant les mécanismes DEP, ASLR et de sandboxing mis en œuvre sur les navigateurs récents. Bien que le niveau de sécurité d une machine neuve en 2013 est bien meilleur que celui d une machine il y a 2 / 3 ans, l investissement nécessaire à la compromission reste faible ; les attaquants vont facilement passer à des techniques plus avancées lorsque cela sera nécessaire. Enfin, la partie questions / réponses fut très intéressante, avec notamment une réponse qui a fait réagir l assistance : «la sensibilisation des utilisateurs est la pire des choses que vous puissiez faire». Évidemment, ce n est pas la nécessité de sensibiliser les utilisateurs qui est remise en cause. La réponse était plutôt une manière de recadrer le problème. Lorsqu un attaquant peut compromettre votre SI pendant plusieurs années, exfiltrer des dizaines de giga-octets de données sans être détecté ni bloqué, c est un problème d ingénierie, pas de sensibilisation. Les interventions sont disponibles en vidéo sur la chaîne YouTube de l événement : Cette formation très technique nous a permis, grâce au matériel fourni, d approfondir nos connaissances dans les domaines suivants : Architectures SCADA Interception et décodage de communications radio Bus snooping, permettant l interception de données en se connectant directement sur les puces mémoires Extraction des données stockées dans des EEPROM en se connectant physiquement sur le circuit Le reste de la semaine était consacré aux conférences de sécurité, toutes d un bon niveau technique et abordant des sujets très variés, des malwares Android à la géolocalisation GSM, en passant par l ingénierie inverse d application Microsoft.NET. Carte d entraînement distribuée lors de la formation Pentesting Scada and Smartgrid 16 La Lettre CERT-Solucom N 2 janvier 2014

17 Extrait d actualité Vol de données personnelles, vol du code source : Adobe sous les feux de la rampe Le 3 octobre, Adobe annonce être victime d une importante attaque informatique depuis au moins près de deux semaines. Par la suite, des informations communiquées par l éditeur font état d une attaque commencée mi-août et portant tout d abord sur un périmètre du SI Adobe gérant les transactions bancaires de ses clients avant de s étendre à d autres périmètres et notamment aux dépôts de code source de certaines applications. Deux types de données ont été volées. Des données personnelles Les attaquants ont été en mesure de mettre la main sur près de 3 millions de comptes clients : des noms, des mots de passe (tout au moins les condensats), des informations sur des commandes déjà passées et, non des moindres, des données cartes bancaires (numéros de carte, a priori chiffrés, et dates d expiration). Du code source Non content de leur pillage, les attaquants ont également mis la main sur le code source de plusieurs applications Adobe dont Acrobat, ColdFusion et ColdFusion Builder. Enfin, il est fort probable que des certificats permettant de signer le code des applications Adobe aient également été volés. Les dépôts de code source accédés par les attaquants sont toujours en cours d analyse par Adobe mais pour le moment l intégrité du code semble être conservée. Cette fuite du code source devrait toutefois redonner un second souffle à la recherche de vulnérabilités sur les produits Adobe. Ne soyons pas étonnés de voir prochainement de nouveaux exploits sur ces produits. En réaction, Adobe a mis en œuvre plusieurs mesures : Renouvellement des mots de passe de tous les comptes utilisateurs. Révocation des certificats permettant de signer les applications Adobe. Notification de tous les utilisateurs, et en particulier ceux pour lesquels il y a une forte présomption de vol des informations CB. Notification des banques utilisées par Adobe. Notification des instances fédérales. Mise en place d une page d alerte à la clientèle. Proposition d une option de monitoring de l activité des comptes clients pendant un an. Correction (hâtive?) de vulnérabilités dans les produits Adobe (APSB13-25). Sources : Évènement OWASP : sécurité de Firefox OS Fin septembre, l OWASP France organisait une rencontre avec Mozilla sur la sécurité dans Firefox OS. Pour rappel, Firefox OS est un système d exploitation entièrement mobile : toutes les applications sont développées en HTML / CSS / JS. Paul Theriault, ingénieur sécurité chez Mozilla, nous a expliqué les concepts de sécurité, à savoir : Les applications disposent de privilèges en fonction de leur niveau de confiance : les applications systèmes, packagées avec l OS, ont accès à tout. Les applications en provenance du marketplace ont des droits administrables par l utilisateur. Enfin, Les applications exécutées depuis le navigateur n ont quant à elles aucun droit particulier Le concept de web activities : certaines API peuvent être accédées ponctuellement par des applications non-privilégiées (comme des sites web), en passant par une application système. Exemple : je suis sur un site qui me propose d envoyer un SMS, je clique sur le lien, l application système «SMS» s affiche à l écran et me demande de valider le SMS avant de l envoyer. La gestion fine des permissions par l utilisateur. Il est possible d installer une application sans lui accorder aucun droit, de les ajouter par la suite, de les révoquer au cas par cas. Ségrégation inter-applications : le navigateur et les applications tournent dans des processus différents. Le stockage est propre à chaque application, ainsi que les cookies et le cache. Sources : La vidéo de l événement est sur Youtube : https://www.youtube.com/ watch?v=ymx3ecly8rm Le simulator de Firefox OS s installe comme un add-on pour Firefox : https://addons.mozilla.org/fr/firefox/addon/firefox-os-simulator/ La Lettre CERT-Solucom N 2 janvier

18 Extrait d actualité Analyse géopolitique du mouvement Anonymous Depuis quelques années, les Anonymous ont développé la faculté d attirer l attention des médias dans leurs protestations à base de fuite de données et piratage de masse. Comment en sont-ils arrivés là? Qui tire les ficelles de cette (dés)organisation? Quelques éléments de réponse sont apportés par l anthropologiste GABRIELLA COLEMAN dans une récente étude : «Anonymous in Context: The Politics and Power behind the Mask». Source : Les 5 méthodes les plus efficaces pour pirater un domaine Windows Active Directory Spiderlabs, l équipe de pentesteurs de Trustwave, nous présente ses 5 méthodes les plus efficaces pour devenir administrateur d un domaine Windows : 1. Netbios and LLMNR Name Poisoning : interception des authentifications en NTLM / NTLMv2 sur le réseau puis cassage des mots de passe Avis de l auditeur : nous utilisons généralement des attaques de type ARP spoofing, qui sont équivalents. C est notamment efficace sur les copieurs/scanneurs qui peuvent contenir des comptes de domaine pour stocker les fichiers scannés sur un partage réseau. Attention aux effets de bord 2. Exploitable JBoss Vulnerability : mot de passe par défaut Avis de l auditeur : Citons également les serveurs Tomcat sur Windows. Souvent, l interface d administration est accessible, avec le mot de passe par défaut, et l application est exécutée avec des privilèges élevés : c est gagné. 3. MS : une vieille vulnérabilité Microsoft, toujours présente (depuis 2008 ) Avis de l auditeur : nous exploitons systématiquement cette faille lorsqu elle est découverte car le taux de réussite est quasiment de 100%... Ensuite, il reste à rebondir vers d autres serveurs Le prochain navire de guerre construit par Raython, l USS Zumwalt, reposera massivement sur Linux et une approche de sécurité par multiples niveaux Une grande partie du système reposera sur un hyperviseur LynuxWorx s LynxSecure (un noyau modifié, temps réél et permettant de faire une séparation à multiple niveau de sécurité). Ainsi plusieurs systèmes et réseaux pourront fonctionner en parallèle sur un même système physique, limitant la place nécessaire, une ressource précieuse sur un bateau. Une approche militaire mais qui tend à se développer de plus en plus dans le monde de l entreprise, les défis et les menaces étant de plus en plus similaires. En effet, les actualités de ces dernières années ont montré à travers de nombreuses attaques ciblées que la bonne configuration seule d un système ou l usage de produits de sécurité (antivirus, équipement réseau, etc) seuls ne permettent pas d arrêter une attaque ciblée sans investissements colossaux. En parallèle l approche par isolation (des systèmes et des réseaux dédiés par niveau de sensibilité) se révèle à la fois plus simple et plus efficace à mettre en place, en minimisant le sacrifice en terme de facilité d usage. Source : the-navys-newest-warship-is-powered-by-linux/ 4. GPO password : définir les mots de passe de comptes locaux par GPO est une mauvaise idée : en effet, tout utilisateur du domaine peut alors accéder à ce mot de passe, obfuscated dans le fichier GPO stocké sur le contrôleur de domaine. Avis de l auditeur : effectivement, c est un des premiers éléments que nous regardons. L avantage est qu il n y a pas besoin de «casser» le mot de passe, il est simplement dans un fichier XML. 5. NetBIOS Null Enumeration Allowed on Server : l énumération des utilisateurs, suivie d attaque brute-force sur le mot de passe, peut se révéler efficace. Avis de l auditeur : trop souvent, des comptes de services (PATROL, controlm, etc) à hauts privilèges disposent d un mot de passe faible et peuvent se connecter sur l ensemble des serveurs... Source : 18 La Lettre CERT-Solucom N 2 janvier 2014

19 Extrait d actualité Une porte dérobée dans mon disque dur, impossible? À l occasion de l ACSAC (Annual Computer Security Applications Conference), une présentation sur le thème des portes dérobées dans les disques durs a été réalisée. Ces recherches ont notamment été réalisées par des personnes d EURECOM, ainsi que Travis Goodspeed (auteur du célèbre : «Real men carry pink pagers»). L objectif était de démontrer que les postes de travail et serveurs ont une confiance aveugle dans les disques durs, et que la mise en place d une porte dérobée n était pas uniquement à la portée d une agence gouvernementale. La menace étudiée est la suivante : un poste de travail / serveur est infectée par un malware, qui va modifier le firmware du disque dur puis s auto-effacer, ne laissant ainsi aucune trace de son passage au niveau du système d exploitation. La première étape a été l ingénierie inverse de disques durs du commerce. Un débugger a notamment été développé et injecté dans la mémoire du contrôleur du disque dur. Cela a permis une compréhension fine des mécanismes de lecture/écriture, ainsi que du format des mises à jour du firmware. Le proof of concept réalisé permet d écrire des blocs arbitraires sur le disque dur, ainsi que de lire certains blocs (mais pas une suite de blocs). Néanmoins, les auteurs présentent une autre porte dérobée (non implémentée techniquement par manque de temps / moyens), qui permettrait la lecture de n importe quel fichier du disque dur, et ce dans une configuration classique de serveur web et d attaquant externe. Quelques pistes de protection sont également présentées dans cet article : Le chiffrement de disque au niveau logiciel pourrait complexifier ce type d attaque Forcer la signature des mises à jour de firmware Utiliser des mécanismes de type IDS pour détecter l exfiltration de données Source : php?module=oc_program&action=summary.php&id=78 La Lettre CERT-Solucom N 2 janvier

20 Le CERT-Solucom Le CERT-Solucom a pour objectif de répondre aux attentes de nos clients en matière de gestion des incidents et des crises sécurité. Les services fournis par le CERT-Solucom Évaluation des risques cybercriminalité et sensibilisation Veille menaces, évaluation d attractivité, cartographie des risques, veille innovations, lien avec la cyber-assurance Audits & tests d intrusion Simulation d attaque cybercriminelle, social engineering, tests d intrusion physiques Investigation numérique / Forensics Détection de compromissions avérées ou suspectées, identification des données ciblées, des méthodes d attaque Gestion de crise cybercriminalité Organisation de crise et tests préalables, pilotage de crises réelles, coordination d intervenants, reporting vers la Direction Générale Accompagnement à la remédiation / continuité d activité Construction des plans d actions, correction de failles, sécurisation du SI, reconstruction ex nihilo de périmètres sécurisés Le CERT-Solucom associe un ensemble d expertises techniques et métiers afin d apporter une réponse globale aux incidents de sécurité. Plus de 45 profils expérimentés sont mobilisables au sein du CERT-Solucom. 1 Directeur de la publication : Pascal Imbert Responsable de la rédaction : Frédéric Goux Contributeurs : Gérôme Billois, Guillaume Bour, Baptistin Buchet, Etienne Capgras, Florent Daquet, Thomas Debize, Matthieu Garin, Damien Godard, Michel Girier, Kevin Guérin, Ary Paul Kokos, Vincent Nguyen, Philippe Planche, Arnaud Soullié. Photographies : Getty images Fotolia Graphiques : Solucom Conception graphique : les enfants gâtés Impression : Axiom Graphics CERT-Solucom Responsable CERT-Solucom : Matthieu Garin Tour Franklin, terrasse Boieldieu La Défense Paris - La Défense abonnement :

Solution de déploiement de certificats à grande échelle. En savoir plus...

Solution de déploiement de certificats à grande échelle. En savoir plus... Solution de déploiement de certificats à grande échelle permet un déploiement des certificats numériques à grande échelle en toute sécurité sans avoir à fournir un support physique (token, carte à puce

Plus en détail

IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr. JTO décembre 2002

IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr. JTO décembre 2002 IGC Infrastructure de gestion de la confiance. Serge.Aumont@cru.fr florent.guilleux@cru.fr JTO décembre 2002 Chiffrement asymétrique Confidentialité d un message : le chiffrer avec la clé publique du destinataire.

Plus en détail

ICP/PKI: Infrastructures à Clés Publiques

ICP/PKI: Infrastructures à Clés Publiques ICP/PKI: Infrastructures à Clés Publiques Aspects Techniques et organisationnels Dr. Y. Challal Maître de conférences Université de Technologie de Compiègne Heudiasyc UMR CNRS 6599 France Plan Rappels

Plus en détail

Cryptologie. Algorithmes à clé publique. Jean-Marc Robert. Génie logiciel et des TI

Cryptologie. Algorithmes à clé publique. Jean-Marc Robert. Génie logiciel et des TI Cryptologie Algorithmes à clé publique Jean-Marc Robert Génie logiciel et des TI Plan de la présentation Introduction Cryptographie à clé publique Les principes essentiels La signature électronique Infrastructures

Plus en détail

Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références

Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références Sommaire Introduction Les bases de la cryptographie Introduction aux concepts d infrastructure à clés publiques Conclusions Références 2 http://securit.free.fr Introduction aux concepts de PKI Page 1/20

Plus en détail

FICHE N 10 SÉCURITÉ DES DONNÉES

FICHE N 10 SÉCURITÉ DES DONNÉES L article 34 de la loi «Informatique et Libertés» impose à un responsable de traitement de prendre toutes les précautions utiles pour préserver la sécurité des données dont il est responsable, en fonction

Plus en détail

Cryptographie. Cours 6/8 - Gestion de clés

Cryptographie. Cours 6/8 - Gestion de clés Cryptographie Cours 6/8 - Gestion de clés Plan du cours Importance de la gestion des clés Clés secrètes, clés publiques Certificats Infrastructure à clé publique (Public Key Infrastructure, PKI) Dans le

Plus en détail

Du 03 au 07 Février 2014 Tunis (Tunisie)

Du 03 au 07 Février 2014 Tunis (Tunisie) FORMATION SUR LA «CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES TRANSACTIONS ELECTRONIQUES» POUR LES OPERATEURS ET REGULATEURS DE TELECOMMUNICATION Du 03 au 07 Février 2014 Tunis (Tunisie) CRYPTOGRAPHIE ET SECURITE

Plus en détail

Cours 14. Crypto. 2004, Marc-André Léger

Cours 14. Crypto. 2004, Marc-André Léger Cours 14 Crypto Cryptographie Définition Science du chiffrement Meilleur moyen de protéger une information = la rendre illisible ou incompréhensible Bases Une clé = chaîne de nombres binaires (0 et 1)

Plus en détail

Porte dérobées : implications du nouveau paradigme de l'industrie des composants microélectroniques

Porte dérobées : implications du nouveau paradigme de l'industrie des composants microélectroniques 10 juin 2014 Porte dérobées : implications du nouveau paradigme de l'industrie des composants microélectroniques Partie 1 : rappels sur les portes dérobées Ary Kokos Contexte & Objectif L une des graals

Plus en détail

1 - Chiffrement ou Cryptage, Déchiffrement ou Décryptage?

1 - Chiffrement ou Cryptage, Déchiffrement ou Décryptage? Avertissements : Le contenu de ce document est sous licence GPL. Le document est librement diffusable dans le contexte de cette licence. Toute modification est encouragée et doit être signalée à othebaud@e-watching.net

Plus en détail

Référentiel Général de Sécurité. version 2.0. Annexe A1

Référentiel Général de Sécurité. version 2.0. Annexe A1 Premier ministre Agence nationale de la sécurité des systèmes d information (ANSSI) Secrétariat général pour la modernisation de l action publique (SGMAP) Référentiel Général de Sécurité version 2.0 Annexe

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN ClearBUS Application cliente pour la communication sécurisée Version 1.12 Le 25/11/2011 Identifiant : CBUS-CS-1.12-20111125 contact@clearbus.fr tel : +33(0)485.029.634 Version 1.12

Plus en détail

Security Party. Marc SCHAEFER. 22 octobre 2009

Security Party. Marc SCHAEFER. 22 octobre 2009 Security Party Marc SCHAEFER 22 octobre 2009 Résumé L utilisation d outils cryptographiques est essentielle aujourd hui : que ce soit pour chiffrer ou identifier l émetteur d un message électronique ou

Plus en détail

Cryptographie et utilisation. Utilisation de la cryptographie. Rappel des propriétés à assurer. Assurer le secret :stockage.

Cryptographie et utilisation. Utilisation de la cryptographie. Rappel des propriétés à assurer. Assurer le secret :stockage. Rappel des propriétés à assurer Cryptographie et utilisation Secret lgorithmes symétriques : efficace mais gestion des clés difficiles lgorithmes asymétriques : peu efficace mais possibilité de diffuser

Plus en détail

TLS C.1 CRYPTAGE SYMÉTRIQUE. Objectif

TLS C.1 CRYPTAGE SYMÉTRIQUE. Objectif C TLS Objectif Cette annexe présente les notions de cryptage asymétrique, de certificats et de signatures électroniques, et décrit brièvement les protocoles SSL (Secure Sockets Layer) et TLS (Transport

Plus en détail

Signature électronique. Romain Kolb 31/10/2008

Signature électronique. Romain Kolb 31/10/2008 Romain Kolb 31/10/2008 Signature électronique Sommaire I. Introduction... 3 1. Motivations... 3 2. Définition... 3 3. La signature électronique en bref... 3 II. Fonctionnement... 4 1. Notions requises...

Plus en détail

La sécurité dans les grilles

La sécurité dans les grilles La sécurité dans les grilles Yves Denneulin Laboratoire ID/IMAG Plan Introduction les dangers dont il faut se protéger Les propriétés à assurer Les bases de la sécurité Protocoles cryptographiques Utilisation

Plus en détail

Projet Magistère: SSL

Projet Magistère: SSL Université Joseph Fourier, IMA Janvier 2010 Table des matières 1 Introduction 2 Qu est ce que SSL? 3 Historique de SSL/TLS 4 Théorie à propos du fonctionnement de SSL 5 Structure d un certificat 6 SSL

Plus en détail

Offre d archivage des transactions en ligne Certification CSPN Cible sécurité

Offre d archivage des transactions en ligne Certification CSPN Cible sécurité Offre d archivage des transactions en ligne Certification CSPN Cible sécurité Date : 2010-09-08 Référence 20100906-CSPN-CibleSécurité-V1.1.doc VALIDITE DU DOCUMENT Identification Client Projet Fournisseur

Plus en détail

Chapitre 3 INTÉGRITÉ ET AUTHENTIFICATION

Chapitre 3 INTÉGRITÉ ET AUTHENTIFICATION Chapitre 3 INTÉGRITÉ ET AUTHENTIFICATION 32 Services souhaités par la cryptographie Confidentialité : Rendre le message secret entre deux tiers Authentification : Le message émane t-il de l expéditeur

Plus en détail

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE sommaire MIEUX COMPRENDRE LES CERTIFICATS SSL...1 SSL et certificats SSL : définition...1

Plus en détail

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs

Perso. SmartCard. Mail distribution. Annuaire LDAP. SmartCard Distribution OCSP. Codes mobiles ActivX Applet. CRLs HASH LOGIC s e c u r i t y s o l u t i o n s Version 1.0 de Janvier 2007 PKI Server Une solution simple, performante et économique Les projets ayant besoin d'une infrastructure PKI sont souvent freinés

Plus en détail

Technologies de l Internet. Partie 6 : Introduction à la sécurité dans le web Iulian Ober iulian.ober@irit.fr

Technologies de l Internet. Partie 6 : Introduction à la sécurité dans le web Iulian Ober iulian.ober@irit.fr Technologies de l Internet Partie 6 : Introduction à la sécurité dans le web Iulian Ober iulian.ober@irit.fr Cryptage avec clé secrète même clé I think it is good that books still exist, but they do make

Plus en détail

Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D.

Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D. 2013 Windows Server 2008 Sécurité ADMINISTRATION ET CONFIGURATION DE LA SECURITE OLIVIER D. Table des matières 1 Les architectures sécurisées... 3 2 La PKI : Autorité de certification... 6 3 Installation

Plus en détail

vendredi 8 juillet 2011

vendredi 8 juillet 2011 PROCESSUS DE CERTIFICATION ELECTRONIQUE AU BURKINA FASO 1 Sommaire Contexte de la CE Aspects techniques Réalisations et futurs projets de l ARCE Types et domaines d utilisation de certificats Procédures

Plus en détail

Modules M42B4 & M42C3 Patrice GOMMERY

Modules M42B4 & M42C3 Patrice GOMMERY Modules M42B4 & M42C3 Patrice GOMMERY PROBLEMES : Comment générer les couples de clés? Comment distribuer les clés publiques? Comment stocker les clés? La clé publique est-elle réellement garantie? UNE

Plus en détail

CP - NBS System. La sécurité informatique : focus sur les menaces les plus communes et leurs solutions

CP - NBS System. La sécurité informatique : focus sur les menaces les plus communes et leurs solutions La sécurité informatique : focus sur les menaces les plus communes et leurs solutions Nous avons publié en février un article résumant les principaux risques liés au manque de sécurité des sites internet.

Plus en détail

Certificats électroniques

Certificats électroniques Certificats électroniques Matthieu Herrb Jean-Luc Archimaud, Nicole Dausque & Marie-Claude Quidoz Février 2002 CNRS-LAAS Plan Services de sécurité Principes de cryptographie et signature électronique Autorités

Plus en détail

SIGNATURE DIGITALE ET AUTHENTIFICATION FORTE

SIGNATURE DIGITALE ET AUTHENTIFICATION FORTE SIGNATURE DIGITALE ET AUTHENTIFICATION FORTE Michel Laloy 18/06/2002 Objectifs Expliquer les mécanismes de la signature digitale et de l authentification forte Montrer comment ces mécanismes s'appliquent

Plus en détail

Politique de signature OID : xxx.xxx.xxx.xxx

Politique de signature OID : xxx.xxx.xxx.xxx ALIENCE INTERNATIONNALE DES ASSURANCES Politique de signature OID : xxx.xxx.xxx.xxx Version 1.0 AID 3 RUE ALLAL BEN ABDALLAH 20000 CASABLANCA FAX :05 22 27 52 94 TEL : 05 22 48 38 38 MAIL : INFO@AID.MA

Plus en détail

FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE

FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE FORMATION SUR «CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES TRANSACTIONS ELECTRONIQUES : STANDARDS, ALGORITHMES DE HACHAGE ET PKI» DU 22 AU 26 JUIN 2015 TUNIS (TUNISIE) CRYPTOGRAPHIE APPLIQUEE ET SECURITE DES

Plus en détail

Cahier des charges des dispositifs de télétransmission des actes soumis au contrôle de légalité. Annexe 2 : sécurisation des échanges

Cahier des charges des dispositifs de télétransmission des actes soumis au contrôle de légalité. Annexe 2 : sécurisation des échanges Cahier des charges des dispositifs de télétransmission des actes Annexe 2 : sécurisation des échanges Page 2 / 7 1. OBJET DU DOCUMENT...3 2. PRINCIPES...3 3. SÉCURISATION DES DÉPÔTS DE FICHIERS SUR LES

Plus en détail

L iphone en entreprise Présentation de la sécurité

L iphone en entreprise Présentation de la sécurité L iphone en entreprise Présentation de la sécurité Avec iphone vous pourrez accéder de façon totalement sécurisée aux services de l entreprise tout en protégeant les données de l appareil. Vous profiterez

Plus en détail

Politique d Horodatage achatpublic.com. achatpublic.com

Politique d Horodatage achatpublic.com. achatpublic.com Politique d Horodatage achatpublic.com Version 1.0 1 Préambule 2 1.1 Glossaire et bibliographie 2 1.2 Objet du présent document 2 1.3 Les services d achatpublic.com achatpublic.com 2 1.4 Les marchés publics

Plus en détail

Les certificats numériques

Les certificats numériques Les certificats numériques Quoi, pourquoi, comment Freddy Gridelet 9 mai 2005 Sécurité du système d information SGSI/SISY La sécurité : quels services? L'authentification des acteurs L'intégrité des données

Plus en détail

Chapitre II. Introduction à la cryptographie

Chapitre II. Introduction à la cryptographie Chapitre II Introduction à la cryptographie PLAN 1. Terminologie 2. Chiffrement symétrique 3. Chiffrement asymétrique 4. Fonction de hachage 5. Signature numérique 6. Scellement 7. Echange de clés 8. Principe

Plus en détail

Politique de Signature Électronique de DICTServices

Politique de Signature Électronique de DICTServices Politique de Signature Électronique de DICTServices Politique de signature électronique de DICTServices version 1.0.0 1/8 Suivi du document Version Date Origine de la mise à jour Rédigé par 1.0.0 01/12/12

Plus en détail

Livre blanc. Sécuriser les échanges

Livre blanc. Sécuriser les échanges Livre blanc d information Sécuriser les échanges par emails Octobre 2013 www.bssi.fr @BSSI_Conseil «Sécuriser les échanges d information par emails» Par David Isal Consultant en Sécurité des Systèmes d

Plus en détail

CIBLE DE SECURITE CSPN COFFRE-FORT DES JEUX EN LIGNE

CIBLE DE SECURITE CSPN COFFRE-FORT DES JEUX EN LIGNE CIBLE DE SECURITE CSPN COFFRE-FORT DES JEUX EN LIGNE Sommaire 1. Identification du produit... 2 2. Argumentaire (description) du produit... 3 a. Description générale du produit... 3 b. Description de la

Plus en détail

Architecture de join.me

Architecture de join.me Présentation technique de l architecture sécurisée et fiable de join.me 1 Introduction 2 Présentation de l architecture 3 Sécurité des données 4 Sécurité des sessions et du site web 5 Présentation de l

Plus en détail

Crypto et sécurité de l information

Crypto et sécurité de l information 1 / 73 Crypto et sécurité de l information Chap 4: Gestion des clés symétriques ou asymétriques, Protocoles d authentification, Kerberos, Protocoles de sécurité Rhouma Rhouma https://sites.google.com/site/rhoouma

Plus en détail

Profil de protection d une passerelle VPN industrielle

Profil de protection d une passerelle VPN industrielle Profil de protection d une passerelle industrielle Version 1.0 court-terme GTCSI 13 juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant

Plus en détail

Chiffrement et authentification

Chiffrement et authentification Chiffrement et authentification Certificats et architecture PKI Tuyêt Trâm DANG NGOC Université de Cergy-Pontoise 2012 2013 Tuyêt Trâm DANG NGOC Chiffrement et authentification 1 / 38

Plus en détail

Faut-il brûler vos certificats? JRES 2003 Serge Aumont

Faut-il brûler vos certificats? JRES 2003 Serge Aumont Faut-il brûler vos certificats? JRES 2003 Serge Aumont 1 Motivation https : illusion de sécurité? Protection des clés privées Mobilité Les AC de confiance La révocation Exploiter une IGC L interopérabilité

Plus en détail

La sécurité par TLS, un voeu pieu?

La sécurité par TLS, un voeu pieu? La sécurité par TLS, un voeu pieu? christophe.renard@hsc.fr Hervé Schauer Consultants 20 mars 2014 JSSI 2014-17 mars Agenda Introduction Les menaces Couches de TLS Que faire Références 2/33 Pourquoi Cette

Plus en détail

Profil de protection d un logiciel d ingénierie

Profil de protection d un logiciel d ingénierie Version 1.0 moyen-terme GTCSI 11 septembre 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne le composant qui est l objet de l évaluation. 1 Descriptif

Plus en détail

Sécurité 2. Université Kasdi Merbah Ouargla. PKI- Public Key Infrastructure (IGC Infrastructure de Gestion de Clés) M2-RCS.

Sécurité 2. Université Kasdi Merbah Ouargla. PKI- Public Key Infrastructure (IGC Infrastructure de Gestion de Clés) M2-RCS. Sécurité 2 Université Kasdi Merbah Ouargla Département Informatique PKI- Public Key Infrastructure (IGC Infrastructure de Gestion de Clés) M2-RCS Janvier 2014 Master RCS Sécurité informatique 1 Sommaire

Plus en détail

Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE

Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE Sécuriser les communications sur Internet de bout-en-bout avec le protocole DANE Aujourd hui, près de,5 milliards de personnes utilisent Internet pour communiquer et fournir/obtenir des informations. Lorsque

Plus en détail

Fiches micro-informatique SECURITE LOGIQUE LOGIxx

Fiches micro-informatique SECURITE LOGIQUE LOGIxx Objectif Fiches micro-informatique SECURITE LOGIQUE LOGIxx Présenter des préconisations pour sécuriser le poste de travail informatique et son environnement sous forme de fiches pratiques. Public concerné

Plus en détail

Chiffrement à clef publique, authentification et distribution des clefs. Plan

Chiffrement à clef publique, authentification et distribution des clefs. Plan Chiffrement à clef publique, authentification et distribution des clefs Sécurité des réseaux informatiques 1 Plan Les principes de l'authentification de message Les fonctions de hachage sécurisées SHA-1

Plus en détail

RECOMMANDATIONS DE SECURITE

RECOMMANDATIONS DE SECURITE PREMIER MINISTRE Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information Paris, le 14 février 2013 N 524/ANSSI/SDE RECOMMANDATIONS DE SECURITE

Plus en détail

Introduction à la sécurité Cours 8 Infrastructure de clés publiques. Catalin Dima

Introduction à la sécurité Cours 8 Infrastructure de clés publiques. Catalin Dima Introduction à la sécurité Cours 8 Infrastructure de clés publiques Catalin Dima 1 Gestion des clés La gestion des clés concerne : La distribution de clés cryptographiques, Les mécanismes utilisés pour

Plus en détail

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO)

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO) CIBLE DE SECURITE CSPN DU PRODUIT PASS (Product for Advanced SSO) Préparé pour : ANSSI Préparé par: Thales Communications & Security S.A. 4 Avenue des Louvresses 92622 GENNEVILLIERS CEDEX France This document

Plus en détail

Gestion des Clés. Pr Belkhir Abdelkader. 10/04/2013 Pr BELKHIR Abdelkader

Gestion des Clés. Pr Belkhir Abdelkader. 10/04/2013 Pr BELKHIR Abdelkader Gestion des Clés Pr Belkhir Abdelkader Gestion des clés cryptographiques 1. La génération des clés: attention aux clés faibles,... et veiller à utiliser des générateurs fiables 2. Le transfert de la clé:

Plus en détail

Signer électroniquement un document

Signer électroniquement un document Signer électroniquement un document Signer électroniquement un document.doc 1 / 20 Table des matières Introduction 3 Signer un document Microsoft Office 4 Signer un document Office 2003. 4 Signer un document

Plus en détail

Déploiement de l iphone et de l ipad Gestion des appareils mobiles (MDM)

Déploiement de l iphone et de l ipad Gestion des appareils mobiles (MDM) Déploiement de l iphone et de l ipad Gestion des appareils mobiles (MDM) ios prend en charge la gestion des appareils mobiles (MDM), offrant aux entreprises la possibilité de gérer des déploiements évolutifs

Plus en détail

Groupe Eyrolles, 2006, ISBN : 2-212-11933-X

Groupe Eyrolles, 2006, ISBN : 2-212-11933-X Groupe Eyrolles, 2006, ISBN : 2-212-11933-X Table des matières Introduction... V CHAPITRE 1 Introduction à SSL VPN... 1 Une histoire d Internet.............................................. 3 Le modèle

Plus en détail

Propagation virale sur le Web Le ver BackTrack

Propagation virale sur le Web Le ver BackTrack Propagation virale sur le Web Le ver BackTrack Althes (http://www.althes.fr) Revision 1 - December 2002 Vincent Royer 1. Introduction Au cours de ces dernières années, un certain nombre

Plus en détail

ELOECM Conference2015

ELOECM Conference2015 ELOECM Conference2015 Signature Electronique et SAE Comment s assurer que les documents signés électroniquement conservent leur valeur probatoire? Patrick ANGE Consultant GED et Archivage http://www.opusconseils.com/

Plus en détail

La sécurité des Réseaux Partie 7 PKI

La sécurité des Réseaux Partie 7 PKI La sécurité des Réseaux Partie 7 PKI Fabrice Theoleyre Enseignement : INSA Lyon / CPE Recherche : Laboratoire CITI / INSA Lyon Références C. Cachat et D. Carella «PKI Open Source», éditions O REILLY Idealx,

Plus en détail

PKI, PGP et OpenSSL. Pierre-Louis Cayrel

PKI, PGP et OpenSSL. Pierre-Louis Cayrel Université de Limoges, XLIM-DMI, 123, Av. Albert Thomas 87060 Limoges Cedex France 05.55.45.73.10 pierre-louis.cayrel@xlim.fr Licence professionnelle Administrateur de Réseaux et de Bases de Données IUT

Plus en détail

Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des tablettes ou smartphones.

Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des tablettes ou smartphones. PERSPECTIVES Le Single Sign-On mobile vers Microsoft Exchange avec OWA et ActiveSync Ce document décrit une solution de single sign-on (SSO) sécurisée permettant d accéder à Microsoft Exchange avec des

Plus en détail

Attaques visant des prestataires de services de certification et conséquences

Attaques visant des prestataires de services de certification et conséquences Unité de pilotage informatique de la Confédération UPIC Service de renseignement de la Confédération SRC Centrale d enregistrement et d analyse pour la sûreté de l information MELANI www.melani.admin.ch

Plus en détail

Profil de protection d un progiciel serveur applicatif MES

Profil de protection d un progiciel serveur applicatif MES Profil de protection d un progiciel serveur applicatif MES Version 1.0 court-terme GTCSI 1 er juillet 2015 Avant-propos Dans toute la suite de ce document, l acronyme ToE (Target of Evaluation) désigne

Plus en détail

Présentation du projet EvalSSL

Présentation du projet EvalSSL 24 SSLTeam FévrierPrésentation 2011 du projet EvalSSL 1 / 36 Présentation du projet EvalSSL SSLTeam : Radoniaina ANDRIATSIMANDEFITRA, Charlie BOULO, Hakim BOURMEL, Mouloud BRAHIMI, Jean DELIME, Mour KEITA

Plus en détail

HASH LOGIC. Web Key Server. Solution de déploiement des certificats à grande échelle. A quoi sert le Web Key Server? A propos de HASHLOGIC

HASH LOGIC. Web Key Server. Solution de déploiement des certificats à grande échelle. A quoi sert le Web Key Server? A propos de HASHLOGIC HASH LOGIC s e c u r i t y s o l u t i o n s Version 1.0 de Janvier 2007 Web Key Server Solution de déploiement des certificats à grande échelle A propos de HASHLOGIC HASHLOGIC est Editeur spécialisé dans

Plus en détail

Chiffrement : Échanger et transporter ses données en toute sécurité

Chiffrement : Échanger et transporter ses données en toute sécurité Chiffrement : Échanger et transporter ses données en toute sécurité Septembre 2014 Chiffrement : Confidentialité des données Malgré les déclarations de Google et autres acteurs du Net sur les questions

Plus en détail

Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PUBLIÉ

Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PUBLIÉ PC Gestion des certificats émis par l AC Notaires Format RFC 3647 Politique de Certification Pour les Certificats de classe 0 et 4 émis par l autorité de certification Notaires PC Notaires Référence du

Plus en détail

Aristote Groupe PIN. Utilisations pratiques de la cryptographie. Frédéric Pailler (CNES) 13 janvier 2009

Aristote Groupe PIN. Utilisations pratiques de la cryptographie. Frédéric Pailler (CNES) 13 janvier 2009 Aristote Groupe PIN Utilisations pratiques de la cryptographie Frédéric Pailler (CNES) 13 janvier 2009 Objectifs Décrire les techniques de cryptographie les plus courantes Et les applications qui les utilisent

Plus en détail

Internal Hacking et contre-mesures en environnement Windows Piratage interne, mesures de protection, développement d'outils

Internal Hacking et contre-mesures en environnement Windows Piratage interne, mesures de protection, développement d'outils Introduction 1. Préambule 15 2. Décryptage d une attaque réussie 17 3. Décryptage de contre-mesures efficaces 18 3.1 Analyse de risques réels 18 3.2 Considérations techniques 19 3.3 Considérations de la

Plus en détail

THEME: Protocole OpenSSL et La Faille Heartbleed

THEME: Protocole OpenSSL et La Faille Heartbleed THEME: Protocole OpenSSL et La Faille Heartbleed Auteurs : Papa Kalidou Diop Valdiodio Ndiaye Sene Professeur: Année: 2013-2014 Mr, Gildas Guebre Plan Introduction I. Définition II. Fonctionnement III.

Plus en détail

Chapitre 7. Sécurité des réseaux. Services, attaques et mécanismes cryptographiques. Hdhili M.H. Cours Administration et sécurité des réseaux

Chapitre 7. Sécurité des réseaux. Services, attaques et mécanismes cryptographiques. Hdhili M.H. Cours Administration et sécurité des réseaux Chapitre 7 Sécurité des réseaux Services, attaques et mécanismes cryptographiques Hdhili M.H Cours Administration et sécurité des réseaux 1 Partie 1: Introduction à la sécurité des réseaux Hdhili M.H Cours

Plus en détail

Installation d'un serveur Forefront Threat Management Gateway 2010 (TMG 2010)

Installation d'un serveur Forefront Threat Management Gateway 2010 (TMG 2010) Installation d'un serveur Forefront Threat Management Gateway 2010 (TMG 2010) Par LoiselJP Le 01/05/2013 1 Objectifs Ce document décrit le plus succinctement possible une manière, parmi d'autres, d installer

Plus en détail

Présentation des caractéristiques des logiciels de chiffrement : principes et fonctionnalités

Présentation des caractéristiques des logiciels de chiffrement : principes et fonctionnalités Présentation des caractéristiques des logiciels de chiffrement : principes et fonctionnalités Journée chiffrement Le 24 janvier 2006 X. Jeannin (CNRS/UREC) Plan! Différents aspects du chiffrement de données!

Plus en détail

Bénéfices de Citrix NetScaler pour les architectures Citrix

Bénéfices de Citrix NetScaler pour les architectures Citrix Bénéfices de Citrix NetScaler pour les architectures Citrix 15 novembre 2007 Auteurs: Mahmoud EL GHOMARI E-mail: mahmoud.elghomari@eu.citrix.com Stéphane CAUNES E-mail: stephane.caunes@eu.citrix.com Riad

Plus en détail

Sécurité : les principaux risques et les moyens de protection associés

Sécurité : les principaux risques et les moyens de protection associés Sécurité : les principaux risques et les moyens de protection associés Les dangers sont très nombreux et divers. De plus, ils évoluent rapidement dans le temps. Néanmoins, les principaux risques pour les

Plus en détail

VSC-TOOAL. Cible de Sécurité CSPN. 1 Identification du produit. Organisation éditrice. Nom commercial du produit. Numéro de la version évaluée 1.

VSC-TOOAL. Cible de Sécurité CSPN. 1 Identification du produit. Organisation éditrice. Nom commercial du produit. Numéro de la version évaluée 1. VSC-TOOAL 1.1 Cible de Sécurité CSPN 1 Identification du produit Organisation éditrice Lien vers l organisation Nom commercial du produit MEDISCS www.mediscs.com VSC-TOOAL Numéro de la version évaluée

Plus en détail

signature de code THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS CODE SIGNING DANS LE MONDE

signature de code THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS CODE SIGNING DANS LE MONDE signature de code THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS CODE SIGNING DANS LE MONDE signature de code...1 Qu est-ce que la signature de code?...1 À quoi sert la signature de code?...1

Plus en détail

Comment activer un accès pratique et sécurisé à Microsoft SharePoint?

Comment activer un accès pratique et sécurisé à Microsoft SharePoint? DOSSIER SOLUTIONS SharePoint Security Solution de CA Technologies Comment activer un accès pratique et sécurisé à Microsoft SharePoint? agility made possible La solution de sécurité SharePoint proposée

Plus en détail

www.netexplorer.fr contact@netexplorer.fr

www.netexplorer.fr contact@netexplorer.fr www.netexplorer.fr 05 61 61 20 10 contact@netexplorer.fr Sommaire Sécurité applicative... 3 Authentification... 3 Chiffrement... 4 Traçabilité... 4 Audits... 5 Sécurité infrastructure... 6 Datacenters...

Plus en détail

Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin

Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin Horodatage Sécurisé J.M. Fourneau Laboratoire PRiSM, CNRS UMR 8144 Université de Versailles St-Quentin M2 ASS-ACSIS 2008, Université de Versailles St Quentin [1/25] Horodatage Sécurisé Le service d horodatage

Plus en détail

Référentiel Général de Sécurité. version 1.0. Annexe A4

Référentiel Général de Sécurité. version 1.0. Annexe A4 Premier ministre Agence nationale de la sécurité des systèmes d information Ministère du budget, des comptes publics et de la réforme de l État Direction générale de la modernisation de l État Référentiel

Plus en détail

Devoir Surveillé de Sécurité des Réseaux

Devoir Surveillé de Sécurité des Réseaux Année scolaire 2009-2010 IG2I L5GRM Devoir Surveillé de Sécurité des Réseaux Enseignant : Armand Toguyéni Durée : 2h Documents : Polycopiés de cours autorisés Note : Ce sujet comporte deux parties. La

Plus en détail

Gestion des comptes à privilèges

Gestion des comptes à privilèges 12 décembre 2013 Gestion des comptes à privilèges Bertrand CARLIER, Manager Sécurité de l Information bertrand.carlier@solucom.fr Solucom, conseil en management et système d information Cabinet de conseil

Plus en détail

Master Informatique 1ère Année 2007. Participants: Tarek Ajroud Jérémy Ameline Charles Balle Fabrice Douchant VPN SSL

Master Informatique 1ère Année 2007. Participants: Tarek Ajroud Jérémy Ameline Charles Balle Fabrice Douchant VPN SSL VPN SSL : Présentation Master Informatique 1ère Année Année 2006-2007 2007 Participants: Tarek Ajroud Jérémy Ameline Charles Balle Fabrice Douchant VPN SSL Durée : 20 minutes Remarques Intervention : 15-20

Plus en détail

Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe

Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe Peter Sylvester / Paul-André Pays EdelWeb http://www.edelweb.fr/ ps@edelweb.fr / pays@edelweb.fr

Plus en détail

Généralité sur la cryptographie

Généralité sur la cryptographie 1.1 Introduction L origine de la cryptologie mot réside dans la Grèce antique. La cryptologie est un mot composé de deux éléments : «cryptos», qui signifie caché et «logos» qui signifie mot. La cryptologie

Plus en détail

Sécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte thawte thawte thawte thawte

Sécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte thawte thawte thawte thawte Sécurisez votre serveur Web Internet Information Services de Microsoft (MS IIS) avec un certificat numérique de thawte UN GUIDE ÉTAPE PAR ÉTAPE, pour tester, acheter et utiliser un certificat numérique

Plus en détail

Cahier des charges pour le référencement des produits de sécurité et des offres de prestataires de services de confiance

Cahier des charges pour le référencement des produits de sécurité et des offres de prestataires de services de confiance Cahier des charges pour le référencement des produits de sécurité et des offres de prestataires de services de confiance Version 1 Direction générale de la modernisation de l État Page 1/12 Historique

Plus en détail

Sécurisation du DNS : les extensions DNSsec

Sécurisation du DNS : les extensions DNSsec Sécurisation du DNS : les extensions DNSsec Bertrand Leonard, AFNIC/projet IDsA Sécurisation du DNS: les extensions DNSsec JRES, 19/11/03 1 Historique Jusqu en 1984 : réseau restreint militaire/universitaire/recherche

Plus en détail

Politique de Certification Pour les Certificats techniques de classe 0 émis par l autorité de certification REALTECH PUBLIÉ

Politique de Certification Pour les Certificats techniques de classe 0 émis par l autorité de certification REALTECH PUBLIÉ PC Gestion des certificats émis par l AC REALTECH Format RFC 3647 Politique de Certification Pour les Certificats techniques de classe 0 émis par l autorité de certification REALTECH PC REALTECH Référence

Plus en détail

PUBLIC KEY INFRASTRUCTURE. Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé

PUBLIC KEY INFRASTRUCTURE. Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé PUBLIC KEY INFRASTRUCTURE Rappels PKI PKI des Impôts PKI de la Carte de Professionnel de Santé Rappels PKI Fonctionnement général Pourquoi? Authentification Intégrité Confidentialité Preuve (non-répudiation)

Plus en détail

Accès au SI de RTE par carte à puce sous Microsoft Windows Vista

Accès au SI de RTE par carte à puce sous Microsoft Windows Vista Accès au SI de RTE par carte à puce sous Microsoft Windows Vista Indice 2, 22/12/2010 Ce document est la propriété de RTE. Toute communication, reproduction, publication, même partielle, est interdite,

Plus en détail

Sécurité informatique

Sécurité informatique Sécurité informatique Université Kasdi Merbah Ouargla Master RCS Octobre 2014 Département Informatique 1 Master RCS 1 Sécurité informatique Organisation du cours Ce cours a pour but de présenter les fondements

Plus en détail

3. Gestion de la signature électronique dans le Hub Electronique de Documents. 4. Signature manuscrite scannée et signature numérique dans le Hub

3. Gestion de la signature électronique dans le Hub Electronique de Documents. 4. Signature manuscrite scannée et signature numérique dans le Hub Certificat et Signature électronique by LegalBox Certificat et Signature électronique Table des matières : 1. Qu'est-ce qu'une signature électronique? 2. Qu est-ce qu un certificat électronique? 3. Gestion

Plus en détail