정보보안개론 03. 암호화와 디지털 신뢰

1. 암호화란 무엇인가?

암호화는 평문(Plaintext)을 키(Key)를 이용해 암호문(Ciphertext)으로 변환하고, 권한을 가진 사용자가 다시 복호화하는 기술이다.

기본 구조는 다음과 같다.

평문 → 암호화 + 키 → 암호문 → 복호화 + 키 → 평문

여기서 중요한 것은 알고리즘 자체뿐만 아니라 키를 누가 가지고 있고, 어떻게 안전하게 관리하는가이다.

 

2. 대칭키와 비대칭키

암호화 기술은 크게 대칭키 암호화와 비대칭키 암호화로 나눌 수 있다.

 

대칭키 암호화

암호화와 복호화에 같은 비밀키를 사용하는 방식이다.

대표적인 알고리즘이 AES다.

장점은 빠르고 대량의 데이터를 처리하는 데 적합하다는 것이다.

하지만 문제가 있다.

“상대방에게 비밀키를 어떻게 안전하게 전달할 것인가?”

사용자가 많아질수록 키를 배포하고 보관하고 교체하고 폐기하는 키 관리(Key Management)가 복잡해진다.

따라서 대칭키는 파일, 디스크, 데이터베이스, 통신 세션 등 실제 데이터를 빠르게 암호화하는 데 많이 사용된다.

 

비대칭키 암호화

비대칭키는 공개키(Public Key)와 개인키(Private Key)라는 서로 다른 키를 사용한다.

공개키는 다른 사람에게 알려도 되지만 개인키는 소유자만 안전하게 보관해야 한다.

이를 우체통에 비유할 수 있다.

• 공개키 = 누구나 편지를 넣을 수 있는 우체통
• 개인키 = 우체통을 열 수 있는 주인만 가진 열쇠

비대칭키를 사용하면 비밀키를 직접 전달해야 하는 문제를 줄일 수 있다.

하지만 새로운 문제가 생긴다.

“이 공개키가 정말 그 사람의 공개키라는 것을 어떻게 믿을 것인가?”

이 질문에서 PKI와 인증서가 등장한다.

 

3. 현대 암호화는 대칭키와 비대칭키를 함께 사용한다

실제 인터넷 통신에서는 두 방식 중 하나만 사용하는 것이 아니라 혼합 구조(Hybrid Cryptography)를 사용하는 경우가 많다.

일반적으로는 다음과 같은 흐름이다.

서버 인증 → 공개키 기반 키 합의 → 세션키 생성 → 대칭키로 데이터 암호화

비대칭키는 인증과 키 교환에 적합하고, 대칭키는 대량의 데이터를 빠르게 암호화하는 데 적합하기 때문이다.

즉,

비대칭키와 대칭키는 경쟁 관계가 아니라 역할 분담 관계다.

HTTPS/TLS 같은 현대적인 통신 보안도 이러한 구조를 기반으로 한다.

 

4. 해시는 암호화와 다르다

해시(Hash)는 암호화와 자주 혼동되지만 목적이 다르다.

암호화

• 목적: 정보를 숨김
• 키를 사용
• 적절한 키가 있으면 원래 정보로 복호화 가능
• 기밀성에 초점

해시

• 목적: 정보의 지문을 생성
• 일반적인 해시는 복호화를 위한 기술이 아님
• 원본의 변경 여부를 확인
• 무결성에 초점

예를 들어 같은 계약서에 해시 함수를 적용하면 항상 같은 해시값이 나온다.

그런데 계약서의 숫자 하나만 바뀌어도 해시값은 크게 달라진다.

따라서

“이 파일이 원본과 동일한가?”

를 확인하는 데 사용할 수 있다.

 

5. 해시의 주요 특징

좋은 암호학적 해시는 다음과 같은 특성을 가진다.

• 같은 입력 → 같은 결과
• 입력 크기와 관계없이 일정한 길이의 결과
• 해시값만으로 원본을 찾기 어려움
• 다른 입력에서 같은 해시를 만들기 어려움
• 입력이 조금만 바뀌어도 결과가 크게 달라짐

이러한 특성 때문에 해시는 파일 무결성 검사, 전자서명, 포렌식, 비밀번호 저장 등 다양한 분야에서 활용된다.

 

6. 비밀번호 저장은 일반적인 해시와 다르다

비밀번호 저장에서는 한 가지 중요한 차이가 있다.

해시가 너무 빠르면 오히려 위험할 수 있다.

