Sécurité des données de santé

Architecture cryptographique de la synchronisation locale entre postes de cabinet médical. Document technique complet — chiffrement de bout en bout, sans compromis.

Aucune donnée patient ne transite par nos serveurs
Chiffrement Noise KK — même framework que Signal et WireGuard
Certificats signés par une CA intégrée, vérifiables hors ligne
Forward secrecy sur chaque session
Architecture auditée et formellement vérifiée
Conforme RGPD Art. 32 et aligné ISO 27001

Résumé

Ocureo est une application desktop pour orthoptistes qui synchronise les dossiers patients entre postes de travail sur un réseau local, sans faire transiter aucune donnée clinique par un serveur externe. Ce document décrit l’architecture cryptographique qui sécurise cette synchronisation. La conception combine trois composants établis dans une configuration originale : (1) le Noise Protocol Framework [1], pattern KK, pour le chiffrement de session authentifié ; (2) une Autorité de Certification (CA) intégrée hébergée sur le backend SaaS pour la certification d’identité des postes ; (3) un protocole d’appairage (pairing) par Short Authentication String (SAS), inspiré de ZRTP [27] et du Bluetooth Secure Simple Pairing, pour la vérification hors bande. L’architecture adopte un environnement LAN zero trust conformément à NIST SP 800-207 [7] et vise la conformité avec l’article 32 du RGPD et les contrôles de l’Annexe A de l’ISO/IEC 27001:2022. Au-delà de la couche cryptographique, le système repose sur un modèle CRDT custom (HLC + LWW) pour la convergence des données, un protocole de transfert de fichiers avec vérification SHA-256, et un mécanisme de verrouillage distribué pour la coordination des accès concurrents. La conformité de l’implémentation est validée contre les vecteurs de test de référence cacophony. Les propriétés de sécurité du pattern Noise KK ont été formellement vérifiées par des travaux académiques indépendants [11][12][13][14].

Table des matières

Modèle de menace
Vue d’ensemble de l’architecture
Identité des postes et gestion des clés
Autorité de Certification intégrée
Protocole d’appairage
Chiffrement de session : Noise KK
Révocation et cycle de vie des certificats
Synchronisation des données
Synchronisation des fichiers
Verrouillage distribué
Isolation sauvegarde/restauration
Périmètre des données : ce que voit le serveur
Conformité réglementaire
Validation
Limites connues
État de l’art
Références

1. Modèle de menace

1.1 Actifs protégés

Actif	Classification	Base réglementaire
Dossiers patients (bilans, examens)	RGPD Art. 9 — catégorie spéciale (données de santé)	RGPD Art. 32, Art. 5.1.f
Intégrité des échanges (absence de falsification)	Intégrité	RGPD Art. 5.1.f
Disponibilité de la synchronisation	Disponibilité	Continuité d’activité

1.2 Modèle d’attaquant

Nous adoptons un modèle Dolev-Yao restreint au segment LAN. L’attaquant :

Peut observer, intercepter, modifier, supprimer, rejouer et injecter tout message sur le réseau local (ex. : WiFi compromis, ARP spoofing, équipement tiers sur réseau partagé).
Peut énumérer les postes annoncés via la découverte multicast (NSD/Bonjour).
Ne peut pas compromettre le serveur backend (considéré comme de confiance pour les opérations CA — voir §4.3 pour la discussion de cette hypothèse).
Ne peut pas obtenir un accès physique aux postes enregistrés.
Ne peut pas casser les primitives cryptographiques sous-jacentes (hypothèse standard).

Ce modèle reflète la surface d’attaque réaliste d’un cabinet médical : le WiFi de la salle d’attente est partagé, des prestataires de maintenance peuvent connecter des équipements, et le matériel réseau grand public n’offre aucune garantie d’isolation.

1.3 Hypothèses de confiance

Entité	Niveau de confiance	Justification
Backend Dokitek	Confiance pour les opérations d’identité (CA)	Comparable à une CA TLS ; n’accède pas aux données cliniques
Stockage sécurisé OS (Keychain/DPAPI)	Confiance pour le matériel cryptographique	Fourni par la plateforme, avec support matériel si disponible
Administrateur du cabinet	Confiance pour les décisions d’enrôlement	Vérification visuelle du SAS lors de l’appairage
Infrastructure LAN	Non fiable	Zero trust per NIST SP 800-207 [7]

1.4 Objectifs de sécurité

Propriété	Mécanisme	Base formelle
Confidentialité	Chiffrement de session Noise KK (AEAD ChaCha20-Poly1305)	Prouvé dans [11][12][13]
Authentification mutuelle	Authentification par clé statique dans le pattern KK + certificats signés par la CA	Propriété Noise KK [1]
Forward secrecy	Clés DH éphémères par session	Propriété Noise KK, prouvé dans [14]
Intégrité	Tag d’authentification AEAD sur chaque message	RFC 8439 [4]
Anti-replay	Compteurs de nonce séquentiels dans le transport Noise	Noise spec §5 [1]
Résistance au MITM (appairage)	SAS dérivé des hachés de clés publiques	Channel binding, cf. ZRTP [27]

2. Vue d’ensemble de l’architecture

2.1 Pile protocolaire

┌─────────────────────────────────────────┐
│         Couche applicative              │
│   ├── Sync données (CRDT, Knowledge    │
│   │   Vector — §8)                      │
│   ├── Sync fichiers (SHA-256,           │
│   │   transfert par chunks — §9)        │
│   ├── Protocole de verrouillage         │
│   │   (pessimiste, HLC — §10)           │
├─────────────────────────────────────────┤
│         Session Noise KK                │
│   (chiffrement authentifié, PFS)        │
├─────────────────────────────────────────┤
│         Transport WebSocket             │
│   (encadrement, bidirectionnel)         │
├─────────────────────────────────────────┤
│         TCP                             │
│   (livraison fiable)                    │
├─────────────────────────────────────────┤
│         Découverte NSD / Bonjour        │
│   (DNS-SD, mDNS, zero-conf)             │
└─────────────────────────────────────────┘

2.2 Séparation fonctionnelle

L’architecture impose une séparation stricte entre trois plans fonctionnels :

Plan	Où il s’exécute	Accès Internet requis
Plan de contrôle — appairage, signature de certificats, émission de CRL	Backend (Dokitek)	Oui (enrôlement uniquement)
Plan de données — synchronisation des dossiers patients et des fichiers	LAN (pair-à-pair)	Non
Plan de coordination — verrouillage distribué des ressources, réconciliation par heartbeat	LAN (pair-à-pair)	Non

Après l’appairage initial, les postes communiquent exclusivement sur le réseau local. Le backend n’est ni impliqué ni informé des échanges de données ou de coordination. Une coupure Internet n’interrompt pas la synchronisation entre les postes déjà enrôlés.

3. Identité des postes et gestion des clés

3.1 Génération des clés

Au premier démarrage, chaque poste génère deux paires de clés indépendantes :

Paire de clés	Algorithme	Usage	Standard
Clé de signature	Ed25519	Preuve d’identité, demandes de certificat	RFC 8032 [3]
Clé de session	X25519	Diffie-Hellman Noise KK	RFC 7748 [2]

Les clés sont générées via le générateur de nombres aléatoires cryptographiques de l’OS, par l’intermédiaire de libsodium.

3.2 Stockage des clés

Les clés privées sont stockées exclusivement dans le mécanisme de stockage sécurisé du système d’exploitation :

Plateforme	Stockage	Protection
macOS	Keychain Services	Support matériel (Secure Enclave sur Apple Silicon)
Windows	DPAPI (Data Protection API)	Limité à l’utilisateur, lié à la machine

Politique fail-hard : si le stockage sécurisé est indisponible, le sous-système de synchronisation refuse de démarrer. Aucun repli sur un stockage non chiffré, aucun mode dégradé, aucune rétrogradation silencieuse. Ce choix est délibéré, conformément aux recommandations ANSSI-PA-079 §3.1 [15].

3.3 Cycle de vie des clés

Phase	Mécanisme	Référence
Génération	Au premier démarrage, automatique	NIST SP 800-57 Part 1 §5.2 [8]
Distribution	Via le protocole d’appairage (§5)	—
Utilisation	Sessions Noise KK	—
Rotation (V1)	Manuelle : ré-appairage requis	NIST SP 800-57 Part 1 §5.3.6 [8]
Rotation (V2, prévue)	Automatique : nouvelle clé signée par la clé précédente (chaîne de confiance)	—
Révocation	CRL signée par la CA (§7)	—
Destruction	Suppression du stockage sécurisé OS lors de la révocation du poste	—

4. Autorité de Certification intégrée

Cette section décrit la contribution architecturale centrale : l’utilisation du backend SaaS comme Autorité de Certification (CA) intégrée pour la certification d’identité des postes.

4.1 Justification du choix de conception

Dans un petit cabinet médical (2 à 5 postes), le défi fondamental est d’établir une confiance mutuelle entre des postes sur un LAN non fiable. Trois approches ont été étudiées :

Approche	Avantages	Inconvénients	Décision
PKI / KMS externe (ex. : AWS KMS, HashiCorp Vault)	Standard industrie, support HSM	Coût prohibitif pour un petit cabinet (plusieurs centaines d’EUR/mois) ; complexité opérationnelle	Rejeté
Poste maître local (un poste fait office de CA)	Aucune dépendance serveur	Poste maître = point de défaillance unique ; clés sur un laptop potentiellement volé	Rejeté
CA intégrée au backend (le serveur SaaS signe les certificats)	Clé CA jamais sur aucun poste ; simple ; économique	Nécessite Internet pour l’appairage ; confiance dans l’opérateur backend	Retenu

L’approche CA intégrée est un compromis pragmatique documenté dans la littérature. NIST SP 800-57 Part 2 [9] définit le concept de « Key Management Organization » — une entité centralisée qui gère les clés cryptographiques pour des participants distribués. Le backend Dokitek remplit exactement ce rôle : il génère, stocke et opère la paire de clés CA pour le compte de chaque cabinet, sans jamais accéder aux données cliniques protégées par les clés de session dérivées.

4.2 Hiérarchie des clés CA

Clé maître AES-256 (KMS cloud, chiffrement par enveloppe)
  └── Paire de clés CA par cabinet (Ed25519)
        ├── Clé privée : chiffrée avec la clé maître, stockée côté serveur
        ├── Clé publique : distribuée à tous les postes enrôlés
        └── Signe : certificats postes, mises à jour CRL
              └── Certificat par poste
                    ├── Clé publique Ed25519 du poste
                    ├── Clé publique X25519 du poste
                    ├── Périmètre cabinet (structurellement lié)
                    └── Signature CA (Ed25519)

4.3 Propriétés de sécurité

