HotXLS leser Agile-krypterte Excel-filer, passordbeskyttelsen som Excel 2010 og alle senere versjoner bruker som standard, gjennom et enkelt kall: TXLSXWorkbook.OpenEncrypted. Komponenten tolker XML-krypteringsbeskrivelsen, utleder nøkler fra passordet med en SHA-512 spin-count hashkjede, verifiserer passordet mot den krypterte verifikatoren, og dekrypterer deretter pakken i 4096-byte AES-CBC-segmenter. Ingen Excel-installasjon, ingen COM eller ekstern krypto-DLL er involvert
Denne artikkelen dekker spesifikt lesesiden av Agile-kryptering. To relaterte problemer har egne artikler: samhandling med eldre RC4- og XOR-ordninger i gamle BIFF .xls-filer dekkes i artikkelen om ECB- og RC4-samhandling, og produksjon av passordbeskyttede arbeidsbøker med ECMA-376 Standard-kryptering dekkes i artikkelen om AES-beskyttede XLSX-utdata. Her eksisterer filen allerede, noen andre krypterte den, og jobben din er å åpne den
Scenarioet som tvinger frem saken er kjent for alle som kjører en dokumentpipeline. En importtjeneste på serversiden godtar opplastinger av arbeidsbøker; det er ingen Excel på maskinen og vil aldri bli det; og en morgen laster en kunde opp en helt vanlig .xlsx som ZIP-leseren avviser fordi det ikke er en ZIP i det hele tatt. Kunden lagret den med et passord. Fra det øyeblikket må innleseren din enten forstå [MS-OFFCRYPTO] eller så returnerer den filen til en bruker som, fra sitt ståsted, ikke gjorde noe uvanlig
Hva er Agile-kryptering i en Excel-fil?
Agile-kryptering er passordbeskyttelsesordningen definert i [MS-OFFCRYPTO] §2.3.4.10 til §2.3.4.15, og det er det Excel 2010 og senere skriver når en arbeidsbok lagres med et passord. Den krypterte filen er ikke lenger en ZIP-pakke. Det er en OLE Compound File Binary (CFB)-beholder som inneholder to strømmer: EncryptionInfo, som beskriver hvordan krypteringen ble utført, og EncryptedPackage, som er den ekte .xlsx-ZIP-en kryptert som en ugjennomsiktig blob. CFB-signaturen (D0 CF 11 E0 A1 B1 1A E1) er den same magiske som eldre BIFF .xls-filer bærer, noe som er grunnen til at en omdøpt eller kryptert fil ikke kan klassifiseres etter filendelse alene
Det som skiller Agile fra sine forgjengere er at EncryptionInfo er selvbeskrivende. Etter et 8-byte versjonsprefiks, med både hoved- og underversjon satt til 4, er strømmen en UTF-8 XML-beskrivelse. Et keyData-element erklærer chifferet (AES), kjedemodusen (ChainingModeCBC), hashen (SHA512), nøkkellengden i bit, blokkstørrelsen og et Base64-salt. Et passord keyEncryptor-element bærer sitt eget salt, spinCount, og tre Base64-nyttelaster: encryptedVerifierHashInput, encryptedVerifierHashValue og encryptedKeyValue. Excel skriver AES-256 med et spin-antall på 100 000, men beskrivelsen har lov til å erklære AES-128 eller AES-192, og HotXLS respekterer det keyBits sier fremfor å anta 256
Ett inngangspunkt for ren tekst-, standard- og Agile-arbeidsbøker
TXLSXWorkbook.OpenEncrypted håndterer alle tre tilstander en kaller kan støte på: ren ZIP, standard-kryptert og Agile-kryptert, slik at opplastingsbehandlere ikke trenger å klassifisere filer før de laster dem inn. Metoden snuser først på filen: hvis det ikke finnes noen CFB-signatur, overlater den arbeidet til den vanlige Open-banen og passordet ignoreres. Hvis filen er en CFB-beholder, prøver den ECMA-376 Standard-kryptering først, og når EncryptionInfo-versjonssignaturen er Agile 4.4, videresendes oppgaven to Agile-pipelinen. Returverdien er 1 ved suksess, samme kontrakt som Open
Hvordan blir et passord til en AES-nøkkel?
Agile-kryptering bruker aldri passordet direkte. HotXLS beregner først en iterert hash: den første digesten er SHA-512 over passordsaltet slått sammen med UTF-16LE-bytene til passordet, og deretter hashes digesten på nytt spinCount ganger, der hver runde foran-stiller den 32-biters little-endian iterasjonstelleren foran den forrige digesten. Med Excels standard spin-antall på 100 000 er det et hundre tusen serielle SHA-512-kall per passordforsøk, og det er hele poenget. Spin-antallet er en brute-force-brems: det koster en legitim kaller noen få millisekunder én gang, og koster en ordbokangriper de samme millisekundene for hvert eneste gjett
Passordverifisering og saltSize-avkortingsfellen
HotXLS verifiserer passordet før det rører pakken ved å bruke verifikatorparet fra beskrivelsen. Den dekrypterer encryptedVerifierHashInput med den første utledede nøkkelen, hashes resultatet med SHA-512, dekrypterer encryptedVerifierHashValue med den andre utledede nøkkelen, og sammenligner de to digestene byte for byte. Avvik betyr at passordet er feil, noe som rapporteres som et eget resultat i stedet for en uforståelig arbeidsbok, og kritisk betyr det at pakke-kroppen aldri dekrypteres med en dårlig nøkkel, så det er ingen scenarioer der et feil passord produserer korrupte data som ser troverdige ut
Det er en spesifikasjonsdetalj her som er lett å ta feil av. [MS-OFFCRYPTO] §2.3.4.13 definerer verifikatoren som saltSize byte med tilfeldige data, der saltSize er lengden på nøkkelkryptererens salt, ikke chifferblokkstørrelsen. Fordi AES-CBC-chiffertekst er blokkjustert, kommer den dekrypterte verifikator-inndataen tilbake polstret til et multiplum av 16 byte, og den må avkortes tilbake til saltSize før hashing. Excel skriver alltid saltSize lik blockSize, begge 16, so an implementation that skips the truncation passes every test against real Excel output and then fails on the first file from a producer that chose a different salt length. HotXLS avkorter til saltlengden fordi det er det spesifikasjonen faktisk sier, og at de to verdiene er like i praksis er en tilfeldighet, ikke en kontrakt
Hvordan dekrypteres EncryptedPackage?
Strømmen EncryptedPackage begynner med en 8-byte little-endian klartekststørrelse, etterfulgt av chifferteksten i segmenter på 4096 byte, og HotXLS dekrypterer den segment for segment med en ny IV per segment. Selve pakkenøkkelen er ikke passord-utledet: det er en tilfeldig mellomnøkkel som skriveren krypterte inn i encryptedKeyValue, og HotXLS pakker den ut med den tredje utledede nøkkelen og avkorter til nøkkellengden erklært av keyData. Hvert segments IV er SHA-512 over keyData-saltet slått sammen med den 32-biters little-endian segmentindeksen, avkortet til blokkstørrelsen. Den grunnleggende konstruksjonen gjør at ethvert segment på 4096 byte kan dekrypteres uavhengig, noe som også gjør formatet egnet for vilkårlig tilgang (random access) i prinsippet, selv om HotXLS dekrypterer hele pakken til minnet og sender de resulterende ZIP-bytene til sin vanlige XLSX-innleser
Den erklærte klartekststørrelsen gjør den siste delen av jobben. AES-CBC-utdata er blokkjustert, so the last segment carries up to 15 bytes of padding that are not part of the document; the decrypted buffer is truncated to the size prefix, and the result is exactly the .xlsx ZIP that Excel encrypted. HotXLS validerer prefikset mot den faktiske strømlengden før dekryptering, slik at en avkortet opplasting eller et manipulert størrelsesfelt feiler rent i stedet for å overkjøre
Feilrapportering og ærlige grenser
Feilmodusene holdes bevisst adskilt. A wrong password raises an exception with an explicit wrong-password message, driven by the verifier mismatch, so a UI can prompt the user to retry. A CFB container whose descriptor declares algorithms outside the supported set, anything other than AES with CBC chaining and SHA-512 hashing in an Agile descriptor, or a container that is neither Standard nor Agile, raises a different exception identifying the scheme as unsupported. The two must never be conflated: retrying a password against an unsupported scheme wastes the user's time, and reporting a wrong password as a format error sends your support team down the wrong road
Grensene er verdt å si tydelig. HotXLS leser Agile-beskrivelser som erklærer AES i CBC-modus med SHA-512, noe som dekker det Excel 2010 til Excel 365 faktisk skriver, i alle tre nøkkelstørrelser. Beskrivelser som erklærer andre chiffer eller hash-algoritmer avvises i stedet for å gjettes på, og sertifikatbaserte nøkkelkrypterere konsulteres ikke, bare passordnøkkelkryptering. På skrivesiden produserer HotXLS for øyeblikket Standard-kryptering i stedet for Agile, en forskjell som betyr noe hvis etterfølgende verktøy inspiserer ordningen; detaljene finnes i artikkelen om skriving av AES-beskyttede XLSX-utdata
Passordbeskyttede opplastinger slutter å være et spesialtilfelle så snart innleseren behandler kryptering som en del av filformatet i stedet for et unntak fra det. Inngangspunktet OpenEncrypted, SHA-512 spin-count-utledningen og den segmenterte AES-CBC-pipelinen beskrevet her leveres som en del av HotXLS Delphi Excel Component, sammen med resten av dens native XLS- og XLSX-lese- og skrivemotor for Delphi og C++Builder