Nghiên cứu hai hệ mật mã hạng nhẹ giành chiến thắng trong cuộc thi caesar acorn và ascon​

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

KHUẤT QUANG DUY

NGHIÊN CỨU HAI HỆ MẬT MÃ HẠNG NHẸ GIÀNH
CHIẾN THẮNG TRONG CUỘC THI CAESAR
ACORN VÀ ASCON

LUẬN VĂN THẠC SĨ
Ngành: Khoa học máy tính

HÀ NỘI - 2019


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

KHUẤT QUANG DUY

NGHIÊN CỨU HAI HỆ MẬT MÃ HẠNG NHẸ GIÀNH
CHIẾN THẮNG TRONG CUỘC THI CAESAR
ACORN VÀ ASCON

Ngành: Khoa học máy tính
Chuyên ngành: Khoa học máy tính
Mã số: 8480101.01

LUẬN VĂN THẠC SĨ
Ngành: Khoa học máy tính

CÁN BỘ HƯỚNG DẪN
TS. Lê Phê Đô

HÀ NỘI - 2019


i

TĨM TẮT
Tóm tắt: Mật mã có xác thực và mật mã nhẹ đang là những chủ đề nóng trong cộng đồng
mật mã những năm gần đây. Nhu cầu về mật mã nhẹ, có xác thực xuất phát từ sự phát
triển bùng nổ của hệ thống vạn vật kết nối (Internet of Things – IoT), nơi mà rất nhiều
thiết bị nhỏ gọn, năng lực tính tốn thấp và giới hạn về tài nguyên được kết nối với nhau.
Cùng với đó là sự xuất hiện của các lỗ hổng bảo mật trên các giao thức phổ biến hiện nay.
Một số cuộc tấn công thực tế được đưa vào các giao thức (bao gồm SSL/TLS) là do thiếu
xác thực và kiểm tra tính tồn vẹn của dữ liệu. Do đó, cần có những tiêu chuẩn mật mã
mới để đảm bảo được tính xác thực dữ liệu, đồng thời có khả năng thực thi trên những
thiết bị hạn chế về tài nguyên. Cuộc thi CAESAR nhằm kêu gọi cộng đồng mật mã thiết
kế các chương trình mật mã có xác thực mới đã được khởi xướng năm 2013. Trong đó có
rất nhiều ứng viên là các hệ mật mã nhẹ. Luận văn này sẽ tập trung nghiên cứu hai ứng
viên giành chiến thắng ở hạng mục mật mã nhẹ của cuộc thi CAESAR là ACORN và
Ascon. Phân tích, đánh giá các đặc trưng an tồn và hiệu suất của các thuật tốn. Đồng
thời cài đặt thực nghiệm những thuật toán này trên điện thoại thơng minh chạy hệ điều
hành Android.
Từ khóa: mật mã nhẹ, mật mã có xác thực, ACORN, Ascon, CAESAR


ii

LỜI CẢM ƠN

Đầu tiên, tôi muốn gửi lời cảm ơn chân thành nhất tới tiến sĩ Lê Phê Đô, người đã
ln tận tình hướng dẫn tơi nghiên cứu đề tài này. Nếu khơng có sự định hướng, những
lời dạy bảo của thầy thì luận văn này tơi rất khó có thể hồn thiện được.
Tơi xin cảm ơn Khoa cơng nghệ thông tin, Trường Đại học Công nghệ đã tạo điều
kiện, mơi trường thuận lợi cho học viên trong q trình học tập, nghiên cứu và hồn thiện
luận văn thạc sĩ.
Tơi xin bày tỏ lịng kính trọng và biết ơn sâu sắc tới các thầy, cô, bạn bè trong khoa
Công nghệ thơng tin, ngành Khoa học máy tính, đã ln nhiệt tình giúp đỡ tơi trong suốt
q trình học tập và nghiên cứu.
Cuối cùng, tôi muốn gửi lời cảm ơn tới gia đình, người thân, những người ln quan
tâm, động viên để giúp tơi có động lực học tập, nghiên cứu và hoàn thiện đề tài nghiên
cứu này.
Bước đầu đi vào nghiên cứu, tìm hiểu các vấn đề về An tồn thơng tin với kiến thức
cịn hạn chế, do vậy tơi khơng tránh khỏi những thiếu sót trong luận văn này. Tơi rất
mong nhận được những ý kiến đóng góp của các thầy cơ và bạn bè để hồn thiện luận văn
hơn nữa.
Tôi xin chân thành cảm ơn!


