APIs de sécurité

Transcription

APIs de sécurité

Sécurité des implémentations pour la
cryptographie
Partie 2 : APIs de sécurité
Benoı̂t Gérard
4 janvier 2017
Fil rouge
Objectif
Développement de la CCP (Carte Cryptographique Personnelle).
I
Donnée par l’administration (autorité de confiance).
I
Doit pouvoir être utilisée pour tout besoin faisant intervenir de la
cryptographie.
Benoı̂t Gérard
APIs de sécurité
2 / 27
Plan du cours
Étape 1
Définition de l’interface carte/terminal : API exposée par la carte.
Étape 2
Implémentation d’une version résistante aux attaques non-crypto.
Étape 3
Implémentation d’algo. crypto. résistante aux attaques distantes.
Étape 4
Implémentation d’algo. crypto. résistante aux attaques locales.
Benoı̂t Gérard
3 / 27
Sommaire de la session
Introduction
Principes et outils
Gestion des clefs
Ce qui existe
Benoı̂t Gérard
4 / 27
Plan
Introduction
Principes et outils
Gestion des clefs
Ce qui existe
API de sécurité
Motivation
I
On a une carte avec des secrets.
I
On veut les utiliser
sans les compromettre i.e.
I
I
I
les secrets restent secrets
les secrets ne sont pas altérés.
→ confidentialité
→ intégrité
Analogie bancaire
On veut un coffre fort !
infrastructure + règles d’accès
⇓
politique de sécurité
Benoı̂t Gérard
5 / 27
API de sécurité
Définition
API de sécurité
Interface entre une zone sécurisée et le reste du monde.
Elle doit garantir la validité d’une ou plusieurs propriétés de sécurité pour
toute suite d’appels à ses fonctions.
Requêtes
Benoı̂t Gérard
SYM
ASYM
CLES
MEM
ALEA
SEC
API
6 / 27
API de sécurité
Problématiques
Propriété de sécurité classique
Un attaquant ne peut connaı̂tre que les secrets d’utilisateurs qu’il a
corrompu.
Contraintes :
I
besoin de standards flexibles,
I
garantie des propriétés de sécurité.
Problème
Plus de flexibilité ⇒ plus de difficultés à garantir la sécurité.
Exemple de PKCS#11
API de sécurité avec 70 fonctions (250 pages et 5 versions).
Benoı̂t Gérard
7 / 27
Plan
Introduction
Principes et outils
Gestion des clefs
Ce qui existe
Politique de sécurité
Une politique de sécurité pour une application cryptographique :
I
Période de validité des certificats.
I
Définition des droits de l’administrateur.
I
Définition des droits des utilisateurs.
Règles de manipulation des secrets :
I
I
I
I
impossible de supprimer le secret racine,
possibilité d’exporter certains secrets
...
Tout ceci en fonction
1. de l’instant,
2. du type de secret,
3. de l’identité de l’utilisateur.
Benoı̂t Gérard
8 / 27
Machines à états
Cycles de vie
Plusieurs cycles (pouvant être indépendants)
I
cycle de vie du système
I
cycle de vie d’un élément (e.g. carte)
I
cycle de vie de l’API
Changement de propriétaire d’une carte ⇒ RAZ du cycle de l’API.
Renouvellement d’une carte
⇒ RAZ du cycle de l’élément.
En général
Contient au moins les états :
1. Initialisation/Personnalisation (e.g. injection données personelles)
2. Utilisation
3. Fin de vie
Benoı̂t Gérard
9 / 27
Machine à états
Rôles des états
À chaque état sa liste d’actions autorisées.
start
S1
I
Insertion des données biométriques
seulement en S1 .
I
La génération/injection du secret racine
ne peut avoir lieu qu’en S2 .
I
Utilisation des services uniquement dans
l’état S3 .
I
Dans l’état S4 on peut uniquement
déverouiller la carte.
I
...
linkToOwner
S2
unlock setSecret
S4
S3
lock
kill
Sf
Benoı̂t Gérard
10 / 27
Machines à états
Le séquenceur
I
Reçoit les requêtes.
I
Applique les règles du cycle de vie de l’API.
Applique les règles de séquencement des sous-états
I
I
I
I
I
début/suite/fin du hachage
authentification avant un échange de clef DH
confirmation de l’échange de clef avant utilisation de celle-ci
...
Partie de l’implémentation très critique et potentiellement complexe.
I
Faire au plus simple.
I
Être rigoureux et exhaustif.
Essentiel pour garantir que l’on se place bien dans le modèle des preuves
cryptographiques (de protocoles ou autres).
Benoı̂t Gérard
11 / 27
Objets
Les données à protéger sont :
I
des clefs,
I
des données sensibles.
Mais on a aussi des certificats.
On a donc des données
I
de sensibilités 6=,
I
de tailles 6=,
I
ayant des périodes de validité 6=,
I
pour des usages 6=.
Différents types/structures pour différents objets contenant
la valeur utile et des attributs.
Benoı̂t Gérard
12 / 27
Objets
Attributs
Les attributs permettent de formaliser la politique de sécurité.
Cas multi-utilisateurs
Des attributs owner et/ou group permettent de donner des droits quant
à l’usage d’une clef.
Transport
Un attribut exportable permet de savoir si l’on peut sortir une clef du
coffre (chiffrée bien entendu).
Validité
Un attribut validity permet de donner une date limite de validité à un
certificat.
Benoı̂t Gérard
13 / 27
Droits
Authentification
Les propriétés de sécurité reposent sur le fait que l’API sache quel
utilisateur est connecté.
La sécurité ne peut jamais entièrement se baser sur de la cryptographie !
I
Vol de carte/badge/dongle.
I
Récupération de mot de passe.
I
Piratage des lecteurs d’empreintes.
I
...
Et en cas de perte d’un élément d’authentification ?
Benoı̂t Gérard
14 / 27
Droits
Authentification forte
Authentification forte
Renforcer l’assurance que la bonne personne se connecte.
Combinaison de techniques :
I
dispositif électronique (clef, carte, dongle . . .),
I
mot de passe (ou code PIN),
I
envoi d’un code par messagerie (SMS, internet),
I
biométrie (empreinte digitale, rétine, ECG)
I
...
Compromis entre complexité de mise en oeuvre et sécurité.
Permet un mode dégradé en cas de perte.
Benoı̂t Gérard
15 / 27
Droits
L’authentification permet de déterminer
I
l’ensemble des objets possédés,
I
le rôle de l’utilisateur.
En fonction, l’utilisateur aura différents droits.
I Droit de créer/supprimer
I
I
I
I
Droit d’exporter/importer
I
I
I
un utilisateur,
un objet possedé,
un objet autre.
un objet possedé,
un objet autre.
Droit d’effectuer certaines opérations spéciales
I
I
transition entre deux états du cycle de vie,
mise à jour.
Benoı̂t Gérard
16 / 27
Exemple
Retour à l’attaque sur la carte bancaire
Rappel des faits
Le composant pirate répond OK pour le code pin à la place de la carte.
Analyse
La carte n’a donc pas validé de code PIN avant la transaction.
Solution possible
Ajout d’un séquenceur qui vérifie qu’un code PIN a été testé
avant une transaction.
Benoı̂t Gérard
17 / 27
Exemple
Rappel des faits
Analyse
Solution possible
Ajout d’un séquenceur qui vérifie qu’un code PIN a été testé avec succès
Benoı̂t Gérard
17 / 27
Exemple
Rappel des faits
Analyse
Solution possible
Ajout d’un séquenceur qui vérifie qu’un code PIN a été testé avec succès
Variantes liées aux contraintes commerciales
I
Ajout d’un compteur : max. 3 opérations sans code PIN par mois.
I
Ajout d’un plafond : max. 100 euros dépensés avant code PIN
obligatoire.
Benoı̂t Gérard
17 / 27
Plan
Introduction
Principes et outils
Gestion des clefs
Ce qui existe
Création des clefs
Génération/import
La génération de clef peut avoir lieu :
I
dans le périmètre de sécurité.
I
hors du périmètre (import dans le périmètre par la suite).
Attention dans les deux cas !
Interne :
I
Disposer d’un bon aléa.
Externe :
I
Aucune maı̂trise de l’aléa utilisé.
I
Aucune garantie de non diffusion de la clef.
Périmètre de sécurité
Contient toutes les implémentations de l’API qui sont de confiance.
Benoı̂t Gérard
18 / 27
Manipulation des clefs
Quelques mécanismes
Key Wrap
Stockage/transport de clefs hors périmètre de sécurité ⇒ besoin
- de confidentialité,
- d’intégrité/d’authenticité.
Handles
Permet l’utilisation des clefs sans les manipuler directement (identifiants).
Cryptopériode
- usure de la clef,
- impact d’une compromission.
Benoı̂t Gérard
19 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
req = clef grise
Benoı̂t Gérard
20 / 27
Handles
md
p
=
to
to
req = clef grise
Benoı̂t Gérard
20 / 27
Handles
md
p
=
to
to
req = clef grise
Benoı̂t Gérard
20 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
req = ECDSA
clef grise
Benoı̂t Gérard
20 / 27
Handles
req = ECDSA
md
p
=
to
to
clef grise
Benoı̂t Gérard
20 / 27
Handles
req = ECDSA
md
p
=
to
to
clef grise
Benoı̂t Gérard
20 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
Benoı̂t Gérard
20 / 27
Handles
Il existe ce genre de solution :
YubiKey par exemple.
Benoı̂t Gérard
20 / 27
Typer les clefs
Bonne pratique
Différencier (fortement) les éléments sensibles.
Mauvais exemple (possible dans PKCS #11)
Attribut sensible.
1. K crée déclarée sensible
1. K crée
2. Export(K) refusé
2. Export(K) autorisé
3. Attribut sensible désactivé
3. K déclarée sensible
4. Export(K) autorisé
Leçon
Type défini à la création d’un élément.
Types/attributs liés à la sécurité non modifiables (par l’utilisateur).
Benoı̂t Gérard
21 / 27
Cloisonner les clefs
Buts
1. Limiter l’impact d’une compromission.
2. Éviter de tendre le bâton à l’attaquant.
Benoı̂t Gérard
22 / 27
Cloisonner les clefs
Buts
1. Limiter l’impact d’une compromission.
2. Éviter de tendre le bâton à l’attaquant.
Exemple : sortir une clef en clair
Clef K qui protège en confidentialité les clefs et les messages.
1. C = E(K, K 0 )
2. E −1 (K, C) → K 0
Exemple : injecter une clef maı̂trisée
Clef K chiffrement + import de clefs.
1. C = E(K, 0)
2. K 0 = Import(K, C) = E −1 (K, C) → K 0 = 0
Benoı̂t Gérard
22 / 27
Coffre fort de clefs
Il existe d’autres attaques plus ou moins réalisables en pratique :
I
key conjuring (générationd de clefs non autorisées),
I
key binding (découpe de clefs longues en sous-clefs),
I
injection clef troyenne.
À retenir
Une bonne sécurité des clefs implique
1. de contrôler fortement les opérations effectuées,
2. de séparer les clefs selon leurs usages.
C’est une grande source de vulnérabilités (on n’a pourtant pas fait de
cryptanalyse).
Benoı̂t Gérard
23 / 27
Plan
Introduction
Principes et outils
Gestion des clefs
Ce qui existe
PKCS #11
Déploiement
API C utilisée par :
I
autorités de certification,
I
HSM (Hardware Security
Module)
I
GnuTLS,
I
OpenSSL/SSH/SC,
I
Mozilla,
I
OpenVPN,
I
Truecrypt,
I
...
Benoı̂t Gérard
Implémentation conforme
PKCS #11
m
implémente un sous-ensemble de
règles
24 / 27
PKCS #11
Analyse
I
Model checking
I
I
I
I
I
I
par Graham Steel
analyse l’implémentation pour déterminer le sous-ensemble de règles
implantées,
fourni le modèle correspondant à un model checker,
fait tourner le checker jusqu’à trouver une faille.
Très peu d’implémentations résistantes . . .
Preuve formelle API générique proposée à CCS en 2012
I
I
gestion des clefs symétriques,
prise en compte de la révocation.
Comment s’assurer que l’implémentation finale est bien conforme aux hypothèses de la preuve ?
Benoı̂t Gérard
25 / 27
Dans l’industrie
Problématique de la certification (Critères Communs) :
I
certification obtenue auprès de l’ANSSI et des CESTIs,
I
on ne peut plus toucher au produit une fois obtenue,
I
EAL4 et plus : demande une conception méthodique,
I
EAL5 et plus : nécessite des méthodes (semi-)formelles.
Contraintes coût/délai/performances :
I
manque de temps,
manque de compétences,
⇒ utilisation de produits sur étagère fait par des spécialistes
I
I
I
I
HSM (PCI, microSD),
TPM (composant pour carte mère),
Globull (disque avec coeur crypto de chez Bull).
Benoı̂t Gérard
26 / 27
À retenir
Messages
I
Faire au plus simple.
I
Quand la complexité augmente : avoir une méthodologie “formelle”
pour être précis, clair et non-ambigu.
I
Les contrôles aident à garantir que l’on reste dans le modèle.
Bonnes pratiques
I
Limiter l’exposition des clefs.
I
Cloisonner le plus possible afin de limiter les impacts.
Benoı̂t Gérard
27 / 27

APIs de sécurité

Transcription

Documents pareils

Quelques leçons sur la sécurité apr`es les piratages de Twitter

Attestation de la qualité d`Ayant Droit

Logiciels libres et formats ouverts pour la sécuritè informatique

Sophie PARIS Assistante dentaire en contrat de professionnalisation

Des correctifs de sécurité à la mise à jour

Une allÃ©e du Luxembourg

DU - ISN

TD: Parabole de sécurité