Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

LỜI CẢM ƠN
Tôi xin gửi lời cảm ơn sâu sắc tới Tiến sĩ Nguyễn Hữu Đức, thầy đã trực
tiếp hướng dẫn tôi trong quá trình thực hiện luận văn này. Thầy là người đưa ra ý
tưởng và hỗ trợ tôi rất nhiều trong việc định hướng tìm hiểu và triển khai các giải
thuật thám mã.
Tôi xin gửi lời cảm ơn đến Trung tâm Tính toán Hiệu năng cao – Đại học
Bách Khoa Hà Nội. Trung tâm đã hỗ trợ tôi rất nhiều về mặt chuyên môn cũng như
cơ sở vật chất để thực hiện luận văn này.
Tôi xin gửi lời cảm ơn đến các thành viên tại Trung tâm Tính toán Hiệu năng
cao đã giúp đỡ tôi trong những lúc khó khăn, cùng thảo luận và làm việc với tinh
thần hăng say nhiệt huyết trong suốt thời gian qua.

1


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

MỤC LỤC
LỜI CẢM ƠN ........................................................................................................................................1
DANH MỤC HÌNH VẼ ...........................................................................................................................5
DANH MỤC BẢNG ...............................................................................................................................6
DANH MỤC TỪ VIẾT TẮT VÀ THUẬT NGỮ ..........................................................................................7
CHƯƠNG 1- GIỚI THIỆU CHUNG .........................................................................................................8
1.1. Tổng quan về mật mã học ........................................................................................................8
1.2. Giới thiệu bài toán thám mật khẩu cho các file word ..............................................................9

1.2.1. Những thách thức trong việc thám mật khẩu cho các file word ......................................9
1.2.2. Sơ lược về định dạng DOCX ........................................................................................... 10
1.3. Mục tiêu của luận văn ........................................................................................................... 10
1.4. Cấu trúc của luận văn ............................................................................................................ 11
CHƯƠNG 2 – CẤU TRÚC MÃ HÓA VĂN BẢN TRONG MICROSOFT OFFICE ...................................... 12
2.1. Giới thiệu............................................................................................................................... 12
2.1.1. Chú giải một vài thuật ngữ ............................................................................................. 12
2.1.2. Data space ...................................................................................................................... 12
2.1.3. Quản lý bản quyền thông tin trong Data space ............................................................. 14
2.1.4. Mã hóa ........................................................................................................................... 15
2.1.5. Tính năng chống chỉnh sửa ............................................................................................ 16
2.1.6. Chữ ký số ........................................................................................................................ 16
2.1.7. Sắp xếp byte ................................................................................................................... 16
2.1.8. Mã hóa chuỗi ký tự ........................................................................................................ 16
2.1.9. Mã hóa đường dẫn file hợp nhất OLE ............................................................................ 16
2.1.10. Các đối tượng chuẩn Pseudocode ............................................................................... 17
2.1.11. Các trường vendor có thể mở rộng ............................................................................. 17
2.2. Cấu trúc mã hóa .................................................................................................................... 17
2.2.1. EncryptionHeaderFlags .................................................................................................. 18
2.2.2. EncryptionHeader .......................................................................................................... 18
2.2.3. EncryptionVerifier .......................................................................................................... 20
2.2.4. Mã hóa Văn bản ECMA-376 ........................................................................................... 22
2.2.5. Mã hóa RC4 CryptoAPI Văn bản Office .......................................................................... 33
2.2.6. Mã hóa RC4 Văn bản Office ........................................................................................... 35
2.2.7. Kỹ thuật gây rối XOR....................................................................................................... 36

2


Luận văn Thạc sĩ


THÁM MẬT KHẨU CÁC FILE WORD

2.3. Định dạng file DOCX .............................................................................................................. 36
2.3.1. Định dạng ....................................................................................................................... 37
2.3.2. Quan hệ với OOXML....................................................................................................... 37
CHƯƠNG 3 –THÁM MẬT KHẨU CÁC FILE WORD ............................................................................. 38
3.1. Phương pháp vét cạn ............................................................................................................ 38
3.2. Phương pháp phân tích cấu trúc mật khẩu........................................................................... 39
3.2.1. Đặt vấn đề ...................................................................................................................... 39
3.2.2. Tìm hiểu và nghiên cứu thói quen của người dùng ....................................................... 40
3.2.3. Nguồn dữ liệu và phương pháp phân tích ..................................................................... 40
3.2.4. Phân tích......................................................................................................................... 41
3.2.5. Không gian mật khẩu...................................................................................................... 42
3.2.6. Từ điển ........................................................................................................................... 43
3.2.7. Cấu trúc mật khẩu .......................................................................................................... 43
3.2.8. Sinh không gian mật khẩu từ cấu trúc mật khẩu và từ điển .......................................... 44
CHƯƠNG 4 –THỬ NGHIỆM VÀ ĐÁNH GIÁ ....................................................................................... 48
4.1. Các dữ liệu cần trích xuất ..................................................................................................... 48
4.1.1. Sinh khóa Mã hóa Văn bản ECMA-376 (Mã hóa chuẩn) ................................................ 48
4.1.2. Sinh mật khẩu xác thực (Mã hóa chuẩn) ....................................................................... 49
4.1.3. Xác thực mật khẩu (Mã hóa chuẩn) ............................................................................... 49
4.1.4. Sinh khóa mã (Mã hóa nhanh) ....................................................................................... 49
4.1.5. Sinh vectơ khởi tạo (Mã hóa nhanh).............................................................................. 50
4.1.6. Sinh PasswordKeyEncryptor (Mã hóa nhanh) ................................................................ 50
4.1.7. Sinh DataIntegrity (Mã hóa nhanh) ................................................................................ 52
4.1.8. Sinh khóa Mã hóa RC4 CryptoAPI .................................................................................. 53
4.1.9. Luồng mã hóa (Mã hóa RC4) .......................................................................................... 54
4.1.10. Sinh mật khẩu xác thực (Mã hóa RC4) ......................................................................... 55
4.1.11. Tiến trình xác thực mật khẩu (Mã hóa RC4) ................................................................ 55

4.1.12. Thu khóa mã................................................................................................................. 56
4.1.13. Sinh mật khẩu xác thực (Mã hóa mở rộng).................................................................. 56
4.1.14. Xác thực mật khẩu (Mã hóa mở rộng) ......................................................................... 57
4.1.15. Kỹ thuật gây rối XOR .................................................................................................... 57
4.2. Thử nghiệm ........................................................................................................................... 63
4.2.1. Mô hình thử nghiệm ...................................................................................................... 63

3


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

4.2.2. Dữ liệu thử nghiệm ........................................................................................................ 68
4.2.3. Môi trường thử nghiệm ................................................................................................. 68
4.2.4. Kết quả thử nghiệm ....................................................................................................... 68
4.3. Đánh giá ................................................................................................................................ 68
CHƯƠNG 5 - KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ............................................................................ 69
5.1. Kết luận ................................................................................................................................. 69
5.2. Hướng phát triển................................................................................................................... 69
TÀI LIỆU THAM KHẢO ....................................................................................................................... 70

4


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD


DANH MỤC HÌNH VẼ
Hình 2.1. Các mối quan hệ giữa luồng DataSpaceMap, kho DataSpaceInfo, kho TransformInfo và
nội dung được bảo mật . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hình 2.2. Xử lý văn bản ECMA-376 được áp dụng cấu trúc IRMDS . . . . . . . . . . . . . . . . . . . . . . . . . .14
Hình 2.3. Cấu trúc EncryptionHeaderFlags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Hình 2.4. Cấu trúc EncryptionHeader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Hình 2.5. Cấu trúc EncryptionVerifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Hình 2.6. Luồng \EncryptedPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Hình 2.7. Luồng \EncryptionInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Hình 2.8. Cấu trúc luồng \EncryptionInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
Hình 2.9. Cấu trúc luồng \EncryptedPackage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Hình 2.10. Cấu trúc header của Mã hóa RC4 CryptoAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Hình 2.11. Cấu trúc EncryptedStreamDescriptor RC4 CryptoAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Hình 2.12. Luồng mã hóa giản lược RC4 CryptoAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Hình 2.13. Cấu trúc header của Mã hóa RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Hình 3.1. Phân bố xác suất thói quen đặt mật khẩu của người dùng . . . . . . . . . . . . . . . . . . . . . . . . 41
Hình 4.1. Sơ đồ mô hình thử nghiệm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Hình 4.2. Đọc lấy thông tin dkLen, salt và verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Hình 4.3. Giải thuật kiểm tra một mật khẩu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

5


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

DANH MỤC BẢNG
Bảng 2.1. Bảng giá trị lựa chọn số nguyên chỉ định thuật toán mã hóa . . . . . . . . . . . . . . . . . . . . . . .19
Bảng 2.2. Bảng giá trị các trường Flags tương ứng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Bảng 2.3. Bảng giá trị chỉ định thuật toán băm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Bảng 2.4. Bảng giá trị chỉ định số bit trong các khóa mã tương ứng . . . . . . . . . . . . . . . . . . . . . . . . . 20
Bảng 2.5. Bảng giá trị bổ sung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Bảng 2.6. Bảng giá trị các trường của EncryptionHeader (mã hóa chuẩn) . . . . . . . . . . . . . . . . . . . . 24
Bảng 2.7. Bảng giá trị các trường của EncryptionHeader (mã hóa mở rộng) . . . . . . . . . . . . . . . . . . 25
Bảng 2.8. Bảng thể hiện của EncryptionData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Bảng 2.9. Bảng ký tự chỉ định thuật toán mã hóa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Bảng 2.10. Bảng giá trị được dùng bởi CipherAlgorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Bảng 2.11. Bảng ký tự chỉ định thuật toán băm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Bảng 2.12. Báng giá trị các trường của EncyptionHeader (Mã hóa RC4 CryptoAPI) . . . . . . . . . . . . .34

6


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

DANH MỤC TỪ VIẾT TẮT VÀ THUẬT NGỮ
TỪ VIẾT TẮT

CHÚ GIẢI

SHA

Là năm thuật giải dùng để chuyển một đoạn dữ liệu nhất định
thành một đoạn dữ liệu có chiều dài không đổi với xác suất khác
biệt cao. Năm thuật giải SHA là SHA-1, SHA-224, SHA-256,
SHA-384, và SHA-512. Bốn thuật giải sau thường được gọi chung
là SHA-2.


AES

Thuật toán mã khối, mã hóa dữ liệu cải tiến và là hệ mã mạnh, có
kích thước khóa là 128-bit, 192-bit hoặc 256-bit.

ECMA-376

Một chuẩn mở quốc tế được phê duyệt dành cho các tài liệu xử lý
văn bản, trình diễn và bảng tính, được áp dụng hoàn toàn tự do
trên nhiều ứng dụng và hệ thống. Các phiên bản Microsoft Office
từ 2007 trở đi đã áp dụng chuẩn này như khuôn dạng lưu trữ mặc
định.

IRMDS

Cấu trúc quản lý bản quyền thông tin vùng dữ liệu được dùng để
gắn chính sách quản lý bản quyền cho một văn bản.

RC4

Hệ mã đối xứng, tuy nhiên có nhiều điểm yếu nên ít được sử dụng
trong các hệ thống mới ngày nay.

PBKDF2

Giải thuật sinh mã từ mật khẩu ban đầu có giá trị salt ngẫu nhiên.

GPU


Bộ xử lý đồ họa.

7


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

CHƯƠNG 1- GIỚI THIỆU CHUNG
1.1. Tổng quan về mật mã học
Mật mã học (tiếng Anh là Cryptography hoặc Cryptology) là ngành khoa
học nghiên cứu về các kỹ thuật toán học liên quan tới các khía cạnh an toàn thông
tin. Trước thời kỳ hiện đại, mật mã học chỉ tập trung duy nhất tới tính bí mật của
bản tin – tức là gắn liền với sự mã hóa, đó là quá trình chuyển đổi các thông tin
thông thường (bản rõ) ở dạng có thể nhận thức được thành một dạng khó có thể
nhận thức trực tiếp được. Muốn đọc được cần phải có “khóa” dùng để giải mã cho
bản tin đó. Việc mã hóa được dùng để đảm bảo tính bí mật của thông tin trong lưu
trữ cũng như trong thông tin liên lạc, chẳng hạn trong công tác tình báo, quân sự,
ngoại giao hay là kinh tế, thương mại. Trong những thập niên gần đây, lĩnh vực này
đã được mở rộng vượt ngoài các mối quan tâm về tính bí mật còn bao gồm các kỹ
thuật khác như kiểm tra tính toàn vẹn của thông điệp, xác thực định danh người
gửi/nhận, chữ ký số, chứng thực khóa công khai.
Về mặt thuật ngữ, cho đến thời kỳ hiện đại, thuật ngữ cryptography được
dùng để nhắc đến việc sử dụng và thực hành các kỹ thuật mật mã hóa. Nhiều người
sử dụng thuật ngữ cryptography và cryptology hoán đổi cho nhau trong tiếng Anh.
Tuy vậy, theo các chuyên gia về mật mã cryptology dùng để chỉ sự nghiên cứu kết
hợp của mật mã hóa (cryptography) và thám mã (cryptanalysis).
Thám mã (tiếng Anh là Cryptanalysis) – là khoa học nghiên cứu về các
phương pháp lấy lại ý nghĩa của các thông tin đã bị mã hóa, mà không cần truy xuất

