Informations :
Dates
- Publish : : Friday 08 september 2023
- 607 views
Share :
NdM : Ébauche d'article.
IPsec (Internet Protocol Security)
IPsec (Internet Protocol Security), défini par l'IETF comme un cadre de standards ouverts pour assurer des communications privées et protégées sur des réseaux IP, par l'utilisation des services de sécurité cryptographiques est un ensemble de protocoles utilisant des algorithmes permettant le transport de données sécurisées sur un réseau IP.
IPsec opère à la couche réseau (couche 3 du modèle OSI ) contrairement aux standards antérieurs qui opéraient à la couche application (couche 7 du modèle OSI ), ce qui le rend indépendant des applications.
Son objectif est d'authentifier et de chiffrer les données : le flux ne pourra être compréhensible que par le destinataire final (confidentialité) et la modification des données par des intermédiaires ne pourra être possible (Intégrité).
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 pour chiffrer celui-ci. Le message chiffré obtenu ne peut être déchiffré que connaissant la clé privée. 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.
....
Sources sur WikipediA : IPSec : Internet Protocol Security , IKE : Internet Key Exchange , ESP : Encapsulating Security Payload , AE : Authenticated Encryption (GCM , CCM ) | Authenticated Encryption with Associated Data (AEAD), AH, Authentication Header .
- L'IANA fournit une liste complète des identifiants d'algorithme enregistrés pour IKEv2 .
Post-Quantum Key Exchange Methods
L'institut national des normes et de la technologie américain a publié des projets de normes de cryptographie post-quantique et demande l'avis de l'industrie. Ces normes sont en effet conçues comme un cadre global destiné à aider les entreprises à se protéger contre les cyberattaques quantiques à venir.
Le mécanisme d'encapsulation à clé publique sélectionné est CRYSTALS-KYBER, ainsi que trois schémas de signature numérique : CRYSTAL-Dilithium, FALCON et SPHINCS+. [Lire la suite ]
La prochaine version strongSwan 6.0 prend en charge les algorithmes sélectionnés du NIST PQC (cryptographie post-quantique) et les candidats KEM (Submissions Key Exchange Method) du Round 4 Submissions .
- Post-Quantum Cryptography (PQC) > Post-Quantum Cryptography Standardization : https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization
- Post-Quantum Cryptography (PQC) > Selected Algorithms 2022 : https://csrc.nist.gov/projects/post-quantum-cryptography/selected-algorithms-2022
- Post-Quantum Cryptography (PQC) > Round 4 Submissions : https://csrc.nist.gov/projects/post-quantum-cryptography/round-4-submissions
Les commentaires sur Federal Information Processing Standards Publication FIPS 203 , FIPS 204 ou FIPS 205 doivent être reçus au plus tard le 22 novembre 2023, a déclaré le NIST.
Commercial National Security Algorithm Suite (Algorithmes de sécurité nationale commerciale)
Les suites cryptographiques Suite B pour IPsec (RFC 6379 ) ont été remplacées par la suite CNSA (Commercial National Security Algorithm Suite), qui déprécie fondamentalement la suite 128 bits définie par Suite B. Ses recommandations concernant les paramètres d'algorithme sont les suivantes :
Encryption :
- AES with 256-bit key length (
aes256gcm16oraes256)
Key Exchange :
- ECDH with NIST P-384 curve (
ecp384) - DH with at least 3072-bit modulus (
modp3072or higher)
Pseudo-Random Function/Integrity Protection :
- SHA-384 (e.g.
prfsha384orsha384if not using AES in GCM mode)
Digital Signatures :
- ECDSA with NIST P-384 curve
- RSA with at least 3072-bit modulus
Suite B obsolète de la NSA
strongSwan ne fournit pas de mots-clés directs pour configurer les suites cryptographiques obsolètes de la Suite B définies dans la RFC 6379 dont le statut a été défini sur historique en 2018. Mais les algorithmes de la Suite B peuvent être configurés explicitement à l'aide des chaînes de proposition suivantes (si prises en charge par les plugins et l'implémentation IPsec) :
ESP Integrity Protection and Confidentiality
Suite-B-GCM-128 :
- IKE:
aes128gcm16-prfsha256-ecp256 - ESP:
aes128gcm16-ecp256
Suite-B-GCM-256 :
- IKE:
aes256gcm16-prfsha384-ecp384 - ESP:
aes256gcm16-ecp384
ESP Integrity Protection Only
Suite-B-GMAC-128 :
- IKE:
aes128-sha256-ecp256 - ESP:
aes128gmac-ecp256
Suite-B-GMAC-256 :
- IKE:
aes256-sha384-ecp384 - ESP:
aes256gmac-ecp384
- RFC 6379 : Suite B Cryptographic Suites for IPsec
- ipsec.conf - General Connection Parameters : https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
- strongSwan IKEv2 Cipher Suites : https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html
- strongSwan VPN Client for Android : https://docs.strongswan.org/docs/5.9/os/androidVpnClient.html
- Google Cloud VPN : Algorithmes de chiffrement IKE compatibles
- Thibaut Probst Blog : Décortiquer IPsec avec strongSwan sur Debian
#crypto #cryptography #encryption #postquantum
- RFC 9242 : Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)
- RFC 9370 : Multiple Key Exchanges in IKEv2
