암호·해시·전자서명과 PKI

1. 암호기술이 제공하는 기능

암호화만으로 무결성이나 송신자 신원이 자동 보장되는 것은 아니다. 목적에 맞는 기술을 조합해야 한다.

2. 대칭키 암호

암호화와 복호화에 같은 비밀키를 사용한다.

평문 ──비밀키 K로 암호화──► 암호문
암호문 ──같은 K로 복호화──► 평문

장점:

• 대용량 데이터 처리에 빠름
• 키 길이가 상대적으로 짧음
• 파일·통신 본문 암호화에 적합

한계:

• 통신 상대마다 비밀키를 안전하게 공유해야 함
• 참여자가 많으면 키 관리가 복잡해짐

대표적인 현대 블록암호는 AES이다. DES와 3DES는 역사적·레거시 맥락에서 구분한다.

3. 공개키 암호

공개키와 개인키의 쌍을 사용한다.

기밀성 목적:
송신자 ─ 수신자 공개키로 암호화 ─► 수신자
수신자 ─ 자신의 개인키로 복호화

서명 목적:
송신자 ─ 자신의 개인키로 서명 ─► 수신자
수신자 ─ 송신자 공개키로 검증

공개키 암호는 대칭키보다 계산 비용이 크므로 대량 데이터 전체보다 키 교환·전자서명·작은 값 보호에 주로 사용한다.

공개키가 누구의 것인지 확인하지 못하면 중간자 공격에 취약할 수 있다. 인증서와 신뢰체계가 필요한 이유이다.

4. 하이브리드 암호화

실제 보안 프로토콜은 대칭키와 공개키 기술을 결합한다.

① 임시 대칭 세션키 생성·합의
② 공개키 기반 인증·키 교환으로 세션키 보호
③ 실제 데이터는 대칭키로 빠르게 암호화
④ 무결성과 인증 태그 검증

HTTPS의 TLS도 이런 원리를 사용한다. 구체 알고리즘 조합은 프로토콜 버전과 설정에 따라 달라진다.

5. 블록암호 운용 모드

제공 자료의 CFB·OFB도 피드백 방식의 스트림형 운용 모드로 이해할 수 있다. 입력 피드백 대상과 병렬 처리 가능성, 오류 전파 특징을 기준으로 비교한다.

ECB:  P1 ─E(K)─► C1
      P2 ─E(K)─► C2

CBC:  IV ⊕ P1 ─E(K)─► C1
      C1 ⊕ P2 ─E(K)─► C2

CTR: Counter1 ─E(K)─► KS1 ⊕ P1 = C1
     Counter2 ─E(K)─► KS2 ⊕ P2 = C2

6. 해시함수

해시는 임의 길이 입력을 고정 길이 요약값으로 변환한다.

요구 성질:

• 역상 저항성
• 제2역상 저항성
• 충돌 저항성
• 입력이 조금 바뀌어도 출력이 크게 변하는 특성

문서 A ──Hash──► 9f4a...
문서 A'──Hash──► 0bc1...

해시는 암호화가 아니므로 복호화 키가 없다. 단순 해시만으로 비밀번호를 저장하면 빠른 대입 공격에 취약할 수 있으므로 salt와 비밀번호용 KDF를 사용한다.

7. MAC과 HMAC

MAC은 메시지와 공유 비밀키로 인증값을 만든다.

메시지 + 공유키 ──MAC──► 인증 태그
수신자도 같은 공유키로 다시 계산해 비교

무결성과 공유키 보유자임을 확인할 수 있지만, 여러 사람이 같은 키를 공유하면 특정 송신자가 누구였는지 제3자에게 증명하기 어렵다. 부인방지에는 전자서명이 더 적합하다.

HMAC은 해시함수를 안전한 구조로 조합한 MAC 방식이다.

8. 전자서명

일반적인 서명 흐름은 문서 전체가 아니라 문서 해시값에 서명한다.

송신자
문서 ──Hash──► 요약값 ──개인키 서명──► 서명값
      문서 + 서명값 전송

수신자
수신 문서 ──Hash──► 요약값 A
서명값 ──공개키 검증──► 요약값 B
A와 B가 같으면 무결성과 서명키 보유를 확인

전자서명은 문서를 숨기는 기능이 아니라 변경 여부와 서명자 확인을 지원한다. 기밀성이 필요하면 별도 암호화가 필요하다.

9. PKI와 인증서 검증

PKI는 공개키, 인증서, 인증기관, 등록·검증·폐기 절차, 정책과 시스템을 포함한 신뢰구조이다.