tới các thông tin dùng để thực hiện mã hóa đó. Thông thường, điều này liên quan
đến hiểu biết về cách hệ thống làm việc và tìm ra một khóa bí mật. Mục tiêu của
thám mã (phá mã) là tìm những điểm yếu hoặc không an toàn trong phương thức
mật mã hóa. Thám mã có thể được thực hiện bởi những kẻ tấn công mục đích xấu,
nhằm làm hỏng hệ thống; hoặc bởi những người thiết kế ra hệ thống với mục đích
đánh giá độ an toàn của hệ thống.
Khoa học thám mã luôn đi cùng với khoa học mật mã trong suốt chiều dài
lịch sử của mật mã học – khi một thuật toán mã hóa mới được thiết kế để thay thế
những thiết kế cũ bị hỏng, thì các kỹ thuật thám mã mới được đưa ra để phá vỡ các
đề án cải thiện đó. Hai nhánh nghiên cứu này được xem như hai mặt của cùng vấn
đề an toàn an ninh thông tin: sự phát triển của một nhánh luôn thúc đẩy sự phát triển
của nhanh kia và ngược lại.
Trong lịch sử phát triển, sự phát triển vượt trước của một nhánh so với nhánh
còn lại đôi khi mang đến những lợi ích to lớn cho đời sống, thậm chí còn quyết định
vận mệnh của cả một đất nước. Ví dụ như sự thành công trong việc thám mã
Zimmermann Telegram trong thế chiến thứ nhất đã kéo Hoa Kỳ vào cuộc chiến, hay
việc thám mã thành công hệ mã German được đánh giá góp phần rút ngắn thế chiến
thứ hai đi vài tháng.
8


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

1.2. Giới thiệu bài toán thám mật khẩu cho các file word
1.2.1. Những thách thức trong việc thám mật khẩu cho các file word
Đối với các file word 2003 trở về trước thì chúng ta có thể dùng phương pháp
vét cạn. Nhưng từ word 2007 trở lên thì mật khẩu đã được mã hóa bằng AES 128bit kết hợp SHA1. Với các hệ mã mạnh như AES (hệ mã được sử dụng phổ biến
trong các phiên bản mới của Microsoft Word) việc tấn công vét cạn như vậy là

không khả thi. AES, tiêu chuẩn mã hóa tiên tiến, là một thuật toán mã hóa khối.
AES làm việc với các khối dữ liệu 128-bit (4x4 bytes) và khóa của nó có độ dài là
128, 192 hoặc 256 bit. AES có thể dễ dàng thực hiện với tốc độ cao bằng phần mềm
hoặc phần cứng và không đòi hỏi nhiều bộ nhớ. Là một hệ thống mã hóa mạnh,
AES-128/AES-256 với kích thước khóa là 128/256 bit có đến 2128/2256 khả năng
phải thử để có thể tìm ra được mật khẩu ban đầu. Một số nghiên cứu gần đây như
giải thuật XSL cho phép giảm không gian khóa từ 2128 khả năng xuống còn khoảng
2100 khả năng. Tuy nhiên, ngay cả như vậy việc thử hết tất cả các khả năng đó vẫn là
không chấp nhận được đối với các hệ thống tính toán thông dụng.
Cách tiếp cận được để xuất ở đây là không trực tiếp tấn công trên không gian
khóa AES. Thay vào đó, do khóa cho các hệ mã của file word được sinh ra từ mật
khẩu người dùng thông qua một hàm băm được công bố trong phần đặc tả của file.
Không gian mật khẩu mặc dù lớn nhưng tính khả thi cho việc thám mã file dựa trên
không gian mật khẩu cao hơn nhiều so với thám mã dựa trên không gian khóa. Hơn
nữa, nếu kết hợp với việc phân tích cấu trúc mật khẩu dựa trên thói quen của người
dùng (phương pháp tấn công từ điển) thì không gian mật khẩu sẽ được thu hẹp lại
rất nhiều làm tăng hiệu suất thám mã.
Đối tượng nghiên cứu cụ thể trong luận văn này là file dạng word với đuôi
DOCX (viết tắt là file DOCX) được mã hóa bằng giải thuật AES-128. Thông tin
này rất quan trọng cho việc khôi phục chính xác mật khẩu đúng cho file DOCX đã
được bảo vệ nhờ quy trình giải mã.
Trong phân tích mật mã và bảo mật máy tính, tấn công từ điển là một kỹ
thuật phá mã hoặc vượt qua một cơ chế xác thực bằng cách thử các khóa mã hay
mật khẩu trong một miền tiềm năng.
Kỹ thuật tấn công từ điển là tấn công mục tiêu bằng cách thử tất cả các từ
trong một danh sách dài gọi là từ điển (được chuẩn bị trước). Khác với kiểu tấn
công vét cạn, phần lớn không gian khóa được tìm kiếm một cách hệ thống, tấn công
từ điển thử trong vùng có nhiều khả năng thành công nhất, thường xuất phát từ một
danh sách các từ được tạo ra dựa trên thông tin của người sử dụng hoặc của một từ
điển (vì vậy mà có thuật ngữ "tấn công từ điển"). Nói chung, thành công của tấn

công từ điển chủ yếu là do dựa trên xác suất các từ hay cụm từ mà nhiều người
dùng có xu hướng lựa chọn, chẵng hạn như chọn mật khẩu ngắn (7 ký tự hoặc ít
hơn), những từ đơn tìm thấy trong từ điển, những từ đơn giản, dễ dự đoán các biến
thể trên từ (như viết hoa một chữ, hay thêm vào một chữ số)…
9


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

1.2.2. Sơ lược về định dạng DOCX
DOCX là phần mở rộng của file Microsoft Word Open XML. Định dạng xử
lý văn bản này đã được giới thiệu cùng Microsoft Word 2007.
Các file DOCX khác với các chương trình Microsoft Word trước đây sử dụng
file DOC, nghĩa là trong khi file DOC sử dụng văn bản hoặc định dạng nhị phân để
lưu trữ một tài liệu, thì file DOCX lại dựa trên XML và sử dụng công nghệ nén ZIP
để có kích thước file nhỏ hơn. Nói cách khác, một file DOCX là một tập hợp các
file XML đã được nén bằng Zip. Sự cần thiết khi thay đổi từ một định dạng file nhị
phân trở thành một định dạng XML đã được nhận ra bởi các định dạng trước đây
không thể đáp ứng những thách thức mới nhất như di chuyển dữ liệu giữa các ứng
dụng khác nhau và thu thập thông tin từ chúng. Bây giờ với XML, người dùng sẽ dễ
dàng làm việc với các file word hơn nếu các ứng dụng đó có hỗ trợ. Hơn nữa, mối
lo ngại về bảo mật cũng đã được giảm thiểu tối đa vì XML có thể dễ dàng đi qua
tường lửa. Việc gửi và nhận cũng đã trở nên dễ dàng khi các file DOCX nhỏ gọn và
mạnh mẽ hơn nhiều.
Các thuật toán mã hóa có thể phụ thuộc vào các thuật toán được truy cập
thông qua các hàm API (giao diện lập trình ứng dụng) trong hệ điều hành Windows.
Hiện nay, Word 2013 ngoài việc duy trì hỗ trợ các hàm mã hóa API (CryptoAPI),
còn hỗ trợ CNG (CryptoAPI Next Generation), chúng được sử dụng trong

