HotXLS skriver en konform dataIntegrity-blokk inn i Agile-krypterte XLSX-pakker og verifiserer den ved åpning. HMAC-SHA-512-en dekker hele EncryptedPackage-strømmen, inkludert den åtte-byte lange StreamSize-prefiksen, og sjekkes over chifferteksten før noe segment dekrypteres, slik at et feil passord eller en endret pakke oppdages i stedet for å dekrypteres til søppel
Kryptering uten integritet er et halvt svar, og Office-filformatene gjør det lett å overse dette gapet fordi krypteringen ser så grundig ut utenfra. Å forstå hva hvert lag lover, er det som holder en sikkerhetsgjennomgang kort
Hva lover egentlig en kryptert arbeidsbok?
Agile-kryptering, definert i [MS-OFFCRYPTO], gir deg konfidensialitet gjennom AES i CBC-modus med en nøkkel utledet fra en iterert SHA-512-passordhash. Konfidensialitet er hele løftet i denne konstruksjonen. CBC er ikke en autentisert modus: den sier ingenting om hvorvidt chifferteksten du dekrypterer, er chifferteksten som ble skrevet
Den praktiske konsekvensen er konkret. Vend bit i en kryptert pakke, og CBC vil villig dekryptere dem til annen klartekst. Du vil vanligvis få en ZIP-analysefeil et sted nedstrøms, fordi en korrupt deflate-strøm sjelden overlever, men «vanligvis» gjør en stor jobb i den setningen, og en nedstrøms parserfeil er et forferdelig sted å oppdage at en fil ble endret. dataIntegrity-elementet finnes for å besvare spørsmålet direkte, før dekryptering, med en MAC over de eksakte bytene
Hvordan sjekken kjører, og i hvilken rekkefølge
Rekkefølgen er den interessante delen. HotXLS utleder mellomnøkkelen fra passordet, dekrypterer den krypterte HMAC-nøkkelen og HMAC-verdien fra dataIntegrity-attributtene ved hjelp av blokknøkkel-utledede IV-er, beregner HMAC-SHA-512 over den krypterte pakken slik den er lagret, og sammenligner. Først deretter begynner segmentdekrypteringen
Å sjekke MAC-en over chifferteksten fremfor klarteksten er den standard encrypt-then-MAC-disiplinen, og det er dette som gjør sjekken meningsfull: en tuklet pakke avvises uten at noen angriperkontrollerte byte har blitt kjørt gjennom dekrypterings- og inflate-veien. Begge sammenligningene i åpningsveien, passordverifiseringshashen og HMAC-verdien, akkumulerer forskjeller med XOR og OR over hele digesten i stedet for å returnere tidlig ved den første ikke-matchende byten, slik at ingen av dem lekker en byteposisjon gjennom tidsbruk
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Fungerer for vanlige, Standard-krypterte og Agile-krypterte filer
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Feil passord, eller en pakke der dataIntegrity-HMAC-en ikke stemte
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;På skrivesiden endres ingenting i koden din. SaveAsEncrypted sender ut blokken automatisk, og saltene, verifikatorinndataen og HMAC-nøkkelen kommer fra CryptGenRandom. Hvis det kallet feiler, kaster HotXLS et unntak i stedet for å falle tilbake til en svakere kilde. En fail-closed CSPRNG er ikke paranoia; en stille nedgradering til en forutsigbar tilfeldig kilde produserer filer som ser krypterte ut, består hver funksjonstest, og er verdiløse
Hvorfor åpnes filer uten blokken likevel?
Fordi svært mange Agile-krypterte arbeidsbøker i omløp ble skrevet av produsenter som utelater dataIntegrity fullstendig, og å avvise dem ville ødelagt langt mer legitimt arbeid enn det ville beskyttet. HotXLS behandler integritet som til stede bare når begge attributtene, den krypterte HMAC-nøkkelen og den krypterte HMAC-verdien, finnes og er velformet. Ellers hoppes verifiseringen over, og filen åpnes som før
Dette er en kompatibilitetsbeslutning med en sikkerhetskonsekvens du bør navngi eksplisitt i din egen trusselmodell: fraværet av blokken kan ikke skilles fra at en angriper fjernet den, fordi attributtene ligger utenfor MAC-en de ville ha båret. Hvis du kontrollerer begge ender av en pipeline, bør du behandle en manglende blokk som en policyfeil på applikasjonsnivå. Hvis du tar imot filer fra verden utenfor, bør du behandle sjekken som det den er: et verdifullt signal når den er til stede, og intet signal i det hele tatt når den er fraværende
Passord for endring er en konvensjon, ikke en grense
Klassiske XLS-arbeidsbøker støtter en separat mekanisme som rutinemessig forveksles med kryptering: skrivereservasjonen, Excels «passord for endring»-dialog. HotXLS eksponerer den gjennom SetModifyPassword, som tar imot passordet, et anbefal-skrivebeskyttet-flagg og navnet til den reserverende brukeren, og rapporterer tilstand gjennom IsWriteReserved. Å sende inn et tomt passord fjerner reservasjonen
Det som skrives, er et WRITEPROT- og FILESHARING-recordpar som bærer anbefal-skrivebeskyttet-flagget, en gammel 16-bits passordhash og brukernavnet som en BIFF8 Unicode-streng. Den 16-bits hashen er en sjekksum, ikke en kryptografisk digest, og dokumentinnholdet er ikke kryptert i det hele tatt. Alle som åpner filen med et annet verktøy, leser alt. Funksjonens egentlige jobb er koordinering: den forteller neste person at noen anser denne filen som sin å redigere, i samme kategori som arksnivåkontrollene dekket i XLSX-arkbeskyttelse og tillat-alternativer
var
Book: IXLSWorkbook; // grensesnitt-tellet: ikke kall Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Anbefal skrivebeskyttet, reservert av rapporteringstjenesten
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Bruk begge lagene til det hvert av dem er gode på. Reell konfidensialitet kommer fra SaveAsEncrypted med et passord ingen utenfor målgruppen har, som produserer AES-256-utdataen beskrevet i AES-beskyttet XLSX-utdata. Skrivereservasjonen kommer på toppen når arbeidsboken er et delt redigeringsartefakt, og du vil at Excel skal spørre før noen lagrer over den
Hva du bør sjekke på en utiltrodd mottaksvei
Integritetsverifisering beskytter den krypterte nyttelasten, ikke beholderen rundt den. En XLSX-fil er et ZIP-arkiv, og arkivstrukturen analyseres før noen krypteringslogikk kjører, så validering på beholdernivå hører hjemme først i kjeden; de spesifikke feilmodusene dekkes i validering av ZIP end-of-central-directory for utiltrodd XLSX. Etter det bør du behandle en integritetsfeil og et feil passord som samme driftshendelse, fordi de fra din side er umulige å skille fra hverandre etter design, og begge betyr at filen ikke kan stoles på å være det avsenderen tror den er
Logg hvilke filer som i det hele tatt bar en dataIntegrity-blokk. Over noen tusen dokumenter forteller den statistikken deg noe nyttig om avsendernes verktøy, og den gjør en per-fil-sjekk om til en observasjon på flåtenivå du kan handle på
HotXLS leser og skriver XLS, XLSX og ODS fra Delphi og C++Builder uten at Excel er installert, og implementerer krypteringsveiene [MS-OFFCRYPTO] Standard og Agile i Pascal. API-ene for kryptering, beskyttelse og arbeidsbok er dokumentert på HotXLS sin side for Delphi regnearkkomponent