HotXLS v pakete XLSX, šifrirane z Agile, zapiše skladen blok dataIntegrity in ga ob odpiranju preveri. HMAC-SHA-512 pokrije celoten tok EncryptedPackage, vključno z njegovo osembajtno predpono StreamSize, in je preverjen nad šifriranim besedilom, preden je dešifriran kakršen koli segment, tako da je napačno geslo ali spremenjen paket zaznan namesto dešifriran v smeti
Šifriranje brez celovitosti je polovičen odgovor, oblike datotek Office pa to vrzel zlahka spregledajo, ker se šifriranje od zunaj zdi tako temeljito. Razumevanje, kaj obljublja vsaka plast, je tisto, kar varnostni pregled ohrani kratek
Kaj dejansko obljublja šifriran delovni zvezek?
Šifriranje Agile, opredeljeno v [MS-OFFCRYPTO], vam da zaupnost prek AES v načinu CBC s ključem, izpeljanim iz iterirane razpršitve gesla SHA-512. Zaupnost je celotna obljuba te konstrukcije. CBC ni avtenticiran način: nič ne pove o tem, ali je šifrirano besedilo, ki ga dešifrirate, tisto, ki je bilo zapisano
Praktična posledica je natančna. Preobrnite bite v šifriranem paketu in CBC jih bo veselo dešifriral v drugačno navadno besedilo. Ponavadi boste nekje po poti dobili napako razčlenjevanja ZIP, ker poškodovan tok deflate redko preživi, toda "ponavadi" v tem stavku opravlja veliko dela, napaka razčlenjevalnika nižje v verigi pa je grozno mesto, da izveste, da je bila datoteka spremenjena. Element dataIntegrity obstaja, da na to vprašanje odgovori neposredno, pred dešifriranjem, z MAC nad natančnimi bajti
Kako teče preverjanje, in v kakšnem vrstnem redu
Vrstni red je zanimivi del. HotXLS izpelje vmesni ključ iz gesla, dešifrira šifrirani ključ HMAC in vrednost HMAC iz atributov dataIntegrity z uporabo inicializacijskih vektorjev, izpeljanih iz bločnega ključa, izračuna HMAC-SHA-512 nad shranjenim šifriranim paketom in ga primerja. Šele nato se začne dešifriranje segmentov
Preverjanje MAC nad šifriranim besedilom namesto nad navadnim besedilom je standardna disciplina šifriraj-nato-MAC, in prav to preverjanje naredi smiselno: spremenjen paket je zavrnjen, ne da bi kateri koli bajt, ki ga nadzoruje napadalec, sploh šel skozi pot dešifriranja in inflacije. Obe primerjavi na poti odpiranja, razpršitev preveritelja gesla in vrednost HMAC, kopičita razlike z XOR in OR čez celoten prstni odtis namesto da bi se predčasno vrnili ob prvem neujemajočem bajtu, zato nobena ne razkrije položaja bajta prek časovnega vzorca
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Deluje za navadne, s Standard šifrirane in z Agile šifrirane datoteke
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Napačno geslo, ali paket, katerega HMAC dataIntegrity se ni ujemal
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Na pisalni strani se v vaši kodi ne spremeni nič. SaveAsEncrypted blok zapiše samodejno, soli, vhod preveritelja in ključ HMAC pa prihajajo iz CryptGenRandom. Če ta klic odpove, HotXLS sproži izjemo namesto da bi padel nazaj na šibkejši vir. CSPRNG, ki ob napaki zapre dostop, ni paranoja; tih padec na predvidljiv naključni vir ustvari datoteke, ki izgledajo šifrirane, prestanejo vsak funkcionalni test in so povsem brez vrednosti
Zakaj se datoteke brez tega bloka še vedno odprejo?
Ker je veliko delovnih zvezkov, šifriranih z Agile in v obtoku, napisanih z izdelovalci, ki dataIntegrity povsem izpustijo, njihova zavrnitev pa bi pokvarila veliko več legitimnega dela, kot bi ga zaščitila. HotXLS obravnava celovitost kot prisotno le, kadar sta prisotna oba atributa, šifrirani ključ HMAC in šifrirana vrednost HMAC, in sta pravilno oblikovana. Sicer se preverjanje preskoči in datoteka se odpre kot prej
To je odločitev o združljivosti z varnostno posledico, ki jo velja izrecno poimenovati v svojem lastnem modelu groženj: odsotnosti bloka ni mogoče razločiti od napadalca, ki ga je odstranil, ker so atributi izven MAC, ki bi ga sicer nosili. Če nadzorujete oba konca cevovoda, obravnavajte manjkajoč blok kot napako politike na ravni aplikacije. Če sprejemate datoteke iz sveta, obravnavajte preverjanje kot to, kar je, dragocen signal, kadar je prisoten, in nikakršen signal, kadar ni
Geslo za urejanje je konvencija, ne meja
Klasični delovni zvezki XLS podpirajo ločen mehanizem, ki ga redno zamenjujejo s šifriranjem: rezervacijo za pisanje, Excelov poziv "geslo za urejanje" (password to modify). HotXLS jo izpostavi prek SetModifyPassword, ki sprejme geslo, zastavico priporočila le za branje in ime uporabnika, ki rezervira, stanje pa poroča prek IsWriteReserved. Podajanje praznega gesla rezervacijo počisti
Zapisan je par zapisov WRITEPROT in FILESHARING, ki nosi zastavico priporočila le za branje, zastarelo 16-bitno razpršitev gesla in ime uporabnika kot niz Unicode BIFF8. Ta 16-bitna razpršitev je kontrolna vsota in ne kriptografski povzetek, vsebina dokumenta pa sploh ni šifrirana. Vsakdo, ki datoteko odpre s katerim koli drugim orodjem, prebere vse. Prava naloga te funkcije je usklajevanje: naslednji osebi pove, da nekdo šteje to datoteko za svojo za urejanje, v isti kategoriji kot nadzor na ravni delovnega lista, obravnavan v zaščiti listov XLSX in možnostih dovoljenj
var
Book: IXLSWorkbook; // šteto z referencami: ne kličite Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Priporoči le za branje, rezervirala storitev poročanja
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Obe plasti uporabite za tisto, v čemer je vsaka dobra. Prava zaupnost prihaja iz SaveAsEncrypted z geslom, ki ga nima nihče zunaj občinstva, kar ustvari izhod AES-256, opisan v izhodu XLSX, zaščitenem z AES. Rezervacija za pisanje pride na vrh, kadar je delovni zvezek artefakt skupnega urejanja in želite, da Excel vpraša, preden nekdo shrani čeznj
Kaj preveriti na nezaupljivi poti sprejema
Preverjanje celovitosti ščiti šifrirano vsebino, ne vsebnika okoli nje. Datoteka XLSX je arhiv ZIP, struktura arhiva pa je razčlenjena, preden steče kakršna koli logika šifriranja, zato veljavnost na ravni vsebnika sodi na prvo mesto v verigi; specifični načini odpovedi so obravnavani v preverjanju konca osrednjega imenika ZIP za nezaupljive XLSX. Po tem obravnavajte napako celovitosti in napačno geslo kot isti operativni dogodek, ker sta z vaše strani po zasnovi neločljiva, oba pa pomenita, da datoteki ni mogoče zaupati, da je to, za kar pošiljatelj misli, da je
Beležite, katere datoteke so sploh nosile blok dataIntegrity. Čez nekaj tisoč dokumentov vam ta statistika pove nekaj uporabnega o orodjih vaših pošiljateljev in spremeni preverjanje po posamezni datoteki v opažanje na ravni celotne flote, na podlagi katerega lahko ukrepate
HotXLS bere in zapisuje XLS, XLSX in ODS iz Delphija in C++Builderja brez namestitve Excela, pri čemer izvaja poti šifriranja Standard in Agile iz [MS-OFFCRYPTO] v Pascalu. API-ji za šifriranje, zaščito in delovni zvezek so dokumentirani na strani izdelka HotXLS