해시·전자서명·PKI

대칭키 암호 = 같은 키 사용, 빠름, 대량 데이터 암호화
공개키 암호 = 공개키·개인키 사용, 키 교환과 전자서명에 활용
하이브리드 암호 = 공개키로 대칭키를 교환하고 실제 데이터는 대칭키로 암호화

해시 함수의 특징과 용도를 설명하시오.
암호화와 해시의 차이를 설명하시오.
MAC과 전자서명의 차이를 설명하시오.
전자서명이 제공하는 보안 속성을 설명하시오.
PKI의 구성요소와 역할을 설명하시오.
CRL과 OCSP의 차이를 설명하시오.
HTTPS 인증서 검증 절차를 설명하시오.

해시는 데이터가 바뀌었는지 확인하고,
전자서명은 누가 보냈는지와 바뀌지 않았는지를 증명하며,
PKI는 공개키와 인증서를 신뢰할 수 있게 관리하는 체계이다.

해시 함수는 임의 길이의 입력 데이터를 고정 길이의 해시값으로 변환하는 일방향 함수로, 데이터 무결성 검증과 비밀번호 저장 등에 사용된다.

해시 = 데이터의 지문

원본 파일 → 해시 함수 → 해시값 A
변조 파일 → 해시 함수 → 해시값 B
A와 B가 다르면 파일이 변경된 것으로 판단

일방향성
고정 길이 출력
충돌 저항성
눈사태 효과

해시 함수는 임의 길이의 데이터를 고정 길이 해시값으로 변환하는 일방향 함수이다. 원문이 조금만 변경되어도 해시값이 달라지므로 데이터 무결성 검증에 활용되며, 안전한 해시 함수는 원문 추정과 충돌 생성이 어려워야 한다.

충돌 = 서로 다른 입력값이 같은 해시값을 갖는 상황

해시 단독 = 무결성 확인
HMAC = 무결성 + 메시지 인증
전자서명 = 무결성 + 인증 + 부인방지

MD5는 충돌 취약성이 알려진 오래된 해시 함수로, 무결성 검증이나 전자서명 등 보안 목적에는 사용하지 않는 것이 바람직하다.

SHA-1은 과거 널리 사용되었으나 충돌 공격 위험으로 인해 전자서명이나 인증서 등 보안 목적에는 사용을 지양해야 한다.

SHA-224
SHA-256
SHA-384
SHA-512

SHA-256 = SHA-2 계열의 대표적인 해시 함수

SHA-3는 SHA-2와 함께 사용 가능한 안전한 해시 함수 계열이다.

MD5와 SHA-1은 충돌 취약성이 있어 보안 목적 사용을 지양하고, SHA-2 또는 SHA-3 계열을 사용하는 것이 바람직하다.

암호화는 기밀성 보호를 위해 평문을 암호문으로 변환하고 올바른 키로 복호화할 수 있는 방식이다. 반면 해시는 임의 길이 데이터를 고정 길이 해시값으로 변환하는 일방향 함수로, 원칙적으로 원문 복원이 불가능하며 무결성 검증과 비밀번호 저장에 활용된다.

회원가입 시:
비밀번호 + 솔트 → 해시값 저장

로그인 시:
입력 비밀번호 + 동일 솔트 → 해시값 계산
저장된 해시값과 비교

비밀번호는 서버가 원문을 복원할 필요가 없으므로 평문이나 복호화 가능한 암호문으로 저장하지 않고, 솔트를 적용한 일방향 해시값으로 저장해야 한다. 로그인 시 입력 비밀번호를 동일한 방식으로 해시하여 저장된 해시값과 비교하면 된다.

솔트는 비밀번호 해시 계산 시 함께 사용하는 사용자별 임의 값으로, 동일한 비밀번호라도 서로 다른 해시값이 생성되도록 한다.

user01: password123 + saltA → hashA
user02: password123 + saltB → hashB

솔트는 비밀일 필요는 없지만 사용자별로 고유하고 충분히 무작위여야 한다.

PBKDF2
bcrypt
scrypt
Argon2

비밀번호 저장에는 솔트와 함께 반복 연산 또는 느린 해시 방식을 사용하여 오프라인 추측 공격 비용을 높이는 것이 바람직하다.

비밀번호 저장 시 단순 해시만 사용하면 공격자가 탈취한 해시값에 대해 빠르게 사전 공격이나 무차별 대입을 수행할 수 있다. 따라서 사용자별 솔트와 PBKDF2, bcrypt, scrypt, Argon2 같은 느린 비밀번호 해시 방식을 사용하여 오프라인 추측 공격 비용을 높여야 한다.

