ZW3B :-: API Client * Contents * Docs by LAB3W.ORJ

Translate this page

Name : BETA-TESTERS

Project name : ZW3B-API-BETA-TESTERS

Authorized. - 200 - Client API Name and Origin Wildcard OK

¿Comment? 'Ou' ¿Que faire?, Internet Protocol Securited

IPSec, Cryptographie, IKEv2, EAP, ESP, protocoles de communication pour la confidentialité des données, pour l'authentification du paquet et de son émetteur, pour l'intégrité des données et pour l'unicité du paquet transmis et reçus.

Author : O.Romain.Jaillet-ramey

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 :

  1. 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 ;
  2. 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 :



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 :


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 :



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 :

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 :

  1. la confidentialité des données par l'utilisation d'un système de chiffrement ;
  2. l'authentification du paquet et de son émetteur (l'adresse source du paquet est celle de l'émetteur) ;
  3. l'intégrité des données (aucune altération volontaire ou non du paquet durant le transport)
  4. 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 :


ESP chiffrement :

Exemples :

Script avec 5 lignes

001proposals = aes256-sha256-x25519
002# strongSwan 5.9.x
003esp_proposals = aes256gcm128-chacha20poly1305-x25519
004# strongSwan 6.0.beta
005esp_proposals = aes256-sha256-x25519-ke1_kyber3-ke2_bike3-ke3_hqc
Retirer les numéros de lignes


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

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

Chiffrement (Algorithme de chiffrement du trafic) :

Compression (Compression du trafic) :

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-----
002362722d4fbff4075853fbe6991689c36
003[...]
004cb488b5dd8ce9733055a3bdc17fb3d2d
005-----END Static key-----
Retirer les numéros de lignes

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 --version
002strongSwan swanctl 6.0.0beta5
003# swanctl --list-algs
004encryption:
005  AES_CBC[openssl]
006  AES_CTR[openssl]
007  AES_ECB[openssl]
008  AES_CFB[openssl]
009  CAMELLIA_CBC[openssl]
010  CAMELLIA_CTR[openssl]
011  CAST_CBC[openssl]
012  BLOWFISH_CBC[openssl]
013  3DES_CBC[openssl]
014  DES_CBC[openssl]
015  DES_ECB[openssl]
016  NULL[openssl]
017integrity:
018  HMAC_MD5_96[openssl]
019  HMAC_MD5_128[openssl]
020  HMAC_SHA1_96[openssl]
021  HMAC_SHA1_128[openssl]
022  HMAC_SHA1_160[openssl]
023  HMAC_SHA2_256_128[openssl]
024  HMAC_SHA2_256_256[openssl]
025  HMAC_SHA2_384_192[openssl]
026  HMAC_SHA2_384_384[openssl]
027  HMAC_SHA2_512_256[openssl]
028  HMAC_SHA2_512_512[openssl]
029  CAMELLIA_XCBC_96[xcbc]
030  AES_XCBC_96[xcbc]
031  AES_CMAC_96[cmac]
032aead:
033  AES_GCM_16[openssl]
034  AES_GCM_12[openssl]
035  AES_GCM_8[openssl]
036  AES_CCM_16[openssl]
037  AES_CCM_12[openssl]
038  AES_CCM_8[openssl]
039  CHACHA20_POLY1305[openssl]
040hasher:
041  HASH_SHA1[openssl]
042  HASH_MD5[openssl]
043  HASH_MD4[openssl]
044  HASH_SHA2_224[openssl]
045  HASH_SHA2_256[openssl]
046  HASH_SHA2_384[openssl]
047  HASH_SHA2_512[openssl]
048  HASH_SHA3_224[openssl]
049  HASH_SHA3_256[openssl]
050  HASH_SHA3_384[openssl]
051  HASH_SHA3_512[openssl]
052  HASH_IDENTITY[openssl]
053prf:
054  PRF_KEYED_SHA1[openssl]
055  PRF_HMAC_MD5[openssl]
056  PRF_HMAC_SHA1[openssl]
057  PRF_HMAC_SHA2_256[openssl]
058  PRF_HMAC_SHA2_384[openssl]
059  PRF_HMAC_SHA2_512[openssl]
060  PRF_AES128_XCBC[xcbc]
061  PRF_CAMELLIA128_XCBC[xcbc]
062  PRF_AES128_CMAC[cmac]
063xof:
064  XOF_SHAKE128[openssl]
065  XOF_SHAKE256[openssl]
066kdf:
067  KDF_PRF[openssl]
068  KDF_PRF_PLUS[openssl]
069drbg:
070  DRBG_CTR_AES256[drbg]
071  DRBG_CTR_AES128[drbg]
072  DRBG_CTR_AES192[drbg]
073  DRBG_HMAC_SHA1[drbg]
074  DRBG_HMAC_SHA256[drbg]
075  DRBG_HMAC_SHA384[drbg]
076  DRBG_HMAC_SHA512[drbg]
077ke:
078  MODP_3072[openssl]
079  MODP_4096[openssl]
080  MODP_6144[openssl]
081  MODP_8192[openssl]
082  MODP_2048[openssl]
083  MODP_2048_224[openssl]
084  MODP_2048_256[openssl]
085  MODP_1536[openssl]
086  MODP_1024[openssl]
087  MODP_1024_160[openssl]
088  MODP_768[openssl]
089  MODP_CUSTOM[openssl]
090  ECP_256[openssl]
091  ECP_384[openssl]
092  ECP_521[openssl]
093  ECP_224[openssl]
094  ECP_192[openssl]
095  ECP_256_BP[openssl]
096  ECP_384_BP[openssl]
097  ECP_512_BP[openssl]
098  ECP_224_BP[openssl]
099  CURVE_25519[openssl]
100  CURVE_448[openssl]
101  FRODO_SHAKE_L1[frodo]
102  FRODO_SHAKE_L3[frodo]
103  FRODO_SHAKE_L5[frodo]
104  FRODO_AES_L1[frodo]
105  FRODO_AES_L3[frodo]
106  FRODO_AES_L5[frodo]
107  KYBER_L1[oqs]
108  KYBER_L3[oqs]
109  KYBER_L5[oqs]
110  BIKE_L1[oqs]
111  BIKE_L3[oqs]
112  BIKE_L5[oqs]
113  HQC_L1[oqs]
114  HQC_L3[oqs]
115  HQC_L5[oqs]
116rng:
117  RNG_WEAK[openssl]
118  RNG_STRONG[random]
119  RNG_TRUE[random]
120nonce-gen:
121  NONCE_GEN[nonce]
Retirer les numéros de lignes

Bonne encryption.

Informations complémentaires :



Bonne journée, Romain.



Notes : -> Mes tests de configuration (j’ai rien de mieux pour le moment)