Mã hóa IoT mới của NIST rất mạnh về toán — nhưng chỉ một bit bị ép sai cũng có thể trở thành cửa tấn công

Ascon-AEAD128 được NIST chọn để bảo vệ những thiết bị không dư dả CPU, RAM hay điện năng: cảm biến IoT, RFID, thiết bị nhúng và nhiều hệ thống nhỏ mà AES không phải lúc nào cũng là lựa chọn thuận tiện nhất. Về mặt mật mã học, Ascon đã trải qua nhiều năm phân tích trước khi trở thành chuẩn NIST SP 800-232 vào tháng 8/2025.

Nhưng một bài báo công bố ngày 25/8/2026 chỉ ra một kiểu rủi ro hoàn toàn khác. Thay vì tìm cách giải bài toán toán học của Ascon, nhóm Yang Gao, Siqi Lu, Qingjun Yuan, Yange Chen và Yongjuan Wang hỏi điều gì xảy ra nếu kẻ tấn công làm phần cứng tính sai — rất ít, nhưng sai theo cách có kiểm soát.

Trong mô hình của họ, chỉ một bit ở đầu ra của một mục trong bảng tra cứu S-box bị lật và lỗi đó tồn tại qua nhiều lần mã hóa. Với một cấu hình triển khai cụ thể, những sai lệch rất nhỏ trong tag xác thực có thể trở thành dấu vết để suy ngược khóa 128 bit. Kết quả đáng chú ý ở đây không phải Ascon “yếu về toán”, mà là khoảng cách giữa an toàn của thuật toán và an toàn của thiết bị thực sự chạy thuật toán đó.

Ascon được NIST chọn vì bài toán của IoT khác máy tính thông thường

NIST chính thức hóa họ Ascon trong SP 800-232 với bốn chức năng gồm Ascon-AEAD128, Ascon-Hash256, Ascon-XOF128 và Ascon-CXOF128. Mục tiêu là cung cấp mật mã đối xứng cho những hệ thống hạn chế tài nguyên, nơi thời gian xử lý, diện tích mạch và mức tiêu thụ năng lượng đều bị siết chặt.

Ascon-AEAD128 vừa mã hóa dữ liệu vừa tạo tag để bên nhận kiểm tra tính xác thực. Bên trong, thuật toán duy trì trạng thái 320 bit và xử lý nó qua nhiều vòng biến đổi. Một thành phần quan trọng là lớp S-box phi tuyến gồm 64 S-box 5 bit hoạt động theo kiểu bit-sliced.

Nhìn từ góc độ mật mã học cổ điển, đây là nơi người thiết kế muốn tạo ra quan hệ đủ phức tạp giữa input, trạng thái và output để không thể suy ngược khóa bằng cách quan sát ciphertext thông thường. Nhưng fault analysis thay đổi luật chơi: kẻ tấn công không còn chấp nhận thiết bị tính đúng rồi cố phá kết quả. Họ cố làm thiết bị tính sai, sau đó so sánh cái sai với cái đúng.

Một bit sai có thể nói gì về khóa?

Nghiên cứu mới, From one to three: multi-entry persistent fault analysis of Ascon, xem xét một kiến trúc phần cứng kiểu round-unrolled. Trong thiết kế này, các vòng được triển khai bằng những tài nguyên phần cứng riêng để tăng mức song song, còn 64 phép S-box trong từng vòng dùng chung một bảng tra cứu LUT dành cho vòng đó.

Điểm tấn công nằm ở LUT của vòng cuối trong giai đoạn Finalization. Nếu một mục 5 bit của bảng này bị sửa và lỗi vẫn còn sau đó, mọi lần mã hóa đi qua đúng mục bị lỗi sẽ tạo ra một khác biệt có cấu trúc trong tag xác thực.

Mô hình nghiêm ngặt nhất của nhóm chỉ cho phép lật đúng một bit ở đầu ra của mỗi mục LUT bị hỏng. Khi một S-box nhận đúng giá trị kích hoạt mục lỗi, khác biệt truyền qua lớp khuếch tán tuyến tính rồi xuất hiện ở tag. Vì tag của Ascon trong giai đoạn cuối có quan hệ trực tiếp với hai nửa khóa 64 bit, nhiều cặp tag đúng–sai có thể dần tiết lộ các bit khóa.

Trong mô phỏng của bài báo, sau khi đã thiết lập được một cấu hình lỗi hữu ích, mô hình một mục lỗi cần trung bình khoảng 150 truy vấn plaintext để khôi phục đủ khóa 128 bit. Khi hai mục lỗi phân biệt được cùng tồn tại, con số giảm còn khoảng 74; với ba mục trong mô hình LUT-overwrite tổng quát hơn, còn khoảng 49.

Điều đó không có nghĩa bất kỳ bit nào trên chip bị nhiễu một lần là khóa sẽ lập tức lộ. Trong chính mô hình bit-flip của paper, chỉ những lỗi tạo ra mẫu sai khác quan sát được mới hữu ích cho việc khôi phục khóa. Ba bit cao của đầu ra S-box có thể tạo mẫu mà phương pháp này không khai thác được, trong khi hai bit thấp tạo ra các mẫu phân biệt được. Câu “một bit có thể mở cửa tấn công” vì thế phải hiểu là một bit ở đúng vị trí, bị làm sai theo đúng mô hình và tồn tại đủ lâu.

