AES: ano ito, algorithm ng simetrikong pag-encrypt at kung saan ito ginagamit

Mga laki ng key ng AES at antas ng seguridad

AES ay sumusuporta sa tatlong laki ng key, na ang bawat isa ay tumutugma sa isang tiyak na antas ng cryptographic resistance. Ang pagpili ng laki ng key ay nakakaapekto sa seguridad, pagganap, at mga kinakailangan sa mapagkukunan ng device.

Praktikal na panuntunan: sa mga mobile app, gamitin ang AES-256 bilang default. Ang pagkakaiba sa pagganap sa pagitan ng AES-128 at AES-256 sa mga modernong device na may suporta sa AES-NI ay hindi hihigit sa 10–15%, ngunit ang antas ng seguridad ay dumoble. Ayon sa quantum analysis (Grassl et al., 2016), kailangan ng 2^77 quantum operations sa pamamagitan ng Grover algorithm upang mabasag ang AES-128, at para sa AES-256 — 2^149, na ginagawang lumalaban ang AES-256 sa quantum attacks sa susunod na 20–30 taon. Kahit ang AES-128 ay nagbibigay ng sapat na proteksyon para sa karamihan ng mga komersyal na senaryo: para sa kumpletong paghahanap ng 128-bit key ay kinakailangan ng mas maraming enerhiya kaysa sa umiiral sa uniberso ayon sa pagtatantya ni Bruce Schneier. Gayunpaman, ang mga pamantayan ng seguridad (GDPR, HIPAA, PCI DSS) ay madalas na malinaw na nangangailangan ng AES-256, kaya sa mga production project ay inirerekomenda na gamitin ang maximum na haba ng key.

Mga mode ng operasyon ng AES

AES bilang block cipher ay nag-encrypt ng mga block na may nakapirming laki (128 bit). Para sa pag-encrypt ng data ng arbitraryong haba, ginagamit ang mga mode ng operasyon (modes of operation). Ang pagpili ng mode ay kritikal na nakakaapekto sa seguridad: ang maling mode ay maaaring magpawalang-bisa sa resistensya ng AES.

• ECB (Electronic Codebook) — ang pinakasimple at pinaka-hindi ligtas na mode. Ang bawat block ay independiyenteng na-encrypt na may parehong key. Ang magkaparehong block ng plain text ay nagbibigay ng magkaparehong block ng ciphertext, na nagpapahintulot sa pagbawi ng istraktura ng data. Ipinagbabawal sa lahat ng modernong pamantayan ng seguridad. Huwag KAILANMAN gumamit ng ECB sa mga mobile app.
• CBC (Cipher Block Chaining) — bawat nakaraang ciphertext block ay ginagamit bilang initialization vector (IV) para sa susunod. Nangangailangan ng random IV para sa bawat mensahe. Mahina sa padding oracle attacks kung hindi tama ang implementasyon. Angkop para sa pag-encrypt ng mga file, ngunit nangangailangan ng MAC (HMAC) para sa integridad ng data.
• GCM (Galois/Counter Mode) — ang inirerekomendang mode para sa mga mobile app. Nagbibigay ng authenticated encryption (AEAD): encryption + integrity check sa isang operasyon. Gumagamit ng counter para sa pagbuo ng key stream at multiplication sa Galois field para sa authentication. Ang GCM ay nangangailangan ng natatanging nonce (12 byte) para sa bawat mensahe. Inirerekomenda ng NIST, ginagamit sa TLS 1.2/1.3 at Android Keystore.
• CCM (Counter with CBC-MAC) — isang alternatibong AEAD mode na batay sa CTR + CBC-MAC. Mas mabagal kaysa sa GCM at hindi sumusuporta sa parallel processing. Ginagamit sa mga protocol ng ZigBee at 802.11 (Wi-Fi). Para sa mga mobile app, ang GCM ay mas gusto.

