Krypter XLSX-filer med AES i Delphi med HotXLS

Excel eksponerer to ting som begge kalles «passord», og bare den ene av dem er kryptering. Åpningspassordet er nøkkel til en ekte chiffer: uten det kan filen ikke leses i det hele tatt. Passordene for regneark- og arbeidsbokbeskyttelse gjør ikke noe slikt. De setter et flagg som et samarbeidsvillig redigeringsprogram går med på å respektere, og en arbeidsbok som ikke bærer annet enn det flagget, er en helt vanlig lesbar zip med dataene liggende i klartekst. Velg feil, og du sender ut lønnsdata som ser låst ut i Excel og leses i en hvilken som helst teksteditor

Beviset tar ti sekunder. Gi en beskyttet .xlsx nytt navn til .zip, åpne den i et hvilket som helst arkivverktøy, og se på xl/worksheets/sheet1.xml. Ligger celleverdiene der i ren UTF-8, er filen ikke kryptert, uansett hvor mange passordvinduer Excel viser når noen prøver å redigere en celle. Det gapet overlever i årevis inne i team som antar at arkbeskyttelse er konfidensialitet, og det dukker som regel opp den dagen en sikkerhetsgjennomgang kjører nøyaktig dette navnebyttet

HotXLS er et native regnearkbibliotek for Delphi og C++Builder, og det holder de to funksjonene på hver sin side av den streken. Regneark- og arbeidsbokbeskyttelse er redigeringsbegrensninger støttet av en bevisst svak eldre hash. SaveAsEncrypted produserer en AES-kryptert pakke som ingenting annet enn passordet vil åpne. Avsnittene nedenfor dekker hva det kallet skriver, asymmetrien du må designe rundt (HotXLS skriver krypterte filer, men kan ikke lese dem tilbake), og hvordan den eldre XLS-stien skiller seg

Hvorfor arkbeskyttelse ikke er kryptering

Protect-metodene på ark og ProtectWorkbook på arbeidsboken lagrer en hash på 4 heksadesimale sifre av passordet. Det er den eldre algoritmen både OOXML og BIFF arvet fra 1990-tallets Excel, og formatdokumentasjonen påstår aldri at den gjør mer enn å stoppe utilsiktede redigeringer. Pakken forblir en helt vanlig lesbar zip: celledata, formler og delte strenger alt sammen i klartekst-XML. Standardinnstillingen gjør det verre, ikke bedre. Hver celle starter med Locked=True, så å kalle Protect uten først å låse opp et inndataområde fryser hele arket mot redigering, mens hver verdi fortsatt ligger i fullt dagslys

Ikke noe av dette gjør beskyttelse ubrukelig. Å lose brukere inn i redigerbare områder og å stabilisere et oppsett for utskrift er reelle jobber, dekket i artikkelen vår om regnearkbeskyttelse og sideoppsett. Men det er brukervennlighetsjobber. I det øyeblikket kravet er konfidensialitet, er det eneste API-et som svarer på det, SaveAsEncrypted

Hva SaveAsEncrypted faktisk skriver

Implementasjonen følger ECMA-376 Standard Encryption, spesifisert i [MS-OFFCRYPTO] avsnitt 2.3.4. Passordet kjøres gjennom 50 000 iterasjoner av SHA-1 for å utlede en AES-128-nøkkel. En verifikatorblokk, kryptert med AES-128 i ECB-modus, lar en konsument bekrefte passordet før den dekrypterer noe som helst, og hele arbeidsbokpakken krypteres deretter med AES-128 i CBC-modus. Det som lander på disk, er ikke en zip i det hele tatt. Det er en OLE-sammensatt fil som rommer EncryptionInfo-, EncryptedPackage- og DataSpaces-strømmene, uten noen xl/-katalog et arkivverktøy kan liste opp, som er grunnen til at navnebyttetesten nå ikke gir noe lesbart. Excel 2007 og senere åpner den med passordet alene, og dagens LibreOffice leser også Standard Encryption

var
  Book: TXLSXWorkbook;
  Sheet: TXLSXWorksheet;
  rc: Integer;
