HotXLS menulis blok dataIntegrity yang sesuai spesifikasi ke dalam paket XLSX terenkripsi Agile dan memverifikasinya saat dibuka. HMAC-SHA-512 mencakup seluruh stream EncryptedPackage, termasuk prefix StreamSize delapan byte-nya, dan diperiksa atas ciphertext sebelum satu pun segmen didekripsi, sehingga password yang salah atau paket yang dimodifikasi terdeteksi, bukan malah didekripsi menjadi data sampah
Enkripsi tanpa integritas adalah jawaban setengah jalan, dan format file Office membuat celah itu mudah terlewat karena enkripsinya tampak begitu menyeluruh dari luar. Memahami apa yang dijanjikan setiap lapisan adalah yang membuat security review tetap singkat
Apa sebenarnya yang dijanjikan workbook terenkripsi?
Agile encryption, yang didefinisikan di [MS-OFFCRYPTO], memberi Anda confidentiality lewat AES mode CBC dengan key yang diturunkan dari hash password SHA-512 berulang. Confidentiality adalah keseluruhan janji dari konstruksi itu. CBC bukan mode terautentikasi: ia tidak mengatakan apa pun soal apakah ciphertext yang sedang Anda dekripsi adalah ciphertext yang ditulis
Konsekuensi praktisnya spesifik. Balikkan sejumlah bit di paket terenkripsi dan CBC akan dengan senang hati mendekripsinya menjadi plaintext yang berbeda. Anda biasanya akan mendapat error parsing ZIP di suatu tempat downstream, karena deflate stream yang rusak jarang bertahan, tapi kata "biasanya" itu menanggung banyak beban dalam kalimat itu, dan error parser downstream adalah tempat yang buruk untuk mengetahui bahwa sebuah file telah dimodifikasi. Elemen dataIntegrity ada untuk menjawab pertanyaan itu secara langsung, sebelum dekripsi, dengan MAC atas byte yang persis
Bagaimana pemeriksaan berjalan, dan dalam urutan apa
Urutannya adalah bagian yang menarik. HotXLS menurunkan intermediate key dari password, mendekripsi HMAC key dan HMAC value terenkripsi dari atribut dataIntegrity menggunakan IV yang diturunkan dari block-key, menghitung HMAC-SHA-512 atas encrypted package sebagaimana tersimpan, lalu membandingkannya. Baru setelah itu dekripsi segmen dimulai
Memeriksa MAC atas ciphertext, bukan plaintext, adalah disiplin standar encrypt-then-MAC, dan itulah yang membuat pemeriksaan ini bermakna: paket yang dimanipulasi ditolak tanpa satu byte pun yang dikendalikan penyerang sempat dijalankan melalui jalur dekripsi dan inflation. Kedua perbandingan di jalur pembukaan, hash password verifier dan nilai HMAC, mengakumulasi perbedaan dengan XOR dan OR di seluruh digest alih-alih kembali lebih awal pada byte pertama yang tidak cocok, sehingga tidak ada satu pun yang membocorkan posisi byte lewat timing
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Berfungsi untuk file plain, terenkripsi Standard, dan terenkripsi Agile
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Password salah, atau paket yang HMAC dataIntegrity-nya tidak cocok
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Di sisi penulisan tidak ada yang berubah dalam kode Anda. SaveAsEncrypted menghasilkan blok itu secara otomatis, dan salt, verifier input, serta HMAC key berasal dari CryptGenRandom. Jika pemanggilan itu gagal, HotXLS akan raise, bukan jatuh kembali ke sumber yang lebih lemah. CSPRNG yang fail-closed bukan bentuk paranoia; downgrade diam-diam ke sumber acak yang bisa diprediksi menghasilkan file yang terlihat terenkripsi, lolos setiap functional test, dan sama sekali tidak berharga
Mengapa file tanpa blok itu tetap bisa dibuka?
Karena sangat banyak workbook terenkripsi Agile yang beredar ditulis oleh producer yang sama sekali menghilangkan dataIntegrity, dan menolaknya akan merusak jauh lebih banyak pekerjaan legitim daripada yang dilindunginya. HotXLS menganggap integrity ada hanya jika kedua atribut, HMAC key terenkripsi dan HMAC value terenkripsi, keduanya ada dan berbentuk baik. Selain itu verifikasi dilewati dan file dibuka seperti biasa
Ini adalah keputusan kompatibilitas dengan konsekuensi keamanan yang harus Anda nyatakan secara eksplisit dalam threat model Anda sendiri: ketiadaan blok itu tidak bisa dibedakan dari penyerang yang menghapusnya, karena atribut-atribut itu berada di luar MAC yang seharusnya mereka bawa. Jika Anda mengendalikan kedua ujung pipeline, perlakukan blok yang hilang sebagai kegagalan kebijakan di level aplikasi. Jika Anda menerima file dari luar, perlakukan pemeriksaan ini sebagaimana adanya, sinyal yang berharga saat hadir dan sama sekali bukan sinyal saat tidak ada
Password to modify adalah konvensi, bukan batas keamanan
Workbook XLS klasik mendukung mekanisme terpisah yang rutin disalahartikan sebagai enkripsi: write reservation, prompt "password to modify" milik Excel. HotXLS mengeksposnya lewat SetModifyPassword, yang menerima password, flag recommend-read-only, dan nama user yang mereservasi, dan melaporkan statusnya lewat IsWriteReserved. Memberikan password kosong akan menghapus reservasi tersebut
Yang ditulis adalah sepasang record WRITEPROT dan FILESHARING yang membawa flag recommend-read-only, hash password 16-bit lawas, dan nama user sebagai string Unicode BIFF8. Hash 16-bit itu adalah checksum, bukan digest kriptografis, dan konten dokumen sama sekali tidak dienkripsi. Siapa pun yang membuka file itu dengan tool lain akan bisa membaca semuanya. Tugas sebenarnya dari fitur ini adalah koordinasi: ia memberi tahu orang berikutnya bahwa seseorang menganggap file ini miliknya untuk diedit, dalam kategori yang sama dengan kontrol level sheet yang dibahas di XLSX sheet protection dan allow options
var
Book: IXLSWorkbook; // interface-counted: do not Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Recommend read-only, direservasi oleh reporting service
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Gunakan kedua lapisan itu sesuai kelebihan masing-masing. Confidentiality yang sesungguhnya datang dari SaveAsEncrypted dengan password yang tidak dipegang siapa pun di luar audiens yang dituju, yang menghasilkan output AES-256 seperti yang dijelaskan di output XLSX terlindungi AES. Write reservation ditambahkan di atasnya saat workbook adalah artefak editing bersama dan Anda ingin Excel bertanya sebelum seseorang menimpanya
Apa yang perlu diperiksa pada intake path yang tidak tepercaya
Verifikasi integritas melindungi payload terenkripsi, bukan container di sekitarnya. File XLSX adalah arsip ZIP, dan struktur arsipnya diparsing sebelum logika enkripsi apa pun berjalan, sehingga validasi level container harus berada paling awal dalam rantai; mode kegagalan spesifiknya dibahas di validasi ZIP end-of-central-directory untuk XLSX tidak tepercaya. Setelah itu, perlakukan kegagalan integritas dan password yang salah sebagai peristiwa operasional yang sama, karena dari sisi Anda keduanya memang sengaja dibuat tidak bisa dibedakan, dan keduanya berarti file itu tidak bisa dipercaya sebagai apa yang dikira pengirimnya
Catat file mana saja yang sama sekali membawa blok dataIntegrity. Dari beberapa ribu dokumen, statistik itu memberi tahu Anda sesuatu yang berguna soal tooling para pengirim Anda, dan mengubah pemeriksaan per-file menjadi observasi level fleet yang bisa Anda tindaklanjuti
HotXLS membaca dan menulis XLS, XLSX, dan ODS dari Delphi dan C++Builder tanpa instalasi Excel, mengimplementasikan jalur enkripsi Standard dan Agile [MS-OFFCRYPTO] dalam Pascal. API enkripsi, proteksi, dan workbook didokumentasikan di halaman komponen spreadsheet Delphi HotXLS