--- titre: Cybersécurité et cyberdéfense (Cours 4) description: Cybersécurité et cyberdéfense (Cours 4), 19/03/2020 tags: C&C, jerome.tchan author: Jérôme Tchan --- # Cybersécurité et cyberdéfense (Cours 4) > Guide de cours > {%pdf https://51.38.177.120/dokuwiki/lib/exe/fetch.php?media=cours:ars:guide_de_cours-c11.pdf %} ## Introduction à la PKI / IGC (Public Key Infrastructure / Infrastructure à gestion de clés) Cryptographie: - Intégrité - Authenticité - Confidentialité Chiffrement symétrique: une clé secrète partagée entre les deux parties => algos les plus rapides Chiffrement asymétrique: chaque partie a 2 clés: une clé privée et une clé publique; on chiffre avec la clé publique et on déchiffre avec la clé privée Hash / condensat: données de taille n ==> donne une signature de taille beaucoup plus petite (de taille fixe pour n'importe quelle taille initiale) Signature: on hash les données et on signe le hash avec sa clé privée et on utilise la clé publique pour garantir que le hash et donc les données associées sont correct Pour un mail que l'on chiffre + signe: mail => condensat => signature => regroupement du mail + signature => chiffrement de l'ensemble Chiffrement symétrique: - par flux - par blocs => La manière de chaîner les blocs / flux est importante, ce n'est pas parce qu'un algo est bon sur un seul bloc / flux qu'il est bon avec tous les blocs (cf AES ECB) ![AES-ECB](https://i.imgur.com/TPrplab.png) On combine symétrique et asymétrique: - On négocie une clé privée en utilisant des algos asymétriques - Les données sont ensuite chiffrées avec la clé privée Comment certifier/vérifier l'identité associé à une clé? - Modèle de confiance pyramidal (eg entreprise) - Modèle de confiance communautaire ("je connais l'ami de ton ami donc is ok") - Registre avec l'ensemble de ce qui est autorisé PKCS: [Public Key Cryptography Standards](https://en.wikipedia.org/wiki/PKCS) Par exemple, PKCS#1 = RSA Connaître PKCS#1, 7, 12 et 15 AE: Autorité d'enrôlement AC: Autorité de certification CSR: Certificate Service Request - L'utilisateur fait sa demande au près de l'AE - l'AE signe la demande de certificat avec sa clé privée - l'AC vérifie la signature et ajoute des champs (validité du certificat, numéro de certificat, etc.) - Publication des certificats (signés avec le certificat de l'AC) dans un annuaire, si le certificat de l'AC est valide ![](https://www.securiteinfo.com/cryptographie/organisation.jpe) Le certificat de l'AC est signé par elle-même Chaque certificat créé par l'AC est numéroté Liste de révocation (CRL): liste de numéros de certificats à revoke La CRL est signée par l'AC et publiée Séquestre: l'AE garde les clés privées de l'utilisateur au cas où il la perd (dans le cas du chiffrement) mais on ne veux pas utiliser la clé pour la signature => on génère deux paires de clés: une pour le chiffrement et une pour la signature et on fait deux CSR On stocke les clés dans un dispositif matériel (carte à puce, etc.) - CSR signature: la carte à puce génère une clé privée (impossible à sortir) et on utilise la clé publique pour faire le certificat - CSR chiffrement: l'AE génère la clé privée et on injecte la clé privée dans la carte à puce, de cette manière l'AE peut séquestrer la clé privée et après on continue le processus habituel transchiffrement: tout déchiffrer et tout rechiffrer Si le certificat est périmé, il n'est pas nécessaire de le mettre dans la CRL (vu que le champ dans le certificat permet de déterminer sa validité) OCSP: Online Certificate Status Protocol, permet de vérifier en temps réel qu'un certificat est toujours valable (ou pas) Client fait une requête vers un serveur OCSP (qui a les CRL les plus à jour possible) Le serveur OCSP signe sa réponse Eviter de mettre la même durée de validité pour tous les certificats (histoire d'avoir le temps de réagir) => ex. si on veut qu'un certificat soit valable 360 jours, on ne met pas exactement 360 jours sur tous les certificats Si l'AC expire, toute la chaîne est invalidée **=> La sécurité de la clé privée de l'AC est donc primordiale** ![](https://i.imgur.com/MHbJ3n0.png) Dans ce cas de figure, la CRL de AC IONIS contient uniquement les certificats en dessous de lui; si un certificat de l'AC EPITA se fait révoquer, il ne sera pas dans la CRL de l'AC IONIS mais uniquement dans la CRL de l'AC EPITA HSM: Hardware Security Module, améliorer les performances et la sécurité, peut être utilisé pour stocker les clés privées CMS: Card Management System => BDD gérant l'inventaire des cartes, des HSM, etc.