begin
  Book := TXLSXWorkbook.Create;
  try
    Sheet := Book.Sheets.Add('Payroll');
    Sheet.Cells[1, 1].Value := 'Employee';
    Sheet.Cells[1, 2].Value := 'Net pay';
    Sheet.Cells[2, 1].Value := 'A. Garcia';
    Sheet.Cells[2, 2].Value := 4815.16;

    rc := Book.SaveAsEncrypted('payroll-2026-06.xlsx', PasswordFromVault);
    if rc <> 1 then
      raise Exception.CreateFmt('Encrypted save failed (rc=%d)', [rc]);
  finally
    Book.Free;
  end;
end;

Behandle passordvariabelen med samme omhu som en tilkoblingsstreng. Hent den fra et hvelv eller en tjeneste for genererte hemmeligheter i siste liten, logg den aldri, og skriv den aldri inn i selve arbeidsboken. Kontrollen av returkoden er ikke valgfritt seremoniell. En krypteringslagring som feiler halvveis, må avbryte leveransen, fordi den eneste reserveløsningen den kallende koden kan tilby, er en ukryptert kopi, og den kopien er nøyaktig den hendelsen denne funksjonen finnes for å forhindre

Det finnes også en maskinkontrollerbar akseptansetest som nesten ikke koster noe: kall CanReadEncrypted på filen du nettopp skrev. Den returnerer sant bare når utdataene virkelig er en krypteringscontainer, så å hevde den etter hver krypterte lagring fanger den regresjonen som betyr mest, en kodesti som stille falt tilbake til en vanlig SaveAs, i det øyeblikket den skjer, i stedet for uker senere i en kundes innboks. Det siste ordet tilhører fortsatt en manuell åpning i Excel med det ekte passordet under utgivelsestesting

Kun skriving etter design: å håndtere EXlsxEncryptionNotImplemented

Her er asymmetrien som bør forme rørledningsarkitekturen din: HotXLS krypterer ved lagring, men dekrypterer ikke ved åpning. OpenEncrypted reiser EXlsxEncryptionNotImplemented når den rettes mot en faktisk kryptert pakke; på en vanlig arbeidsbok faller den ganske enkelt gjennom til en normal Open. Følgesonden CanReadEncrypted oppdager OLE-krypteringscontaineren billig, så inntakskode kan rute slike filer uten å utløse unntaket:

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    if Book.CanReadEncrypted(FileName) then
    begin
      // Kryptert container: HotXLS kan ikke dekryptere den.
      Writeln(FileName + ': needs manual decryption in Excel first');
      Exit;
    end;
    try
      Book.OpenEncrypted(FileName, '');   // vanlige filer faller gjennom til Open
      Writeln(FileName + ': opened, ' + IntToStr(Book.Sheets.Count) + ' sheet(s)');
    except
      on EXlsxEncryptionNotImplemented do
        Writeln(FileName + ': encrypted - routed to manual queue');
    end;
  finally
    Book.Free;
  end;
end;

Den asymmetrien har én klar arkitektonisk lesning: krypter ved leveransekanten, sist. Hold klartekstoriginalen innenfor tillitsgrensen din, i en database, et dokumentlager eller en tilgangsstyrt deling, og produser den krypterte kopien som siste steg før filen forlater systemet. En rørledning som bare arkiverer de krypterte utdataene, har låst seg selv ute fra sine egne data, fordi ingen senere trinn i det samme systemet kan åpne de filene igjen. Når en nedstrøms HotXLS-prosess trenger arbeidsboken på nytt, gi den klartekstoriginalen, aldri leveranseartefakten

AES-128 Standard Encryption og samsvarsgrensen ved AES-256

Office-filkryptering kommer i to generasjoner. Standard Encryption, den HotXLS skriver, bruker AES-128 med SHA-1-nøkkelutledning. Agile Encryption kom senere og går over til AES-256 med SHA-512 og en annen, XML-beskrevet nøkkelcontainer. Begge åpner seg sømløst i Excel, og AES-128 er fortsatt beregningsmessig solid for å beskytte en fil på vei til en kunde

