154

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

Embed Size (px)

DESCRIPTION

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

Citation preview

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

Notions deSécuritéA l'usage du développeur

Noël Bardelot, ingénieur Soat

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

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

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

QU'EST-CE QUE LA SÉCURITÉ ?

« J'ai l'impression qu'on m'écoute. »Paul Bismuth

ancien Président de la République

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

Sécurité

« Situation dans laquellequelqu'un,

quelque chosen'est exposé à

aucun danger. »

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

Danger

« Ce qui constitueune menace,

un risquepour quelqu'un,

quelque chose. »

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

CRYPTOGRAPHIEET

CRYPTANALYSE

Cryptex façon « Da Vinci Code »

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

La stéganographie

L'art de cacher

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

Le chiffrede

César

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

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

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

Analyse fréquentielle

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

Le chiffrede

Vigenère

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

Exemple à l'aide d'un MOTDEPASSE

HELLO

TSE...

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

La machineEnigma

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

LES OPERATIONSCRYPTOGRAPHIQUES

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

HASHER

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

SHA-2

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

Exemple : la somme de contrôle d'un fichier

> cat mon_fichier.txtFichiercontenantdesdonnéesimportantes.

> md5sum mon_fichier.txtf530b08d011669bf271fbd60b91b95b7

> sha1sum mon_fichier.txta136aef251b4c7458d6870c7476079c6ff06fce5

> sha256sum mon_fichier.txt0dc6fd63d59eb2f26000f1486516de4297b42c89eeccddb47203111a1a2b0a91

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

Autre exemple : les commits dans Git

> git log --reverse

commit f90acc01df5c399f9badebe1b306dd6b0e86df90Author: Noel Bardelot <[email protected]>Date: Fri Oct 31 15:20:36 2014 +0100

Feat.: ajout d'une IA

commit c91d5ff37726891d1ae5498d6a59d49bb0bf06dcAuthor: Noel Bardelot <[email protected]>Date: Fri Oct 31 23:54:24 2014 +0100

Fix: à l'aide, le serveur a pris le contrôle !

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

SCELLER

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

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

"fonction_de_hashage": "SHA1", "sceau": "79a14c50bba0a3ac6623b4292c60915929c271d7"}

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

CHIFFRERCHIFFRER

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

Chiffrementsymétrique

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

Chiffrementasymétrique

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

THE

SERVER

Page 29: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 30: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 31: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 32: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)

AmericanEncryptionStandard

Vincent RijmenJoan Daemen

Symét

rique

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

RivestShamirAdlemanAsy

mét

rique

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

vs.

Asymétrique

Plus lent

Nombres premiers

Secret non partagé

Symétrique

Plus rapide

Clé aléatoire

Partager la clé

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

Comment partager

une clé symétrique ?

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

AUTHENTIFIER

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

Autorité de certificationFournisseur officiel de clés

Page 40: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 41: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 42: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 43: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)

X.509

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

SIGNATURE NUMÉRIQUE→ SCELLEMENT & AUTHENTIFICATION

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

DES OUTILSET

DES BONNES PRATIQUES

L'actu en Patates (Martin Vidberg)

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

TransportLayerSecurity

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

Le modèle OSI

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

THE

SERVER

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

FTP+ STARTTLS

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

SMTP &IMAP &POP3 +STARTTLS

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

STOCKAGESÉCURISÉ

Page 54: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 55: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 56: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 57: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 58: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 59: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)
Page 60: Notions de sécurité à l'usage des développeurs (Soat, 6 nov. 2014)

Le sel doit être aléatoire

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

OAUTH 2.0

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

LA SÉCURITÉ :CONCEPT GLOBAL

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

Un maillon casse...

… tout casse

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

Les cookies

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

Local storage

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

L'ajout manuel de certificats

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

Le navigateur

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

Le système

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

Les bibliothèques

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

Le réseau

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

Le hardware

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

Même les algorithmes !

Randall Munroe (XKCD)

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

Les Méta-données

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

ingénierie sociale

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

les bons outils,

des développeurs responsables,

Des standards éprouvés,

et ça dès le début d'un projet.

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

Bibliographie

Histoire des codes secrets, par Simon Singh

https://www.schneier.comle blog de Bruce Schneier

Cryptonomicon, par Neal Stephensonroman

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

Avez-vousdesquestions ?

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

Notions deSécuritéA l'usage du développeur

Noël Bardelot, ingénieur Soat

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

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

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

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

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

QU'EST-CE QUE LA SÉCURITÉ ?

« J'ai l'impression qu'on m'écoute. »Paul Bismuth

ancien Président de la République

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

Sécurité

« Situation dans laquellequelqu'un,

quelque chosen'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é.

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

Danger

« Ce qui constitueune menace,

un risquepour 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.

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

