대칭키 암호화
동일한 키를 사용하여 암호화와 복호화를 하는 방식으로, 서버와 클라이언트 양쪽이 동일한 키(=대칭키)를 가지도록한다.
암호화를 할 때는 데이터와 키를 특정 알고리즘에 넣어서 돌리면 되고, 복호화를 할 때는 데이터와 키를 그 알고리즘에 넣어서 거꾸로 돌리면 된다.
즉, 대칭키를 서버와 클라이언트만 가지고 있다면 전송 과정의 데이터를 누군가 훔쳐보더라도 그 내용을 알아볼 수 없게 된다.
그러나 이러한 대칭키를 서버와 클라이언트가 서로 공유하기 위해서는 최소 한 번은 그 대칭키를 전송하는 과정을 필요하다는 문제가 있다.
만약 이 과정에서 그 대칭키가 탈취당한다면 암호화가 아무 의미 없어지는 것이다.
이를 보완하기 위해 등장한 방식이 바로 비대칭키(공개키) 암호화 방식이다.
비대칭키(공개키) 암호화
암호화와 복호화를 할 때 서로 다른 키를 사용하는 방식으로, 서버는 자신만의 개인키를 가지고 있고 이에 대응되는 공개키는 누구나 가지고 있을 수 있도록 공개한다.
개인키로 암호화된 데이터는 이에 대응되는 공개키로만 복호화가 가능하며, 공개키로 암호화된 데이터는 이에 대응되는 개인키로만 복호화가 가능하다.
따라서 서버에게 데이터를 전송할 때 해당 서버의 공개키로 암호화를 하면 누군가 훔쳐보더라도 해당 서버의 개인키를 가지고 있지 않아서 그 내용을 알아볼 수 없게 된다.
CA
인터넷 상에 존재하는 수 많은 사이트들은 CA라고 불리는 공인 민간 기업들로부터 신뢰할 만한 사이트임을 인증할 수 있는 인증서를 발급받는다.
CA로부턴 발급되는 인증서는 인증받는 서버와 공개키 정보를 포함하고 있으며, 해당 CA의 개인키로 암호화가 되어 있다.
Handshake(사이트의 안정성 판별)
처음에는 클라이언트가 서버를 완전히 신뢰할 수 없기 때문에 그 사이트의 안정성을 판별하기 위한 Handshake(악수)의 과정을 밟는다.
클라이언트는 특정 랜덤 데이터를 생성해서 서버에게 보내고, 그것을 받은 서버는 또 다른 랜덤 데이터를 생성하여 자신이 CA로부터 발급받은 인증서와 함께 클라이언트에게 보내는 것이다.
그러면 클라이언트는 브라우저에 내장되어 있는 CA들의 정보를 통해 해당 인증서가 정말 CA로부터 발급받은 인증서인지 확인한다.
모든 브라우저는 각 CA의 공개키를 이미 알고 있고 CA로부터 발급받는 인증서는 해당 CA의 개인키로 암호화가 되어 있기 때문에, 정말로 CA로부터 발급받은 인증서가 맞다면 복호화가 가능할 것이다.
만약 브라우저가 알고 있는 CA의 개인키로 복호화가 불가능하다면 안정하지 않음 표시가 뜰 것이다.
대칭키 + 비대칭키(공개키) 암호화
Handshake의 과정이 성공적으로 끝나고 나면, 복호화된 서버의 인증서로부터 해당 서버의 공개키를 얻게 된다.
비대칭키(공개키) 암호화 방식은 대칭키 암호화 방식에 비해 알고리즘이 복잡하여 컴퓨터에 많은 부담을 준다고 알려져 있다.
따라서 수많은 데이터들을 주고 받을 때마다 매번 비대칭키 방식을 사용하는 것은 좋지 못하다.
따라서 데이터를 주고받을 때는 대칭키 암호화 방식을 사용하게 된다.
최초에 대칭키를 공유할 때만 비대칭키(공개키) 암호화 방식을 사용하게 된다.
이전에 Handshake 과정이 끝나고 나면 클라이언트에는 두 종류의 랜덤 데이터가 존재한다는 것을 알 수 있다.
하나는 클라이언트에서 생성했던 랜덤 데이터이고, 나머지 하나는 서버가 만들어서 보내준 랜덤 데이터이다.
클라이언트는 이 둘을 섞어서 특정 임시키를 생성하고, 이 임시키를 서버의 공개키로 암호화하여 서버로 전송하며, 서버는 그 임시키를 자신의 개인키로 복호화한다. 이제 클라이언트와 서버가 동일한 어떤 방식으로 그 임시키를 조작하면 동일한 대칭키가 생성이 된다.
결국, 둘의 통신을 위한 대칭키는 오직 둘만 가지고 있게 되기 때문에 안전한 데이터 통신이 가능해진다.
출처
