HTTPS 공개키와 개인키 개념

Bright Hyeon·2022년 4월 23일

HTTPS

먼저 HTTPS가 뭔지를 간략히! 말씀드리자면 HTTP + Secure입니다!
HTTP로만 정보를 보낸다면, 다른 누군가가 이 정보를 쉽게 탈취하여 있는 그대로 읽을 수 있게 됩니다.
하지만 HTTPS를 통해 정보를 보내면, 이 정보는 알 수 없는 문자열로 암호화되어 있게되어 안전합니다.

기관으로부터 검증된 사이트만 주소에 HTTPS 사용이 허가되고, 그냥 HTTP를 주소창에 사용하는 사이트는 ‼️안전하지않다라는 표시가 뜨게됩니다.

결론적으로, 요약하자면, HTTPS는
1. 내가 사이트에 보내는 정보들을 제3자가 못보게한다.
2. 접속한 사이트가 믿을 만한 곳인지를 알려준다.

HTTP

프로토콜 규약
컴퓨터에게 내가 보낸 형식이 HTTP형식이야~!라고 알려줘야 서버가 "아~ HTTP형식으로 읽어야징~!"할 수 있다~!
여기에 +보안을 한것이 HTTPS고~!

대칭키 vs 비대칭키

‼️ 공개키와 개인키에 대한 개념을 알려면, 먼저 대칭키와 비대칭키에 대해 알아야한다~!

대칭키

Example) 전쟁에서 아군끼리 메세지를 주고받을 때, 내용을 암호화해서 보내야 적군이 이를 읽을 수가 없겠죠.
Key개념이 바로 이런 것입니다.
대칭키는 메세지를 주는 쪽과 받는 쪽의 복호화하는 방식이 같은 것을 뜻합니다. 즉, 복호화를 하는 키가 서로 같다는 개념이죠.
암튼! 이 복호화 표 or 키만 노출되지않는다면, 적군(해커)들은 이 내용을 읽을 수가 없게되죠.
Key형태 예시) a084#l%^q3_97

Problems

결국 문제는, 처음에 이 복호화키(대칭키)를 어떻게?! 공유하냐입니다.

결국 최소 한 번은 한쪽에서 다른 한 쪽으로 이 key를 전송해야하는데 말이죠.

이 과정에서 Key가 노출된다면, 말짱도루묵이 되버리는데, 이게 대칭키의 "한계"입니다.

비대칭키 (공개키 & 개인키)

대칭키의 Problems을 보완한 개념. (1970년대 수학자들에 의해 개발됨)
두 개의 키는 한 쌍이다.
이 개념을 보통 그냥 공개키 개념이라 부릅니다.
대칭키의 경우 같은 키로 암호화를 하고, 다시 같은 키로 복호화를 수행하지만, 비대칭키의 경우 A키로 암호화한 것은 B키로만 복호화를 수행할 수 있고, 반대로 B키로 암호화한 것은 A키로만 복호화를 수행할 수 있습니다.

사용 형태

Server는 이 한 쌍의 키 중에 하나는 비밀로 보관하고(개인키), 다른 하나는 대중들에게 공개합니다.(공개키)

그럼 이제 사용자가 자신의 비밀번호를 암호화해서 Server에 보낼 때, 이를 탈취당하더라도, 탈취자는 개인키를 모르고, 같은 공개키만 가지기에 이 암호를 풀어낼 수가 없다‼️ (같은 키로는 암호한것을 풀 수 없기에~!)

이를 읽어낼 수 있는건 같은 공개키가 아닌 Server가 지닌 개인키입니다.

그럼 이 사이트가 우리 사이트인 것은 어떻게 증명하는가?

애초에 우리 서버에서 보내준 정보는 울 서버의 개인키로 암호화된 정보이고, 이를 읽을 수 있는 것은 우리가 받았던 공개키뿐입니다.

그러니, 수상한 사이트(서버)에서 보낸 정보는 우리의 공개키와 맞지않기 때문에 이상함을 알 수 있고요. (에러)

마지막으로 이 공개키가 우리 서버의 정품인 것은 어떻게 알 수 있는가?

애초에 공개키가 수상한 사이트가 준 공개키라면 수상한 사이트가 준 정보를 옳은 정보로 인식할 수 있잖아⁉️

정품 공개키인지를 인증해주는 공인된 민간기업들이 있습니다.

CA (Certificate Authority)

공개키가 정품인지를 인증해주는 공인된 민감기업들을 칭하는 말.
Below are the best SSL certificate providers of...를 검색해보면 어떤 회사들이 있는지 알 수 있다.
아무나 차려서 되는게 아니라, 엄격한 인증과정을 거쳐야 CA를 할 수 있다.
우리의 브라우저, 즉 크롬이나 사파리, 파이어폭스, 엣지, 익스플로러 등의 프로그램에는 이 CA들의 목록이 내장되어있다.