Isolation de la clé CA : la clé privée CA est chiffrée au repos (AES-256) et ne quitte jamais le backend. Aucun poste — y compris celui de l’administrateur — ne possède la clé privée CA. Un poste compromis ne peut pas forger de certificats.

Périmètre par cabinet : chaque cabinet dispose de sa propre paire de clés CA. Un certificat émis pour le cabinet A est structurellement invalide pour le cabinet B. Il n’existe aucune relation de confiance inter-cabinets.

Vérification hors ligne : après l’appairage, les postes vérifient mutuellement leurs certificats en local, contre la clé publique CA mise en cache. Aucun contact avec le backend n’est requis pour l’authentification courante.

Scénario de compromission du backend — analyse de la chaîne d’exploitation complète : par souci de transparence, nous décrivons le scénario le plus défavorable et sa chaîne d’exploitation complète.

Si un attaquant parvenait à compromettre le backend (RCE, accès à l’infrastructure AWS, fuite de variables d’environnement), il pourrait extraire la clé maître CA et forger un certificat pour un cabinet ciblé. Cette hypothèse de confiance dans le backend est inhérente à toute architecture basée sur une CA — le même risque s’applique aux CA publics tels que Let’s Encrypt ou DigiCert. La clé maître est stockée dans AWS SSM (SecureString, chiffrée par KMS) et injectée au démarrage du backend ; les protections à ce niveau sont celles de l’infrastructure standard (IAM, journalisation CloudTrail), pas un HSM dédié.

Cependant, la possession d’un certificat forgé est nécessaire mais pas suffisante pour accéder aux données. La chaîne d’exploitation complète requiert l’ensemble des étapes suivantes, chacune devant aboutir :

Compromission du backend — l’attaquant obtient la clé maître et le matériel cryptographique CA stocké en base de données (clé privée chiffrée, IV, auth tag), ce qui lui permet de déchiffrer la clé privée CA du cabinet ciblé et de forger un certificat pour un poste fictif.
Implémentation du protocole — l’attaquant implémente un client compatible avec le protocole de pairing complet (échange de clés, génération SAS, handshake Noise KK), documenté dans le présent whitepaper.
Présence physique sur le LAN du cabinet — le protocole opère exclusivement en réseau local. L’attaquant doit être physiquement dans le cabinet ou avoir compromis un équipement sur le réseau local.
Initiation du pairing par l’administrateur — l’appairage n’est pas initié par le nouveau poste : c’est l’administrateur du cabinet qui déclenche la procédure depuis son poste. L’attaquant doit convaincre l’administrateur d’appairer un poste inconnu.
Vérification visuelle du SAS — l’administrateur lit le code SAS affiché sur son écran et le confirme avec la personne physiquement présente devant lui. L’attaquant doit compléter cette vérification humaine sans éveiller de soupçon.

Les étapes 1 et 2, bien que non triviales, sont des attaques logicielles classiques. Ce sont les étapes 3 à 5 qui rendent l’exploitation pratiquement irréalisable : elles exigent une présence physique dans un cabinet médical de quelques personnes, une ingénierie sociale sur l’administrateur pour lui faire appairer un poste qu’il ne reconnaît pas, et une interaction face-à-face pour la vérification SAS — le tout pour accéder aux données d’un unique cabinet d’orthoptie. Ce profil d’attaque n’a aucun précédent connu dans le secteur des petites structures de santé.

La forward secrecy garantit par ailleurs que les sessions passées restent protégées indépendamment de toute compromission future de la clé CA.

4.4 Comparaison avec des précédents industriels

Système	Modèle CA	Emplacement de la clé	Fonctionnement hors ligne
Matter/Thread [18]	Le Commissioner (poste local) signe les certificats NOC	Sur le poste de commissioning	Oui, après commissioning
Tailscale [—]	Le serveur de coordination distribue les clés WireGuard	Serveur (ne signe pas de certificats)	Partiel (repli DERP)
Signal [21]	Serveur stocke les pre-keys ; pas de PKI	Serveur + poste	Oui, après échange de clés
Ocureo	CA backend signe les certificats postes	Serveur uniquement (chiffré)	Oui, après appairage

Le modèle Ocureo est le plus proche de l’architecture Matter Commissioner [18], à la différence clé que la clé CA réside sur le serveur backend plutôt que sur un poste local, ce qui offre une meilleure isolation contre le vol physique.

5. Protocole d’appairage

L’appairage (pairing) est le processus par lequel un nouveau poste est enrôlé dans le domaine de confiance d’un cabinet. C’est un événement supervisé et peu fréquent (à l’installation ou au remplacement d’une machine), réalisé sous le contrôle visuel de l’administrateur.

5.1 Séquence protocolaire

Pré-condition : les deux postes se sont déjà découverts via NSD/Bonjour sur le LAN et ont établi une connexion WebSocket (en clair à ce stade — aucune session Noise KK n’existe encore).

    Nouveau poste (C)           Backend (Dokitek)           Poste admin (A)
         │                            │                           │
         │     [WebSocket LAN déjà établi via NSD]                │
         │                            │                           │
    ┌────┤                            │                           │
    │Gén.│ Paires de clés Ed25519 + X25519                        │
    └────┤                            │                           │
         │                            │                           │
         │── prepare-pairing ────────>│                           │
         │   (token auth, clés pub)   │                           │
         │                            │                           │
         │<── pairingRequestId ───────│                           │
         │    + nonce                 │                           │
         │                            │                           │
         │══ pairingRequest (WS/LAN) ════════════════════════════>│
         │   (requestId, nonce,       │                           │
         │    clés pub de C)          │              ┌────────────┤
         │                            │              │ Calcule    │
         │                            │              │ le code SAS│
    ┌────┤                            │              │ depuis les │
    │Calcule le code SAS              │              │ deux clés  │
    │depuis les deux clés pub         │              │ + nonce    │
    │+ nonce                          │              └────────────┤
    └────┤                            │                           │
         │  Affiche : [83927461]      │               ┌───────────┤
         │                            │               │ Affiche   │
         │                            │               │ [83927461]│
         │                            │               │ Admin     │
         │                            │               │ confirme  │
         │                            │               └──────────>│
         │                            │                           │
         │                            │<── confirm-pairing ───────│
         │                            │    (requestId,            │
         │                            │     clés pub de A)        │
         │                            │                           │
         │                            │── certificats ───────────>│
         │                            │   (cert C + cert A)       │
         │                            │                           │
         │<════════ Livraison du certificat (WS/LAN) ═════════════│
         │                            │                           │
    ┌────┤                            │                           │
    │Stocke certificat + clé pub CA   │                           │
    │Démarre les sessions Noise KK    │                           │
    └────┤                            │                           │

5.2 Dérivation du SAS (Short Authentication String)

Le code de vérification est dérivé par hachage cryptographique déterministe des clés publiques des deux parties et d’un nonce fourni par le serveur, suivant l’approche de channel binding établie par ZRTP [27] (RFC 6189) et le Bluetooth Secure Simple Pairing (mode Numeric Comparison). Les deux postes calculent indépendamment le même code ; toute substitution de clé publique par un intermédiaire provoque une divergence visible que l’administrateur détecte.

Résistance au brute-force : l’espace de codes offre 10^8 combinaisons. Le rate limiting et l’expiration des jetons contraignent la fenêtre d’attaque pratique.

5.3 Gossip de certificats

Après l’appairage, les postes enrôlés propagent automatiquement les certificats et les listes de révocation :

À chaque handshake Noise KK, les pairs échangent l’ensemble des certificats connus et la CRL courante.
Chaque certificat reçu est vérifié contre la clé publique CA avant acceptation.
Un certificat forgé (non signé par la CA du cabinet) est rejeté.

Ce mécanisme gossip garantit qu’un nouveau poste enrôlé par l’administrateur est automatiquement reconnu par tous les autres postes sans nécessiter de ré-appairage individuel. Un seul appairage par poste ; propagation à l’ensemble du réseau.

6. Chiffrement de session : Noise KK

6.1 Choix du pattern

Le Noise Protocol Framework [1] définit 12 patterns de handshake interactifs fondamentaux. Nous avons retenu le pattern KK (les deux clés statiques sont connues — Known — de chaque partie) :

KK:
  -> s
  <- s
  ...
  -> e, es, ss
  <- e, ee, se

Pattern	Auth. mutuelle	Forward secrecy	Messages	Prérequis
KK	Oui	Oui	2	Les deux clés statiques pré-partagées
IK	Oui	Oui	2	Seule la clé de l’initiateur est connue
XX	Oui	Oui	3	Aucune clé pré-partagée

KK est le choix optimal pour notre cas d’usage : après l’appairage (§5), les deux postes possèdent les clés statiques certifiées de l’autre. Le pattern KK exploite cette connaissance pour atteindre l’authentification mutuelle et la forward secrecy en un minimum de messages (2), tout en rejetant les pairs inconnus dès le premier message.

6.2 Suite cryptographique

Fonction	Algorithme	Taille de clé	Standard	Recommandation ANSSI
Échange de clés (DH)	X25519	256 bits	RFC 7748 [2]	Recommandé [15]
Signature	Ed25519	256 bits	RFC 8032 [3]	Recommandé [15]
Chiffrement authentifié	ChaCha20-Poly1305	Clé 256 bits, nonce 96 bits	RFC 8439 [4]	Recommandé [15]
Dérivation de clés	HKDF-SHA256	—	RFC 5869 [5]	Recommandé [15]
Protocole de session	Noise KK	—	Noise spec rev. 34 [1]	—

Tous les algorithmes retenus sont recommandés par l’ANSSI dans le Guide de sélection d’algorithmes cryptographiques (ANSSI-PA-079) [15] et listés dans NIST SP 800-57 Part 1 [8] comme approuvés pour la protection des données sensibles.

6.3 Vérification formelle

Les propriétés de sécurité du pattern Noise KK ont été vérifiées indépendamment par plusieurs travaux académiques :

Travail	Méthode	Périmètre	Résultat
Noise Explorer (Kobeissi et al., 2018) [12]	ProVerif	57 patterns Noise dont KK	KK satisfait l’authentification mutuelle, la forward secrecy, l’anti-replay
Noise* (Inria, IEEE S&P 2022) [11]	Assistant de preuve F*	Implémentations vérifiées haute performance	Implémentation KK prouvée correcte et sécurisée
fACCE (Dowling, 2019) [13]	Preuves calculatoires	8 des 15 patterns de base dont KK	KK sécurisé sous hypothèses standard
Spectral Analysis of Noise (Girol et al., USENIX Security 2020) [14]	Analyse systématique	Tous les patterns Noise	Modèle de menace maximal sous lequel KK est sécurisé

