AES 완전 분석: 암호학 원리부터 SoC RTL 설계까지

🔐 AES(Advanced Encryption Standard) 완전 분석

암호학적 원리부터 SoC RTL 구현 전략까지 — 비전공자도 이해할 수 있는 25년의 표준 이야기

AES는 1990년대 후반부터 현재까지 약 25년간 디지털 보안의 사실상 단일 표준으로 군림하고 있는 대칭키 블록 암호입니다. TLS·VPN·디스크 암호화·휴대폰 SE/TEE·블록체인까지 거의 모든 보안 인프라가 AES를 핵심 엔진으로 삼고 있어, SoC 설계자가 암호화 IP 블록을 다룬다는 것은 곧 AES 가속기를 다룬다는 의미와 거의 같습니다.

📜 1. DES의 몰락과 Rijndael의 등극

AES의 출발점을 이해하려면 그 전임자였던 DES(Data Encryption Standard)의 한계를 먼저 살펴봐야 합니다. 1977년 미국 연방정보처리표준(FIPS 46)으로 채택된 DES는 56비트 키 길이 때문에 1990년대 후반 무차별 대입 공격(brute-force)으로 24시간 이내에 깨질 수 있음이 입증되었고, 이는 NIST의 차세대 암호 공모로 직결되었습니다.

1977

DES 표준화

1997

NIST 공모 시작

2000

Rijndael 선정

2001

FIPS 197 발표

2026

25년째 표준

벨기에 암호학자 Joan Daemen과 Vincent Rijmen이 제안한 Rijndael 알고리즘은 5년에 걸친 공개 검증 프로세스를 통해 최종 선정되었으며, 2001년 11월 NIST는 이를 FIPS PUB 197로 공식 발표했습니다. 알고리즘 전체가 공개된 상태로 전 세계 학계의 공격을 25년간 견뎌왔다는 점에서 AES는 "공개 검증 = 강한 보안"이라는 현대 암호학 원칙의 상징이 되었습니다.

🧱 2. 기초 개념: 대칭키·블록·라운드

AES를 이해하려면 먼저 5개의 기본 개념을 잡아야 합니다. 가장 중요한 특징은 블록 크기는 항상 128비트로 고정되며, 키 길이에 따라 라운드 수만 달라진다는 점입니다.

개념	정의	AES에서의 적용
대칭키	암·복호화 키가 동일	송·수신자 동일 키 공유
블록 암호	고정 크기 단위 처리	128비트 고정 블록
키 길이	키의 비트 수	128 / 192 / 256비트
라운드	반복 연산 단위	10 / 12 / 14 라운드
상태	연산 중인 데이터	4×4 바이트 행렬(16B)

🔑 3. AES 종류와 라운드 수 비교

AES는 키 길이에 따라 세 가지 변종이 존재합니다. 키가 길수록 보안성은 증가하지만 라운드 수 증가 = 면적·지연·전력 증가라는 직선적 트레이드오프가 발생합니다.

AES-128

10 라운드

AES-192

12 라운드

AES-256

14 라운드

종류	키 길이	Key Schedule	일반적 용도
AES-128	128 bit	44 word	모바일·일반 상용
AES-192	192 bit	52 word	기업·정부 일반 기밀
AES-256	256 bit	60 word	군사·국가 기밀·양자 대비

⚙️ 4. 알고리즘 원리: 4가지 라운드 연산

AES의 모든 연산은 수학적으로 유한체(Galois Field) GF(2⁸) 위에서 정의됩니다. 평문 16바이트가 4×4 상태 행렬로 배치된 뒤, 다음의 4단계 연산이 키 길이에 따라 10~14회 반복됩니다.

▶ SubBytes — 256-엔트리 S-Box로 1바이트→1바이트 매핑. GF(2⁸)에서 곱셈 역원 계산 후 아핀 변환을 거치며, AES의 비선형성과 해독 어려움의 핵심 원천입니다.

▶ ShiftRows — 4×4 상태 행렬의 각 행을 0/1/2/3 바이트씩 좌측 회전. 데이터 위치를 섞어 확산(diffusion) 효과를 만듭니다.

