Thám mật khẩu các file word

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.. Cấu t

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

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.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

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

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

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

là SHA-2

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

gắn chính sách quản lý bản quyền cho một văn bản

trong các hệ thống mới ngày nay

CHƯƠNG 1- GIỚI THIỆU CHUNG1.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

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 128-bit 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ư

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ố)…

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

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

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

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

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

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 40-bit

- 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:

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

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ở rộng để cho phép sử dụng bất kỳ mô đun mã hóa nào

- Đị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

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

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

dụng trong văn bản

đị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:

- 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

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 376; nếu không thì nó phải là 0 Nếu bit fAES là 1 thì bit fCryptoAPI cũng phải là

ECMA-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

ECMA-376 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

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

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)

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)

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)

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)

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

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

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:

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

"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:

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

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

hoặc là 0x00006610 (AES-256)

hoặc là 0x00000100 (AES-256)

ProviderType Giá trị này là 0x00000018 (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

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

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

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

đun mã hóa mở rộng

dùng bởi mô đun mở rộng

Bảng 2.8 Bảng thể hiện của EncryptionData

EncryptionVerfier (biến): Một cấu trúc EncryptionVerifier được sinh.

2.2.4.7 Luồng \EncryptionInfo (Mã hóa nhanh)

Luồng \EncryptionInfo chứa thông tin chi tiết về mật mã được dùng để mã hóa luồng \EncryptedPackage khi mã hóa nhanh được sử dụng (hình 2.9)

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

Reserved XmlEncryptionDescriptor (biến)

…

Hình 2.9 Cấu trúc luồng \EncryptedPackage

EncryptionVersionInfo (4 byte): Cấu trúc Version với Version.vMajor phải là 0x0004 và Version.vMinor phải là 0x0004

Reserved (4 byte): Giá trị phải là 0x00000040

XmlEncryptionDescriptor (biến): Một thành tố XML phù hợp với

namespace XMLSchema dưới đây:

<xs:attribute name="saltSize" type="ST_SaltSize" use="required" />

<xs:attribute name="blockSize" type="ST_BlockSize" use="required" />

<xs:attribute name="keyBits" type="ST_KeyBits" use="required" />

<xs:attribute name="hashSize" type="ST_HashSize" use="required" />

<xs:attribute name="cipherAlgorithm" type="ST_CipherAlgorithm" use="required" />

<xs:attribute name="cipherChaining" type="ST_CipherChaining" use="required" />

<xs:attribute name="hashAlgorithm" type="ST_HashAlgorithm" use="required" />

<xs:attribute name="saltValue" type="xs:base64Binary" use="required" />

</xs:complexType>

<xs:complexType name="CT_DataIntegrity">

<xs:attribute name="encryptedHmacKey" type="xs:base64Binary" use="required" />

<xs:attribute name="encryptedHmacValue" type="xs:base64Binary" use="required" />

<xs:element name="keyData" type="CT_KeyData" minOccurs="1" maxOccurs="1" />

<xs:element name="dataIntegrity" type="CT_DataIntegrity" minOccurs="0"

SaltSize: Số nguyên không dấu chỉ định số byte được dùng bởi salt Nó ít

nhất phải là 1 và không lớn hơn 65536

BlockSize: Số nguyên không dấuchỉ định số byte được dùng để mã hóa một

block của dữ liệu Nó ít nhất phải là 2, không lớn hơn 4096 và là bội của 2

KeyBits: Số nguyên không dấuchỉ định số các bit được dùng bởi thuật toán

mã hóa Nó ít nhất phải là 8 và là bội của 8

HashSize: Số nguyên không dấuchỉ định số các byte được dùng bởi một giá

trị băm Nó ít nhất phải là 1, không lớn hơn 65536 và cùng số byte với các thuật toán băm

SpinCount: Số nguyên không dấu chỉ định số lần băm của một mật khẩu Nó

không được lớn hơn 10000000

CipherAlgorithm: Chỗi ký tự chỉ định thuật toán mật mã Các giá trị được

định nghĩa trong bảng 2.9

Bảng 2.9 Bảng ký tự chỉ định thuật toán mã hóa

Các giá trị không được định nghĩa vẫn có thể được dùng, và có một sự bổ sung lệnh không qua yêu cầu để hỗ trợ tất cả các giá trị đã được định nghĩa Chuỗi

ký tự ít nhất phải có 1 ký tự

CipherChaining: Chuỗi ký tự chỉ định chế độ móc nối được dùng bởi CipherAlgorithm Nó phải là một trong các giá trị được môt tả như bảng 2.10

ChainingModeCBC Móc nối khối mật mã

ChainingModeCFB Móc nối phản hồi mật mã, với một cửa sổ 8-bit

Bảng 2.10 Bảng giá trị được dùng bởi CipherAlgorithm

HashAlgorithm: Chuỗi ký tự chỉ định thuật toán băm Các giá trị được mô tả

như dưới đây (bảng 2.11)

Bảng 2.11 Bảng ký tự chỉ định thuật toán băm

Các giá trị không được định nghĩa vẫn có thể được dùng, và có một sự bổ sung lệnh không qua yêu cầu để hỗ trợ tất cả các giá trị đã được định nghĩa Chuỗi

ký tự phải có ít nhất một ký tự

KeyData: Một loại phức hệ chỉ định mã hóa được dùng với thành tố này Thuộc tính saltValue là một giá trị nhị phân mã base 64 được sinh ngẫu nhiên Số các byte được yêu cầu để để giải mã thuộc tính saltValue phải bằng giá trị của thuộc tính saltSize

DataIntegrity: Một loại phức hệ chỉ định giá trị được dùng để xác thực dữ

liệu đã mã hóa vượt qua kiểm tra tính toàn vẹn Loại này được tạo ra dựa trên các loại khác đơn giản hơn dưới đây:

KeyEncryptor: Một loại phức hệ chỉ định các tham số được dùng để mã hóa

khóa trung gian, là khóa dùng để thực hiện bước mã hóa văn bản cuối cùng Để đảm bảo có thể mở rộng, các thành tố tùy ý có thể được định nghĩa để mã hóa khóa trung

gian Khóa trung gian phải giống với tất cả các thành tố KeyEncryptor PasswordKeyEncryptor và CertificateKeyEncryptor được định nghĩa ở phần

sau

KeyEncryptors: Chuỗi các thành tố KeyEncryptor Chính xác thành tố KeyEncryptors phải được đưa ra, và thành tố KeyEncryptors phải chứa ít nhất một KeyEncryptor

Encryption: Một loại phức hợp được soạn từ các thành tố chỉ định các thuộc

tính mã hóa dưới đây:

Thành tố KeyEncryptor phải được dùng khi mã hóa các văn bản mã hóa nhanh được bảo vệbằng mật khẩu, hoặc là một PasswordKeyEncryptor hoặc là một CertificateKeyEncryptor Chính xác thì PasswordKeyEncryptor phải được đưa ra Không hoặc nhiều thành tố CertificateKeyEncryptor được chứa cùng thành tố KeyEncryptors PasswordKeyEncryptor được thể hiện như lược đồ sau:

<?xml version="1.0" encoding="utf-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/office/2006/keyEncryptor/passwor d" xmlns="http://schemas.microsoft.com/office/2006/keyEncryptor/password" xmlns:e="http://schemas.microsoft.com/office/2006/encryption"

<xs:attribute name="saltSize" type="e:ST_SaltSize" use="required" />

<xs:attribute name="blockSize" type="e:ST_BlockSize" use="required" />

<xs:attribute name="keyBits" type="e:ST_KeyBits" use="required" />

<xs:attribute name="hashSize" type="e:ST_HashSize" use="required" />

<xs:attribute name="cipherAlgorithm" type="e:ST_CipherAlgorithm" use="required" />

<xs:attribute name="cipherChaining" type="e:ST_CipherChaining" use="required" />

<xs:attribute name="hashAlgorithm" type="e:ST_HashAlgorithm" use="required" />

<xs:attribute name="saltValue" type="xs:base64Binary" use="required" />

<xs:attribute name="spinCount" type="e:ST_SpinCount" use="required" />

<xs:attribute name="encryptedVerifierHashInput" type="xs:base64Binary"

cipherAlgorithm: Một CipherAlgorith chỉ định thuật toán mật mã cho PasswordKeyEncryptor Thuật toán mật mã đã chỉ định phải giống với thuật toán mật mã được chỉ định cho thành tố Encryption.keyData

cipherChaining: Một CipherChaining chỉ định thuật toán băm cho PasswordKeyEncryptor Thuật toán băm đã chỉ định phải giống với thuật toán băm được chỉ định cho thành tố Encryption.keyData

saltValue: Mảng các byte nhị phân mã base 64 chỉ định giá trị salt cho PasswordKeyEncryptor Số các byte được yêu cầu bởi định dạng giải mã của thành tố này phải là saltSize

encryptedKeyValue: Một giá trị mã base 64 chỉ rõ định dạng mã hóa của

khóa trung gian

CertificateKeyEncryptor được thể hiện như sơ lược sau:

<?xml version="1.0" encoding="utf-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/office/2006/keyEncryptor/certifi cate"

xmlns="http://schemas.microsoft.com/office/2006/keyEncryptor/certificate"

<xs:attribute name="encryptedKeyValue" type="xs:base64Binary" use="required" />

<xs:attribute name="X509Certificate" type="xs:base64Binary" use="required" />

<xs:attribute name="certVerifier" type="xs:base64Binary" use="required" />

</xs:complexType>

<xs:element name="encryptedKey" type="CT_CertificateKeyEncryptor" />

</xs:schema>

encryptedKeyValue: Một giá trị mã base 64 chỉ định định dạng mã hóa của

khóa trung gian, cái mà được mã hóa với khóa công khai chứa cùng thuộc tính

X509Certificate

X50Certificate: Một giá trị mã base 64 chỉ rõ chứng nhận X.509 được mã

hóa DER dùng để mã hóa khóa trung gian Chứng nhận chỉ chứa phần công khai của cặp khóa công khai-cá nhân

certVerifier: Một giá trị mã base 64 chỉ rõ HMAC của dữ liệu nhị phân được thu lại bởi quá trình giải mã base 64 thuộc tính X509Certificate Thuật toán băm

được dùng để chuyển hóa HMAC phải là thuật toán băm được chỉ định cho thành tố

Encryption.keyData Khóa bí mật được dùng để chuyển hóa HMAC phải là khóa

trung gian

Nếu khóa trung gian được thiết lập lại, thì bất kỳ thành tố

CertificateKeyEncryptor nào cũng được thiết lập lại để chứa khóa trung gian mới, ngoại trừ thuộc tính certVerifier phải khớp với giá trị được tính toán sử dụng khóa trung gian hiện tại Nếu một thành tố CertificateKeyEncryptor không có một thuộc tính certVerifier đúng, thì nó phải bị loại bỏ

2.2.4.8 Mã hóa dữ liệu (Mã hóa nhanh)

Luồng EncryptedPackage phải được mã hóa trong các phân đoạn byte 4096

để dễ dàng truy cập gần như ngẫu nhiên trong khi cho phép các chế độ CBC được

sử dụng trong tiến trình mã hóa

Vectơ khởi tạo cho tiến trình mã hóa phải được thu thập bằng cách sử dụng

số phân đoạn cơ bản 0 như một blockKey và dạng nhị phân của KeyData.saltValue Số block phải được xem là một số nguyên dương 32 bit

Các khối dữ liệu phải được mã hóa bằng cách sử dụng vectơ khởi tạo và khóa

trung gian được thu thập bằng cách giải mã encryptedKeyValue từ một KeyEncryptor được chứa cùng chuỗi KeyEncryptors Khối dữ liệu cuối cùng phải được đệm thành bội số nguyên tiếp theo của giá trị KeyData.blockSize Bất kỳ byte

đệm nào cũng có thể được sử dụng Lưu ý rằng trường StreamSize của luồng EncryptedPackage chỉ rõ số các byte của dữ liệu chưa mã hóa

2.2.5 Mã hóa RC4 CryptoAPI Văn bản Office

Các kho và luồng được mã hóa bởi Mã hóa RC4 CryptoAPI Văn bản Office được chỉ rõ cho ứng dụng thích hợp Các tiểu mục dưới đây sẽ trình bày về các cấu trúc và các phương thức sinh khóa được dùng bởi ứng dụng

2.2.5.1 Header của Mã hóa RC4 CryptoAPI

Cấu trúc header sử dụng cho Mã hóa RC4 CryptoAPI được chỉ rõ như trong hình 2.10

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.10 Cấu trúc header của Mã hóa RC4 CryptoAPI

EncryptionVersionInfo (4 byte): Cấu trúc Version chỉ định phiên bản mã

hóa được dùng để tạo văn bản và phiên bản mã hóa được yêu cầu để mở văn bản

Version.vMajor phải là 0x0002, 0x0003 hoặc 0x0004 và Version.vMinor phải là

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 theo như mô tả trong bảng 2.12

lập nếu các thuộc tính của văn bản không được mã hóa

bit 0x00000080, trong gia số của 8 bit Nếu thiết lập thành 0x00000000, nó phải được hiểu như các bit 0x00000028 Nó phải phù hợp với nhà cung cấp dịch vụ mã hóa (CSP) đã chọn

ProviderType Phải là 0x00000001

thuật toán RC4 và SHA-1 với độ dài khóa phù hợp với giá trị trường

KeySize

Bảng 2.12 Báng giá trị các trường của EncyptionHeader (Mã hóa RC4 CryptoAPI)

EncryptionVerifier (biến): Cấu trúc EncryptionVerifier

2.2.5.2 Cấu trúc EncryptedStreamDescriptor RC4 CryptoAPI

Cấu trúc EncryptedStreamDescriptor RC4 CryptoAPI chỉ định thông tin về

các luồng và kho đã mã hóa được chứa cùng một luồng mã hóa giản lược RC4 CryptoAPI Nó được thể hiện như hình 2.11 sau đây:

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

StreamOffset StreamSize

Reserved2 StreamName (biến)

…

Hình 2.11 Cấu trúc EncryptedStreamDescriptor RC4 CryptoAPI

StreamOffset (4 byte): Số nguyên không dấu chỉ định offset, bằng byte,

cùng với luồng sơ lược nơi luồng đã mã hóa được ghi lại

StreamSize (4 byte): Số nguyên không dấu chỉ định kích thước, bằng byte,

của luồng đã mã hóa

Block (2 byte): Số nguyên không dấu chỉ định số của block được dùng để

tìm khóa mã cho luồng đã mã hóa này

NameSize (1 byte): Số nguyên không dấu chỉ định số ký tự được dùng bởi

trường StreamName, không bao gồm ký tự NULL ở tận cùng

A-fStream (1 bit): Giá trị phải là 1 nếu dữ liệu mã hóa là một luồng Nó phải

là 0 nếu dữ liệu mã hóa là một kho

B-Reserved1 (1 bit): Giá trị phải là 0 và được bỏ qua

Unused (6 bit): Giá trị bỏ qua

Reserved2 (4 byte): Giá trị bỏ qua

StreamName (biến): Chuỗi ký tự Unicode tận cùng là null chỉ định tên của

luồng (hoặc kho) được lưu cùng với luồng mã hóa giản lược

2.2.5.3 Luồng mã hóa giản lược RC4 CryptoAPI

Khi Mã hóa RC4 CryptoAPI được sử dụng, một luồng mã hóa giản lược có thể được tạo ra Tên của luồng phải được chỉ rõ bởi ứng dụng Nếu luồng mã hóa

giản lược được đưa ra, thì luồng \0x05DocumentSummaryInformation cũng phải được đưa ra và không chứa thuộc tính nào Luồng \0x05SummaryInformation

không được phép đưa ra

Luồng phải có định dạng như hình 2.12 dưới đây

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

StreamDescriptorArrayOffset StreamDescriptorArraySize EncryptedStreamData (biến)

… EncryptedStreamDescriptorCount EncryptedStreamDescriptorArray (biến)

…

Hình 2.12 Luồng mã hóa giản lược RC4 CryptoAPI

StreamDescriptorArrayOffset (4 byte): Số nguyên không dấu chỉ định

EncryptedStramDescriptorCount được tìm thấy

StreamDescriptorArraySize (4 byte): Số nguyên không dấu chỉ định số các byte được dùng bởi cấu trúc EncryptedStreamDescriptorArray

EncryptedStreamData (biến): Một hoặc nhiều luồng đã mã hóa được lưu

cùng với luồng mã hóa giản lược

EncryptedStreamDescriptorCount (4 byte): Số nguyên không dấu đã mã hóa chỉ định tổng số các cấu trúc EncryptedStreamDescriptor

EncryptedStreamDescriptorArray (biến): Một hoặc nhiều cấu trúc EncryptedStreamDescriptor mà chỉ định các offset và tên của các luồng và các

kho đã mã hóa được chứa cùng với luồng mã hóa giản lược

2.2.6 Mã hóa RC4 Văn bản Office

Mã hóa RC4 Văn bản Office không làm thay đổi các kho và luồng được sử dụng Nếu một luồng được mã hóa thì nó được mã hóa trong vùng thích hợp Các tiểu mục sau chỉ rõ các cấu trúc và phương thức sinh khóa được dùng bởi ứng dụng

Phần header dùng cho Mã hóa RC4 được trình bày rõ trong hình 2.13

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