Ce sont des preuves académiques tierces portant sur la sécurité du protocole lui-même. Notre implémentation est validée contre les vecteurs de test de référence cacophony (§14), qui vérifient la conformité bit à bit avec la spécification — indépendamment de la bibliothèque cryptographique sous-jacente.

6.4 Propriétés de sécurité

Confidentialité : chaque message applicatif est chiffré avec ChaCha20-Poly1305 (AEAD). Un observateur sur le réseau ne voit que du texte chiffré.

Authentification mutuelle : les deux pairs prouvent la possession de leur clé statique attendue lors du handshake. Un imposteur ne peut pas compléter le handshake.

Forward secrecy : chaque session génère de nouvelles paires de clés X25519 éphémères. Les messages de transport bénéficient d’une forward secrecy forte — si une clé privée statique est compromise ultérieurement, les données de transport passées restent indéchiffrables. Les messages de handshake ont une forward secrecy partielle telle que spécifiée par le pattern Noise KK (voir l’analyse Noise Explorer [12]).

Intégrité : chaque message porte un tag d’authentification Poly1305. Toute modification en transit entraîne un rejet.

Anti-replay : le transport Noise utilise des compteurs de nonce séquentiels. Un message capturé et rejoué est détecté et rejeté.

7. Révocation et cycle de vie des certificats

7.1 Certificate Revocation List (CRL)

Lorsqu’un poste est retiré (remplacement de machine, vol, départ d’un collaborateur), l’administrateur le révoque. La CA backend émet une mise à jour de CRL signée :

Propriété	Valeur
Signé par	CA du cabinet (Ed25519)
Versionnement	Numéro de séquence monotone
Propagation	Gossip à chaque handshake entre pairs
Vérification	Avant chaque session Noise KK
Périmètre	Par cabinet (aucun impact inter-cabinets)

7.2 Politique fail-close

Si un poste est isolé au-delà d’un seuil configurable sans mise à jour de CRL et sans contact avec aucun pair connu, il entre en mode fail-close : il refuse les connexions provenant de postes non déjà authentifiés dans la session courante. Cela empêche un attaquant d’exploiter l’isolation réseau pour présenter un certificat forgé.

7.3 Protection du rôle administrateur

Il n’existe pas de « poste maître » unique — tout poste opéré par un utilisateur avec le rôle administrateur peut effectuer les opérations d’enrôlement et de révocation. La protection est appliquée côté serveur : les endpoints de confirmation d’appairage et de révocation sont restreints aux utilisateurs authentifiés disposant du rôle administrateur. Un poste compromis n’ayant pas le rôle admin ne peut ni enrôler ni révoquer de pairs. Si un compte administrateur est compromis, la remédiation passe par le backend (récupération du compte, réaffectation des rôles), et non par un mécanisme au niveau du poste.

7.4 Rotation des clés

Version	Mécanisme	Perturbation
V1 (actuelle)	Manuelle : l’administrateur déclenche un ré-appairage	Nécessite le ré-enrôlement du poste concerné
V2 (prévue)	Automatique : nouvelle paire de clés signée par la clé précédente (chaîne de confiance), cycle de 90 jours	Transparente pour les utilisateurs

8. Synchronisation des données

8.1 Modèle CRDT

La synchronisation des données cliniques repose sur un modèle CRDT (Conflict-free Replicated Data Types) implémenté en interne, sans bibliothèque tierce. Ce choix garantit un contrôle total sur la couche de persistance et sa compatibilité avec le schéma de base de données existant.

L’implémentation combine deux primitives académiques :

Primitive	Référence	Rôle
Hybrid Logical Clocks (HLC)	Kulkarni, Demirbas et al. (2014) [28]	Ordre causal des événements distribués
Last-Writer-Wins Register (LWW)	Shapiro, Preguiça et al. (2011) [29]	Résolution déterministe des conflits par ligne

Chaque enregistrement du domaine métier (patients, bilans, prescripteurs, modèles, formulations) porte une horloge logique hybride, l’identifiant du poste auteur de la dernière écriture, et un marqueur de suppression logique (tombstone). Ces métadonnées permettent à chaque poste de déterminer, de manière autonome et sans coordination centralisée, quelle version d’un enregistrement prévaut.

8.2 Protocole de synchronisation

La synchronisation entre pairs suit une séquence notification-requête-transfert, transmise exclusivement par le canal chiffré Noise KK (fail-closed) :

Notification : un poste ayant accumulé des écritures locales notifie ses pairs.
Requête : le pair récepteur répond par une demande de synchronisation, incluant son vecteur de connaissance (§8.3) comme contexte causal.
Transfert : le poste notifiant calcule le delta minimal et le transmet de manière paginée. Le récepteur pilote la pagination jusqu’à épuisement du changeset. La pagination est tolérante aux pannes : si une interruption survient mid-transfert, la reprise au reconnect ne perd aucune donnée.
Acquittement : un signal de complétion bidirectionnel garantit que les opérations post-synchronisation (propagation de certificats, réconciliation des verrous) ne démarrent qu’après convergence complète des deux pairs.

Le merge respecte l’ordre topologique (parents avant enfants) pour satisfaire les contraintes d’intégrité référentielle.

8.3 Vecteur de connaissance (Knowledge Vector)

Lorsqu’un nouveau poste rejoint le réseau, les pairs existants n’ont pas d’historique commun, ce qui forcerait un transfert complet redondant. Avec N postes, le coût serait O(N²) en volume transféré.

Le Knowledge Vector résout ce problème en implémentant un modèle delta-state formel (Almeida, Shoker et Baquero, 2018 [30]). Chaque pair maintient une carte d’état représentant, pour chaque poste d’écriture connu, l’horloge la plus récente observée. Lors d’une demande de synchronisation, le pair envoie cette carte ; le répondant calcule le delta minimal — seules les données que le demandeur n’a pas encore vues sont transmises.

Le vecteur est maintenu avec une sémantique de mise à jour monotone. En cas de défaillance — y compris une restauration de sauvegarde — la cohérence est préservée par reconstruction du vecteur à partir du jeu de données réel.

8.4 Résolution de conflits

Arbitrage LWW : lorsque deux pairs modifient le même enregistrement, l’écriture avec l’horloge la plus récente l’emporte. Les propriétés CvRDT (commutativité, associativité, idempotence) garantissent la convergence indépendamment de l’ordre de réception des messages.

Suppressions logiques (tombstones) : les suppressions sont représentées par un marqueur plutôt que par une suppression physique. Ce mécanisme est requis pour la convergence CRDT : une suppression physique serait invisible lors du merge et provoquerait la résurrection de l’enregistrement par un pair n’ayant pas encore reçu la suppression.

Déduplication par clé métier : lorsqu’un merge produit un doublon (par exemple, un même patient créé indépendamment sur deux postes), une stratégie de résolution déterministe fondée sur l’ordre des horloges garantit que les deux postes convergent vers le même résultat sans coordination.

8.5 Persistance de l’état de synchronisation

Les curseurs de synchronisation sont persistés localement par pair et avancent de manière monotone. Lors d’une restauration de sauvegarde, les curseurs sont réinitialisés pour forcer une resynchronisation complète — préservant l’intégrité des données à travers les frontières de restauration.

9. Synchronisation des fichiers

9.1 Architecture

Les fichiers associés aux bilans (exports PDF/Word, aperçus, pièces jointes) sont synchronisés via un registre CRDT dédié. Chaque entrée de fichier porte des métadonnées CRDT et un checksum d’intégrité SHA-256.

La synchronisation des fichiers progresse indépendamment de la synchronisation des données, via un espace de curseurs séparé.

9.2 Protocole de transfert

Le protocole opère en deux phases, toutes deux chiffrées via Noise KK :

Phase d’index : les pairs échangent des notifications de changement de fichiers et identifient les fichiers à transférer à partir des curseurs CRDT.

Phase de transfert : les fichiers sont transférés séquentiellement avec une vérification d’intégrité SHA-256 par fichier avant écriture sur disque.

9.3 Intégrité cross-platform

Tous les chemins relatifs stockés et échangés suivent une convention canonique unique, indépendamment de la plateforme (macOS, Windows). La normalisation est appliquée aux frontières du système de fichiers pour prévenir toute divergence cross-platform.

10. Verrouillage distribué

10.1 Modèle

Le système implémente un verrouillage pessimiste par ressource (patient, bilan, prescripteur, modèle, formulation) pour prévenir les conflits d’édition concurrente. Le premier rédacteur obtient le verrou (first-writer-wins via comparaison d’horloge logique).

Trois types de messages assurent la coordination, tous exclusivement chiffrés (fail-closed) : demande de verrouillage, libération, et état complet (envoyé à la connexion et enrichi dans les heartbeats).

10.2 Propriétés

Propriété	Valeur
Timeout de connexion	Configurable — libération automatique des verrous du pair déconnecté
Filet de sécurité verrous périmés	Durée maximale de maintien imposée
Surfaces de mutation gardées	Toutes les opérations d’écriture dans l’interface (suppression, édition, finalisation)
Réconciliation par heartbeat	Périodique — détecte et corrige l’état de verrouillage asymétrique

La réconciliation par heartbeat est un mécanisme de défense en profondeur : les pairs échangent périodiquement un résumé de l’état de verrouillage et corrigent toute divergence causée par des messages de coordination perdus lors de déconnexions transitoires.

11. Isolation sauvegarde/restauration

La sauvegarde et la restauration sont des opérations exclusives qui remplacent le jeu de données local. La couche de synchronisation complète (découverte, connexions, données, fichiers, verrous) est arrêtée pendant toute la durée de l’opération pour prévenir la propagation d’état intermédiaire ou les effets de bord en cascade. Les pairs observent une déconnexion propre. La synchronisation est redémarrée systématiquement à la fin de l’opération, et les pairs se reconnectent pour une resynchronisation propre.

12. Périmètre des données : ce que voit le serveur

Donnée	Transite par le serveur ?	Finalité
Dossiers patients, bilans, fichiers	Non — pair-à-pair, chiffré	—
Clés de session (éphémères)	Non — ne quittent jamais la RAM	—
Clés publiques des postes	Oui — à l’appairage uniquement	Signature de certificat
Clé privée CA	Oui — chiffrée au repos	Opérations CA
CRL	Oui — signée, publique par nature	Propagation des révocations
Curseurs de synchronisation	Non — LAN uniquement, chiffré	Suivi de progression sync (SQLite local)
Vecteurs de connaissance	Non — LAN uniquement, chiffré	Delta-state sync (SQLite local)
État des verrous	Non — LAN uniquement, chiffré	Coordination des accès (mémoire, non persisté)
Index des fichiers (chemins + HLC)	Non — LAN uniquement, chiffré	Registre de fichiers sync (SQLite local)
Noms des postes	Partiellement — NSD sur LAN + backend (enregistrement device)	Identification visuelle des postes