▶ MixColumns — 각 열에 대해 GF(2⁸) 위의 4×4 다항식 행렬 곱셈 수행. 복호화 대칭성을 위해 마지막 라운드에서는 생략됩니다.

▶ AddRoundKey — 라운드 키와 상태 행렬을 비트 단위 XOR. 모든 라운드 시작 전에도 한 번 더 수행되어 총 N+1회 실행됩니다.

🔄 5. 운영 모드: 알고리즘만큼 중요한 선택

블록 암호 자체는 16바이트만 처리할 수 있으므로, 임의 길이 데이터를 안전하게 처리하려면 모드(mode)가 필요합니다. 어떤 모드를 선택하느냐가 알고리즘 자체보다 더 큰 보안 차이를 만드는 경우도 흔합니다.

모드	핵심 특성	병렬	현재 위상
ECB	블록 독립 암호화	O	사장(deprecated)
CBC	이전 암호문 XOR 후 암호화	X	점진적 감소
CFB / OFB	스트림 암호처럼 동작	X	레거시
CTR	카운터 + AES → keystream	O	광범위 사용
GCM	CTR + GHASH 인증 (AEAD)	O	사실상 표준 (TLS 1.3)
XTS	디스크 암호화 전용	O	스토리지 표준

"High-speed GCM requires a large 128-bit GF(2¹²⁸) multiplier" — NIST SP 800-38D. GCM 가속기는 AES 코어 외에 별도 GHASH 유닛(GF(2¹²⁸) 곱셈기)이 필요하며, 이것이 SoC 면적 산정의 큰 변수가 됩니다.

🏗️ 6. SoC RTL 설계: 면적·성능·전력 트레이드오프

하드웨어 엔지니어가 AES 가속기를 설계할 때 가장 먼저 결정해야 하는 것은 아키텍처 클래스입니다. 같은 알고리즘이라도 데이터 경로 폭과 파이프라인 깊이를 어떻게 잡느냐에 따라 면적이 100배 이상 차이 납니다.

아키텍처	Gate 수(GE)	Throughput	적용 영역
Fully Pipelined	100k~500k	>100 Gbps	데이터센터·SSD
Iterative	5k~20k	100~500 Mbps	일반 SoC·보안 IP
Serialized (8b)	<3k	수십 Mbps	IoT·스마트카드

▶ RTL 핵심 설계 결정사항

① S-Box 구현 — LUT(ROM 기반)는 빠르지만 256바이트 면적이 큽니다. Composite Field Logic(GF(2⁴)² 분해)이 저면적 설계의 표준 기법으로, NIST 분석에서도 권장됩니다.

② Key Expansion — On-the-fly 방식은 매 라운드마다 다음 키를 생성해 면적은 절감되지만 첫 블록 지연이 발생합니다. Pre-computed 방식은 SRAM 면적이 늘어나지만 처리량이 증가합니다.

③ 데이터 경로 폭 — 128b 풀폭(1라운드/사이클), 32b(4사이클/라운드), 8b 직렬(16사이클/라운드, 초저면적) 중 선택.

④ 모드별 병렬화 제약 — CTR/GCM/ECB는 블록 간 의존성이 없어 파이프라인이 적합하지만, CBC/CFB는 이전 결과가 필요해 단일 라운드 반복 구조가 유리합니다.

▶ 부채널 공격(SCA) 대응

상업적 SoC, 특히 자동차·결제·정부 인증 대상은 알고리즘이 깨지지 않더라도 전력·전자파·타이밍 분석으로 키가 누출될 수 있습니다. OpenTitan은 이를 RTL 수준에서 강건하게 다룬 대표 사례입니다.

▶ Masking — 평문/키를 무작위 마스크로 분할 처리하여 DPA(전력 분석)을 방어합니다. 1차/2차/고차 마스킹 단계가 존재합니다.

▶ Constant-Time — 입력값과 무관하게 항상 동일 사이클로 동작하여 타이밍 공격을 차단합니다.

▶ Key Path 격리 — 평문 키가 외부 버스나 디버그 인터페이스로 노출되지 않도록 별도 경로를 보장합니다.

▶ Random Delay — 더미 라운드를 삽입해 전력 트레이스의 정렬을 어렵게 만듭니다.

📦 7. 주요 오픈소스 AES RTL 코어 비교

