AES-256 암호화 가이드 - Spring boot

AES-256 암호화 가이드

목차

1. AES 암호화란?
2. 왜 IV를 랜덤하게 생성해야 하나?
3. 랜덤 IV로 복호화하는 방법
4. 왜 SecretKey를 환경변수로 분리해야 하나?
5. 실제 동작 예시

---

AES 암호화란?

AES (Advanced Encryption Standard) 는 미국 정부 표준 암호화 알고리즘입니다.

암호화에 필요한 3가지 요소

평문(Plain Text) + SecretKey + IV  →  암호문(Cipher Text)

1. SecretKey (비밀키)

• 역할: 암호화/복호화의 핵심 열쇠
• 길이: AES-256은 32바이트(256비트) 필요
• 특징: 절대 노출되면 안 되는 값
• 비유: 집의 마스터 키

2. IV (Initialization Vector)

• 역할: 암호화의 시작점을 무작위로 만드는 값
• 길이: 16바이트(128비트)
• 특징: 암호문마다 달라야 하며, 노출되어도 상관없음
• 비유: 암호문을 섞는 소금(Salt)

3. 암호화 모드

• CBC (Cipher Block Chaining): 블록 단위로 체인처럼 연결하여 암호화
• 이전 블록의 결과가 다음 블록 암호화에 영향을 줌

---

왜 IV를 랜덤하게 생성해야 하나?

❌ 고정 IV의 문제점

시나리오: 방문자 이름 암호화

// 기존 코드 (고정 IV 사용)
byte[] ivBytes = {0x00, 0x00, 0x00, ...}; // 항상 같음

String name1 = "홍길동";
String encrypted1 = encrypt(name1); // 결과: "Abc123=="

String name2 = "홍길동";  
String encrypted2 = encrypt(name2); // 결과: "Abc123=="  ← 똑같음! 🚨

문제점:

1. 같은 평문은 항상 같은 암호문이 생성됨
2. 공격자가 패턴을 분석할 수 있음
3. 데이터베이스를 탈취당하면 같은 이름들을 쉽게 찾을 수 있음

예시: 데이터베이스 유출 시

SELECT visitor_name, COUNT(*) 
FROM tb_visitor 
GROUP BY visitor_name;

-- 결과
visitor_name          | count
----------------------+-------
Abc123==              | 150   ← 150명이 같은 이름
Xyz789==              | 80    ← 80명이 같은 이름
Def456==              | 1     ← 1명만 있는 희귀한 이름

공격자는 이렇게 생각합니다:

• "Abc123==는 150명이나 되니까 '김철수' 같은 흔한 이름일 거야"
• "Def456==는 1명만 있으니 희귀한 이름이겠네"

이것이 바로 패턴 분석 공격입니다.

✅ 랜덤 IV 사용 시

// 개선된 코드 (랜덤 IV)
byte[] iv = generateRandomIV(); // 매번 다름

String name1 = "홍길동";
String encrypted1 = encrypt(name1); // 결과: "Xyz789TnmK8w..."

String name2 = "홍길동";
String encrypted2 = encrypt(name2); // 결과: "Pqr456MlkJ2x..."  ← 다름! ✅

장점:

1. 같은 평문도 매번 다른 암호문
2. 패턴 분석 불가능
3. 데이터베이스 유출 시에도 안전

---

랜덤 IV로 복호화하는 방법

핵심 원리: IV를 암호문에 포함시킨다

IV는 비밀 정보가 아닙니다. 따라서 암호문과 함께 저장해도 안전합니다.

암호화 과정

1단계: 랜덤 IV 생성
   IV = [A1, B2, C3, D4, ...] (16바이트)

2단계: 평문 암호화
   평문 = "홍길동"
   SecretKey + IV로 암호화
   암호문 = [E5, F6, G7, H8, ...] (가변 길이)

3단계: IV + 암호문 결합
   최종 결과 = [A1, B2, C3, D4, E5, F6, G7, H8, ...]
                ↑---------------↑  ↑-----------------↑
                    IV (16)           암호문 (가변)

4단계: Base64 인코딩
   저장할 값 = "Abc123XyzDef456..."

복호화 과정

1단계: Base64 디코딩
   입력값 = "Abc123XyzDef456..."
   디코딩 = [A1, B2, C3, D4, E5, F6, G7, H8, ...]

2단계: IV 추출
   처음 16바이트 = IV = [A1, B2, C3, D4, ...]

3단계: 암호문 추출
   나머지 = 암호문 = [E5, F6, G7, H8, ...]

4단계: 복호화
   SecretKey + 추출한 IV로 암호문 복호화
   결과 = "홍길동"

실제 코드

// 암호화
public String encrypt(String plainText) {
    byte[] iv = generateRandomIV();              // 1. 랜덤 IV 생성
    byte[] encrypted = doEncrypt(plainText, iv); // 2. 암호화

    // 3. IV + 암호문 결합
    byte[] combined = ByteBuffer.allocate(16 + encrypted.length)
            .put(iv)           // 앞에 IV
            .put(encrypted)    // 뒤에 암호문
            .array();

    return Base64.encode(combined); // 4. Base64 인코딩
}

// 복호화
public String decrypt(String encryptedText) {
    byte[] combined = Base64.decode(encryptedText); // 1. Base64 디코딩

    // 2. IV 추출 (앞 16바이트)
    byte[] iv = Arrays.copyOfRange(combined, 0, 16);

    // 3. 암호문 추출 (나머지)
    byte[] encrypted = Arrays.copyOfRange(combined, 16, combined.length);

    return doDecrypt(encrypted, iv); // 4. 복호화
}

시각적 예시

