HotXLS schrijft een conform dataIntegrity-blok naar Agile-versleutelde XLSX-packages en verifieert het bij het openen. De HMAC-SHA-512 dekt de volledige EncryptedPackage-stroom, inclusief het voorloopstukje van acht bytes met StreamSize, en wordt gecontroleerd over de ciphertext vóórdat enig segment ontsleuteld wordt, zodat een verkeerd wachtwoord of een gewijzigde package gedetecteerd wordt in plaats van tot brij ontsleuteld
Versleuteling zonder integriteit is een half antwoord, en Office-bestandsformaten maken dat gat gemakkelijk over het hoofd te zien omdat de versleuteling van buitenaf zo grondig oogt. Weten wat elke laag belooft, is wat een beveiligingsreview kort houdt
Wat belooft een versleuteld werkboek werkelijk?
Agile-versleuteling, gedefinieerd in [MS-OFFCRYPTO], geeft u vertrouwelijkheid via AES in CBC-modus met een sleutel afgeleid van een geïtereerde SHA-512-wachtwoordhash. Vertrouwelijkheid is de volledige belofte van die constructie. CBC is geen geauthenticeerde modus: het zegt niets over of de ciphertext die u ontsleutelt, de ciphertext is die geschreven werd
De praktische consequentie is specifiek. Draai bits om in een versleutelde package en CBC zal ze met plezier ontsleutelen naar andere plaintext. U krijgt meestal ergens verderop een ZIP-parseerfout, omdat een beschadigde deflate-stroom zelden overleeft, maar "meestal" doet veel werk in die zin, en een parseerfout verderop is een verschrikkelijke plek om te ontdekken dat een bestand gewijzigd is. Het dataIntegrity-element bestaat om die vraag direct te beantwoorden, vóór ontsleuteling, met een MAC over de exacte bytes
Hoe de controle verloopt, en in welke volgorde
De volgorde is het interessante deel. HotXLS leidt de tussenliggende sleutel af van het wachtwoord, ontsleutelt de versleutelde HMAC-sleutel en HMAC-waarde uit de dataIntegrity-attributen met behulp van block-key-afgeleide IV's, berekent HMAC-SHA-512 over de package zoals opgeslagen, en vergelijkt. Pas daarna begint segmentontsleuteling
De MAC over ciphertext controleren in plaats van over plaintext is de standaard encrypt-then-MAC-discipline, en dat is wat de controle betekenisvol maakt: een gemanipuleerde package wordt afgewezen zonder dat er ook maar één door de aanvaller gecontroleerde byte door het ontsleutel- en inflate-pad is gegaan. Beide vergelijkingen in het openpad, de wachtwoordverifier-hash en de HMAC-waarde, stapelen verschillen op met XOR en OR over de volledige digest in plaats van vroeg terug te keren bij de eerste niet-overeenkomende byte, zodat geen van beide een byte-positie via timing lekt
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Werkt voor gewone, Standard-versleutelde en Agile-versleutelde bestanden
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Verkeerd wachtwoord, of een package waarvan de dataIntegrity-HMAC niet klopte
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Aan de schrijfkant verandert er niets in uw code. SaveAsEncrypted voegt het blok automatisch toe, en de salts, verifier-input en HMAC-sleutel komen van CryptGenRandom. Faalt die aanroep, dan gooit HotXLS een exceptie in plaats van terug te vallen op een zwakkere bron. Een fail-closed CSPRNG is geen paranoia; een stille downgrade naar een voorspelbare willekeurige bron levert bestanden op die versleuteld ogen, elke functionele test doorstaan, en waardeloos zijn
Waarom openen bestanden zonder het blok nog steeds?
Omdat heel veel Agile-versleutelde werkboeken die in omloop zijn, geschreven werden door producenten die dataIntegrity volledig weglaten, en ze afwijzen zou veel meer legitiem werk breken dan het zou beschermen. HotXLS behandelt integriteit als aanwezig alleen wanneer beide attributen, de versleutelde HMAC-sleutel en de versleutelde HMAC-waarde, er zijn en correct gevormd. Anders wordt verificatie overgeslagen en opent het bestand zoals voorheen
Dit is een compatibiliteitsbeslissing met een beveiligingsconsequentie die u expliciet in uw eigen dreigingsmodel moet benoemen: de afwezigheid van het blok is niet te onderscheiden van een aanvaller die het verwijderd heeft, omdat de attributen buiten de MAC vallen die ze zouden dragen. Beheert u beide uiteinden van een pijplijn, behandel dan een ontbrekend blok als een beleidsfout op applicatieniveau. Accepteert u bestanden uit de wereld, behandel de controle dan voor wat ze is, een waardevol signaal wanneer aanwezig en helemaal geen signaal wanneer afwezig
Wachtwoord om te wijzigen is een conventie, geen grens
Klassieke XLS-werkboeken ondersteunen een apart mechanisme dat routinematig verward wordt met versleuteling: de schrijfreservering, Excels "wachtwoord om te wijzigen"-prompt. HotXLS legt het bloot via SetModifyPassword, dat het wachtwoord, een aanbeveel-alleen-lezen-vlag en de reserverende gebruikersnaam aanneemt, en rapporteert de status via IsWriteReserved. Een leeg wachtwoord doorgeven wist de reservering
Wat er geschreven wordt, is een WRITEPROT- en FILESHARING-recordpaar met de aanbeveel-alleen-lezen-vlag, een legacy 16-bit-wachtwoordhash en de gebruikersnaam als BIFF8 Unicode-string. Die 16-bit-hash is een controlesom, geen cryptografische digest, en de documentinhoud wordt helemaal niet versleuteld. Wie het bestand ook maar met een ander gereedschap opent, leest alles. De echte taak van deze functie is coördinatie: ze vertelt de volgende persoon dat iemand dit bestand als het zijne beschouwt om te bewerken, in dezelfde categorie als de sheetniveau-controles behandeld in XLSX-sheetbeveiliging en allow-opties
var
Book: IXLSWorkbook; // interface-geteld: niet Free aanroepen
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Aanbevolen alleen-lezen, gereserveerd door de rapportageservice
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Gebruik beide lagen voor waar elk goed in is. Echte vertrouwelijkheid komt van SaveAsEncrypted met een wachtwoord dat niemand buiten het beoogde publiek kent, wat de AES-256-output oplevert beschreven in AES-beveiligde XLSX-output. De schrijfreservering komt erbovenop wanneer het werkboek een gedeeld bewerkingsartefact is en u wilt dat Excel vraagt voordat iemand eroverheen opslaat
Wat te controleren op een niet-vertrouwd intakepad
Integriteitsverificatie beschermt de versleutelde payload, niet de container eromheen. Een XLSX-bestand is een ZIP-archief, en de archiefstructuur wordt geparseerd vóórdat enige versleutelingslogica draait, dus containerniveau-validatie hoort vooraan in de keten; de specifieke faalwijzen staan in ZIP-end-of-central-directory-validatie voor niet-vertrouwde XLSX. Behandel daarna een integriteitsfout en een verkeerd wachtwoord als dezelfde operationele gebeurtenis, want vanuit uw kant zijn ze door ontwerp niet te onderscheiden, en beide betekenen dat het bestand niet vertrouwd kan worden om te zijn wat de afzender denkt dat het is
Log welke bestanden überhaupt een dataIntegrity-blok droegen. Over een paar duizend documenten vertelt die statistiek u iets nuttigs over de gereedschappen van uw afzenders, en verandert een controle per bestand in een waarneming op vlootniveau waarop u kunt handelen
HotXLS leest en schrijft XLS, XLSX en ODS vanuit Delphi en C++Builder zonder installatie van Excel, en implementeert de Standard- en Agile-versleutelingspaden van [MS-OFFCRYPTO] in Pascal. De versleutelings-, beveiligings- en werkboek-API's staan gedocumenteerd op de HotXLS Delphi spreadsheetcomponentpagina