Chương I.

Cryptographic protocols: basic concepts

0. Abstract (201-203)
- Giao thức: một chuỗi các bước thủ tục, bao gồm 2-3 bên để hoàn thành công việc.

• “Một chuỗi các bước”: từ start → finish, mỗi bước chỉ được thực hiện khi bước trước nó đã xong.
• “bao gồm 2-3 bên”: ít nhất là 2 người cho một giao thức. (không bao giờ là 1 người cả)
• “hoàn thành công việc”: giao thức phải đạt được cái gì đó

→ Giao thức có thể hoàn thành nhưng mà không an toàn (người ngoài phá hoặc một trong các bên không
trung thực).

→ Giao thức an toàn, mật mã sẽ đảm bảo secrecy, authentication, integrity (thông tin không nhập nhằng,
gốc), dishonest people.

- Người tham gia phải: Hiểu rõ giao thức và Đồng ý để tham gia

- Giao thức phải: Không mập mờ (mỗi bước phải định nghĩa, không nhập nhằng)

Mọi trường hợp được tính đến

- Cryptographic protocol: là một protocol

• Bao gồm các thuật toán mật mã

• Hướng tới ngăn ngừa và phát hiện gian lận, nghe trộm xem lén.

1. List of regular players (203-204)

• Alice, Bob: hai người trong giao thức
• Carol bên thứ ba
• Dave bên thứ tư
• Eve Bên nghe lén, xem lén
• Mallory Kẻ tấn công nguy hiểm (sửa, bóp méo thông tin)
• Trent Trọng tài (trusted)
• Walter Người canh gác? (warden)
• Peggy Người chứng minh (prover)
• Victor Người xác minh (verifier)

2. Arbitrated Protocols (giao thức có người phân xử) (204-207)

- Có người thứ ba (trọng tài, luật sư, cơ quan có thẩm quyền...) và hỗ trợ hai người lạ, không có sự tin
tưởng lẫn nhau.

- Tuy nhiên chi phí mời/thuê một người như vậy sẽ là khá đáng kể. Vì vậy arbitrated protocols có thể chia
thành 2 pha giao thức (sub-protocol)

• Non-arbitrated subprotocol (Giao thức con không người phân xử): thực hiện khi các bên muốn
hoàn thiện giao thức.
 • Arbitrated subprotocol (Giao thức con có người phân xử): thực hiện chỉ khi có các trường hợp
tranh chấp
• Người phân xử phải không có quyền lợi liên can đến giao dịch và phải được cả hai tin tưởng

Ví dụ (Adjudicated Protocols):

a. Non-arbitrated protocol (dùng tại mọi thời điểm)

• Alice và Bob thương lượng các điều khoản trong hợp đồng
• Alice ký hợp đồng
• Bob ký hợp đồng

b. Adjudicated protocol (xảy ra khi tranh chấp)

• Alice và Bob ra trước tòa

• Alice và Bob đưa ra bằng chứng
• Tòa xử đúng – sai

Điểm khác biệt giữa người trọng tài và người phân xử (dùng theo ý nghĩa như ở đây) là người phân xử
không phải luôn luôn cần thiết. Nếu có tranh cãi thì mới cần người phân xử, không có tranh cãi thì thôi.

Vì thế trong trường hợp này ta không dùng khái niệm người trọng tài (arbitrator), với ý nghĩa là người phải
trực tiếp tham gia vào protocol, mà sử dụng khái niệm người phân xử (adjudicator): người này không cần
phải có mặt khi Alice và Bob tiến hành giao dịch, mà chỉ được mời đến khi Alice và Bob yêu cầu giải quyết
tranh cãi.

3. Self-Enforcing protocols (giao thức tự xử) (207)

- Là giao thức tốt nhất:

• Giao thức tự biết phải làm gì trong các tình huống

• Không cần trọng tài để hoàn thành giao thức
• Không cần tòa để giải quyết tranh chấp (vì giao thức được xây dựng để không xảy ra tranh chấp)

- Nếu một hoặc các bên cố gian lận, các bên khác sẽ ngay lập tức phát hiện và dừng giao thức.

→ Tuy nhiên không phải có giao thức này trong mọi trường hợp. (kịch bản đẹp nhưng khó xảy ra)

4. Key Exchange with Symmertric Cryptography

*Ý tưởng: Giao thức trao đổi khóa đối xứng.

• Giả sử Alice và Bob đều có khóa riêng với Trent (ví dụ: KDC-Key Distribution Center). Các khóa này
phải sẵn có trước khi giao thức bắt đầu
• A và T phải có KAT (Ví dụ: mã băm password giữa mình và google); B và T phải có KBT

