Excel eksponerer to ting som begge kalles "passord," og bare ett av dem er kryptering. Passordet for åpning styrer et reelt chiffer: uten det kan ikke filen leses i det hele tatt. Passordene for regneark- og arbeidsbokbeskyttelse gjør ingenting av den typen. De setter et flagg som en samarbeidende redaktør samtykker i å respektere, og en arbeidsbok som bare har dette flagget er en vanlig ZIP-fil der dataene ligger i klartekst. Velger du feil, sender du lønningslister som ser låst ut i Excel, men som kan leses i et hvilket som helst tekstredigeringsprogram
Beviset tar ti sekunder. Omdøp en beskyttet .xlsx til .zip, åpne den i et arkivverktøy, og se på xl/worksheets/sheet1.xml. Hvis celleverdiene ligger der i vanlig UTF-8, er ikke filen kryptert, uansett hvor mange passordforespørsler Excel kommer med når noen prøver å redigere en celle. Den misforståelsen overlever i årevis i team som antar at arkbeskyttelse betyr konfidensialitet, og det dukker vanligvis opp den dagen en sikkerhetsgjennomgang kjører akkurat denne omdøpingen
HotXLS er et opprinnelig regnearkbibliotek for Delphi og C++Builder, og det holder de to funksjonene på hver sin side av den linjen. Regneark- og arbeidsbokbeskyttelse er redigeringsbegrensninger støttet av en bevisst svak, eldre hash-algoritme. SaveAsEncrypted produserer en AES-kryptert pakke som ingenting annet enn passordet vil kunne åpne. Avsnittene nedenfor dekker hva dette kallet skriver, asymmetrien du må designe rundt (HotXLS skriver krypterte filer, men kan ikke lese dem tilbake), og hvordan den eldre XLS-banen skiller seg fra dette
Hvorfor arkbeskyttelse ikke er kryptering
Metodene Protect på ark og ProtectWorkbook på arbeidsboken lagrer en 4-sifret heksadesimal hash av passordet. Det er den eldre algoritmen OOXML og BIFF arvet fra 1990-tallets Excel, og formatdokumentasjonen hevder aldri at den gjør mer enn å forhindre utilsiktede redigeringer. Pakken forblir en vanlig lesbar ZIP-fil: celledata, formler og delte strenger ligger 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 alle verdier forblir godt synlige
Noe som ikke betyr at beskyttelse er ubrukelig. Å lede brukere til redigerbare områder og stabilisere et sideoppsett for utskrift er reelle oppgaver, dekket i artikkelen vår om regnearkbeskyttelse og sideoppsett. Men dette er oppgaver knyttet til brukervennlighet. I det øyeblikket kravet er konfidensialitet, er det eneste API-et som gir et svar SaveAsEncrypted
Hva SaveAsEncrypted faktisk skriver
Implementasjonen følger ECMA-376 Standard-kryptering, 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, og hele arbeidsbokpakken blir deretter kryptert med AES-128 i CBC-modus. Det som havner på disken er ikke en ZIP-fil i det hele tatt. Det er en OLE compound-fil som inneholder strømmene EncryptionInfo, EncryptedPackage og DataSpaces, uten noen xl/-katalog som et arkivverktøy kan liste opp, og det er derfor omdøpingstesten nå ikke viser noe lesbart. Excel 2007 og later opens it with the password alone, and current LibreOffice reads Standard Encryption too
Skrivebeskyttet av design: håndtere EXlsxEncryptionNotImplemented
Her er asymmetrien som bør forme din pipeline-arkitektur: HotXLS krypterer ved lagring, men dekrypterer ikke ved åpning. OpenEncrypted utløser EXlsxEncryptionNotImplemented når den pekes mot en faktisk kryptert pakke; på en vanlig arbeidsbok faller den rett og slett igjennom til en vanlig Open. Ledsagersjekken CanReadEncrypted oppdager OLE-krypteringsbeholderen rimelig, slik at mottakskoden kan rute slike filer uten å utløse unntaket
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
if Book.CanReadEncrypted(FileName) then
begin
// Encrypted container: HotXLS cannot decrypt it.
Writeln(FileName + ': needs manual decryption in Excel first');
Exit;
end;
try
Book.OpenEncrypted(FileName, ''); // plain files fall through to 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 en klar arkitektonisk tolkning: krypter helt på kanten av leveringen, til slutt. Behold klartekst-masteren innenfor tillitsgrensen din (i en database, et dokumentlager eller en delt ressurs med tilgangskontroll), og produser den krypterte kopien som siste trinn før filen forlater systemet. En pipeline som bare arkiverer de krypterte utdataene har låst seg ute fra sine egne data, fordi ingen senere stadier av det samme systemet kan gjenåpne disse filene. Når en nedstrøms HotXLS-prosess trenger arbeidsboken igjen, gi den klartekst-masteren, aldri leverings-artifakten
AES-128 Standard-kryptering og grensen for AES-256-samsvar
Kryptering av Office-filer kommer i to generasjoner. Standard-kryptering, som er den HotXLS skriver, bruker AES-128 med SHA-1-nøkkelutledning. Agile-kryptering kom senere og går over til AES-256 med SHA-512 og en annen, XML-beskrevet nøkkelbeholder. Begge åpnes transparent i Excel, og AES-128 er fremdeles beregningsmessig solid for å beskytte en fil under transport til en kunde
Forskjellen slutter å være akademisk den dagen et sikkerhetsspørreskjema ber om "AES-256-kryptering av filer under lagring (at rest)". Standard-kryptering tilfredsstiller ikke det kravet, uansett hvor sterkt passordet er, og ingen parameter i SaveAsEncrypted endrer algoritmen den leverer. Oppgitt derfor profilen nøyaktig i sikkerhetsdokumentasjonen din: AES-128, ECMA-376 Standard-kryptering, SHA-1-nøkkelutledning ved 50 000 iterasjoner. En påstand som overlever en gjennomgang er verdt mer enn en optimistisk påstand som kollapser under en revisjon
Den eldre XLS-banen: RC4 ut, RC4 og XOR tilbake inn
BIFF-fasaden har motsatt form. Krypteringen der er eldre og svakere, men tur-returen er fullstendig: det den skriver, kan den også lese tilbake. Å sette EncryptionPassword før SaveAs produserer en RC4-kryptert .xls via BIFF-ens FilePass-mekanisme, og Open med et passordparameter leser alle tre eldre ordninger: RC4, RC4 CryptoAPI og den urgamle XOR-obfuskeringen
var
Writer, Reader: IXLSWorkbook; // interface refs: no manual 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); // Entries are 1-based
end;RC4 er utdatert kryptografi og bør aldri beskytte data som betyr noe i dag; dens eneste gjenværende verdi er samhandling med systemer som fremdeles utveksler .xls. Lesesiden gjør imidlertid nytte for seg i migreringsarbeid. En passordbeskyttet eldre fil åpnes med Open(FileName, Password), brobygges inn i OOXML-modellen og sikres på nytt via AES-banen, en enveis oppgradering som kjører uten Excel i det hele tatt. For krypterte leveranser med høyt volum gjelder merknadene om ytelse på skrivesiden i artikkelen vår om strømmende skriving for server-batchjobber for innholdsbyggings-fasen som skjer før kryptering
Kryptering og beskyttelse er ikke motstandere
Enda et poeng det er verdt å avklare, fordi det oppstår i det øyeblikket noen leser advarselen øverst på denne siden som "beskyttelse er verdiløst". Det er det ikke. Kryptering og beskyttelse besvarer ulike spørsmål, og de kan fint stables oppå hverandre. Kryptering bestemmer hvem som kan åpne filen; beskyttelse bestemmer hva en leser som allerede er inne, har lov til å endre. En lønnsutbetaling kan rimeligvis gjøre begge deler: kryptere pakken slik at bare eieren av passordet ser den, og deretter låse formelcellene slik at mottakeren kan filtrere og sortere, men ikke i det stille skrive om beregningene. Feilen er aldri å legge til beskyttelse. Feilen er å la dens tilstedeværelse tre inn i stedet for kryptering når kravet var konfidensialitet
Forvaringssiden har ikke noe sikkerhetsnett, og det er etter design. Nøkkelutledningen med 50 000 iterasjoner eksisterer for å gjøre gjetting dyrt, og ingenting inne i filen deponerer hemmeligheten. Et tapt passord betyr tapte data. Generer, lever og lagre disse passordene med samme disiplin som du bruker på databasetilgang, så holder krypteringen sin del av avtalen
Reell filkryptering er ett kall i HotXLS. Disiplinen ligger i alt rundt kallet: passord-forvaring, den skrivebeskyttede grensen som forhindrer HotXLS fra å gjenåpne sine egne utdata, og en påstand om algoritme du kan forsvare i en revisjon. SaveAsEncrypted og den eldre tur-returen leveres med HotXLS Component, og kjører opprinnelig i Delphi- og C++Builder-prosesser uten Excel-automatisering noe sted i banen