암호화 결과 (Base64 문자열):
"YxZ3nP8kLm2Qr5T9WvXy1234567890AbCdEfGh..."
 ↑-------------------------↑ ↑-----------------↑
    앞 22자 정도: IV           나머지: 실제 암호문
    (16바이트 Base64)

복호화 시:
1. Base64 디코딩
2. 앞 16바이트 추출 → IV
3. 나머지 추출 → 암호문
4. IV와 SecretKey로 암호문 복호화

---

왜 SecretKey를 환경변수로 분리해야 하나?

❌ 하드코딩의 문제점

public class AES256 {
    // 소스코드에 키가 그대로 노출!
    public static String secretKey = "qwerqwerqwer";
}

문제 상황:

1. GitHub 공개 저장소에 푸시

git push origin main
# → 전 세계 누구나 secretKey를 볼 수 있음! 🚨

2. 내부 직원이 코드를 볼 수 있음

• 개발자 A, B, C 모두 마스터 키를 알게 됨
• 퇴사한 직원도 키를 기억하고 있음

3. 키 변경이 어려움

• 키를 변경하려면 코드 수정 → 빌드 → 배포 필요
• 긴급 상황에 대응 불가

4. 환경별로 다른 키 사용 불가

• 개발/테스트/운영 환경 모두 같은 키 사용
• 개발 DB가 유출되면 운영 DB도 위험

✅ 환경변수 사용

application.properties

# 개발 환경
encryption.secret-key=${ENCRYPTION_SECRET_KEY}

서버 환경변수 설정

# 개발 서버
export ENCRYPTION_SECRET_KEY="dev-key-12345678901234567890123"

# 운영 서버  
export ENCRYPTION_SECRET_KEY="prod-key-98765432109876543210987"

장점:

1. 소스코드에 키가 없음
   • GitHub에 올라가도 안전 (.gitignore에 application.properties을 추가했을 때 말하는거임)
   • 개발자가 코드를 봐도 실제 키는 모름
2. 환경별로 다른 키 사용
   • 개발: dev-key-...
   • 운영: prod-key-...
   • 개발 DB 유출 시 운영은 안전
3. 키 교체 용이
   • 환경변수만 변경 후 재시작
   • 코드 수정/빌드 불필요
4. 접근 통제
   • 서버 접근 권한이 있는 사람만 키 확인 가능
   • 일반 개발자는 키를 모름

실제 운영 시나리오

[개발 환경]
소스코드: GitHub에 공개
환경변수: 로컬 PC에만 설정
  → ENCRYPTION_SECRET_KEY=개발용키

[테스트 환경]
소스코드: 동일
환경변수: 테스트 서버에만 설정
  → ENCRYPTION_SECRET_KEY=테스트용키

[운영 환경]
소스코드: 동일
환경변수: 운영 서버에만 설정 (보안팀만 접근 가능)
  → ENCRYPTION_SECRET_KEY=운영용키

---

실제 동작 예시

시나리오: 방문자 정보 저장 및 조회

1. 4. 검색은 어떻게?

문제: 암호화된 데이터는 검색이 안 됩니다!

-- 이렇게 검색 불가
SELECT * FROM tb_visitor 
WHERE visitor_name = '홍길동';  -- 암호화되어 있어서 못 찾음

해결 방법:

 

방법 2: 해시 컬럼 추가

CREATE TABLE tb_visitor (
    visitor_id int4 PRIMARY KEY,
    visitor_name varchar(200),      -- 암호화된 이름
    visitor_name_hash varchar(64),  -- 검색용 해시
    visitor_phone varchar(200)      -- 암호화된 전화번호
);

String name = "홍길동";
String encrypted = aes256Util.encrypt(name);
String hash = SHA256.hash(name); // 해시는 같은 입력 → 같은 출력

visitor.setVisitorName(encrypted);
visitor.setVisitorNameHash(hash);

검색 시:

SELECT * FROM tb_visitor 
WHERE visitor_name_hash = SHA256('홍길동');

---

요약

IV (Initialization Vector)

질문	답변
왜 랜덤으로?	같은 평문도 다른 암호문 생성 → 패턴 분석 방지
복호화는?	암호문 앞에 IV를 포함시켜 저장 → 복호화 시 추출하여 사용
노출되면?	상관없음 (비밀 정보가 아님)
크기	16바이트 (128비트) 고정

SecretKey

질문	답변
왜 환경변수로?	소스코드 노출 방지, 환경별 다른 키 사용
하드코딩하면?	GitHub 유출, 모든 개발자가 알게 됨, 키 변경 어려움
노출되면?	모든 암호화 데이터 복호화 가능 (치명적)
크기	32바이트 (256비트) 고정

암호화 흐름

[암호화]
평문 → (SecretKey + 랜덤IV) → 암호문 → IV+암호문 결합 → Base64 → DB 저장

[복호화]  
DB 조회 → Base64 디코딩 → IV 추출 → 암호문 추출 → (SecretKey + IV) → 평문

보안 체크리스트

• ✅ IV는 매번 랜덤하게 생성
• ✅ SecretKey는 환경변수로 관리
• ✅ SecretKey는 32바이트 (AES-256)
• ✅ 운영/개발 환경별로 다른 키 사용
• ✅ GitHub에 키가 올라가지 않도록 .gitignore 설정
• ✅ 암호화 대상: 이름, 전화번호, 이메일 등 개인정보
• ⚠️ 비밀번호는 암호화가 아닌 해시(BCrypt) 사용

---

참고 자료

• NIST AES 표준
• OWASP 암호화 가이드
• 개인정보보호법: 고유식별정보(주민번호 등) 암호화 의무