Forskjellen slutter å være akademisk den dagen et sikkerhetsskjema ber om «AES-256-kryptering av filer i hvile». Standard Encryption innfrir ikke den grensen, uansett hvor sterkt passordet er, og ingen parameter i SaveAsEncrypted endrer algoritmen den skriver ut. Så oppgi profilen presist i sikkerhetsdokumentasjonen din: AES-128, ECMA-376 Standard Encryption, SHA-1-nøkkelutledning med 50 000 iterasjoner. En påstand som overlever gjennomgang, er verdt mer enn en optimistisk en som bryter sammen under en revisjon

Den eldre XLS-veien: RC4 ut, RC4 og XOR inn igjen

BIFF-fasaden har motsatt form. Krypteringen der er eldre og svakere, men rundturen er komplett: det den skriver, kan den også lese tilbake. Å sette EncryptionPassword før SaveAs produserer en RC4-kryptert .xls gjennom BIFF-mekanismen FilePass, og Open med en passordparameter leser alle tre eldre ordningene, RC4, RC4 CryptoAPI og den eldgamle XOR-tilsløringen:

var
  Writer, Reader: IXLSWorkbook;   // grensesnittreferanser: ingen manuell Free
begin
  Writer := TXLSWorkbook.Create;
  Writer.Sheets.Add.Cells.Item[1, 1].Value := 'Confidential';
  Writer.EncryptionPassword := 'S3cret!';
  Writer.SaveAs('confidential.xls');

  Reader := TXLSWorkbook.Create;
  if Reader.Open('confidential.xls', 'S3cret!') > 0 then
    Writeln(Reader.Sheets[1].Cells.Item[1, 1].Value);  // Oppføringer er 1-baserte
end;

RC4 er foreldet kryptografi og bør aldri beskytte data som betyr noe i dag; den eneste gjenværende verdien er interoperabilitet med systemer som fortsatt utveksler .xls. Lesesiden gjør imidlertid nytte for seg i migreringsarbeid. En passordbeskyttet eldre fil åpnes med Open(FileName, Password), brofører inn i OOXML-modellen og sikres på nytt gjennom AES-stien, en enveis oppgradering som kjører uten Excel noe sted i sløyfen. For krypterte leveranser i stort volum gjelder notatene om skrivesidens gjennomstrømning i artikkelen vår om strømmende skriving for serverbatchjobber for innholdsbyggingsfasen som skjer før krypteringen

Kryptering og beskyttelse er ikke rivaler

Ett poeng til er verdt å avklare, fordi det kommer opp i det øyeblikket noen leser advarselen øverst på denne siden som «beskyttelse er verdiløs». Det er den ikke. Kryptering og beskyttelse besvarer ulike spørsmål, og de stables rent oppå hverandre. Kryptering avgjør hvem som kan åpne filen; beskyttelse avgjør hva en leser som allerede er innenfor, får lov til å endre. En lønnsleveranse kan med rette gjøre begge deler: krypter pakken slik at bare den som har passordet ser den, og lås så formelcellene slik at mottakeren kan filtrere og sortere, men ikke stille skrive om beregningene. Feilen er aldri å legge på beskyttelse. Feilen er å la tilstedeværelsen av den tre inn i stedet for kryptering når kravet var konfidensialitet

Forvaltningssiden har ikke noe sikkerhetsnett, og det er tilsiktet. Nøkkelutledningen med 50 000 iterasjoner finnes for å gjøre gjetting dyrt, og ingenting inne i filen deponerer hemmeligheten. Et tapt passord er tapte data. Generer, lever og lagre disse passordene med samme disiplin som du bruker på databaselegitimasjon, så holder krypteringen sin del av avtalen

Ekte filkryptering er ett kall i HotXLS. Disiplinen bor i alt rundt kallet: passordforvaltning, skriv-bare-grensen som hindrer HotXLS i å åpne sine egne utdata på nytt, og en algoritmepåstand du kan forsvare i en revisjon. SaveAsEncrypted og den eldre rundturen følger med HotXLS Delphi Component, som kjører nativt i Delphi- og C++Builder-prosesser uten Excel-automatisering noe sted i stien