공격자가 수많은 비밀번호를 빠르게 대입해볼 수 있기 때문이다.

그래서 비밀번호를 저장할 때는 일반적인 빠른 해시보다는 Salt와 함께 계산 비용을 높인 비밀번호 전용 방식이 사용된다.

대표적인 예로 다음과 같은 방식이 있다.

• Argon2
• bcrypt
• scrypt
• PBKDF2

핵심은 간단하다.

파일 검증은 빠른 해시가 유리하지만, 비밀번호 저장은 공격자의 대입 공격을 늦추기 위해 일부러 느리게 만드는 것이 중요하다.

 

7. 전자서명: 숨기는 것이 아니라 증명하는 기술

전자서명은 암호화와 목적이 다르다.

전자서명은 주로 다음 세 가지를 확인하는 데 사용된다.

1. 인증 – 누가 서명했는가?
2. 무결성 – 서명 이후 문서가 변경되지 않았는가?
3. 부인방지 – 서명 사실을 쉽게 부인할 수 있는가?

전자서명은 일반적으로 문서 전체에 직접 서명하기보다는,

문서 → 해시 → Digest 생성 → 개인키로 서명 → 공개키로 검증

이라는 구조를 사용한다.

따라서 전자서명은 흔히 생각하는 단순한 '암호화된 사인'이라기보다 암호학적으로 검증 가능한 디지털 증명이라고 이해하는 것이 좋다.

 

8. PKI: 공개키를 어떻게 믿을 것인가?

비대칭키 기술을 사용하다 보면 중요한 문제가 생긴다.

“이 공개키가 정말 해당 서버나 사람의 것인가?”

공격자가 자신의 공개키를 다른 사람의 공개키인 것처럼 전달하면 중간자 공격(MITM)이 발생할 수 있다.

이 문제를 해결하기 위한 대표적인 구조가 PKI(Public Key Infrastructure)다.

PKI는 쉽게 말하면 인터넷에서 사용하는 디지털 신분증 제도라고 볼 수 있다.

공개키와 신원을 인증서로 연결하고, 그 인증서를 발급하고 검증하고 갱신하고 폐기하는 전체 체계를 의미한다.

 

9. PKI의 주요 구성요소

PKI에는 여러 역할이 있다.

• Subscriber: 인증서를 신청하고 사용하는 주체
• RA(Registration Authority): 신원이나 도메인 등을 확인
• CA(Certificate Authority): 인증서를 발급
• Repository: 인증서 및 상태 정보 저장·조회
• Relying Party: 인증서를 검증하고 신뢰 여부를 판단

쉽게 비유하면,

RA = 신원 확인 창구
CA = 디지털 신분증 발급기관
인증서 = 인터넷 신분증

이라고 이해하면 된다.

 

10. X.509 인증서는 무엇을 담고 있을까?

웹사이트의 인증서는 단순히 공개키만 담고 있는 것이 아니다.

대표적인 정보는 다음과 같다.

• Subject: 인증서의 주체
• Issuer: 인증서를 발급한 기관
• Validity: 유효기간
• Public Key: 공개키
• SAN: 인증서가 유효한 도메인이나 이름
• Key Usage / EKU: 키의 사용 목적
• CRL DP / AIA: 폐기나 검증에 필요한 정보

브라우저는 인증서를 확인할 때 단순히 "인증서가 존재하는가?"만 확인하지 않는다.

도메인이 맞는지, 유효기간이 남았는지, 신뢰할 수 있는 CA인지, 신뢰체인이 정상인지, 인증서가 폐기되지 않았는지 등을 종합적으로 확인한다.

 

11. 인증서 신뢰는 체인으로 연결된다

웹사이트 인증서는 일반적으로 다음과 같은 신뢰 구조를 가진다.

Root CA → Intermediate CA → Server Certificate

브라우저와 운영체제에는 신뢰할 수 있는 Root CA 정보가 저장되어 있고, 서버 인증서는 중간 CA 등을 통해 이 신뢰의 시작점까지 연결된다.

따라서 인터넷에서의 신뢰는 인증서 한 장만 믿는 것이 아니라 신뢰 체인 전체를 검증하는 과정이다.

 

12. 인증서는 유효기간이 남아 있어도 폐기될 수 있다

인증서는 유효기간이 끝나기 전에도 신뢰를 잃을 수 있다.

예를 들어,

• 개인키가 유출된 경우
• 인증서가 잘못 발급된 경우
• 도메인이나 소유자가 변경된 경우
• 서비스가 종료된 경우

