Entrixy — chiffrement de bout en bout

• Confidentialité du contenu. Le serveur ne connaît ni l’adresse de la barrière ni le numéro de téléphone, ni l’adresse du webhook, ni les coordonnées, ni le BSSID Wi-Fi, ni le texte d’accueil.
• Intégrité vérifiable. Toute altération d’un blob sur le serveur casse le déchiffrement (AES-GCM), et le client signale des données corrompues.
• Compatibilité future des clés. Un invité n’accède qu’aux objets qui lui sont accordés. Compromettre une clé invité ne révèle rien des autres.
• La limite de la connaissance nulle. Le serveur voit bien qu’une clé existe, les horodatages d’activité et les identifiants d’objets — il en a besoin pour le routage. Masquer les métadonnées (schémas en oignon) sort du cadre.

Algorithm: AES-256-GCM. Disponible d’origine sur la JVM (via javax.crypto), et pris en charge par l’Android Keystore. Il apporte à la fois confidentialité et authentification.

Format du texte chiffré

v1:<base64url(nonce || ciphertext || tag)>

• v1: — un préfixe de version, pour changer le format plus tard.
• nonce — 12 octets aléatoires, renouvelés à chaque chiffrement.
• ciphertext+tag — tout ce que renvoie Cipher.doFinal ; l’étiquette de 128 bits est incluse.
• base64url sans remplissage — sûr aussi bien dans une adresse que dans du JSON.

Source d’entropie

K_master — la clé maîtresse du propriétaire

• 32 octets aléatoires, générés au premier lancement.
• Stockée dans EncryptedSharedPreferences sous le nom master_key et ne quitte jamais l’appareil en clair.
• Sert uniquement à envelopper K_obj pour le stockage local.

K_obj — la clé de l’objet

• 32 octets aléatoires, générés à la création de chaque objet.
• Stockée localement sous la forme encrypt_k_master(K_obj) sous la clé obj_key_{id}.
• Elle chiffre le JSON de tous les champs sensibles de l’objet (data_cipher sur le serveur).
• La rotation, c’est une nouvelle K_obj_new → rechiffrer data_cipher et tous les lots qui le portaient.

K_guest — la clé du lot invité

• 32 octets aléatoires, générés à la création d’une clé invité.
• Elle chiffre le bundle — un petit JSON {obj_id: K_obj} pour les objets autorisés à l’invité.
• Ce qui parvient au serveur, c’est only bundle_cipher. La puce K_guest lui-même n’est jamais vu par le serveur.
• K_guest parvient à l’invité dans le fragment d’adresse : entrixy.com/key#<user_key><base64url(K_guest)> — un unique bloc de 75 caractères. Le fragment ne part pas au serveur avec la requête HTTP : c’est une garantie de base du navigateur.

Sur l’appareil du propriétaire (EncryptedSharedPreferences)

Sur le serveur

https://entrixy.com/key#<user_key(32)><K_guest_base64url(43)>

• Le fragment est un bloc de 75 caractères : 32 caractères de user_key et 43 caractères de la clé invité.
• user_key — l’identifiant côté serveur. Sans lui, le serveur ne livre pas le lot.
• Le fragment (#...) n’atteint jamais le journal du serveur — c’est une garantie du navigateur.
• La page /key — du JS ordinaire : elle lit location.hash, analyse le bloc et transmet la clé soit à l’application, soit à la version web /app/. Le serveur ne voit jamais la clé.
• Si l’application n’est pas installée, la page copie le lien dans le presse-papiers et vous envoie vers /download/android, d’où l’application récupère la clé toute seule.

Créer un objet

1. Le propriétaire appuie sur Ajouter — cela génère K_obj.
2. Les champs sont empaquetés en JSON et chiffrés avec K_obj → data_cipher.
3. POST /api/number_add avec data_cipher plus le type. Le serveur renvoie un id.
4. Stocké localement : obj_key_{id} = encrypt_k_master(K_obj).

Mettre à jour un objet

Construire le nouveau JSON localement, le chiffrer avec la K_obj → POST /api/number_update. K_obj existante, qui ne change pas.

Créer une clé invité

1. Le propriétaire a choisi [obj1, obj2, obj3]. Cela génère K_guest.
2. Le JSON du lot est assemblé : {obj_ids: [...], obj_keys: {1: K_obj1, ...}, welcome_cipher: ...}.
3. Chiffré avec K_guest → bundle_cipher.
4. POST /api/key_create avec bundle_cipher, obj_ids (en clair — pour la matrice d’accès).
5. Le serveur renvoie user_key.
6. Le propriétaire voit un QR code avec le lien entrixy.com/key#{user_key}{base64url(K_guest)}.

L’invité accepte la clé

1. L’invité ouvre le QR code ou le lien. La page /key reads location.hash et transmet la clé à l’application ou à la version web.
2. Le client demande POST /api/key_bundle.php avec user_key → reçoit bundle_cipher et la liste des obj_ids.
3. Déchiffre le lot avec K_guest→ obtenant {obj_keys, welcome}.
4. K_guest et les déchiffrés obj_keys sont stockés dans EncryptedSharedPreferences du client invité.
5. Ensuite, à chaque appel : GET du chiffré data_cipher de l’objet → déchiffrement avec la obj_key_{id}.

Révoquer une clé invité

Le propriétaire appuie sur Supprimer → POST /api/key_revoke.php → le serveur supprime l’enregistrement de la clé. À la prochaine demande de lot, l’invité est refusé et perd l’accès.

Faire tourner la clé d’un objet

Le propriétaire appuie sur Régénérer la clé dans les réglages de l’objet. Cela génère K_obj_new, et tous les bundle_cipher contenant cet objet sont rechiffrés. Le client ne les connaît pas par cœur, aussi le client du propriétaire reconstruit les lots : il récupère le bundle_cipher de chacune de ses clés, le déchiffre, insère K_obj_newet rechiffre. Les nouveaux blobs partent au serveur en un seul lot.

Losing K_master signifie perdre l’accès à tous les objets et à toutes les clés, d’où la nécessité d’un export.

• Le propriétaire définit une passphrase (au moins 8 caractères).
• KDF: Argon2id (64 Mo de mémoire, 3 itérations, 1 fil) → clé dérivée de 32 octets.
• La clé dérivée chiffre K_master → produisant master_backup_blob.
• Le blob est affiché sous forme de QR code et enregistré dans Téléchargements. On peut l’imprimer et l’enfermer dans un coffre.
• Restauration sur un nouvel appareil : scanner le QR code, saisir la phrase secrète, K_master est récupérée, et le client télécharge à l’avance tous les obj_keys depuis le serveur — ils se trouvent dans le lot des propres clés du propriétaire — et les rechiffre localement.