iii

LỜI CAM ĐOAN
Tôi xin cam đoan các kết quả trong luận văn này là do tôi thực hiện dưới sự hướng
dẫn của tiến sĩ Lê Phê Đô.
Tất cả các tham khảo từ những nghiên cứu liên quan đều được trích dẫn nguồn gốc
một cách rõ ràng từ danh mục tài liệu tham khảo trong luận văn. Luận văn không sao
chép tài liệu, cơng trình nghiên cứu của người khác mà không chỉ rõ về mặt tài liệu tham
khảo. Các kết quả thực tế của luận văn đều được tiến hành thực nghiệm.
Nếu phát hiện có bất kỳ sự gian lận nào, tơi xin hồn tồn chịu trách nhiệm trước hội
đồng, cũng như kết quả luận văn tốt nghiệp của mình.

Hà Nội,
ngày

thán
nă
m
g
Học viên

,


iv

MỤC LỤC
TÓM TẮT........................................................................................................................... i
LỜI CẢM ƠN.................................................................................................................... ii
LỜI CAM ĐOAN.............................................................................................................iii
MỤC LỤC......................................................................................................................... iv
DANH MỤC HÌNH VẼ.................................................................................................... vi
DANH MỤC BẢNG BIỂU..............................................................................................vii
DANH MỤC VIẾT TẮT................................................................................................. viii
MỞ ĐẦU............................................................................................................................ 1
Chương 1: TỔNG QUAN..................................................................................................3
1.1. Mật mã nhẹ............................................................................................................ 3
1.1.1.

Khái niệm.......................................................................................................3

1.1.2.

Ngun lý thiết kế...........................................................................................3

1.1.3.

Q trình phát triển.........................................................................................5

1.2. Mã hóa có xác thực...............................................................................................6
1.2.1.

Khái niệm.......................................................................................................6

1.2.2.

Ngun lý thiết kế...........................................................................................7

1.2.3.

Q trình phát triển.........................................................................................8

1.3. Cuộc thi CAESAR............................................................................................... 10
Chương 2: HAI HỆ MẬT MÃ HẠNG NHẸ GIÀNH CHIẾN THẮNG TRONG CUỘC
THI CAESAR: ACORN VÀ ASCON.............................................................................. 16
2.1. Hệ mã ACORN.................................................................................................... 16
2.1.1.

Tổng quan về thuật toán................................................................................ 16

2.1.2.

Các đặc trưng an tồn trong thiết kế của thuật tốn...................................... 23

2.1.3.

Một số cuộc tấn công lên hệ mã ACORN..................................................... 26

2.1.4.

Hiệu suất của thuật toán................................................................................ 32

2.2. Hệ mã Ascon....................................................................................................... 32
2.2.1.

Tổng quan về thuật tốn................................................................................ 32

2.2.2.

Các đặc trưng an tồn của thuật tốn............................................................ 40

2.2.3.

Một số cuộc tấn cơng lên hệ mã Ascon......................................................... 44


v
2.2.4.

Hiệu suất của thuật toán................................................................................ 50

Chương 3: CÀI ĐẶT THỰC NGHIỆM TRÊN THIẾT BỊ ANDROID............................53

3.1. Mơ tả bài tốn...................................................................................................... 53
3.2. Cài đặt................................................................................................................. 53
3.2.1.

Mơi trường thực nghiệm............................................................................... 53

3.2.2.

Cài đặt thuật tốn ACORN (v3), Ascon-128 (v1.2) và AES-128-GCM........54

3.2.3.

Ứng dụng truyền dữ liệu đa phương tiện...................................................... 56

3.3. Kết quả và đánh giá............................................................................................. 59
3.3.1.

Thời gian thực thi.......................................................................................... 60

3.3.2.

Kích thước bộ nhớ RAM sử dụng................................................................. 61

3.3.3.

Truyền video trong thời gian thực................................................................. 62

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN........................................................................ 63
TÀI LIỆU THAM KHẢO................................................................................................ 65

vi

