Modèle de menace public
CryptPeer® est conçu pour réduire les risques techniques et opérationnels dans des environnements sensibles : infrastructures critiques, organisations souveraines, environnements auto-hébergés, réseaux fermés ou déconnectés.
Les adversaires pris en compte au niveau public comprennent notamment :
- Adversaire réseau — interception, observation, altération de trafic, tentatives de type MITM.
- Adversaire serveur — compromission du serveur relais, accès à la base, au code servi ou aux métadonnées techniques.
- Adversaire local — compromission du terminal client, malware, vol de poste, analyse post-mortem.
- Adversaire visuel — observation directe, capture d’écran, exposition temporaire de contenus affichés.
- Adversaire organisationnel — erreur de configuration, cloisonnement insuffisant, gouvernance inadaptée.
Le principe directeur est le suivant : le serveur ne doit pas constituer une source de clair ni une racine de secrets applicatifs.
Protection des clés et sécurité des accès
La différenciation de CryptPeer repose en particulier sur la protection locale des clés applicatives.
- Système à clé segmentée : CryptPeer s’appuie sur un système d’authentification à clé segmentée pour limiter l’exposition directe de la racine locale d’application.
- Exposition éphémère des secrets utiles : les clés de travail sont dérivées localement et ne doivent être conservées que pour la durée strictement nécessaire.
- Absence de centralisation des secrets structurants : le serveur relais n’est pas conçu pour détenir la racine de déchiffrement applicative.
- Authentification complémentaire : selon la configuration, des mécanismes tels que 2FA TOTP peuvent être activés pour renforcer la sécurité d’accès aux comptes.
Les mécanismes détaillés de dérivation et de hiérarchie de clés sont documentés dans la spécification cryptographique publique.
Cryptographie et architecture de sécurité
Les primitives publiques utilisées et les propriétés de sécurité normatives sont documentées dans les spécifications.
- Chiffrement authentifié : AES-256-GCM pour les contenus applicatifs.
- Dérivations : PBKDF2-HMAC-SHA-256, HKDF-SHA-256 et usages publics documentés de SHA-256 / SHA-3.
- Séparation des usages : distinction entre clés de conversation, de fichier, d’affichage et de session.
- Dérivation locale à la demande : réduction de la valeur d’une compromission serveur isolée.
- Approche symétrique robuste : conception orientée robustesse de long terme des briques symétriques.
Spécifications cryptographiques →
Sécurité opérationnelle et résilience
La sûreté opérationnelle ne dépend pas uniquement des algorithmes. Elle repose aussi sur l’architecture de déploiement, la maîtrise de l’infrastructure et la continuité d’exploitation.
- Auto-hébergement : maîtrise du serveur relais, du stockage et des politiques de déploiement.
- Modes local-only et réseaux fermés : fonctionnement possible sans dépendance structurelle à un cloud de messagerie tiers.
- Sauvegardes chiffrées : stratégie de résilience et de restauration sans exposition des contenus en clair.
- Modes de réduction de persistance : selon la configuration, limitation des traces durables, de l’historique ou de la persistance serveur.
- Réduction des dépendances externes : cohérence avec une approche de souveraineté opérationnelle.
Minimisation des traces et protection de la confidentialité
CryptPeer® adopte une logique de minimisation des informations exploitables :
- réduction de l’exposition des métadonnées non nécessaires ;
- pas de dépendance structurelle à des services d’analytics ou de profilage pour le produit souverain ;
- limitation de la persistance locale ou serveur selon les modes opératoires ;
- réduction de l’exposition visuelle grâce à des modes de protection d’affichage lorsque la configuration le prévoit.
Cette logique ne signifie pas l’absence absolue de toute trace technique, mais la réduction systématique des traces évitables et des dépendances non essentielles.
Conformité et cadre cyber
CryptPeer s’inscrit dans une logique de conformité et de maîtrise des risques. Le niveau exact d’obligation dépend du produit déployé, du licencié, du secteur d’activité et du périmètre réglementaire applicable.
- Cyber Resilience Act (CRA)
- Déclaration UE de conformité (CRA)
- RGPD : minimisation des données, protection des contenus et réduction des dépendances à des tiers.
- NIS2 : maîtrise de l’infrastructure et réduction des dépendances critiques externes.
- DORA : pertinence selon le statut de l’entité exploitante et le périmètre financier concerné.
- Double usage / Dual-Use : analyse au cas par cas selon les usages, juridictions et régimes applicables.
Sécurité du site cryptpeer.com
Le site web de présentation applique une logique de sécurité par conception cohérente avec le positionnement général de CryptPeer®.
Principes de sécurité appliqués au site
- HTTPS pour le transport sécurisé des contenus.
- Headers de sécurité configurés pour réduire les risques courants d’intégration et d’exposition navigateur.
- Politique de contenu restrictive (CSP) afin de limiter la surface d’exécution de ressources tierces.
- Intégrité des ressources externes lorsque cela est applicable sur les dépendances CDN.
- Surface d’attaque réduite grâce à une architecture majoritairement statique.
- Réduction du tracking et limitation des composants non indispensables.
- HTTPS obligatoire — objectif de transport chiffré pour l’ensemble du site.
- Headers de sécurité — protection contre le clickjacking, le MIME sniffing, certaines fuites de referrer et réduction de la surface d’exécution.
- Surface d’attaque minimale — architecture principalement statique, sans logique applicative serveur complexe pour la présentation publique.
- Réduction des composants non nécessaires — limitation des scripts, dépendances et services externes superflus.
- Cookies et consentement — gestion locale et transparente des préférences lorsque des cookies techniques sont utilisés.
- Bonnes pratiques d’intégration — usage de liens sécurisés et contrôle des ressources servies.
La sécurité du site vitrine n’est pas assimilable à celle du produit de communication lui-même, mais elle doit rester cohérente avec les exigences de sérieux, de sobriété technique et de réduction de surface d’attaque.
Références publiques utiles
Transparence et évolution
La transparence produit est assurée par la documentation publique, les versions publiées et les notes de version. Les éléments sensibles ou susceptibles d’affaiblir la sécurité par sur-divulgation ne sont pas exposés publiquement.