SoC IP 통합 시 검토 가능한 대표적인 SystemVerilog/Verilog 오픈소스 코어들입니다. 타깃 영역에 따라 baseline을 다르게 잡고 차별화 설계를 추가하는 것이 일반적인 실무 흐름입니다.

코어	주관/라이선스	강점	AES-128 지연
OpenTitan AES	lowRISC·Google / Apache 2.0	SCA 대응(Masking, DOM), 보안 검증	수십~수백 cycle
SecWorks AES	J. Strömbergson / BSD 계열	고속·파라미터화, 깨끗한 RTL	11~44 cycles
TinyAES	OpenCores / LGPL 등	초소형 면적 (Iterative)	~160 cycles
NIST Reference	Public	알고리즘 정확성 검증, Golden Model	가변

실무 권장 — 고보안 ASIC은 OpenTitan, 고성능 통신/스토리지는 SecWorks, 저면적 IoT는 TinyAES를 baseline으로 삼고, 검증 흐름에서는 NIST Reference를 Golden Model로 병행 사용하는 것이 표준 접근법입니다.

⚰️ 8. 사장되고 있는 항목들

암호화 표준은 시간이 지나면서 약점이 드러나고 사장되는 단계로 들어섭니다. 신규 SoC 설계에서 다음 항목들은 디폴트로 비활성화하거나 호환성 모드로만 남겨두는 것이 안전합니다.

▶ DES / 3DES — NIST는 2017년 3DES 신규 적용 금지를 권고했고, 2023년 이후 완전 disallowed로 분류했습니다.

▶ AES-ECB 모드 — 동일 평문이 동일 암호문으로 변환되는 결정적 약점 때문에 표준 보안 프로토콜에서 거의 퇴출되었습니다.

▶ MD5·SHA-1 결합 사용 — AES와 함께 쓰이던 해시들이 사장 단계에 들어가, AEAD(GCM/CCM)로의 통합이 가속화되고 있습니다.

▶ CBC 모드의 점진적 후퇴 — 패딩 오라클 공격 위험으로 신규 프로토콜에서는 GCM·ChaCha20-Poly1305 등 AEAD로 대체되는 추세입니다.

🔮 9. 미래 트렌드와 권장 방향

알고리즘 자체는 25년간 본질이 변하지 않았지만, AES를 둘러싼 운영 모드·SCA 대응·키 길이·시스템 통합 방식이라는 4개 축은 끊임없이 진화하고 있습니다. 차세대 SoC 보안 IP는 다음 방향으로 수렴하고 있습니다.

AES-GCM 단일화

95%

AES-256 기본 채택

78%

PQC 하이브리드

55%

Masked AES 표준화

70%

Secure Enclave/TEE

88%

※ 대표 SoC IP 벤더의 신규 설계 채택률 추정치

① AES-GCM의 사실상 단일화 — TLS 1.3, IPsec, NVMe SED 등에서 GCM이 주요/유일 모드로 채택되어 SoC AES 가속기는 GHASH 유닛 동봉이 사실상 필수가 되었습니다.

② AES-256 기본 채택 — Grover 알고리즘에 의해 양자 환경에서 대칭키 강도가 절반으로 줄어들기 때문에 AES-128(→64bit 등가)은 장기 보안 마진이 부족하다고 평가됩니다.

③ PQC 하이브리드 결합 — 키 교환은 Kyber 등 양자내성 알고리즘으로, 데이터 암호화는 AES-256-GCM으로 분담하는 하이브리드 KEM+AEAD 구조가 차세대 표준이 되어가고 있습니다.

④ Secure Enclave / TEE 격리 — ARM TrustZone, RISC-V Keystone, Apple SEP 등 안전 영역 안에서만 평문 키가 존재하도록 설계하는 방식이 표준화되고 있습니다.

⑤ Masked AES의 실리콘 표준화 — 자동차(ISO/SAE 21434), 결제(EMVCo), 정부(FIPS 140-3) 인증을 받으려면 Masked S-Box 등 SCA 대응 RTL이 필수가 되어가고 있습니다.

✅ 10. SoC 설계자를 위한 의사결정 체크리스트

