AES·RSA·ECC·SHA-256으로 구성하는 하이브리드 암호화 체계
AES, RSA, ECC, SHA-256의 역할을 분리하고 키 관리·AEAD·하이브리드 암호화로 데이터 기밀성과 무결성을 설계하는 방법
2026-08-14 · 최초 발행 2024-04-29
암호화 체계는 알고리즘의 역할을 나누는 데서 시작한다
데이터를 암호화하는 일과 키를 전달하는 일, 메시지가 바뀌지 않았음을 확인하는 일은 서로 다른 문제다. AES, RSA, ECC, SHA-256은 이 문제를 각자 맡으며, 실제 시스템에서는 하이브리드 구조로 함께 배치된다.
AES는 128비트 블록 크기를 사용하는 대칭키 블록 암호로 128/192/256비트 키를 지원한다. 데이터 기밀성에 적합하지만, 운용 모드에 따라 보안 성질이 달라진다. 인증까지 함께 제공하는 AEAD 모드인 GCM 사용이 권장된다.
RSA는 정수 인수분해의 어려움에 기반한 공개키 암호다. 대용량 데이터를 직접 암호화하기보다 키 래핑과 전자서명에 주로 사용한다. 암호화에는 OAEP, 서명에는 PSS 같은 현대적 패딩이 필요하다.
ECC는 타원곡선 이산로그 문제를 기반으로 한다. 짧은 키 길이로 동등한 보안 강도를 제공하며, ECDH 키 합의와 ECDSA 서명에 사용된다. X25519와 Ed25519 같은 현대 곡선도 선택지다.
SHA-256은 고정 길이 다이제스트를 만드는 암호 해시 함수다. 무결성 검증과 서명 전 전처리에 쓰이며, 공유키 기반 무결성 검증에는 HMAC-SHA-256이 일반적으로 사용된다.
이 역할을 조합하면 기밀성은 AES가, 키 분배와 서명은 RSA 또는 ECC가, 무결성은 SHA-256·HMAC 또는 인증 태그가 담당한다. 하이브리드 암호화는 대칭키로 데이터를 암호화한 뒤 공개키로 세션키를 래핑하고, 서명이나 태그로 무결성을 확인하는 구조다.
키와 Nonce가 암호화 운영의 중심이 된다
암호 알고리즘을 선택한 뒤에는 키 수명과 보호 위치를 설계해야 한다. 루트 키는 HSM 또는 KMS로 보호하고, 세션키는 일회성으로 사용하며, 키 수명과 회전 정책을 정한다. 키 파생 KDF와 키 래핑 KW/KEM의 책임을 나누고, KID를 포함한 메타데이터를 관리하는 방식이 권장된다.
AES에서는 GCM 같은 AEAD 모드를 채택하고 IV 또는 Nonce의 고유성을 보장해야 한다. ChaCha20-Poly1305는 대안으로 고려할 수 있다. RSA에는 OAEP와 PSS를 사용하며 PKCS#1 v1.5는 지양한다. ECC 서명에서는 ECDSA 파라미터 검증도 필요하다.
무결성 검증은 RSA-PSS·ECDSA 전자서명이나 AEAD 인증 태그로 수행한다. 두 방식을 겹쳐 적용할 경우에는 계층과 검증 순서를 미리 정의해야 한다. HMAC-SHA-256은 공유키 기반 무결성을 제공하므로 키 분리(Key Separation) 관행을 함께 적용한다.
키, Nonce, Salt 생성에는 CSPRNG를 사용해 엔트로피와 예측 불가능성을 확보한다. RNG 실패 탐지와 재시도를 고려하고, 하드웨어 TRNG와 소프트웨어 DRBG를 병행하는 운용도 검토할 수 있다.
성능 최적화에서는 AES-NI, ARMv8 Crypto 확장, PCLMULQDQ를 통한 GCM 가속과 벡터화가 활용된다. ECC 구현에서는 X25519·Ed25519 최적화와 함께 상수시간 연산, 캐시 부채널 완화가 필요하다.
알고리즘별 역할과 운영 특성
| 알고리즘 | 목적/역할 | 키/보안 강도(예) | 성능/확장성 | 안정성/공격 내성 | 운영 편의 |
|---|---|---|---|---|---|
| AES | 데이터 기밀성, AEAD | 128/192/256비트 → 128/192/256비트 보안 | 매우 빠름, 하드웨어 가속·배치 처리 용이 | 모드·IV 오용 취약, AEAD 사용 시 내성 향상 | 키·Nonce 관리 중요, 회전 간편 |
| RSA | 키 래핑, 전자서명 | 2048/3072/4096비트 → ~112/~128/~152비트 | 느림, 대용량 데이터 부적합, 세션키 용도 적합 | OAEP/PSS 사용 시 안전성 확보 | 키 크기 큼, HSM 사용 빈도 높음 |
| ECC | 키 합의, 전자서명 | P-256/384/521 → ~128/~192/~256비트 | 빠름, 모바일/IoT 적합, 작은 키 | 곡선 선택 중요, 타이밍·사이드채널 주의 | 짧은 키, 배포·회전 용이 |
| SHA-256 | 해시, 무결성 | 256비트 출력, 충돌 내성 128비트 | 매우 빠름, 스트리밍 처리 용이 | 광범위 검증, SHA-1 대비 안전성 우수 | HMAC 적용 시 키 관리 요구 |
주: 보안 강도와 성능 수치는 구현·플랫폼 의존 특성, NIST 가이드라인 참조 필요
세션키를 공개키로 보호하는 하이브리드 흐름
수신 측은 헤더의 버전과 알고리즘 화이트리스트를 확인하고, KID로 대상 키를 조회한다. OAEP 또는 태그 검증이 실패했을 때 상세 원인을 노출하지 않고, 일정 지연 상수시간 응답을 적용한다. 실패 카운트, IP, KID는 감사 로그로 남기고 경보 임계치를 설정한다.
통신·저장·토큰·원장에서의 조합
TLS 1.3 통신에서는 X25519 또는 ECDHE로 키를 합의하고, AES-128/256-GCM 또는 ChaCha20-Poly1305를 대칭키로 사용한다. 서버 인증서는 ECDSA 또는 RSA를 사용하며 핸드셰이크 기록의 무결성도 보호한다.
저장 데이터에서는 파일과 DB에 AES-GCM 또는 CTR+HMAC을 적용하고, 파일 단위로 Nonce와 태그를 관리한다. 키 계층은 DEK(Data Encryption Key)–KEK(Key Encryption Key)–HSM 루트키의 3계층 구조로 구성할 수 있다.
API 토큰은 HMAC-SHA-256 또는 JWS 서명(ES256/RS256)으로 보호한다. 로그 불변성에는 SHA-256 기반 레코드 체인 해시와 시간기반 시그니처를 적용할 수 있다.
블록체인과 분산원장에서는 ECDSA·EdDSA가 주소와 서명을 담당하고 트랜잭션 무결성을 뒷받침한다. 블록 헤더에는 SHA-256을 사용하며, 머클 트리로 데이터를 구성한다.
성능과 보안 수준을 함께 보는 기준
AES-GCM은 하드웨어 가속 시 코어당 수 Gbps 처리량을 달성할 수 있어 대용량 스트리밍에 적합하다. RSA-2048 서명은 수천 TPS 수준, ECDSA P-256은 수만 TPS 수준이 가능하며 플랫폼 의존적이다.
보안 강도 관점에서는 AES-256이 256비트 보안, P-256이 약 128비트 동등 보안, RSA-3072가 약 128비트 보안 수준에 해당한다. SHA-256은 충돌내성 128비트, 전이미지 내성 256비트 수준이다.
키 계층화와 자동 회전은 키 수명 관리를 단순화하고 사고 범위를 한정한다. AEAD로 전환하면 무결성 오류 탐지율을 높이고 재암호화 비용을 줄일 수 있다.
선택과 구현에서 피할 지점
데이터 암호화에는 AES-GCM을 기본 선택으로 두고, 모바일 또는 소프트웨어만 사용하는 환경에서는 ChaCha20-Poly1305를 대안으로 고려한다. 키 합의와 서명에는 X25519·Ed25519 또는 P-256·ECDSA를 채택하며, 규제 준수가 필요한 경우 P-256·P-384를 우선한다.
RSA는 OAEP와 PSS만 허용하고 CBC+PKCS#7 조합은 지양하며 AEAD로 일원화한다. Nonce는 반드시 고유해야 하므로 카운터와 랜덤을 혼용하는 충돌 방지 설계를 적용하고, 키는 KMS 또는 HSM으로 보호한다.
구현 단계에서는 상수시간 연산과 타이밍·캐시·전력 분석 대응을 고려한다. 서명 파라미터는 strict DER와 S 범위 검사를 포함해 검증한다. 운영에서는 실패 동작을 균일하게 만들고 에러 메시지를 최소화하며, 보안 로그와 지표 대시보드를 구성한다.
양자 대비를 위해 PQC 전환 로드맵을 수립하고 X25519+Kyber 같은 하이브리드 키 합의를 검토할 필요가 있다. 최신 정보 확인이 필요하다.