BEAST: Một phương pháp tấn công HTTPS mới (2)

2. CBC – Tấn công Rogaway-Dai

2.1 CBC

Trong định nghĩa của mỗi mã khối (block cipher) đều có một thuật toán mã hóa nhận vào một khối bản rõ (plaintext block) có chiều dài $b$ bit (gọi là chiều dài khối – block size) và một khóa có chiều dài $n$ bit, rồi “nhào trộn” bản rõ và khóa lại với nhau để xuất ra một khối bản mã (ciphertext block) có $b$ bit. Ví dụ như thuật toán mã hóa của mã khối nổi tiếng DES nhận vào một khối bản rõ có chiều dài 64 bit và một khóa có chiều dài 56 bit, rồi xuất ra một khối bản mã có chiều dài 64 bit. Vì lý do an toàn, các mã khối hiện đại thường có $b = 128$ và $n >= 128$ , ví dụ như AES-128, AES-192, AES-256 (con số phía sau là chiều dài khóa; tất cả đều có chiều dài khối là 128 bit). Câu hỏi tự nhiên là mã hóa thế nào nếu bản rõ dài hơn $b$ ? Chẳng hạn như tôi cần phải làm sao nếu muốn dùng AES-128 để mã hóa bài viết này, vốn chắc chắn dài hơn 128 bit?

Để giải quyết vấn đề này, người ta dùng một phương thức hoạt động (mode of operation) của mã khối. Lưu ý rằng cùng một phương thức hoạt động có thể sử dụng cho nhiều mã khối khác nhau và ngược lại. Mỗi phương thức hoạt động sẽ định nghĩa hai thuật toán: mã hóa và giải mã. Các thuật toán này sẽ sử dụng mã khối và một khóa duy nhất để mã hóa/giải mã các khối dữ liệu có chiều dài lớn hơn $b$ . Có nhiều phương thức hoạt động, phổ biến nhất là Electronic Code Book (ECB) và Cipher Block Chaining (CBC). Để mã hóa bằng ECB hay CBC, chúng ta cần phải thực hiện hai bước:

Nếu chiều dài bản rõ không chia hết cho chiều dài khối thì đệm thêm (pad) một số byte vào bản rõ (padding bytes) để tổng chiều dài chia hết cho $b$ . Có nhiều cách đệm, phổ biến nhất là đệm theo chuẩn PKCS #5.

Chia bản rõ ra thành từng khối và mã hóa theo thuật toán quy định trong phương thức hoạt động. Tôi sẽ đi vào chi tiết bước này trong cả hai phương thức ECB và CBC ngay bên dưới.

Điều thú vị là cả hai thao tác này đều đã tạo ra những tấn công rất nghiêm trọng vào các ứng dụng của mã khối trong thực tế. Ví dụ như đối với bước thứ nhất, ở Eurocrypt 2002 Serge Vaudenay đã trình bày tấn công padding oracle, một tấn công chọn bản mã (chosen-ciphertext attack) cho phép kẻ tấn công có thể giải mã bất kỳ bản mã nào, chỉ với một điều kiện là nạn nhân tiết lộ kết quả gỡ đệm trong quá trình giải mã. Sau Vaudenay, đã có rất nhiều nghiên cứu khác về tấn công padding oracle. Tôi và một đồng nghiệp cũng có hai nghiên cứu về đề tài này. Tuy vậy, BEAST không phải là một tấn công padding oracle, nên từ đây về sau chúng ta xem như các bản rõ đều đã được thêm đệm cho phù hợp.

Tôi dùng một số ký hiệu sau đây cho phần còn lại của loạt bài này:

Bản rõ được ký hiệu là $M$ , bản mã là $C$ . Bản rõ được chia ra thành $m$ khối $P_1$ , $P_2$ ,…, $P_m$ . Các khối này sẽ được mã hóa thành $C_1$ , $C_2$ ,…, $C_m$ .

Hàm mã hóa của mã khối là $E_k$ , trong đó $k$ là khóa. Tương ứng, hàm giải mã là $D_k$ .

Viết $X = {X_1}|{X_2}|\cdots|{X_m}$ nghĩa là kết nối các khối $X_i$ lại với nhau để tạo ra khối $X$ .