DANH MỤC HÌNH VẼ
Hình 1.1: Ngun lý thiết kế của mật mã nhẹ.....................................................................4
Hình 1.2: Số lượng mật mã nhẹ đối xứng tính đến 2017....................................................6
Hình 1.3: Mã hóa có xác thực.............................................................................................7
Hình 1.4: Ngun lý thiết kế mật mã có xác thực...............................................................7
Hình 2.1: Kiến trúc thanh ghi dịch của ACORN [19]....................................................... 16
Hình 2.2: Lược đồ mã hóa của ACORN [20].................................................................... 20
Hình 2.3: Cơ chế hoạt động của Ascon [32]..................................................................... 34
Hình 2.4: Cấu trúc từ thanh ghi trạng thái của Ascon [32]................................................ 37
Hình 2.5: Cấu trúc lớp thay thế của Ascon [32]................................................................ 38
Hình 2.6: Triển khai bitsliced của S-box 5 bit S(x) [32]................................................... 39
Hình 2.7: Lớp khuếch tán tuyến tính của Ascon, trộn các bit trong các từ thông qua hàm
40
∑ ( ) [32]......................................................................................................................................................................................................................................................................................................................

Hình 3.1: Java Native Interface trong Android................................................................. 56
Hình 3.2: Kiến trúc ứng dụng CryptoCamera................................................................... 57
Hình 3.3: Giao tiếp socket thơng qua giao thức UDP....................................................... 58
Hình 3.4: Ứng dụng CryptoTest để đánh giá thời gian thực thi........................................59
Hình 3.5: Ứng dụng CryptoCamera truyền video mã hóa thời gian thực.......................... 60
Hình 3.6: Thời gian thực thi của các thuật tốn................................................................ 61
Hình 3.7: Kích thước bộ nhớ RAM bị chiếm khi thực hiện mã hóa – giải mã..................62


vii

DANH MỤC BẢNG BIỂU

Bảng 1.1: Số lượng ứng viên tham dự CAESAR.............................................................. 11
Bảng 1.2: Các ứng viên bị loại và rút khỏi cuộc thi.......................................................... 11
Bảng 1.3: Một số cuộc tấn công trên các ứng viên của CAESAR.................................... 13
Bảng 2.1: Sự khác nhau giữa ACORN-v1 và ACORN-v2,v3........................................... 19
Bảng 2.2: Một số cuộc tấn công lên hệ mã ACORN......................................................... 26
Bảng 2.3: Tốc độ (cpb) của ACORN với các độ dài bản rõ khác nhau............................. 32
Bảng 2.4: Các tham số cài đặt đề xuất cho Ascon [32]..................................................... 33
Bảng 2.5: Hằng số vòng sử dụng trên các hoán vị pa và pb [32]....................................... 37
Bảng 2.6: S-box 5 bit của Ascon [32]............................................................................... 38
Bảng 2.7: Tuyến bố bảo mật của Ascon [32].................................................................... 40
Bảng 2.8: Đặc trưng vi sai của S-box trong Ascon. [32]................................................... 41
Bảng 2.9: Đặc trưng tuyến tính của S-box trong Ascon [32]............................................ 42
Bảng 2.10: Số lượng S-box hoạt động trong 4 vịng của hốn vị...................................... 44
Bảng 2.11: Vi sai khơng thể trên 5 vịng của Ascon [32].................................................. 44
Bảng 2.12: Một số cuộc tấn công lên Ascon..................................................................... 45
Bảng 2.13: Độ lệch đầu ra x0[i+1] tương ứng với vi sai ở bit đầu vào x3[i] và x4[i] của Sbox [41]............................................................................................................................ 48
Bảng 2.14: Hiệu suất phần mềm (cycles per byte - cpb) trong trường hợp.......................51

Ký hiệu
AES

GCM
IoT


CAESAR

RFID
RAM

PC
NIST


AE
AEAD

MAC
SSL/TLS

IND-CPA

WPA
WEP

Ethernet

OpenVPN


LUTs
GE

UDP

MSB
LSB


1

MỞ ĐẦU
1.

Cơ sở khoa học và tính thực tiễn của đề tài
Trong thời đại phát triển bùng nổ của cuộc cách mạng công nghiệp 4.0, nhu cầu về

