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

1. Notions de Sécurité A l'usage du développeur Noël Bardelot, ingénieur Soat

2. https://plus.google.com/+NoëlBardelot

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. 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. Sécurité « Situation dans laquelle quelqu'un, quelque chose n'est exposé à aucun danger. »

6. Danger « Ce qui constitue une menace, un risque pour quelqu'un, quelque chose. »

7. CRYPTOGRAPHIE ET CRYPTANALYSE Cryptex façon « Da Vinci Code »

8. La stéganographie L'art de cacher

9. Le chiffre de César

10. Exemple : le chiffre de César avec un décalage de 13 caractères

11. Analyse fréquentielle

12. Le chiffre de Vigenère

13. Exemple à l'aide d'un MOTDEPASSE HELLO → TSE...

14. La machine Enigma

15. LES OPERATIONS CRYPTOGRAPHIQUES

16. HASHER

17. SHA-2

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. 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. SCELLER

21. { "piou-piou": { "utilisateur": "@RenéDescartes", "date": "15 oct. 1644", "contenu": "Je #piou donc je suis !" }, "fonction_de_hashage": "SHA1", "sceau": "79a14c50bba0a3ac6623b4292c60915929c271d7" }

22. CCHHIIFFFFRREERR

23. Chiffrement symétrique

24. Chiffrement asymétrique

25. THE SERVER

26. American Encryption Standard Symétrique Joan Daemen Vincent Rijmen

27. Rivest Shamir Adleman Asymétrique

28. vs. Asymétrique Plus lent Nombres premiers Secret non partagé Symétrique Plus rapide Clé aléatoire Partager la clé

29. Comment partager une clé symétrique ?

30. AUTHENTIFIER

31. Autorité de certification Fournisseur officiel de clés

32. X.509

33. SIGNATURE NUMÉRIQUE → SCELLEMENT & AUTHENTIFICATION

34. DES OUTILS ET DES BONNES PRATIQUES L'actu en Patates (Martin Vidberg)

35. Transport Layer Security

36. Le modèle OSI

37. THE SERVER

38. FTP + STARTTLS

39. SMTP & IMAP & POP3 + STARTTLS

40. STOCKAGE SÉCURISÉ

41. Le sel doit être aléatoire

42. OAUTH 2.0

43. LA SÉCURITÉ : CONCEPT GLOBAL

44. Un maillon casse... … tout casse

45. Les cookies

46. Local storage

47. L'ajout manuel de certificats

48. Le navigateur

49. Le système

50. Les bibliothèques

51. Le réseau

52. Le hardware

53. Même les algorithmes ! Randall Munroe (XKCD)

54. Les Méta-données

55. ingénierie sociale

56. les bons outils, Des standards éprouvés, des développeurs responsables, et ça dès le début d'un projet.

57. Bibliographie Histoire des codes secrets, par Simon Singh https://www.schneier.com le blog de Bruce Schneier Cryptonomicon, par Neal Stephenson roman

58. Avez-vous des questions ?

59. Notions de Sécurité A l'usage du développeur Noël Bardelot, ingénieur Soat

60. https://plus.google.com/+NoëlBardelot

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. 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. 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. 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. CRYPTOGRAPHIE ET CRYPTANALYSE Cryptex façon « Da Vinci Code »

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. 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. 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. 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. 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. 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. 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. 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. LES OPERATIONS CRYPTOGRAPHIQUES

75. HASHER Fonctions mathématiques. A priori destructives (non reversibles).

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. 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. 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. 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. { "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. 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. 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. 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. 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. 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. 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. Rivest Shamir Adleman Asymétrique ● RSA ● Ron Rivest + Adi Shamir + Leonard Adleman ● 1977 ● Implémentation la plus courante

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. 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. 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. 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. 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. X.509 X.509, la spécification ● Émettre un certificat ● Valider un certificat ● Révoquer un certificat

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. DES OUTILS ET DES BONNES PRATIQUES L'actu en Patates (Martin Vidberg)

96. Transport Layer Security Protocoles TLS de l'IETF Successeur de SSL de Netscape (terme obsolète)

97. Le modèle OSI TLS sécurise la couche applicative du point de vue du modèle OSI

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. ● 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. 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. FTP + STARTTLS

102. SMTP & IMAP & POP3 + STARTTLS

103. STOCKAGE SÉCURISÉ Les données sensibles ne doivent pas être corrompues ou dérobées

104. Un exemple : les mots de passe utilisateurs ● sceller, pas chiffrer ! ● saler les hashs ● utiliser un sel aléatoire

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. 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. 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. 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. 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. 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. LA SÉCURITÉ : CONCEPT GLOBAL

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. 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. Local storage Idem que pour les cookies.

115. L'ajout manuel de certificats L'utilisateur peut ajouter manuellement des certificats verreux par méconnaissance ou erreur.

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. Le système Trojans, keyloggers, etc.

118. Les bibliothèques Les bibliothèques tierces contiennent forcément des bugs (et notamment les bibliothèques cryptographiques).

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. Le hardware L'ajout de composants électroniques pour écouter/enregistrer des communications à très bas niveau n'est pas de la science fiction.

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. 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. 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. les bons outils, Des standards éprouvés, des développeurs responsables, et ça dès le début d'un projet.

125. Bibliographie Histoire des codes secrets, par Simon Singh https://www.schneier.com le blog de Bruce Schneier Cryptonomicon, par Neal Stephenson roman

126. Avez-vous des questions ?