Le serveur est un tiers de confiance pour l’identité — il certifie quels postes appartiennent à quel cabinet. Il n’est pas un intermédiaire de données. Il ne voit, ne traite ni ne stocke aucune donnée clinique. Cette séparation est imposée architecturalement : le plan de données opère exclusivement sur le LAN, et le backend ne dispose d’aucun endpoint API qui accepte ou retourne des données cliniques.

13. Conformité réglementaire

13.1 Correspondance RGPD

Article	Exigence	Implémentation
Art. 5.1.f	Intégrité et confidentialité	AEAD Noise KK, forward secrecy, anti-replay
Art. 25	Protection des données dès la conception et par défaut	Sécurité conçue avant l’implémentation (4 audits de conception) ; aucun mode dégradé
Art. 32.1.a	Chiffrement des données personnelles	Chiffrement de bout en bout sur tous les canaux de synchronisation
Art. 32.1.b	Confidentialité, intégrité, disponibilité continues	Révocation CRL, fail-close, propagation par gossip
Art. 32.1.d	Tests et évaluations réguliers	Vecteurs de test cacophony, audits de sécurité
Art. 9	Catégories spéciales (données de santé)	Données ne quittant jamais le réseau local ; aucun traitement côté serveur

13.2 Correspondance avec les contrôles de l’Annexe A ISO/IEC 27001:2022

Contrôle	Titre	Implémentation
A.5.15	Contrôle d’accès	Séparation des rôles : administrateur (appairage, révocation) vs. membre (sync). Appliqué côté serveur sur chaque appel API
A.5.28	Collecte de preuves	Journalisation des événements de sécurité : tentatives d’appairage, échecs de handshake, révocations, détections de replay
A.8.9	Gestion de configuration	Matériel cryptographique géré centralement (CA backend) ; configuration des postes via stockage sécurisé
A.8.10	Suppression des informations	La révocation d’un poste déclenche une mise à jour CRL ; matériel cryptographique détruit à la révocation
A.8.24	Utilisation de la cryptographie	Sélection des algorithmes per ANSSI-PA-079 [15] et NIST SP 800-57 [8] ; pas de cryptographie personnalisée ; framework Noise KK
A.8.25	Cycle de vie de développement sécurisé	4 audits de sécurité en phase de conception ; vérification formelle citée ; validation par vecteurs de test
A.8.26	Exigences de sécurité applicative	Fail-hard en cas d’indisponibilité du stockage sécurisé ; aucun repli en clair ; rate limiting sur l’appairage

Note : Ocureo n’est pas certifié ISO 27001. Cette correspondance documente l’alignement de l’architecture cryptographique avec les contrôles pertinents de l’Annexe A. La certification ISO 27001 est un processus organisationnel qui dépasse les seules mesures techniques.

13.3 Conformité ANSSI

Tous les algorithmes cryptographiques individuels utilisés sont recommandés par l’ANSSI dans le Guide de sélection d’algorithmes cryptographiques (ANSSI-PA-079, 2021) [15] :

Ed25519 : recommandé pour les signatures numériques
X25519 : recommandé pour l’accord de clés
ChaCha20-Poly1305 : recommandé pour le chiffrement authentifié
SHA-256 / HKDF : recommandé pour le hachage et la dérivation de clés

Le Noise Protocol Framework en tant que tel n’a pas été évalué par l’ANSSI ; ses propriétés de sécurité reposent sur des preuves académiques indépendantes [11][12][13][14].

13.4 HDS (Hébergement de Données de Santé)

La certification HDS (réglementation française sur l’hébergement de données de santé, Décret n° 2018-137) s’applique aux organisations qui hébergent des données de santé pour le compte d’un professionnel de santé. Dans l’architecture Ocureo, les données cliniques ne quittent jamais le réseau local et ne sont jamais hébergées sur les serveurs Dokitek. La certification HDS n’est donc pas requise pour la fonctionnalité de synchronisation. Néanmoins, les fondations architecturales (gestion des clés, contrôle d’accès, piste d’audit) sont conçues pour soutenir une trajectoire de certification HDS si le périmètre du produit venait à évoluer.

14. Validation

14.1 Conformité de l’implémentation

L’implémentation Noise KK est validée contre les vecteurs de test de référence cacophony — la suite de tests standard pour les implémentations du Noise Protocol. Chaque test injecte des clés connues, exécute le handshake et 4 messages de transport, et vérifie que chaque octet en sortie correspond aux valeurs attendues, bit à bit. C’est le test de conformité le plus strict disponible pour les implémentations du Noise Protocol.

Les vecteurs de test sont maintenus par la communauté Noise Protocol et utilisés par les implémentations de référence en Haskell, Rust et Go. Passer ces vecteurs confirme que notre implémentation suit correctement la spécification Noise KK [1].

14.2 Audits de sécurité

Quatre audits de sécurité ont été conduits pendant les phases de conception et d’implémentation :

Audit	Phase	Périmètre	Résultats	Résolution
V1 — Revue de la pile cryptographique	Pré-implémentation	Sélection des algorithmes, modèle de menace	2 Haute, 4 Moyenne, 3 Faible, 2 Info	Toutes les Haute/Moyenne résolues. Recommandation d’adopter Noise KK appliquée.
V2 — Revue de la chaîne de confiance	Pré-implémentation	Architecture CA, protocole d’appairage, séquencement des phases	2 Haute, 6 Moyenne, 3 Faible, 3 Info	Toutes les Haute résolues. Phase sécurité réordonnée avant la phase données.
V3 — Revue post-implémentation	Après développement	Conformité à la conception, problèmes au niveau du code	Findings de sévérité critique	Tous résolus en moins de 24 heures.
V4 — Migration cryptographique	Post-implémentation	Migration vers une bibliothèque cryptographique auditée et largement déployée (libsodium)	1 Haute (dépendance mono-auteur)	Résolue. Couche d’abstraction découplant le code protocolaire de l’implémentation cryptographique. Conformité revalidée via les vecteurs cacophony.

14.3 Protections contre les CVE

Classe de vulnérabilité	Protection
Incrément du nonce en cas d’échec de déchiffrement (cf. CVE-2024-58265 dans la bibliothèque Rust `snow`)	Le compteur n’avance pas en cas d’échec de déchiffrement ; cette classe de vulnérabilité est traitée par conception
Attaque par point neutre (X25519)	Clés publiques nulles rejetées au handshake
Attaque par rétrogradation (repli en clair)	Aucun mode dégradé — chiffrement ou absence de connexion
Épuisement du nonce	Plafond vérifié avant chaque opération de chiffrement

15. Limites connues

Transparence sur les limites actuelles de l’architecture :

Limite	Impact	Atténuation	Résolution prévue
Pas de rotation automatique des clés (V1)	Clés statiques à longue durée de vie : fenêtre d’exposition élargie en cas de compromission	La forward secrecy limite l’impact aux métadonnées ; ré-appairage disponible	V2 : rotation automatique avec chaîne de confiance
Pas de HSM pour la clé maître	Clé maître dans AWS SSM (protégée par KMS), pas dans un HSM dédié	KMS fournit un chiffrement par enveloppe et une journalisation des accès ; acceptable pour le profil de risque des petits cabinets	Coût prohibitif ; à réévaluer si le produit évolue vers le segment hospitalier
Bindings mono-auteur vers la bibliothèque cryptographique	Les bindings vers la bibliothèque cryptographique sont maintenus par un auteur unique	Risque atténué : (1) le cœur cryptographique (libsodium) est un projet multi-contributeurs, audité, utilisé par Signal, 1Password, Cloudflare ; (2) les bindings sont mécaniquement simples et forkables ; (3) une couche d’abstraction découple le code protocolaire de l’implémentation	Le point de défaillance unique porte sur la couche de bindings, non sur l’implémentation cryptographique
Internet requis pour l’appairage	Enrôlement d’un nouveau poste impossible lors d’une indisponibilité backend	Les sessions existantes continuent sur le LAN ; l’indisponibilité n’affecte que l’enrôlement	Contrainte architecturale du modèle CA-backend
Identifiant de poste visible sur le LAN	Les identifiants de postes sont visibles lors de la découverte réseau locale. Aucun accès aux données n’est possible à partir de cette information seule	Mitigation prévue : identifiants dérivés remplaçant les valeurs directes dans les enregistrements de découverte	Post-v1
Pas de garbage collection des tombstones CRDT	Les enregistrements soft-deleted (`is_deleted = 1`) s’accumulent indéfiniment	Impact marginal sur les volumes actuels (quelques milliers de lignes)	Compaction prévue en post-v1
Orphelin de session file sync	Si un pair déconnecte mid-transfert, les sessions dépendantes peuvent se bloquer jusqu’à la reconnexion	Récupération automatique à la reconnexion : l’état de synchronisation n’a pas avancé, le transfert reprend proprement	Timeout de session à évaluer en post-v1

16. État de l’art

Système	Chiffrement	Modèle d’identité	Coût	Différence clé avec Ocureo
Doctolib (via acquisition Tanker)	E2E partiel (échange de documents)	PKI (Tanker SDK)	135-149 EUR/mois	Capacité acquise (~25-30 M EUR). Couvre l’échange de documents, pas la synchronisation complète.
Matter/Thread [18]	Sessions AES-128-CCM	Le Commissioner signe les certificats NOC	— (standard IoT)	Le Commissioner est un poste local ; clé CA sur un équipement (isolation plus faible).
Tailscale	WireGuard (Noise IK)	Serveur de coordination distribue les clés	5-18 $/utilisateur/mois	Pas de signature de certificats ; clés distribuées, non certifiées.
Syncthing	TLS 1.3	Identifiants de postes (auto-signés), Introducer pour la propagation de confiance	Gratuit (open source)	Pas de CA centralisée ; modèle TOFU ; l’Introducer est consultatif, pas autoritatif.
Signal	X3DH + Double Ratchet (basé sur Noise)	Serveur de pre-keys + safety numbers	Gratuit	Pas de PKI ; TOFU + vérification par QR code. Modèle de menace différent (global, asynchrone).
Ocureo	Noise KK (E2E complet)	CA backend signe les certificats des postes	~20 EUR/mois	Clé CA côté serveur (isolation maximale) ; vérification hors ligne ; inclus dans l’abonnement de base.

Ocureo utilise le même framework cryptographique que Signal et WireGuard (Noise Protocol), mais dans un pattern différent (KK vs. IK/XX) optimisé pour un réseau fermé et pré-authentifié où les clés statiques de tous les participants sont certifiées par une autorité commune. L’architecture n’est pas comparable à celle de Signal, qui résout un problème fondamentalement différent (messagerie asynchrone entre inconnus) nécessitant des propriétés supplémentaires (post-compromise security, deniability cryptographique) hors du périmètre de Noise KK.

