Havaitse peukaloitu XLSX: HotXLS Agile dataIntegrity HMAC

HotXLS kirjoittaa standardinmukaisen dataIntegrity-lohkon Agile-salattuihin XLSX-paketteihin ja varmentaa sen avattaessa. HMAC-SHA-512 kattaa koko EncryptedPackage-virran, mukaan lukien sen kahdeksan tavun StreamSize-etuliitteen, ja se tarkistetaan salatusta tekstistä ennen kuin yhtäkään segmenttiä puretaan, joten väärä salasana tai muokattu paketti havaitaan sen sijaan, että se purettaisiin roskaksi

Salaus ilman eheyttä on puolikas vastaus, ja Office-tiedostomuodot tekevät tästä aukosta helposti sivuutettavan, koska salaus näyttää ulkopuolelta niin perusteelliselta. Sen ymmärtäminen, mitä kukin kerros lupaa, on se, mikä pitää turvallisuuskatselmuksen lyhyenä

Mitä salattu työkirja todella lupaa?

Agile-salaus, joka on määritelty [MS-OFFCRYPTO]-spesifikaatiossa, antaa luottamuksellisuuden AES:n CBC-tilan avulla avaimella, joka on johdettu iteroidusta SHA-512-salasanatiivisteestä. Luottamuksellisuus on tämän rakenteen koko lupaus. CBC ei ole todennettu tila: se ei kerro mitään siitä, onko purettava salateksti se salateksti, joka kirjoitettiin

Käytännön seuraus on täsmällinen. Käännä bittejä salatussa paketissa, ja CBC purkaa ne mielellään toiseksi selkotekstiksi. Yleensä saat ZIP-jäsennysvirheen jossain myöhemmässä vaiheessa, koska vioittunut deflate-virta harvoin selviää, mutta sana "yleensä" tekee paljon työtä tuossa lauseessa, ja myöhemmän vaiheen jäsennysvirhe on kauhea paikka oppia, että tiedostoa on muokattu. dataIntegrity-elementti on olemassa vastatakseen kysymykseen suoraan, ennen purkua, MAC-arvolla täsmällisten tavujen yli

Miten tarkistus suoritetaan, ja missä järjestyksessä

Järjestys on kiinnostava osa. HotXLS johtaa väliavaimen salasanasta, purkaa salatun HMAC-avaimen ja HMAC-arvon dataIntegrity-attribuuteista lohkoavaimesta johdettujen IV-arvojen avulla, laskee HMAC-SHA-512-arvon tallennetusta salatusta paketista sellaisenaan ja vertailee. Vasta sitten segmenttien purku alkaa

MAC-arvon tarkistaminen salatekstistä eikä selkotekstistä on tavanomainen encrypt-then-MAC-käytäntö, ja se on se, mikä tekee tarkistuksesta merkityksellisen: peukaloitu paketti hylätään ilman, että yhtäkään hyökkääjän hallitsemaa tavua on ajettu purku- ja purkupolun läpi. Molemmat vertailut avauspolussa, salasanan todentajatiiviste ja HMAC-arvo, keräävät erot XOR- ja OR-operaatioilla koko tiivisteen yli sen sijaan, että palattaisiin heti ensimmäisessä täsmäämättömässä tavussa, joten kumpikaan ei vuoda tavun sijaintia ajoituksen kautta

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    // Toimii tavallisille, Standard-salatuille ja Agile-salatuille tiedostoille
    if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
      ProcessWorkbook(Book)
    else
      // Väärä salasana, tai paketti, jonka dataIntegrity-HMAC ei täsmännyt
      Quarantine('incoming.xlsx');
  except
    on E: Exception do
      Quarantine('incoming.xlsx: ' + E.Message);
  end;
  Book.Free;
end;

Kirjoituspuolella koodissasi ei muutu mikään. SaveAsEncrypted tuottaa lohkon automaattisesti, ja suolat, todentajan syöte ja HMAC-avain tulevat CryptGenRandom-kutsusta. Jos tuo kutsu epäonnistuu, HotXLS nostaa poikkeuksen sen sijaan, että se palaisi heikompaan lähteeseen. Fail-closed-CSPRNG ei ole vainoharhaisuutta; hiljainen alentuminen ennustettavaan satunnaislähteeseen tuottaa tiedostoja, jotka näyttävät salatuilta, läpäisevät jokaisen toiminnallisen testin ja ovat arvottomia

Miksi ilman lohkoa olevat tiedostot silti avautuvat?

Koska hyvin moni liikkeellä oleva Agile-salattu työkirja on kirjoitettu tuottajilla, jotka jättävät dataIntegrity-elementin kokonaan pois, ja niiden hylkääminen rikkoisi paljon enemmän oikeutettua työtä kuin se suojaisi. HotXLS pitää eheyttä läsnä olevana vain, kun molemmat attribuutit, salattu HMAC-avain ja salattu HMAC-arvo, ovat olemassa ja hyvin muodostettuja. Muuten varmennus ohitetaan ja tiedosto avautuu kuten ennenkin

