[Medboy224]

Lot WP-D.2 du plan J6d, première partie : le protocole par BLE de la bible §6.6, dans le cœur, sans radio ni API. La partie cryptographique se relit ainsi seule ; l'API (internal/cabi, pair_ble sur TLS, l'écran) suit dans une seconde PR.

Ce qu'il y a

pkg/pairing/ble.go, deux côtés : BLEResponder (l'appareil touché, un BLEConn par connexion GATT) et BLEClient (celui qui touche). La plateforme ne fera que porter les octets.

• Format : version ‖ type ‖ lv_cat(champs), 512 octets au plus. Une autre version, un champ de taille fausse, de trop ou de moins, une longueur pas sous sa forme la plus courte : refuse.
• Reconnaissance : défi frais ; réponse avec toujours 16 étiquettes dans un ordre aléatoire (places libres aléatoires), le suffixe du nom générique et le défi du répondant.
• Appareil de confiance mutuelle : clés HKDF-SHA-256(K_AB, c_I ‖ c_R, info ‖ fp_I ‖ fp_R) ; l'étiquette désigne la paire, le déchiffrement authentifie. Un côté qui a oublié l'autre n'a plus la clé (PAIR-09).
• Appareil inconnu : CPace avec sid = n_I ‖ n_R et un CI sans empreinte ; les empreintes passent chiffrées après la confirmation, sous HKDF(ISK). Le même PIN que TLS : mêmes essais, délais, PIN factice et arrêt.
• Chiffrement : AES-256-GCM, une clé par sens, nonce compté et non transmis, AD = version ‖ type.
• Qui crée le réseau (Creator), contrôle du réseau reçu, et BLEAuthenticated : les empreintes que BLE a authentifiées, acceptées une fois sur TLS dans les 2 minutes (pour pair_ble, à venir).
• Limites : une seule demande de PIN à l'écran ; « Refuser » (RefusePIN) ; une connexion perdue sans que la plateforme le voie ne garde pas l'écran au-delà de la vie d'un PIN ; 4 Kio lus par connexion ; défi valable 60 s.

pkg/pake gagne seulement Session.Key(info, n) : HKDF-SHA-256 sur l'ISK, comme le recommande le brouillon (§4, §10.3). C'est la seule modification du code relu par G4, et le dossier le dit.

Tests

16 tests dans pkg/pairing/ble_test.go, un dans pkg/pake :

• reconnaissance et demande entre appareils de confiance ; refus quand un côté a oublié l'autre ;
• 16 étiquettes, neuves à chaque défi, avec 0, 1 ou 17 appareils de confiance ;
• rejeu refusé, dans un autre échange et après la minute du défi ;
• PIN : appairage, 3 mauvais PIN qui détruisent le PIN, PIN factice indiscernable ;
• compteur partagé : 2 mauvais PIN sur TLS et 1 par BLE détruisent le PIN ;
• relais qui change un nonce, messages modifiés, coupés, allongés, d'un autre type ;
• aucune empreinte, aucun nom ni mot de passe de réseau en clair ;
• une demande de PIN à la fois, « Refuser », connexion perdue.

FuzzBLEReceive : environ 1,5 million d'exécutions en 60 s, sans défaut. go test ./... passe.

Docs

• Bible : statuts de BLE-01 à BLE-11 (ce qui est dans le cœur, ce qui reste à l'API et aux plateformes).
• Dossier G4 : le code, la modification de pkg/pake, le tableau des tests BLE.
• Plan J6d : WP-D.2 en deux PR.

🤖 Generated with Claude Code