Chiffrement zéro accès par conception
Vos données de profil synchronisées sont chiffrées sur votre appareil avant d'atteindre un serveur, donc le serveur ne stocke que des blobs chiffrés qu'il ne peut jamais lire. Les connexions à l'application de calendrier sont une exception en clair documentée, limitée à votre boîte de réception du calendrier et aux abonnements en lecture seule.
Comment fonctionne le chiffrement
Graspee utilise une hiérarchie de clés côté client. Votre mot de passe et un sel aléatoire passent par PBKDF2 avec 200 000 itérations pour dériver une clé de chiffrement de clé (KEK). La KEK chiffre une clé de chiffrement de données (DEK) générée aléatoirement. La DEK chiffre toutes vos données avec AES-GCM-256. Votre mot de passe ne quitte jamais le navigateur.
Ce que signifie zéro accès
Le serveur ne voit jamais vos données en clair, votre mot de passe ou vos clés de chiffrement. Même avec un accès complet à la base de données, l'opérateur du serveur ne peut pas lire vos notes, tâches, transactions ou tout autre contenu synchronisé. Si vous activez la synchronisation, le serveur relaye des blobs chiffrés entre vos appareils mais ne peut pas les déchiffrer. Les connexions à l'application de calendrier sont une exception documentée : les flux d'abonnement en lecture seule sont des artefacts en clair que les applications de calendrier externes doivent pouvoir lire, et les événements en Ajout rapide envoyés à votre boîte de réception du calendrier sont stockés en clair tant qu'ils sont en attente afin que le navigateur déverrouillé puisse les importer. Après import, ignorance, expiration ou tombstone, le contenu en clair en attente est purgé.
Sécurité de session
Votre DEK est chiffrée sous une clé de session temporaire stockée dans sessionStorage. Elle survit aux rechargements de page mais est effacée à la fermeture du navigateur. Les sessions utilisent des cookies HttpOnly avec les drapeaux SameSite et Secure. La protection CSRF est appliquée via la vérification de l'origine. La limitation de débit protège les endpoints d'authentification.
Chiffrement de la synchronisation
La synchronisation cloud utilise des documents Yjs CRDT chiffrés côté client. Le transport WebSocket ne transporte que des payloads chiffrés. Les vecteurs d'état et les mises à jour sont validés côté serveur pour la taille mais jamais déchiffrés. La compaction utilise le verrouillage optimiste pour éviter la perte de données.
Sécurité des connexions bancaires
Les identifiants des fournisseurs, tels que les jetons d'accès Plaid, les identifiants de connexion Flinks ou les GUID utilisateur/membre MX, sont stockés dans votre shard local chiffré, jamais dans la base de données du serveur. Le serveur agit comme un relais : il transmet les appels API du fournisseur et peut garder les payloads de synchronisation brièvement en mémoire, mais ne stocke aucune donnée fournisseur de manière durable. Les preuves de propriété HMAC lient les jetons à votre compte sans état. Un registre séparé des liens de connexion contient des empreintes HMAC non réversibles des identifiants de connexion fournisseur pour appliquer les limites de liens par utilisateur. Flinks et MX ne sont disponibles que là où l'opérateur les a activés.
Exception relative aux connexions à l'application de calendrier
Les connexions à l'application de calendrier sont une exception en clair intentionnelle et limitée au modèle zéro accès. Les artefacts d'abonnement en lecture seule sont en clair car les applications de calendrier externes doivent pouvoir lire le .ics, et les événements en Ajout rapide depuis votre application sont stockés en clair dans votre boîte de réception du calendrier tant qu'ils sont en attente afin que le navigateur déverrouillé puisse les importer. Le serveur conserve ce contenu en clair en attente dans la boîte de réception ainsi que les artefacts publiés des abonnements en lecture seule ; pour les identifiants et les jetons porteurs, seuls des hachages sont conservés sur le serveur, et le jeton d'abonnement vivant est gardé en stockage local chiffré sur le navigateur déverrouillé. Les événements en attente expirent au bout de 7 jours, et le contenu en clair est purgé après import navigateur, ignorance, expiration ou tombstone. Si une URL d'abonnement fuit, effectuez une rotation depuis Paramètres pour invalider tous les abonnés existants.
Abonnements et paiements
Les paiements d'abonnement sont traités par Stripe via une page de paiement hébergée. Votre numéro de carte, votre date d'expiration, votre CVC, votre adresse de facturation et vos identifiants Stripe Link n'entrent jamais dans l'interface ni dans le backend de Graspee ; ils restent exclusivement dans l'environnement PCI-DSS niveau 1 de Stripe. Graspee conserve les identifiants client et abonnement émis par Stripe nécessaires pour associer l'abonnement à votre compte, ainsi qu'une ligne de corrélation de paiement utilisée pour relancer en toute sécurité un paiement interrompu. La première fois que vous souscrivez, votre adresse e-mail de compte est envoyée à Stripe (en tant que customer_email) et conservée dans l'instantané de requête de la ligne de corrélation afin qu'un paiement relancé puisse être rejoué sous la même clé d'idempotence ; dès que Stripe a émis un identifiant client, seul cet identifiant est transmis lors des tentatives suivantes. L'instantané portant l'e-mail est toujours effacé 24 heures après la création de la tentative, qu'elle soit ouverte, terminée, échouée, ou en attente de règlement différé. La ligne de corrélation elle-même est ensuite supprimée à 90 jours ; les tentatives à règlement différé non encore résolues sont conservées (sans l'e-mail) jusqu'à cette échéance pour permettre la réconciliation de l'événement Stripe à venir, puis supprimées selon la même rétention que les tentatives terminées ou échouées. Chaque changement d'état de facturation est piloté par des webhooks Stripe signés : la signature du webhook est vérifiée par rapport au corps brut de la requête avec HMAC-SHA256 et une tolérance d'horodatage de 5 minutes avant toute modification de l'état du compte. L'accès payant n'est jamais accordé à partir d'une URL de paiement, d'une chaîne de requête ou d'une réponse client ; il découle uniquement d'un abonnement réconcilié. Les charges utiles brutes des webhooks ne sont pas persistées sur le serveur ; le journal d'audit ne conserve que les identifiants d'événement, les types et les hachages des identifiants d'objet Stripe associés.