신뢰 루트 CA
     │ 서명
     ▼
중간 CA
     │ 서명
     ▼
서버 인증서
     │
     └─ 도메인·공개키·유효기간·용도 포함

인증서 검증 항목:

• 신뢰할 수 있는 인증기관까지 서명 경로가 이어지는가
• 유효기간 안인가
• 접속한 이름과 인증서 이름이 맞는가
• 필요한 키 사용 용도인가
• 폐기 여부를 확인할 수 있는가
• 서명 알고리즘과 키가 정책상 허용되는가

10. 키 관리

암호의 안전성은 알고리즘뿐 아니라 키 관리에 달려 있다.

키 생성 → 안전한 저장 → 배포·사용 → 회전 → 폐기
             │
             ├─ 접근권한 최소화
             ├─ 키와 데이터 분리
             ├─ 백업·복구
             └─ 사용 이력 감사

코드나 저장소에 비밀키·API 키를 하드코딩하지 않는다. 환경별 비밀관리 시스템이나 HSM/KMS 같은 통제를 사용할 수 있다.

11. 암호화 목적과 무결성을 함께 설계하기

기밀성만 제공하는 암호화 모드에 MAC을 잘못 결합하면 순서·키 분리 오류가 생길 수 있다. 현대 설계에서는 AES-GCM, ChaCha20-Poly1305 같은 AEAD가 평문 기밀성과 무결성을 함께 제공한다.

AEAD 입력: key, nonce, plaintext, AAD
AEAD 출력: ciphertext, authentication tag

AAD는 암호화하지 않지만 위·변조는 검출한다. 프로토콜 버전, 헤더, 레코드 번호를 AAD로 보호할 수 있다. 같은 키에서 nonce를 재사용하면 GCM·스트림 계열의 기밀성과 무결성이 심각하게 깨질 수 있으므로 고유성 정책이 필요하다.

12. 해시 길이와 생일 공격

n비트 해시에서 무작위 충돌을 찾는 일반적인 작업량은 약 2^(n/2)이다.

SHA-256 충돌 보안 강도 ≈ 2^128
256비트 해시의 원상(preimage) 탐색 ≈ 2^256

비밀번호 저장은 빠른 일반 해시가 아니라 salt와 반복·메모리 비용을 주는 전용 KDF를 사용한다. HMAC은 비밀키를 사용해 메시지 무결성과 송신자 인증을 제공하지만 부인방지는 제공하지 않는다.

13. 전자서명과 인증서 경로 검증

서명은 “문서를 개인키로 암호화한다”로만 외우면 틀리기 쉽다. 실제 서명 알고리즘은 메시지 해시와 서명 전용 수학 연산을 사용한다.

서명: private key + message → signature
검증: public key + message + signature → valid/invalid

인증서 검증은 다음을 모두 확인한다.

1. 신뢰 anchor까지의 서명 체인
2. 현재 시각이 유효기간 안인지
3. 호스트명·주체가 요청 대상과 일치하는지
4. Key Usage·Extended Key Usage가 용도에 맞는지
5. CRL 또는 OCSP 등 폐지 상태
6. 알고리즘·키 길이가 정책상 허용되는지

14. Envelope encryption과 키 회전

데이터 ──DEK로 암호화──▶ 암호문
DEK ──KEK/KMS 키로 암호화──▶ 암호화된 DEK

대용량 데이터를 다시 암호화하지 않고 암호화된 DEK만 새 KEK로 감싸는 rewrap을 사용할 수 있다. 키 회전은 새 암호화에 새 버전을 사용하면서 과거 암호문의 키 버전도 유지하는 단계적 절차가 필요하다.

15. 계산·판독 체크리스트

• 비트 단위 보안 강도와 해시 충돌 강도를 혼동하지 않는다.
• IV·nonce는 반드시 비밀일 필요는 없지만 모드가 요구하는 고유성·예측불가능성을 지킨다.
• 암호화는 기밀성, 해시·MAC·서명은 서로 다른 무결성·인증 목적을 가진다.
• 인증서가 존재한다는 사실과 인증서 경로가 신뢰된다는 판단을 구분한다.

확인 문제

1. AEAD의 AAD는 암호화되는가?
2. 같은 키에서 GCM nonce 재사용이 위험한 이유는?
3. 256비트 해시의 일반 충돌 공격 작업량은?
4. HMAC이 부인방지를 제공하지 않는 이유는?
5. envelope encryption의 rewrap은 무엇을 다시 암호화하는가?