VORQYN · Livre blanc sécurité · Architecture de sécurité

01 / VISUAL SECURITY LAB

Explorer l’architecture

Explorez la dérivation des clés, les enregistrements chiffrés, les écritures, la synchronisation et leurs limites de sécurité à travers des schémas interactifs.

INTERACTIVE · SECURITY ENGINEERING

Architecture de sécurité

Explication simple

L’interface Flutter gère l’affichage ; le cœur Rust applique les règles cryptographiques, les contrôles de format et les transitions d’état. Les adaptations système et le transport sont séparés.

Limite de sécurité

Un client compromis peut révéler du texte clair lors d’un usage légitime.

Détails techniques

Un client compromis peut révéler du texte clair lors d’un usage légitime.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Mot de passe + Secret Factor

Explication simple

Le Secret Factor est généré aléatoirement sur 256 bits, indépendamment du mot de passe. Il renforce certains scénarios de vol du coffre, mais un logiciel malveillant ayant les mêmes droits peut aussi voler le fichier facteur.

Limite de sécurité

Un Factor local ne constitue pas automatiquement une MFA indépendante.

Détails techniques

Un Factor local ne constitue pas automatiquement une MFA indépendante.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Hiérarchie des clés

Explication simple

La clé de déverrouillage ouvre une enveloppe protégeant une clé racine locale LPRK indépendante. Des clés Vault Epoch, DEK de révision et Collection Keys séparent ouverture, chiffrement et partage.

Limite de sécurité

Sans clés de récupération, la perte des secrets peut être définitive.

Détails techniques

Sans clés de récupération, la perte des secrets peut être définitive.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Chiffrement par enregistrement

Explication simple

Chaque modification produit une nouvelle révision chiffrée avec un DEK aléatoire de 256 bits. Les révisions publiées ne sont pas remplacées directement.

Limite de sécurité

Les anciennes révisions peuvent rester selon la politique de conservation.

Détails techniques

Chaque modification produit une nouvelle révision chiffrée avec un DEK aléatoire de 256 bits. Les révisions publiées ne sont pas remplacées directement.

Les anciennes révisions peuvent rester selon la politique de conservation.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Écriture atomique et récupération

Explication simple

L’écriture suit une séquence : valider, créer une révision et un DEK, chiffrer, écrire temporairement, synchroniser, publier les objets, puis publier le commit et actualiser le head.

Limite de sécurité

Des objets absents ou du matériel défaillant peuvent empêcher la récupération.

Détails techniques

L’écriture suit une séquence : valider, créer une révision et un DEK, chiffrer, écrire temporairement, synchroniser, publier les objets, puis publier le commit et actualiser le head.

Des objets absents ou du matériel défaillant peuvent empêcher la récupération.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Monolithe ou stockage objet

Explication simple

Changer un mot de passe dans un coffre de 100 Go crée normalement de nouveaux objets ciblés plutôt que de réécrire tous les objets. Les octets transférés doivent être mesurés.

Limite de sécurité

D’autres architectures utilisent aussi efficacement la synchronisation delta.

Détails techniques

Changer un mot de passe dans un coffre de 100 Go crée normalement de nouveaux objets ciblés plutôt que de réécrire tous les objets. Les octets transférés doivent être mesurés.

D’autres architectures utilisent aussi efficacement la synchronisation delta.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Graphe de commits authentifiés

Explication simple

Les commits authentifiés référencent les objets et leurs parents. Des appareils peuvent créer plusieurs branches valides ; l’horodatage seul ne doit pas décider.

Limite de sécurité

Un fournisseur malveillant peut dissimuler des commits authentiques.

Détails techniques

Les commits authentifiés référencent les objets et leurs parents. Des appareils peuvent créer plusieurs branches valides ; l’horodatage seul ne doit pas décider.

Un fournisseur malveillant peut dissimuler des commits authentiques.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Synchronisation de bout en bout

Explication simple