Vector khởi tạo (initialization vector) được ký hiệu là $IV$ .

Phương thức hoạt động đơn giản nhất là ECB. ECB mã hóa các khối bản rõ độc lập với nhau, cụ thể như sau:

Mã hóa

$\displaystyle \begin{array}{rcl} C_i &=& E_k(P_i), i=1,..,m\\ C &=& C_1|C_2|\cdots|C_m \end{array}$

Giải mã

$\displaystyle \begin{array}{rcl} P_i &=& D_k(C_i), i=1,..,m\\ M &=& P_1|P_2|\cdots|P_m \end{array}$

Phương thức mã hóa độc lập này có một tính chất: các khối bản rõ giống nhau sẽ cho kết quả là các khối bản mã giống nhau. Nói cách khác, so sánh giá trị của $C_i$ và $C_j$ với $i, j$ bất kỳ chúng ta có thể biết được một chút “thông tin” về $P_i$ và $P_j$ . Đây là một tính chất không mong muốn của bất kỳ phương thức hoạt động hay hệ mã nào (bởi vì nó làm cho hệ mã không còn an toàn theo định nghĩa semantic security). Điều thú vị là ECB được chọn là phương thức mặc định trong nhiều thư viện lập trình phổ biến.

Bài tập 1: Quân ta đang ở chiến trường. Mỗi ngày bộ chỉ huy sẽ gửi ra một lệnh cho biết hôm đó quân ta sẽ làm gì. Chỉ có hai lệnh: “TAN CONG” hoặc “PHONG THU”. Do quân địch cũng có thể nghe lén sóng radio, nên để cho an toàn, bộ chỉ huy sử dụng ECB để mã hóa các lệnh trước khi gửi. Tất cả các lệnh đều được mã hóa bằng cùng một khóa duy nhất. Chứng minh rằng ngay trong ngày thứ hai, quân địch đã có thể đoán trước chiến thuật của quân ta.

Bài tập 2: Tìm và liệt kê các thư viện lập trình sử dụng ECB là phương thức hoạt động mặc định. Điểm thưởng: tìm trên Google Code Search các chương trình sử dụng các thư viện này và xem thử có cách nào khai thác điểm yếu của ECB trong các chương trình này hay không.

Vậy làm thế nào để phá vỡ sự độc lập giữa các khối? Làm cho chúng phụ thuộc nhau :-) . Đó cũng là ý tưởng của phương thức CBC. Tên gọi của CBC gợi ý rằng các khối bản mã sẽ được “móc nối” lại với nhau, cụ thể như sau:

Mã hóa

$\displaystyle \begin{array}{rcl} C_0 &=& IV\\ C_i &=& E_k(P_i \oplus C_{i-1}), i=1,..,m\\ C &=& C_0|C_1|C_2|\cdots|C_m \end{array}$

Giải mã

$\displaystyle \begin{array}{rcl} P_i &=& D_k(C_i) \oplus C_{i-1}, i=1,..,m\\ M &=& P_1|P_2|\cdots|P_m \end{array}$

Lưu ý rằng khi mã hóa bằng CBC, chiều dài bản mã tăng thêm một khối. Khối tăng thêm này là $IV$ , dùng để mã hóa khối bản rõ đầu tiên. Trong CBC, $IV$ không cần được giữ bí mật, nhưng với cùng một khóa thì $IV$ phải độc nhất và không dự đoán được.

Bài tập 3: Giả sử bộ chỉ huy ở bài tập 1 chuyển sang sử dụng CBC. Vì thiếu thiết bị tạo số ngẫu nhiên, bộ chỉ huy quyết định chọn một $IV$ cố định và dùng $IV$ này trong tất cả các lần gửi lệnh. Chứng minh rằng quân địch vẫn có thể đoán trước chiến thuật của quân ta ngay trong ngày thứ hai.