kết nối và trao đổi thông tin ngày càng trở nên mạnh mẽ. Đi cùng với đó là yêu cầu về
vấn đề đảm bảo an tồn thơng tin.
Hiện nay, phương pháp chủ yếu được sử dụng để đảm bảo được tính bí mật và an
tồn cho thơng tin là mã hóa dữ liệu. Tuy nhiên, trong nhiều trường hợp, mã hóa đơn
thuần là không đủ mạnh trước các cuộc tấn công phát lại, hay tấn cơng người đứng giữa
(man-in-the-middle). Địi hỏi cần có cơ chế xác thực để chống lại các dạng tấn công này.
Kể từ năm 2017, AES-GCM đã trở thành thuật tốn mã hóa được sử dụng phổ biến với
mục đích đảm bảo đồng thời tính bí mật và tính xác thực cho dữ liệu. Tuy nhiên những lỗ
hổng bảo mật được phát hiện gần đây đã đặt ra yêu cầu định nghĩa một tiêu chuẩn mật mã
có xác thực mới.
Bên cạnh vấn đề về tăng cường bảo mật thông qua các hệ mật mã có xác thực, yêu
cầu về các hệ mật mã nhẹ cũng phản ánh nhu cầu của thời đại. Trong bối cảnh mạng kết
nối vạn vật IoT đang phát triển ngày càng nhanh, không chỉ những thiết bị truyền thống
với khả năng xử lý mạnh mẽ như PC, laptop, điện thoại di động, mà cịn có rất nhiều các
thành phần khác, với khả năng tính tốn và cơ sở phần cứng hạn chế được kết nối vào các
mạng IoT (như các cảm biến, thẻ thông minh, thiết bị y tế, …). Do đó, cần xây dựng
những mật mã có khả năng thực thi trên mơi trường tài nguyên giới hạn trong khi vẫn
đảm bảo được độ an tồn cần thiết.
Mật mã có xác thực và mật mã nhẹ là những chủ đề mới đang thu hút sự quan tâm
của cộng đồng mật mã. Hiện nay, vẫn chưa có những tiêu chuẩn được đặt ra cho các dạng
mật mã này. Các cuộc thi được tổ chức ở thời điểm hiện tại mới chỉ nhằm mục đích thúc
đẩy cộng đồng xây dựng những hệ mật mã mới, lựa chọn ra các mật mã xuất sắc nhất để
tạo tiền đề cho các q trình tiêu chuẩn hóa. Trong bối cảnh đó, luận văn lựa chọn nghiên

cứu về hai hệ mật mã có xác thực hạng nhẹ ACORN và Ascon. Phân tích, đánh giá và cài
đặt thực nghiệm, so sánh với mật mã đang được sử dụng phổ biến hiện nay là AES-GCM.


2
Từ đó, đưa ra những kết quả về tính khả thi cũng như ưu điểm trong việc ứng dụng các hệ
mật mã mới này.
2.

Nội dung nghiên cứu
Nội dung chính của luận văn được trình bày trong 3 chương:
Chương 1: Giới thiệu tổng quan về mật mã nhẹ, mật mã có xác thực (một số khái

niệm, nguyên lý thiết kế, quá trình phát triển) và cuộc thi CAESAR.
Chương 2: Nghiên cứu hai hệ mật mã nhẹ giành chiến thắng trong cuộc thi
CAESAR: ACORN và Ascon. Trình bày tổng quan thuật tốn. Đánh giá các thuật toán
trên phương diện đặc trưng an toàn và hiệu suất trong cài đặt.
Chương 3: Cài đặt và so sánh hiệu suất của các thuật toán ACORN, Ascon và AESGCM trên điện thoại thông minh chạy hệ điều hành Android. Xây dựng và đánh giá tính
khả thi của ứng dụng truyền video thời gian thực sử dụng các thuật tốn mã hóa nói trên.


3

Chương 1: TỔNG QUAN
1.1. Mật mã nhẹ
1.1.1. Khái niệm
Hiện nay, vẫn chưa có một định nghĩa chính thức nào về mật mã nhẹ được công bố
bởi các hệ thống đánh giá mật mã tiêu chuẩn. Tuy nhiên, trong nhiều nghiên cứu, mật mã
nhẹ có thể được hiểu là những thuật toán và giao thức mật mã được thiết kế để phù hợp
cho việc cài đặt trên các môi trường bị hạn chế về tài nguyên như các thẻ RFID, cảm biến,

