Pourquoi le chiffrement de bout en bout est important pour l'édition de PDF

Vous devez caviarder un numéro de sécurité sociale sur un formulaire numérisé. Ou valider un document d'admission patient avant de l'envoyer à un spécialiste. Ou retirer un montant de salaire d'un fichier RH avant de le transmettre à quelqu'un hors de l'entreprise. Vous ouvrez un navigateur, cherchez un éditeur PDF en ligne et téléversez le fichier.

Ce qui arrive ensuite à ce document est quelque chose à quoi la plupart des gens ne pensent jamais.

Comment la plupart des outils PDF en ligne traitent vos fichiers

Quand vous téléversez un fichier dans un éditeur PDF web typique, le fichier voyage vers un serveur distant détenu par cette entreprise. Le serveur l'ouvre, le traite — rotation de pages, application de caviardages, aplatissement de champs de formulaire — puis renvoie le résultat ou stocke une copie temporairement.

Pendant tout ce processus, le PDF est lisible sur leur infrastructure. Un employé avec accès au serveur pourrait l'ouvrir. Une assignation ou demande gouvernementale pourrait contraindre l'entreprise à le remettre. Un bucket S3 mal configuré, une brèche dans leur base de données ou une sauvegarde compromise pourrait l'exposer.

La plupart des prestataires sont francs sur le stockage de fichiers sur une courte fenêtre — quelques heures ou une journée — avant suppression. C'est une amélioration significative par rapport à un stockage indéfini, mais «supprimé à terme» n'est pas la même chose que «jamais lisible». Le fichier a existé en clair sur leurs systèmes, et cette fenêtre est la surface d'attaque.

Le modèle de confiance est : vous faites confiance à l'entreprise, à ses employés, à son infrastructure, à ses pratiques de sécurité et à sa juridiction. Pour un document anodin, ça va. Pour quoi que ce soit de sensible, c'est un saut significatif.

Ce que signifie vraiment le chiffrement de bout en bout

Le chiffrement de bout en bout (E2EE) change le modèle de confiance fondamentalement.

Avec l'E2EE, le chiffrement se passe dans votre navigateur avant que le fichier ne quitte votre appareil. Au moment où des octets atteignent un serveur, ils sont déjà transformés en texte chiffré — indiscernable de données aléatoires sans la clé. Le serveur stocke ce texte chiffré, mais ne peut pas le lire. Le déchiffrement se passe dans votre navigateur quand vous rouvrez le document.

Le «bout en bout» renvoie aux deux extrémités : votre appareil est une extrémité, et le destinataire (ou votre vous futur qui rouvre le fichier) est l'autre. Le serveur est au milieu et est délibérément gardé aveugle.

C'est le même modèle utilisé par des applications de messagerie chiffrée comme Signal. La différence : l'appliquer au stockage et à l'édition de fichiers — où il faut enregistrer, recharger et modifier des documents — exige une approche plus en couches qu'un simple échange de messages.

Comment fonctionne le chiffrement de RedaktPDF

RedaktPDF utilise une hiérarchie de clés conçue pour que le serveur soit cryptographiquement empêché d'accéder à vos documents — pas seulement engagé contractuellement à la confidentialité, mais techniquement incapable.

Quand vous activez le chiffrement, votre mot de passe passe dans PBKDF2 (600 000 itérations) pour dériver une clé maîtresse. Cette clé maîtresse ne quitte jamais votre navigateur. Elle sert à wrapper une clé de chiffrement de clé (KEK), qui à son tour wrappe une clé de fichier (FK) par document. Les versions chiffrées de ces clés — inutiles sans votre mot de passe — sont stockées sur le serveur. Les versions en clair n'existent qu'en mémoire dans votre onglet de navigateur.

Quand vous téléversez un document, le navigateur chiffre les octets du PDF, les images de page et le texte extrait avec AES-256-GCM via la clé de fichier avant qu'aucune donnée ne soit envoyée. Ce que le serveur reçoit, ce sont des blobs chiffrés. Quand vous rouvrez le document, le navigateur récupère ces blobs, dérive les clés depuis votre mot de passe et déchiffre localement. Le serveur n'est jamais impliqué dans l'étape de déchiffrement.

Quand vous exportez depuis l'éditeur PDF sécurisé, le document édité est assemblé et téléchargé directement depuis votre navigateur — il n'est jamais re-téléversé au serveur sous forme déchiffrée.

