Otkrivanje izmjena XLSX-a: HotXLS dataIntegrity HMAC

HotXLS zapisuje sukladan blok dataIntegrity u Agile-šifrirane XLSX pakete i provjerava ga pri otvaranju. HMAC-SHA-512 pokriva cijeli tok EncryptedPackage, uključujući njegov osambajtni prefiks StreamSize, i provjerava se nad šifriranim tekstom prije nego što se dešifrira ijedan segment, tako da se pogrešna lozinka ili izmijenjen paket otkrivaju umjesto da se dešifriraju u besmislen sadržaj

Enkripcija bez integriteta samo je pola odgovora, a formati Office datoteka olakšavaju previd tog nedostatka jer enkripcija izvana djeluje toliko temeljito. Razumijevanje što svaki sloj zapravo jamči ono je što sigurnosnu reviziju drži kratkom

Što šifrirana radna knjiga zapravo jamči?

Agile enkripcija, definirana u [MS-OFFCRYPTO], daje vam povjerljivost putem AES-a u CBC načinu rada s ključem izvedenim iz iteriranog SHA-512 sažetka lozinke. Povjerljivost je cjelokupno obećanje te konstrukcije. CBC nije autenticirani način rada: ne govori ništa o tome je li šifrirani tekst koji dešifrirate isti onaj koji je izvorno zapisan

Praktična je posljedica konkretna. Promijenite bitove u šifriranom paketu i CBC će ih sasvim spremno dešifrirati u drugačiji čisti tekst. Obično ćete negdje nizvodno dobiti pogrešku parsiranja ZIP-a, jer oštećen deflate tok rijetko preživi, ali riječ „obično” u toj rečenici nosi veliku odgovornost, a pogreška parsera nizvodno grozno je mjesto na kojem ćete saznati da je datoteka izmijenjena. Element dataIntegrity postoji upravo da izravno odgovori na to pitanje, prije dešifriranja, pomoću MAC-a nad točnim bajtovima

Kako provjera teče, i kojim redoslijedom

Redoslijed je zanimljivi dio. HotXLS izvodi međuključ iz lozinke, dešifrira šifrirani HMAC ključ i HMAC vrijednost iz atributa dataIntegrity koristeći IV-ove izvedene iz ključa bloka, izračunava HMAC-SHA-512 nad pohranjenim šifriranim paketom i uspoređuje rezultate. Tek se tada počinje dešifrirati segmente

Provjera MAC-a nad šifriranim tekstom, a ne nad čistim tekstom, standardna je disciplina encrypt-then-MAC, i upravo to čini provjeru smislenom: izmijenjen paket odbacuje se bez da ijedan bajt pod kontrolom napadača prođe kroz putanju dešifriranja i inflacije. Obje usporedbe u putanji otvaranja, sažetak verifikatora lozinke i HMAC vrijednost, akumuliraju razlike pomoću XOR-a i OR-a preko cijelog sažetka umjesto da se prekinu na prvom neusklađenom bajtu, tako da nijedna ne otkriva poziciju bajta putem vremena izvođenja

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    // Radi za obične, Standard-šifrirane i Agile-šifrirane datoteke
    if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
      ProcessWorkbook(Book)
    else
      // Pogrešna lozinka, ili paket čiji se dataIntegrity HMAC nije podudarao
      Quarantine('incoming.xlsx');
  except
    on E: Exception do
      Quarantine('incoming.xlsx: ' + E.Message);
  end;
  Book.Free;
end;

Na strani pisanja u vašem se kodu ništa ne mijenja. SaveAsEncrypted automatski emitira taj blok, a soli, ulaz verifikatora i HMAC ključ dolaze iz CryptGenRandom. Ako taj poziv ne uspije, HotXLS izaziva iznimku umjesto da se vrati na slabiji izvor. Fail-closed CSPRNG nije paranoja; tihi pad na predvidljiv izvor slučajnih brojeva proizvodi datoteke koje izgledaju šifrirano, prolaze svaki funkcionalni test, a bezvrijedne su

Zašto se datoteke bez tog bloka i dalje otvaraju?

Zato što je vrlo velik broj Agile-šifriranih radnih knjiga u optjecaju napisan proizvođačima koji dataIntegrity potpuno izostavljaju, a njihovo bi odbacivanje pokvarilo mnogo više legitimnog posla nego što bi zaštitilo. HotXLS integritet smatra prisutnim samo kada su oba atributa, šifrirani HMAC ključ i šifrirana HMAC vrijednost, prisutna i pravilno oblikovana. U suprotnom se provjera preskače, a datoteka se otvara kao i prije

