NIST phát hành dự thảo SP 800-38E Rev.1: kiểm chứng XTS-AES trên thiết bị lưu trữ

NIST CSRC ghi ngày phát hành 03/09/2026, trạng thái Initial Public Draft và hạn góp ý 16/10/2026. Tác giả được liệt kê là Meltem Sönmez Turan (NIST) và Eric Hibbard (Samsung Semiconductor). NIST cho biết bản sửa đổi cập nhật tài liệu tham chiếu sang IEEE Std 1619-2025.

Thông báo NIST mô tả XTS-AES là mode bảo vệ confidentiality cho dữ liệu trên thiết bị lưu trữ dạng block. NIST nói rõ mode này không cung cấp authentication cho dữ liệu hoặc nguồn dữ liệu. Đây là ranh giới quan trọng nhất khi chuyển tài liệu thành yêu cầu kiến trúc và kiểm thử.

Theo trang dự thảo, các thay đổi làm rõ phạm vi sử dụng được phê duyệt, giới hạn data unit và key scope, yêu cầu về key, cùng quy ước thứ tự cho ciphertext stealing. Bản sửa đổi dẫn chiếu IEEE 1619-2025 thay vì sao chép đầy đủ đặc tả; NIST cho biết IEEE cung cấp quyền truy cập tiêu chuẩn trong kỳ góp ý.

Với đội validation, “làm rõ” có thể thay đổi test evidence dù thuật toán cốt lõi không đổi: data-unit boundary, kích thước không chia hết block, key assignment và cách biểu diễn ciphertext stealing phải khớp profile được đánh giá. Không nên chỉ chạy một known-answer vector ở kích thước sector phổ biến. Theo mục 3–4 của dự thảo, các data unit trong một key scope có cùng kích thước, mỗi data unit dài ít nhất 128 bit và không vượt 2^20 block AES 128 bit. Khi thử nhiều kích thước, phải tách thành các instance/profile tương ứng, không tùy ý trộn trong một key scope. XTS-AES ở đây không dành cho mã hóa dữ liệu truyền trên mạng, key wrapping hoặc thay thế authenticated encryption.

Thiết kế cần xác định encryption boundary: controller, drive, volume, filesystem hay application; data-unit number/tweak được dẫn xuất ở đâu; hai AES key được quản lý thế nào; và key scope bao phủ bao nhiêu dữ liệu. Các câu trả lời phải gắn với implementation/version, không suy từ nhãn “AES-XTS”.

Test plan nên có known-answer/interoperability, boundary size, read-after-write, corruption, power-loss, rekey, secure erase và recovery. Bài thử corruption phải minh họa đúng giới hạn: ciphertext bị sửa có thể làm plaintext đổi mà mode không báo lỗi xác thực. Nếu sản phẩm có integrity, bằng chứng phải đến từ lớp/cơ chế khác.

• Nhóm test: Known-answer · Biến chính: key, tweak, data-unit number, length · Bằng chứng: input/output vector · Không được suy diễn: toàn implementation đã an toàn
• Nhóm test: Boundary/CTS · Biến chính: chiều dài cuối data unit · Bằng chứng: ciphertext ordering · Không được suy diễn: mọi kích thước đều tương thích
• Nhóm test: Key scope · Biến chính: lượng dữ liệu/key, rotation · Bằng chứng: key ID + audit log · Không được suy diễn: nhãn XTS tự bảo đảm lifecycle
• Nhóm test: Corruption · Biến chính: bit flip/reorder/replay · Bằng chứng: plaintext + error behavior · Không được suy diễn: XTS cung cấp authentication
• Nhóm test: Power loss/recovery · Biến chính: thời điểm write/rekey · Bằng chứng: journal/log + data check · Không được suy diễn: crash consistency từ cipher mode
• Nhóm test: Performance · Biến chính: queue depth, block size, R/W mix · Bằng chứng: throughput, latency, CPU · Không được suy diễn: benchmark áp dụng cấu hình khác

Nhà sản xuất drive/controller, đội storage firmware, cloud/block storage, appliance mã hóa, phòng lab cryptographic validation và nhóm compliance cần xem dự thảo. Chủ hệ thống dùng full-disk encryption cũng nên rà lại security claim, key lifecycle và cơ chế integrity bổ sung.

Đội mua sắm cần yêu cầu algorithm/mode, module boundary, validation scope, key management, data-unit profile và recovery evidence. Một chứng nhận hoặc tuyên bố “AES” không tự chứng minh sản phẩm đáp ứng revision mới hay bảo vệ khỏi tampering.

Đây là Initial Public Draft nên nội dung có thể thay đổi sau góp ý; chưa được mô tả như yêu cầu cuối hoặc mốc bắt buộc chuyển đổi cho mọi hệ thống. Bản tin cũng không kết luận sản phẩm cụ thể nào compliant, vulnerable hoặc cần thay thế.

SP 800-38E Rev.1 không biến XTS-AES thành cơ chế authenticated encryption. Không thể từ tài liệu suy ra throughput, latency, endurance, resistance trước physical attack hay chất lượng random number/key storage của một thiết bị. Các thuộc tính đó cần test và chuẩn riêng.

• Tải đúng Initial Public Draft ngày 03/09/2026 và theo dõi revision.
• Lập inventory implementation, firmware, library và validation certificate liên quan.
• Ghi encryption boundary, data-unit definition, tweak và key scope.
• Chạy known-answer/interoperability theo profile đã xác định.
• Thử kích thước boundary và ciphertext stealing ordering.
• Thử corruption/replay để xác nhận không gán authentication cho XTS.
• Thử rekey, power loss, recovery và secure erase tách biệt.
• Đo throughput/latency theo block size, queue depth và R/W mix thực.
• Gửi góp ý kỹ thuật trước 16/10/2026 nếu phát hiện điểm chưa rõ.

• XTS-AES: mode dùng AES, thiết kế cho confidentiality của storage dạng block.
• Data unit: đơn vị dữ liệu được mode xử lý với định danh/tweak tương ứng.
• Tweak: giá trị làm biến đổi phép mã hóa theo vị trí data unit/block.
• Ciphertext stealing: xử lý phần dữ liệu cuối không đủ một block.
• Key scope: tập dữ liệu được bảo vệ bởi một XTS-AES key, chia thành các data unit cùng kích thước, mà đối thủ có thể hợp lý tiếp cận; chính sách rotation/lifecycle phải được quản lý riêng.
• Authentication: phát hiện sửa đổi và/hoặc xác minh nguồn; XTS-AES không cung cấp.
• Initial Public Draft: dự thảo ban đầu mở để nhận góp ý, chưa phải final.