AES: nó là gì, thuật toán mã hóa đối xứng và được áp dụng ở đâu

Kích thước khóa AES và mức bảo mật

AES hỗ trợ ba kích thước khóa, mỗi kích thước tương ứng với một mức độ mạnh mật mã cụ thể. Việc chọn kích thước khóa ảnh hưởng đến bảo mật, hiệu suất và yêu cầu tài nguyên thiết bị.

Quy tắc thực tế: cho ứng dụng di động, sử dụng AES-256 theo mặc định. Sự khác biệt về hiệu suất giữa AES-128 và AES-256 trên các thiết bị hiện đại có hỗ trợ AES-NI không quá 10–15%, nhưng mức bảo mật tăng gấp đôi. Theo phân tích lượng tử (Grassl et al., 2016), việc phá vỡ AES-128 sẽ cần 2^77 thao tác lượng tử thông qua thuật toán Grover, trong khi AES-256 cần 2^149, làm cho AES-256 có khả năng chống lại các cuộc tấn công lượng tử trong 20–30 năm tới. Ngay cả AES-128 cũng cung cấp đủ bảo vệ cho phần lớn các kịch bản thương mại: theo ước tính của Bruce Schneier, việc vét cạn khóa 128 bit sẽ cần nhiều năng lượng hơn tồn tại trong vũ trụ. Tuy nhiên, các tiêu chuẩn bảo mật (GDPR, HIPAA, PCI DSS) thường yêu cầu rõ ràng AES-256, do đó các dự án sản xuất nên sử dụng độ dài khóa tối đa.

Chế độ hoạt động của AES

AES như một mã hóa khối mã hóa các khối có kích thước cố định (128 bit). Để mã hóa dữ liệu có độ dài tùy ý, các chế độ hoạt động được sử dụng. Việc chọn chế độ ảnh hưởng nghiêm trọng đến bảo mật: chế độ sai có thể vô hiệu hóa sức mạnh của AES.

• ECB (Electronic Codebook) — chế độ đơn giản nhất và kém an toàn nhất. Mỗi khối được mã hóa độc lập với cùng một khóa. Các khối văn bản gốc giống hệt nhau tạo ra các khối mã hóa giống hệt nhau, cho phép khôi phục cấu trúc dữ liệu. Bị cấm trong tất cả các tiêu chuẩn bảo mật hiện đại. KHÔNG BAO GIỜ sử dụng ECB trong ứng dụng di động.
• CBC (Cipher Block Chaining) — mỗi khối mã hóa trước đó được sử dụng làm vectơ khởi tạo (IV) cho khối tiếp theo. Yêu cầu IV ngẫu nhiên cho mỗi thông điệp. Dễ bị tấn công padding oracle khi triển khai không đúng. Phù hợp để mã hóa tệp nhưng yêu cầu MAC (HMAC) để đảm bảo tính toàn vẹn dữ liệu.
• GCM (Galois/Counter Mode) — chế độ được khuyến nghị cho ứng dụng di động. Cung cấp mã hóa xác thực (AEAD): mã hóa + xác minh tính toàn vẹn trong một thao tác duy nhất. Sử dụng bộ đếm để tạo luồng khóa và phép nhân trường Galois để xác thực. GCM yêu cầu nonce duy nhất (12 byte) cho mỗi thông điệp. Được NIST khuyến nghị, được sử dụng trong TLS 1.2/1.3 và Android Keystore.
• CCM (Counter with CBC-MAC) — chế độ AEAD thay thế dựa trên CTR + CBC-MAC. Chậm hơn GCM và không hỗ trợ xử lý song song. Được sử dụng trong các giao thức ZigBee và 802.11 (Wi-Fi). Cho ứng dụng di động, GCM được ưu tiên.