MAC은 메시지와 송수신자가 공유한 비밀키를 이용해 생성하는 값으로, 메시지의 무결성과 송신자 인증을 확인하는 데 사용된다.

MAC = 비밀키를 아는 사람이 만든 메시지 검증값

HMAC은 해시 함수와 공유 비밀키를 결합하여 메시지의 무결성과 인증을 제공하는 MAC 방식이다.

메시지 + 비밀키 → HMAC 값

HMAC 값 일치 → 메시지 변조 없음, 같은 키를 가진 주체가 생성
HMAC 값 불일치 → 변조 또는 인증 실패

요청 파라미터
Timestamp
Nonce
HMAC 서명값

HMAC은 메시지와 공유 비밀키를 해시 함수와 결합하여 생성하는 메시지 인증 코드로, 메시지 무결성과 송신자 인증을 제공한다. API 요청 검증에서는 요청 파라미터, Timestamp, Nonce 등에 대해 HMAC 값을 생성하고 서버가 이를 검증하여 위변조와 재전송 공격을 줄일 수 있다.

MAC은 송신자와 수신자가 같은 비밀키를 공유한다.
따라서 둘 중 누가 MAC을 만들었는지 제3자에게 증명하기 어렵다.

MAC/HMAC은 송수신자가 공유한 비밀키로 메시지 인증값을 생성하여 무결성과 인증을 제공하지만, 같은 키를 공유하므로 제3자에게 누가 생성했는지 증명하기 어려워 부인방지를 제공하기 어렵다. 전자서명은 송신자의 개인키로 서명하고 공개키로 검증하므로 인증, 무결성, 부인방지를 제공한다.

전자서명은 송신자가 자신의 개인키로 메시지 또는 메시지 해시값에 서명하고, 수신자가 송신자의 공개키로 이를 검증하여 서명자 인증, 데이터 무결성, 부인방지를 제공하는 기술이다.

전자서명 = 누가 보냈고, 바뀌지 않았고, 나중에 부인할 수 없음을 증명

인증
무결성
부인방지

전자서명 = 인증 + 무결성 + 부인방지

1. 송신자가 메시지를 작성한다.
2. 메시지의 해시값을 계산한다.
3. 송신자의 개인키로 해시값에 서명한다.
4. 메시지와 서명값을 수신자에게 보낸다.
5. 수신자는 메시지의 해시값을 다시 계산한다.
6. 송신자의 공개키로 서명값을 검증한다.
7. 두 해시값이 일치하면 무결성과 서명자 인증이 확인된다.

개인키로 서명
공개키로 검증

공개키 암호화는 수신자의 공개키로 암호화하고 수신자의 개인키로 복호화하여 기밀성을 제공한다. 전자서명은 송신자의 개인키로 서명하고 송신자의 공개키로 검증하여 인증, 무결성, 부인방지를 제공한다.

인증서는 공개키와 소유자의 신원 정보를 인증기관이 전자서명하여 보증한 전자 문서이다.

인증서 = 이 공개키가 정말 이 사람 또는 이 서버의 것이라고 보증하는 문서

접속한 도메인과 인증서의 도메인이 일치해야 한다.

CA는 사용자나 서버의 신원을 확인하고, 공개키와 신원 정보를 포함한 인증서를 발급·서명·관리하는 신뢰 기관이다.

CA는 공개키가 누구의 것인지 신뢰할 수 있게 보증한다.

RA는 인증서 발급 전 신청자의 신원 확인과 등록 업무를 수행하고, 그 결과를 CA에 전달하는 기관이다.

RA = 신원 확인 담당
CA = 인증서 발급·서명 담당

CA는 공개키와 신원 정보를 포함한 인증서를 발급하고 자신의 개인키로 서명하여 신뢰를 보증하는 인증기관이다. RA는 인증서 발급 전 신청자의 신원 확인과 등록 업무를 수행하고, 확인 결과를 CA에 전달하는 등록기관이다.

PKI는 공개키 암호를 안전하게 사용하기 위해 인증기관, 등록기관, 인증서, 인증서 저장소, 폐지 확인 체계 등을 통해 공개키와 사용자 신원을 관리하는 기반 구조이다.

PKI = 공개키를 믿을 수 있게 만드는 신뢰 체계