thẻ thông minh, các hệ thống nhúng, …
Các đặc trưng của mật mã nhẹ được mô tả trong tiêu chuẩn ISO/IEC 29192 [1].
Theo đó, độ an tồn tối thiểu của mật mã nhẹ là 80 bit. Đặc tính “nhẹ” phụ thuộc vào nền
tảng cài đặt. Đối với triển khai phần cứng, đặc tính này được tính tốn và đo lường thơng
qua diện tích chip và năng lượng tiêu thụ. Đối với triển khai phần mềm, kích thước mã
nguồn, kích thước RAM lại là các tiêu chí đánh giá. Ngồi ra, một số đặc trưng khác như
hiệu suất đối với bản tin ngắn hay độ trễ cũng được sử dụng để đánh giá các mật mã nhẹ.
1.1.2. Nguyên lý thiết kế
Có nhiều cách tiếp cận trong việc tìm kiếm giải pháp để giải quyết các vấn đề cần
đến mật mã nhẹ:
-

Sử dụng các mật mã truyền thống, nếu có thể

-

Điều chỉnh các mật mã truyền thống để thích nghi với các thành phần phần
cứng và những giới hạn của hệ thống với chi phí thấp.

-

Xây dựng, phát triển các giải pháp, thuật toán mới, chuyên dụng trên cả phần
cứng và phần mềm.

Cho đến nay, hầu hết các nghiên cứu đều tập trung vào hướng tiếp cận thứ 3 và đã
đạt được những kết quả tốt. Tuy nhiên việc xây một thuật toán mật mã thực thi được trên
cơ sở phần cứng hạn chế cũng có thể phải đánh đổi bằng độ bảo mật hoặc độ bền tổng thể
suy giảm.
Do đó, để thiết kế được một thuật toán mật mã nhẹ trong khi vẫn đảm bảo mức độ
an toàn cần thiết, người thiết kế phải cân đối giữa 3 tiêu chí: an tồn, hiệu suất và chi phí

(Hình 1.1)


4

256 bit

Kích thước khóa

80 bit

8 vịng

Chi phí

Nối tiếp

Hình 1.1: Ngun lý thiết kế của mật mã nhẹ
Trên thực tế, có thể dễ dàng đạt được hai trong số ba mục tiêu thiết kế. Trong khi
đảm bảo được cả ba mục tiêu lại là một nhiệm vụ khá khó khăn. Ví dụ, có thể thiết kế
được một thuật tốn có độ an toàn và hiệu suất tốt, nhưng để thực thi thuật tốn lại u
cầu phần cứng với diện tích mạch lớn, dẫn đến tăng chi phí.
Một số phương pháp thường được các nhà mật mã học sử dụng để đạt được các mục
tiêu trong thiết kế mật mã nhẹ:
-

Giảm kích thước các tham số chính của thuật tốn: kích thước khối dữ liệu,
kích thước khóa, hay kích thước trạng thái của thuật tốn.

-

Bù đắp sự mất mát khơng mong muốn về độ an tồn do thiết kế của thuật
tốn, dựa trên các nghiên cứu đáng tin cậy đã có. Thơng thường được thực
hiện bởi các chuyển đổi tuyến tính/phi tuyến cơ bản.


-

Lựa chọn những kỹ thuật đơn giản nhưng vẫn đạt hiệu quả tốt, ví dụ như các
bit điều khiển hốn vị (lựa chọn hoán vị phù hợp phụ thuộc vào giá trị của bit
điều khiển), hay các thanh ghi dịch.


5
-

Sử dụng các phép biến đổi (transformations) phù hợp với tài ngun của từng
bộ mã hóa cụ thể (ví dụ: yêu cầu giảm bộ nhớ nhưng phải trả giá bằng tốc độ
mã hóa và ngược lại).