Tämä on yhteensopivuuspäätös, jolla on turvallisuusseuraus, joka kannattaa nimetä eksplisiittisesti omassa uhkamallissasi: lohkon puuttumista ei voi erottaa siitä, että hyökkääjä on poistanut sen, koska attribuutit ovat sen MAC-arvon ulkopuolella, jonka ne kantaisivat. Jos hallitset putken molempia päitä, käsittele puuttuvaa lohkoa käytäntörikkomuksena sovellustasolla. Jos vastaanotat tiedostoja maailmalta, käsittele tarkistusta sellaisena kuin se on, arvokkaana signaalina kun se on läsnä ja ei signaalina lainkaan, kun se puuttuu

Salasana muokkaamiseen on käytäntö, ei raja

Klassiset XLS-työkirjat tukevat erillistä mekanismia, joka sekoitetaan rutiininomaisesti salaukseen: kirjoitusvaraus, Excelin "salasana muokkaamiseen" -kehote. HotXLS paljastaa sen SetModifyPassword-metodin kautta, joka ottaa salasanan, suositellaan-vain-luku-lipun ja varauksen tehneen käyttäjän nimen, ja raportoi tilan IsWriteReserved-ominaisuuden kautta. Tyhjän salasanan välittäminen poistaa varauksen

Kirjoitettavaksi tulee WRITEPROT- ja FILESHARING-tietuepari, joka kantaa suositellaan-vain-luku-lipun, vanhentuneen 16-bittisen salasanatiivisteen ja käyttäjän nimen BIFF8 Unicode -merkkijonona. Tuo 16-bittinen tiiviste on tarkistussumma, ei kryptografinen tiiviste, eikä asiakirjan sisältöä salata lainkaan. Kuka tahansa, joka avaa tiedoston millä tahansa muulla työkalulla, lukee kaiken. Ominaisuuden todellinen tehtävä on koordinointi: se kertoo seuraavalle henkilölle, että joku pitää tätä tiedostoa omanaan muokattavaksi, samassa kategoriassa kuin taulukkotason hallinnat, jotka on käsitelty artikkelissa XLSX-taulukkosuojaus ja sallimisasetukset

var
  Book: IXLSWorkbook;   // interface-laskettu: älä kutsu Free-metodia
begin
  Book := TXLSWorkbook.Create;
  if Book.Open('shared-model.xls') = 1 then
  begin
    // Suositellaan vain luku -tilaa, varannut raportointipalvelu
    Book.SetModifyPassword('edit-me', True, 'Reporting Service');

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

Käytä molempia kerroksia siihen, missä ne kumpikin ovat hyviä. Todellinen luottamuksellisuus tulee SaveAsEncrypted-metodista salasanalla, jota kukaan yleisön ulkopuolinen ei hallitse, mikä tuottaa AES-256-tulosteen, joka on kuvattu artikkelissa AES-suojattu XLSX-tuloste. Kirjoitusvaraus tulee päälle, kun työkirja on jaettu muokkausartefakti ja haluat Excelin kysyvän, ennen kuin joku tallentaa sen päälle

Mitä tarkistaa epäluotettavalla vastaanottopolulla

Eheyden varmennus suojaa salatun hyötykuorman, ei sitä ympäröivää säiliötä. XLSX-tiedosto on ZIP-arkisto, ja arkiston rakenne jäsennetään ennen kuin mikään salauslogiikka ajetaan, joten säiliötason validointi kuuluu ketjussa ensimmäiseksi; täsmälliset virhetilat käsitellään artikkelissa ZIP-hakemiston lopun validointi epäluotettaville XLSX-tiedostoille. Sen jälkeen käsittele eheysvirhe ja väärä salasana samana operatiivisena tapahtumana, koska sinun näkökulmastasi ne ovat suunnitelmallisesti erottamattomia, ja molemmat tarkoittavat, ettei tiedostoon voi luottaa sellaisena kuin lähettäjä olettaa

Kirjaa lokiin, missä tiedostoissa ylipäätään oli dataIntegrity-lohko. Muutaman tuhannen asiakirjan yli tämä tilasto kertoo jotain hyödyllistä lähettäjiesi työkaluista, ja se muuttaa tiedostokohtaisen tarkistuksen kalustotason havainnoksi, johon voit reagoida

HotXLS lukee ja kirjoittaa XLS-, XLSX- ja ODS-tiedostoja Delphistä ja C++Builderista ilman Excel-asennusta, toteuttaen [MS-OFFCRYPTO]-spesifikaation Standard- ja Agile-salauspolut Pascalissa. Salaus-, suojaus- ja työkirja-API:t on dokumentoitu sivulla HotXLS Delphi spreadsheet component page