A HotXLS egy szabványos dataIntegrity blokkot ír az Agile-titkosítású XLSX csomagokba, és megnyitáskor ellenőrzi azt. A HMAC-SHA-512 a teljes EncryptedPackage streamet lefedi, beleértve annak nyolcbyte-os StreamSize előtagját is, és a titkosított szöveg felett kerül ellenőrzésre, mielőtt bármely szegmens dekódolásra kerülne, így egy rossz jelszó vagy egy módosított csomag felismerésre kerül, ahelyett hogy hibás adatra dekódolódna
A titkosítás integritás nélkül csak félmegoldás, és az Office fájlformátumok könnyűvé teszik ennek a résnek a figyelmen kívül hagyását, mert a titkosítás kívülről annyira alaposnak tűnik. Annak megértése, hogy az egyes rétegek mit ígérnek, az, ami rövidre zár egy biztonsági felülvizsgálatot
Mit ígér valójában egy titkosított munkafüzet?
Az [MS-OFFCRYPTO]-ban meghatározott Agile titkosítás bizalmasságot nyújt AES CBC módban, egy iterált SHA-512 jelszó-hash-ből származtatott kulccsal. A bizalmasság ennek a konstrukciónak a teljes ígérete. A CBC nem hitelesített mód: semmit sem mond arról, hogy a titkosított szöveg, amelyet dekódolsz, ugyanaz-e, mint amelyet írtak
A gyakorlati következmény konkrét. Forgass bitet egy titkosított csomagban, és a CBC szívesen dekódolja azokat egy másik nyílt szöveggé. Általában egy ZIP-elemzési hibát kapsz valahol lentebb, mert egy sérült deflate stream ritkán éli túl, de a „általában” szó rengeteget dolgozik ebben a mondatban, és egy lentebbi elemzési hiba szörnyű hely arra, hogy megtudd, egy fájlt módosítottak. A dataIntegrity elem azért létezik, hogy közvetlenül, dekódolás előtt válaszolja meg ezt a kérdést, egy MAC-cel a pontos byte-ok felett
Hogyan fut az ellenőrzés, és milyen sorrendben
A sorrend az érdekes rész. A HotXLS a jelszóból származtatja a köztes kulcsot, dekódolja a titkosított HMAC kulcsot és a HMAC értéket a dataIntegrity attribútumokból blokk-kulcsból származtatott IV-k használatával, kiszámítja a HMAC-SHA-512-t a tárolt titkosított csomag felett, és összehasonlítja. Csak ezután kezdődik a szegmensek dekódolása
A MAC ellenőrzése a titkosított szöveg, nem a nyílt szöveg felett a szabványos encrypt-then-MAC elv, és ez teszi az ellenőrzést értelmessé: egy manipulált csomag elutasításra kerül anélkül, hogy bármilyen támadó által vezérelt byte végigfutott volna a dekódolási és kibontási útvonalon. A megnyitási útvonal mindkét összehasonlítása, a jelszó-ellenőrző hash és a HMAC érték, XOR és OR művelettel halmozza az eltéréseket a teljes digest felett, ahelyett hogy az első eltérő byte-nál korán visszatérne, így egyik sem szivárogtat byte-pozíciót az időzítésen keresztül
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Sima, Standard- és Agile-titkosítású fájloknál egyaránt működik
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Rossz jelszó, vagy egy csomag, amelynek dataIntegrity HMAC-ja nem egyezett
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Az írási oldalon semmi sem változik a kódodban. A SaveAsEncrypted automatikusan kiadja a blokkot, és a saltok, a verifier bemenet és a HMAC kulcs a CryptGenRandom függvényből származnak. Ha az a hívás meghiúsul, a HotXLS kivételt dob, ahelyett hogy egy gyengébb forrásra esne vissza. Egy fail-closed CSPRNG nem paranoia; egy csendes visszaesés egy kiszámítható véletlenforrásra olyan fájlokat állít elő, amelyek titkosítottnak tűnnek, minden funkcionális teszten átmennek, és értéktelenek
Miért nyílnak meg mégis a blokk nélküli fájlok?
Mert nagyon sok forgalomban lévő Agile-titkosítású munkafüzetet olyan előállítók írtak, amelyek teljesen kihagyják a dataIntegrity blokkot, és ezek elutasítása sokkal több legitim munkát törne el, mint amennyit védene. A HotXLS csak akkor kezeli jelenlévőként az integritást, ha mindkét attribútum, a titkosított HMAC kulcs és a titkosított HMAC érték, jelen van és jól formázott. Egyébként az ellenőrzés kimarad, és a fájl a korábbi módon nyílik meg
Ez egy kompatibilitási döntés egy biztonsági következménnyel, amelyet érdemes explicit módon megnevezned a saját fenyegetettségi modelledben: a blokk hiánya nem különböztethető meg attól, hogy egy támadó eltávolította azt, mert az attribútumok kívül esnek azon a MAC-on, amelyet hordoznának. Ha te irányítod egy folyamat mindkét végét, kezeld a hiányzó blokkot alkalmazásszintű szabályzatsértésként. Ha a világ bármely pontjáról fogadsz fájlokat, kezeld az ellenőrzést annak, ami: értékes jelzésnek, ha jelen van, és semmilyen jelzésnek, ha hiányzik
A módosítási jelszó egy konvenció, nem egy határ
A klasszikus XLS munkafüzetek egy külön mechanizmust támogatnak, amelyet rendszeresen összekevernek a titkosítással: az írásfoglalást, az Excel „jelszó a módosításhoz” párbeszédablakát. A HotXLS ezt a SetModifyPassword függvényen keresztül teszi elérhetővé, amely elfogadja a jelszót, egy csak-olvasásra-ajánlott jelzőt és a foglaló felhasználónevet, és az IsWriteReserved függvényen keresztül jelenti az állapotot. Egy üres jelszó átadása törli a foglalást
Ami megíródik, az egy WRITEPROT és FILESHARING rekordpár, amely hordozza a csak-olvasásra-ajánlott jelzőt, egy örökölt 16 bites jelszó-hash-t és a felhasználónevet BIFF8 Unicode stringként. Ez a 16 bites hash egy ellenőrző összeg, nem kriptográfiai digest, és a dokumentum tartalma egyáltalán nincs titkosítva. Bárki, aki bármilyen más eszközzel nyitja meg a fájlt, mindent olvashat. A funkció valódi feladata a koordináció: megmondja a következő embernek, hogy valaki ezt a fájlt a sajátjának tekinti szerkesztés céljából, ugyanabban a kategóriában, mint a XLSX munkalapvédelem és engedélyezési beállítások című cikkben tárgyalt munkalap-szintű vezérlők
var
Book: IXLSWorkbook; // interfész-számlált: ne hívj Free-t rá
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Csak olvasásra ajánlott, a jelentéskészítő szolgáltatás foglalta le
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Használd mindkét réteget arra, amiben mindegyik jó. A valódi bizalmasságot a SaveAsEncrypted adja egy olyan jelszóval, amelyet a célközönségen kívül senki sem ismer, ami a AES-védett XLSX kimenet című cikkben leírt AES-256 kimenetet állítja elő. Az írásfoglalás akkor kerül rá tetejére, amikor a munkafüzet egy megosztott szerkesztési artefaktum, és azt szeretnéd, hogy az Excel kérdezzen rá, mielőtt valaki felülírja
Mit ellenőrizz egy nem megbízható befogadási útvonalon
Az integritásellenőrzés a titkosított hasznos terhelést védi, nem a körülötte lévő konténert. Egy XLSX fájl egy ZIP archívum, és az archívum szerkezete elemzésre kerül, mielőtt bármilyen titkosítási logika lefutna, így a konténer-szintű validálás a lánc elején helyezkedik el; a konkrét hibamódokat a ZIP end-of-central-directory validálás nem megbízható XLSX-eknél című cikk tárgyalja. Ezután kezeld az integritási hibát és a rossz jelszót ugyanolyan üzemeltetési eseményként, mert a te oldaladról szándékosan megkülönböztethetetlenek, és mindkettő azt jelenti, hogy a fájlban nem lehet megbízni abban, hogy az, aminek a küldője gondolja
Naplózd, mely fájlok tartalmaztak egyáltalán dataIntegrity blokkot. Néhány ezer dokumentum felett ez a statisztika hasznos dolgot mond a küldőid eszközkészletéről, és egy fájlonkénti ellenőrzésből egy flottaszintű megfigyelést csinál, amelyre cselekedni tudsz
A HotXLS Excel telepítése nélkül olvas és ír XLS, XLSX és ODS fájlokat Delphiből és C++Builderből, az [MS-OFFCRYPTO] Standard és Agile titkosítási útvonalait Pascalban implementálva. A titkosítási, védelmi és munkafüzet API-k a HotXLS Delphi táblázatkezelő komponens oldalán vannak dokumentálva