1.1.3. Q trình phát triển
Nhu cầu về mật mã nhẹ xuất phát từ một thực tế rằng mạng lưới kết nối vạn vật
(IoT) ngày càng phát triển mạnh. Số lượng lớn thiết bị được kết nối với nhau đồng nghĩa
với việc những rủi ro về bảo mật sẽ tăng lên. Hơn nữa, không phải chỉ những thiết bị
truyền thống với khả năng xử lý mạnh mẽ như PC, laptop, điện thoại di động, mà còn có
rất nhiều các thành phần khác, với khả năng tính toán và cơ sở phần cứng hạn chế được
kết nối vào các mạng IoT (như các cảm biến, thẻ thông minh, thiết bị y tế, …). Do đó, yêu
cầu đặt ra là cần xây dựng những mật mã có khả năng thực thi trên môi trường tài nguyên
giới hạn trong khi vẫn đảm bảo được được độ an toàn cần thiết.
Nghiên cứu về mật mã nhẹ trở nên phát triển từ năm 2004 với dự án đầu tiên được

chọn làm chủ đề cho Chương trình Khung (Framework Programmes) lần thứ 6 và 7 của
Liên minh Châu Âu. Quá trình tiêu chuẩn hóa vẫn đang được hồn thiện, bao gồm tiêu
chuẩn ISO/IEC 29192, trong đó định nghĩa các thuật tốn mật mã nhẹ cho từng lĩnh vực
kỹ thuật và ISO/IEC 29167, mô tả công nghệ mật mã nhẹ cho các thiết bị nhận dạng tần
số vô tuyến (RFID). Viện Tiêu chuẩn và Kĩ thuật Quốc gia (NIST) Hoa Kỳ cũng đã tổ
chức những hội thảo về mật mã nhẹ từ năm 2015 và chính thức phát động chương trình
“Lightweight Cryptography” để thu hút, đánh giá và chuẩn hóa mật mã nhẹ vào năm 2017
[2].
Trong vòng 25 năm qua, đặc biệt từ năm 2011, rất nhiều thuật tốn mã hóa theo
khuynh hướng “nhẹ” đã ra đời. Dưới đây là thống kê số lượng mật mã nhẹ đối xứng tính
đến năm 2017 (Hình 1.2) [3]


6

Hình 1.2: Số lượng mật mã nhẹ đối xứng tính đến 2017
Tháng 4/2019, NIST đã công bố danh sách 56 thành viên (trên tổng số 57 yêu cầu
được gửi đến) cho vòng đầu tiên của dự án “Lightweight Cryptography” [2]. Chương
trình hứa hẹn sẽ tìm ra được những ứng viên chiến thắng, trở thành tiêu chuẩn mật mã nhẹ
và được sử dụng rộng rãi trên toàn bộ thị trường.
1.2. Mã hóa có xác thực
1.2.1. Khái niệm
Cũng tương tự như mật mã nhẹ, mã hóa có xác thực đang là một hướng đi mới trong
cộng đồng mật mã hiện nay. Trong các nghiên cứu được cơng bố, nhìn chung mã hóa có
xác thực (AE – Authenticated Encryption) có thể được hiểu là một hình thức mã hóa đảm
bảo đồng thời tính bảo mật, tính tồn vẹn và tính xác thực của dữ liệu.
Biến thể phổ biến nhất của AE là mã hóa có xác thực với dữ liệu liên kết (AEAD –
Authenticated encryption with associated data). AEAD gắn dữ liệu liên kết (AD) với bản
mã và bối cảnh nơi nó xuất hiện, do đó giúp phát hiện và ngăn chặn những nỗ lực “cắt và
dán” (copy-and-paste) bản mã hợp lệ sang một ngữ cảnh khác.

Bản rõ


Dữ liệu liên kết

Bản mã

Thẻ xác thực

Hình 1.3: Mã hóa có xác thực
1.2.2. Nguyên lý thiết kế
Cách tự nhiên nhất để xây dựng các lược đồ mã hóa xác thực là kết hợp các nguyên
thủy mã hóa hiện có. Phương pháp này được gọi là “generic composition” [4]. Có ba cách
tiếp cận chính, bao gồm: Encrypt-and-MAC, Encrypt-then-MAC và MAC-then-Encrypt.

Bản rõ

Mã hóa

Bản mã

a) EtM

b) E&M
Hình 1.4: Ngun lý thiết kế mật mã có xác thực

c) MtE

8