→ A và B cần có khóa phiên KAB (gọi là K) → Cần T tạo ra

Giao thức

(1) A → T {yêu cầu tạo khóa phiên để liên lạc với Bob}
 (2) T → A {𝐾}𝐾𝐴𝑇 || {𝐾}𝐾𝐵𝑇

(3) A có thể giải mã và lấy K ở hộp đầu tiên

(4) A → B {𝐾}𝐾𝐵𝑇

(5) B có thể giải mã và lấy K

(6) Cả A và B đều có khóa phiên K để giao tiếp bảo mật.

*Vấn đề: Tấn công phát lại, replay attack.

- Giao thức trên có một khuyết điểm lớn: các bên không thể XÁC THỰC được lẫn nhau

(B nhận một thông điệp nói là từ A thì B không thể xác minh được có đúng thông điệp do A chuyển trực
tiếp tới hay không hay do một kẻ giả mạo truyền tới. Tương tự với việc A nhận từ T)

→ Vì vậy kẻ tấn công mặc dù chưa thể lấy được thông tin mật mà các bên chuyển cho nhau, nhưng có thể
làm cho các bên chấp nhận và xử lý thông tin cũ (phát lại), dẫn tới xử lý thừa có thể gây thiệt hại nghiêm
trọng.

- Ví dụ:

A → B: {gửi tao 100 triệu}K (E bắt được cái cụm này)

E → B : {gửi tao 100 triệu}K

(tấn công nhiều lần, khiến B tưởng A vẫn đang đòi, gây thiệt hại cho B)

(FROM PĐH) thầy bảo là dữ liệu lớn mà mã bằng khóa công khai thì rất là lâu và không nên dùng

→ Nên dùng khóa đối xứng. @@

5. Key Exchange with Public-Key Cryptography

- Trao đổi khóa công khai

• (1) Alice lấy khóa công khai của Bob từ KDC.

• (2) Alice tạo random session key 𝐾.

Alice → Bob : {𝐾}𝐾𝐵

• (3) Bob giải mã cái kia bằng private key của mình → Bob lấy được khóa phiên K
 • (4) Cả hai bây giờ đều có thể mã hóa cuộc trò chuyện sử dụng khóa phiên K

Nhận xét: (Man in the middle attack)

- Máy trung gian, đường truyền đi qua nó, thằng này nguy hiểm gọi là Mallory (M). M có thể giả dạng Bob
để nói chuyện với Alice, giả dạng Alice để nói chuyện với Bob.

- Nếu không dùng KDC để lấy khóa public của nhau thì mình hay truyền public key cho nhau

1. Alice gửi Bob khóa công khai 𝐾𝐴 của mình. Mallory can thiệp và chặn 𝐾𝐴 , gửi cho B khóa của nó
𝐾𝑀
2. (Tương tự chiều ngược lại)

→ Vậy là từ bây giờ Bob gửi cho Alice, sử dụng “khóa công khai của Alice” (thực chất là của Mallory)
để gửi. (và ngược lại)

→ Mallory giải mã cái đấy, làm gì k biết xong lại mã hóa lại bằng mã công khai của Alice

→ Alice nhận được mà không hề hay biết đã bị đọc trộm, chỉnh sửa gì cả

→ Phải dùng khóa công khai legit có tick xanh.

→ Nhưng mà ai cũng có khóa công khai thì khó, dùng phức tạp nên mọi người thường dùng khóa công
khai tự tạo thôi.

*Interlock protocol (dùng khóa công khai không cần chứng chỉ, chống lại man-in-the-middle attack)

1. Alice gửi khóa công khai cho Bob

2. Bob gửi khóa công khai cho Alice
3. Alice mã hóa message sử dụng khóa công khai của Bob và chỉ gửi nửa message đã mã hóa.
4. Bob mã hóa message sử dụng khóa công khai của Alice và chỉ gửi nửa message đã mã hóa.
5. Alice gửi nửa còn lại cho Bob.
6. Bob ghép lại và giải mã bằng khóa bí mật của Bob. Bob gửi nửa còn lại cho Alice
7. Alice ghép hai nửa lại và giải mã bằng khóa bị mật của mình

• Nếu ở bước (3), Eve nhận được một nửa message từ Alice, giải mã ra sẽ ra đoạn bit vô nghĩa
• Phải nhận cả hai nửa từ Alice xong ghép lại, xong giải mã ra mới có ý nghĩa được