등이다.

이때 필요한 것이 인증서 폐기(Revocation)다.

대표적인 방법이 다음 두 가지다.

CRL

폐기된 인증서 목록을 제공한다.

OCSP

특정 인증서의 현재 상태를 질의한다.

따라서 중요한 것은

“유효기간이 남아 있다 = 지금도 반드시 신뢰할 수 있다”는 의미는 아니다.

라는 점이다.

 

13. DigiNotar 사건이 보여준 PKI의 한계

PKI는 CA를 신뢰의 기반으로 삼기 때문에 CA가 잘못되면 전체 신뢰 체계가 흔들릴 수 있다.

2011년 DigiNotar 사건은 부정하게 발급된 인증서가 악용되면서 CA 자체에 대한 신뢰가 무너질 수 있음을 보여준 대표적인 사례다.

이 사건이 주는 핵심 교훈은 다음과 같다.

암호 알고리즘만 안전하다고 해서 전체 보안이 완성되는 것은 아니다.

발급기관, 인증 절차, 인증서 폐기, 브라우저와 운영체제의 신뢰 저장소 관리 등 운영 체계 전체가 안전해야 한다.

 

14. PGP와 S/MIME

이메일 보안에서는 PGP/OpenPGP와 S/MIME을 대표적으로 살펴볼 수 있다.

PGP / OpenPGP

중앙 CA에 의존하기보다는 사용자가 직접 키를 확인하고 신뢰를 형성하는 방식이다.

이를 흔히 Web of Trust라는 개념으로 설명한다.

주요 기능은 다음과 같다.

• 이메일·파일 암호화
• 전자서명
• 키 관리

S/MIME

S/MIME은 X.509 인증서와 PKI를 기반으로 이메일 암호화와 전자서명을 제공한다.

따라서 기업이나 기관처럼 조직적으로 인증서를 관리해야 하는 환경에 적합한 구조로 이해할 수 있다.

둘의 핵심적인 차이는 공개키를 어떻게 신뢰하는가에 있다.

구분OpenPGPS/MIME

신뢰 방식	사용자 중심 신뢰망	CA 기반 PKI
주요 환경	개인·개발자·커뮤니티	기업·기관·조직
핵심 특징	직접 키 확인	조직적인 인증서 관리

 

15. HTTPS의 자물쇠가 모든 것을 보장하는 것은 아니다

웹브라우저의 자물쇠 아이콘을 보면 "안전한 사이트"라고 생각하기 쉽다.

하지만 HTTPS가 보장하는 것은 보다 구체적이다.

브라우저는 대체로 다음과 같은 것을 확인한다.

• 접속한 도메인과 인증서 이름이 일치하는가?
• 신뢰할 수 있는 CA가 발급했는가?
• 인증서가 유효한가?
• 인증서가 폐기되지 않았는가?
• 암호화된 연결을 만들 수 있는가?

따라서 HTTPS는 통신의 암호화와 서버 인증에 관한 신뢰를 제공하는 것이지, 해당 사이트의 사업자나 판매 행위가 정직하다는 것까지 보장하는 것은 아니다.

여기서 다음 세 가지를 구분할 필요가 있다.

• 인증(Authentication): 당신은 누구인가?
• 인가(Authorization): 무엇을 할 수 있는가?
• 감사(Audit): 무엇을 했는가?

 

16. 전자상거래와 SET

전자상거래가 발전하면서 또 다른 문제가 등장했다.

고객, 상점, 결제기관이 모든 정보를 서로 볼 필요가 있는가?

SET(Secure Electronic Transaction)은 과거 전자상거래 환경에서 이러한 문제를 해결하기 위해 등장한 역사적 사례다.

핵심적인 아이디어는 정보 최소 노출이다.

예를 들어 상점은 주문과 배송에 필요한 정보를 알아야 하지만, 카드 결제에 필요한 모든 정보를 직접 볼 필요는 없다.

즉,

모든 참여자가 모든 정보를 알 필요는 없다.

현대의 결제 시스템은 TLS, 결제대행사(PG), 토큰화, 다양한 인증 기술 등으로 발전했지만, SET이 보여준 역할별 정보 분리와 최소 노출이라는 원칙은 여전히 중요한 보안 개념이다.

 

17. 암호화는 어디에 사용되는가?

암호기술은 특정 분야에만 사용되지 않는다.