Encrypt-and-MAC (E&M)
MAC được tạo ra dựa vào bản rõ và bản rõ được mã hóa mà khơng cần MAC. MAC
và bản mã được gửi đi cùng nhau. Cách tiếp cận này được sử dụng trong lớp vận chuyển
(transport layer) của SSH
Encrypt-then-MAC (EtM)
Đầu tiên, bản rõ được mã hóa, sau đó MAC được sinh ra dựa trên bản mã kết quả.
Bản mã và MAC được gửi đi cùng nhau. Cách tiếp cận này được sử dụng trong giao thức
IPsec.
MAC-then-Encrypt (MtE)
MAC được tạo ra dựa vào bản rõ. Sau đó bản rõ và MAC cùng được mã hóa để thu
được bản mã. Bản mã (chứa MAC đã mã hóa) được gửi đi. MtE được sử dụng trong giao
thức SSL/TLS
Thông qua nghiên cứu của mình, Ballare và Namprempre cũng đã chứng minh rằng
mã hóa một bản tin, sau đó áp dụng MAC vào bản mã (EtM) là tối ưu hơn so với hai
phương pháp cịn lại [4].
Ngồi các cách tiếp cận tự nhiên như trên, cũng có nhiều cách khác để xây dựng mật
mã có xác thực. Trong những năm qua , nhiều lược đồ mã hóa xác thực hiệu quả hơn đã
được xây dựng bằng các kỹ thuật khác nhau [5, 6], bao gồm hốn vị khơng sử dụng khóa
(keyless permutations) [7] và mật mã dòng [8]. Những cách tiếp cận mới này đã thay đổi
hiểu biết của các nhà mật mã học về AE từ việc pha trộn các nguyên thủy mật mã sang
xây dựng một một khối thống nhất ngay từ đầu.
1.2.3. Q trình phát triển
Nhu cầu về mã hóa xác thực được hình thành từ việc chúng ta nhận thấy rằng một số
cuộc tấn thực tế được đưa vào các giao thức (bao gồm SSL/TLS) là do thiếu xác thực và
kiểm tra tính tồn vẹn của dữ liệu.
Giao thức Needham-Schroeder được Roger Needham và Michael Schroeder phát
minh vào năm 1978, là một giao thức vận chuyển hướng tới sử dụng trên các mạng khơng
an tồn. Bao gồm giao thức Needham-Schoroeder khóa đối xứng, nhằm mục đích thiết

9
lập khóa phiên giữa hai bên và Needham-Schoroeder khóa cơng khai, nhằm cung cấp xác
thực lẫn nhau giữa hai bên. Giao thức này sử dụng một lược đồ mã hóa với độ an toàn
IND-CPA. Tuy nhiên Denning và Sacco đã thực hiện một cuộc tấn công phát lại (replay
attack) lên giao thức này (1981) [9], chứng minh rằng một lược đồ với độ an tồn INDCPA là khơng đủ mạnh trong nhiều trường hợp.
Giai đoạn 1980-2000, nhiều cuộc tấn công được thực hiện lên các các chế độ hoạt
động của mã hóa khối đã chứng minh tính khơng an tồn chúng. Cuộc tấn công của
Wagner [10] trên một lớp các lược đồ mật mã sử dụng CBC với kiểm tra dư thừa (CBCmode encryption-with-redundancy) cho thấy chế độ hoạt động này khơng an tồn bất kể
hàm kiểm tra (checksum) được tính như thế nào. Năm 2001, nghiên cứu của Jee Hea An
and Mihir Bellare cũng chỉ ra rằng hàm kiểm tra khơng dùng khóa (unkeyed checksum) là
khơng đủ an tồn [11].
Năm 2004, Tom Yu, Sam Hartman và Kenneth Raeburn đã tìm ra nhiều lỗ hổng
trong thiết kế của giao thức Kerberos 4 (một giao thức dùng để xác thực trong các máy
tính hoạt động trên những đường truyền khơng an tồn) [12]. Trong đó chỉ ra rằng, việc
đảm bảo tính toàn vẹn dựa vào chế độ PCBC là hoàn toàn thất bại.
Năm 1999, Virgil D. Gligor và Pompiliu Donescu giới thiệu lược đồ mã hóa PCBC
mới (iaPCBC) với tuyên bố đảm bảo tính bảo mật và tính tồn vẹn của bản tin trước các
cuộc tấn công lựa chọn bản mã thích nghi [13]. Tuy nhiên, iaPCBC đã nhanh chóng bị
phá vỡ bởi Jutla (1999) và Ferguson, Whiting, Kelsey, Wagner (1999)
Từ trước năm 2000, hầu hết nỗ lực xây dựng mã hóa có xác thực đều dựa trên những
mật mã đã có, cố gắng kết hợp chúng nhằm giảm chi phí, và đều đem lại kết quả khơng
tốt. Nó cũng cho thấy một khoảng cách lớn trong nhận thức về AE giữa những người làm
lý thuyết và thực tế. Cho đến năm 2000, Mihir Bellare và Chanathip Namprempre mới có
những nghiên cứu chính thức đầu tiên về AE. Họ đưa ra một số định nghĩa và khái niệm
liên quan. Mở ra một hướng đi mới trong việc xây dựng mật mã có xác thực [4].
Giai đoạn những năm 2000 cũng là thời điểm mà nhu cầu về mã hóa xác thực trở
nên cấp thiết. Năm 1999, WEP trở thành tiêu chuẩn bảo mật IEEE 802.11 cho wi-fi (sử
dụng mã hóa RC4 cùng với hàm kiểm tra toàn vẹn CRC-32). Tuy nhiên, những cuộc tấn

