AES: 개념, 대칭 암호화 알고리즘 및 활용 분야

AES 키 크기 및 보안 수준

AES는 세 가지 키 크기를 지원하며, 각각 특정 암호화 강도 수준에 해당합니다. 키 크기 선택은 보안, 성능 및 장치 리소스 요구 사항에 영향을 미칩니다.

실용적인 규칙: 모바일 애플리케이션에는 기본적으로 AES-256을 사용합니다. AES-NI 지원 최신 기기에서 AES-128과 AES-256의 성능 차이는 10~15%를 넘지 않지만 보안 수준은 두 배가 됩니다. 양자 분석(Grassl et al., 2016)에 따르면 AES-128을 해독하려면 Grover 알고리즘을 통해 2^77의 양자 연산이 필요한 반면, AES-256은 2^149가 필요하여 향후 20~30년간 양자 공격에 저항합니다. AES-128조차도 대다수의 상업적 시나리오에 충분한 보호를 제공합니다: Bruce Schneier의 추정에 따르면 128비트 키의 무차별 대입에는 우주에 존재하는 것보다 더 많은 에너지가 필요합니다. 그러나 보안 표준(GDPR, HIPAA, PCI DSS)은 종종 AES-256을 명시적으로 요구하므로 프로덕션 프로젝트에서는 최대 키 길이를 사용해야 합니다.

AES 작동 모드

AES는 블록 암호로서 고정 크기(128비트) 블록을 암호화합니다. 임의 길이의 데이터를 암호화하려면 작동 모드가 사용됩니다. 모드 선택은 보안에 중요한 영향을 미칩니다: 잘못된 모드는 AES의 강도를 무효화할 수 있습니다.

• ECB(Electronic Codebook) — 가장 간단하고 가장 안전하지 않은 모드. 각 블록은 동일한 키로 독립적으로 암호화됩니다. 동일한 평문 블록이 동일한 암호문 블록을 생성하여 데이터 구조 복구가 가능합니다. 모든 최신 보안 표준에서 금지됩니다. 모바일 애플리케이션에서 ECB를 절대 사용하지 마십시오.
• CBC(Cipher Block Chaining) — 이전 암호문 블록이 다음 블록의 초기화 벡터(IV)로 사용됩니다. 각 메시지에 대해 무작위 IV가 필요합니다. 잘못 구현된 경우 패딩 오라클 공격에 취약합니다. 파일 암호화에 적합하지만 데이터 무결성을 위해 MAC(HMAC)이 필요합니다.
• GCM(Galois/Counter Mode) — 모바일 애플리케이션에 권장되는 모드입니다. 인증된 암호화(AEAD) 제공: 단일 작업으로 암호화 + 무결성 검증. 키 스트림 생성에 카운터를 사용하고 인증에 갈루아 필드 곱셈을 사용합니다. GCM은 각 메시지에 대해 고유한 nonce(12바이트)가 필요합니다. NIST 권장, TLS 1.2/1.3 및 Android Keystore에서 사용됩니다.
• CCM(Counter with CBC-MAC) — CTR + CBC-MAC 기반의 대체 AEAD 모드. GCM보다 느리고 병렬 처리를 지원하지 않습니다. ZigBee 및 802.11(Wi-Fi) 프로토콜에서 사용됩니다. 모바일 애플리케이션의 경우 GCM이 선호됩니다.

모바일 프로젝트에는 12바이트 nonce와 함께 AES-256-GCM을 사용하세요. GCM은 데이터 암호화와 인증이라는 두 가지 문제를 동시에 해결하여 패딩 오라클 및 선택 암호문 공격을 방지합니다. Android Keystore와 iOS CryptoKit은 추가 암호화 기본 요소 없이 AES-GCM을 기본 지원합니다. GCM으로 작업할 때 동일한 키로 nonce를 절대 재사용하지 않는 것이 중요합니다 — 이는 암호화 보안을 완전히 파괴합니다. 각 암호화마다 새 무작위 nonce를 생성하고 암호문과 함께 저장하십시오.

모바일 애플리케이션에서 AES 구현

Jetpack Security를 사용하여 Android에서 안전한 AES-256-GCM 구현의 예를 살펴보겠습니다. 아래 코드는 전체 사이클을 보여줍니다: MasterKey를 통한 AES-256 키 생성, 추가 인증 데이터(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)
}

이 솔루션의 주요 특징은 AES-256-GCM이 두 수준에서 사용된다는 것입니다: 키-값 쌍(PrefValueEncryptionScheme) 암호화와 키 이름 자체 보호(PrefKeyEncryptionScheme은 nonce 재사용에 저항하는 AES-256-SIV 사용). MasterKey는 AES-256-GCM 알고리즘을 사용하여 생성되며 Trusted Execution Environment가 있는 기기에서는 하드웨어로 보호되는 Android Keystore에 저장됩니다. 하드웨어 지원(TEE)이 없는 기기에서는 키가 Bouncy Castle을 통해 암호화되어 SharedPreferences에 저장하는 것보다 여전히 안전합니다.

대량의 데이터(예: 이미지 또는 파일)를 직접 암호화하려면 AndroidX Security의 EncryptedFile을 통해 AES-256-GCM을 사용하세요. 키 내보내기(예: 백업)의 경우 PBKDF2와 100000+ 반복을 사용하여 사용자 비밀번호로 추가 암호화를 사용하세요.

CryptoKit을 통한 iOS에서의 AES

iOS에서 AES 작업은 CryptoKit 프레임워크(Swift 5.0+)를 통해 구성됩니다. AES-256 키는 SymmetricKey(size: .bits256)를 통해 생성되며 Secure Enclave에 저장됩니다 — 메인 CPU 및 운영 체제와 격리된 하드웨어 암호 프로세서입니다. CryptoKit은 두 가지 AES 구현을 제공합니다: AES.GCM(권장) 및 AES.CBC(레거시 형식과의 하위 호환성용). 암호화는 데이터, 키 및 nonce(12바이트)를 받아 암호문과 인증 태그가 포함된 구조체 AES.GCM.SealedBox를 반환하는 seal() 메서드를 통해 수행됩니다. 복호화는 open()을 통해 수행됩니다. Apple은 CommonCrypto를 직접 사용하지 말 것을 강력히 권장합니다: CryptoKit은 자동으로 최적 매개변수를 선택하고, 부채널 공격으로부터 보호하며, Apple Silicon 프로세서에서 AES-NI 하드웨어 가속을 사용합니다. Secure Enclave가 있는 기기에서는 키가 하드웨어 모듈을 절대 떠나지 않아 앱이 완전히 손상되어도 도난을 방지합니다. 키 직렬화를 위해 withUnsafeBytes 메서드를 사용한 다음 kSecAttrAccessible = kSecAttrAccessibleWhenUnlockedThisDeviceOnly 속성으로 SecItemAdd를 통해 Keychain에 저장합니다.