Microsoft Word 2007 Service Pack 2 (SP2) với file DOCX.
Để thuận tiện cho người dùng, khóa bí mật của các hàm mã hóa này được
sinh ra từ một mật khẩu do người gửi nhập vào thông qua một hàm băm để mã hóa
tài liệu. Sau đó mật khẩu được người gửi chuyến đến cho người nhận qua một kênh
an toàn khác để người nhận sử dụng cho quá trình giải mã.
Bài toán thám mật khẩu file word được đặt ra ở đây là: cho một file word, cụ
thể là định dạng DOCX, có mật khẩu bảo vệ được tạo bởi một người đã biết, hãy
xác định mật khẩu để có thể mở được file này.
1.3. Mục tiêu của luận văn
Luận văn có mục đích nghiên cứu như sau:
- Nghiên cứu cơ chế mã hóa của file DOCX.
- Nghiên cứu cấu trúc mật khẩu dựa trên thói quen chung của các người
dùng trong việc đặt mật khẩu để làm cơ sở thực hiện thám mật khẩu.
- Xây dựng ứng dụng thử nghiệm.
Đối tượng nghiên cứu bao gồm:
- File word được tạo ra từ bộ phần mềm Microsoft Office, cụ thể là phần
mềm Microsoft Word từ phiên bản 2007 trở đi.
- Cấu trúc mật khẩu.
Phạm vi nghiên cứu của luận văn giới hạn trên file DOCX.
10


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

1.4. Cấu trúc của luận văn
Luận văn được chia ra làm 5 chương:
Chương 1: Giới thiệu các vấn đề liên quan đến luận văn.
Chương 2: Giới thiệu về cấu trúc mã hóa văn bản trong Microsoft Office.

Chương 3: Các phương pháp thám mật khẩu cho file word.
Chương 4: Thử nghiệm và đánh giá.
Chương 5: Kết luận và hướng phát triển của luận văn.

11


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

CHƯƠNG 2 – CẤU TRÚC MÃ HÓA VĂN BẢN TRONG
MICROSOFT OFFICE
Chương này tập trung trình bày về cấu trúc mã hóa được Microsoft sử dụng
trong các file văn bản Office. Trong đó có thông tin mã hóa và phương pháp mã hóa
của các file văn bản. Những kiến thức này sẽ phục vụ cho việc trích xuất dữ liệu xác
thực mật khẩu được lưu trong file DOCX.
2.1. Giới thiệu
Cấu trúc mã hóa văn bản Microsoft Office có tính chất đặc trưng là chúng có
chính sách quản lý bản quyển thông tin (IRM), được mã hóa, có chữ ký hoặc có tính
năng bảo vệ soạn thảo. Cụ thể hơn, định dạng các file Office được mô tả như sau:
- Có cấu trúc cư xử như một cơ chế chung trong việc lưu trữ dữ liệu đã
biến đổi cùng với thông tin về dữ liệu đó.
- Có cấu trúc lưu các chính sách quản lý bản quyền được áp dụng cho
một văn bản nhất định.
- Được mã hóa, có chữ ký xác thực và có tính năng chống chỉnh sửa văn
bản.
2.1.1. Chú giải một vài thuật ngữ
data space: Một loạt các biến đổi xảy ra trên nội dung văn bản gốc theo một
thứ tự nhất định. Biến đổi đầu tiên trong data space lấy dữ liệu chưa biến đổi làm

đầu vào và biến đổi nó thành đầu ra cho bước tiếp theo. Biến đổi cuối cùng trong
data space xuất ra dữ liệu đã được lưu trữ trong file hợp nhất OLE. Khi đảo ngược
quá trình, mỗi biến đổi trong data space được áp dụng theo thứ tự ngược lại để trả
dữ liệu về trạng thái ban đầu của nó.
data space reader: Một thành phần chuyên trích xuất nội dung được bảo mật
để thực hiện một thao tác nào đó hoặc để hiển thị cho người dùng. Reader không
làm thay đổi hay tạo ra các data space khác.
data space updater: Một thành phần có thể đọc và cập nhật nội dung bảo
mật. Updater không thể thay đổi các định nghĩa data space.
data space writer: Một thành phần có thể đọc, cập nhật hay tạo ra một định
nghĩa data space hoặc nội dung bảo mật.
ECMA-376: Một chuẩn mở quốc tế được phê duyệt dành cho các tài liệu xử
lý văn bản, trình diễn và bảng tính, được áp dụng hoàn toàn tự do trên nhiều ứng
dụng và hệ thống. Các phiên bản Microsoft Office từ 2007 trở đi đã áp dụng chuẩn
này như khuôn dạng lưu trữ mặc định.
2.1.2. Data space
Cấu trúc data space mô tả một phương thức thích hợp cho việc lưu trữ dữ liệu
trong các file hợp nhất OLE mà đã được biến đổi theo một cách nào đó. Cấu trúc
này lưu trữ cả nội dung được bảo mật và thông tin về các dạng biến đổi đã được áp
12


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

dụng với nội dung đó. Bằng việc lưu trữ tất cả thông tin này trong file hợp nhất
OLE, phần mềm client có tất cả thông tin được yêu cầu để đọc, ghi hoặc thao tác
khác trên nội dung. Một cấu trúc chuẩn của các luồng và các kho lưu trữ cho phép
các thành phần khác nhau của phần mềm tác động đến dữ liệu một cách phù hợp.

Cấu trúc data space cho phép các ứng dụng client mô tả một hoặc nhiều dạng
biến đổi tùy ý. Mỗi dạng biến đổi đại diện cho một hoạt động đơn lẻ bất kỳ được
thực hiện trên thiết lập của các kho hoặc các luồng trong nội dung văn bản gốc. Một
hoặc nhiều dạng biến đổi có thể sẽ được hợp nhất lại trong một định nghĩa data
space. Các định nghĩa data space có thể được áp dụng cho bất kỳ kho hoặc luồng
nào in nội dung văn bản gốc trong bản đồ data space.
Vì các lớp hành động gián tiếp ở giữa các dạng biến đổi và nội dung văn bản
nên các dạng biến đổi khác nhau có thể được áp dụng cho các phần khác nhau của
nội dung văn bản và các dạng biến đổi có thể được hợp lại tại bất kỳ cấp nào.
Hình dưới minh họa cho các mối quan hệ giữa luồng DataSpaceMap, kho
DataSpaceInfo, kho TransformInfo và nội dung được bảo mật. Chú ý rằng các
luồng và kho khác cũng tồn tại trong định dạng file này; hình này chỉ mô tả các mối
quan hệ giữa các kho và các luồng.

Hình 2.1. Các mối quan hệ giữa luồng DataSpaceMap, kho DataSpaceInfo, kho
TransformInfo và nội dung được bảo mật

13


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

Cấu trúc data space chỉ rõ thiết lập của các kho và các luồng trong một file
hợp nhất OLE, các cấu trúc được chứa trong chúng, và các mối quan hệ giữa chúng.
Các file hợp nhất OLE đó không những phù hợp với cấu trúc data space mà còn có
thể có các kho và các luồng khác trong chúng mà không cần phải được chỉ định bởi
định dạng file này.
2.1.3. Quản lý bản quyền thông tin trong Data space