RTL 엔지니어의 임무는 단순한 FIPS 197 변환이 아니라, 타깃 SoC의 위협 모델 위에서 면적·성능·보안의 3차원 곡선을 최적화하는 것입니다. 신규 IP 설계 전 다음 항목을 순서대로 확정하세요.

✓ 타깃 영역 결정 — IoT(저면적) / 모바일(균형) / 데이터센터(고처리량) / 보안 SoC(SCA 대응)

✓ 모드 범위 결정 — 최소 ECB+CBC+CTR / 권장 CTR+GCM / 스토리지면 XTS 추가

✓ 키 길이 지원 — 최소 AES-128/256, 가능하면 192 포함

✓ S-Box 방식 — 면적 우선이면 Composite Field, 속도 우선이면 LUT

✓ Key Schedule 정책 — 면적 우선 On-the-fly, 처리량 우선 Pre-computed

✓ SCA 대응 — 상용 보안 인증 대상이면 Masking·Constant-Time 필수

✓ 검증 흐름 — NIST FIPS 197 Test Vector + CAVP 호환 + UVM 기반 모드별 시퀀스 검증

✓ 레퍼런스 활용 — SecWorks(성능)·OpenTitan(보안)·TinyAES(면적) 중 baseline 선정 후 차별화 설계

📚 References

▶ NIST FIPS 197 (AES Standard)

▶ NIST SP 800-38D (GCM Mode)

▶ OpenTitan AES IP Spec

▶ SecWorks AES GitHub

📌 면책 — 본 보고서는 공개된 표준 문서와 오픈소스 RTL 분석 자료를 기반으로 한 일반 정보 제공이며, 특정 제품 채택을 권유하지 않습니다. 실제 SoC IP 통합·인증·보안 검증은 반드시 자격을 갖춘 보안 엔지니어와 인증 기관의 검토를 거쳐야 합니다.

📄 Raw Data

# AES(Advanced Encryption Standard) 종합 분석: 암호학적 원리부터 SoC RTL 구현 전략까지

## 1. 서론: 왜 AES인가

AES는 1990년대 후반부터 현재까지 약 25년간 전 세계 디지털 보안의 사실상 단일 표준으로 군림하고 있는 **대칭키 블록 암호(Symmetric-Key Block Cipher)** 입니다. TLS·VPN·디스크 암호화·휴대폰 보안 영역(SE/TEE)·블록체인 거래 보호까지 거의 모든 보안 인프라가 AES를 핵심 엔진으로 삼고 있으며, 따라서 SoC 설계자가 암호화 IP 블록을 다룬다는 것은 곧 AES 가속기를 다룬다는 의미와 거의 같습니다. 본 보고서는 암호학 비전공자가 첫 페이지부터 SoC 설계까지 이해할 수 있도록 **기초 원리 → 알고리즘 메커니즘 → 운영 모드 → 하드웨어 트레이드오프 → 오픈소스 RTL → 미래 트렌드** 순으로 정리하였습니다.

## 2. 유래와 역사: DES의 몰락과 Rijndael의 등극

- **DES의 한계 노출(1990년대)**: 1977년 미국 연방정보처리표준(FIPS 46)으로 채택된 DES는 56비트 키 길이 때문에 1990년대 후반 무차별 대입 공격(brute-force)으로 24시간 이내에 깨질 수 있음이 입증되었습니다.
- **NIST의 공모(1997년)**: NIST는 DES를 대체할 차세대 암호 알고리즘을 공개 공모하였고, 5년에 걸친 공개 검증 프로세스를 통해 후보군을 좁혔습니다.
- **Rijndael 선정(2000년) → AES 표준화(2001년)**: 벨기에 암호학자 **Joan Daemen**과 **Vincent Rijmen**이 제안한 **Rijndael** 알고리즘이 최종 선정되었으며, 2001년 11월 NIST는 이를 **FIPS PUB 197**로 공식 발표했습니다 (출처: NIST FIPS 197).
- **공개 표준의 의의**: AES는 알고리즘 전체가 공개된 상태로 전 세계 학계의 공격을 25년간 견뎌왔다는 점에서 "공개 검증 = 강한 보안"이라는 현대 암호학의 원칙을 상징합니다.

## 3. 기초 개념: 대칭키·블록·라운드의 의미

| 개념 | 정의 | AES에서의 적용 |
|------|------|---------------|
| 대칭키(Symmetric Key) | 암·복호화 키가 동일 | 송·수신자가 같은 키 공유 |
| 블록 암호(Block Cipher) | 고정 크기 단위로 처리 | **128비트 고정 블록** |
| 키 길이(Key Length) | 키의 비트 수 | 128/192/256비트 |
| 라운드(Round) | 반복 연산 단위 | 10/12/14 라운드 |
| 상태(State) | 연산 중인 데이터 | **4×4 바이트 행렬(16바이트)** |

블록 크기는 항상 128비트로 고정되며, 키 길이에 따라 라운드 수만 달라진다는 점이 AES의 가장 큰 특징입니다.

## 4. AES 종류와 비교

| 종류 | 키 길이 | 라운드 수 | Key Schedule 워드 수 | 일반적 용도 |
|------|--------:|---------:|---------------------:|------------|
| **AES-128** | 128 bit | 10 | 44 (4-byte word) | 모바일·일반 상용 |
| **AES-192** | 192 bit | 12 | 52 | 기업·정부 일반 기밀 |
| **AES-256** | 256 bit | 14 | 60 | 군사·국가 기밀·양자 대비 |

키가 길수록 보안성은 증가하지만 **라운드 수 증가 = 면적/지연/전력 증가**라는 직선적 트레이드오프가 발생합니다 (출처: NIST FIPS 197).

## 5. 알고리즘 원리: 4가지 라운드 연산

AES의 모든 연산은 수학적으로 **유한체(Galois Field) GF(2⁸)** 위에서 정의됩니다. 한 라운드는 다음 4단계로 구성됩니다.

1. **SubBytes (비선형 치환)**
   - 256-엔트리 S-Box를 통해 1바이트 → 1바이트로 매핑
   - GF(2⁸)에서의 곱셈 역원 + 아핀 변환
   - **AES의 비선형성 = 해독 어려움의 핵심 원천**

2. **ShiftRows (행 단위 회전)**
   - 4×4 상태 행렬의 각 행을 0/1/2/3 바이트씩 좌측 회전
   - 데이터 위치 섞기 (확산 효과)

3. **MixColumns (열 단위 확산)**
   - 각 열에 대해 GF(2⁸) 위의 4×4 다항식 행렬 곱셈 수행
   - **마지막 라운드에서는 생략**됨 (복호화 대칭성을 위해)

4. **AddRoundKey (키 혼합)**
   - 라운드 키와 상태 행렬을 비트 단위 XOR
   - 모든 라운드 시작 전 한 번 더 수행 (총 N+1번)

## 6. 운영 모드(Modes of Operation): 알고리즘만큼 중요한 선택

블록 암호 자체는 16바이트만 처리할 수 있으므로, 임의 길이 데이터를 안전하게 처리하려면 **모드(mode)** 가 필요합니다 (출처: NIST SP 800-38 Series).

| 모드 | 핵심 특성 | 병렬 처리 | 보안성 | 현재 위상 |
|------|----------|:--------:|--------|----------|
| **ECB** | 블록 독립 암호화 | O | 패턴 노출 | **사장(deprecated)** |
| **CBC** | 이전 암호문 XOR 후 암호화 | X | 양호 | 점진적 감소 |
| **CFB/OFB** | 스트림 암호처럼 동작 | X/X | 양호 | 레거시 |
| **CTR** | 카운터 + AES → keystream | **O** | 양호 | 광범위 사용 |
| **GCM** | CTR + GHASH 인증 (AEAD) | **O** | 매우 우수 | **사실상 표준** (TLS 1.3) |
| **XTS** | 디스크 암호화 전용 | O | 우수 | 스토리지 표준 |

> "High-speed GCM requires a large 128-bit GF(2^128) multiplier" (NIST SP 800-38D). 즉, GCM 가속기는 AES 코어 외에 별도 **GHASH 유닛**(GF(2¹²⁸) 곱셈기)이 필요합니다.

## 7. SoC RTL 설계 관점: 면적·성능·전력 트레이드오프

### 7.1 아키텍처 선택지