Les clients chiffrent avant l’envoi et vérifient après téléchargement. Les nouveaux objets précèdent le commit qui les référence ; le travail hors ligne crée éventuellement des branches.

Limite de sécurité

Le fournisseur peut supprimer, retarder ou rejouer des objets.

Détails techniques

Les clients chiffrent avant l’envoi et vérifient après téléchargement. Les nouveaux objets précèdent le commit qui les référence ; le travail hors ligne crée éventuellement des branches.

Le fournisseur peut supprimer, retarder ou rejouer des objets.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Intégrité ≠ fraîcheur

Explication simple

Un AEAD valide ne prouve pas que le coffre est récent. Un ancrage de fraîcheur indépendant est nécessaire pour détecter de manière fiable certains retours arrière complets.

Limite de sécurité

Un retour arrière complet nécessite un ancrage indépendant fiable.

Détails techniques

Un AEAD valide ne prouve pas que le coffre est récent. Un ancrage de fraîcheur indépendant est nécessaire pour détecter de manière fiable certains retours arrière complets.

Un retour arrière complet nécessite un ancrage indépendant fiable.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Droits Business & Enterprise

Explication simple

Les rôles Owner, Admin, Editor et Viewer ne remplacent pas les permissions cryptographiques. Les Collections disposent de clés séparées ; les textes déjà connus ne peuvent être retirés.

Limite de sécurité

Un texte clair déjà connu ne peut pas être retiré rétroactivement.

Détails techniques

Les rôles Owner, Admin, Editor et Viewer ne remplacent pas les permissions cryptographiques. Les Collections disposent de clés séparées ; les textes déjà connus ne peuvent être retirés.

Un texte clair déjà connu ne peut pas être retiré rétroactivement.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Modèle de menace

Explication simple

Le modèle couvre vol, manipulation, panne, disque plein, serveur compromis, rollback et appareil infecté. Chaque protection conserve une limite explicite.

Limite de sécurité

Aucune protection isolée ne couvre toutes les menaces.

Détails techniques

Le modèle couvre vol, manipulation, panne, disque plein, serveur compromis, rollback et appareil infecté. Chaque protection conserve une limite explicite.

Aucune protection isolée ne couvre toutes les menaces.

Lire le chapitre ↗

INTERACTIVE · SECURITY ENGINEERING

Audit et preuves

Explication simple

Les audits exigent des contrats vérifiables : formats, KDF, AAD, nonce, commits, erreurs, persistance, signatures et builds effectivement livrés.

Limite de sécurité

Les invariants de sécurité sont reliés aux contrats techniques, au code, aux tests et à la validation des plateformes.

Détails techniques

Les audits exigent des contrats vérifiables : formats, KDF, AAD, nonce, commits, erreurs, persistance, signatures et builds effectivement livrés.

Les invariants de sécurité sont reliés aux contrats techniques, au code, aux tests et à la validation des plateformes.

Lire le chapitre ↗

02 / TECHNICAL REFERENCE · V1.2

Référence technique

La référence technique présente les mécanismes cryptographiques, formats, hypothèses de menace, erreurs et choix d’architecture. Cette édition contient des synthèses techniques et des liens vers la référence allemande complète.

01La sécurité est fondamentale+

La sécurité couvre tout le cycle de vie des secrets : création, consultation, modification, synchronisation, restauration et suppression. Les pannes font partie du modèle, pas seulement les attaques.

Architecture de sécuritéAu cœur de VORQYN.

Explorer l’architecture

Architecture de sécurité

Mot de passe + Secret Factor

Hiérarchie des clés

Chiffrement par enregistrement

Écriture atomique et récupération

Monolithe ou stockage objet

Graphe de commits authentifiés

Synchronisation de bout en bout

Intégrité ≠ fraîcheur

Droits Business & Enterprise

Modèle de menace

Audit et preuves

Référence technique

La sécurité est un choix d’architecture.