BenchTLSESP32

Banc de mesure des capacites cryptographiques et reseau securisees d'un ESP32, ecrit directement sur ESP-IDF (pas de couche Arduino).

Il repond a une question precise : qu'est-ce qu'un ESP32 sait reellement soutenir en chiffrement, en TLS, en 802.1X et en SNMPv3, et a quel prix ?

Materiel du banc de reference :

L'ESP32 de premiere generation accelere en materiel AES, SHA et l'arithmetique multiprecision de RSA. Il n'accelere pas les courbes elliptiques, contrairement aux ESP32-S3, C3 et H2.

Consequence contre-intuitive : sur cette puce, une signature ECDSA P-256 n'est pas forcement plus rapide qu'une signature RSA-2048, et une poignee de main ECDHE coute cher parce que la multiplication scalaire reste entierement logicielle. Le banc rend ce compromis chiffrable, courbe par courbe et suite par suite.

C'est ce qui doit guider le choix d'une suite TLS et d'un type de certificat client sur ce materiel — pas les intuitions issues des serveurs.

ESP32-D0WDQ6 a 239,99 MHz, ESP-IDF v5.5.5, mbedTLS 3.6.6, accelerateurs AES, SHA et MPI actifs. Medianes.

Verifier une signature RSA-2048 est ici 290 fois plus rapide que verifier une signature ECDSA P-256. L'exponentiation publique RSA tombe sur le multiplieur materiel ; la verification ECDSA, elle, demande deux multiplications scalaires entierement logicielles.

Consequence directe : sur cette puce, un certificat serveur RSA se valide bien plus vite qu'un certificat ECDSA, a rebours de ce qu'on observe sur un serveur. Cote signature en revanche, ECDSA P-256 et RSA-2048 se valent.

Deux enseignements inattendus. D'abord, le Diffie-Hellman classique sur 2048 bits reste competitif face a ECDH P-256 : il beneficie du multiplieur materiel que les courbes n'utilisent pas. Ensuite, Brainpool P-256 est 18 fois plus lent que NIST P-256 a taille de cle identique : mbedTLS applique aux courbes NIST une reduction modulaire specialisee dont Brainpool ne beneficie pas.

SHA-384 et SHA-512 depassent SHA-256 : l'accelerateur traite des blocs de 128 octets au lieu de 64. En revanche SHA-224 s'effondre a un cinquieme de SHA-256 — le materiel ne le prend pas en charge, il retombe en logiciel. Un detail de configuration lourd de consequences pour SNMPv3, dont un profil normalise repose precisement sur SHA-224.

ChaCha20-Poly1305 depasse AES-GCM de 63 %, malgre l'accelerateur AES : dans GCM, c'est la multiplication dans le corps de Galois qui domine, et elle s'execute en logiciel. La taille de cle AES (128, 192 ou 256) n'a, elle, aucun effet mesurable — le materiel absorbe les tours supplementaires.

C'est la contre-epreuve directe du resultat precedent, sans TLS ni reseau.

Valider une chaine ECDSA coute 127 fois plus cher qu'une chaine RSA sur cette puce. Un niveau de chaine RSA supplementaire ne coute qu'une milliseconde, et la verification du nom d'hote est gratuite (0,03 ms) : rien ne justifie de la desactiver.

Toute connexion a un reseau WPA2-PSK coute 657 ms de calcul pur, avant meme la poignee de main a quatre voies : c'est la derivation de la cle maitresse a partir de la phrase secrete, imposee par IEEE 802.11i. Sur les 2 a 3 secondes d'une association WPA2, une part notable vient de la.

Un equipement qui se reconnecte souvent au meme reseau a tout interet a conserver la cle derivee plutot qu'a la recalculer — c'est exactement ce que fait CONFIG_ESP_WIFI_STA_DISCONNECTED_PM et ce que permet la reconnexion rapide 802.11r.

A l'oppose, HKDF ne coute rien (0,3 ms) : la hierarchie de cles de TLS 1.3 n'est pas un poste de cout.

Noter encore une fois l'inversion : PBKDF2-SHA512 est plus rapide que PBKDF2-SHA256 a nombre d'iterations egal, l'accelerateur traitant des blocs de 128 octets au lieu de 64.

Trois enseignements. La taille de cle AES reste sans effet : 128, 192 et 256 bits donnent le meme debit en GCM, le materiel absorbant les tours supplementaires — l'ecart n'apparait qu'en CCM et XTS, ou une partie du travail est logicielle.

XTS plafonne a 1,8 Mio/s, six fois moins qu'AES-CBC : le mode demande deux operations AES par bloc plus une multiplication dans un corps de Galois. C'est l'ordre de grandeur du surcout a attendre du chiffrement de flash de l'ESP32 sur les lectures non mises en cache.

HMAC bat CMAC d'un facteur 3,5 (0,168 ms contre 0,587 sur 1 Kio), bien que CMAC s'appuie sur l'accelerateur AES : le mode CMAC enchaine les blocs sans pouvoir les traiter d'un seul appel, et repaie le cout fixe du peripherique a chaque bloc. Pour un besoin d'integrite pure, HMAC-SHA-256 est le bon choix sur cette puce.

La derivation de cle est plus de mille cinq cents fois plus couteuse que le traitement d'un message. Un agent qui derive ses cles a chaque demarrage paie une demi-seconde par protocole ; un agent qui les conserve ne paie plus rien. C'est la seule optimisation qui compte reellement dans USM.

Une fois les cles en place, l'ESP32 traite environ 2 500 messages SNMPv3 par seconde en SHA-256 avec AES-128, chiffrement et authentification compris.

Premier constat surprenant : MD5 derive 3,6 fois plus vite que SHA-256, alors que SHA-256 beneficie de l'accelerateur materiel et pas MD5.

L'explication tient au decoupage. Le RFC 3414 fait condenser le megaoctet par blocs de 64 octets, soit 16 384 appels successifs. L'accelerateur materiel a un cout fixe par appel — verrouillage du peripherique, transfert des registres — qui domine completement a cette granularite. Le banc mesure donc la meme derivation soumise par blocs de 4 Kio, qui produit exactement la meme cle :

La lecture est nette : seuls les algorithmes reellement pris en charge par le materiel gagnent au regroupement. MD5 et SHA-224 ne bougent pas — ce qui confirme par la mesure que l'accelerateur SHA de l'ESP32 ne traite pas SHA-224, alors qu'il traite SHA-1, SHA-256, SHA-384 et SHA-512.

Consequence pratique : une implementation SNMPv3 embarquee qui suit litteralement le decoupage du code de reference laisse un facteur quatre sur la table, pour une modification de quelques lignes et sans le moindre ecart a la norme.

Mesures sur WiFi 2,4 GHz, serveur de test sur le meme reseau local.

Trois lectures :

Le choix du certificat serveur pese lourd. Une chaine ECDSA coute 806 ms la ou une chaine RSA en coute 370 : plus du double, en TLS 1.2 comme en 1.3. C'est la traduction directe des 258 ms de verification ECDSA mesures plus haut. Sur cette puce, une PKI RSA est le bon choix.

La reprise TLS 1.2 est le meilleur levier disponible : 32 ms contre 370, soit un facteur onze. Mais la reprise TLS 1.3 ne rapporte que 270 ms, huit fois moins efficace. La raison est structurelle : TLS 1.3 combine par defaut le secret pre-partage avec un echange ECDHE frais, pour garantir la confidentialite persistante — et l'ESP32 repaie donc integralement la multiplication scalaire que la reprise 1.2 evitait. Un equipement qui rouvre souvent ses sessions gagne ici a rester en TLS 1.2.

La verification de chaine ne coute que 55 ms (370 contre 315 sans verification) : la desactiver ne se justifie jamais.

Le contraste sur les 64 Kio resume tout le banc : maintenir la connexion divise le temps par onze et le debit est multiplie par dix. Une fois la session ouverte, l'ESP32 soutient sans peine plus de 1 Mio/s en TLS et pres de 450 journaux par seconde. C'est l'etablissement qui coute, pas le transport.

Ces chiffres sont reproductibles avec crypto, snmp, puis la campagne reseau :

.\tools\run_network_bench.ps1 -Port COM16

• ESP-IDF v5.5.x installe (~/esp/esp-idf sur ce poste)
• Python 3.9 ou plus recent
• OpenSSL (celui de Git for Windows convient)

A faire avant la premiere compilation : les certificats sont embarques dans le binaire, leur absence fait echouer l'edition de liens.

.\pki\gen_pki.ps1                      # detecte l'IP du PC
.\pki\gen_pki.ps1 -ServerIp 192.168.1.50   # ou explicitement

Le script produit une chaine RSA a deux niveaux, une chaine ECDSA, les certificats serveur, client, RADIUS, et les cles nues de mesure. L'adresse IP donnee est inscrite dans le SAN du certificat serveur : si l'IP du PC change, il faut relancer le script puis recompiler.

Les cles privees des autorites restent dans pki/out et ne sont jamais embarquees.

. .\tools\idf_env.ps1
idf.py menuconfig      # menu "BenchTLSESP32 - configuration du banc"

Au minimum : le SSID et le mot de passe WPA2, et l'adresse du PC.

idf.py build
idf.py -p COM16 flash monitor

python .\tools\bench_servers.py

Un seul processus fournit les quatre services : echo TLS sur chaine RSA (8443) et sur chaine ECDSA (8445), HTTPS (8444), collecteur syslog (6514).

Pensez a autoriser ces ports dans le pare-feu Windows, sans quoi les mesures reseau echoueront toutes sans message explicite cote ESP32 :

# PowerShell administrateur
New-NetFirewallRule -DisplayName "BenchTLSESP32 - serveurs de test" `
  -Direction Inbound -Action Allow -Protocol TCP `
  -LocalPort 8443,8444,8445,6514 -RemoteAddress 192.168.1.0/24 -Profile Any

La campagne reseau complete tient ensuite en une commande, qui demarre les serveurs, pilote la carte et les arrete :

.\tools\run_network_bench.ps1 -Port COM16

Le serveur RADIUS tourne dans Docker et se valide sans WiFi :

cd tools\freeradius
docker compose up -d
.\test_eap.ps1              # EAP-TLS, TTLS/MSCHAPv2, TTLS/PAP, PEAP/MSCHAPv2

test_eap.ps1 rejoue une conversation 802.1X complete contre le serveur avec eapol_test, en basculant default_eap_type entre chaque famille de methode puis en restaurant la configuration. Les quatre scenarios doivent passer avant de brancher un point d'acces : cela separe proprement un probleme de configuration RADIUS d'un probleme de lien radio.

Il reste ensuite a fournir un point d'acces annoncant du WPA-Enterprise et pointant vers le poste. Voir tools/freeradius/README.md.

Le firmware demarre sur une console. Ce choix est deliberé : relancer une mesure sans redemarrer evite de repayer l'association WiFi et la synchronisation d'horloge.

bench> help                    liste des commandes

bench> crypto                  toutes les mesures locales, sans reseau
bench> crypto hash             seulement les fonctions de hachage
bench> crypto asym keygen      signatures + generation de cles (tres long)

bench> wifi connect            association WPA2 puis mise a l'heure
bench> wifi connect peap       association 802.1X en PEAP
bench> wifi scan               balayage actif et passif
bench> wifi assoc              temps d'association de tous les modes configures

bench> tls                     poignees de main, mTLS, reprise, debit
bench> syslog                  syslog sur TLS mutuel
bench> https                   requetes HTTPS
bench> snmp                    USM complet
bench> snmp agent              demarre l'agent SNMPv3 embarque

bench> all                     suite complete
bench> report                  tableau de synthese
bench> report crypto.rsa       un seul groupe
bench> export json             resultats exploitables hors ligne
bench> reset                   vide le registre

Apres wifi connect puis snmp agent, depuis le PC :

snmpget -v3 -l authPriv -u benchuser \
        -a SHA-256 -A benchAuthPassword \
        -x AES     -X benchPrivPassword \
        <ip-esp32> 1.3.6.1.2.1.1.1.0

snmpwalk -v3 -l authPriv -u benchuser \
         -a SHA-256 -A benchAuthPassword \
         -x AES     -X benchPrivPassword \
         <ip-esp32> 1.3.6.1.2.1.1

C'est la verification d'interoperabilite de l'implementation USM : si net-snmp accepte les reponses, la derivation de cles, l'authentification et le chiffrement sont conformes.

Chaque ligne rapporte la mediane, la moyenne, le p95, le debit et le nombre d'iterations.

La mediane et le p95 sont donnes ensemble a dessein :

• la mediane donne le cout intrinseque de l'algorithme ;
• le p95 donne le cout observe quand la pile WiFi et l'ordonnanceur preemptent le calcul.

L'ecart entre les deux est l'information utile pour dimensionner un equipement reel. Les debits sont derives de la mediane, non de la moyenne : une seule interruption WiFi suffirait a fausser cette derniere.

Un cas qui n'a pas pu s'executer apparait quand meme, avec son motif. Une ligne absente se lirait a tort comme un succes.

Les chiffres AES, SHA et RSA n'ont de sens qu'accompagnes de l'etat des accelerateurs, rappele dans l'en-tete de chaque rapport. Pour mesurer le gain reel :

.\tools\bench_hw_vs_sw.ps1

Le script construit et flashe successivement les deux configurations. La comparaison des deux exports donne le facteur d'acceleration par algorithme.

BenchTLSESP32/
├── main/                     orchestrateur, console, configuration Kconfig
├── components/
│   ├── bench_core/           chronometrage, statistiques, restitution
│   ├── bench_certs/          PKI embarquee dans le binaire
│   ├── bench_crypto/         hachage, chiffrement, asymetrique, echange de cles
│   ├── bench_wifi/           association, 802.1X, horloge
│   ├── bench_tls/            poignees de main, mTLS, reprise, debit
│   ├── bench_syslog/         client RFC 5424 / RFC 5425
│   ├── bench_https/          client HTTPS
│   └── bench_snmpv3/         USM, messages ASN.1, agent
├── pki/                      generation de la PKI
└── tools/                    serveurs de test, RADIUS, hostapd, scripts

Le socle de mesure repose sur trois choix :

1. Chaque iteration est chronometree individuellement. Diviser une duree totale par un nombre d'iterations masquerait la dispersion, qui est justement ce qui distingue un microcontroleur d'un serveur.

2. L'horloge de reference est le compteur de cycles CPU, calibre au demarrage plutot que suppose. Il reboucle toutes les ~17,9 s a 240 MHz : le socle bascule alors automatiquement sur esp_timer et le signale.

3. Les mesures s'executent sur une tache epinglee au coeur 1. Le compteur de cycles est propre a chaque coeur ; une migration est detectee et l'echantillon concerne est ramene sur esp_timer.

Elles sont a connaitre avant de citer un chiffre.

Methode EAP negociee. En TTLS et PEAP, c'est le serveur RADIUS qui impose la methode de phase 1 ; le suppliant d'ESP-IDF ne peut pas l'exiger. Les lignes EAP-TTLS/* et PEAP portent sur ce que le firmware a demande, pas necessairement sur ce qui a ete negocie. Pour les distinguer reellement, il faut modifier default_eap_type cote serveur entre deux passes : voir tools/freeradius/README.md. EAP-TLS fait exception et reste fiable sans precaution.

Verification du nom d'hote en HTTPS. Le banc s'adresse au serveur par adresse IP. mbedTLS ne confronte pas une adresse aux extensions SAN de type iPAddress, et esp_http_client n'offre pas de moyen d'imposer un nom attendu different de la cible : la verification du nom est donc levee pour ces mesures. La validation de chaine contre l'autorite du banc reste pleinement active — c'est elle qui porte le sujet « CA personnalisee ». Le module TLS, lui, verifie bien le nom, en le passant explicitement a esp-tls.

Controle temporel en 802.1X. Au premier demarrage l'ESP32 est en 1970 et rejetterait le certificat du serveur RADIUS avant d'avoir pu joindre un serveur NTP. Le controle de periode de validite est donc desactive pour la seule phase 802.1X ; la validation de chaine reste active.

Decoupage du temps d'association. ESP-IDF n'expose pas d'evenement entre l'authentification et l'association : le premier segment mesure ne peut pas etre decompose plus finement sans instrumenter la pile. La comparaison entre modes reste valide, seul le contenu de ce segment changeant.

Generation de cles RSA. Sa duree depend du nombre de candidats premiers rejetes et varie d'un facteur superieur a cinq d'un tirage a l'autre. Sur peu d'echantillons, l'ecart entre le minimum et le maximum est plus parlant que la mediane.

Le mode « sans verification » de TLS n'existe que pour chiffrer le cout de la validation de chaine. Il ne doit jamais servir de reference de performance.

Le reseau fait partie de la mesure. Les chiffres TLS, syslog et HTTPS incluent la latence du lien WiFi et la charge du PC. Le RSSI est rapporte par wifi status : deux campagnes menees a des puissances recues differentes ne sont pas comparables.

Ce depot contient une PKI de test dont les cles privees sont generees en clair et dont les mots de passe sont publies. Rien ici ne doit etre reutilise ailleurs qu'entre un ESP32 et un PC sur un reseau de test isole.

.gitignore exclut pki/out et les fichiers PEM embarques : les cles generees ne doivent pas etre versionnees.