Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)

739 views

Published on

L’objectif de la soirée est de donner, ou re-donner, un socle de connaissances en matière de sécurité. Nous commencerons par des éléments de culture générale, en parlant de cryptographie et de cryptanalyse pour inscrire la soirée dans un contexte historique plus large.

Puis nous aborderons une à une chacune des fonctions cryptographiques élémentaires, qu’il est indispensable de comprendre pour s’approprier les outils et les techniques de sécurité que l’on utilise tous les jours. Nous verrons ensuite quelques exemples d’outils et méthodes correspondants aux situations les plus courantes dans un projet informatique. Et dans une dernière partie nous parlerons des sources de risque, des éléments à prendre
en compte lorsque l’on réfléchit à des problématiques de sécurité.

Durée :
1h30 avec questions

Published in: Software
  • Be the first to comment

Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)

  1. 1. Notions de Sécurité A l'usage du développeur Noël Bardelot, ingénieur Soat
  2. 2. https://plus.google.com/+NoëlBardelot
  3. 3. Plan de la présentation 1. Qu'est-ce que la sécurité ? 2. Cryptographie et cryptanalyse 3. Les opérations cryptographiques 4. Des outils et des bonnes pratiques 5. La sécurité : concept global
  4. 4. QU'EST-CE QUE LA SÉCURITÉ ? « J'ai l'impression qu'on m'écoute. » Paul Bismuth ancien Président de la République
  5. 5. Sécurité « Situation dans laquelle quelqu'un, quelque chose n'est exposé à aucun danger. »
  6. 6. Danger « Ce qui constitue une menace, un risque pour quelqu'un, quelque chose. »
  7. 7. CRYPTOGRAPHIE ET CRYPTANALYSE Cryptex façon « Da Vinci Code »
  8. 8. La stéganographie L'art de cacher
  9. 9. Le chiffre de César
  10. 10. Exemple : le chiffre de César avec un décalage de 13 caractères
  11. 11. Analyse fréquentielle
  12. 12. Le chiffre de Vigenère
  13. 13. Exemple à l'aide d'un MOTDEPASSE HELLO → TSE...
  14. 14. La machine Enigma
  15. 15. LES OPERATIONS CRYPTOGRAPHIQUES
  16. 16. HASHER
  17. 17. SHA-2
  18. 18. Exemple : la somme de contrôle d'un fichier > cat mon_fichier.txt Fichier contenant des données importantes. > md5sum mon_fichier.txt f530b08d011669bf271fbd60b91b95b7 > sha1sum mon_fichier.txt a136aef251b4c7458d6870c7476079c6ff06fce5 > sha256sum mon_fichier.txt 0dc6fd63d59eb2f26000f1486516de4297b42c89eeccddb47203111a1a2b0a91
  19. 19. Autre exemple : les commits dans Git > git log --reverse commit f90acc01df5c399f9badebe1b306dd6b0e86df90 Author: Noel Bardelot <noel.bardelot@socgen.com> Date: Fri Oct 31 15:20:36 2014 +0100 Feat.: ajout d'une IA commit c91d5ff37726891d1ae5498d6a59d49bb0bf06dc Author: Noel Bardelot <noel.bardelot@socgen.com> Date: Fri Oct 31 23:54:24 2014 +0100 Fix: à l'aide, le serveur a pris le contrôle !
  20. 20. SCELLER
  21. 21. { "piou-piou": { "utilisateur": "@RenéDescartes", "date": "15 oct. 1644", "contenu": "Je #piou donc je suis !" }, "fonction_de_hashage": "SHA1", "sceau": "79a14c50bba0a3ac6623b4292c60915929c271d7" }
  22. 22. CCHHIIFFFFRREERR
  23. 23. Chiffrement symétrique
  24. 24. Chiffrement asymétrique
  25. 25. THE SERVER
  26. 26. American Encryption Standard Symétrique Joan Daemen Vincent Rijmen
  27. 27. Rivest Shamir Adleman Asymétrique
  28. 28. vs. Asymétrique Plus lent Nombres premiers Secret non partagé Symétrique Plus rapide Clé aléatoire Partager la clé
  29. 29. Comment partager une clé symétrique ?
  30. 30. AUTHENTIFIER
  31. 31. Autorité de certification Fournisseur officiel de clés
  32. 32. X.509
  33. 33. SIGNATURE NUMÉRIQUE → SCELLEMENT & AUTHENTIFICATION
  34. 34. DES OUTILS ET DES BONNES PRATIQUES L'actu en Patates (Martin Vidberg)
  35. 35. Transport Layer Security
  36. 36. Le modèle OSI
  37. 37. THE SERVER
  38. 38. FTP + STARTTLS
  39. 39. SMTP & IMAP & POP3 + STARTTLS
  40. 40. STOCKAGE SÉCURISÉ
  41. 41. Le sel doit être aléatoire
  42. 42. OAUTH 2.0
  43. 43. LA SÉCURITÉ : CONCEPT GLOBAL
  44. 44. Un maillon casse... … tout casse
  45. 45. Les cookies
  46. 46. Local storage
  47. 47. L'ajout manuel de certificats
  48. 48. Le navigateur
  49. 49. Le système
  50. 50. Les bibliothèques
  51. 51. Le réseau
  52. 52. Le hardware
  53. 53. Même les algorithmes ! Randall Munroe (XKCD)
  54. 54. Les Méta-données
  55. 55. ingénierie sociale
  56. 56. les bons outils, Des standards éprouvés, des développeurs responsables, et ça dès le début d'un projet.
  57. 57. Bibliographie Histoire des codes secrets, par Simon Singh https://www.schneier.com le blog de Bruce Schneier Cryptonomicon, par Neal Stephenson roman
  58. 58. Avez-vous des questions ?
  59. 59. Notions de Sécurité A l'usage du développeur Noël Bardelot, ingénieur Soat
  60. 60. https://plus.google.com/+NoëlBardelot
  61. 61. Plan de la présentation 1. Qu'est-ce que la sécurité ? 2. Cryptographie et cryptanalyse 3. Les opérations cryptographiques 4. Des outils et des bonnes pratiques 5. La sécurité : concept global
  62. 62. QU'EST-CE QUE LA SÉCURITÉ ? « J'ai l'impression qu'on m'écoute. » Paul Bismuth ancien Président de la République
  63. 63. Sécurité « Situation dans laquelle quelqu'un, quelque chose n'est exposé à aucun danger. » C'est un concept tellement abstrait, tellement fondamental, qu'on a du mal à le définir. On ne définit pas la sécurité, on ne définit que l'absence de sécurité.
  64. 64. Danger « Ce qui constitue une menace, un risque pour quelqu'un, quelque chose. » Même le danger est un concept qui ne se définit que par lui-même tellement il est basique.
  65. 65. CRYPTOGRAPHIE ET CRYPTANALYSE Cryptex façon « Da Vinci Code »
  66. 66. La stéganographie L'art de cacher Il s'agit de cacher la donnée pour la protéger. La stéganographie n'est pas de la cryptographie.
  67. 67. Le chiffre de César Comme son nom l'indique, date de l'antiquité. Il s'agit de la forme la plus simple de cryptographie par substitution. Elle a continué à être utilisée jusque très tard pour sa facilité de mise en oeuvre (disques offert en cadeau aux enfants aux USA dans les magazines).
  68. 68. Exemple : le chiffre de César avec un décalage de 13 caractères Le plus connu des chiffres de César ROT13 = « rotation » de 13 caractères
  69. 69. Analyse fréquentielle Méthode pour déchiffrer les substitutions simples. Développée par les arabes (Al-Kindi) au 9ème siècle.
  70. 70. Le chiffre de Vigenère Diplomate français du 16ème siècle. Chiffrement par substitution polyalphabétique. A chaque itération l'alphabet choisi est déterminé par la lettre d'un mot de code secret. Cassé au 19ème siècle mais encore utilisé pour des cas simples.
  71. 71. Exemple à l'aide d'un MOTDEPASSE HELLO → TSE... Utilise les 26 façons différentes de fabriquer un chiffre de César. Chaque lettre à chiffrer utilise un alphabet différent. Le choix à chaque étape de l'alphabet à utiliser est fonction d'un mot de passe. La cryptanalyse consiste à essayer de déduire la taille du mot de passe.
  72. 72. La machine Enigma Commercialisée avant la 2ème guerre mondiale. Entrée dans l'ère de l'automatisation des procédés cryptographiques. Les cryptographes de l'armée allemande la savaient cassable, mais ils ont jugé que c'était très improbable.
  73. 73. Pendant que les anglais cassaient Enigma, les américains utilisaient des indiens Navajo pour échanger des messages sur le front Pacifique. Les japonais n'ont jamais réussi à déchiffrer les messages.
  74. 74. LES OPERATIONS CRYPTOGRAPHIQUES
  75. 75. HASHER Fonctions mathématiques. A priori destructives (non reversibles).
  76. 76. SHA-2 Bibliothèque de fonctions cryptographiques de hashage. Conçue par la NSA. Plus utilisée : SHA-256 SHA = Secure Hash Algorithm
  77. 77. Exemple : la somme de contrôle d'un fichier > cat mon_fichier.txt Fichier contenant des données importantes. > md5sum mon_fichier.txt f530b08d011669bf271fbd60b91b95b7 > sha1sum mon_fichier.txt a136aef251b4c7458d6870c7476079c6ff06fce5 > sha256sum mon_fichier.txt 0dc6fd63d59eb2f26000f1486516de4297b42c89eeccddb47203111a1a2b0a91 Permet de vérifier qu'un fichier n'a pas été corrompu.
  78. 78. Autre exemple : les commits dans Git > git log --reverse commit f90acc01df5c399f9badebe1b306dd6b0e86df90 Author: Noel Bardelot <noel.bardelot@socgen.com> Date: Fri Oct 31 15:20:36 2014 +0100 Feat.: ajout d'une IA commit c91d5ff37726891d1ae5498d6a59d49bb0bf06dc Author: Noel Bardelot <noel.bardelot@socgen.com> Date: Fri Oct 31 23:54:24 2014 +0100 Fix: à l'aide, le serveur a pris le contrôle ! Git utilise la fonction mathématique SHA-1. Permet d'identifier uniquement un commit (car la fonction a très peu de collisions). Permet aussi de garantir l'intégrité d'un commit au moment du « pull ».
  79. 79. SCELLER Utilisation particulière du chiffrement qui vise à assurer l'intégrité de la donnée (d'un document par exemple). On se met d'accord avec son interlocuteur sur un chiffrement. L'émetteur chiffre le message et envoie le message et le résultat du chiffrement. Le déstinataire chiffre aussi le message et vérifie que le résultat est le même qu'à l'émission. Si ça n'est pas le cas c'est que le message est corrompu.
  80. 80. { "piou-piou": { "utilisateur": "@RenéDescartes", "date": "15 oct. 1644", "contenu": "Je #piou donc je suis !" }, "fonction_de_hashage": "SHA1", "sceau": "79a14c50bba0a3ac6623b4292c60915929c271d7" } Le scellement est un hashage appliqué à un message. A l'image des sceaux physiques que portent les documents officiels.
  81. 81. CCHHIIFFFFRREERR C A la base de toutes les opérations. On ne dit pas « crypter ». Fonction de base : rendre la donnée illisible sauf pour les personnes choisies.
  82. 82. Chiffrement symétrique Le même secret sert pour chiffrer et déchiffrer Le secret s'appelle « clé ». C'est un paramètre qu'on donne à une fonction mathématique choisie de manière à ce que même si on connaît le résultat et la fonction, il est très dur de retrouver le paramètre initial.
  83. 83. Chiffrement asymétrique Clé publique connue de tous, sert à chiffrer Clé privée connue d'un seul, sert à déchiffrer Pas les même fonctions mathématiques que pour le chiffrement symétrique.
  84. 84. THES ERVER On considère une relation 1-N (one-to-many) quand on parle de chiffrement asymétrique. Celui qui détient la clé privée est le serveur.
  85. 85. Il est possible pour un serveur de recevoir de manière sécurisée des messages depuis autant de clients qu'il le souhaite en partageant sa clé publique.
  86. 86. American Encryption Standard Symétrique Joan Daemen Vincent Rijmen AES (algorithme retenu : Rijndael) ● Vincent Rijmen & Joan Daemen ● remplace DES (1977) ● standardisé en 2001/2002 Rapide Peu gourmand en RAM
  87. 87. Rivest Shamir Adleman Asymétrique ● RSA ● Ron Rivest + Adi Shamir + Leonard Adleman ● 1977 ● Implémentation la plus courante
  88. 88. vs. Asymétrique Plus lent Nombres premiers Secret non partagé Symétrique Plus rapide Clé aléatoire Partager la clé ● Symétrique Avantage : ● Transmission sécurisée avec un coût de calcul faible (par rapport au chiffrement asymétrique) ● Clé secrète aléatoire Inconvénient : ● Partage initial de la clé secrète très sensible ! ● Asymétrique ● Avantage : ● Seule la clé publique est transmise ● Suffisant pour effectuer une signature (donc un scellement et/ou une authentification) ● Désavantage : ● Coût de calcul plus élevé ● Clé privée fondée sur des nombres premiers (pas aléatoire!)
  89. 89. Comment partager une clé symétrique ? Avant de pouvoir utiliser une clé symétrique pour échanger un message chiffré, il faut d'abord réussir à échanger la clé de manière sécurisée. Problème : comment échanger une clé à distance, sans qu'Alice et Bob se rencontre ?
  90. 90. AUTHENTIFIER Utilisation particulière du chiffrement qui vise à éviter l'usurpation d'identité. On identifie quelqu'un en lui demandant de déchiffrer un message pour lequel il n'y a que lui qui connaît le secret (« challenge »).
  91. 91. Autorité de certification Fournisseur officiel de clés Certificat à clé publique ● Garantir le propriétaire d'une clé publique Autorité de Certification (AC) ● Organisme qui signe le certificat avec sa clé privée ● N'importe qui peut se servir de leur clé publique pour vérifier un certificat
  92. 92. Il est crucial pour un serveur de pouvoir révoquer un certificat si la clé privée est jugée compromise. Réciproquement un client doit pouvoir savoir si un certificat qu'il a obtenu a depuis été révoqué.
  93. 93. X.509 X.509, la spécification ● Émettre un certificat ● Valider un certificat ● Révoquer un certificat
  94. 94. SIGNATURE NUMÉRIQUE → SCELLEMENT & AUTHENTIFICATION Ce qu'on appelle « signature numérique » c'est le fait qu'un document soit chiffré avec la clé privée du signataire, et que le résultat soit utilisé comme sceau. N'importe qui peut vérifier ce sceau avec la clé publique correspondante (via le certificat, garanti par une AC), et ainsi s'assurer de son intégrité tout en s'assurant de l'identité du signataire (seule la clé privée a pu chiffrer si la clé publique peut déchiffrer).
  95. 95. DES OUTILS ET DES BONNES PRATIQUES L'actu en Patates (Martin Vidberg)
  96. 96. Transport Layer Security Protocoles TLS de l'IETF Successeur de SSL de Netscape (terme obsolète)
  97. 97. Le modèle OSI TLS sécurise la couche applicative du point de vue du modèle OSI
  98. 98. THE SERVER Protocole de communication sécurisée ● Authentification du serveur ● Authentification réciproque du client ● Etablissement d'une session (échange d'une clé symétrique à usage unique) ● Dialogue sécurisé
  99. 99. ● Deux manières de mettre en place HTTP sur TLS ● avec une implémentation de TLS dans le serveur ● à l'aide d'un proxy spécialisé (par exemple Stunnel)
  100. 100. Un flux HTTP par dessus un protocole sécurisé Consiste à fournir au serveur un moyen de : ● s'authentifier auprès des clients ● chiffrer la communication avec chaque client
  101. 101. FTP + STARTTLS
  102. 102. SMTP & IMAP & POP3 + STARTTLS
  103. 103. STOCKAGE SÉCURISÉ Les données sensibles ne doivent pas être corrompues ou dérobées
  104. 104. Un exemple : les mots de passe utilisateurs ● sceller, pas chiffrer ! ● saler les hashs ● utiliser un sel aléatoire
  105. 105. Une approche naïve consiste à stocket un hash du mot de passe au lieu du mot de passe lui-même. Le défaut majeur de cette pratique est qu'il existe de nombreuses tables de hashs précaculés pour de très nombreux algorithmes de hashage.
  106. 106. Beaucoup d'utilisateurs ayant de mauvais mots de passe vont utiliser des mots de passe identiques, tirés du dictionnaire, ou utilisant une recette facile à deviner (l33t). Dans ce cas la collision de mots de passe devient une collision de hashs et simplifie la vie de l'attaquant.
  107. 107. On ajoute un préfixe au mot de passe. Ce préfixe s'appel un « sel » (anglais « salt »). On ne hash plus seulement le mot de passe mais la concaténation du sel et du mot de passe. On stocke le sel et le hash. Quand quelqu'un veut s'authentifier, on lui donne le sel, et on attend un hash en retour.
  108. 108. Attaquer le mot de passe d'un seul utilisateur reste tout aussi facile (l'attaquant connaît le sel). Par contre il est beaucoup plus coûteux d'attaquer toute une liste de mots de passe : chaque calcul de hash doit être fait autant de fois qu'il y a de mots de passe, puisque chacun a un sel différent. Et la majorité des rainbow tables deviennent inefficaces puisqu'il faudrait précalculer des mots avec un grand nombre de préfixes possibles. Enfin, si un utilisateur utilise le même mot de passe sur deux sites différents, les sels seront différents et les hashs aussi. Même si son compte est corrompu sur un premier site, il ne le sera pas sur le second.
  109. 109. Le sel doit être aléatoire Si le sel est constant on subit les collisions de hashs en cas de collision de mots de passe. Et si le sel est trop facile à déterminer (par exemple la date de création, qui est
  110. 110. OAUTH 2.0 Quand vous pouvez, évitez de le faire vous-même ● authentification par un tiers de confiance (exemple : OAuth via Google, Twitter, Facebook...) ● des API simples basées sur HTTP
  111. 111. LA SÉCURITÉ : CONCEPT GLOBAL
  112. 112. Un maillon casse... … tout casse Quatre maillons : ● le client ● le serveur ● les couches de transport de l'information ● les algorithmes et leurs implémentations Si un seul des maillons est compromis tout le mécanisme est compromis
  113. 113. Les cookies Stockés en clair chez le client. Il ne faut pas y mettre de données confidentielles. Ou alors il faut les chiffrer.
  114. 114. Local storage Idem que pour les cookies.
  115. 115. L'ajout manuel de certificats L'utilisateur peut ajouter manuellement des certificats verreux par méconnaissance ou erreur.
  116. 116. Le navigateur La première source de problème se situe dans la listes des AC pré-établie à l'installation : par défaut les navigateurs font confiance à beaucoup trop d'AC. Certaines de ces AC sont très douteuses. Le navigateur peut aussi être buggé, et surtout les plugins...
  117. 117. Le système Trojans, keyloggers, etc.
  118. 118. Les bibliothèques Les bibliothèques tierces contiennent forcément des bugs (et notamment les bibliothèques cryptographiques).
  119. 119. Le réseau Le flux passe par un certains nombre d'opérateurs réseau, chacun peut écouter. Le principe similaire aux écoutes téléphoniques.
  120. 120. Le hardware L'ajout de composants électroniques pour écouter/enregistrer des communications à très bas niveau n'est pas de la science fiction.
  121. 121. Même les algorithmes ! Randall Munroe (XKCD) ● Indéchiffrable aujourd'hui, déchiffrable demain ● Erreurs mathématiques ou dans les paramètres utilisés ● Pseudo-aléatoire ne veut pas dire vraiment aléatoire...
  122. 122. Les Méta-données Même sans avoir accès aux communications on peut déduire de nombreuses informations sur la nature de ces communications. ● Exemple : rendre aléatoires les séquences d'identifiants ● Autre exemple : rendre aléatoires les temps de réponse
  123. 123. ingénierie sociale L'humain est probablement le maillon le plus faible de tous. Nous sommes des êtres sociaux, nous sommes programmés pour faire confiance. Sans ça, pas de société.
  124. 124. les bons outils, Des standards éprouvés, des développeurs responsables, et ça dès le début d'un projet.
  125. 125. Bibliographie Histoire des codes secrets, par Simon Singh https://www.schneier.com le blog de Bruce Schneier Cryptonomicon, par Neal Stephenson roman
  126. 126. Avez-vous des questions ?

×