| 아키텍처 | Gate 수(GE) | Throughput | Latency | 적용 영역 |
|---------|:-----------:|:----------:|:-------:|----------|
| **Fully Pipelined** | 100k~500k | >100 Gbps @1GHz | 10~14 cycles (고정) | 데이터센터·SSD 컨트롤러 |
| **Iterative (1 round/cycle)** | 5k~20k | 100~500 Mbps | 11~15 cycles | 일반 SoC·보안 IP |
| **Serialized (byte-oriented)** | <3k | 수십 Mbps | 160~200 cycles | IoT·스마트카드 |

(출처: TSMC 65/28nm 기반 일반 추정치, OpenTitan/SecWorks 문서 기반)

### 7.2 RTL 핵심 설계 결정사항

1. **S-Box 구현**
   - **LUT(ROM 기반)**: 256바이트 ROM. 빠르지만 면적 큼.
   - **Composite Field Logic**: GF(2⁴)² 분해를 통한 조합 논리 구현. **저면적 설계의 표준 기법**이며 NIST 분석에서도 권장됨 (출처: NIST FIPS 197 Analysis).

2. **Key Expansion(Key Schedule)**
   - **On-the-fly**: 매 라운드마다 다음 키 생성 → 면적 절감, 첫 블록 지연 발생
   - **Pre-computed Storage**: 사전 전체 라운드 키 생성 → SRAM 면적 증가, 처리량 증가

3. **데이터 경로 폭(Datapath Width)**
   - 128비트 풀폭 → 1라운드/사이클
   - 32비트 → 4사이클/라운드
   - 8비트 직렬 → 16사이클/라운드, 초저면적

4. **모드별 병렬화 제약**
   - **CTR/GCM/ECB**: 블록 간 의존성 없음 → 파이프라인 적합
   - **CBC/CFB**: 이전 결과 필요 → 파이프라인 효과 제한적, 단일 라운드 반복 구조 유리

### 7.3 부채널 공격(SCA) 대응

> "The AES unit is a cryptographic accelerator providing hardened AES encryption and decryption. It includes countermeasures against side-channel analysis." (OpenTitan AES Unit Docs, 2024-05)

상업적 SoC에서 반드시 고려해야 할 항목:

- **Masking**: 평문/키를 무작위 마스크로 분할 처리 → DPA(전력 분석) 방어. 1차/2차/고차 마스킹 단계 존재.
- **Constant-Time Execution**: 입력값과 무관하게 항상 동일 사이클 → Timing Attack 차단.
- **Key Laddering / Key Path 격리**: 평문 키가 외부 버스나 디버그 인터페이스로 노출되지 않도록 별도 경로 보장.
- **Random Delay / Dummy Round**: 전력 트레이스의 정렬을 어렵게 함.

## 8. 주요 오픈소스 AES RTL 코어 비교

SoC IP 통합 시 검토 가능한 대표 오픈소스 SystemVerilog/Verilog 코어 비교:

| 코어 | 라이선스/주관 | 핵심 강점 | AES-128 지연 | 비고 |
|------|--------------|----------|:-----------:|------|
| **OpenTitan AES** | Apache 2.0 / lowRISC·Google | **SCA 대응(Masking, DOM)**, 보안 검증 | 수십~수백 cycle (옵션) | 보안 SoC 1순위 후보 |
| **SecWorks AES** | BSD 계열 / Joachim Strömbergson | 고속·파라미터화, 깨끗한 RTL | **11~44 cycles** | "High speed, area efficient AES-128/192/256. Supports ECB, CBC, CTR, OFB, CFB" (SecWorks GitHub) |
| **TinyAES (OpenCores)** | LGPL 등 | 초소형 면적 (Iterative) | ~160 cycles | IoT·MCU급 |
| **NIST Reference** | Public | 알고리즘 정확성 검증 | 가변 | 검증/Golden Model 용도 |

> 실무 권장: **고보안 ASIC** → OpenTitan, **고성능 통신/스토리지** → SecWorks, **저면적 IoT** → TinyAES, **검증 골든 모델** → NIST Reference 병행.

## 9. 사장되고 있는 항목들

