암호화의 역할
기밀성(Confidentiality) : 허용된 자(인가자)들만 데이터 열람 가능
신뢰성(Authenticity) : 사용자의 진위 확인, 인증
무결성 (Integrity) : 허용된 자(인가자)만 데이터 변경 가능, 데이터의 오염도(변조)
비대칭키 암호화 방식에서는 (기밀성)
- 공개키로 암호화
- 개인키로 복호화
- 개인키를 가지고 있어야 데이터를 열람할 수 있다.
- 인가자는 개인키를 가지고 있는 자
- 공개키로 암호화하여 수신자 쪽에서 개인키로 복호화하는 것은 기밀성 보장
비대칭키 암호화 방식에서는 (신뢰성)
- 개인키로 암호화
- 공개키로 복호화
- 인증!
- 개인키로 암호화시키는 것을 전자서명이라고 함
- 공개키로 데이터가 원문이 복호화가 되는 것은 신뢰성 보장
*전자서명은 어떻게 만들어졌나?
1. 원본데이터를 HASH 알고리즘을 이용하여 해시값(digest)으로 만듭니다.
=> 원본데이터를 해시값으로 만들면 용량이 확 줄어듦
2. 이렇게 만들어진 해시값을 Private Key로 암호화합니다.
비대칭키 암호화 방식에서는 (무결성)
- 수신자 입장에서 송신자가 진짜 별을 보냈는지, 세모를 보냈는지 어떻게 알지!?
- 원본을 알아야 받은 데이터가 진짜인지 가짜인지 알 수 있음
- 송신 측은 원본/백업본 전송, 수신 측은 원본/백업본 동일성 점검
- 그러나 원본/백업본의 용량이 클 수도 있음. 즉, 이렇게 보내는 것은 무리가 될 수 있다.
- 그래서 보통 무결성을 점검할 때 hash를 사용
Hash Algorithm
hash : 하나의 문자열을 상징하는 더 짧은 길이의 값이나 키로 변환하는 것
- hello -> md5 -> 5D41402ABC4B2A76B9719D911017C592
- hello, i'm md5 -> md5 -> 1CFD52DAF70CABA2261687D6E9116CF2
- hi, i'm md5 -> md5 -> EE4FD2444E2CC44C171CAA3077BD062A
DES/3DES/RSA
- 암호화 알고리즘(양방향성)
- 원분 <->암호문
MD/SHA
- 해시 알고리즘(일방향성)
- 원문 -> 해시
SSL
▶ SSL은 Secure Socket Layer의 약자로, 응용계층을 보호하는 프로토콜
▶ TLS는 Ttransport Layer Security의 약자로, 전송 계층 상위에서 동작하여 응용계층 암호화, HTTP 패킷 보호가 주용도
대칭키 암호화 방식 : 기밀성
비대칭키 암호화 방식 : 신뢰성, 무결성
=> SSL은 두가지 방식을 모두 사용하여 암호화를 하기 때문에 안전성을 보장
[암호화 프로토콜]
2계층 : PPTP, L2TP
3계층 : IPSec
4계층 : SSL 3.0 => TLS
5계층 : SSL
4계층이 비어있었는데 SSL 3.0 이름이 TLS로 변경됨
=> HTTP가 곧바로 TCP/IP로 오면 HTTP이고, HTTP가 SS/TLS를 타고 TCP/IP로 오면 HTTPS라고 함
인증서
=> 인증서 유효함은 누가 체크하는 것일까요? 클라이언트가 확인!
=> 인증서를 누구에게 누가 발급해주었는지, 유효기간, 인증서 해시값 등을 확인할 수 있음
인증기관(CA) : 인증서를 발급해주는 기관
- CA는 개인키와 공개키 생성
- 인증기관의 인증서에는 CA의 공개키 포함
- 배포할 때 인증기관-웹브라우저회사-클라이언트 경로로 배포
- CA의 인증서를 받는다는 것은 CA의 공개키를 갖는다라고 볼 수 있음
자체 발급 인증서는 자기가 자기에게 발급해주는 인증서로, 본인 위로 최상위가 없기 때문에 Root CA(최상위 루트 CA)는 가능
웹서버
- 공개키와 개인키 생성
- CA에 인증요청서 + 공개키를 첨부하여 보냄
- CA가 발급한 인증서에는 CA 전자서명(개인키로 암호화), 웹서버의 공개키 포함
- 자체발급인증서 : 발급기관과 발급대상이 같은 경우
- 자체발급인증서는 유효성 검증 불가?? 유효성과 암호화는 별개다!
"인증서에 문제가 있습니다"는
인증서 유효기간이 끝난 경우, 유효성 검사가 불가한 경우, 자체발급인증서인 경우 발생
클라이언트가 웹서버에 접속하면 웹서버는 클라이언트에게 인증서를 줌(나 안전한 사이트야~ CA에서 인증서 발급해줬어)
클라이언트는 이 인증서가 진짜인지 확인. 어떻게?? 웹서버가 넘겨준 인증서에는 CA 전자서명이 포함되어 있고, 클라이언트는 CA의 공개키를 가지고 있음. 공개키고 전자서명을 풀어 해독이 되면 진짜! 이후 데이터 전송~!
SSL Processing
서버가 공개키와 개인키를 생성하여 클라이언트에게 인증서에 공개키를 넣어 전달
서버와 클라이언트는 동시에 공개키를 갖게 됨
=> 서버가 클라이언트에게 공개키를 준 이유? 클라이언트가 만든 대칭키를 암호화 시켜서 전달하라고 준 것!
클라이언트 쪽에서 세션키(대칭키)를 생성
이 세션키를 서버가 준 공개키로 암호화해서 서버에게 전달
서버와 클라이언트는 동일한 세션키(대칭키)를 갖게 됨
클라이언트는 자신의 개인정보(데이터)를 대칭키로 암호화를 시켜 서버로 전달
서버는 클라이언트가 준 대칭키로 복호화를 하여 데이터를 확인
=> SSL은 대칭키, 비대칭키방식을 모두 사용
=> 대칭키 : 데이터 암호화
=> 비대칭키 : 공개키 (대칭키를 암호화 시키기 위함)
[참고] HTTPS : WebClient와 WebServer 사이에 웹 문서를 암호화
공개 키 기반 구조(PKI)
- PKI는 Public Key infrastructure의 약자
- 공개키를 배포해서 데이터를 안전하게 전송할 수 있는 전체적인 인프라
- 메시지의 암호화 및 전자서명을 제공하는 복합적인 보안 시스템 환경
- 공개키를 어떻게 안전하게 배포할 것인가! 일련의 절차들을 하나로 만든 복합시스템 환경