Cấu trúc quản lý bản quyền thông tin data space (IRMDS) được dùng để gắn
chính sách quản lý bản quyền cho một văn bản. Cấu trúc này định nghĩa một dạng
biến đổi được dùng để mã hóa nội dung văn bản và định nghĩa một dạng biến đổi
thứ hai có thể được dùng cho các dạng văn bản khác để nén nội dung văn bản. Nội
dung văn bản gốc được mã hóa và được đặt vào một kho mà không thể truy cập
bình thường bằng ứng dụng. Khi đó, ứng dụng phải dùng các dạng biến đổi đã được
định nghĩa trong văn bản để giải mã nội dung đã được bảo mật.
Cấu trúc này là bổ sung cho cấu trúc data space. Vì vậy, việc bổ sung cấu trúc
này bao gồm cả việc lưu trữ nội dung văn bản trong file hợp nhất OLE.
Các ứng dụng được bổ sung cấu trúc này sẽ lưu trữ một văn bản thứ hai, gọi
là văn bản giữ chỗ (placeholder document), trong file hợp nhất OLE. Văn bản giữ
chỗ được đặt trong các luồng hoặc các kho thường được xác định bởi ứng dụng có
chứa nội dung văn bản, loại ứng dụng không dùng cấu trúc IRMDS mà thay vào đó
sẽ mở văn bản giữ chỗ.

Hình 2.2. Xử lý văn bản ECMA-376 được áp dụng cấu trúc IRMDS

14


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

Các ứng dụng được bổ sung cấu trúc này sẽ cố gắng thực hiện theo các mặt
giới hạn được chỉ định trong văn bản. Các mặt giới hạn được chỉ định bao gồm
quyền được xem, in, chỉnh sửa, chuyển tiếp hoặc xem thông tin bản quyền.
Hình 2.2 thể hiện rõ các kho, luồng, cấu trúc và mối quan hệ giữa chúng được
tạo ra khi cấu trúc IRMDS được sử dụng trong văn bản ECMA-376.
Cấu trúc IRMDS được yêu cầu khi đọc, sửa đổi hoặc tạo các văn bản có áp

dụng chính sách quản lý bản quyền.
2.1.4. Mã hóa
Văn bản được bảo mật bằng mật khẩu có thể được tạo ra bằng một trong bốn
kỹ thuật sau:
- Kỹ thuật gây rối XOR:
Kỹ thuật gây rối XOR có thể được áp dụng trên tất cả các phần của văn bản.
Các luồng bình thường cũng được chứa cùng một chỗ với văn bản đã sửa đổi.
Có hai phương thức để thực hiện kỹ thuật gây rối XOR, gọi là Phương thức 1
và Phương thức 2. Phương thức 1 xác định các cấu trúc và các thủ tục được sử dụng
bởi cấu trúc định dạng Excel (.xls), và Phương thức 2 xác định các cấu trúc và các
thủ thục được sử dụng bởi Cấu trúc định dạng Word (.doc).
- Mã hóa RC4 40-bit
Mã hóa RC4 40-bit có thể được áp dụng trên tất cả các phần của văn bản. Các
kỹ thuật giống nhau trong việc sinh mật khẩu xác thực, chuyển hóa khóa mã và mã
hóa dữ liệu đều được sử dụng trong tất cả các định dạng file hỗ trợ mã hóa RC4 40bit.
- Mã hóa CryptoAPI RC4
Mã hóa CrytoAPI RC4 có thể được áp dụng trên tất cả các phần của văn bản.
Các văn bản sẽ có một luồng mới để chứa thông tin được mã hóa nhưng cũng có thể
mã hóa các luồng khác cùng một chỗ. Các kỹ thuật giống nhau trong việc sinh mật
khẩu xác thực, lưu trữ dữ liệu chỉ định mã hóa, chuyển hóa khóa mã và mã hóa dữ
liệu đều được dùng trong tất cả các định dạng file hỗ trợ hàm mã hóa CryptoAPI
RC4.
- Mã hóa văn bản ECMA-376
Các văn bản ECMA-376 đã mã hóa sử dụng các data space có chức năng
chứa toàn bộ văn bản như một luồng đơn trong file hợp nhất OLE. Tất cả các văn
bản ECMA-376 tuân theo các phương pháp tiếp cận được quy định trong văn bản
này và không yêu cầu kiến thức về ứng dụng cụ thể để thực hiện các hoạt động mã
hóa. Phương pháp tiếp cận tổng thể rất giống với phương pháp được dùng trong
IRMDS.
Mã hóa văn bản ECMA-376, có thể dùng một trong ba cách sau:

15


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

 Mã hóa chuẩn: Cách này sử dụng cấu trúc nhị phân
EncryptionInfo. Nó dùng chuẩn mã hóa cao cấp (AES) làm
thuật toán mã hóa và SHA-1 làm thuật toán băm.
 Mã hóa nhanh: Cách này sử dụng một cấu trúc XML
EncryptionInfo. Các thuật toán mã hóa và băm được quy định
trong cấu trúc này có thể là bất kỳ loại nào mà được máy chủ
hỗ trợ.
 Mã hóa có thể mở rộng: Cách này dùng kỹ thuật có khả năng
mở rộng để cho phép sử dụng bất kỳ mô đun mã hóa nào.
2.1.5. Tính năng chống chỉnh sửa
Các dạng văn bản khác nhau có các cách chống chỉnh sửa khác nhau tùy theo
định dạng file. Sơ lược vài loại trong Microsoft Office như sau:
- Định dạng Excel: Mật khẩu được chuyển thành mật khẩu xác thực 16-bit,
được lưu trong văn bản và sau đó văn bản được mã hóa. Nếu người dùng không
cung cấp mật khẩu thì sẽ mã hóa bằng mật khẩu có sẵn.
- Định dạng Word: mật khẩu được lưu trong bản rõ và văn bản không được
mã hóa.
- Định dạng PowerPoint: Mật khẩu được lưu trong bản rõ và văn bản có thể
được mã hóa. Nếu người dùng không cung cấp mật khẩu thì sẽ mã hóa bằng mật
khẩu có sẵn.
2.1.6. Chữ ký số
Văn bản có thể được ký bằng một trong những phương thức sau:
- Định dạng nhị phân được lưu trong kho _signatures.

- Định dạng sử dụng Tiến trình và Cú pháp chữ ký XML được lưu trong
kho _xmlsignatures.
2.1.7. Sắp xếp byte
Toàn bộ cấu trúc và dữ liệu trong các file văn bản được cho là ở dạng littleendian.
2.1.8. Mã hóa chuỗi ký tự
Trong các file văn bản, một vài kho và luồng được đặt tên kèm các chuỗi
"0x01", "0x05", "0x06" và "0x09". Các chuỗi này không nhất thiết phải có trong
tên. Thay vào đó, chúng đại diện cho các ký tự ASCII tương ứng với từng giá trị
hexa 0x01, 0x05, 0x06 và 0x09.
2.1.9. Mã hóa đường dẫn file hợp nhất OLE
Đường dẫn tới các kho và các luồng trong file hợp nhất OLE được chia tách
bởi dấu chéo ngược (\). Dấu chéo ngược là dấu tách giữa các phần của đường dẫn
16


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

