Informations :
Dates
- Publish : : Friday 12 january 2024
- Modification : Thursday 22 february 2024
- 374 views
Share :
Cryptographie asymétrique
La cryptographie asymétrique, ou « cryptographie à clé publique » est un domaine relativement récent de la cryptographie.
Elle permet d' « assurer la confidentialité d'une communication », ou d' « authentifier les participants », sans que cela repose sur une « donnée secrète partagée » entre ceux-ci, contrairement à la cryptographie symétrique qui nécessite ce secret partagé préalable.
La cryptographie asymétrique peut être illustrée avec l'exemple du chiffrement à clé « publique » et « privée », dont le but, comme tout chiffrement, est de garantir la confidentialité d'une donnée lors d'une transmission de celle-ci.
Le terme asymétrique s'explique par le fait qu'il utilise deux clés différentes, l'une, « la clé publique, pour chiffrer », l'autre, « la clé privée, pour déchiffrer ».
L'utilisateur qui souhaite recevoir des messages engendre un tel couple de clés. Il ne transmet à personne la clé privée alors que la clé publique est transmissible sans restriction.
Quiconque souhaite lui envoyer un message confidentiel utilise la « clé publique » (de l'autre) pour chiffrer celui-ci.
Le message chiffré obtenu ne peut être déchiffré que connaissant la « clé privée » (la sienne).
Il peut donc être communiqué publiquement : la confidentialité du message original est garantie. Le destinataire, qui n'a communiqué à personne sa clé privée, est le seul à pouvoir, à l'aide de celle-ci, déchiffrer le message transmis pour reconstituer le message original.
Un problème crucial pour l'émetteur est de s'assurer que la clé publique qu'il utilise est bien celle du destinataire souhaité ;)
Ce système a deux utilisations majeures :
- la confidentialité des messages reçus : c'est celle qu'on vient de décrire, l'expéditeur utilise la clé publique du destinataire pour chiffrer son message. Le destinataire utilise sa clé privée pour déchiffrer le message de l'expéditeur, garantissant la confidentialité du contenu ;
- l'authentification de l'expéditeur d'un message (pas nécessairement confidentiel)?: l'expéditeur utilise sa clé privée pour chiffrer un message que n'importe qui peut déchiffrer avec la clé publique de l'expéditeur, ce qui garantit que le message a été chiffré par l'expéditeur, seul à posséder la clé privée ; c'est le mécanisme utilisé par la « signature numérique » pour authentifier l'auteur d'un message.
La « signature numérique » est un mécanisme permettant d'authentifier l'auteur d'un document électronique et d'en garantir la « non-répudiation » (le fait de s'assurer qu'un contrat, notamment un contrat signé via internet, ne peut être remis en cause par l'une des parties), par analogie avec la signature manuscrite d'un document papier.
Dans le domaine de la sécurité des systèmes d'information, la « non-répudiation » signifie la possibilité de vérifier que l'envoyeur et le destinataire sont bien les parties qui disent avoir respectivement envoyé ou reçu le message.
WikipediA :
- https://fr.wikipedia.org/wiki/Cryptographie_asymétrique
- https://fr.wikipedia.org/wiki/Signature_numérique
IKE : Internet Key Exchange
Le protocole de communication IKE (Internet Key Exchange) est chargé de négocier la connexion d'un tunnel IPSec (Internet Protocol Securited).
Avant qu'une transmission sécurisé IPSec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d'un tunnel/liaison sécurisé en échangeant des clés partagées.
Ce protocole permet deux types d'authentifications :
- PSK (Pre-Shared Key ou « secret partagé ») est une donnée connue seulement des parties impliquées dans une communication sécurisée (le « secret partagé » peut être un mot de passe, une phrase secrète, un grand nombre ou une suite aléatoire de bits) ;
- ou à l'aide de « certificats TLS ».
Une technique de « cryptographie asymétrique » est utilisée pour authentifier les deux parties (les clefs de Diffie-Hellman).
IKE utilise l'échange de clés (en cryptographie) Diffie-Hellman par laquelle deux agents, nommés par convention « Alice » et « Bob », peuvent se mettre d'accord sur un nombre (qu'ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu'un troisième agent appelé « Ève » puisse découvrir le nombre, même en ayant écouté tous leurs échanges.
WikipediA :
- https://fr.wikipedia.org/wiki/Internet_Key_Exchange
- https://fr.wikipedia.org/wiki/Échange_de_clés_Diffie-Hellman
- https://fr.wikipedia.org/wiki/Secret_partagé
- https://fr.wikipedia.org/wiki/IPsec
Nous avions déjà découvert IKEv1 et les échanges de messages IKEv1 en Phase1 (mode principal/mode agressif) et Phase2 (mode rapide). Dans IKEv1, il y a neuf échanges de messages si IKEv1 Phase 1 est en mode principal (six messages pour le mode principal et trois messages pour le mode rapide) ou six échanges de messages si IKEv1 Phase 1 est en mode agressif (trois messages pour le mode agressif et trois messages pour le mode rapide).
Avec Internet Key Exchange Version 2 (IKEv2), la dernière version d'IKE -- qui possède la plupart des fonctionnalités d'IKEv1 -- dispose également d'un processus de négociation en « deux phases ».
La première phase est appelée IKE_SA_INIT et la deuxième phase est appelée IKE_AUTH.
À la fin du deuxième échange (Phase 2), la première CHILD SA est créée. « Child SA » est le terme IKEv2 pour « IKEv1 IPSec SA ».
Dans une instance ultérieure, il est possible de créer des « Child SA » supplémentaires pour utiliser un nouveau tunnel.
Cet échange est appelée par CREATE_CHILD_SA. De nouvelles valeurs Diffie-Hellman et de nouvelles combinaisons d'algorithmes de chiffrement et de hachage peuvent être négociées lors de l'échange CREATE_CHILD_SA.
IKEv2 s'exécute sur les ports UDP 500 et 4500 (IPsec NAT Traversal). Les appareils configurés pour utiliser IKEv2 acceptent les paquets des ports UDP 500 et 4500.
Les « pairs IPSec IKEv2 » peuvent être validés à l'aide :
- de clés pré-partagées,
- de certificats TLS ou
- du protocole d'authentification extensible (EAP).
Le protocole d'authentification extensible (EAP : Extensible Authentication Protocol) autorise d'autres méthodes d'authentification héritées entre homologues (peers) IPSec.
Les échanges de messages IKEv2 Phase 1 (IKE SA) et Phase 2 (Child SA) :
Le protocole Internet Key Exchange Version 2 (IKEv2) dispose d'un processus de négociation en « deux phases ».
IKEv2 Phase 1 - Messages 1
Dans IKEv2, le premier message de l'initiateur au répondeur (IKE_SA_INIT : Initiator to Responder) contient les propositions d'association de sécurité (Security Association proposals), les algorithmes de chiffrement et d'intégrité (Encryption and Integrity algorithms), les clés Diffie-Hellman (Diffie-Hellman keys) et les noms occasionnels (Nonces).
IKEv2 Phase 1 - Messages 2
Dans IKEv2, le deuxième message du répondeur à l'initiateur (IKE_SA_INIT) contient les propositions d'association de sécurité (Security Association proposals), les algorithmes de chiffrement et d'intégrité (Encryption and Integrity algorithms), les clés (Diffie-Hellman keys) et les noms occasionnels (Nonces).
IKEv2 Phase 1 - Messages 3 et 4
Les troisième et quatrième massages (IKE_AUTH) sont cryptés et authentifiés sur l'IKE SA créé par les messages 1 et 2 précédents (IKE_SA_INIT). Ces deux messages sont destinés à l'authentification. L'identité de l'initiateur et du répondeur et l'échange de certificats (si disponible) sont complétés à ce stade. Les troisième et quatrième massages (IKE_AUTH) servent à authentifier les messages précédents, à valider l'identité des pairs IPSec et à établir le premier CHILD_SA.
A la fin des messages 3 et 4, les identités des homologues IPSec sont vérifiées et le premier CHILD_SA est établi.
Le « Child SA » (IPsec Security Association) d'un tunnel VPN (Virtual Private network) sert à la négociation des paramètres de sécurité qui seront appliqués aux données transmises dans le tunnel VPN.
Une « Child SA » est toute Association de Security (SA) qui a été négociée via l'IKE SA (Security Association d'une Internet Key Exchange).
Une « IKE SA » peut être utilisée pour négocier soit des SA (Security Association) pour protéger le trafic (IPSec SA / Child SA), soit pour créer une autre IKE SA.
EAP : Extensible Authentication Protocol
L'EAP (Extensible Authentication Protocol) est un protocole d'authentification qui permet d'envoyer des informations d'identification permettant l'accès à un réseau sans fil (crypté). Il utilise un mécanisme d'authentification plus sophistiqué pour les connexions réseau (Intranet, Internet) qu'un protocole de base protégé seulement par un mot de passe. Il peut s'agir de certificats numériques, de mots de passe à usage unique, de cartes à jeton, de cartes à puce et de cryptage à clé publique.
WikipediA :
ESP : Encapsulating Security Payload
Le protocole ESP appartenant à la suite IPsec, permettant de combiner plusieurs services de sécurité : confidentialité, authentification et intégrité.
Le protocole ESP permet de combiner, à volonté, plusieurs services de sécurité comme :
- la confidentialité des données par l'utilisation d'un système de chiffrement ;
- l'authentification du paquet et de son émetteur (l'adresse source du paquet est celle de l'émetteur) ;
- l'intégrité des données (aucune altération volontaire ou non du paquet durant le transport)
- et l'unicité du paquet (pas de rejeu).
Par opposition à l'Authentication Header (AH), qui ajoute seulement un en-tête supplémentaire au paquet IP, ESP chiffre les données puis les encapsule.
AH assurant l'intégrité des données transférées, on obtient l'authentification et l'intégrité des données transférées.
ESP propose de l'authentification de la même manière que AH (Authetification Header) grâce à l'utilisation de données d'en-tête :
Le SPI (Security Parameters Index) permet de caractériser l'association de sécurité (Security Association) utilisée pour la communication (SA).
Les données d'authentification contiennent la valeur de vérification d'intégrité (ICV) permettant de vérifier l'authenticité des données du paquet.
Les données chiffrées sont contenues dans la partie « champ libre » (ou PayLoad Data) du paquet.
Ce champ contient éventuellement aussi des données de synchronisation. Du bourrage (Padding), peut être ajouté si nécessaire. Sa longueur est spécifiée dans le champ prévu à cet effet.
Enfin, le champ En-tête suivant (Next Header) indique la nature des informations contenues dans le Payload Data (champ libre).
WikipediA :
- https://fr.wikipedia.org/wiki/Encapsulating_Security_Payload
- https://fr.wikipedia.org/wiki/Authentication_Header
ESP chiffrement :
Exemples :
Script avec 5 lignes
001proposals = aes256-sha256-x25519002# strongSwan 5.9.x003esp_proposals = aes256gcm128-chacha20poly1305-x25519004# strongSwan 6.0.beta005esp_proposals = aes256-sha256-x25519-ke1_kyber3-ke2_bike3-ke3_hqc
Je vous redirige vers PQ-StrongSWAN v6.x et la documentation officielle pour se créer une très forte « Secure Wide Area Network » pour la préparation et mise en garde contre la dé-cryptographie de l'après ère quantique, entre notre entitées (ex: Les communications entre l'Elysée et les ambassades à travers le monde).
Et cela surtout quand des machines supers calculatrices quantiques et neuronnales seront en actions et qu'elles pourront analyser toutes nos faiblessses de caches, de télécommunications inter-stellaires.
C'est humain-noïdes, toutes ces avancées technologiques ?! Ce ne sont pas des conneries, mais pour exemple, je ne crois pas calculer 228 billions de choses par seconde . Il ne faudrait pas se faire tout voler par nos créations. Je prefère nous prevenir.
;-)
Exemple d'algorithmes de suites de chiffrement pour l'authentification et l'encryption.
Les algorithmes de sécurité informatiques.
Authentification initiale (TLS)
Suite de Sécurité :
- Automatique : toutes les suites cryptographiques (sauf nulle) sont proposées à la passerelle qui décide de la meilleure suite à utiliser.
- TLS v1.2 — Medium : seules les suites cryptographiques « moyennes » sont proposées à la passerelle. Dans la version actuelle, ce sont les suites utilisant des algorithmes de chiffrement de 128 bits.
- TLS v1.2 — High : seules les suites cryptographiques fortes sont proposées à la passerelle. Dans la version actuelle, ce sont les suites utilisant des algorithmes de chiffrement supérieurs ou égaux à 128 bits.
- TLS v1.3 : suite TLS 1.3 négociée avec la passerelle, incluant :
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_CCM_SHA256TLS_AES_128_CCM_8_SHA256
Pour plus d’informations : OpenSSL Ciphers : Outil d'affichage du chiffrement SSL et de liste de chiffrement → https://www.openssl.org/docs/man1.1.1/man1/ciphers.html
Suite de Sécurité pour le Trafic
Authentification (Algorithme d’authentification négocié pour le trafic) :
- Automatique
SHA-224SHA-256SHA-384SHA-512
Chiffrement (Algorithme de chiffrement du trafic) :
- Automatique
AES-128-CBCAES-192-CBCAES-256-CBC
Compression (Compression du trafic) :
- Automatique
- None
Lz0Lz4
Automatique signifie que le Client VPN s’adapte automatiquement aux paramètres de la passerelle.
Extra HMAC (TLS-Auth) - Autre type d'authentification
Cette option ajoute un niveau d’authentification aux paquets échangés entre le Client VPN et la passerelle VPN. Pour être opérationnelle, cette option doit aussi être configurée sur la passerelle (sur une passerelle, cette option est souvent appelée « TLS-Auth »)
Cette clé doit être saisie à l’identique sur la passerelle. C’est une suite de caractères hexadécimaux, le format est :
Script avec 5 lignes
001-----BEGIN Static key-----002362722d4fbff4075853fbe6991689c36003[...]004cb488b5dd8ce9733055a3bdc17fb3d2d005-----END Static key-----
Dead Peer Detection (DPD)
La fonction DPD (Dead Peer Detection) permet aux deux extrémités du tunnel de vérifier mutuellement leur présence.
Liste d'algorithmes de chiffrement (ciphers list : OpenSSL, drbg, frodo, liboqs, xcbc)
Script avec 121 lignes
001# swanctl --version002strongSwan swanctl 6.0.0beta5003# swanctl --list-algs004encryption:005AES_CBC[openssl]006AES_CTR[openssl]007AES_ECB[openssl]008AES_CFB[openssl]009CAMELLIA_CBC[openssl]010CAMELLIA_CTR[openssl]011CAST_CBC[openssl]012BLOWFISH_CBC[openssl]0133DES_CBC[openssl]014DES_CBC[openssl]015DES_ECB[openssl]016NULL[openssl]017integrity:018HMAC_MD5_96[openssl]019HMAC_MD5_128[openssl]020HMAC_SHA1_96[openssl]021HMAC_SHA1_128[openssl]022HMAC_SHA1_160[openssl]023HMAC_SHA2_256_128[openssl]024HMAC_SHA2_256_256[openssl]025HMAC_SHA2_384_192[openssl]026HMAC_SHA2_384_384[openssl]027HMAC_SHA2_512_256[openssl]028HMAC_SHA2_512_512[openssl]029CAMELLIA_XCBC_96[xcbc]030AES_XCBC_96[xcbc]031AES_CMAC_96[cmac]032aead:033AES_GCM_16[openssl]034AES_GCM_12[openssl]035AES_GCM_8[openssl]036AES_CCM_16[openssl]037AES_CCM_12[openssl]038AES_CCM_8[openssl]039CHACHA20_POLY1305[openssl]040hasher:041HASH_SHA1[openssl]042HASH_MD5[openssl]043HASH_MD4[openssl]044HASH_SHA2_224[openssl]045HASH_SHA2_256[openssl]046HASH_SHA2_384[openssl]047HASH_SHA2_512[openssl]048HASH_SHA3_224[openssl]049HASH_SHA3_256[openssl]050HASH_SHA3_384[openssl]051HASH_SHA3_512[openssl]052HASH_IDENTITY[openssl]053prf:054PRF_KEYED_SHA1[openssl]055PRF_HMAC_MD5[openssl]056PRF_HMAC_SHA1[openssl]057PRF_HMAC_SHA2_256[openssl]058PRF_HMAC_SHA2_384[openssl]059PRF_HMAC_SHA2_512[openssl]060PRF_AES128_XCBC[xcbc]061PRF_CAMELLIA128_XCBC[xcbc]062PRF_AES128_CMAC[cmac]063xof:064XOF_SHAKE128[openssl]065XOF_SHAKE256[openssl]066kdf:067KDF_PRF[openssl]068KDF_PRF_PLUS[openssl]069drbg:070DRBG_CTR_AES256[drbg]071DRBG_CTR_AES128[drbg]072DRBG_CTR_AES192[drbg]073DRBG_HMAC_SHA1[drbg]074DRBG_HMAC_SHA256[drbg]075DRBG_HMAC_SHA384[drbg]076DRBG_HMAC_SHA512[drbg]077ke:078MODP_3072[openssl]079MODP_4096[openssl]080MODP_6144[openssl]081MODP_8192[openssl]082MODP_2048[openssl]083MODP_2048_224[openssl]084MODP_2048_256[openssl]085MODP_1536[openssl]086MODP_1024[openssl]087MODP_1024_160[openssl]088MODP_768[openssl]089MODP_CUSTOM[openssl]090ECP_256[openssl]091ECP_384[openssl]092ECP_521[openssl]093ECP_224[openssl]094ECP_192[openssl]095ECP_256_BP[openssl]096ECP_384_BP[openssl]097ECP_512_BP[openssl]098ECP_224_BP[openssl]099CURVE_25519[openssl]100CURVE_448[openssl]101FRODO_SHAKE_L1[frodo]102FRODO_SHAKE_L3[frodo]103FRODO_SHAKE_L5[frodo]104FRODO_AES_L1[frodo]105FRODO_AES_L3[frodo]106FRODO_AES_L5[frodo]107KYBER_L1[oqs]108KYBER_L3[oqs]109KYBER_L5[oqs]110BIKE_L1[oqs]111BIKE_L3[oqs]112BIKE_L5[oqs]113HQC_L1[oqs]114HQC_L3[oqs]115HQC_L5[oqs]116rng:117RNG_WEAK[openssl]118RNG_STRONG[random]119RNG_TRUE[random]120nonce-gen:121NONCE_GEN[nonce]
Bonne encryption.
Informations complémentaires :
- StrongSwan : docs
- LibreSwan : IKEv2_Child_SA
- Algorithmes de chiffrement pour les connexions TLS SMTP Gmail - Règles SSL pour les protocoles SSL et TLS
- Suites de chiffrement dans TLS/SSL (SSP Schannel)
- CRYSTALS : Cryptographic Suite for Algebraic Lattices
La « Suite cryptographique pour les treillis algébriques » (CRYSTALS) englobe deux primitives cryptographiques : Kyber, un mécanisme d'encapsulation de clé (KEM) sécurisé par IND-CCA2 (IND-CCA2-secure key-encapsulation mechanism (KEM)) ; et Dilithium, un algorithme de signature numérique fortement sécurisé EUF-CMA (EUF-CMA-secure). Les deux algorithmes sont basés sur des problèmes difficiles sur les réseaux de modules, sont conçus pour résister aux attaques de grands ordinateurs quantiques et ont été soumis au projet de cryptographie post-quantique du NIST.
- Computer Security Resource Center : NIST (National Institute of Standards and Technology) Post-Quantum Cryptography #PQC
- Open Quantum Safe (OQS)
Le projet Open Quantum Safe (OQS) est un projet open source qui vise à soutenir la transition vers une cryptographie résistante aux quantiques. OQS fait partie de la Post-Quantum Cryptography Alliance de la Linux Foundation.
OQS se compose de deux axes de travail principaux : "liboqs", une bibliothèque C open source pour les algorithmes cryptographiques résistants aux quantiques, et des intégrations de prototypes dans des protocoles et des applications, y compris la bibliothèque "OpenSSL" largement utilisée. Ces outils soutiennent la recherche par nous-mêmes et par les autres.
Tous nos développements se déroulent sur nos référentiels GitHub. Nous accueillons les nouveaux contributeurs intéressés à rejoindre notre équipe. N'hésitez pas à commencer à participer sur GitHub ou à dire bonjour sur notre serveur Discord sur la chaîne #oqs -general. Nous sommes reconnaissants envers les organisations qui ont soutenu et continuent de soutenir notre travail, ainsi que les contributeurs universitaires, industriels, publics et individuels qui participent au projet.
- Serveur de test d'interopérabilité Open Quantum Safe #OQS pour une cryptographie à sécurité quantique
Ce serveur est une instance NGINX améliorée avec la prise en charge de la cryptographie à sécurité quantique (QSC) à l'aide de progiciels fournis par le projet Open Quantum Safe (OQS).
Afin de fournir aux clients un moyen de tester l'interopérabilité avec ce logiciel amélioré par QSC et les algorithmes QSC contenus, il comporte des ports séparés pour toutes les combinaisons d'algorithmes d'échange de signature/clé QSC prises en charge par la distribution OQS actuelle.
- Serveur de test d'interopérabilité Open Quantum Safe #OQS pour une cryptographie à sécurité quantique
Bonne journée, Romain.
Notes : → Mes tests de configuration (j’ai rien de mieux pour le moment)
- Je ouvert ces papiers sur Debian-Fr.org : QuantumLeap + Post Quantum StrongSwan : Algorithms & compagnies
- Et ici un « mémo d'introduction à strongSwan » Network IPv6 - IPSec - strongSwan - Modern Security communication
- et celui-ci sur LaFibre.info VPN - PQ strongSwan - Modern Security network