CRYPTOGRAPHIEET

CRYPTANALYSE

Cryptex façon « Da Vinci Code »

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

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.

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

Le chiffrede

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 œuvre (disques offert en cadeau aux enfants aux USA dans les magazines).

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

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

Le plus connu des chiffres de CésarROT13 = « rotation » de 13 caractères

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

Analyse fréquentielle

Méthode pour déchiffrer les substitutions simples.

Développée par les arabes (Al-Kindi) au 9ème siècle.

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

Le chiffrede

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.

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

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.

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

La machineEnigma

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.

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

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.

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

LES OPERATIONSCRYPTOGRAPHIQUES

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

HASHER

Fonctions mathématiques.

A priori destructives (non reversibles).

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

SHA-2

Bibliothèque de fonctions cryptographiques de hashage.

Conçue par la NSA.

Plus utilisée : SHA-256

SHA = Secure Hash Algorithm

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

Exemple : la somme de contrôle d'un fichier

> cat mon_fichier.txtFichiercontenantdesdonnéesimportantes.

> md5sum mon_fichier.txtf530b08d011669bf271fbd60b91b95b7

> sha1sum mon_fichier.txta136aef251b4c7458d6870c7476079c6ff06fce5

> sha256sum mon_fichier.txt0dc6fd63d59eb2f26000f1486516de4297b42c89eeccddb47203111a1a2b0a91

Permet de vérifier qu'un fichier n'a pas été corrompu.

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

Autre exemple : les commits dans Git

> git log --reverse

commit f90acc01df5c399f9badebe1b306dd6b0e86df90Author: Noel Bardelot <[email protected]>Date: Fri Oct 31 15:20:36 2014 +0100

Feat.: ajout d'une IA

commit c91d5ff37726891d1ae5498d6a59d49bb0bf06dcAuthor: Noel Bardelot <[email protected]>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 ».

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

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.

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

{ "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.

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

CHIFFRERCHIFFRER

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.

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

Chiffrementsymé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.

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

Chiffrementasymétrique

Clé publique connue de tous, sert à chiffrerClé privée connue d'un seul, sert à déchiffrer

Pas les même fonctions mathématiques que pour le chiffrement symétrique.

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

THE

SERVER

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.

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

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.

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

AmericanEncryptionStandard

Vincent RijmenJoan Daemen

Symét

rique

AES (algorithme retenu : Rijndael)● Vincent Rijmen & Joan Daemen● remplace DES (1977)● standardisé en 2001/2002RapidePeu gourmand en RAM

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

RivestShamirAdlemanAsy

mét

rique

● RSA ● Ron Rivest + Adi Shamir + Leonard Adleman● 1977

● Implémentation la plus courante

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

vs.

Asymétrique

Plus lent

Nombres premiers

Secret non partagé

Symétrique

Plus rapide

Clé aléatoire

Partager la clé

● SymétriqueAvantage :● Transmission sécurisée avec un coût de calcul

faible (par rapport au chiffrement asymétrique)● Clé secrète aléatoireInconvé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!)

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

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 ?

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

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 »).

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

Autorité de certificationFournisseur officiel de clés

Certificat à clé publique● Garantir le propriétaire d'une clé publiqueAutorité 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

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

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

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

X.509

X.509, la spécification● Émettre un certificat● Valider un certificat● Révoquer un certificat

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

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

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

DES OUTILSET

DES BONNES PRATIQUES

L'actu en Patates (Martin Vidberg)

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

TransportLayerSecurity

Protocoles TLS de l'IETF

Successeur de SSL de Netscape (terme obsolète)

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

Le modèle OSI

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

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

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é

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

● 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)

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

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

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

FTP+ STARTTLS

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

SMTP &IMAP &POP3 +STARTTLS

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

STOCKAGESÉCURISÉ

Les données sensibles ne doivent pas être corrompues ou dérobées

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

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

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

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.

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

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.

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

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.

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

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.

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

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

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

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

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

LA SÉCURITÉ :CONCEPT GLOBAL

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

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 compromistout le mécanisme est compromis

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

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.

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

Local storage

Idem que pour les cookies.

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

L'ajout manuel de certificats

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

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

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

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

Le système

Trojans, keyloggers, etc.

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

Les bibliothèques

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

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

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.

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

Le hardware

L'ajout de composants électroniques pour écouter/enregistrer des communications à très bas niveau n'est pas de la science fiction.

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

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

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

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

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

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

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

les bons outils,

des développeurs responsables,

Des standards éprouvés,

et ça dès le début d'un projet.

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

Bibliographie

Histoire des codes secrets, par Simon Singh

https://www.schneier.comle blog de Bruce Schneier

Cryptonomicon, par Neal Stephensonroman

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

Avez-vousdesquestions ?