và vì vậy nó không phải là một phần trong tên của bất kỳ kho hay luồng nhất định
nào. Các đường dẫn bắt đầu bằng một dấu chéo ngược cho biết đó là kho cha của
file hợp nhất OLE.
2.1.10. Các đối tượng chuẩn Pseudocode
Pseudocode trong file văn bản dẫn đến các đối tượng khác nhau với các thuộc
tính liên kết. Việc truy cập thuộc tính của một đối tượng được chỉ rõ với cú pháp
như sau: Object.Property. Mục này mô tả thuộc tính của từng đối tượng được sử
dụng trong văn bản.
Mảng: là một tập các phần tử con cùng loại, với mỗi phần tử con được đánh
địa chỉ bằng một chỉ số nguyên không dấu. Tra một phần tử con của mảng theo cú
pháp sau: array[index].

Chỉ số bắt đầu từ 0 và tăng dần từng đơn vị một. Vì vậy, chỉ số 0 được xem
như là phần từ đầu tiên của mảng, và chỉ số 1 được xem như là phần tử thứ hai của
mảng.
Mảng có một thuộc tính sau:
Length: Số các phần tử con của mảng.
Chuỗi: là một mảng các ký tự ASCII. Giống như mảng, từng ký tự trong
chuỗi được đánh địa chỉ từ chỉ số 0 trở đi.
Kho: là một kho OLE, có các thuộc tính như sau:
- Name: Định danh duy nhất cho kho theo cha của nó.
- GUID: Một định danh 16-byte được liên kết với kho.
- Children: Có hoặc không có các kho con hoặc các luồng con. Mỗi
phần tử con được đánh địa chỉ theo tên của nó.
Luồng: là một kho OLE, có các thuộc tính như sau:
- Name: Định danh duy nhất cho luồng theo cha của nó.
- Data: Một mảng các số nguyên không dấu 8-bit chứa dữ liệu trong
luồng.
2.1.11. Các trường vendor có thể mở rộng
Cấu trúc data space cho phép các vendor thực hiện các biến đổi tùy ý, các
định nghĩa data space, và các bản đồ data space. Với cách này cấu trúc có thể được
dùng để đại diện cho một biến đổi dữ liệu bất kỳ.
Cấu trúc IRMDS không chứa bất kỳ một trường vendor có thể mở rộng nào.
Mã hóa văn bản ECMA-376 có thể được mở rộng nếu hoặc các nguồn cung
cấp hàm CryptoAPI bổ sung được cài đặt hoặc việc mã hóa mở rộng được sử dụng.
2.2. Cấu trúc mã hóa
Mục này trình bày vấn đề mã hóa và gây rối. Có 4 kỹ thuật như sau:
17


Luận văn Thạc sĩ


-

THÁM MẬT KHẨU CÁC FILE WORD

Mã hóa ECMA-376.
Mã hóa RC4 CryptoAPI.
Mã hóa RC4.
Gây rối XOR.

Mã hóa ECMA-376 cũng bao hàm cả mã hóa sử dụng phần mở rộng mật mã
bên thứ 3, được gọi là mật mã mở rộng trong các mục sau.
2.2.1. EncryptionHeaderFlags
Cấu trúc EncryptionHeaderFlags chỉ rõ thuộc tính của thuật toán mã hóa
được sử dụng. Nó phải được chứa cùng một cấu trúc EncryptionHeader.
Nếu bit fCryptoAPI được thiết lập và bit fAES không được thiết lập thì Mã
hóa RC4 phải được sử dụng. Nếu bit mã hóa fAES được thiết lập thì một block
cipher có hỗ trợ chế độ ECB phải được sử dụng. Để tương thích với các tiến trình
hiện tại thì Mã hóa AES với độ dài khóa 128, 192 hoặc 256 bit nên được sử dụng.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
A B C D E F

Không sử dụng

Hình 2.3. Cấu trúc EncryptionHeaderFlags

A - Reserved1 (1 bit): Giá trị phải là 0 và được bỏ qua.
B - Reserved2 (1 bit): Giá trị phải là 0 và được bỏ qua.
C - fCryptoAPI (1 bit): Một cờ chỉ rõ Mã hóa CryptoAPI RC4 hay Mã hóa
ECMA-376 được sử dụng. Nó phải là 1 khi fExternal là 0. Nếu fExternal là 1 thì
nó phải là 0.

D - fDocProps (1 bit): Giá trị phải là 0 nếu các thuộc tính văn bản được mã
hóa.
E - fExternal (1 bit): Giá trị phải là 1 nếu mã hóa mở rộng được sử dụng.
Nếu giá trị này là 1 thì giá trị của mọi trường khác trong cấu trúc này phải là 0.
F - fAES (1 bit): Giá trị phải là 1 nếu nội dung bảo mật là văn bản ECMA376; nếu không thì nó phải là 0. Nếu bit fAES là 1 thì bit fCryptoAPI cũng phải là
1.
Unused (26 bit): Giá trị không được định nghĩa và bị bỏ qua.
2.2.2. EncryptionHeader
Cấu trúc EncryptionHeader được sử dụng trong Mã hóa Văn bản ECMA376 và mã hóa RC4 CryptoAPI văn bản Office để chỉ định các thuộc tính cho luồng
mã hóa.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
Flags
SizeExtra

18


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

AlgID
AlgIDHash
KeySize
ProviderType
Reserved1
Reserved2
CSPName
…


Hình 2.4. Cấu trúc EncryptionHeader

Flags (4 byte): Cấu trúc EncryptionHeaderFlags chỉ định các thuộc tính
của thuật toán mã hóa sử dụng.
SizeExtra (4 byte): Một trường dự bị với giá trị là 0x00000000.
AlgID (4 byte): Số nguyên chỉ định thuật toán mã hóa. Nó phải là một trong
các giá trị được mô tả trong bảng dưới đây.
Giá trị

Thuật toán

0x00000000

Được xác định bởi Flags

0x00006801

RC4

0x0000660E

128-bit AES

0x0000660F

192-bit AES

0x00006610

256-bit AES


Bảng 2.1. Bảng giá trị lựa chọn số nguyên chỉ định thuật toán mã hóa

Trường Flags và trường AlgID chứa các giá trị có liên quan và phải được
thiết lập thành một trong các tổ hợp trong bảng dưới đây (bảng 2.2).
Flags.fCryptoAPI

Flags.fAES

Flags.fExternal

AlgID

Thuật toán

0

0

1

0x00000000

Được xác định bởi ứng
dụng

1

0


0

0x00000000

RC4

1

0

0

0x00006801

RC4

1

1

0

0x00000000

128-bit AES

1

1


0

0x0000660E

128-bit AES

1

1

0

0x0000660F

192-bit AES

1

1

0

0x00006610

256-bit AES

Bảng 2.2. Bảng giá trị các trường Flags tương ứng

AlgIDHash (4 byte): Số nguyên chỉ định thuật toán băm cùng với bit
Flags.fExternal. Nó phải là một trong các tổ hợp trong bảng sau (bảng 2.3).

AlgIDHash

Flags.fExternal

Thuật toán

19


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

0x00000000

1

Được xác định bởi ứng dụng

0x00000000

0

SHA-1

0x00008004

0

SHA-1


Bảng 2.3. Bảng giá trị chỉ định thuật toán băm

KeySize (4 byte): Số nguyên không dấu chỉ định số các bit trong khóa mã.
Nó phải là bội của 8 và phải là một trong các giá trị trong bảng dưới đây (bảng 2.4).
Thuật toán

Giá trị

Chú thích

Bất kỳ