→ Muốn thu được thông điệp gốc đã gửi thì Eve phải chờ nhận được cả 2 nửa mà Alice lần lượt gửi,
tuy nhiên lúc đó (đã là bước 5) đã quá muộn để TÁC ĐỘNG lên cái mà Bob có thể gửi đi ở bước số 4.
6. Authentication
- Bài toán đặt ra: Khi Alice đăng nhập vào hệ thống (ATM…) làm sao để hệ thống biết đó là Alice mà không
phải Eve đang cố gắng giả danh Alice?

→ (Truyền thống) Password có thể giải quyết vấn đề.

- Xác thực sử dụng hàm băm: hệ thống sẽ không cần biết password của Alice mà vẫn phân biệt được pw
hợp lệ hay không.

6.1. Authentication & Key Exchange. (112-114)

- Mục đích: Tạo khóa đối xứng (khóa phiên K)

- Giao thức Needham-schroeder (5 bước)

1. A → T: 𝐴𝑙𝑖𝑐𝑒, 𝐵𝑜𝑏, 𝑅𝐴
2. T → A: {{𝐾, 𝐴𝑙𝑖𝑐𝑒}𝐾𝐵𝑇 , 𝑅𝐴 , 𝐵𝑜𝑏, 𝐾} 𝐾𝐴𝑇
3. Alice giải mã và lấy được khóa phiên K. Alice có thể confirm rằng random number 𝑅𝐴 bằng 𝑅𝐴 mà
đã gửi cho Trent ở bước (1) (Alice xác thực được Trent). Sau đó, Alice gửi Bob

A → B: {𝐾, 𝐴𝑙𝑖𝑐𝑒}𝐾𝐵𝑇

4. Bob nhận được đoạn mã và giải mã, lấy ra khóa phiên K. Bob tạo một số random khác 𝑅𝐵 và gửi
lại cho Alice (mã hóa bằng khóa phiên K) (cái này kiểu challenge Alice)
B → A: {𝑅𝐵 }𝐾
5. Alice giải mã bằng khóa K. Alice tạo ra 𝑅𝐵 − 1 và mã hóa bằng K. Gửi lại cho Bob
A → B: {𝑅𝐵 − 1}𝐾
➔ Bob nhận được và Bob có thể xác thực được Alice.

➔ Giao thức giúp Alice xác thực được Trent, Bob xác thực được Alice.

- (4) (5) để xác thực tránh tấn công phát lại do số random 𝑅𝐵 qua thời gian nó sẽ khác đi, không thể phát
lại được nữa.

(Nếu xác thực được thì sẽ tránh được tấn công phát lại)
7. Secret Spliting
- Chia message ra thành nhiều phần, mỗi phần sẽ không có ý nghĩa nhưng nếu ghép tất cả lại sẽ trở nên
có nghĩa.

- Mỗi người giữ một phần mật khẩu, tất cả cùng gõ mật khẩu một lúc mới mở.

- Ví dụ đơn giản (2 người)

• Trent tạo ra chuỗi bit random R có độ dài = message M.

• Trent tính M xor R = S.
• Trent gửi R cho Alice, S cho Bob.
• Như vậy để tái tạo lại message, Alice với Bob phải gặp nhau và tính R xor S = M.

8. Secret sharing
- Nâng cấp hơn cái Secret Spliting.

- Chia message thành n phần (gọi là shadows hoặc shares) sao cho chỉ cần dùng m phần bất kì đều tái tạo
lại được message (chứ không cần cả n phần như trên).

- Ví dụ:

• Message là một hàm số đa thức bậc 2: 𝑦 = 𝑎𝑥 2 + 𝑏𝑥 + 𝑐.

• Trent đưa 4 nghiệm của đa thức này cho 4 người.
• Như vậy chỉ cần 3 người bất kì trong 4 người này thì sẽ tìm được hàm bậc 2 kia. (tìm a, b, c)

9. Bit Commitment
- Bit Commitment là một cơ chế cho phép một người cam kết với một giá trị đã chọn, trong khi giấu nó
với người khác, và có khả năng tiết lộ giá trị đã cam kết sau này.

→ Các chương trình phải được thiết kế để một bên không thể thay đổi giá trị hoặc tuyên bố sau khi đã
cam kết.

- Ví dụ:

A cá rằng Bồ Đào Nha thắng Hàn Quốc (bit 1)

A → nhà cái Bob: 1

Bob không thể xem bit này, A cũng không thể thay đổi cho đến khi trận đấu kết thúc