Para sa mga mobile project, gamitin ang AES-256-GCM na may nonce na 12 byte. Nilulutas ng GCM ang dalawang problema nang sabay: pag-encrypt ng data at pag-verify ng pagiging tunay, na pumipigil sa padding oracle at chosen ciphertext attacks. Ang Android Keystore at iOS CryptoKit ay sumusuporta sa AES-GCM out-of-the-box nang hindi kinakailangan magpatupad ng karagdagang cryptographic primitives. Kapag nagtatrabaho sa GCM, mahalagang huwag na huwag ulitin ang nonce na may parehong key — ito ay ganap na sumisira sa seguridad ng pag-encrypt. Gumawa ng bagong random nonce para sa bawat pag-encrypt at itabi ito kasama ng ciphertext.

Pagpapatupad ng AES sa mga mobile app

Tingnan natin ang isang halimbawa ng ligtas na pagpapatupad ng AES-256-GCM sa Android gamit ang Jetpack Security. Ang code sa ibaba ay nagpapakita ng buong cycle: paglikha ng AES-256 key sa pamamagitan ng MasterKey, pag-encrypt at pag-decrypt ng string na may karagdagang authenticated data (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)
}

Ang pangunahing tampok ng solusyong ito ay ang paggamit ng AES-256-GCM sa dalawang antas: para sa pag-encrypt ng mga key-value pairs (PrefValueEncryptionScheme) at para sa pagprotekta sa mga pangalan ng key mismo (PrefKeyEncryptionScheme ay gumagamit ng AES-256-SIV, na lumalaban sa pag-uulit ng nonce). Ang MasterKey ay nabuo gamit ang AES-256-GCM algorithm at nakaimbak sa Android Keystore, na protektado ng hardware sa mga device na may Trusted Execution Environment. Sa mga device na walang hardware support (TEE), ang key ay na-encrypt sa pamamagitan ng Bouncy Castle, na mas ligtas pa rin kaysa sa pag-imbak sa SharedPreferences.

Para sa direktang pag-encrypt ng malalaking volume ng data (halimbawa, mga larawan o file), gamitin ang AES-256-GCM sa pamamagitan ng EncryptedFile mula sa AndroidX Security. Para sa pag-export ng mga key (halimbawa, para sa backup), gamitin ang karagdagang pag-encrypt na may password ng user sa pamamagitan ng PBKDF2 na may 100000+ iterations.

AES sa iOS sa pamamagitan ng CryptoKit

Sa iOS, ang pagtatrabaho sa AES ay inorganisa sa pamamagitan ng CryptoKit framework (Swift 5.0+). Ang AES-256 key ay nilikha sa pamamagitan ng SymmetricKey(size: .bits256) at nakaimbak sa Secure Enclave — isang hardware cryptoprocessor na nakahiwalay mula sa pangunahing CPU at operating system. Ang CryptoKit ay nagbibigay ng dalawang implementasyon ng AES: AES.GCM (inirerekomenda) at AES.CBC (para sa backward compatibility sa mga lumang format). Ang pag-encrypt ay ginagawa sa pamamagitan ng seal() method, na tumatanggap ng data, key, at nonce (12 byte), at nagbabalik ng AES.GCM.SealedBox — isang istraktura na naglalaman ng ciphertext at authentication tag. Ang decryption — sa pamamagitan ng open(). Mahigpit na hindi inirerekomenda ng Apple ang direktang paggamit ng CommonCrypto: awtomatikong pinipili ng CryptoKit ang pinakamainam na parameter, nagpoprotekta laban sa side-channel attacks, at gumagamit ng hardware acceleration ng AES-NI sa mga Apple Silicon processor. Sa mga device na may Secure Enclave, ang mga key ay hindi umaalis sa hardware module, na ginagawang imposible ang pagnanakaw kahit na ganap na nakompromiso ang app. Para sa serialization ng key, ginagamit ang withUnsafeBytes method na may kasunod na pag-imbak sa Keychain sa pamamagitan ng SecItemAdd na may attribute na kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly.