Principe : information dans le temps
Un timing channel exploite le fait que les délais entre événements sont observables mais non chiffrables. Même dans une communication entièrement chiffrée (HTTPS, Signal, WireGuard), l'observateur passif peut mesurer les intervalles de temps entre paquets.
En encodant des bits dans ces intervalles — délai court = bit 0, délai long = bit 1 — on crée un canal de communication entièrement transparent au chiffrement. Aucun IDS, aucun DPI ne peut analyser le contenu pour détecter ce canal.
Canal temporel — modulation basique : Bit 0 → délai de t₀ = 50ms entre paquets Bit 1 → délai de t₁ = 100ms entre paquets Séquence pour encoder "A" = 01000001 : Paquet 1 → attendre 100ms (bit 1 → "0") Paquet 2 → attendre 50ms (bit 0 → "1" ... attendre !) ⚠ Convention : souvent inversé pour lisibilité Ici on lit bit = (délai > seuil) ? 1 : 0 Problème : jitter réseau ≈ 5-50ms → Les délais naturels bruitent le signal → Solution : utiliser des délais plus grands (200ms/500ms) ou plusieurs paquets par bit (redondance)
Inter-Packet Delay (IPD)
L'Inter-Packet Delay est la technique la plus simple : on encode un bit dans le délai entre deux paquets consécutifs. Pour que cela passe inaperçu, les délais doivent rester dans la plage normale du protocole utilisé (HTTP keep-alive, WebSocket, etc.).
IPD Encoding (Python pseudo-code) :
import time, socket
T0 = 0.1 # 100ms → bit 0
T1 = 0.2 # 200ms → bit 1
JITTER_TOLERANCE = 0.05 # ±50ms
def send_covert(bits, sock):
for bit in bits:
delay = T1 if bit else T0
time.sleep(delay)
sock.send(b".") # paquet neutre (ou données légitimes)
def receive_covert(sock, n_bits):
bits = []
t_prev = time.time()
for _ in range(n_bits):
sock.recv(1)
t_now = time.time()
delay = t_now - t_prev
bit = 1 if delay > (T0 + T1) / 2 else 0
bits.append(bit)
t_prev = t_now
return bits
Capacité : 1 bit / (T1 + jitter) ≈ 1 bit / 250ms ≈ 4 bits/sJitterBug : frappes clavier modifiées
JitterBug (Shah & Bhatt, 2006) est une technique élaborée qui modifie les délais entre frappes clavier pour encoder un canal secret. Le malware intercepte les événements clavier et ajoute ou retire quelques millisecondes selon le bit à encoder.
L'observateur qui capture le trafic réseau d'une session SSH voit les timestamps des paquets de frappe clavier. Ces timestamps contiennent le message caché. La modification est de quelques ms seulement — imperceptible à l'utilisateur.
JitterBug — Timing de frappes clavier SSH : Session SSH normale : Frappe "h" → paquet envoyé à t=0.000 Frappe "e" → paquet envoyé à t=0.142 (142ms après) Frappe "l" → paquet envoyé à t=0.287 JitterBug activé (bit 0 = frappe arrondie à 150ms, bit 1 = arrondie à 200ms) : Frappe "h" → paquet envoyé à t=0.000 Frappe "e" → paquet envoyé à t=0.150 (+8ms, encode bit 0) Frappe "l" → paquet envoyé à t=0.350 (+63ms, encode bit 1) L'observateur réseau : voit des inter-keystroke delays de 150ms et 200ms → Lit les bits : 0, 1, 0, 1, 0, 0, 0, 1 = 0x41 = "A" Capacité : 1 bit par frappe clavier ≈ quelques bits/seconde
On-Off Keying et modulation de débit
On-Off Keying est une modulation encore plus simple : la présence ou l'absence de trafic pendant une fenêtre temporelle encode les bits. Le débit réseau lui-même devient le signal.
On-Off Keying (OOK) : Bit 0 → pas de paquet pendant T=500ms (silence) Bit 1 → envoi de N paquets pendant T=500ms (burst) Pour encoder "01101" avec T=500ms : 0-500ms : silence (bit 0) 500-1000ms : burst de paquets (bit 1) 1-1500ms : burst de paquets (bit 1) 1500-2000ms : silence (bit 0) 2-2500ms : burst de paquets (bit 1) Variante — modulation de débit : Débit 10 Mbps → bit 0 Débit 50 Mbps → bit 1 → Encoder dans les variations de vitesse d'une vidéo streaming
Détection et contre-mesures
La détection des timing channels est statistiquement plus difficile que les covert channels dans les headers. Les délais inter-paquets naturels suivent des distributions spécifiques (log-normale, exponentielle selon le protocole). Un timing channel crée des distributions artificielles (pics aux délais fixes, manque de variance naturelle).
Transparent au chiffrement
Un timing channel fonctionne même sur du trafic TLS 1.3 ou WireGuard. L'observateur ne déchiffre rien mais lit les timestamps.
Très furtif
Aucun contenu anormal. Seule l'analyse statistique des délais peut le révéler — peu de DPI commerciaux font cette analyse.
Très faible capacité
Quelques bits à quelques dizaines de bits par seconde. Pas adapté au transfert de fichiers volumineux.
Sensible au jitter réseau
Les variations naturelles de latence dégradent le signal. Nécessite redondance ou délais larges (→ capacité encore plus faible).
→ Contre-mesure principale : traffic shaping / timing normalization. Certains routeurs haute sécurité peuvent normaliser les délais inter-paquets à un intervalle régulier, éliminant toute information temporelle cachée (au prix d'une légère augmentation de la latence).
Questions fréquentes
Comment des délais entre paquets peuvent-ils cacher un message ?
Un timing channel encode des bits dans les intervalles de temps entre paquets : intervalle court = bit 0, intervalle long = bit 1. La connexion semble normale (mêmes données, même volume), seul le timing varie. C'est comme envoyer un message Morse en variant les pauses entre vos frappes sur un clavier.
La latence réseau naturelle ne perturbe-t-elle pas le message ?
C'est l'un des défis majeurs. La latence réseau (jitter) varie constamment. Les implémentations robustes utilisent des fenêtres de temps larges (bit 0 = 90-110 ms, bit 1 = 190-210 ms) pour absorber le jitter, au prix d'une faible capacité (quelques bits par seconde typiquement).
Est-ce un vrai risque de sécurité ?
Oui. JitterBug (2006) a démontré qu'on peut exfiltrer 1 bps via le timing des frappes SSH — suffisant pour transmettre des mots de passe en quelques minutes. Des groupes APT sophistiqués utilisent des variantes de timing channels pour exfiltrer des données à travers des firewalls qui bloquent tout trafic non-standard.
Pour un étudiant en cybersécurité, comment l'expérimenter ?
En Python avec le module socket et time.sleep(), on peut implémenter un timing channel basique en quelques dizaines de lignes. L'expérimenter sur un réseau local isolé (deux machines virtuelles) permet de comprendre les limites pratiques (jitter, dérive temporelle). C'est un excellent exercice pour comprendre les canaux cachés.
Comment les entreprises se défendent-elles ?
La défense est difficile : bloquer les timing channels signifie introduire des délais artificiels dans tout le trafic, ce qui dégrade les performances. Les solutions NDR (Network Detection and Response) peuvent détecter des patterns temporels anormaux dans les flux. La prévention par isolation réseau reste plus efficace.
Canaux réseau connexes
Explorez les covert channels dans les headers IP/TCP ou le DNS steganography.