To je odluka o kompatibilnosti sa sigurnosnom posljedicom koju biste trebali izrijekom navesti u vlastitom modelu prijetnji: odsutnost bloka ne može se razlikovati od toga da ga je napadač uklonio, jer su atributi izvan MAC-a koji bi ih inače nosio. Ako kontrolirate oba kraja pipelinea, tretirajte nedostajući blok kao kvar politike na razini aplikacije. Ako primate datoteke iz vanjskog svijeta, tretirajte provjeru onakvom kakva jest, vrijednim signalom kada je prisutna, a potpunim odsustvom signala kada nije

Lozinka za izmjenu konvencija je, a ne granica

Klasične XLS radne knjige podržavaju zaseban mehanizam koji se redovito zamjenjuje s enkripcijom: rezervaciju pisanja, Excelov upit „lozinka za izmjenu”. HotXLS ju izlaže kroz SetModifyPassword, koja prima lozinku, zastavicu preporuke samo za čitanje i ime korisnika koji rezervira datoteku, a stanje prijavljuje kroz IsWriteReserved. Prosljeđivanje prazne lozinke uklanja rezervaciju

Ono što se zapisuje jest par zapisa WRITEPROT i FILESHARING koji nose zastavicu preporuke samo za čitanje, zastarjeli 16-bitni sažetak lozinke i ime korisnika kao BIFF8 Unicode niz. Taj 16-bitni sažetak je kontrolni zbroj, a ne kriptografski sažetak, a sadržaj dokumenta uopće nije šifriran. Svatko tko datoteku otvori bilo kojim drugim alatom pročitat će sve. Prava je zadaća ove značajke koordinacija: ona sljedećoj osobi govori da netko ovu datoteku smatra svojom za uređivanje, u istoj kategoriji kao i kontrole na razini lista obrađene u članku XLSX zaštita lista i opcije dopuštanja

var
  Book: IXLSWorkbook;   // brojano po referencama sučelja: ne oslobađati (Free)
begin
  Book := TXLSWorkbook.Create;
  if Book.Open('shared-model.xls') = 1 then
  begin
    // Preporuči samo za čitanje, rezervirala usluga izvještavanja
    Book.SetModifyPassword('edit-me', True, 'Reporting Service');

    if Book.IsWriteReserved then
      Book.SaveAs('shared-model.xls', xlExcel97);
  end;
end;

Koristite oba sloja za ono u čemu je svaki dobar. Prava povjerljivost dolazi iz SaveAsEncrypted s lozinkom koju nitko izvan publike nema, što proizvodi AES-256 izlaz opisan u članku AES-zaštićeni XLSX izlaz. Rezervacija pisanja dodaje se na vrh kada je radna knjiga zajednički artefakt za uređivanje i kada želite da Excel pita prije nego što je netko prepiše

Što provjeriti na putanji prihvata nepouzdanih datoteka

Provjera integriteta štiti šifrirani sadržaj, a ne omotnicu oko njega. XLSX datoteka je ZIP arhiva, a struktura arhive parsira se prije nego što se pokrene ikakva logika enkripcije, pa validacija na razini spremnika pripada na prvo mjesto u lancu; konkretni načini kvara obrađeni su u članku validacija ZIP end-of-central-directory za nepouzdane XLSX datoteke. Nakon toga, tretirajte neuspjeh integriteta i pogrešnu lozinku kao isti operativni događaj, jer su s vaše strane po dizajnu nerazlučivi, a oba znače da se ne može vjerovati da je datoteka ono što pošiljatelj misli da jest

Zabilježite koje su datoteke uopće nosile blok dataIntegrity. Na nekoliko tisuća dokumenata ta vam statistika govori nešto korisno o alatima vaših pošiljatelja, i pretvara provjeru po pojedinoj datoteci u opažanje na razini cijele flote na temelju kojeg možete djelovati

HotXLS čita i piše XLS, XLSX i ODS iz Delphija i C++Buildera bez instaliranog Excela, implementirajući putanje [MS-OFFCRYPTO] Standard i Agile enkripcije u Pascalu. API za enkripciju, zaštitu i radne knjige dokumentiran je na stranici HotXLS Delphi komponente za proračunske tablice