공개키와 신원 정보 연결
CA의 전자서명
인증서 신뢰 체인
폐지 여부 확인
인증서 정책 관리

PKI는 공개키가 실제 소유자의 것인지 신뢰할 수 있도록 CA, RA, 인증서, CRL, OCSP 등을 통해 공개키와 신원 정보를 관리하는 체계이다. 이를 통해 공개키 위조와 중간자 공격 위험을 줄이고, 전자서명과 HTTPS 같은 공개키 기반 서비스를 안전하게 사용할 수 있다.

루트 CA 인증서
→ 중간 CA 인증서
→ 서버 인증서

루트 CA 개인키를 직접 자주 사용하면 위험하기 때문에 중간 CA를 통해 운영 위험을 줄인다.

인증서 검증 시 신뢰된 루트 CA까지 인증서 체인이 연결되는지 확인하고, 각 인증서의 전자서명을 검증해야 한다. 또한 유효기간, 접속 도메인과 인증서의 도메인 일치 여부, CRL 또는 OCSP를 통한 폐지 여부, 인증서 사용 목적과 알고리즘 안전성을 확인해야 한다.

CRL은 CA가 발급한 인증서 중 폐지된 인증서의 일련번호를 목록 형태로 제공하는 인증서 폐지 확인 방식이다.

CRL = 폐지된 인증서 목록 파일

OCSP는 특정 인증서의 폐지 여부를 OCSP 서버에 실시간으로 질의하여 확인하는 프로토콜이다.

OCSP = 이 인증서 아직 유효한가요? 라고 실시간으로 물어보는 방식

CRL은 CA가 폐지된 인증서 목록을 배포하고 검증자가 이를 다운로드하여 확인하는 방식이다. OCSP는 특정 인증서의 폐지 여부를 OCSP 서버에 실시간으로 질의하는 방식으로, 필요한 인증서 상태만 확인할 수 있지만 OCSP 서버 가용성과 응답 지연 문제가 있을 수 있다.

OCSP Stapling = 서버가 OCSP 응답을 대신 첨부하여 클라이언트의 직접 OCSP 질의를 줄이는 방식

1. 사용자가 https://example.com에 접속한다.
2. 서버가 인증서를 제시한다.
3. 브라우저는 인증서의 도메인이 example.com과 일치하는지 확인한다.
4. 인증서가 신뢰된 CA 체인으로 이어지는지 확인한다.
5. 인증서 유효기간과 폐지 여부를 확인한다.
6. 인증서 서명을 검증한다.
7. 검증에 성공하면 서버를 신뢰하고 TLS 통신을 진행한다.

HTTPS의 자물쇠 표시는 통신 구간이 암호화되고 인증서 검증이 성공했다는 의미이지, 해당 사이트의 모든 내용이 안전하다는 뜻은 아니다.

HTTPS에서 브라우저는 서버 인증서가 신뢰된 CA로 이어지는지, 접속 도메인과 인증서 도메인이 일치하는지, 유효기간이 지나지 않았는지, 폐지되지 않았는지, 전자서명이 유효한지 확인한다. 검증에 성공하면 TLS를 통해 서버 인증과 암호화 통신을 수행할 수 있다.

인증서 경고를 무시하면 중간자 공격이나 피싱 사이트에 노출될 수 있다.

암호화 저장
접근권한 제한
HSM 사용
백업 보호
키 사용 로그 기록
주기적 교체
유출 시 인증서 즉시 폐지

개인키가 유출되면 전자서명 위조, 서버 위장, 중간자 공격 등이 가능하므로 안전하게 보호해야 한다. 이를 위해 개인키 암호화 저장, 접근권한 제한, HSM 사용, 백업 보호, 키 사용 로그 기록, 유출 시 인증서 폐지와 재발급을 수행해야 한다.

자체 서명 인증서는 인증기관이 아닌 인증서 소유자가 자신의 개인키로 직접 서명한 인증서이다.

자체 서명 인증서 = 암호화는 가능할 수 있지만, 신뢰된 신원 보증이 부족

1. 서버는 인증서를 제시한다.
2. 인증서에는 서버 공개키와 도메인 정보가 들어 있다.
3. CA는 인증서에 전자서명하여 이 공개키가 해당 도메인의 것임을 보증한다.
4. 브라우저는 인증서 체인을 따라 신뢰된 루트 CA까지 검증한다.
5. 인증서 유효기간, 도메인 일치, 폐지 여부를 확인한다.
6. 검증이 성공하면 서버 공개키 또는 키 교환으로 안전한 세션키를 만든다.
7. 실제 데이터는 대칭키로 암호화되고, 무결성도 함께 검증된다.