Đây là tấn công vào triển khai, không phải lời giải mới cho Ascon

Sự phân biệt này rất quan trọng. Paper không đưa ra một cryptanalytic break cho phép người ở xa nhìn ciphertext rồi tính ngược khóa của Ascon-AEAD128. Nó giả định kẻ tấn công có khả năng gây lỗi vật lý hoặc lỗi bộ nhớ lên thiết bị.

Fault injection trong thực tế có thể đến từ glitch xung clock hoặc điện áp, xung điện từ, laser, hay các cơ chế gây nhiễu bộ nhớ. Đây là một nhánh nghiên cứu lâu đời trong bảo mật phần cứng. Với thiết bị nhúng hoặc IoT mà kẻ tấn công có thể cầm trực tiếp, đặt probe gần mạch hoặc thao túng nguồn cấp, giả định này không hoàn toàn mang tính lý thuyết.

Thực tế, một nghiên cứu năm 2025 trên ACM Transactions on Embedded Computing Systems đã kiểm chứng một dạng differential fault attack khác trên Ascon bằng ChipWhisperer Lite và clock glitching. Trong bối cảnh nonce bị dùng sai, nhóm nghiên cứu báo cáo có thể khôi phục một nửa khóa 64 bit với khoảng 50 lỗi ngẫu nhiên ở thanh ghi. Đó không phải cùng cuộc tấn công với paper mới, nhưng nó cho thấy fault analysis trên Ascon không chỉ tồn tại trên giấy.

Những điều kiện khiến cuộc tấn công mới khó hơn tiêu đề gợi ý

Paper 2026 tự nêu khá rõ các giả định giới hạn phạm vi kết luận. Trước hết, nó nhắm tới một kiểu triển khai round-unrolled dùng S-box LUT trong vùng nhớ có thể bị sửa. Một triển khai Ascon khác — chẳng hạn S-box được tổng hợp trực tiếp bằng logic tổ hợp thay vì LUT mutable — không đương nhiên có cùng bề mặt tấn công.

Thứ hai, lỗi phải tồn tại ổn định qua nhiều lần mã hóa. Kẻ tấn công cũng cần biết cấu trúc triển khai đủ rõ để ánh xạ vùng LUT bị nhắm tới với giá trị đầu vào S-box tương ứng.

Thứ ba, quy trình trong paper hoạt động dưới nonce-misuse setting và cần các cặp tag tương ứng giữa chạy đúng và chạy lỗi với input phù hợp. Trong một hệ thống tuân thủ nghiêm quy tắc nonce của AEAD, giả định này không tự nhiên có sẵn.

Cuối cùng, mô hình giả định thiết bị không có cơ chế kiểm tra tính toàn vẹn của LUT hoặc phát hiện fault đủ hiệu quả. Nếu phần cứng kiểm tra parity/ECC, nhân đôi phép tính, so sánh kết quả hoặc reset khi phát hiện trạng thái bất thường, đường rò mà nghiên cứu khai thác có thể bị chặn hoặc trở nên đắt hơn nhiều.

Chính tác giả gọi kết quả của mình là một cảnh báo bảo mật có điều kiện ở cấp triển khai, không phải tuyên bố mọi hệ thống dùng Ascon đều bị phá.

Điểm yếu thật sự nằm ở khoảng cách giữa “cipher an toàn” và “chip an toàn”

NIST cũng không coi bảo mật vật lý là chuyện tự động được giải quyết khi chọn một thuật toán tốt. Khi công bố chuẩn lightweight cryptography, cơ quan này lưu ý thiết bị nhỏ thường dễ bị side-channel attack hơn và không có thuật toán nào mặc nhiên miễn nhiễm trước các tấn công vật lý kiểu đó. Ascon được đánh giá là thuận lợi hơn cho những triển khai chống side channel, nhưng “dễ bảo vệ hơn” không đồng nghĩa với “không cần bảo vệ”.

Fault attack đi xa hơn việc nghe lén thời gian xử lý hay điện năng: nó chủ động can thiệp vào phép tính. Vì vậy, bài toán sau khi Ascon trở thành chuẩn không chỉ là các nhà mật mã tiếp tục tìm differential, linear hay algebraic attack mới. Các kỹ sư phần cứng còn phải quyết định S-box được hiện thực ra sao, bộ nhớ nào có thể bị sửa, có kiểm tra lỗi hay không và thiết bị phản ứng thế nào khi phép tính có dấu hiệu bất thường.

Đây cũng là lý do kết quả mới đáng chú ý đối với IoT. Thiết bị nhỏ thường có ngân sách silicon và điện năng rất hạn chế; mỗi lớp bảo vệ bổ sung đều tốn diện tích mạch, độ trễ hoặc năng lượng. Nhưng bỏ chúng đi có thể biến một thuật toán mạnh thành một triển khai dễ quan sát khi bị gây lỗi.

Bước tiếp theo vì thế không phải thay Ascon bằng một cipher khác chỉ vì paper này. Câu hỏi thực tế hơn là những implementation profile nào của Ascon-AEAD128 cần countermeasure bắt buộc, countermeasure nào đủ rẻ cho MCU và ASIC nhỏ, và chúng có còn hiệu quả trước các fault model thực tế hơn hay không. Khi một chuẩn mới bắt đầu đi vào thiết bị thật, đó là lúc mật mã học trên giấy phải gặp kỹ thuật phần cứng ngoài đời.