Préalables à la construction d'un protocole de communication sécurisé en C

Avant de plonger dans l'implémentation, assurez-vous que votre environnement de développement comprend un compilateur C (GCC ou Clang), une connaissance de base de la programmation des sockets, et la bibliothèque OpenSSL installée. OpenSSL fournit des implémentations robustes d'algorithmes cryptographiques, ce qui en fait le choix standard pour les communications sécurisées dans C. Sur Linux, installez OpenSSL via votre gestionnaire de paquets (par exemple ).

Comprendre les blocs de construction cryptographiques

Un protocole de communication sécurisé repose sur trois piliers : la confidentialité, l'intégrité et l'authentification. La confidentialité est assurée par le chiffrement, garantissant que seul le destinataire prévu peut lire le message. L'intégrité garantit que les données n'ont pas été modifiées en transit. L'authentification vérifie l'identité des parties communicantes.

Chiffrement symétrique avec AES

Le standard de chiffrement avancé (AES) est le chiffrement symétrique le plus utilisé. Il fonctionne sur des blocs 128 bits et prend en charge des tailles de clés de 128, 192 ou 256 bits. Pour des communications sécurisées, préférez AES en mode Galois/Counter (GCM), qui fournit à la fois confidentialité et intégrité en une seule opération.

Échange de clés avec Diffie–Hellman

Pour s'entendre en toute sécurité sur un secret partagé sur un canal non sécurisé, utilisez l'échange de clés Diffie–Hellman (DH).Les deux parties génèrent des clés privées et échangent des paramètres publics, puis calculent un secret commun. Diffie–Hellman est vulnérable aux attaques de l'homme dans le milieu si elles ne sont pas authentifiées, vous pouvez donc l'étendre ultérieurement avec des signatures numériques ou des clés pré-partagées.

Intégrité et authentification des messages avec HMAC

Pour vérifier qu'un message n'a pas été altéré, ajoutez un code d'authentification des messages (HMAC) basé sur Hash à chaque chiffrement chiffré. HMAC utilise une clé secrète partagée et une fonction de hachage cryptographique (p. ex. SHA‐256). Le récepteur recompute le HMAC sur les données reçues et le compare à la valeur transmise. Cette étape empêche les attaques de rejouer et de manipuler.

Configuration d'OpenSSL dans votre projet C

OpenSSL nécessite une initialisation minutieuse. Inclure les en-têtes et les appels nécessaires et au début de votre programme. Pour la gestion des erreurs, utilisez et . Lors de la liaison, ajoutez à vos drapeaux compilateurs. Une configuration minimale ressemble à ceci :

#include <openssl/evp.h>
#include <openssl/rand.h>
#include <openssl/err.h>
// Initialize OpenSSL
void init_openssl() {
 SSL_load_error_strings();
 OpenSSL_add_all_algorithms();
}

Construire le calque TCP

Le transport sous-jacent pour votre protocole sera TCP, qui fournit une livraison fiable et ordonnée. Créez un serveur qui écoute les connexions entrantes et un client qui initie la poignée de main. Utilisez les sockets POSIX standard avec , , , du côté serveur, et , du côté client. N'oubliez pas de gérer les erreurs gracieusement et de fermer les descripteurs de fichiers après utilisation.

Exemple de serveur Squelette

int server_fd = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in address;
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(8080);
bind(server_fd, (struct sockaddr*)&address, sizeof(address));
listen(server_fd, 3);
int client_fd = accept(server_fd, (struct sockaddr*)&client_addr, &addr_len);

Exemple client Skeleton

int sock = socket(AF_INET, SOCK_STREAM, 0);
struct sockaddr_in server_addr;
server_addr.sin_family = AF_INET;
server_addr.sin_port = htons(8080);
inet_pton(AF_INET, "127.0.0.1", &server_addr.sin_addr);
connect(sock, (struct sockaddr*)&server_addr, sizeof(server_addr));

Mise en œuvre de l'échange de clés Diffie–Hellman

Après avoir établi la connexion TCP, le client et le serveur effectuent un échange de clés DH. Chaque côté génère une paire de clés DH en utilisant l'API OpenSSL. La clé publique est envoyée sur la socket, et les deux côtés dérivent un secret partagé en utilisant . Pour plus de simplicité, utilisez un groupe principal fixe (par exemple avec des paramètres de . Dans un protocole réel, vous négocieriez le groupe ou utiliseriez des paramètres prédéfinis.

// Generate DH parameters
EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_DH, NULL);
EVP_PKEY_paramgen_init(pctx);
EVP_PKEY_CTX_set_dh_paramgen_prime_len(pctx, 2048);
EVP_PKEY *params = NULL;
EVP_PKEY_paramgen(pctx, &params);

// Generate key pair
EVP_PKEY_CTX *kctx = EVP_PKEY_CTX_new(params, NULL);
EVP_PKEY_keygen_init(kctx);
EVP_PKEY *my_key = NULL;
EVP_PKEY_keygen(kctx, &my_key);

// Export public key to send
unsigned char *pub_key_der = NULL;
int pub_len = i2d_PUBKEY(my_key, &pub_key_der);
send(sock, pub_key_der, pub_len, 0);