0x00000000

Được xác định bởi Flags

RC4

0x00000028 – 0x00000080 (toàn bộ)

Tăng 8-bit

AES

0x00000080, 0x000000C0, 0x00000100

128-bit, 192-bit hoặc 256-bit

Bảng 2.4. Bảng giá trị chỉ định số bit trong các khóa mã tương ứng


Nếu trường Flags không có bộ bit fCryptoAPI, thì trường KeySize phải là
0x00000000. Nếu RC4 được sử dụng thì giá trị phải phù hợp với bộ cung cấp dịch
vụ mật mã (CSP).
ProviderType (4 byte): Một giá trị bổ sung đặc trưng tương ứng với hằng số
được chấp nhận bởi CSP đã chỉ định. Nó phải phù hợp với CSP đã chọn. Nó là một
trong các giá trị sau (bảng 2.5).
Thuật toán

Giá trị

Chú thích

Bất kỳ

0x00000000

Được xác định bởi Flags

RC4

0x00000001

AES

0x00000018

Bảng 2.5. Bảng giá trị bổ sung

Nếu trường Flags không có bộ bit fCryptoAPI, thì trường ProviderType

phải là 0x00000000.
Reserved1 (4 byte): Giá trị chưa định nghĩa và bị bỏ qua.
Reserved2 (4 byte): Giá trị 0x00000000 và bị bỏ qua.
CSPName (biến): Một chuỗi ký tự Unicode tận cùng là null chỉ định tên
CSP.
2.2.3. EncryptionVerifier
Cấu trúc EncryptionVerifier được sử dụng trong Mã hóa RC4 CryptoAPI
Văn bản Office và Mã hóa Văn bản ECMA-376. Mỗi cách sử dụng cấu trúc này đề
phải chỉ rõ thuật toán băm và thuật toán mã hóa được dùng trong cấu trúc
EncryptionVerifier.
Verifier có thể là 16 byte dữ liệu được sinh ngẫu nhiên mỗi lần cấu trúc này
được tạo ra. Verifier không được lưu trực tiếp trong cấu trúc này.
20


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

Cấu trúc EncryptionVerifier phải được thiết lập theo các bước sau:
1. Sinh dữ liệu ngẫu nhiên và ghi nó vào trường Salt.
2. Xác định khóa mã từ mật khẩu và salt với block 0.
3. Verifier từ 16 byte dữ liệu bổ sung ngẫu nhiên.
4. Mã hóa kết quả của bước 3 và ghi nó vào trường EncryptedVerifier.
5. Đối với thuật toán băm đã chọn, xác định kích thước của dữ liệu băm
và ghi giá trị này vào trường VerifierHashSize.
6. Xác định đầu ra của thuật toán băm bằng cách sử dụng đầu vào là dữ
liệu đã được sinh ở bước 3.
7. Mã hóa đầu ra của thuật toán băm ở bước 6 bằng cách sử dụng thuật
toán mã hóa đã chọn và ghi đầu ra vào trường

EncryptedVerifierHash.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
SaltSize
Salt (16 byte)
…
EncryptedVerifier (16 byte)
…
VerifierHashSize
EncryptedVerifierHash (biến)
…

Hình 2.5. Cấu trúc EncryptionVerifier

SaltSize (4 byte): Số nguyên không dấu chỉ định kích thước của trường Salt.
Nó phải là 0x00000010.
Salt (16 byte): Một mảng các byte chỉ định giá trị salt được dùng trong suốt
quá trình sinh mật khẩu băm. Nó không được phép giống với dữ liệu dùng cho
verifier được mã hóa lưu trong trường EncryptedVerifier.
EncryptedVerifier (16 byte): Phải là giá trị Verifier được sinh ra ngẫu
nhiên đã mã hóa sử dụng thuật toán được chọn bởi sự bổ sung.
VerifierHashSize (4 byte): Số nguyên không dấu chỉ định số các byte cần để
chứa băm của dữ liệu được dùng để sinh trường EncryptedVerifier.
EncryptedVerifierHash (biến): Một mảng các byte chứa dạng đã mã hóa
của băm của giá trị Verifier được sinh ngẫu nhiên. Độ dài của mảng phải là kích
thước của block mã hóa được nhân lên bởi số các block cần để mã hóa băm của
Verifier. Nếu thuật toán mã hóa là RC4 thì độ dài phải là 20 byte. Nếu thuật toán
21


Luận văn Thạc sĩ


THÁM MẬT KHẨU CÁC FILE WORD

mã hóa là AES thì độ dài phải là 32 byte. Sau khi giải mã trường
EncryptedVerifierHash, chỉ các byte VerifierHashSize được dùng.
2.2.4. Mã hóa Văn bản ECMA-376
Khi một văn bản ECMA-376 được mã hóa, một kho có cấu trúc dùng các
data space sẽ được sử dụng. Ngoại trừ các ngoại lệ được ghi chú trong các mục dưới
đây, các luồng và các kho được chứa cùng kho \0x06DataSpaces phải được xem
xét.
2.2.4.1. Luồng \0x06DataSpaces\DataSpaceMap
Bản đồ data space phải chứa cấu trúc như sau:
- Luồng \0x06DataSpaces\DataSpaceMap phải chứa cấu trúc
DataSpaceMap có chứa chính xác một cấu trúc DataSpaceMapEntry.
- Cấu trúc DataSpaceMapEntry phải:
+
+

Có một DataSpaceName "StrongEncryptionDataSpace".
Có chính xác một đầu vào ReferenceComponents là
"EncryptedPackage" và có kiểu 0x00000000, thể hiện như một
luồng.

2.2.4.2. Kho \0x06DataSpaces\DataSpaceInfo
Kho DataSpaceInfo phải chứa một luồng được định nghĩa như sau:
- Kho \0x06DataSpaces\DataSpaceInfo phải chứa một luồng
"StrongEncryptionDataSpace"
có
chứa
một

cấu
trúc
DataSpaceDefinition.
- Cấu trúc DataSpaceDefinition phải có chính xác một đầu vào
TransformReferenceslà "StrongEncryptionTransform".
2.2.4.3. Kho \0x06DataSpaces\TransformInfo
Kho
\0x06DataSpaces\TransformInfo
phải
chứa
một
kho
"StrongEncryptionTransform". Kho "StrongEncryptionTransform" phải chứa một
luồng "0x06Primary". Luồng “0x06Primary” phải chứa một cấu trúc
IRMDSTransformInfo. Cùng với cấu trúc IRMDSTransformInfo, các giá trị sau
phải được thiết lập:
- TransformInfoHeader.TransformType phải là: 0x00000001.
- TransformInfoHeader.TransformID phải là: "{FF9A3F03-56Ef4613-BĐ5-5A41C1S07246}".
- TransformInfoHeader.TransformName phải là:
"Microsoft.Container.EncryptionTransform".
- TransformInfoHeader.ReaderVersion phải là: "1.0".
- TransformInfoHeader.UpdaterVersion phải là: "1.0".
- TransformInfoHeader.WriterVersion phải là: "1.0".
22


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD


Theo
cấu
trúc
IRMDSTransformInfo,
một
cấu
trúc
EncryptionTransformInfo phải tồn tại để chỉ định các thuật toán mã hóa được
dùng. Tuy nhiên, nếu các thuật toán được chỉ định trong cấu trúc
EncryptionTransformInfo khác với các thuật toán được chỉ định trong luồng
EncryptionInfo thì luồng EncryptionInfo phải được xem xét kỹ lưỡng. Nếu
phương thức mã hóa nhanh được dùng thì trường EncryptionName của cấu trúc
EncryptionTransformInfo phải là một chuỗi ký tự null (0x00000000).
2.2.4.4. Luồng \EncryptedPackage
Luồng \EncryptedPackage là một luồng được mã hóa của các byte chứa
toàn bộ file nguồn ECMA-376 trong dạng đã nén.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
StreamSize
…
EncryptedData (biến)
…

Hình 2.6. Luồng \EncryptedPackage

StreamSzie (8 byte): Số nguyên không dấu chỉ định số các byte được dùng
bởi dữ liệu được mã hóa cùng với trường EncryptedData, không bao gồm kích
thước của trường StreamSize. Lưu ý rằng kích thước chính xác của luồng
\EncryptedPackage có thể lớn hơn giá trị này, phụ thuộc vào kích thước block của
thuật toán mã hóa được chọn.
EncryptedData (biến): Một block dữ liệu được mã hóa bằng cách dùng

thuật toán đã chỉ định cùng với luồng \EncryptedInfo.
2.2.4.5. Luồng \EncryptionInfo (Mã hóa chuẩn)
Luồng \EncryptionInfo chứa thông tin chi tiết đã được dùng để khởi chạy
lệnh mã hóa luồng \EncrypedPackage khi mã hóa chuẩn được sử dụng.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
EncryptionVersionInfo
EncryptionHeader.Flags
EncryptionHeaderSize
EncryptionHeader (biến)
…
EncryptionVerifier (biến)

Hình 2.7. Luồng \EncryptionInfo

EncryptionVersionInfo (4 byte): Cấu trúc VersionvớiVersion.vMajor phải
là 0x0002, 0x0003 hoặc 0x0004, và Version.vMinor phải là 0x0002.
23


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

EncryptionHeader.Flags (4 byte): Bản sao của Flags được lưu trong trường
EncryptionHeader của cấu trúc này.
EncryptionHeaderSize (4 byte): Số nguyên không dấu chỉ định kích thước,
bằng byte, của trường EncryptionHeader của cấu trúc này.
EncryptionHeader (biến): Cấu trúc EncryptionHeader chỉ định các tham
số được dùng để mã hóa dữ liệu. Giá trị phải được thiết lập như trong bảng 2.6 sau.
Trường


Giá trị

Flags

Các bit fCryptoAPI và fAES phải được thiết lập. Bit fDocProps là 0.

SizeExtra

Giá trị này phải là 0x00000000.

AlgID

Giá trị này phải là 0x0000660E (AES-128), là 0x0000660F (AES-192),
hoặc là 0x00006610 (AES-256).

AlgIDHash

Giá trị này phải là 0x00008004 (SHA-1).

KeySize

Giá trị này phải là 0x00000080 (AES-128), là 0x000000C0 (AES-192),
hoặc là 0x00000100 (AES-256).

ProviderType

Giá trị này là 0x00000018 (AES)

Reserved1


Giá trị này chưa định nghĩa và được bỏ qua.

Reserved2

Giá trị này phải là 0x00000000 và được bỏ qua.

CSPName

Giá trị này được thiết lập hoặc là “Microsoft Enhanced RSA and AES
Cryptographic Provider” hoặc là “Microsoft Enhanced RSA and AES
Cryptographic Provider (Prototype)” như một chuỗi Unicode tận cùng
là null.

Bảng 2.6. Bảng giá trị các trường của EncryptionHeader (mã hóa chuẩn)

EncryptionVerifier (biến): Một cấu trúc EncryptionVerifier được sinh.
2.2.4.6. Luồng \EncryptionInfo (Mã hóa mở rộng)
Các văn bản ECMA-376 có thể sử dụng tùy ý các mô đun mã hóa tùy biến
(có thể mở rộng) do người dùng cung cấp. Khi mã hóa mở rộng được sử dụng,
luồng \EncryptionInfo phải chứa cấu trúc được mô tả trong hình 2.8 sau.
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1
EncryptionVersionInfo
EncryptionHeader.Flags
EncryptionHeaderSize
EncryptionHeader (biến)
…
EncryptionInfo (biến)
…
EncryptionVerifier (biến)

…

Hình 2.8. Cấu trúc luồng \EncryptionInfo

24


Luận văn Thạc sĩ

THÁM MẬT KHẨU CÁC FILE WORD

EncryptionVersionInfo (4 byte): Cấu trúc VersionvớiVersion.vMajor phải
là 0x0003 hoặc 0x0004 và Version.vMinor phải là 0x0003.
EncryptionHeader.Flags (4 byte): Bản sao của Flags được lưu trong trường
EncryptionHeader của cấu trúc này. Nó phải có bit fExternal được thiết lập là 1.
Tất cả các bit khác của trường này phải là 0.
EncryptionHeaderSize (4 byte): Số nguyên không dấu chỉ định kích thước,
bằng byte, của trường EncryptionHeader của cấu trúc này, bao gồm cả GUID chỉ
định mô đun mã hóa mở rộng.
EncryptionHeader (biến): Cấu trúc EncryptionHeader được dùng để mã
hóa cấu trúc. Giá trị phải được thiết lập như trong bảng 2.7.
Trường

Giá trị

Flags

Giá trị phải có bit fExternal là 1, còn tất cả các bit khác là 0.

SizeExtra


Giá trị phải là 0x00000000.

AlgID

Giá trị phải là 0x00000000.

AlgIDHash

Giá trị phải là 0x00000000.

KeySize

Giá trị phải là 0x00000000.

ProviderType

Giá trị phải là 0x00000000.

Reserved1

Giá trị chưa định nghĩa và được bỏ qua.

Reserved2

Giá trị phải là 0x00000000 và được bỏ qua.

CSPName

Một bộ định danh đơn của mô đun mã hóa.


Bảng 2.7. Bảng giá trị các trường của EncryptionHeader (mã hóa mở rộng)

EncryptionInfo (biến): Một chuỗi ký tự Unicode chỉ định thành tố
EncryptionData. Điểm viết mã Unicode đầu tiên phải là 0xFEFF.
Thành tố XML EncryptionData phải phù hợp với namespace XMLSchema
dưới đây:
<?xml version="1.0" encoding="utf-8"?>
xmlns:xs=" elementFormDefault="qualified">
<xs:element name="EncryptionData">
<xs:complexType>
<xs:sequence>
<xs:element name="EncryptionProvider">
<xs:complexType>
<xs:sequence>
<xs:element name="EncryptionProviderData">
<xs:simpleType>
<xs:restriction base="xs:base64Binary"/>
</xs:simpleType>
</xs:element>
</xs:sequence>
<xs:attribute name="Id" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="\{[0-9A-Fa-f]{8}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}\-[0-9A-Faf]{4}\-[0-9A-Fa-f]{12}\}"/>

25