HotXLS, Agile şifreli XLSX paketlerine uyumlu bir dataIntegrity bloğu yazar ve açılışta bunu doğrular. HMAC-SHA-512, sekiz baytlık StreamSize önekiyle birlikte tam EncryptedPackage akışını kapsar ve herhangi bir segment çözülmeden önce şifreli metin üzerinde denetlenir; bu yüzden yanlış bir parola ya da değiştirilmiş bir paket, karmaşaya dönüştürülmek yerine tespit edilir
Bütünlük olmadan şifreleme yarım bir yanıttır ve Office dosya biçimleri bu boşluğu gözden kaçırmayı kolaylaştırır, çünkü şifreleme dışarıdan bakınca son derece kapsamlı görünür. Her katmanın ne vaat ettiğini anlamak, bir güvenlik incelemesini kısa tutan şeydir
Şifrelenmiş bir çalışma kitabı gerçekte ne vaat eder?
[MS-OFFCRYPTO]'da tanımlanan Agile şifreleme, yinelenmiş bir SHA-512 parola özetinden türetilen bir anahtarla CBC modunda AES üzerinden gizlilik sağlar. Gizlilik, bu yapının tüm vaadidir. CBC kimliği doğrulanan bir mod değildir: çözdüğünüz şifreli metnin yazılan şifreli metin olup olmadığı konusunda hiçbir şey söylemez
Pratik sonuç somuttur. Şifreli bir pakette bitleri çevirin, CBC bunları farklı düz metne memnuniyetle çözer. Genellikle bir yerlerde bir ZIP ayrıştırma hatası alırsınız, çünkü bozulmuş bir deflate akışı nadiren hayatta kalır, ama o cümledeki "genellikle" çok iş yapıyor ve bir dosyanın değiştirildiğini öğrenmek için akış aşağısındaki bir ayrıştırıcı hatası korkunç bir yerdir. dataIntegrity öğesi, çözmeden önce, tam baytlar üzerinde bir MAC ile bu soruyu doğrudan yanıtlamak için vardır
Kontrol nasıl çalışır ve hangi sırayla?
İlginç kısım sıradır. HotXLS, ara anahtarı paroladan türetir, blok anahtarından türetilmiş IV'ler kullanarak dataIntegrity özniteliklerinden şifreli HMAC anahtarını ve HMAC değerini çözer, saklandığı haliyle şifreli paket üzerinde HMAC-SHA-512'yi hesaplar ve karşılaştırır. Segment çözme yalnızca bundan sonra başlar
MAC'i düz metin yerine şifreli metin üzerinde kontrol etmek, standart önce-şifrele-sonra-MAC disiplinidir ve kontrolü anlamlı kılan da budur: kurcalanmış bir paket, hiçbir saldırgan kontrollü bayt çözme ve şişirme yolundan geçirilmeden reddedilir. Açma yolundaki her iki karşılaştırma da, parola doğrulayıcı özeti ve HMAC değeri, ilk uyuşmayan baytta erken dönmek yerine tüm özet boyunca XOR ve OR ile farkları biriktirir; bu yüzden hiçbiri zamanlama üzerinden bir bayt konumu sızdırmaz
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// Düz, Standard şifreli ve Agile şifreli dosyalar için çalışır
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// Yanlış parola ya da dataIntegrity HMAC'i uyuşmayan bir paket
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;Yazma tarafında kodunuzda hiçbir şey değişmez. SaveAsEncrypted bloğu otomatik olarak yayar ve tuzlar, doğrulayıcı girdisi ile HMAC anahtarı CryptGenRandom'dan gelir. O çağrı başarısız olursa HotXLS daha zayıf bir kaynağa geri düşmek yerine hata verir. Kapalı-yönde başarısız olan bir CSPRNG paranoyaklık değildir; öngörülebilir bir rastgele kaynağa sessiz bir düşüş, şifreli görünen, her işlevsel testi geçen ve değersiz dosyalar üretir
Blok olmayan dosyalar neden hâlâ açılıyor?
Çünkü dolaşımdaki pek çok Agile şifreli çalışma kitabı, dataIntegrity'yi tamamen atlayan üreticiler tarafından yazılmıştır ve bunları reddetmek koruyacağından çok daha fazla meşru işi bozardı. HotXLS, bütünlüğü yalnızca her iki öznitelik, şifreli HMAC anahtarı ve şifreli HMAC değeri, mevcut ve iyi biçimlendirilmişse mevcut sayar. Aksi halde doğrulama atlanır ve dosya öncekiyle aynı şekilde açılır
Bu, kendi tehdit modelinizde açıkça adlandırmanız gereken güvenlik sonuçlu bir uyumluluk kararıdır: bloğun yokluğu, bir saldırganın onu kaldırmasından ayırt edilemez, çünkü öznitelikler taşıyacakları MAC'in dışındadır. Boru hattının her iki ucunu da kontrol ediyorsanız, eksik bir bloğu uygulama düzeyinde bir politika başarısızlığı olarak ele alın. Dünyadan dosya kabul ediyorsanız, kontrolü olduğu şey olarak ele alın: mevcut olduğunda değerli bir sinyal, olmadığında ise hiçbir sinyal
Değiştirmek için parola bir sözleşmedir, bir sınır değil
Klasik XLS çalışma kitapları, şifrelemeyle rutin olarak karıştırılan ayrı bir mekanizmayı destekler: yazma rezervasyonu, Excel'in "değiştirmek için parola" istemi. HotXLS bunu SetModifyPassword üzerinden açar; bu, parolayı, salt-okunur önerme bayrağını ve rezervasyonu yapan kullanıcı adını alır ve durumu IsWriteReserved üzerinden bildirir. Boş bir parola geçmek rezervasyonu temizler
Yazılan şey, salt-okunur önerme bayrağını, eski bir 16 bit parola özetini ve kullanıcı adını bir BIFF8 Unicode dizesi olarak taşıyan bir WRITEPROT ve FILESHARING kayıt çiftidir. O 16 bit özet, bir kriptografik özet değil bir sağlama toplamıdır ve belge içeriği hiç şifrelenmez. Dosyayı başka herhangi bir araçla açan herkes her şeyi okur. Özelliğin gerçek işi koordinasyondur: bir sonraki kişiye, birinin bu dosyayı kendi düzenleme sorumluluğunda gördüğünü söyler; XLSX sayfa koruması ve izin verme seçeneklerinde ele alınan sayfa düzeyi kontrollerle aynı kategoride
var
Book: IXLSWorkbook; // arayüz sayaçlı: Free çağırmayın
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// Salt-okunur öner, raporlama servisi tarafından rezerve edildi
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;Her katmanı iyi olduğu şey için kullanın. Gerçek gizlilik, hedef kitle dışında kimsenin sahip olmadığı bir parolayla SaveAsEncrypted'den gelir; bu, AES korumalı XLSX çıktısında anlatılan AES-256 çıktısını üretir. Yazma rezervasyonu ise çalışma kitabı paylaşılan bir düzenleme eseri olduğunda ve birisi üzerine kaydetmeden önce Excel'in sormasını istediğinizde üste eklenir
Güvenilmeyen bir alım yolunda ne kontrol edilmeli
Bütünlük doğrulaması şifreli yükü korur, çevresindeki kapsayıcıyı değil. Bir XLSX dosyası bir ZIP arşividir ve arşiv yapısı herhangi bir şifreleme mantığı çalışmadan önce ayrıştırılır; bu yüzden kapsayıcı düzeyi doğrulama zincirde önce gelir. Belirli başarısızlık modları güvenilmeyen XLSX için ZIP EOCD doğrulamasında ele alınmıştır. Bundan sonra, bir bütünlük hatası ile yanlış bir parolayı aynı operasyonel olay olarak ele alın, çünkü sizin tarafınızdan bunlar tasarım gereği ayırt edilemez ve her ikisi de dosyanın göndericinin düşündüğü şey olduğuna güvenilemeyeceği anlamına gelir
Hangi dosyaların bir dataIntegrity bloğu taşıdığını kaydedin. Birkaç bin belge üzerinde bu istatistik, gönderenlerinizin araçları hakkında yararlı bir şey söyler ve dosya başına bir kontrolü, üzerinde hareket edebileceğiniz filo düzeyinde bir gözleme çevirir
HotXLS, Excel kurulumu olmadan Delphi ve C++Builder'dan XLS, XLSX ve ODS okur ve yazar; [MS-OFFCRYPTO] Standard ve Agile şifreleme yollarını Pascal içinde uygular. Şifreleme, koruma ve çalışma kitabı API'leri HotXLS Delphi elektronik tablo bileşeni sayfasında belgelenmiştir