- **DES / 3DES**: NIST는 2017년 3DES의 새 적용 금지를 권고했고, 2023년 이후 완전 disallowed로 분류했습니다.
- **AES-ECB 모드**: 동일 평문 → 동일 암호문이라는 결정적 약점으로 표준 보안 프로토콜에서 거의 퇴출.
- **MD5·SHA-1 기반 결합 사용**: AES 자체는 아니지만 함께 사용되던 해시는 사장 단계에 있어, AEAD(GCM/CCM)로의 통합이 가속화되고 있습니다.
- **CBC 모드의 점진적 후퇴**: 패딩 오라클 공격(Padding Oracle Attack) 위험으로 신규 프로토콜에서는 GCM·ChaCha20-Poly1305 등 AEAD로 대체되는 추세입니다.

## 10. 미래 트렌드 및 권장 방향

1. **AES-GCM의 사실상 단일화**: TLS 1.3, IPsec, NVMe Self-Encrypting Drive 등에서 GCM이 주요/유일 모드로 채택되고 있습니다. SoC AES 가속기는 **GHASH 유닛 동봉이 사실상 필수**입니다.
2. **AES-256 기본 채택 추세**: Grover 알고리즘에 의해 양자 컴퓨터 환경에서 대칭키 강도가 절반으로 줄어드는 점을 고려할 때, AES-128(→64bit 등가)은 장기 보안 마진이 부족하다고 평가되며, **AES-256(→128bit 등가) 권장**이 점차 표준화되고 있습니다.
3. **PQC와의 하이브리드 결합**: 키 교환은 Kyber 등 양자내성 알고리즘으로, 데이터 암호화는 AES-256-GCM으로 분담하는 **하이브리드 KEM + AEAD** 구조가 차세대 SoC 보안 IP의 기본형으로 부상하고 있습니다.
4. **Secure Enclave / TEE 내부 격리**: ARM TrustZone, RISC-V PMP+Keystone, Apple SEP 등 안전 영역 안에서만 평문 키가 존재하도록 설계하는 방식이 표준화되고 있으며, OpenTitan은 이를 실제 RTL 수준에서 구현한 대표 사례입니다.
5. **Masked AES의 실리콘 표준화**: 자동차(ISO/SAE 21434), 결제(EMVCo), 정부(FIPS 140-3) 인증을 받으려면 Masked S-Box 등 SCA 대응 RTL이 필수가 되어가고 있습니다.

## 11. 결론: SoC 설계자를 위한 의사결정 체크리스트

- [ ] **타깃 영역 결정**: IoT(저면적) / 모바일·일반 SoC(균형) / 데이터센터(고처리량) / 보안 SoC(SCA 대응)
- [ ] **모드 범위 결정**: 최소 ECB+CBC+CTR / 권장 CTR+GCM / 스토리지면 XTS 추가
- [ ] **키 길이 지원**: 최소 AES-128/256, 가능하면 192 포함
- [ ] **S-Box 방식**: 면적 우선이면 Composite Field, 속도 우선이면 LUT
- [ ] **Key Schedule 정책**: 면적 우선 On-the-fly, 처리량 우선 Pre-computed
- [ ] **SCA 대응**: 상용 보안 인증 대상이면 Masking·Constant-Time 필수
- [ ] **검증 흐름**: NIST FIPS 197 Test Vector + CAVP 호환 + UVM 기반 모드별 시퀀스 검증
- [ ] **레퍼런스 활용**: SecWorks(성능)·OpenTitan(보안)·TinyAES(면적) 중 하나를 baseline으로 두고 차별화 설계

AES는 알고리즘 자체는 25년간 본질이 변하지 않았지만, **운영 모드·SCA 대응·키 길이·시스템 통합 방식**이라는 4개 축에서 끊임없이 진화해왔습니다. 따라서 RTL 엔지니어의 임무는 단순한 FIPS 197 변환이 아니라, **타깃 SoC의 위협 모델 위에서 면적·성능·보안의 3차원 곡선을 최적화하는 것**이라 정리할 수 있습니다.
---

## References

- [NIST FIPS 197 (AES Standard)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf)
- [NIST SP 800-38D (GCM Mode)](https://csrc.nist.gov/publications/detail/sp/800-38d/final)
- [OpenTitan AES IP Spec](https://opentitan.org/book/hw/ip/aes/)
- [SecWorks AES GitHub](https://github.com/secworks/aes)