대칭키 암호화와 비대칭키 암호화
- 대칭키 : 키가 하나라 빠르고 편한데 보안이 상대적으로 취약하다.
- 비대칭 키는 반드시 공개키로 암호화, 개인키로 복호화 하는건 아니다. 암호화 - 복호화에 관련된 키 중 하나가 비공개여서 어느 한 과정을 해커가 알 수 없는 것이라고 보는게 맞다.
공개키로 암호화화면 개인키로 복호화하고, 개인키로 암호화하면 공개키로 복호화 한다.
인증서와 디지털 서명
네트워크에서 사용되는 인증서는 일반적으로 공개 키 인증서를 말한다.
공개 키 인증서는 공개 키와 그 키의 유효성을 입증하기 위한 전자 문서이다.
내가 특정 서버와 공개 키 암호화 방식으로 통신할때, 우리 컴퓨터는 서버에게서 공개 키를 받는다.
근데 이게 정말 믿을 수 있는 공개 키인지, 조작된 건 아닌지 우리가 알 수 있을까?🤔 단순히 공개 키 하나 받은 걸로는 믿을 수 없다.
그래서 서버는 공개 키만 주는게 아니라 그 공개키를 누가 만들었는지, 조작되지 않았는지, 유효기간은 언제인지 등의 내용을 포함한 인증서를 같이 보내준다. 이 인증서는 인증기관(CA, Certification Authority) 이라는 제 3의 기관에서 발급된다.
-> CA가 발급한 인증서에는 서명 값이 있다. 클라이언트는 이 서명 값을 바탕으로 인증서를 검증할 수 있다.
서명 값은 '인증서 내용에 대한 해시 값을 CA의 개인 키로 암호화'
'인증서 내용: ABC' -> 해시 : 3zxc
'인증서 내용을 해시처리하고 개인키로 암호화한 값' : asdasd -> 공개키로 복호화 : 3zxc (인증서 내용을 해시 처리한 값)
이렇게 서명값이 붙은 인증서를 전달받았다면, 가장 먼저 할 일은 서명 값과 인증서를 분리하는 것.
서명값은 인증서 내용에 대한 해시 값을 CA의 개인키로 암호화 한 것 이라고 했다.
CA의 공개 키는 공개되어 있으니, 서명 값은 CA의 공개 키로 복호화 할 수 있다.
서명 값을 CA의 공개 키로 복호화 하면 인증서 내용에 대한 해시 값을 얻을 수 있다.
해당 해시 값을 실제 인증서를 해싱한 결과값과 비교하여 일치하는 지 확인.
만약 값이 일치한다면 전달받은 인증서는 인증기관의 암호화를 거친게 맞는 것!
기본적으로 HTTP는 80번 포트에서 대기하고, 클라가 TCP 80번으로 접속하면 서버와 요청을 주고받는다.
그런데 HTTP는 정보를 텍스트로 주고받기 때문에 네트워크에서 인터셉트 하면 정보 유출의 위험이 있다.
HTTPS는 앞서 우리가 학습한 인증서와 디지털 서명 개념이 들어가 있다.
인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지 보장하는 역할을 한다.
그리고 인증서를 발급하는 기관을 CA라고 부른다고 했다.
인증서 발급 과정
- 사이트는 사이트 정보와 공개키를 인증기관에 제공 (이거 계약하고 돈 지불하는거임)
- 인증기관은 검증 후 그 정보들을 인증기관 개인키로 암호화
- 인증기관이 사이트에게 인증서 발급 - 이 인증서 안에 인증기관 개인키로 암호화 한 정보 들어있음
- 인증기관이 인증기관 공개키를 브라우저에 제공
-> 웹 브라우저는 공인인증기관 리스트와 각각 인증기관의 공개키를 알고 있다!
사용자 - 사이트의 인증서 사용 과정
- 사용자가 브라우저를 통해 사이트에 접속
- 사이트는 발급받은 인증서를 전달
- 인증기관의 공개키로 해독
- 해독하면 사이트 정보와 서버의 공개키가 나옴 -> 이 서버 공개키로 대칭키를 암호화!
- 서버 공개키로 암호화된 대칭키 전송 - 사이트 개인키로 암호화된 대칭키 해독
-> 키 교환이 이루어져서 받게되는 대칭키를 세션키 라고 부른다.