17. References

Specifications and Standards

#	Document	Reference
[1]	Noise Protocol Framework, Revision 34	noiseprotocol.org/noise.html
[2]	RFC 7748 — Elliptic Curves for Security (X25519)	rfc-editor.org/rfc/rfc7748
[3]	RFC 8032 — Edwards-Curve Digital Signature Algorithm (Ed25519)	rfc-editor.org/rfc/rfc8032
[4]	RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols	rfc-editor.org/rfc/rfc8439
[5]	RFC 5869 — HMAC-based Extract-and-Expand KDF (HKDF)	rfc-editor.org/rfc/rfc5869
[6]	RFC 5280 — Internet X.509 PKI Certificate and CRL Profile	rfc-editor.org/rfc/rfc5280
[27]	RFC 6189 — ZRTP: Media Path Key Agreement for Unicast Secure RTP	rfc-editor.org/rfc/rfc6189

NIST Publications

#	Document	Reference
[7]	NIST SP 800-207 — Zero Trust Architecture	csrc.nist.gov/pubs/sp/800/207/final
[8]	NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management	csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
[9]	NIST SP 800-57 Part 2 Rev. 1 — Best Practices for Key Management Organizations	csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final

Academic Publications (Formal Verification of Noise Protocol)

#	Document	Reference
[11]	Noise* — A Library of Verified High-Performance Secure Channel Protocol Implementations (IEEE S&P 2022, Inria)	eprint.iacr.org/2022/607
[12]	Noise Explorer — Fully Automated Modeling and Verification for Arbitrary Noise Protocols (Kobeissi et al., 2018)	eprint.iacr.org/2018/766
[13]	Flexible Authenticated and Confidential Channel Establishment (fACCE): Analyzing the Noise Protocol Framework (Dowling, 2019)	eprint.iacr.org/2019/436
[14]	A Spectral Analysis of Noise: A Comprehensive, Automated, Formal Analysis of Diffie-Hellman Protocols (Girol et al., USENIX Security 2020)	usenix.org/system/files/sec20-girol_0.pdf

CRDT and Distributed Systems

#	Document	Reference
[28]	Kulkarni, S., Demirbas, M., Madappa, D., Avva, B., Leone, M. “Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases.” 2014.	cse.buffalo.edu/tech-reports/2014-04.pdf
[29]	Shapiro, M., Preguiça, N., Baquero, C., Zawirski, M. “A comprehensive study of Convergent and Commutative Replicated Data Types.” INRIA Research Report RR-7506, 2011.	inria.hal.science/inria-00555588
[30]	Almeida, P.S., Shoker, A., Baquero, C. “Delta State Replicated Data Types.” Journal of Parallel and Distributed Computing, 111, 2018.	doi.org/10.1016/j.jpdc.2017.08.003

ANSSI / Réglementation française

#	Document	Reference
[15]	ANSSI-PA-079 — Guide de sélection d’algorithmes cryptographiques (2021)	cyber.gouv.fr/publications/mecanismes-cryptographiques
[16]	RGS v2.0 — Référentiel Général de Sécurité	cyber.gouv.fr/le-referentiel-general-de-securite-version-20-les-documents

Industry References

#	Document	Reference
[18]	Matter Security & Privacy Fundamentals (CSA, 2022)	csa-iot.org
[21]	Signal X3DH Specification	signal.org/docs/specifications/x3dh/

Regulatory

#	Document	Reference
[22]	ISO/IEC 27001:2022 — Information Security Management Systems	iso.org/standard/27001
[23]	ISO/IEC 27002:2022 — Information Security Controls	iso.org/standard/75652.html
[26]	RGPD — Règlement (UE) 2016/679	eur-lex.europa.eu

Abstract

Ocureo is a desktop application for orthoptists (eye care professionals) that synchronizes patient records across workstations within a local network, without routing any clinical data through an external server. This paper describes the cryptographic architecture that secures this synchronization. The design combines three established components in an original configuration: (1) the Noise Protocol Framework [1] pattern KK for authenticated session encryption, (2) an embedded Certificate Authority hosted on the SaaS backend for device identity certification, and (3) a Short Authentication String (SAS) pairing protocol inspired by ZRTP [27] and Bluetooth Secure Simple Pairing for out-of-band verification. The architecture assumes a zero-trust LAN environment per NIST SP 800-207 [7] and targets compliance with GDPR Article 32 and ISO/IEC 27001:2022 Annex A controls. Beyond the cryptographic layer, the system relies on a custom CRDT model (HLC + LWW) for data convergence, a file transfer protocol with SHA-256 verification, and a distributed locking mechanism for concurrent access coordination. Implementation correctness is validated against the cacophony reference test vectors. The security properties of the Noise KK pattern itself have been formally verified by independent academic work [11][12][13][14].

Threat Model
Architecture Overview
Device Identity and Key Management
Embedded Certificate Authority
Pairing Protocol
Session Encryption: Noise KK
Revocation and Trust Lifecycle
Data Synchronization
File Synchronization
Distributed Locking
Backup/Restore Isolation
Data Boundary: What the Server Sees
Regulatory Alignment
Validation
Known Limitations
Related Work
References

1. Threat Model

1.1 Protected Assets

Asset	Classification	Regulatory basis
Patient records (dossiers, assessments)	GDPR Art. 9 — special category (health data)	GDPR Art. 32, Art. 5.1.f
Exchange integrity (no tampering)	Integrity	GDPR Art. 5.1.f
Synchronization availability	Availability	Business continuity

1.2 Attacker Model

We adopt a restricted Dolev-Yao model scoped to the LAN segment. The attacker:

Can observe, intercept, modify, drop, replay, and inject any message on the local network (e.g., compromised WiFi, ARP spoofing, rogue device on shared network).
Can enumerate devices announced via multicast discovery (NSD/Bonjour).
Cannot compromise the backend server (assumed trusted for CA operations — see §4.3 for discussion of this assumption).
Cannot obtain physical access to enrolled workstations.
Cannot break the underlying cryptographic primitives (standard assumption).

This model reflects the realistic threat surface of a medical practice: the waiting room WiFi is shared, maintenance contractors may connect devices, and consumer-grade network equipment offers no isolation guarantees.

1.3 Trust Assumptions

Entity	Trust level	Justification
Dokitek backend	Trusted for identity operations (CA)	Comparable to a TLS CA; does not access clinical data
OS secure storage (Keychain/DPAPI)	Trusted for key material	Platform-provided, hardware-backed where available
Practice administrator	Trusted for enrollment decisions	Visual SAS verification during pairing
LAN infrastructure	Untrusted	Zero-trust per NIST SP 800-207 [7]

1.4 Security Goals

Property	Mechanism	Formal basis
Confidentiality	Noise KK session encryption (ChaCha20-Poly1305 AEAD)	Proven in [11][12][13]
Mutual authentication	Static key authentication in KK pattern + CA-signed certificates	Noise KK property [1]
Forward secrecy	Ephemeral DH keys per session	Noise KK property, proven in [14]
Integrity	AEAD authentication tag on every message	RFC 8439 [4]
Anti-replay	Sequential nonce counters in Noise transport	Noise spec §5 [1]
MITM resistance (pairing)	SAS derived from public key hashes	Channel binding, cf. ZRTP [27]

2. Architecture Overview

2.1 Protocol Stack

┌─────────────────────────────────────────┐
│         Application Layer               │
│   ├── Data sync (CRDT, Knowledge       │
│   │   Vector — §8)                      │
│   ├── File sync (SHA-256,               │
│   │   chunked transfer — §9)            │
│   ├── Locking protocol                  │
│   │   (pessimistic, HLC — §10)          │
├─────────────────────────────────────────┤
│         Noise KK Session                │
│   (authenticated encryption, PFS)       │
├─────────────────────────────────────────┤
│         WebSocket Transport             │
│   (framing, bidirectional)              │
├─────────────────────────────────────────┤
│         TCP                             │
│   (reliable delivery)                   │
├─────────────────────────────────────────┤
│         NSD / Bonjour Discovery         │
│   (DNS-SD, mDNS, zero-conf)             │
└─────────────────────────────────────────┘

2.2 Functional Separation

The architecture enforces a strict separation between three functional planes:

Plane	Where it runs	Internet required
Control plane — pairing, certificate signing, CRL issuance	Backend (Dokitek)	Yes (enrollment only)
Data plane — patient record and file synchronization	LAN (peer-to-peer)	No
Coordination plane — distributed resource locking, heartbeat reconciliation	LAN (peer-to-peer)	No

After initial pairing, workstations communicate exclusively on the local network. The backend is not involved in, nor aware of, any data exchange or coordination. A network partition from the Internet does not interrupt synchronization between already-enrolled devices.

3. Device Identity and Key Management

3.1 Key Generation

At first launch, each workstation generates two independent key pairs:

Key pair	Algorithm	Purpose	Standard
Signing key	Ed25519	Identity proof, certificate requests	RFC 8032 [3]
Session key	X25519	Noise KK Diffie-Hellman	RFC 7748 [2]

Keys are generated using the OS cryptographic random number generator via libsodium.

3.2 Key Storage

Private keys are stored exclusively in the operating system’s secure storage facility:

Platform	Storage	Protection
macOS	Keychain Services	Hardware-backed (Secure Enclave on Apple Silicon)
Windows	DPAPI (Data Protection API)	User-scoped, machine-bound

Fail-hard policy: if secure storage is unavailable, the synchronization subsystem refuses to start. There is no fallback to unencrypted storage, no degraded mode, no silent downgrade. This is a deliberate design choice per the recommendations of ANSSI-PA-079 §3.1 [15].

3.3 Key Lifecycle

Phase	Mechanism	Reference
Generation	At first launch, automatic	NIST SP 800-57 Part 1 §5.2 [8]
Distribution	Via pairing protocol (§5)	—
Usage	Noise KK sessions	—
Rotation (V1)	Manual: re-pairing required	NIST SP 800-57 Part 1 §5.3.6 [8]
Rotation (V2, planned)	Automatic: new key signed by previous key (chain of trust)	—
Revocation	CRL signed by CA (§7)	—
Destruction	OS secure storage deletion on device revocation	—

4. Embedded Certificate Authority

This section describes the central architectural contribution: using the SaaS backend as an embedded Certificate Authority (CA) for device identity certification.

4.1 Design Rationale

In a small medical practice (2-5 workstations), the fundamental challenge is establishing mutual trust between devices on an untrusted LAN. Three approaches were considered:

Approach	Pros	Cons	Decision
External PKI / KMS (e.g., AWS KMS, HashiCorp Vault)	Industry standard, HSM-backed	Cost prohibitive for small practices (hundreds of EUR/month); operational complexity	Rejected
Local master device (one device acts as CA)	No server dependency	Master device = single point of failure; key material on a potentially stolen laptop	Rejected
Backend-embedded CA (SaaS server signs certificates)	CA key never on any device; simple; cost-effective	Requires Internet for pairing; trust in backend operator	Adopted

The embedded CA approach is a pragmatic trade-off documented in the literature. NIST SP 800-57 Part 2 [9] defines the concept of a “Key Management Organization” — a centralized entity that manages cryptographic keys for distributed participants. The Dokitek backend fulfills exactly this role: it generates, stores, and operates the CA key pair on behalf of each practice, while never accessing the clinical data protected by the derived session keys.

4.2 CA Key Hierarchy

AES-256 Master Key (cloud KMS, envelope-encrypted)
  └── Per-office CA key pair (Ed25519)
        ├── Private key: encrypted with master key, stored server-side
        ├── Public key: distributed to all enrolled devices
        └── Signs: device certificates, CRL updates
              └── Per-device certificate
                    ├── Device Ed25519 public key
                    ├── Device X25519 public key
                    ├── Office scope (structurally bound)
                    └── CA signature (Ed25519)

4.3 Security Properties

CA key isolation: The CA private key is encrypted at rest (AES-256) and never leaves the backend. No device — including the administrator’s — possesses the CA private key. A compromised workstation cannot forge certificates.

Per-office scoping: Each practice has its own CA key pair. A certificate issued for Practice A is structurally invalid for Practice B. There is no cross-practice trust relationship.

Offline verification: After pairing, devices verify each other’s certificates locally against the cached CA public key. No backend contact is required for ongoing authentication.

Backend compromise scenario — full exploitation chain analysis: For transparency, we describe the worst-case scenario and its complete exploitation chain.

If an attacker were to compromise the backend (RCE, AWS infrastructure access, environment variable leak), they could extract the CA master key and forge a certificate for a targeted practice. This trust assumption in the backend is inherent to any CA-based architecture — the same risk applies to public CAs such as Let’s Encrypt or DigiCert. The master key is stored in AWS SSM (SecureString, KMS-encrypted) and injected at backend startup; protections at this level are standard infrastructure controls (IAM, CloudTrail logging), not a dedicated HSM.

However, possession of a forged certificate is necessary but not sufficient to access data. The complete exploitation chain requires all of the following steps, each of which must succeed:

Backend compromise — the attacker obtains the master key and the per-office encrypted CA key material from the database (encrypted private key, IV, auth tag), allowing them to decrypt the target practice’s CA private key and forge a certificate for a fictitious device.
Protocol implementation — the attacker implements a client compatible with the full pairing protocol (key exchange, SAS generation, Noise KK handshake), documented in this whitepaper.
Physical presence on the practice’s LAN — the protocol operates exclusively on the local network. The attacker must be physically present in the practice or have compromised a device on the local network.
Administrator-initiated pairing — pairing is not initiated by the new device: the practice administrator triggers the procedure from their own workstation. The attacker must convince the administrator to pair an unknown device.
Visual SAS verification — the administrator reads the SAS code displayed on their screen and confirms it with the person physically present in front of them. The attacker must complete this human verification without raising suspicion.

Steps 1 and 2, while non-trivial, are standard software attacks. It is steps 3 through 5 that make exploitation practically infeasible: they require physical presence in a small medical practice, social engineering the administrator into pairing a device they do not recognize, and a face-to-face interaction for SAS verification — all to access data from a single orthoptic practice. This attack profile has no known precedent in the small healthcare practice sector.

Forward secrecy further guarantees that past sessions remain protected regardless of any future CA key compromise.

4.4 Comparison with Industry Precedents

System	CA model	Key location	Offline operation
Matter/Thread [18]	Commissioner (local device) signs NOC certificates	On commissioning device	Yes, after commissioning
Tailscale [—]	Coordination server distributes WireGuard keys	Server stores, does not sign certificates	Partial (DERP fallback)
Signal [21]	Server stores pre-keys; no PKI	Server + device	Yes, after key exchange
Ocureo	Backend CA signs device certificates	Server only (encrypted)	Yes, after pairing

The Ocureo model is closest to the Matter Commissioner architecture [18], with the key difference that the CA key resides on the backend server rather than on a local device, providing stronger isolation against physical theft.

5. Pairing Protocol

Pairing is the process by which a new workstation is enrolled into a practice’s trust domain. It is a supervised, infrequent event (at installation or machine replacement), performed under the administrator’s visual control.

5.1 Protocol Sequence

