AES: apa itu, algoritma enkripsi simetris dan di mana diterapkan

Ukuran kunci AES dan tingkat keamanan

AES mendukung tiga ukuran kunci, yang masing-masing sesuai dengan tingkat ketahanan kriptografi tertentu. Pemilihan ukuran kunci memengaruhi keamanan, kinerja, dan persyaratan sumber daya perangkat.

Aturan praktis: di aplikasi seluler, gunakan AES-256 secara default. Perbedaan kinerja antara AES-128 dan AES-256 pada perangkat modern dengan dukungan AES-NI tidak lebih dari 10–15%, tetapi tingkat keamanan menjadi dua kali lipat. Menurut analisis kuantum (Grassl et al., 2016), diperlukan 2^77 operasi kuantum melalui algoritma Grover untuk memecahkan AES-128, dan untuk AES-256 — 2^149, yang membuat AES-256 tahan terhadap serangan kuantum selama 20–30 tahun ke depan. Bahkan AES-128 memberikan perlindungan yang cukup untuk sebagian besar skenario komersial: untuk pencarian lengkap kunci 128-bit diperlukan lebih banyak energi daripada yang ada di alam semesta menurut perkiraan Bruce Schneier. Namun, standar keamanan (GDPR, HIPAA, PCI DSS) sering secara eksplisit mensyaratkan AES-256, oleh karena itu dalam proyek produksi disarankan untuk menggunakan panjang kunci maksimum.

Mode operasi AES

AES sebagai cipher blok mengenkripsi blok berukuran tetap (128 bit). Untuk mengenkripsi data dengan panjang sembarang, digunakan mode operasi (modes of operation). Pemilihan mode sangat memengaruhi keamanan: mode yang salah dapat meniadakan ketahanan AES.

• ECB (Electronic Codebook) — mode paling sederhana dan paling tidak aman. Setiap blok dienkripsi secara independen dengan kunci yang sama. Blok teks biasa yang identik menghasilkan blok ciphertext yang identik, memungkinkan pemulihan struktur data. Dilarang digunakan di semua standar keamanan modern. JANGAN PERNAH menggunakan ECB di aplikasi seluler.
• CBC (Cipher Block Chaining) — setiap blok ciphertext sebelumnya digunakan sebagai vektor inisialisasi (IV) untuk blok berikutnya. Memerlukan IV acak untuk setiap pesan. Rentan terhadap serangan padding oracle jika implementasi tidak tepat. Cocok untuk enkripsi file, tetapi memerlukan MAC (HMAC) untuk memastikan integritas data.
• GCM (Galois/Counter Mode) — mode yang direkomendasikan untuk aplikasi seluler. Menyediakan enkripsi terautentikasi (AEAD): enkripsi + pemeriksaan integritas dalam satu operasi. Menggunakan penghitung untuk menghasilkan aliran kunci dan perkalian di bidang Galois untuk autentikasi. GCM memerlukan nonce unik (12 byte) untuk setiap pesan. Direkomendasikan oleh NIST, digunakan di TLS 1.2/1.3 dan Android Keystore.
• CCM (Counter with CBC-MAC) — mode AEAD alternatif berbasis CTR + CBC-MAC. Lebih lambat dari GCM dan tidak mendukung pemrosesan paralel. Digunakan dalam protokol ZigBee dan 802.11 (Wi-Fi). Untuk aplikasi seluler, GCM lebih disukai.

Untuk proyek seluler, gunakan AES-256-GCM dengan nonce sepanjang 12 byte. GCM memecahkan dua masalah sekaligus: enkripsi data dan verifikasi keaslian, yang mencegah serangan padding oracle dan chosen ciphertext. Android Keystore dan iOS CryptoKit mendukung AES-GCM secara bawaan tanpa perlu mengimplementasikan primitif kriptografi tambahan. Saat bekerja dengan GCM, penting untuk tidak pernah mengulangi nonce dengan kunci yang sama — ini sepenuhnya menghancurkan keamanan enkripsi. Hasilkan nonce acak baru untuk setiap enkripsi dan simpan bersama dengan ciphertext.

Implementasi AES di aplikasi seluler

Mari kita lihat contoh implementasi aman AES-256-GCM di Android menggunakan Jetpack Security. Kode di bawah mendemonstrasikan siklus lengkap: pembuatan kunci AES-256 melalui MasterKey, enkripsi dan dekripsi string dengan data terautentikasi tambahan (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)
}

Fitur kunci dari solusi ini adalah penggunaan AES-256-GCM pada dua tingkat: untuk enkripsi pasangan kunci-nilai (PrefValueEncryptionScheme) dan untuk melindungi nama kunci itu sendiri (PrefKeyEncryptionScheme menggunakan AES-256-SIV, yang tahan terhadap pengulangan nonce). MasterKey dihasilkan menggunakan algoritma AES-256-GCM dan disimpan di Android Keystore, yang dilindungi perangkat keras pada perangkat dengan Trusted Execution Environment. Pada perangkat tanpa dukungan perangkat keras (TEE), kunci dienkripsi melalui Bouncy Castle, yang masih lebih aman daripada penyimpanan di SharedPreferences.

Untuk enkripsi langsung volume data besar (misalnya, gambar atau file), gunakan AES-256-GCM melalui EncryptedFile dari AndroidX Security. Untuk mengekspor kunci (misalnya, untuk cadangan), gunakan enkripsi tambahan dengan kata sandi pengguna melalui PBKDF2 dengan 100000+ iterasi.

AES di iOS melalui CryptoKit

Di iOS, bekerja dengan AES diatur melalui framework CryptoKit (Swift 5.0+). Kunci AES-256 dibuat melalui SymmetricKey(size: .bits256) dan disimpan di Secure Enclave — kriptoprocessor perangkat keras yang terisolasi dari CPU utama dan sistem operasi. CryptoKit menyediakan dua implementasi AES: AES.GCM (direkomendasikan) dan AES.CBC (untuk kompatibilitas mundur dengan format usang). Enkripsi dilakukan melalui metode seal(), yang menerima data, kunci, dan nonce (12 byte), dan mengembalikan AES.GCM.SealedBox — struktur yang berisi ciphertext dan tag autentikasi. Dekripsi — melalui open(). Apple sangat tidak merekomendasikan penggunaan CommonCrypto secara langsung: CryptoKit secara otomatis memilih parameter optimal, melindungi dari serangan side-channel, dan menggunakan akselerasi perangkat keras AES-NI pada prosesor Apple Silicon. Pada perangkat dengan Secure Enclave, kunci tidak pernah meninggalkan modul perangkat keras, yang membuat pencuriannya tidak mungkin bahkan jika aplikasi sepenuhnya dikompromikan. Untuk serialisasi kunci, digunakan metode withUnsafeBytes dengan penyimpanan berikutnya di Keychain melalui SecItemAdd dengan atribut kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.