이런 브라우저에서 서버에 접속할 때 어떤 과정을 거치는가?

처음, 클라이언트는 아직 이 서버를 신뢰하지 못한다.

그래서 먼저 일종의 탐색과정을 거치게되는데 이걸 handshake, 악수라고 합니다.‼️

먼저 클라이언트는 어떤 랜덤 데이터를 생성해서 서버에 보냅니다.

이를 받은 서버측은 답변으로, 역시 서버측에서 생성한 1) 무작위의 데이터, 그리고 2) 해당서버의 인증서를 실어보냅니다.

이것으로 둘은 Handshake, 악수를 한 것입니다.

인증서 확인

자, 그럼이제 Client는 이 인증서가 진짜인지, (비대칭키 System을 사용해서‼️) 브라우저에 내장된 CA들의 정보를 통해 확인하게 됩니다.

CA를 통해 인증받은 정품공개키들은 해당 CA의 개인키로 암호화가 되어있습니다.

이 인증서가 진짜라면⁉️, 이 인증서는 그 CA의 공개키로 복호화할 수 있겠죠!! (아래 그림 참고)

CA측에서 Client에 자신의 개인키에 맞대응하는 공개키를 전달하게되고, 이 공개키로 인증서가 복호화된다는 것은, 즉, 정품인증서가 맞다는 것을 의미하죠‼️
만약 CA리스트 중에 이 인증서가 해당하는 것이 없다면, 브라우저 주소창에 ‼️Not Secure 표시가 뜨게 되는 것이구요~!

이렇게 성공적으로 복호화된 인증서 안에는 Server의 공개키가 내장되어 있습니다.

오! 그려면 이젠 이 비대칭키를 이용해서 메시지를 주고받으면 되는건가?

결론은 아닙니다.‼️⁉️

지금부터 주고받는 메세지는 대칭키 방식과 비대칭키 방식이 혼합되어서 사용됩니다.

아니! 비대칭키가 안전한데 왜 혼합해서 사용하는것인가요?!

비대칭키 방식으로 메시지를 암호화 및 복호화하는 것은 대칭키 방식보다 컴퓨터에 훨씬 큰‼️ 부담을 주기 때문입니다.

사이트를 이용할 때 주고받을 그 다량의 데이터를 비대칭키로 일일이 암호화, 복호화하는 것은 무리란 얘기입니다...

그래서 이 데이터는 대칭키로 암호화를 합니다.

엇? 대칭키는 탈취당할 수 있어서 위험하다하지않았나....⁉️

ㅋㅋㅋ그 대칭키!!!를 공유하는 순간에‼️ 비대칭키를 사용하면 되는 것이죸ㅋㅋㅋ Wow... 그렇네...오우야...

아까 handshake단계에서 주고받았던 이 값들을 이용해서 Client는 아래와 같은 어떤 임시 Key를 생성합니다.

이 임시키는 서버의 공개키로 암호화돼서 (공개키 인증은 완료되었으니!), 서버로 보내진다음!,

이 임시키를 일련의 과정을 통해 그들만의 대칭키‼️로 만드는 것입니다.
아래 그림 참고

이제 이 공개키는 클라이언트와 서버 단 둘만 알고있으니까, 이제는 제3자가 이것을 알아볼 걱정은 하지않아도 되는것이죠!!

💻 Summary

대칭키를 사용하면, 내용을 암호화하기에 정보를 안전히 보낼 수 있지만, 처음 이 대칭키를 공유할 때 유출되면 큰일이라는 단점이 있다.
이 때, 비대칭키를 사용해서 대칭키를 보내주면 되는 것이다.
중요한 점은, 이 정보를 보내주는 서버가 정말 공인된 곳인가를 알아야한다.
먼저, handshake를 통해, Client에서 랜덤데이터를 보내고, 이에 Server가 응답하며 랜덤데이터 + 암호화된 인증서를 보냅니다.
이 인증서가 정품이라면, 브라우저에 내장된 해당 CA의 개인키로 암호화되어있기 때문에, 이 인증서는 CA의 공개키로 복호화할 수 있는 인증서여야합니다.
성공적으로 정품 인증서가 복호화되면, 그곳엔 처음 악수했던 서버의 공개키가 담겨있습니다.
이젠 handshake당시 주고받았던 값들을 이용해서 Client는 어떤 임시Key를 생성합니다.
이 임시키는 클라이언트에서 공개키로 암호화되어 서버에 전달됩니다.
이 임시키를 일련의 과정을 통해 그들만의 대칭키로 만듭니다.
‼️이제 Client와 Server는 서로 정품인 것이 인증되었고, 비대칭방식으로 전달하여 안전하게 서로의 대칭키도 만들었으니, 이제 안전하게 정보교류를 하면되는 것입니다.‼️