Cho các dự án di động, sử dụng AES-256-GCM với nonce 12 byte. GCM giải quyết đồng thời hai vấn đề: mã hóa dữ liệu và xác thực, ngăn chặn các cuộc tấn công padding oracle và chosen ciphertext. Android Keystore và iOS CryptoKit hỗ trợ AES-GCM nguyên bản mà không cần các nguyên hàm mật mã bổ sung. Khi làm việc với GCM, điều quan trọng là không bao giờ sử dụng lại nonce với cùng một khóa — điều này phá hủy hoàn toàn bảo mật mã hóa. Tạo một nonce ngẫu nhiên mới cho mỗi lần mã hóa và lưu trữ nó cùng với bản mã.

Triển khai AES trong ứng dụng di động

Hãy xem xét một ví dụ về triển khai AES-256-GCM an toàn trên Android sử dụng Jetpack Security. Đoạn mã dưới đây minh họa chu trình đầy đủ: tạo khóa AES-256 qua MasterKey, mã hóa và giải mã một chuỗi với dữ liệu xác thực bổ sung (AAD).

import androidx.security.crypto.MasterKey
import androidx.security.crypto.EncryptedSharedPreferences

val masterKey = MasterKey.Builder(context)
    .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)
    .build()

val securePrefs = EncryptedSharedPreferences.create(
    context,
    "secure_prefs",
    masterKey,
    EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
    EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

fun storeSecureData(key: String, value: String) {
    securePrefs.edit().putString(key, value).apply()
}

fun readSecureData(key: String): String? {
    return securePrefs.getString(key, null)
}

Đặc điểm chính của giải pháp này là AES-256-GCM được sử dụng ở hai cấp độ: để mã hóa các cặp khóa-giá trị (PrefValueEncryptionScheme) và để bảo vệ chính tên khóa (PrefKeyEncryptionScheme sử dụng AES-256-SIV, chống lại việc sử dụng lại nonce). MasterKey được tạo bằng thuật toán AES-256-GCM và được lưu trữ trong Android Keystore, được bảo vệ bằng phần cứng trên các thiết bị có Trusted Execution Environment. Trên các thiết bị không có hỗ trợ phần cứng (TEE), khóa được mã hóa qua Bouncy Castle, vẫn an toàn hơn so với lưu trữ trong SharedPreferences.

Để mã hóa trực tiếp khối lượng dữ liệu lớn (ví dụ: hình ảnh hoặc tệp), sử dụng AES-256-GCM qua EncryptedFile từ AndroidX Security. Để xuất khóa (ví dụ: sao lưu), sử dụng mã hóa bổ sung với mật khẩu người dùng qua PBKDF2 với 100000+ vòng lặp.

AES trên iOS qua CryptoKit

Trên iOS, các thao tác AES được tổ chức qua framework CryptoKit (Swift 5.0+). Khóa AES-256 được tạo qua SymmetricKey(size: .bits256) và được lưu trữ trong Secure Enclave — một bộ xử lý mật mã phần cứng cách ly với CPU chính và hệ điều hành. CryptoKit cung cấp hai triển khai AES: AES.GCM (được khuyến nghị) và AES.CBC (để tương thích ngược với các định dạng cũ). Mã hóa được thực hiện qua phương thức seal(), nhận dữ liệu, khóa và nonce (12 byte), và trả về AES.GCM.SealedBox — một cấu trúc chứa bản mã và thẻ xác thực. Giải mã qua open(). Apple đặc biệt khuyến cáo không sử dụng CommonCrypto trực tiếp: CryptoKit tự động chọn các tham số tối ưu, bảo vệ khỏi các cuộc tấn công kênh phụ và sử dụng tăng tốc phần cứng AES-NI trên bộ xử lý Apple Silicon. Trên các thiết bị có Secure Enclave, khóa không bao giờ rời khỏi mô-đun phần cứng, ngăn chặn hành vi trộm cắp ngay cả khi ứng dụng bị xâm phạm hoàn toàn. Để tuần tự hóa khóa, sử dụng phương thức withUnsafeBytes, sau đó lưu trữ trong Keychain qua SecItemAdd với thuộc tính kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.