HotXLS เขียนบล็อก dataIntegrity ที่เป็นไปตามข้อกำหนดลงในแพ็กเกจ XLSX ที่เข้ารหัสแบบ Agile และตรวจสอบมันตอนเปิดไฟล์ HMAC-SHA-512 ครอบคลุมสตรีม EncryptedPackage ทั้งหมด รวมถึงส่วนนำหน้า StreamSize ขนาดแปดไบต์ด้วย และถูกตรวจสอบบนไซเฟอร์เท็กซ์ก่อนที่ส่วนใดจะถูกถอดรหัส ดังนั้นรหัสผ่านที่ผิดหรือแพ็กเกจที่ถูกแก้ไขจะถูกตรวจพบ แทนที่จะถูกถอดรหัสออกมาเป็นข้อมูลขยะ
การเข้ารหัสโดยไม่มีการตรวจสอบความสมบูรณ์คือคำตอบเพียงครึ่งเดียว และรูปแบบไฟล์ของ Office ทำให้ช่องว่างนี้ถูกมองข้ามได้ง่าย เพราะการเข้ารหัสดูรัดกุมมากจากภายนอก การเข้าใจว่าแต่ละชั้นให้คำมั่นอะไรบ้างคือสิ่งที่ทำให้การตรวจสอบความปลอดภัยกระชับ
เวิร์กบุ๊กที่เข้ารหัสให้คำมั่นอะไรจริง ๆ
การเข้ารหัสแบบ Agile ที่กำหนดไว้ใน [MS-OFFCRYPTO] ให้การรักษาความลับผ่าน AES โหมด CBC ด้วยคีย์ที่ได้จากแฮชรหัสผ่านแบบ SHA-512 ที่ทำซ้ำหลายรอบ การรักษาความลับคือคำมั่นทั้งหมดของโครงสร้างนี้ CBC ไม่ใช่โหมดที่มีการยืนยันตัวตน มันไม่ได้บอกอะไรเลยว่าไซเฟอร์เท็กซ์ที่คุณกำลังถอดรหัสคือไซเฟอร์เท็กซ์เดียวกับที่ถูกเขียนไว้จริงหรือไม่
ผลในทางปฏิบัติมีความเจาะจง หากพลิกบิตในแพ็กเกจที่เข้ารหัสไว้ CBC จะถอดรหัสมันออกมาเป็นข้อความธรรมดาที่ต่างไปอย่างไม่ลังเล คุณมักจะได้ข้อผิดพลาดการแยกวิเคราะห์ ZIP ที่ไหนสักแห่งในขั้นตอนถัดไป เพราะสตรีม deflate ที่เสียหายมักไม่รอด แต่คำว่า “มักจะ” นี้แบกรับความหมายไว้มากในประโยคนี้ และข้อผิดพลาดจากตัวแยกวิเคราะห์ในขั้นตอนถัดไปก็เป็นจุดที่แย่มากในการมารู้ว่าไฟล์ถูกแก้ไข องค์ประกอบ dataIntegrity มีอยู่เพื่อตอบคำถามนี้โดยตรง ก่อนการถอดรหัส ด้วย MAC ที่ครอบคลุมไบต์ที่แน่นอน
การตรวจสอบทำงานอย่างไร และตามลำดับใด
ลำดับการทำงานคือส่วนที่น่าสนใจ HotXLS จะได้คีย์ระดับกลางจากรหัสผ่านก่อน แล้วถอดรหัสคีย์ HMAC และค่า HMAC ที่เข้ารหัสไว้จากแอตทริบิวต์ dataIntegrity โดยใช้ IV ที่ได้จากคีย์บล็อก จากนั้นคำนวณ HMAC-SHA-512 บนแพ็กเกจที่เข้ารหัสไว้ตามที่จัดเก็บจริง แล้วเปรียบเทียบผล การถอดรหัสเซกเมนต์จะเริ่มขึ้นก็ต่อเมื่อผ่านขั้นตอนนี้แล้วเท่านั้น
การตรวจสอบ MAC บนไซเฟอร์เท็กซ์แทนที่จะเป็นข้อความธรรมดาคือหลักการมาตรฐานแบบ encrypt-then-MAC และนี่คือสิ่งที่ทำให้การตรวจสอบมีความหมาย: แพ็กเกจที่ถูกแก้ไขจะถูกปฏิเสธโดยไม่มีไบต์ที่ผู้โจมตีควบคุมได้ถูกส่งผ่านเส้นทางการถอดรหัสและขยายข้อมูลเลย การเปรียบเทียบทั้งสองแบบในเส้นทางเปิดไฟล์ คือแฮชตัวตรวจสอบรหัสผ่านและค่า HMAC จะสะสมความต่างด้วย XOR และ OR ตลอดทั้งไดเจสต์ แทนที่จะคืนค่าเร็วเมื่อพบไบต์ที่ไม่ตรงกันตัวแรก จึงไม่มีทางใดที่จะรั่วไหลตำแหน่งไบต์ผ่านการจับเวลาได้
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
// ใช้ได้กับไฟล์ธรรมดา ไฟล์ที่เข้ารหัสแบบ Standard และไฟล์ที่เข้ารหัสแบบ Agile
if Book.OpenEncrypted('incoming.xlsx', PasswordFromVault) = 1 then
ProcessWorkbook(Book)
else
// รหัสผ่านผิด หรือแพ็กเกจที่ HMAC ของ dataIntegrity ไม่ตรงกัน
Quarantine('incoming.xlsx');
except
on E: Exception do
Quarantine('incoming.xlsx: ' + E.Message);
end;
Book.Free;
end;ในฝั่งการเขียน ไม่มีอะไรในโค้ดของคุณต้องเปลี่ยนเลย SaveAsEncrypted จะสร้างบล็อกนี้ให้โดยอัตโนมัติ และซอลต์ ข้อมูลนำเข้าสำหรับตัวตรวจสอบ และคีย์ HMAC มาจาก CryptGenRandom ถ้าเรียกฟังก์ชันนั้นไม่สำเร็จ HotXLS จะเกิดข้อยกเว้นแทนที่จะถอยไปใช้แหล่งที่อ่อนแอกว่า CSPRNG แบบล้มเหลวปิดกั้นไม่ใช่ความหวาดระแวงเกินเหตุ การลดระดับอย่างเงียบ ๆ ไปสู่แหล่งสุ่มที่คาดเดาได้จะสร้างไฟล์ที่ดูเหมือนเข้ารหัสไว้ ผ่านการทดสอบเชิงฟังก์ชันทุกอย่าง แต่ไร้ค่าโดยสิ้นเชิง
เหตุใดไฟล์ที่ไม่มีบล็อกนี้จึงยังเปิดได้
เพราะเวิร์กบุ๊กที่เข้ารหัสแบบ Agile ที่หมุนเวียนอยู่จำนวนมากถูกเขียนโดยระบบที่ละเว้น dataIntegrity ไปเลย และการปฏิเสธไฟล์เหล่านั้นจะทำลายงานที่ถูกต้องมากกว่าที่จะปกป้องอะไร HotXLS จะถือว่ามีการตรวจสอบความสมบูรณ์อยู่ก็ต่อเมื่อแอตทริบิวต์ทั้งสอง คือคีย์ HMAC ที่เข้ารหัสและค่า HMAC ที่เข้ารหัส มีอยู่และมีรูปแบบถูกต้องเท่านั้น ไม่เช่นนั้นการตรวจสอบจะถูกข้ามไปและไฟล์จะเปิดได้เหมือนเดิม
นี่คือการตัดสินใจเพื่อความเข้ากันได้ที่มีผลกระทบด้านความปลอดภัยซึ่งคุณควรระบุไว้อย่างชัดเจนในโมเดลภัยคุกคามของคุณเอง: การไม่มีบล็อกนี้แยกแยะไม่ได้จากการที่ผู้โจมตีลบมันออกไป เพราะแอตทริบิวต์เหล่านั้นอยู่นอก MAC ที่มันจะพกพาอยู่แล้ว ถ้าคุณควบคุมทั้งสองปลายของไปป์ไลน์ ให้ถือว่าบล็อกที่หายไปเป็นความล้มเหลวเชิงนโยบายที่ระดับแอปพลิเคชัน ถ้าคุณกำลังรับไฟล์จากภายนอก ให้มองการตรวจสอบนี้ตามสภาพจริง คือเป็นสัญญาณที่มีค่าเมื่อมีอยู่ แต่ไม่ใช่สัญญาณใด ๆ เลยเมื่อไม่มี
รหัสผ่านสำหรับแก้ไขคือธรรมเนียมปฏิบัติ ไม่ใช่เขตแดนความปลอดภัย
เวิร์กบุ๊ก XLS แบบคลาสสิกรองรับกลไกแยกต่างหากที่มักถูกเข้าใจผิดว่าเป็นการเข้ารหัสอยู่เสมอ นั่นคือการจองสิทธิ์เขียน หรือพรอมต์ “password to modify” ของ Excel HotXLS เปิดให้ใช้งานผ่าน SetModifyPassword ซึ่งรับรหัสผ่าน แฟล็กแนะนำให้เปิดแบบอ่านอย่างเดียว และชื่อผู้ใช้ที่จอง แล้วรายงานสถานะผ่าน IsWriteReserved การส่งรหัสผ่านว่างจะล้างการจองนั้น
สิ่งที่ถูกเขียนคือคู่รีเคิร์ด WRITEPROT และ FILESHARING ที่พกแฟล็กแนะนำให้เปิดแบบอ่านอย่างเดียว แฮชรหัสผ่านแบบ 16 บิตรุ่นเก่า และชื่อผู้ใช้ในรูปสตริง Unicode แบบ BIFF8 แฮช 16 บิตนั้นเป็นเพียงเช็กซัม ไม่ใช่ไดเจสต์เชิงการเข้ารหัส และเนื้อหาเอกสารไม่ได้ถูกเข้ารหัสเลย ใครก็ตามที่เปิดไฟล์ด้วยเครื่องมืออื่นจะอ่านทุกอย่างได้ หน้าที่แท้จริงของฟีเจอร์นี้คือการประสานงาน มันบอกคนถัดไปว่ามีคนถือว่าไฟล์นี้เป็นของตนที่จะแก้ไข อยู่ในหมวดหมู่เดียวกับการควบคุมระดับชีตที่กล่าวถึงใน การป้องกันชีตและตัวเลือกอนุญาตของ XLSX
var
Book: IXLSWorkbook; // นับอ้างอิงแบบอินเทอร์เฟซ: ห้าม Free
begin
Book := TXLSWorkbook.Create;
if Book.Open('shared-model.xls') = 1 then
begin
// แนะนำให้เปิดแบบอ่านอย่างเดียว จองโดยบริการรายงาน
Book.SetModifyPassword('edit-me', True, 'Reporting Service');
if Book.IsWriteReserved then
Book.SaveAs('shared-model.xls', xlExcel97);
end;
end;ใช้ทั้งสองชั้นในจุดที่แต่ละชั้นทำได้ดี การรักษาความลับที่แท้จริงมาจาก SaveAsEncrypted พร้อมรหัสผ่านที่ไม่มีใครนอกกลุ่มเป้าหมายถืออยู่ ซึ่งได้ผลลัพธ์แบบ AES-256 ตามที่อธิบายไว้ใน ผลลัพธ์ XLSX ที่ป้องกันด้วย AES ส่วนการจองสิทธิ์เขียนจะเสริมเข้าไปเมื่อเวิร์กบุ๊กเป็นงานที่แก้ไขร่วมกัน และคุณต้องการให้ Excel ถามก่อนที่ใครจะบันทึกทับ
สิ่งที่ควรตรวจสอบบนเส้นทางรับไฟล์ที่ไม่น่าเชื่อถือ
การตรวจสอบความสมบูรณ์ปกป้องเพย์โหลดที่เข้ารหัสไว้ ไม่ใช่คอนเทนเนอร์ที่ห่อหุ้มมันอยู่ ไฟล์ XLSX คือไฟล์ ZIP archive และโครงสร้าง archive จะถูกแยกวิเคราะห์ก่อนที่ตรรกะการเข้ารหัสใด ๆ จะเริ่มทำงาน ดังนั้นการตรวจสอบระดับคอนเทนเนอร์ควรอยู่ต้นสุดของสาย รูปแบบความล้มเหลวที่เจาะจงอธิบายไว้ใน การตรวจสอบ ZIP end-of-central-directory สำหรับ XLSX ที่ไม่น่าเชื่อถือ หลังจากนั้น ให้ถือว่าความล้มเหลวด้านความสมบูรณ์และรหัสผ่านที่ผิดเป็นเหตุการณ์เชิงปฏิบัติการเดียวกัน เพราะในฝั่งของคุณทั้งสองแยกแยะไม่ออกโดยการออกแบบ และทั้งคู่หมายความว่าไฟล์นั้นไม่สามารถเชื่อถือได้ว่าเป็นสิ่งที่ผู้ส่งคิดว่ามันเป็น
บันทึกไว้ว่าไฟล์ใดบ้างที่มีบล็อก dataIntegrity อยู่เลย เมื่อมีเอกสารหลายพันไฟล์ สถิตินี้จะบอกอะไรที่เป็นประโยชน์เกี่ยวกับเครื่องมือของผู้ส่งไฟล์ และมันเปลี่ยนการตรวจสอบทีละไฟล์ให้กลายเป็นข้อสังเกตระดับกองไฟล์ทั้งหมดที่คุณนำไปแก้ไขได้
HotXLS อ่านและเขียน XLS, XLSX และ ODS จาก Delphi และ C++Builder โดยไม่ต้องติดตั้ง Excel ใช้งานเส้นทางการเข้ารหัสแบบ Standard และ Agile ตาม [MS-OFFCRYPTO] ที่นำมาเขียนด้วย Pascal ทั้งหมด API ด้านการเข้ารหัส การป้องกัน และเวิร์กบุ๊กมีเอกสารอธิบายไว้ที่ หน้าคอมโพเนนต์สเปรดชีตสำหรับ Delphi ของ HotXLS