Centre de confiance

Sécurité

Les protections sont décrites avec leurs primitives réelles, leurs dépendances et leurs limites.

Primitives réellement utilisées

Le canal entre le PC et un appareil associé repose sur les primitives de la bibliothèque standard .NET 8, sans dépendance cryptographique tierce dans le SDK partagé.

Identité d’appareil et signatures
ECDSA P-256, utilisée pour les preuves d’appairage et les jetons de confiance.
Échange de clé
ECDH P-256 éphémère, une paire neuve à chaque appairage et à chaque reprise de session.
Dérivation de clé
HKDF-SHA256, avec deux clés directionnelles distinctes PC → téléphone et téléphone → PC.
Chiffrement authentifié
AES-256-GCM, avec un nonce aléatoire par message.
Anti-rejeu
Un compteur strictement croissant transmis comme donnée associée ; tout message rejoué ou réordonné est rejeté.
Protection au repos
Clé privée chiffrée par DPAPI sur le PC, et par le stockage sécurisé d’Android sur le téléphone.

Ce qui n’est jamais transmis

Aucun secret d’authentification

Ni le mot de passe ni les secrets du moteur d’identifiants ne circulent dans le protocole d’appairage.

Aucune donnée biométrique

La biométrie reste sur le téléphone. ScreenShield21 reçoit une confirmation d’identité, jamais l’empreinte ou le visage.

Aucune portée extensible

Les capacités d’un appareil associé sont plafonnées à quatre permissions ; le protocole ne porte structurellement aucun champ de secret.

Limite assumée : pas de TLS sur le canal local

Le Companion natif utilise le canal local HTTP, avec des messages applicatifs chiffrés par AES-256-GCM après l’appairage. Le Web Companion utilise un tunnel HTTPS qui rend le transport du serveur local accessible via un relais et nécessite Internet. Le relais ne valide aucune preuve et ne décide d’aucun déverrouillage : cette autorité reste le PC. Le canal local direct ne dispose pas de TLS dans cette version.

Aucune de ces mesures ne rend un système inviolable. Elles réduisent des risques précis, et leurs limites sont écrites ici volontairement.