Odhalte poškozený XLSX: HotXLS Agile dataIntegrity HMAC

HotXLS zapisuje do Agile šifrovaných balíčků XLSX konformní blok dataIntegrity a při otevření ho ověřuje. HMAC-SHA-512 pokrývá celý proud EncryptedPackage, včetně jeho osmibajtové předpony StreamSize, a kontroluje se nad šifrovaným textem ještě předtím, než se dekóduje jakýkoli segment, takže se odhalí špatné heslo nebo pozměněný balíček, místo aby se dekódovaly do nesmyslu

Šifrování bez integrity je jen poloviční odpověď, a formáty souborů Office tuto mezeru snadno maskují, protože šifrování zvenčí vypadá tak důkladně. Pochopení toho, co slibuje každá vrstva, je to, co udrží bezpečnostní revizi krátkou

Co vlastně slibuje šifrovaný sešit?

Agile šifrování, definované v [MS-OFFCRYPTO], vám dává důvěrnost prostřednictvím AES v režimu CBC s klíčem odvozeným z iterovaného hashe hesla SHA-512. Důvěrnost je celý slib této konstrukce. CBC není autentizovaný režim: neříká vůbec nic o tom, jestli šifrovaný text, který dekódujete, je ten, který byl zapsán

Praktický důsledek je konkrétní. Otočíte bity v šifrovaném balíčku a CBC je ochotně dekóduje do jiného otevřeného textu. Obvykle dostanete někde po proudu chybu parsování ZIP, protože poškozený deflate proud jen zřídka přežije, ale slovo „obvykle" v této větě odvádí hodně práce, a chyba parseru po proudu je hrozné místo na to, abyste se dozvěděli, že byl soubor pozměněný. Prvek dataIntegrity existuje proto, aby odpověděl na tuto otázku přímo, ještě před dekódováním, pomocí MAC nad přesnými bajty

Jak kontrola probíhá a v jakém pořadí

To zajímavé je pořadí. HotXLS odvodí mezilehlý klíč z hesla, dekóduje šifrovaný klíč HMAC a hodnotu HMAC z atributů dataIntegrity pomocí IV odvozených z klíče bloku, spočítá HMAC-SHA-512 nad uloženým šifrovaným balíčkem a porovná. Teprve poté začne dekódování segmentů

Kontrola MAC nad šifrovaným textem místo nad otevřeným textem je standardní disciplína encrypt-then-MAC, a právě to dělá kontrolu smysluplnou: pozměněný balíček se odmítne, aniž by jakékoli bajty pod kontrolou útočníka prošly cestou dekódování a inflace. Obě porovnání na cestě otevírání – hash verifieru hesla i hodnota HMAC – akumulují rozdíly pomocí XOR a OR napříč celým digestem místo předčasného návratu při prvním neshodujícím se bajtu, takže žádné z nich neprozradí pozici bajtu přes časování

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    // funguje pro obyčejné i Standard/Agile šifrované soubory
    if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
      ProcessWorkbook(Book)
    else
      // špatné heslo nebo balíček, jehož HMAC dataIntegrity nesouhlasil
      Quarantine('incoming.xlsx');
  except
    on E: Exception do
      Quarantine('incoming.xlsx: ' + E.Message);
  end;
  Book.Free;
end;

Na straně zápisu se ve vašem kódu nic nemění. SaveAsEncrypted blok vyprodukuje automaticky a soli, vstup verifieru a klíč HMAC pocházejí z CryptGenRandom. Pokud toto volání selže, HotXLS vyvolá výjimku, místo aby se vrátil ke slabšímu zdroji. Uzavřené selhání CSPRNG není paranoia; tiché snížení na předvídatelný zdroj náhodnosti vytváří soubory, které vypadají zašifrovaně, projdou každým funkčním testem a jsou bezcenné

Proč se soubory bez tohoto bloku pořád dají otevřít?

Protože velké množství Agile šifrovaných sešitů v oběhu bylo zapsáno producenty, kteří dataIntegrity úplně vynechávají, a jejich odmítání by rozbilo mnohem víc legitimní práce, než kolik by ochránilo. HotXLS považuje integritu za přítomnou, jen když jsou přítomné a správně formátované oba atributy – šifrovaný klíč HMAC i šifrovaná hodnota HMAC. Jinak se ověření přeskočí a soubor se otevře jako dřív