해시 함수는 임의 길이의 데이터를 고정 길이 해시값으로 변환하는 일방향 함수이다. 원문이 조금만 변경되어도 해시값이 달라지므로 데이터 무결성 검증에 활용되며, 비밀번호 저장 시에는 원문 대신 사용자별 솔트를 적용한 해시값을 저장하는 데 사용된다.

솔트는 비밀번호 해시 계산 시 함께 사용하는 사용자별 임의 값으로, 동일한 비밀번호라도 서로 다른 해시값이 생성되도록 한다. 이를 통해 레인보우 테이블 공격과 동일 비밀번호 사용자 식별을 어렵게 하고, 공격자가 사용자별로 해시를 다시 계산해야 하므로 사전 공격 비용을 증가시킬 수 있다.

MAC/HMAC은 송수신자가 공유한 비밀키를 이용해 메시지 인증값을 생성하여 무결성과 메시지 인증을 제공한다. 그러나 같은 비밀키를 양측이 공유하므로 제3자에게 누가 생성했는지 증명하기 어려워 부인방지를 제공하기 어렵고, 전자서명은 송신자의 개인키로 서명하고 공개키로 검증하므로 인증, 무결성, 부인방지를 제공한다.

전자서명은 송신자가 자신의 개인키로 메시지 또는 메시지 해시값에 서명하고, 수신자가 송신자의 공개키로 이를 검증하는 기술이다. 이를 통해 서명자 인증, 데이터 무결성, 부인방지를 제공할 수 있다.

PKI는 공개키 암호를 안전하게 사용하기 위해 공개키와 사용자 신원을 인증서로 연결하고 이를 발급·검증·폐지하는 공개키 기반 구조이다. 주요 구성요소로는 인증서를 발급·서명하는 CA, 신청자 신원을 확인하는 RA, 인증서, 인증서 저장소, 폐지 목록인 CRL, 인증서 상태를 실시간 확인하는 OCSP 등이 있다.

CRL은 CA가 폐지된 인증서 목록을 배포하고 검증자가 이를 다운로드하여 인증서 폐지 여부를 확인하는 방식이다. OCSP는 특정 인증서의 폐지 여부를 OCSP 서버에 실시간으로 질의하는 방식으로, 필요한 인증서 상태만 확인할 수 있지만 OCSP 서버 가용성과 응답 지연 문제가 있을 수 있다.

HTTPS 접속 시 브라우저는 서버 인증서가 신뢰된 루트 CA까지 이어지는 인증서 체인을 갖는지 확인하고, 각 인증서의 전자서명을 검증한다. 또한 인증서 유효기간, 접속 도메인과 인증서 도메인의 일치 여부, CRL 또는 OCSP를 통한 폐지 여부, 인증서 사용 목적과 서명 알고리즘의 안전성을 확인한다.

해시 함수는 임의 길이 데이터를 고정 길이 해시값으로 변환하는 일방향 함수로, 무결성 검증과 비밀번호 저장에 사용된다.

MD5와 SHA-1은 충돌 취약성이 있어 보안 목적 사용을 지양하고, SHA-2 또는 SHA-3 계열을 사용하는 것이 바람직하다.

비밀번호는 평문이나 단순 인코딩으로 저장하지 않고, 사용자별 솔트와 느린 비밀번호 해시 방식을 적용해 저장해야 한다.

솔트는 동일한 비밀번호라도 사용자마다 다른 해시값이 생성되도록 하여 레인보우 테이블 공격과 동일 비밀번호 식별을 어렵게 한다.

MAC/HMAC은 공유 비밀키를 이용해 메시지의 무결성과 인증을 제공하지만, 같은 키를 공유하므로 전자서명처럼 강한 부인방지를 제공하기는 어렵다.

전자서명은 송신자의 개인키로 서명하고 송신자의 공개키로 검증하며, 인증·무결성·부인방지를 제공한다.

공개키 암호화는 수신자의 공개키로 암호화하고 수신자의 개인키로 복호화하여 기밀성을 제공한다.

인증서는 공개키와 소유자의 신원 정보를 인증기관이 전자서명하여 보증한 전자 문서이다.

CA는 인증서를 발급·서명·폐지 관리하는 인증기관이고, RA는 인증서 신청자의 신원 확인과 등록 업무를 수행하는 기관이다.