(trận đấu kết thúc sau màn trình diễn tuyệt vời của Kim Ri Cha)

Bob xem được 1 và kết luận A thắng hay không….

9.1. Sử dụng mã hóa đối xứng

1. Bob tạo ra một chuỗi R ngẫu nhiên và gửi cho Alice
2. Alice tạo message chứa chuỗi bit muốn commit b và chuỗi R của Bob. Alice mã hóa message với
chìa khóa ngẫu nhiên K và gửi cho Bob 𝐸𝑘 (𝑅, 𝑏).
 → Bob không thể giải mã được message và cũng không biết chuỗi bit là gì. Khi nào đến thời điểm để
Alice hé lộ bit thì giao thức tiếp tục.

3. Alice gửi cho Bob chìa khóa

4. Bob giải mã message để lấy chuỗi bit và kiểm tra chuỗi ngẫu nhiên để xem tính hợp lệ của bit đó.

- Chức năng của chuỗi R:

• Lỡ key rởm ra kết quả sai thì Alice sẽ đánh tráo kết quả (tránh cửa thua, vào cửa thắng)
• Nếu không có R thì Alice có cơ hội làm việc đó
→ Bob dùng R để xác minh xem thực sự Alice có đánh tráo kết quả bên trong hay không.

Bởi vì nếu không có R (hoặc R fix = 20232023 đã bị biết trước)

• Alice sẽ tìm K và K’ sao cho 𝐸𝐾 (𝑅, 0) = 𝐸𝐾′ (𝑅, 1) = 𝑦 và gửi 𝑦 cho Bob
• Khi kết quả trò chơi xác định xong, tùy theo thắng hay thua thì Alice gửi 𝐾 hoặc 𝐾 ′
• Vậy Alice lúc nào cũng thắng

→ Nếu R là Bob random thì Alice vẫn gian lận được nhưng mà sẽ rất mất thời gian (do phải tìm được K
và K’ thỏa mãn mà), cơ hội làm rất nhỏ.

9.2. Sử dụng hàm băm

1. Alice tạo ra hai chuỗi R1 và R2 random.
2. Alice tạo ra message chứa hai chuỗi trên và bit mà mong muốn commit. Sau đó dùng hàm băm
lên message và gửi nó cho Bob cùng với một trong hai chuỗi ban đầu.

Alice → Bob: 𝐻(𝑅1 , 𝑅2 , 𝑏), 𝑅1

Khi đến giờ tiết lộ bit, giao thức tiếp tục:

3. Alice gửi Bob message nguyên gốc ban đầu: Alice → Bob: (𝑅1 , 𝑅2 , 𝑏)
4. Bob thực hiện hàm băm lên nó và so sánh message sau khi băm và 𝑅1 với 𝐻(𝑅1 , 𝑅2 , 𝑏), 𝑅1 . Nếu
giống nhau thì chúng hợp lệ

- Ý nghĩa của R1 và R2:

+) R2 để che giấu giá trị b, Bob không đoán được bit b là gì (0 hay 1 chẳng hạn). (che giấu giá trị b)

Nếu không có R2 thì

Alice → Bob: 𝐻(𝑅1 , 𝑏), 𝑅1

Bob có hàm băm, băm thử (𝑅1 , 0) hoặc (𝑅2 , 0) xem thằng nào trùng với cái kia là đoán ra
được luôn.

+) R1 giúp cho việc Alice không thể đánh tráo bit b được (chống Alice gian lận, bảo vệ nhà cái Bob)

Nếu không có R1 thì chỉ có R2, b

Alice → Bob: 𝐻(𝑅2 , 𝑏)
Alice tìm hai giá trị R2 để 𝐻(𝑅2 , 0) = 𝐻(𝑅2′ , 1). Tùy thuộc kết quả mà sau đó Alice gửi
(𝑅2 , 0) hay (𝑅2′ , 1) , lúc này Bob hash đều ra kết quả giống nhau mà
10. Fair Coin Flips
- Có thể sử dụng giao thức Bit Commitment ở trên.

- Xét coin flipping sử dụng hàm băm: Giả sử Alice và Bob thống nhất hàm băm f.

1. Alice chọn số ngẫu nhiên x và tính y = f(x)

2. Alice gửi y cho Bob
3. Bob đoán x chẵn/lẻ và gửi dự đoán cho Alice
4. Nếu Bob đoán đúng thì đồng xu sẽ ngửa, nếu Bob sai thì đồng xu sẽ sấp. Alice công bố kết quả của
đồng xu và gửi Bob x.
5. Bob có thể confirms y = f(x)