Jde o rozhodnutí ohledně kompatibility s bezpečnostním důsledkem, který byste měli ve svém vlastním modelu hrozeb výslovně pojmenovat: nepřítomnost bloku nelze odlišit od toho, že ho útočník odstranil, protože atributy leží mimo MAC, který by nesly. Pokud máte pod kontrolou oba konce pipeline, berte chybějící blok jako selhání politiky na úrovni aplikace. Pokud přijímáte soubory odkudkoli ze světa, berte kontrolu za to, čím skutečně je – hodnotným signálem, když je přítomná, a žádným signálem, když přítomná není

Heslo k úpravě je konvence, ne hranice

Klasické sešity XLS podporují samostatný mechanismus, který se běžně zaměňuje se šifrováním: rezervaci zápisu, tedy excelovskou výzvu „heslo k úpravě". HotXLS ji zpřístupňuje přes SetModifyPassword, která přijímá heslo, příznak doporučující jen ke čtení a jméno uživatele, který rezervaci provádí, a hlásí stav přes IsWriteReserved. Předáním prázdného hesla se rezervace zruší

Zapíše se dvojice záznamů WRITEPROT a FILESHARING nesoucí příznak doporučující jen ke čtení, zastaralý 16bitový hash hesla a jméno uživatele jako řetězec BIFF8 Unicode. Tento 16bitový hash je kontrolní součet, ne kryptografický digest, a obsah dokumentu se vůbec nešifruje. Kdokoli, kdo otevře soubor jakýmkoli jiným nástrojem, přečte úplně všechno. Skutečným úkolem této funkce je koordinace: sděluje dalšímu člověku, že někdo tento soubor považuje za svůj k úpravě, a spadá do stejné kategorie jako ovládací prvky na úrovni listu popsané v článku o ochraně listu XLSX a povolovacích volbách

var
  Book: IXLSWorkbook;   // interface-counted: do not Free
begin
  Book := TXLSWorkbook.Create;
  if Book.Open('shared-model.xls') = 1 then
  begin
    // doporučeno jen ke čtení, rezervováno reportovací službou
    Book.SetModifyPassword('edit-me', True, 'Reporting Service');

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

Používejte obě vrstvy na to, v čem je každá z nich dobrá. Skutečná důvěrnost pochází z SaveAsEncrypted s heslem, které nemá nikdo mimo cílové publikum, což vyprodukuje výstup AES-256 popsaný v článku o výstupu XLSX chráněném AES. Rezervace zápisu se přidává navrch ve chvíli, kdy je sešit sdíleným editačním artefaktem a chcete, aby se Excel zeptal, než ho někdo přepíše

Co kontrolovat na nedůvěryhodné vstupní cestě

Ověření integrity chrání šifrovaný obsah, ne kontejner kolem něj. Soubor XLSX je archiv ZIP a struktura archivu se parsuje ještě předtím, než se spustí jakákoli logika šifrování, takže validace na úrovni kontejneru patří v řetězci na první místo; konkrétní typy selhání popisuje článek o validaci konce centrálního adresáře ZIP u nedůvěryhodných XLSX. Poté berte selhání integrity a špatné heslo jako stejnou provozní událost, protože z vaší strany jsou záměrně nerozlišitelné, a oba případy znamenají, že souboru nelze věřit, že je tím, čím ho odesílatel považuje

Logujte si, které soubory vůbec nesly blok dataIntegrity. Na několika tisících dokumentů vám tato statistika řekne něco užitečného o nástrojích vašich odesílatelů a promění kontrolu jednotlivých souborů v pozorování na úrovni celé flotily, na jehož základě lze jednat

HotXLS čte a zapisuje XLS, XLSX a ODS z Delphi a C++Builder bez instalace Excelu a implementuje šifrovací cesty [MS-OFFCRYPTO] Standard i Agile přímo v Pascalu. API pro šifrování, ochranu i práci se sešitem jsou zdokumentované na stránce HotXLS Delphi spreadsheet component