Pre-condition: Both devices have already discovered each other via NSD/Bonjour on the LAN and established a WebSocket connection (cleartext at this stage — no Noise KK session exists yet).

    New Device (C)              Backend (Dokitek)           Admin Device (A)
         │                            │                           │
         │     [LAN WebSocket already established via NSD]        │
         │                            │                           │
    ┌────┤                            │                           │
    │Gen │ Ed25519 + X25519 key pairs │                           │
    └────┤                            │                           │
         │                            │                           │
         │── prepare-pairing ────────>│                           │
         │   (auth token, pub keys)   │                           │
         │                            │                           │
         │<── pairingRequestId ───────│                           │
         │    + nonce                 │                           │
         │                            │                           │
         │══ pairingRequest (WS/LAN) ════════════════════════════>│
         │   (requestId, nonce,       │                           │
         │    C's pub keys)           │              ┌────────────┤
         │                            │              │ Compute    │
         │                            │              │ SAS code   │
    ┌────┤                            │              │ from both  │
    │Compute SAS code                 │              │ pub keys   │
    │from both pub keys               │              │ + nonce    │
    │+ nonce                          │              └────────────┤
    └────┤                            │                           │
         │  Display: [83927461]       │               ┌───────────┤
         │                            │               │ Display   │
         │                            │               │ [83927461]│
         │                            │               │ Admin     │
         │                            │               │ confirms  │
         │                            │               └──────────>│
         │                            │                           │
         │                            │<── confirm-pairing ───────│
         │                            │    (requestId,            │
         │                            │     A's pub keys)         │
         │                            │                           │
         │                            │── certificates ──────────>│
         │                            │   (C's cert + A's cert)   │
         │                            │                           │
         │<════════ Certificate delivery (WS/LAN) ════════════════│
         │                            │                           │
    ┌────┤                            │                           │
    │Store certificate + CA pub key   │                           │
    │Begin Noise KK sessions          │                           │
    └────┤                            │                           │

5.2 SAS (Short Authentication String) Derivation

The verification code is derived via a deterministic cryptographic hash of both parties’ public keys and a server-provided nonce, following the channel-binding approach established by ZRTP [27] (RFC 6189) and Bluetooth Secure Simple Pairing (Numeric Comparison mode). Both devices independently compute the same code; any man-in-the-middle substitution of a public key causes a visible mismatch that the administrator detects.

Brute-force resistance: the code space provides 10^8 combinations. Rate limiting and token expiration constrain the practical attack window.

5.3 Certificate Gossip

After pairing, enrolled devices propagate certificates and revocation lists automatically:

At each Noise KK handshake, peers exchange all known certificates and the current CRL.
Each received certificate is verified against the CA public key before acceptance.
A forged certificate (not signed by the practice’s CA) is rejected.

This gossip mechanism ensures that a new device enrolled by the administrator is automatically recognized by all other devices without requiring individual re-pairing. One pairing per device; propagation to the entire network.

6. Session Encryption: Noise KK

6.1 Pattern Selection

The Noise Protocol Framework [1] defines 12 fundamental interactive handshake patterns. We selected pattern KK (both static keys Known to each other):

KK:
  -> s
  <- s
  ...
  -> e, es, ss
  <- e, ee, se

Pattern	Mutual auth	Forward secrecy	Messages	Pre-requisite
KK	Yes	Yes	2	Both static keys pre-shared
IK	Yes	Yes	2	Only initiator’s key known
XX	Yes	Yes	3	No pre-shared keys

KK is the optimal choice for our use case: after pairing (§5), both devices possess each other’s certified static keys. The KK pattern leverages this knowledge to achieve mutual authentication and forward secrecy in the minimum number of messages (2), while rejecting unknown peers at the first message.

6.2 Cryptographic Suite

Function	Algorithm	Key size	Standard	ANSSI recommendation
Key exchange (DH)	X25519	256-bit	RFC 7748 [2]	Recommended [15]
Signature	Ed25519	256-bit	RFC 8032 [3]	Recommended [15]
Authenticated encryption	ChaCha20-Poly1305	256-bit key, 96-bit nonce	RFC 8439 [4]	Recommended [15]
Key derivation	HKDF-SHA256	—	RFC 5869 [5]	Recommended [15]
Session protocol	Noise KK	—	Noise spec rev. 34 [1]	—

All selected algorithms are recommended by the ANSSI Guide de sélection d’algorithmes cryptographiques (ANSSI-PA-079) [15] and listed in NIST SP 800-57 Part 1 [8] as approved for protection of sensitive data.

6.3 Formal Verification

The security properties of the Noise KK pattern have been independently verified by multiple academic works:

Work	Method	Scope	Result
Noise Explorer (Kobeissi et al., 2018) [12]	ProVerif	57 Noise patterns including KK	KK satisfies mutual authentication, forward secrecy, anti-replay
Noise* (Inria, IEEE S&P 2022) [11]	F* proof assistant	High-performance verified implementations	KK implementation proven correct and secure
Dowling (2019) [13]	Computational proofs	8 of 15 base patterns including KK	KK secure under standard assumptions
Vacarme (Girol et al., USENIX Security 2020) [14]	Systematic analysis	All Noise patterns	Maximal threat model under which KK is secure

These are third-party academic proofs that the protocol itself is secure. Our implementation is validated against the cacophony reference test vectors (§14), which verify bit-for-bit conformance with the specification — regardless of the underlying cryptographic library.

6.4 Security Properties

Confidentiality: every application message is encrypted with ChaCha20-Poly1305 (AEAD). An observer on the network sees only ciphertext.

Mutual authentication: both peers prove possession of their expected static key during the handshake. An impostor cannot complete the handshake.

Forward secrecy: each session generates fresh ephemeral X25519 key pairs. Transport messages benefit from strong forward secrecy — if a static private key is compromised in the future, past recorded transport data remains undecipherable. Handshake messages have partial forward secrecy as specified by the Noise KK pattern (see Noise Explorer analysis [12]).

Integrity: every message carries a Poly1305 authentication tag. Any modification in transit causes rejection.

Anti-replay: Noise transport uses sequential nonce counters. A captured and replayed message is detected and rejected.

7. Revocation and Trust Lifecycle

7.1 Certificate Revocation List (CRL)

When a device is removed (machine replacement, theft, personnel departure), the administrator revokes it. The backend CA issues a signed CRL update:

Property	Value
Signed by	Practice CA (Ed25519)
Versioning	Monotonic sequence number
Propagation	Gossip at every peer handshake
Verification	Before every Noise KK session
Scope	Per-practice (no cross-practice impact)

7.2 Fail-Close Policy

If a device has been isolated beyond a configurable threshold without a CRL update and without contact with any known peer, it enters fail-close mode: it refuses connections from devices not already authenticated in the current session. This prevents an attacker from exploiting network isolation to present a forged certificate.

7.3 Administrator Role Protection

There is no single “master device” — any device operated by a user with the administrator role can perform enrollment and revocation operations. The protection is enforced server-side: the enrollment confirmation and revocation endpoints are restricted to authenticated users with the administrator role. A compromised non-admin device cannot enroll or revoke peers. If an administrator account is compromised, the remediation path is through the backend (account recovery, role reassignment), not through a device-level mechanism.

7.4 Key Rotation

Version	Mechanism	Disruption
V1 (current)	Manual: administrator triggers re-pairing	Requires re-enrollment of affected device
V2 (planned)	Automatic: new key pair signed by previous key (chain of trust), 90-day cycle	Transparent to users

8. Data Synchronization

8.1 CRDT Model

Clinical data synchronization relies on a CRDT (Conflict-free Replicated Data Types) model implemented in-house, without third-party libraries. This choice ensures full control over the persistence layer and its compatibility with the existing database schema.

The implementation combines two academic primitives:

Primitive	Reference	Role
Hybrid Logical Clocks (HLC)	Kulkarni, Demirbas et al. (2014) [28]	Causal ordering of distributed events
Last-Writer-Wins Register (LWW)	Shapiro, Preguiça et al. (2011) [29]	Deterministic per-row conflict resolution

Every domain record (patients, assessments, prescribers, templates, formulations) carries a hybrid logical clock, the identifier of the workstation that performed the last write, and a logical deletion marker (tombstone). These metadata allow each workstation to determine, autonomously and without centralized coordination, which version of a record prevails.

8.2 Synchronization Protocol

Synchronization between peers follows a notification-request-transfer sequence, transmitted exclusively over the Noise KK encrypted channel (fail-closed):

Notification: a workstation that has accumulated local writes notifies its peers.
Request: the receiving peer responds with a synchronization request, including its knowledge vector (§8.3) as causal context.
Transfer: the notifying peer computes the minimal delta and transmits it in paginated form. The receiver drives pagination until the changeset is exhausted. Pagination is fault-tolerant: if an interruption occurs mid-transfer, recovery on reconnect resumes without data loss.
Acknowledgment: a bidirectional completion signal ensures post-synchronization operations (certificate propagation, lock reconciliation) only begin after both peers have fully converged.

The merge respects topological order (parents before children) to satisfy referential integrity constraints.

8.3 Knowledge Vector

When a new workstation joins the network, existing peers have no shared history, which would force a complete redundant transfer. With N workstations, the cost would be O(N²) in transferred volume.

The Knowledge Vector solves this problem by implementing a formal delta-state model (Almeida, Shoker and Baquero, 2018 [30]). Each peer maintains a state map representing, for each known writing node, the most recent clock observed. During a synchronization request, the peer sends this map; the responder computes the minimal delta — only data the requester has not yet seen is transmitted.

The vector is maintained with monotonic update semantics. Under fault conditions — including backup restore — consistency is preserved by rebuilding the vector from the actual dataset.

8.4 Conflict Resolution

LWW arbitration: when two peers modify the same record, the write with the most recent clock wins. The CvRDT properties (commutativity, associativity, idempotence) guarantee convergence regardless of message reception order.

Logical deletions (tombstones): deletions are represented by a marker rather than a physical deletion. This mechanism is required for CRDT convergence: a physical deletion would be invisible during merge and would cause the record to be resurrected by a peer that has not yet received the deletion.

Business key deduplication: when a merge produces a duplicate record (e.g., the same patient created independently on two workstations), a deterministic resolution strategy based on clock ordering ensures both workstations converge to the same outcome without coordination.

8.5 Synchronization State Persistence

Per-peer synchronization cursors are persisted locally and advance monotonically. Upon backup restore, cursors are reset to force a complete resynchronization — preserving data integrity across restore boundaries.

9. File Synchronization

9.1 Architecture

Files associated with assessments (PDF/Word exports, previews, attachments) are synchronized via a dedicated CRDT register. Each file entry carries CRDT metadata and a SHA-256 integrity checksum.

File synchronization progresses independently from data synchronization, via a separate cursor namespace.

9.2 Transfer Protocol

The protocol operates in two phases, both encrypted via Noise KK:

Index phase: peers exchange file change notifications and identify which files require transfer based on CRDT cursors.

Transfer phase: files are transferred sequentially with per-file SHA-256 integrity verification before write to disk.

9.3 Cross-Platform Integrity

All relative paths stored and exchanged follow a single canonical convention, regardless of platform (macOS, Windows). Normalization is enforced at filesystem boundaries to prevent cross-platform path divergence.

10. Distributed Locking

10.1 Model

The system implements pessimistic per-resource locking (patient, assessment, prescriber, template, formulation) to prevent concurrent editing conflicts. The first writer obtains the lock (first-writer-wins via logical clock comparison).

Three message types handle coordination, all exclusively encrypted (fail-closed): lock request, lock release, and full state (sent on connection and enriched in heartbeats).

10.2 Properties

Property	Value
Connection timeout	Configurable — automatic release of disconnected peer’s locks
Stale lock safety net	Maximum hold duration enforced
Guarded mutation surfaces	All write operations in the interface (deletion, editing, finalization)
Heartbeat reconciliation	Periodic — detects and corrects asymmetric lock state

Heartbeat reconciliation is a defense-in-depth mechanism: peers periodically exchange lock state summaries and correct any divergences caused by coordination messages lost during transient disconnections.

11. Backup/Restore Isolation

Backup and restore are exclusive operations that replace the local dataset. The entire synchronization layer (discovery, connections, data, files, locks) is stopped for the duration of the operation to prevent intermediate state propagation or cascading side effects. Peers observe a clean disconnection. Synchronization is restarted systematically after the operation completes, and peers reconnect for a clean resynchronization.

12. Data Boundary: What the Server Sees

Data	Touches the server?	Purpose
Patient records, assessments, files	No — peer-to-peer, encrypted	—
Session keys (ephemeral)	No — never leave RAM	—
Device public keys	Yes — at pairing only	Certificate signing
CA private key	Yes — encrypted at rest	Certificate operations
CRL	Yes — signed, public by nature	Revocation propagation
Synchronization cursors	No — LAN only, encrypted	Sync progress tracking (local SQLite)
Knowledge vectors	No — LAN only, encrypted	Delta-state sync (local SQLite)
Lock state	No — LAN only, encrypted	Access coordination (in-memory, not persisted)
File index (paths + HLC)	No — LAN only, encrypted	Sync file registry (local SQLite)
Device names	Partially — NSD on LAN + backend (device registration)	Visual device identification

The server is a trusted third party for identity — it certifies which devices belong to which practice. It is not a data intermediary. It never sees, processes, or stores any clinical data. This separation is enforced architecturally: the data plane operates exclusively on the LAN, and the backend has no API endpoint that accepts or returns clinical data.

13. Regulatory Alignment

Article	Requirement	Implementation
Art. 5.1.f	Integrity and confidentiality	Noise KK AEAD, forward secrecy, anti-replay
Art. 25	Data protection by design and by default	Security designed before implementation (4 design audits); no degraded mode
Art. 32.1.a	Encryption of personal data	End-to-end encryption on all synchronization channels
Art. 32.1.b	Ongoing confidentiality, integrity, availability	CRL revocation, fail-close, gossip propagation
Art. 32.1.d	Regular testing and evaluation	Cacophony test vectors, security audits
Art. 9	Special categories (health data)	Data never leaves local network; no server-side processing

13.2 ISO/IEC 27001:2022 Annex A Control Mapping

Control	Title	Implementation
A.5.15	Access control	Role separation: administrator (pairing, revocation) vs. member (sync). Enforced server-side on every API call
A.5.28	Collection of evidence	Security event logging: pairing attempts, handshake failures, revocations, replay detections
A.8.9	Configuration management	Key material managed centrally (CA backend); device configuration via secure storage
A.8.10	Information deletion	Device revocation triggers CRL update; key material destroyed on revocation
A.8.24	Use of cryptography	Algorithm selection per ANSSI-PA-079 [15] and NIST SP 800-57 [8]; no custom cryptography; Noise KK framework
A.8.25	Secure development lifecycle	4 security audits during design phase; formal verification cited; test vector validation
A.8.26	Application security requirements	Fail-hard on secure storage failure; no cleartext fallback; rate limiting on pairing

Note: Ocureo is not ISO 27001 certified. This mapping documents the alignment of the cryptographic architecture with relevant Annex A controls. ISO 27001 certification is an organizational process that extends beyond technical measures.

13.3 ANSSI Compliance

All individual cryptographic algorithms used are recommended by the ANSSI Guide de sélection d’algorithmes cryptographiques (ANSSI-PA-079, 2021) [15]:

Ed25519: recommended for digital signatures
X25519: recommended for key agreement
ChaCha20-Poly1305: recommended for authenticated encryption
SHA-256 / HKDF: recommended for hashing and key derivation

The Noise Protocol Framework itself has not been evaluated by the ANSSI; its security properties rely on independent academic proofs [11][12][13][14].

13.4 HDS (Hébergement de Données de Santé)

HDS certification (French health data hosting regulation, Décret n° 2018-137) applies to organizations that host health data on behalf of a healthcare provider. In Ocureo’s architecture, clinical data never leaves the local network and is never hosted on Dokitek servers. HDS certification is therefore not required for the synchronization feature. However, the architectural foundations (key management, access control, audit trail) are designed to support a future HDS certification trajectory if the product scope evolves.

14. Validation

14.1 Implementation Conformance

The Noise KK implementation is validated against the cacophony reference test vectors — the standard test suite for Noise Protocol implementations. Each test injects known keys, executes the handshake and 4 transport messages, and verifies that every output byte matches the expected values bit-for-bit. This is the strictest available conformance test for Noise Protocol implementations.

The test vectors are maintained by the Noise Protocol community and are used by reference implementations in Haskell, Rust, and Go. Passing these vectors confirms that our implementation correctly follows the Noise KK specification [1].

14.2 Security Audits

Four security audits were conducted during the design and implementation phases:

Audit	Phase	Scope	Findings	Resolution
V1 — Cryptographic stack review	Pre-implementation	Algorithm selection, threat model	2 High, 4 Medium, 3 Low, 2 Info	All High/Medium resolved. Recommendation to adopt Noise KK applied.
V2 — Trust chain review	Pre-implementation	CA architecture, pairing protocol, phase sequencing	2 High, 6 Medium, 3 Low, 3 Info	All High resolved. Security phase reordered before data phase.
V3 — Post-implementation review	After development	Conformance to design, code-level issues	Critical-severity findings	All resolved within 24 hours.
V4 — Cryptographic migration	Post-implementation	Migration to an audited, widely-deployed cryptographic library (libsodium)	1 High (single-author dependency)	Resolved. Abstraction layer decouples protocol code from the cryptographic implementation. Conformance re-validated via cacophony test vectors.

14.3 CVE Protections

Vulnerability class	Protection
Nonce increment on decrypt failure (cf. CVE-2024-58265 in the Rust `snow` library)	Counter does not advance on decryption failure; this vulnerability class is addressed by design
Neutral point attack (X25519)	Null public keys rejected at handshake
Downgrade attack (cleartext fallback)	No degraded mode — encryption or no connection
Nonce exhaustion	Ceiling checked before every encryption operation

15. Known Limitations

Transparency about the current limitations of the architecture:

Limitation	Impact	Mitigation	Planned resolution
No automatic key rotation (V1)	Long-lived static keys increase window of exposure if compromised	Forward secrecy limits impact to metadata; re-pairing available	V2: automatic rotation with chain of trust
No HSM for master key	Master key in AWS SSM (KMS-backed), not in dedicated HSM	KMS provides envelope encryption and access logging; acceptable for the risk profile of small practices	Cost-prohibitive; revisit if product moves to hospital segment
Single-author library bindings	The language bindings to the cryptographic library are maintained by a single author	Risk mitigated: (1) the cryptographic core (libsodium) is a multi-contributor, audited project used by Signal, 1Password, Cloudflare; (2) the bindings are mechanically simple and forkable; (3) an abstraction layer decouples protocol code from the binding	The single point of failure is on the binding layer, not on the cryptographic implementation
Internet required for pairing	New device enrollment impossible during backend outage	Existing sessions continue on LAN; outage only affects enrollment	Architectural constraint (CA-backend model)
Device identifier visible on LAN	Device identifiers are visible during local network discovery. No data access is possible from this information alone	Planned mitigation: derived identifiers replacing direct values in discovery records	Post-v1
No CRDT tombstone garbage collection	Soft-deleted records (`is_deleted = 1`) accumulate indefinitely	Marginal impact at current volumes (a few thousand rows)	Compaction planned for post-v1
File sync session orphan	If a peer disconnects mid-transfer, dependent sessions may stall until reconnection	Automatic recovery on reconnection: synchronization state has not advanced, so the transfer resumes cleanly	Timeout-based cleanup to evaluate post-v1

System	Encryption	Identity model	Cost	Key difference with Ocureo
Doctolib (via Tanker acquisition)	Partial E2E (document exchange)	PKI (Tanker SDK)	135-149 EUR/month	Acquired capability (~25-30M EUR). Covers document exchange, not full sync.
Matter/Thread [18]	AES-128-CCM sessions	Commissioner signs NOC certificates	— (IoT standard)	Commissioner is a local device; CA key on device (weaker isolation).
Tailscale	WireGuard (Noise IK)	Coordination server distributes keys	$5-18/user/month	No certificate signing; keys distributed, not certified.
Syncthing	TLS 1.3	Device IDs (self-signed), Introducer for trust propagation	Free (open source)	No centralized CA; TOFU model; Introducer is advisory, not authoritative.
Signal	X3DH + Double Ratchet (Noise-based)	Pre-key server + safety numbers	Free	No PKI; TOFU + QR code verification. Different threat model (global, asynchronous).
Ocureo	Noise KK (full E2E)	Backend CA signs device certificates	~20 EUR/month	CA key server-side (strongest isolation); offline verification; included in base subscription.

Ocureo uses the same cryptographic framework as Signal and WireGuard (Noise Protocol), but in a different pattern (KK vs. IK/XX) optimized for a closed, pre-authenticated network where all participants’ static keys are certified by a common authority. The architecture is not comparable to Signal’s, which addresses a fundamentally different problem (asynchronous messaging between strangers) requiring additional properties (post-compromise security, deniability) outside the scope of Noise KK.

17. References

Specifications and Standards

#	Document	Reference
[1]	Noise Protocol Framework, Revision 34	noiseprotocol.org/noise.html
[2]	RFC 7748 — Elliptic Curves for Security (X25519)	rfc-editor.org/rfc/rfc7748
[3]	RFC 8032 — Edwards-Curve Digital Signature Algorithm (Ed25519)	rfc-editor.org/rfc/rfc8032
[4]	RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols	rfc-editor.org/rfc/rfc8439
[5]	RFC 5869 — HMAC-based Extract-and-Expand KDF (HKDF)	rfc-editor.org/rfc/rfc5869
[6]	RFC 5280 — Internet X.509 PKI Certificate and CRL Profile	rfc-editor.org/rfc/rfc5280
[27]	RFC 6189 — ZRTP: Media Path Key Agreement for Unicast Secure RTP	rfc-editor.org/rfc/rfc6189

NIST Publications

#	Document	Reference
[7]	NIST SP 800-207 — Zero Trust Architecture	csrc.nist.gov/pubs/sp/800/207/final
[8]	NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management	csrc.nist.gov/publications/detail/sp/800-57-part-1/rev-5/final
[9]	NIST SP 800-57 Part 2 Rev. 1 — Best Practices for Key Management Organizations	csrc.nist.gov/publications/detail/sp/800-57-part-2/rev-1/final

Academic Publications (Formal Verification of Noise Protocol)

#	Document	Reference
[11]	Noise* — A Library of Verified High-Performance Secure Channel Protocol Implementations (IEEE S&P 2022, Inria)	eprint.iacr.org/2022/607
[12]	Noise Explorer — Fully Automated Modeling and Verification for Arbitrary Noise Protocols (Kobeissi et al., 2018)	eprint.iacr.org/2018/766
[13]	Flexible Authenticated and Confidential Channel Establishment (fACCE): Analyzing the Noise Protocol Framework (Dowling, 2019)	eprint.iacr.org/2019/436
[14]	A Spectral Analysis of Noise: A Comprehensive, Automated, Formal Analysis of Diffie-Hellman Protocols (Girol et al., USENIX Security 2020)	usenix.org/system/files/sec20-girol_0.pdf

CRDT and Distributed Systems

#	Document	Reference
[28]	Kulkarni, S., Demirbas, M., Madappa, D., Avva, B., Leone, M. “Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases.” 2014.	cse.buffalo.edu/tech-reports/2014-04.pdf
[29]	Shapiro, M., Preguica, N., Baquero, C., Zawirski, M. “A comprehensive study of Convergent and Commutative Replicated Data Types.” INRIA Research Report RR-7506, 2011.	inria.hal.science/inria-00555588
[30]	Almeida, P.S., Shoker, A., Baquero, C. “Delta State Replicated Data Types.” Journal of Parallel and Distributed Computing, 111, 2018.	doi.org/10.1016/j.jpdc.2017.08.003

ANSSI / French Regulatory

#	Document	Reference
[15]	ANSSI-PA-079 — Guide de sélection d’algorithmes cryptographiques (2021)	cyber.gouv.fr/publications/mecanismes-cryptographiques
[16]	RGS v2.0 — Référentiel Général de Sécurité	cyber.gouv.fr/le-referentiel-general-de-securite-version-20-les-documents

Industry References

#	Document	Reference
[18]	Matter Security & Privacy Fundamentals (CSA, 2022)	csa-iot.org
[21]	Signal X3DH Specification	signal.org/docs/specifications/x3dh/

Regulatory

#	Document	Reference
[22]	ISO/IEC 27001:2022 — Information Security Management Systems	iso.org/standard/27001
[23]	ISO/IEC 27002:2022 — Information Security Controls	iso.org/standard/75652.html
[26]	GDPR — Regulation (EU) 2016/679	eur-lex.europa.eu

Dokitek SARL, mars 2026. Ce document décrit l'architecture cryptographique implémentée au 23 mars 2026. Il ne constitue ni une certification ni un engagement contractuel.

Sécurité des données de santé

Résumé

Table des matières

1. Modèle de menace

1.1 Actifs protégés

1.2 Modèle d’attaquant

1.3 Hypothèses de confiance

1.4 Objectifs de sécurité

2. Vue d’ensemble de l’architecture

2.1 Pile protocolaire

2.2 Séparation fonctionnelle

3. Identité des postes et gestion des clés

3.1 Génération des clés

3.2 Stockage des clés

3.3 Cycle de vie des clés

4. Autorité de Certification intégrée

4.1 Justification du choix de conception

4.2 Hiérarchie des clés CA

4.3 Propriétés de sécurité

4.4 Comparaison avec des précédents industriels

5. Protocole d’appairage

5.1 Séquence protocolaire

5.2 Dérivation du SAS (Short Authentication String)

5.3 Gossip de certificats

6. Chiffrement de session : Noise KK

6.1 Choix du pattern

6.2 Suite cryptographique

6.3 Vérification formelle

6.4 Propriétés de sécurité

7. Révocation et cycle de vie des certificats

7.1 Certificate Revocation List (CRL)

7.2 Politique fail-close

7.3 Protection du rôle administrateur

7.4 Rotation des clés

8. Synchronisation des données

8.1 Modèle CRDT

8.2 Protocole de synchronisation

8.3 Vecteur de connaissance (Knowledge Vector)

8.4 Résolution de conflits

8.5 Persistance de l’état de synchronisation

9. Synchronisation des fichiers

9.1 Architecture

9.2 Protocole de transfert

9.3 Intégrité cross-platform

10. Verrouillage distribué

10.1 Modèle

10.2 Propriétés

11. Isolation sauvegarde/restauration

12. Périmètre des données : ce que voit le serveur

13. Conformité réglementaire

13.1 Correspondance RGPD

13.2 Correspondance avec les contrôles de l’Annexe A ISO/IEC 27001:2022

13.3 Conformité ANSSI

13.4 HDS (Hébergement de Données de Santé)

14. Validation

14.1 Conformité de l’implémentation

14.2 Audits de sécurité

14.3 Protections contre les CVE

15. Limites connues

16. État de l’art

17. References

Specifications and Standards

NIST Publications

Academic Publications (Formal Verification of Noise Protocol)

CRDT and Distributed Systems

ANSSI / Réglementation française

Industry References

Regulatory

Abstract

Table of Contents

1. Threat Model

1.1 Protected Assets

1.2 Attacker Model

1.3 Trust Assumptions

1.4 Security Goals

2. Architecture Overview

2.1 Protocol Stack

2.2 Functional Separation

3. Device Identity and Key Management

3.1 Key Generation