Aptikite pakeistus XLSX: HotXLS Agile dataIntegrity HMAC

HotXLS įrašo atitinkantį dataIntegrity bloką į Agile šifruotus XLSX paketus ir patikrina jį atidarant. HMAC-SHA-512 apima visą EncryptedPackage srautą, įskaitant jo aštuonių baitų StreamSize priešdėlį, ir tikrinamas per šifruotą tekstą prieš dekoduojant bet kurį segmentą, todėl neteisingas slaptažodis ar pakeistas paketas aptinkamas, o ne dekoduojamas į šlamštą

Šifravimas be vientisumo yra pusinis atsakymas, o Office failų formatai leidžia lengvai to nepastebėti, nes šifravimas iš išorės atrodo toks kruopštus. Supratimas, ką garantuoja kiekvienas sluoksnis, ir yra tai, kas saugumo peržiūrą palieka trumpą

Ką iš tikrųjų garantuoja šifruota knyga?

Agile šifravimas, apibrėžtas [MS-OFFCRYPTO] specifikacijoje, suteikia konfidencialumą per AES CBC režimu su raktu, gautu iš iteruoto SHA-512 slaptažodžio maišos. Konfidencialumas yra visas šios konstrukcijos pažadas. CBC nėra autentifikuotas režimas: jis nieko nesako apie tai, ar šifruotas tekstas, kurį dekoduojate, yra tas pats, kuris buvo įrašytas

Praktinė pasekmė konkreti. Apverskite bitus šifruotame pakete, ir CBC noriai juos dekoduos į skirtingą atvirą tekstą. Paprastai gausite ZIP analizavimo klaidą kažkur toliau, nes sugadintas deflate srautas retai išgyvena, tačiau žodis „paprastai" čia daug ką slepia, o klaida žemesniame analizatoriuje yra siaubinga vieta sužinoti, kad failas buvo pakeistas. dataIntegrity elementas egzistuoja tam, kad atsakytų į šį klausimą tiesiogiai, prieš dekodavimą, su MAC per tikslius baitus

Kaip vyksta patikra ir kokia tvarka

Tvarka yra įdomiausia dalis. HotXLS gauna tarpinį raktą iš slaptažodžio, dekoduoja šifruotą HMAC raktą ir HMAC reikšmę iš dataIntegrity atributų, naudodamas iš blokų raktų gautus IV, apskaičiuoja HMAC-SHA-512 per šifruotą paketą tokį, koks jis saugomas, ir palygina. Tik tada prasideda segmentų dekodavimas

MAC tikrinimas per šifruotą tekstą, o ne per atvirą tekstą, yra standartinė šifruoti-tada-MAC disciplina, ir būtent tai daro patikrą prasmingą: pakeistas paketas atmetamas be jokių užpuoliko kontroliuojamų baitų, praėjusių per dekodavimo ir išplėtimo kelią. Abu palyginimai atidarymo kelyje – slaptažodžio tikrintuvo maiša ir HMAC reikšmė – kaupia skirtumus su XOR ir OR per visą santrauką, o ne grįžta anksti prie pirmo nesutampančio baito, todėl nė vienas neišduoda baito pozicijos per laiką

var
  Book: TXLSXWorkbook;
begin
  Book := TXLSXWorkbook.Create;
  try
    // Veikia paprastiems, Standard šifruotiems ir Agile šifruotiems failams
    if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
      ProcessWorkbook(Book)
    else
      // Neteisingas slaptažodis, arba paketas, kurio dataIntegrity HMAC nesutapo
      Quarantine('incoming.xlsx');
  except
    on E: Exception do
      Quarantine('incoming.xlsx: ' + E.Message);
  end;
  Book.Free;
end;

Rašymo pusėje jūsų kode niekas nesikeičia. SaveAsEncrypted automatiškai išveda bloką, o druskos, tikrintuvo įvestis ir HMAC raktas gaunami iš CryptGenRandom. Jei tas iškvietimas nepavyksta, HotXLS sukelia išimtį, o ne grįžta prie silpnesnio šaltinio. Griežtai uždaras CSPRNG nėra paranoja; tylus nusileidimas iki nuspėjamo atsitiktinio šaltinio sukuria failus, kurie atrodo šifruoti, praeina kiekvieną funkcinį testą ir yra beverčiai

Kodėl failai be šio bloko vis dar atsidaro?

Todėl, kad labai daug apyvartoje esančių Agile šifruotų darbo knygų buvo parašyta generatorių, kurie visiškai praleidžia dataIntegrity, o jų atmetimas sugadintų daug daugiau teisėto darbo, nei apsaugotų. HotXLS laiko vientisumą esamu tik tada, kai abu atributai – šifruotas HMAC raktas ir šifruota HMAC reikšmė – yra ir taisyklingai suformuoti. Kitu atveju tikrinimas praleidžiamas, ir failas atsidaro kaip anksčiau