cơng sau đó đã chứng minh WEP khơng đủ tính xác thực và đảm bảo tính riêng tư của


10
bản tin. WEP sau đó đã được đổi thành WPA (sử dụng TKIP), bản dự thảo tiếp theo dựa
trên OCB (R, Bellare, Black, Krovetz 2001). Tuy nhiên để tránh các vấn đề về chính trị và
bằng sáng chế, CCM (Whiting, Housley, Ferguson 2002) đã được phát triển và sử dụng
cho WPA2.
Kể từ năm 2017, “Galois Counter Mode” (GCM) [14, 15] đã trở thành kỹ thuật phổ
biến nhất để chuyển đổi một lược đồ mã hóa thơng thường sang AE. GCM thường được
áp dụng cho AES, và lược đồ AES-GCM được sử dụng trong rất nhiều cài đặt khác nhau,
ví dụ như các giao thức bảo mật cho Ethernet, OpenVPN, và nhiều dịch vụ giao tiếp web
an toàn khác. Số lượng ứng dụng và bối cảnh cần đến mã hóa có xác thực ngày càng tăng,
cũng như những điểm yếu đã xuất hiện trong GCM [16], đã đặt ra yêu cầu định nghĩa một
tiêu chuẩn cho AE. Vì lý do này, cộng động nghiên cứu mật mã quốc tế đã phát động một
cuộc thi trên toàn thế giới để chọn ra danh mục các thuật toán cho AE, mang tên
CAESAR.
1.3. Cuộc thi CAESAR
Cuộc thi CAESAR bắt đầu từ năm 2013 và được đồng sáng lập bởi NIST và Dan
Berstein. Mục tiêu của cuộc thi là kêu gọi cộng đồng mật mã thiết kế các chương trình AE
an tồn mới. Ứng viên chiến thắng dự kiến sẽ cải thiện AES-GCM với độ bảo mật cao
hơn (với hiệu suất tương đương) hoặc nhanh hơn (với độ bảo mật tương đương). 57 đề án
đã được đề xuất ở vòng đầu tiên của cuộc thi [17, 18].
Các kiến trúc cơ sở cho các ứng viên của CAESAR bao gồm: mật mã khối (Block
Cipher), Sponge, mật mã dịng (Stream Cipher), Hốn vị (Permutation), hàm nén
(Compression Function), và các kiến trúc chuyên dụng (Dedicated)


11
Bảng 1.1: Số lượng ứng viên tham dự CAESAR

(POLAWIS không được xem xét vì kiến trúc rất phức tạp của nó)
Ở vịng 1, có 9 ứng viên được xem là không đạt tiêu chuẩn, và rút khỏi cuộc thi

(bảng 1.2).
Bảng 1.2: Các ứng viên bị loại và rút khỏi cuộc thi
STT

Ứng viên

1

AES-COBRA

2

Calico

3

CBEAM

4

FASER
(2 phiên bản


12
128 và 256 bit)

5

HKC

6

Marble

7

McMambo

8

PAES
(2 phiên bản