Résultat pratique : même si la base de données du serveur était compromise demain, l'attaquant n'aurait qu'un tas de données chiffrées et de clés wrappées qu'il ne peut pas unwrapper sans votre mot de passe.

Quand l'E2EE compte le plus

Tous les PDF n'ont pas besoin de chiffrement. Une recette que vous avez numérisée, un billet de concert, un prospectus — ce n'est pas sensible. Mais une part étonnamment grande des documents que les gens éditent en ligne est sensible, même quand la personne qui les téléverse ne s'arrête pas pour y réfléchir :

Les dossiers médicaux sont le cas le plus clair. HIPAA exige des entités couvertes qu'elles protègent les informations de santé des patients, et la définition de «protégé» s'étend à tout prestataire que vous utilisez pour traiter ces informations. Téléverser un dossier patient dans un outil en ligne standard peut enfreindre vos obligations de conformité, quelle que soit la politique de confidentialité du prestataire.

Les documents juridiques — contrats, accords transactionnels, documents de planification successorale — contiennent souvent des clauses ou des montants qu'une partie a de fortes raisons de garder confidentiels. Les faire passer par un serveur tiers crée un risque de discovery auquel vous n'aviez peut-être pas pensé.

Les états financiers — déclarations fiscales, exports de comptes-titres, dossiers de prêt — contiennent exactement les données que ciblent les voleurs d'identité. Numéros de sécurité sociale, numéros de compte, montants de revenu. Avant de partager l'un d'eux, caviardez d'abord les champs sensibles, puis chiffrez le document pour le transit.

Les documents RH — lettres d'offre, évaluations de performance, données de rémunération, accords de rupture — peuvent exposer des individus et créer une responsabilité juridique en cas de divulgation.

Tout document contenant des PII — noms combinés à des adresses, dates de naissance, numéros d'identité ou informations médicales — comporte un risque au regard des lois sur la vie privée dans la plupart des juridictions.

Si vous éditez l'un d'eux, la question n'est pas de savoir si le chiffrement compte. C'est de savoir si l'outil que vous utilisez le fournit.

Contre quoi l'E2EE ne protège pas

Il est important d'être clair sur les limites, parce que surévaluer la sécurité d'un système est sa propre forme de tromperie.

L'E2EE n'empêche pas les captures d'écran. Quelqu'un qui a accès à votre écran — via partage d'écran, malware ou proximité physique — peut capturer ce qui est affiché. Le chiffrement protège les données en transit et au repos, pas les données rendues à l'écran.

L'E2EE ne protège pas contre un appareil compromis. Si votre navigateur, votre système d'exploitation ou votre appareil a été compromis par un malware, un attaquant peut intercepter les données déchiffrées avant que le chiffrement n'ait lieu ou après que le déchiffrement soit terminé. Le chiffrement ne remplace pas la sécurité de l'appareil.

L'E2EE ne signifie pas zero-knowledge si vous partagez. Si vous envoyez un document chiffré à un collaborateur, il en reçoit une copie. Cette copie est déchiffrée sur son appareil. Ce qui en advient ensuite est hors de votre contrôle. L'E2EE protège le document de l'infrastructure, pas des personnes avec qui vous le partagez.

L'E2EE ne protège pas les métadonnées de votre compte. Votre adresse e-mail, les noms de documents, les horodatages et les schémas d'accès ne sont pas chiffrés. Le serveur sait que vous avez téléversé un document et quand — il ne peut juste pas lire ce qu'il y a dedans.

Ce ne sont pas des raisons d'éviter le chiffrement. Ce sont des raisons de comprendre quel problème le chiffrement résout et quels problèmes appellent d'autres solutions.

Le réglage par défaut devrait être meilleur

La plupart des outils en ligne se contentent par défaut d'un traitement serveur en clair parce que c'est plus simple à construire et plus simple à expliquer. Le chiffrement demande plus d'ingénierie — gestion des clés, crypto côté navigateur, gestion soignée des changements de mot de passe et de la récupération.

Mais «plus simple à construire» n'est pas une bonne raison d'exposer vos documents. Pour les catégories de fichiers qui comptent — médical, juridique, financier, tout ce qui contient des informations personnelles — le réglage par défaut devrait être que le prestataire ne puisse pas lire vos données même s'il le voulait.

C'est ce que fournit le chiffrement de bout en bout, et c'est ce sur quoi l'éditeur PDF sécurisé de RedaktPDF est construit.