CBC được sử dụng ở rất nhiều ứng dụng của mã khối, trong đó có SSL/TLS. Điểm mấu chốt trong việc sử dụng CBC chính là chọn lựa $IV$ đảm bảo hai tiêu chí ở trên. Rất tiếc người thiết kế SSL/TLS làm sai chỗ này. Bài tập 3 gợi ý rằng, để có $IV$ độc nhất thì nên dùng một bộ tạo số ngẫu nhiên (random number generator). Lưu ý là không phải bộ tạo số nào cũng có thể dùng trong mật mã và hầu hết các bộ tạo số ngẫu nhiên đi kèm theo các ngôn ngữ lập trình đều không an toàn. Có lẽ tôi sẽ viết một bài về đề tài này sau. Quay trở lại giá trị $IV$ . Như vậy trong CBC, mỗi lần mã hóa, chúng ta nên chọn một $IV$ ngẫu nhiên. Câu hỏi là: ngẫu nhiên có bao hàm không dự đoán được? Chắc chắn rồi, bởi nếu đã là ngẫu nhiên thì làm sao mà dự đoán được! Tôi nghĩ sự tồn tại của điểm yếu trong SSL/TLS, tấn công Rogaway-Dai và bây giờ là BEAST đều xuất phát từ chỗ này. Cách mà SSL/TLS chọn các $IV$ để mã hóa các bản ghi (record) khiến các $IV$ này ngẫu nhiên, nhưng lại dự đoán được!

Trong SSL/TLS, dữ liệu từ tầng ứng dụng được chia ra thành từng bản ghi dài không quá $2^{14}$ byte, rồi các bản ghi này sẽ được mã hóa dùng CBC. Với bản ghi đầu tiên, SSL/TLS sẽ chọn một $IV$ hoàn toàn ngẫu nhiên từ bộ tạo số ngẫu nhiên. Từ bản ghi thứ hai trở đi, SSL/TLS sẽ chọn khối bản mã cuối cùng của bản ghi trước đó làm $IV$ . Ví dụ như bản ghi thứ nhất có 3 khối $P_1, P_2, P_3$ , mã hóa tạo thành 4 khối $C_0, C_1, C_2, C_3$ , thì $C_3$ sẽ được chọn làm $IV$ cho bản ghi thứ hai. Rồi khối bản mã cuối cùng của bản ghi thứ hai sẽ là $IV$ cho bản ghi thứ ba, v.v. Lưu ý rằng $C_3$ là hoàn toàn ngẫu nhiên, nhưng nếu như chúng ta biết $C_3$ trước khi chọn bản ghi thứ hai thì xem như $IV$ của bản ghi thứ hai là dự đoán được. Nói cách khác, $IV$ không dự đoán được nghĩa là chúng ta không thể biết được giá trị của $IV$ trước khi chọn bản rõ.

Vậy chuyện gì sẽ xảy ra nếu chúng ta dự đoán được $IV$ trước khi chọn bản rõ?

2.2 Tấn công Rogaway-Dai

Wei Dai mô tả như sau tấn công này như sau:

Phil Rogaway observed that CBC mode is not secure against chosen-plaintext attack if the IV is known or can be
predicted by the attacker before he choses his plaintext [1]. Similarly, CBC mode is not secure if the attacker can
observe the last ciphertext block before choosing the next block of plaintext, because the last block of ciphertext
essentially serves as the IV for the rest of the message. 

The attack itself is very simple. Remember that in CBC mode, each plaintext block is XOR'ed with the last ciphertext
block and then encrypted to produce the next ciphertext block. Suppose the attacker suspects that plaintext block
 might be x, and wants to test whether that's the case, he would choose the next plaintext block 
to be . If his guess is correct, then , and so he can confirm his
guess by looking at whether .[...]

[1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt

Như vậy Dai chỉ ra rằng chúng ta có thể dự đoán được (giải mã!) bản rõ đã quan sát nếu chúng ta biết được $IV$ trước khi chọn bản rõ mới trong CBC. Nếu $P_i$ chỉ nhận 100 giá trị, thì rõ ràng chúng ta có thể giải mã được $P_i$ sau khi thực hiện trung bình 50 bước chọn và thử $P_j$ . Giới hạn của Rogaway-Dai nằm ở chỗ trong thực tế miền giá trị của $P_i$ thường rất lớn. Làm sao để giảm miền giá trị của $P_i$ ?

(Phần 3: Tấn công chọn lề)

Xem đầy đủ bài viết tại http://www.procul.org/blog/2011/10/06/beast-2/