Tai suderinamumo sprendimas su saugumo pasekme, kurią turėtumėte aiškiai įvardyti savo pačių grėsmių modelyje: bloko nebuvimo negalima atskirti nuo užpuoliko, kuris jį pašalino, nes atributai yra už MAC, kurį jie neštų. Jei kontroliuojate abu konvejerio galus, traktuokite trūkstamą bloką kaip politikos nesėkmę aplikacijos lygmenyje. Jei priimate failus iš pasaulio, traktuokite patikrą kaip tai, kas ji yra – vertingas signalas, kai jis yra, ir jokio signalo, kai jo nėra

Slaptažodis keitimui – tai susitarimas, ne riba

Klasikinės XLS darbo knygos palaiko atskirą mechanizmą, kuris nuolat painiojamas su šifravimu: rašymo rezervavimas, Excel raginimas „slaptažodis keitimui". HotXLS jį atskleidžia per SetModifyPassword, kuris priima slaptažodį, rekomenduojamos tik skaitymo vėliavėlę ir rezervuojantį naudotojo vardą, o būseną praneša per IsWriteReserved. Perduodant tuščią slaptažodį, rezervavimas panaikinamas

Kas įrašoma – tai WRITEPROT ir FILESHARING įrašų pora, nešanti rekomenduojamos tik skaitymo vėliavėlę, seną 16 bitų slaptažodžio maišą ir naudotojo vardą kaip BIFF8 Unicode eilutę. Tas 16 bitų maiša yra kontrolinė suma, ne kriptografinė santrauka, o dokumento turinys iš viso nešifruojamas. Bet kas, atidaręs failą bet kokiu kitu įrankiu, perskaito viską. Realus šios funkcijos darbas yra koordinavimas: ji praneša kitam asmeniui, kad kažkas laiko šį failą savu redaguoti, toje pačioje kategorijoje kaip lakšto lygmens valdikliai, aprašyti straipsnyje apie XLSX lakšto apsaugą ir leidimo parinktis

var
  Book: IXLSWorkbook;   // valdomas per sąsają: nereikia Free
begin
  Book := TXLSWorkbook.Create;
  if Book.Open('shared-model.xls') = 1 then
  begin
    // Rekomenduojama tik skaityti, rezervuota ataskaitų tarnybos
    Book.SetModifyPassword('edit-me', True, 'Reporting Service');

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

Naudokite abu sluoksnius tam, kam kiekvienas jų geras. Tikras konfidencialumas gaunamas iš SaveAsEncrypted su slaptažodžiu, kurio niekas už auditorijos ribų nežino, o tai sukuria AES-256 išvestį, aprašytą straipsnyje apie AES apsaugotą XLSX išvestį. Rašymo rezervavimas pridedamas, kai darbo knyga yra bendrai redaguojamas artefaktas ir norite, kad Excel paklaustų, prieš kam nors išsaugant per jį

Ką tikrinti nepatikimame priėmimo kelyje

Vientisumo patikra saugo šifruotą turinį, ne konteinerį aplink jį. XLSX failas yra ZIP archyvas, o archyvo struktūra analizuojama prieš prasidedant bet kokiai šifravimo logikai, todėl konteinerio lygmens validacija turi būti pirmoje grandinės vietoje; konkretūs nesėkmės režimai aprašyti straipsnyje apie ZIP centrinio katalogo pabaigos validaciją nepatikimiems XLSX failams. Po to traktuokite vientisumo nesėkmę ir neteisingą slaptažodį kaip tą patį eksploatacinį įvykį, nes iš jūsų pusės jie pagal dizainą neatskiriami, o abu reiškia, kad failu negalima pasitikėti kaip tuo, kuo siuntėjas galvoja jį esant

Registruokite, kurie failai apskritai turėjo dataIntegrity bloką. Per kelis tūkstančius dokumentų ta statistika pasako kažką naudingo apie jūsų siuntėjų įrankius, ir paverčia patikrą apie vieną failą stebėjimu visos siuntėjų bazės lygmeniu, kuriuo galite remtis

HotXLS skaito ir rašo XLS, XLSX ir ODS iš Delphi ir C++Builder be Excel diegimo, įgyvendindamas [MS-OFFCRYPTO] Standard ir Agile šifravimo kelius Pascal kalba. Šifravimo, apsaugos ir darbo knygos API dokumentuoti HotXLS Delphi skaičiuoklių komponento puslapyje