• 웹: HTTPS/TLS
• 이메일: PGP, S/MIME
• 전자문서: 전자서명, 타임스탬프
• 저장장치: 디스크·파일 암호화
• 클라우드: KMS, 데이터 암호화
• 소프트웨어: Code Signing

결국 중요한 것은 단순히 "어떤 암호 알고리즘을 사용하는가?"가 아니다.

데이터, 키, 신원, 무결성을 어디에서 어떻게 관리할 것인가?

가 핵심이다.

 

18. 암호화의 역설: 랜섬웨어

암호화는 데이터를 보호하기 위한 기술이지만 공격자 역시 암호화를 사용할 수 있다.

랜섬웨어는 공격자가 피해자의 파일을 암호화한 뒤 피해자가 파일을 사용할 수 없도록 만들어 가용성을 공격한다.

따라서 중요한 질문은 단순히

"암호화가 안전한가?"

가 아니라,

"누가 암호화 키를 통제하고 있는가?"

가 된다.

그리고 랜섬웨어 문제는 자연스럽게 백업과 복구, 업무연속성 문제로 이어진다.

 

19. BCP와 DRP: 사고 이후에도 살아남기

보안 사고를 완벽하게 예방하는 것은 현실적으로 어렵다.

따라서 사고가 발생했을 때 업무를 계속하고 시스템을 복구할 수 있는 능력이 중요하다.

BCP

Business Continuity Planning

사고가 발생해도 업무를 계속하기 위한 계획이다.

사람, 절차, 대체 업무, 고객 안내 등을 포함한다.

DRP

Disaster Recovery Planning

장애가 발생한 IT 시스템을 복구하기 위한 계획이다.

서버, 데이터베이스, 네트워크, 백업 등을 복구하거나 다른 시스템으로 전환하는 방법을 다룬다.

쉽게 말하면,

BCP = 업무를 어떻게 계속할 것인가?
DRP = IT 시스템을 어떻게 되살릴 것인가?

 

20. RTO와 RPO

복구 계획을 세울 때 중요한 두 가지 지표가 RTO와 RPO다.

RTO

Recovery Time Objective

서비스를 얼마나 빨리 복구해야 하는가를 의미한다.

RPO

Recovery Point Objective

장애가 발생했을 때 얼마나 많은 데이터를 잃어도 되는가를 의미한다.

게임 저장에 비유하면 이해하기 쉽다.

• RTO = 게임을 언제까지 다시 켤 수 있어야 하는가?
• RPO = 마지막 저장 이후 얼마나 진행 상황을 잃어도 되는가?

따라서 백업과 복구 전략은 단순히 "백업을 해두자"에서 끝나는 것이 아니라 얼마나 자주 백업하고, 얼마나 빨리 복구해야 하는가까지 결정해야 한다.

 

21. 위험은 어떻게 평가할까?

정보보안에서는 모든 위험에 동일한 비용을 투자할 수 없다.

따라서 위험을 평가하고 우선순위를 정해야 한다.

정량적 위험평가의 대표적인 계산식은 다음과 같다.

SLE = AV × EF

• AV: 자산가치
• EF: 손실률
• SLE: 단일손실예상액

그리고

ALE = SLE × ARO

• ARO: 연간 발생빈도
• ALE: 연간손실예상액

예를 들어 자산가치가 1억 원이고 사고가 발생했을 때 40%의 손실이 발생한다고 가정하면,

SLE = 1억 × 40% = 4,000만 원

연간 발생빈도를 0.5회라고 가정하면,

ALE = 4,000만 원 × 0.5 = 2,000만 원/년

이처럼 위험을 금액으로 추정하면 보안 투자나 복구 체계에 필요한 비용을 설명하는 데 도움을 줄 수 있다.

다만 이런 계산은 정확한 미래 예측이 아니라 의사결정을 위한 추정 모델이라는 점에 주의해야 한다.

 

22. 정량적 위험평가만으로 충분할까?

모든 위험을 돈으로 계산하기는 어렵다.

예를 들어 다음과 같은 피해는 정확한 금액으로 표현하기 어렵다.

• 기업 이미지 훼손
• 고객 신뢰 하락
• 법적 영향
• 언론 보도
• 장기적인 고객 이탈

따라서 실제 위험관리에서는 정량적 평가와 정성적 평가를 함께 활용할 수 있다.

예를 들어,

• 정량적: 예상 매출 손실, 복구 비용
• 정성적: 평판 영향, 고객 신뢰 하락
• 반정량적: 가능성 1~5 × 영향도 1~5

와 같이 여러 관점에서 위험을 평가한다.