À la fin de la réception, le pair importe la clé publique en utilisant , puis tire le secret partagé. Le secret dérivé peut être hashé (p. ex. avec SHA-256) pour produire une clé uniforme pour AES et HMAC.

Cryptage et déchiffrement des messages avec AES‐GCM

Utilisez OpenSSL. avec . Vous avez besoin d'un nonce de 12 octets (IV) et de la clé 256 bits dérivée du secret partagé DH. Le code est produit en morceaux, et après la mise à jour finale, vous récupérez la balise de 16 octets. Envoyez le nonce, le code et l'étiquette ensemble. Le récepteur effectue , définit la balise et déchiffre. Si la vérification de la balise échoue, le message est rejeté.

// Encryption
EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, key, nonce);
unsigned char ciphertext[1024];
int outlen;
EVP_EncryptUpdate(ctx, ciphertext, &outlen, plaintext, len);
int tmplen;
EVP_EncryptFinal_ex(ctx, ciphertext + outlen, &tmplen);
unsigned char tag[16];
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag);

Ajout d'intégrité avec HMAC (ou Tag GCM de levier)

Si vous choisissez de ne pas utiliser AES‐GCM, vous pouvez chiffrer avec AES‐CBC puis calculer un HMAC sur le chiffrement. Utilisez depuis OpenSSL avec SHA‐256. Ajoutez le HMAC après le chiffrement. Le récepteur recalcule et compare. Cette approche nécessite deux touches : une pour le chiffrement, une pour HMAC. Dérivez à la fois du secret partagé en utilisant une fonction de dérivation de clé (KDF) comme HKDF. Cependant, AES‐GCM élimine la nécessité d'un HMAC distinct, réduisant ainsi la complexité et les erreurs potentielles.

La mise en place : un flux de travail complet

  1. Établir une connexion TCP entre le client et le serveur.
  2. Les deux côtés génèrent des paires de clés éphémères Diffie‐Hellman.
  3. Échanger les clés publiques et calculer le secret partagé.
  4. Dérivez une clé AES 256 bits et une clé HMAC 256 bits (ou utilisez la même clé pour GCM).
  5. Le client envoie un nonce (12 octets au hasard) puis le message chiffré AES‐GCM plus la balise. Le serveur déchiffre et vérifie.
  6. Serveur envoie une réponse en utilisant un nouveau nonce (ne réutiliser jamais les nonces avec la même clé).
  7. Les deux côtés peuvent continuer à échanger des messages; pour les longues sessions, rekey périodiquement en utilisant la même poignée de main DH ou un mécanisme de cliquet.

Pratiques exemplaires en matière de sécurité

  • Utiliser des générateurs de nombres aléatoires puissants.Appeler depuis OpenSSL pour générer des clés, des nonces et des clés privées DH. Ne jamais utiliser ou à des fins cryptographiques.
  • Valider toutes les données reçues Vérifier la longueur, les paramètres de clé publique (p. ex., s'assurer que p est prime, g est un générateur) et les étiquettes HMAC avant le traitement.
  • Éviter les clés ou les valeurs par défaut codées en dur. Toujours négocier les clés fraîches par session pour fournir le secret parfait avant.
  • Erreurs de poignée gracieusement. Si le décryptage échoue ou que la vérification HMAC échoue, fermez la connexion et enregistrez l'événement. Ne révèlez pas pourquoi l'échec s'est produit.
  • Gardez à jour les dépendances. Mettez à jour régulièrement OpenSSL pour corriger les vulnérabilités connues. La documentation OpenSSL fournit des conseils sur la déprécation et les meilleures pratiques.
  • Considérer l'utilisation de TLS plutôt qu'un protocole personnalisé. Pour les systèmes de production, s'appuyer sur des protocoles bien testés comme TLS 1.3. Construire un protocole personnalisé à partir de zéro est une question d'erreur et non recommandée à moins d'avoir une expertise cryptographique profonde.

Essais du Protocole

Testez votre implémentation en exécutant client et serveur sur la même machine (localhost) et vérifiez que les messages décryptent correctement. Introduisez des erreurs telles que le chiffrement falsifié ou les nonces invalides pour s'assurer que le protocole les rejette. Utilisez des outils comme Wireshark pour inspecter le trafic réseau brut et confirmer que le texte simple n'est pas visible. Pour les tests unitaires, imitez la couche de socket et testez séparément les primitives cryptographiques.

Conclusion

En mettant à profit les implémentations éprouvées d'OpenSSL, de Diffie-Hellman, d'AES-GCM et de HMAC, vous pouvez créer un système qui assure la confidentialité, l'intégrité et l'authentification. Suivez toujours les meilleures pratiques cryptographiques : utiliser une forte randomité, dériver les clés de session avec un KDF, ne jamais réutiliser les nonces et valider toutes les données de façon approfondie. Pour tout ce qui dépasse un projet d'apprentissage, envisagez d'adopter un protocole standard tel que TLS 1.3, qui a été rigoureusement examiné et déployé à l'échelle. La communication sécurisée est un processus continu d'amélioration; restez informé des menaces émergentes et mettez à jour vos implémentations en conséquence.