PKI는 CA, RA, 인증서, CRL, OCSP 등을 통해 공개키와 신원 정보를 신뢰할 수 있게 관리하는 기반 구조이다.

CRL은 폐지된 인증서 목록을 다운로드해 확인하는 방식이고, OCSP는 특정 인증서의 상태를 실시간 질의하는 방식이다.

HTTPS 인증서 검증 시 신뢰 체인, 전자서명, 유효기간, 도메인 일치, 폐지 여부, 사용 목적을 확인해야 한다.

개인키가 유출되면 전자서명 위조, 서버 위장, 중간자 공격이 가능하므로 암호화 저장, 접근통제, HSM 사용 등으로 보호해야 한다.

1. 해시 함수란 무엇인가?
2. 해시 함수의 주요 특징 4가지를 쓰시오.
3. 충돌이란 무엇인가?
4. MD5와 SHA-1을 보안 목적에 사용하면 안 되는 이유는 무엇인가?
5. SHA-2 계열 해시 함수 예시 2가지를 쓰시오.
6. 암호화와 해시의 차이를 쓰시오.
7. 비밀번호 저장 시 해시를 사용하는 이유는 무엇인가?
8. 솔트란 무엇인가?
9. 솔트가 레인보우 테이블 공격 완화에 도움이 되는 이유는 무엇인가?
10. 단순 SHA-256만으로 비밀번호 저장이 충분하지 않을 수 있는 이유는 무엇인가?
11. MAC이란 무엇인가?
12. HMAC이란 무엇인가?
13. MAC/HMAC이 제공하는 보안 속성은 무엇인가?
14. MAC/HMAC이 전자서명처럼 부인방지를 제공하기 어려운 이유는 무엇인가?
15. 전자서명이란 무엇인가?
16. 전자서명이 제공하는 보안 속성 3가지를 쓰시오.
17. 전자서명에서 개인키와 공개키는 각각 어떻게 사용되는가?
18. 공개키 암호화와 전자서명의 차이를 쓰시오.
19. 인증서란 무엇인가?
20. 인증서에 포함되는 주요 정보 5가지를 쓰시오.
21. CA란 무엇인가?
22. RA란 무엇인가?
23. CA와 RA의 차이를 쓰시오.
24. PKI란 무엇인가?
25. PKI 구성요소 5가지를 쓰시오.
26. 인증서 체인이란 무엇인가?
27. CRL이란 무엇인가?
28. OCSP란 무엇인가?
29. CRL과 OCSP의 차이를 쓰시오.
30. HTTPS 인증서 검증 항목 5가지를 쓰시오.
31. 인증서 폐지가 필요한 경우 3가지를 쓰시오.
32. 개인키 보호가 중요한 이유는 무엇인가?

33. 파일이 다운로드 중 변조되었는지 확인하고 싶다.
34. 서로 다른 두 파일이 같은 해시값을 갖도록 만들 수 있다면 문제가 된다.
35. 비밀번호 원문을 저장하지 않고 로그인 검증을 하고 싶다.
36. 같은 비밀번호를 쓰는 사용자들의 해시값이 모두 같게 나타난다.
37. API 요청 파라미터가 중간에서 변조되지 않았는지 비밀키로 검증하고 싶다.
38. 계약서 작성자가 나중에 서명 사실을 부인하지 못하게 하고 싶다.
39. 송신자의 개인키로 서명하고 공개키로 검증한다.
40. 공개키가 실제 서버의 것인지 신뢰할 수 있게 보증하고 싶다.
41. 인증서 신청자의 신원을 확인하는 기관이 필요하다.
42. 폐지된 인증서 목록을 내려받아 확인한다.
43. 특정 인증서가 폐지되었는지 실시간으로 확인한다.
44. 브라우저가 서버 인증서의 도메인과 접속 도메인이 일치하는지 확인한다.
45. 서버 인증서 개인키가 유출되어 더 이상 인증서를 신뢰할 수 없다.

46. 해시 함수의 특징과 용도를 설명하시오.

47. 비밀번호 저장 시 솔트가 필요한 이유를 설명하시오.

48. MAC/HMAC과 전자서명의 차이를 설명하시오.

49. 전자서명의 개념과 제공하는 보안 속성을 설명하시오.

50. PKI의 개념과 구성요소를 설명하시오.

51. CRL과 OCSP의 차이를 설명하시오.

52. HTTPS 인증서 검증 절차를 설명하시오.