HotXLS écrit un bloc dataIntegrity conforme dans les paquets XLSX chiffrés en Agile et le vérifie à l'ouverture. Le HMAC-SHA-512 couvre l'intégralité du flux EncryptedPackage, y compris son préfixe StreamSize de huit octets, et il est vérifié sur le texte chiffré avant que le moindre segment ne soit déchiffré, si bien qu'un mot de passe erroné ou un paquet modifié est détecté plutôt que déchiffré en charabia
Le chiffrement sans intégrité n'est qu'une demi-réponse, et les formats de fichier Office rendent cette lacune facile à négliger, car le chiffrement paraît si complet vu de l'extérieur. Comprendre ce que promet chaque couche est ce qui garde une revue de sécurité brève
Que promet réellement un classeur chiffré ?
Le chiffrement Agile, défini dans [MS-OFFCRYPTO], vous offre la confidentialité via AES en mode CBC avec une clé dérivée d'un hachage de mot de passe SHA-512 itéré. La confidentialité est toute la promesse de cette construction. CBC n'est pas un mode authentifié : il ne dit rien sur le fait que le texte chiffré que vous déchiffrez soit bien celui qui a été écrit
La conséquence pratique est précise. Inversez des bits dans un paquet chiffré et CBC les déchiffrera sans broncher en un texte clair différent. Vous obtiendrez généralement une erreur d'analyse ZIP plus loin dans la chaîne, car un flux deflate corrompu survit rarement, mais « généralement » porte une lourde charge dans cette phrase, et une erreur de parseur en aval est un endroit terrible pour apprendre qu'un fichier a été modifié. L'élément dataIntegrity existe pour répondre directement à la question, avant le déchiffrement, avec un MAC sur les octets exacts
Comment se déroule la vérification, et dans quel ordre
L'ordre est la partie intéressante. HotXLS dérive la clé intermédiaire à partir du mot de passe, déchiffre la clé HMAC chiffrée et la valeur HMAC chiffrée à partir des attributs dataIntegrity en utilisant des IV dérivés par clé de bloc, calcule HMAC-SHA-512 sur le paquet chiffré tel que stocké, et compare. C'est seulement alors que commence le déchiffrement des segments
Vérifier le MAC sur le texte chiffré plutôt que sur le texte clair est la discipline standard chiffrer-puis-MAC, et c'est ce qui rend la vérification significative : un paquet altéré est rejeté sans qu'aucun octet contrôlé par l'attaquant n'ait été passé dans le chemin de déchiffrement et d'inflation. Les deux comparaisons du chemin d'ouverture, le hachage vérificateur de mot de passe et la valeur HMAC, accumulent les différences avec XOR et OR sur l'intégralité du condensé plutôt que de retourner tôt au premier octet non concordant, si bien qu'aucune des deux ne divulgue une position d'octet via le minutage
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Fonctionne pour les fichiers en clair, chiffrés en Standard et chiffrés en Agile
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Mot de passe erroné, ou paquet dont le HMAC dataIntegrity ne correspondait pas
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Du côté de l'écriture, rien ne change dans votre code. SaveAsEncrypted émet le bloc automatiquement, et les sels, l'entrée de vérificateur et la clé HMAC proviennent de CryptGenRandom. Si cet appel échoue, HotXLS lève une exception plutôt que de se rabattre sur une source plus faible. Un CSPRNG en échec fermé n'est pas de la paranoïa ; une dégradation silencieuse vers une source aléatoire prévisible produit des fichiers qui paraissent chiffrés, passent tous les tests fonctionnels, et ne valent rien
Pourquoi les fichiers sans ce bloc s'ouvrent-ils quand même ?
Parce qu'un très grand nombre de classeurs chiffrés en Agile en circulation ont été écrits par des producteurs qui omettent entièrement dataIntegrity, et les rejeter casserait bien plus de travail légitime que cela n'en protégerait. HotXLS ne considère l'intégrité comme présente que lorsque les deux attributs, la clé HMAC chiffrée et la valeur HMAC chiffrée, sont présents et bien formés. Sinon, la vérification est ignorée et le fichier s'ouvre comme avant
C'est une décision de compatibilité avec une conséquence de sécurité que vous devriez nommer explicitement dans votre propre modèle de menace : l'absence du bloc ne peut pas être distinguée d'un attaquant qui l'aurait supprimé, car les attributs sont en dehors du MAC qu'ils porteraient. Si vous contrôlez les deux extrémités d'un pipeline, traitez un bloc manquant comme un échec de politique au niveau applicatif. Si vous acceptez des fichiers venant du monde extérieur, traitez la vérification pour ce qu'elle est, un signal précieux quand il est présent et aucun signal du tout quand il est absent
Le mot de passe de modification est une convention, pas une frontière
Les classeurs XLS classiques prennent en charge un mécanisme distinct que l'on confond régulièrement avec le chiffrement : la réservation d'écriture, l'invite Excel « mot de passe de modification ». HotXLS l'expose via SetModifyPassword, qui prend le mot de passe, un indicateur de lecture seule recommandée et le nom de l'utilisateur réservataire, et rapporte l'état via IsWriteReserved. Passer un mot de passe vide efface la réservation
Ce qui est écrit est une paire d'enregistrements WRITEPROT et FILESHARING portant l'indicateur de lecture seule recommandée, un hachage de mot de passe hérité sur 16 bits et le nom d'utilisateur sous forme de chaîne Unicode BIFF8. Ce hachage 16 bits est une somme de contrôle, pas un condensé cryptographique, et le contenu du document n'est pas chiffré du tout. Quiconque ouvre le fichier avec un autre outil lit tout. Le véritable rôle de la fonctionnalité est la coordination : elle indique à la personne suivante que quelqu'un considère ce fichier comme sien à modifier, dans la même catégorie que les contrôles au niveau feuille couverts dans la protection de feuille XLSX et les options allow
var
Book: IXLSWorkbook; // à comptage d'interface : ne pas Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Lecture seule recommandée, réservé par le service de reporting
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Utilisez chaque couche pour ce en quoi elle excelle. La véritable confidentialité vient de SaveAsEncrypted avec un mot de passe que personne en dehors de l'audience ne détient, ce qui produit la sortie AES-256 décrite dans la sortie XLSX protégée par AES. La réservation d'écriture vient en plus quand le classeur est un artefact d'édition partagée et que vous voulez qu'Excel demande avant que quelqu'un n'écrase le fichier
Que vérifier sur un chemin d'entrée non fiable
La vérification d'intégrité protège la charge utile chiffrée, pas le conteneur qui l'entoure. Un fichier XLSX est une archive ZIP, et la structure de l'archive est analysée avant que la moindre logique de chiffrement ne s'exécute, si bien que la validation au niveau du conteneur vient en premier dans la chaîne ; les modes de défaillance spécifiques sont couverts dans la validation du répertoire central de fin ZIP pour XLSX non fiables. Après cela, traitez un échec d'intégrité et un mot de passe erroné comme le même événement opérationnel, car de votre côté ils sont indissociables par conception, et les deux signifient que le fichier ne peut pas être considéré comme étant ce que l'expéditeur pense qu'il est
Journalisez quels fichiers portaient un bloc dataIntegrity, ne serait-ce que sa présence. Sur quelques milliers de documents, cette statistique vous apprend quelque chose d'utile sur l'outillage de vos expéditeurs, et transforme une vérification par fichier en une observation à l'échelle du parc sur laquelle vous pouvez agir
HotXLS lit et écrit XLS, XLSX et ODS depuis Delphi et C++Builder sans aucune installation d'Excel, en implémentant en Pascal les chemins de chiffrement Standard et Agile de [MS-OFFCRYPTO]. Les API de chiffrement, de protection et de classeur sont documentées sur la page HotXLS Delphi spreadsheet component