Odhaľte upravené XLSX: HotXLS Agile dataIntegrity HMAC

HotXLS zapisuje do balíkov XLSX šifrovaných pomocou Agile konformný blok dataIntegrity a pri otvorení ho overuje. HMAC-SHA-512 pokrýva celý tok EncryptedPackage vrátane jeho osembajtovej predpony StreamSize a kontroluje sa nad šifrovaným textom skôr, než sa dešifruje čo i len jeden segment, takže sa nesprávne heslo alebo upravený balík odhalí namiesto toho, aby sa dešifroval na nezmysel

Šifrovanie bez integrity je len polovičná odpoveď, a formáty súborov Office túto medzeru ľahko zakryjú, pretože šifrovanie vyzerá zvonka natoľko dôkladne. Pochopiť, čo sľubuje každá vrstva, je to, čo drží bezpečnostnú kontrolu krátkou

Čo naozaj sľubuje zašifrovaný zošit?

Šifrovanie Agile, definované v [MS-OFFCRYPTO], vám dáva dôvernosť pomocou AES v režime CBC s kľúčom odvodeným z iterovaného hashu hesla SHA-512. Dôvernosť je celý sľub tejto konštrukcie. CBC nie je autentizovaný režim: nehovorí nič o tom, či šifrovaný text, ktorý dešifrujete, je ten istý, aký bol zapísaný

Praktický dôsledok je konkrétny. Preklopte bity v šifrovanom balíku a CBC ich ochotne dešifruje na iný plaintext. Zvyčajne niekde ďalej po ceste dostanete chybu pri parsovaní ZIP, pretože poškodený deflate tok len zriedka prežije, ale slovo „zvyčajne“ tu robí veľa práce, a chyba parsera ďalej po ceste je hrozné miesto na to, aby ste sa dozvedeli, že súbor bol upravený. Prvok dataIntegrity existuje práve na to, aby odpovedal na túto otázku priamo, ešte pred dešifrovaním, pomocou MAC nad presnými bajtami

Ako kontrola prebieha, a v akom poradí

Zaujímavé je práve poradie krokov. HotXLS odvodí medziľahlý kľúč z hesla, dešifruje zašifrovaný kľúč HMAC a hodnotu HMAC z atribútov dataIntegrity pomocou IV odvodených z kľúča bloku, vypočíta HMAC-SHA-512 nad zašifrovaným balíkom tak, ako je uložený, a porovná. Až potom začne dešifrovanie segmentov

Kontrola MAC nad šifrovaným textom namiesto plaintextu je štandardná disciplína encrypt-then-MAC, a práve to robí kontrolu zmysluplnou: upravený balík sa odmietne bez toho, aby čo i len jeden bajt kontrolovaný útočníkom prešiel dešifrovaním a inflate cestou. Obe porovnania na ceste otvorenia — hash overovača hesla aj hodnota HMAC — hromadia rozdiely pomocou XOR a OR naprieč celým digestom namiesto toho, aby sa predčasne vrátili pri prvom nezhodnom bajte, takže ani jedno neuniká pozíciu bajtu cez časovanie

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    // Funguje pre nešifrované, Standard-šifrované aj Agile-šifrované súbory
    if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
      ProcessWorkbook(Book)
    else
      // Nesprávne heslo, alebo balík, ktorého dataIntegrity HMAC nesúhlasil
      Quarantine('incoming.xlsx');
  except
    on E: Exception do
      Quarantine('incoming.xlsx: ' + E.Message);
  end;
  Book.Free;
end;

Na strane zápisu sa vo vašom kóde nič nemení. SaveAsEncrypted blok vygeneruje automaticky, a soli, vstup overovača a kľúč HMAC pochádzajú z CryptGenRandom. Ak toto volanie zlyhá, HotXLS vyvolá výnimku namiesto toho, aby sa vrátil k slabšiemu zdroju. Fail-closed CSPRNG nie je paranoja; tichý pád na predvídateľný zdroj náhodnosti produkuje súbory, ktoré vyzerajú zašifrované, prejdú každým funkčným testom a sú bezcenné

Prečo sa súbory bez tohto bloku aj tak otvoria?

Pretože veľké množstvo Agile-šifrovaných zošitov v obehu bolo zapísaných producentmi, ktorí dataIntegrity úplne vynechávajú, a ich odmietnutie by rozbilo oveľa viac legitímnej práce, než by ochránilo. HotXLS považuje integritu za prítomnú iba vtedy, keď sú prítomné a správne formátované oba atribúty — zašifrovaný kľúč HMAC aj zašifrovaná hodnota HMAC. Inak sa overenie preskočí a súbor sa otvorí ako predtým

