HotXLS skriver en konform dataIntegrity-blok ind i Agile-krypterede XLSX-pakker og verificerer den ved åbning. HMAC-SHA-512 dækker den komplette EncryptedPackage-strøm, inklusive dens otte-byte StreamSize-præfiks, og tjekkes over ciphertekst, før noget segment dekrypteres, så en forkert adgangskode eller en modificeret pakke registreres frem for at blive dekrypteret til volapyk
Kryptering uden integritet er et halvt svar, og Office-filformater gør det gab let at overse, fordi krypteringen ser så grundig ud udefra. At forstå, hvad hvert lag lover, er det, der holder en sikkerhedsgennemgang kort
Hvad lover en krypteret projektmappe egentlig?
Agile-kryptering, defineret i [MS-OFFCRYPTO], giver dig fortrolighed gennem AES i CBC-tilstand med en nøgle, udledt af en itereret SHA-512-adgangskodehash. Fortrolighed er hele løftet i den konstruktion. CBC er ikke en autentificeret tilstand: den siger intet om, hvorvidt den ciphertekst, du dekrypterer, er den ciphertekst, der blev skrevet
Den praktiske konsekvens er specifik. Vend bits i en krypteret pakke, og CBC vil gerne dekryptere dem til anden klartekst. Du får som regel en ZIP-parsefejl et sted nedstrøms, fordi en beskadiget deflate-strøm sjældent overlever, men "som regel" gør et stort stykke arbejde i den sætning, og en nedstrøms parserfejl er et forfærdeligt sted at lære, at en fil er blevet ændret. Elementet dataIntegrity findes for at besvare spørgsmålet direkte, før dekryptering, med en MAC over de nøjagtige bytes
Hvordan tjekket kører, og i hvilken rækkefølge
Rækkefølgen er den interessante del. HotXLS udleder mellemnøglen fra adgangskoden, dekrypterer den krypterede HMAC-nøgle og HMAC-værdi fra dataIntegrity-attributterne ved hjælp af blok-nøgle-udledte IV'er, beregner HMAC-SHA-512 over den krypterede pakke, som den er gemt, og sammenligner. Først derefter begynder segmentdekryptering
At tjekke MAC'en over ciphertekst frem for klartekst er den standard encrypt-then-MAC-disciplin, og det er det, der gør tjekket meningsfuldt: en manipuleret pakke afvises, uden at nogen angriberkontrollerede bytes er blevet kørt gennem dekrypterings- og udpakningsstien. Begge sammenligninger i åbningsstien, verifikatorhashen for adgangskoden og HMAC-værdien, akkumulerer forskelle med XOR og OR på tværs af hele digest'et frem for at returnere tidligt ved den første uoverensstemmende byte, så ingen af dem afslører en byteposition gennem timing
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Works for plain, Standard-encrypted and Agile-encrypted files
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Wrong password, or a package whose dataIntegrity HMAC did not match
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;På skrivesiden ændrer intet sig i din kode. SaveAsEncrypted udsender blokken automatisk, og salte, verifikator-input og HMAC-nøgle kommer fra CryptGenRandom. Hvis det kald fejler, rejser HotXLS en fejl frem for at falde tilbage til en svagere kilde. Et fail-closed CSPRNG er ikke paranoia; en lydløs nedgradering til en forudsigelig tilfældighedskilde producerer filer, der ser krypterede ud, består hver funktionel test og er værdiløse
Hvorfor åbner filer uden blokken stadig?
Fordi et stort antal Agile-krypterede projektmapper i omløb blev skrevet af producenter, der helt udelader dataIntegrity, og at afvise dem ville ødelægge langt mere legitimt arbejde, end det ville beskytte. HotXLS behandler kun integritet som til stede, når begge attributter, den krypterede HMAC-nøgle og den krypterede HMAC-værdi, er der og velformede. Ellers springes verifikation over, og filen åbnes som før
Dette er en kompatibilitetsbeslutning med en sikkerhedskonsekvens, du bør navngive eksplicit i din egen trusselsmodel: fraværet af blokken kan ikke skelnes fra en angriber, der har fjernet den, fordi attributterne ligger uden for den MAC, de ville bære. Hvis du kontrollerer begge ender af en pipeline, bør du behandle en manglende blok som en politikfejl på applikationsniveau. Hvis du modtager filer fra omverdenen, bør du behandle tjekket som det, det er, et værdifuldt signal, når det er til stede, og intet signal overhovedet, når det er fraværende
Adgangskode til at ændre er en konvention, ikke en grænse
Klassiske XLS-projektmapper understøtter en separat mekanisme, der rutinemæssigt forveksles med kryptering: write reservation, Excels "adgangskode til at ændre"-prompt. HotXLS eksponerer den gennem SetModifyPassword, som tager adgangskoden, et anbefal-skrivebeskyttet-flag og navnet på den reserverende bruger, og rapporterer tilstand gennem IsWriteReserved. At sende en tom adgangskode rydder reservationen
Det, der skrives, er et WRITEPROT- og FILESHARING-recordpar, der bærer anbefal-skrivebeskyttet-flaget, en gammeldags 16-bit adgangskodehash og brugernavnet som en BIFF8 Unicode-streng. Den 16-bit hash er en tjeksum, ikke et kryptografisk digest, og selve dokumentindholdet er slet ikke krypteret. Enhver, der åbner filen med et andet værktøj, læser alt. Funktionens reelle opgave er koordinering: den fortæller den næste person, at nogen betragter denne fil som deres at redigere, i samme kategori som de arkkontroller, der dækkes i XLSX-arkbeskyttelse og allow-indstillinger
var
Book: IXLSWorkbook; // interface-tælt: kald ikke Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Anbefal skrivebeskyttet, reserveret af rapporteringstjenesten
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Brug begge lag til det, hver er god til. Reel fortrolighed kommer fra SaveAsEncrypted med en adgangskode, ingen uden for målgruppen har, hvilket producerer det AES-256-output, der beskrives i AES-beskyttet XLSX-output. Write reservation lægges ovenpå, når projektmappen er et delt redigeringsartefakt, og du vil have, at Excel spørger, før nogen gemmer oven i det
Hvad du skal tjekke på en ubetroet indtagelsessti
Integritetsverifikation beskytter den krypterede nyttelast, ikke containeren omkring den. En XLSX-fil er et ZIP-arkiv, og arkivstrukturen parses, før nogen krypteringslogik kører, så validering på containerniveau hører hjemme først i kæden; de specifikke fejltilstande dækkes i ZIP end-of-central-directory-validering for ubetroet XLSX. Derefter bør en integritetsfejl og en forkert adgangskode behandles som samme driftshændelse, fordi de fra din side er umulige at skelne per design, og begge betyder, at filen ikke kan stoles på til at være det, afsenderen tror
Log hvilke filer, der overhovedet bar en dataIntegrity-blok. Over et par tusind dokumenter fortæller den statistik dig noget nyttigt om dine afsenderes værktøjer, og den gør et per-fil-tjek til en observation på flådeniveau, du kan handle på
HotXLS læser og skriver XLS, XLSX og ODS fra Delphi og C++Builder uden nogen Excel-installation og implementerer [MS-OFFCRYPTO] Standard- og Agile-krypteringsstierne i Pascal. Kryptering-, beskyttelse- og projektmappe-API'erne er dokumenteret på HotXLS' produktside for Delphi-regnearkskomponenten