Ide o kompatibilné rozhodnutie s bezpečnostným dôsledkom, ktorý by ste mali explicitne pomenovať vo svojom vlastnom modeli hrozieb: neprítomnosť bloku sa nedá odlíšiť od toho, že ho útočník odstránil, pretože atribúty ležia mimo MAC, ktorý by inak niesli. Ak kontrolujete oba konce pipeline, považujte chýbajúci blok za zlyhanie politiky na úrovni aplikácie. Ak prijímate súbory odkiaľkoľvek, berte kontrolu za to, čím naozaj je — cenný signál, keď je prítomná, a žiadny signál, keď prítomná nie je

Heslo na úpravu je konvencia, nie hranica

Klasické zošity XLS podporujú samostatný mechanizmus, ktorý sa bežne zamieňa so šifrovaním: rezerváciu zápisu, teda výzvu Excelu „heslo na úpravu“. HotXLS ju sprístupňuje cez SetModifyPassword, ktorá prijíma heslo, príznak odporúčania len na čítanie a meno rezervujúceho používateľa, a stav hlási cez IsWriteReserved. Odovzdanie prázdneho hesla rezerváciu zruší

Zapíše sa dvojica záznamov WRITEPROT a FILESHARING nesúca príznak odporúčania len na čítanie, zastaraný 16-bitový hash hesla a meno používateľa ako reťazec BIFF8 Unicode. Tento 16-bitový hash je kontrolný súčet, nie kryptografický digest, a obsah dokumentu vôbec nie je zašifrovaný. Ktokoľvek, kto otvorí súbor akýmkoľvek iným nástrojom, prečíta úplne všetko. Skutočnou úlohou tejto funkcie je koordinácia: hovorí ďalšej osobe, že niekto považuje tento súbor za svoj na úpravu, v rovnakej kategórii ako ovládacie prvky na úrovni hárku opísané v článku ochrana hárku XLSX a voľby povolení

var
  Book: IXLSWorkbook;   // počítané cez rozhranie: nevolajte Free
begin
  Book := TXLSWorkbook.Create;
  if Book.Open('shared-model.xls') = 1 then
  begin
    // Odporučiť len na čítanie, rezervované reportovacou službou
    Book.SetModifyPassword('edit-me', True, 'Reporting Service');

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

Používajte obe vrstvy na to, na čo je každá z nich dobrá. Skutočná dôvernosť pochádza z SaveAsEncrypted s heslom, ktoré nedrží nikto mimo cieľového publika, čo produkuje výstup AES-256 opísaný v článku výstup XLSX chránený AES. Rezervácia zápisu ide navrch vtedy, keď je zošit zdieľaný editačný artefakt a chcete, aby sa Excel spýtal skôr, než ho niekto prepíše

Čo skontrolovať na nedôveryhodnej vstupnej ceste

Overenie integrity chráni zašifrovaný payload, nie kontajner okolo neho. Súbor XLSX je archív ZIP, a štruktúra archívu sa parsuje skôr, než začne bežať akákoľvek šifrovacia logika, takže validácia na úrovni kontajnera patrí v reťazi na prvé miesto; konkrétne spôsoby zlyhania sú opísané v článku validácia ZIP end-of-central-directory pre nedôveryhodné XLSX. Potom zaobchádzajte so zlyhaním integrity a nesprávnym heslom ako s tou istou prevádzkovou udalosťou, pretože z vašej strany sú zámerne nerozlíšiteľné, a oboje znamená, že súboru sa nedá dôverovať, že je tým, čím ho odosielateľ považuje

Logujte, ktoré súbory vôbec niesli blok dataIntegrity. Naprieč niekoľkými tisíckami dokumentov vám táto štatistika povie niečo užitočné o nástrojoch vašich odosielateľov a mení kontrolu na úrovni jedného súboru na pozorovanie na úrovni celej flotily, na základe ktorého môžete konať

HotXLS číta a zapisuje XLS, XLSX a ODS z Delphi a C++Builder bez nainštalovaného Excelu, pričom cesty šifrovania Standard aj Agile z [MS-OFFCRYPTO] implementuje priamo v Pascale. API pre šifrovanie, ochranu a prácu so zošitom sú zdokumentované na stránke HotXLS Delphi spreadsheet component