1. 디지털 서명
암호 체계는 메시지를 암호화하고 해독하는 것뿐 아니라, 누가 메시지를 썼는지 알려주고 그 메시지가 위조되지 않았음을 증명하기 위해 메시지에 서명을 하도록 하는 데에 이용될 수 있다. 디지털 서명(digital signing)이라 불리는 이 기법은 아래에서 논의할 인터넷 보안 인증서에게 중요하다.
1) 서명은 암호 checksum
디지털 서명은 메시지에 붙어있는 특별한 암호 checksum이다. 이들은 두 가지 이점을 가진다.
- 서명은 메시지를 작성한 저자가 누군지 알려준다. 저자는 저자의 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 이 checksum을 계산할 수 있다. checksum은 저자의 개인 '서명'처럼 동작한다.
- 서명은 메시지 위조를 방지한다. 만약 악의적인 공격자가 송신 중인 메시지를 수정했다면, checksum은 더 이상 그 메시지와 맞지 않게 될 것이다. 그리고 checksum은 저자의 비밀 개인 키에 관련되어 있기 때문에, 침입자는 그 위조된 메시지에 대한 올바른 checksum을 날조해낼 수 없을 것이다.
디지털 서명 동작 방식
그림 14-10은 어떻게 노드 A가 노드 B에게 메시지를 보내고 그것을 서명하는지 보여준다.
- 노드 A는 메시지를 정제하여 고정될 길이의 요약(digest)으로 만든다.
- 노드 A는 그 요약에, 사용자의 개인 키를 매개변수로 하는 '서명' 함수를 적용한다. 오직 그 사용자만 개인 키를 알고 있기 때문에, 올바른 서명 함수는 서명자가 소유자임을 보여준다.
- 서명이 계산되면, 노드 A는 그것을 메시지의 끝에 덧붙이고 메시지와 그에 대한 서명을 노드 B에게 전송한다.
- 메시지를 받은 노드 B가, 만약 그 메시지를 쓴 것이 정말로 노드 A이며 동시에 위조되지도 않았다는 것을 확인하기 원한다면, 노드 B는 서명을 검사할 수 있다. 노드 B는 개인 키로 알아보기 어렵게 변형된 서명에 공개 키를 이용한 역함수를 적용한다. 만약 풀어낸 요약(digest)이 노드 B가 갖고 있는 버전의 요약과 일치하지 않는다면, 메시지가 송신 중에 위조되었거나 발송자가 노드 A가 아닌 것이다.
2. 디지털 인증서
디지털 인증서(Digital Certificate)는 보안이 필요한 통신에서 상대방이 통신하고자 하는 대상이 맞음을 확인해주는 역할을 한다.
1) 인증서를 사용하는 이유
특정 서버에 요청을 주고 받을 대 수많은 라우터와 스위치를 거치게 되는데, 그 중간에서 누군가 우리의 패킷을 훔쳐볼 수 있다. 만약 네트워크 데이터가 암호화된다면, 중간에 공격자가 패킷을 열람하더라도 데이터가 유출되는 것을 막을 수 있다. 오늘날 가장 널리 쓰이고 있는 암호화 방식이 SSL/TLS 라는 것인데, 이 방식은 '인증서'라고 하는 일종의 서명을 사용한다.
서버와 클라이언트 간 보안 연결은 크게 두 가지 단계로 이뤄진다.
- 클라이언트의 CA를 통해 서버 인증서가 신뢰 가능한지 확인. 즉, 서버가 신뢰할 수 있는 대상인지 인증서를 통해 검증함
- 보안 연결 수립. 즉, 서버-클라이언트 간에 생성된 대칭 키를 생성하고 이를 통해 네트워크 데이터를 암호화해 전송함
2) CA
CA(Certificate Authority)는 디지털 인증서를 발급해주는 신뢰할 수 있는 기관이다. 그 중에서도 Root CA는 최상위 인증 기관으로, 인증서를 발급하는 기관이다.
이 Root CA는 본인들만의 고유한 비밀 키를 가지고 있고, 이에 대응하는 공개 키를 전 세계에 배포한다. 이 기관의 공개 키로 복호화가 가능한 데이터는 그 기관의 비밀 키로 암호화되었기 때문에 믿을 수 있는 데이터로 간주한다. 일반적으로 이렇게 신뢰 가능한 기관의 공개 키는 이미 웹 브라우저에 내장되어 있다.
3) 인증서의 내부
디지털 인증서에는 공식적으로 '인증 기관'에 의해 디지털 서명된 정보의 집합이 담겨있다. 기본적인 디지털 인증서는 보통 다음과 같은 것들을 담고 있다.
- 인증서 소유자 이름
- 인증서 소유자의 공개 키(비밀 키는 소유자가 가지고 있음)
- 인증서 유효 기간
- 인증서의 내용을 종합한 hash 값을 암호화한 값(지문)
그림 14-11은 일반적인 인증서의 구조를 보여준다.
4) 인증서의 구조
Geotrust <-> Google CA 예시(2계층)
인증서는 계층 구조로 되어있다. 보통 3계층 구조로 되어있고, 최상위에 위치한 인증서는 일반적으로 Root 인증서라고 불린다. Root 인증서는 Root CA에서 발급한 인증서로, 일반적으로 웹 브라우저에 미리 내장되어 있으며, 해당 인증서에 대응하는 공개 키 또한 인증서 내부에 포함되어 있다.
Google CA 회사는 자신의 인증서를 만들기 위해 Geotrust에게 다음과 같이 요청한다. 인증서의 내용물을 주면, 그 인증서의 내용을 종합한 hash 값을 Geotrust의 비밀 키로 암호화한 값을 반환해주기를 요청한다. 이렇게 하면 얻는 효과는 다음 두 가지이다.
- Chain of Trust의 원리에 의해 하위 인증서가 신뢰할 수 있는지 알 수 있음. 즉, Google CA의 인증서를 Geotrust의 공개 키로 복호화할 수 있다면 해당 인증서도 신뢰할 수 있게 됨
- 해당 Geotrust의 공개 키로 복호화한 hash 값과 Google CA 인증서 내용을 직접 종합해 만든 hash 값을 비교해 내용물이 변조되었는지를 확인할 수 있다.
Geotrust <-> Google CA <-> 개인 인증서 예시(3계층)
Google CA와 같은 중간 인증서 기관을 ICA(Intermediate CA)라고 부른다. 이러한 ICA 또한 일반적으로 신뢰할 수 있는 회사로 구성되어 있기 때문에 신뢰할 수 있는 인증서 목록에 기본적으로 ICA가 등록되어 있다.
개인이 인증서를 발급 받으려면 일반적으로 Root 인증서가 아닌 ICA에 인증서의 사인(인증서 내용물 hash 값의 암호화)을 요청하게 된다.
Geotrust와 Google CA 예시에서 봤던 것처럼, alicek106 인증서에 저장된 암호화된 hash 값은 Google CA로만 복호화할 수 있다. Chain of Trust 원리에 의해 alicek106의 인증서 또한 Geotrust에 의해 신뢰할 수 있는 인증서를 갖게 된다.
5) 보안 연결 수립 과정
개인이 ICA로부터 인증서를 발급 받았고, 이를 웹사이트에 등록했다. 클라이언트가 해당 웹 서버에 접속해 데이터를 주고 받으려고 할 때, 보안 연결 수립을 위해 어떤 과정이 발생하는지 알아보자.
클라이언트가 웹사이트에 접근하면 서버 측에서는 자신의 인증서 및 ICA 인증서를 클라이언트에게 전송한다. 물론, 클라이언트의 웹 브라우저의 '신뢰할 수 있는 인증서' 목록에는 Root CA의 인증서, ICA의 인증서 등이 포함되어 있다.
위 그림처럼 클라이언트에게 ICA 인증서와 alicek106의 인증서가 함께 전달되고, 웹 브라우저에 등록된 인증서(공개 키)에 의해 alicek106 인증서가 신뢰할 수 있는지 확인한다. alicek106의 인증서가 상위 인증서에 의해 신뢰할 수 있음을 확인하고 나면 클라이언트는 alicek106 인증서에 내장되어 있는 공개 키를 꺼내 사용하게 된다.
비대칭 키의 암호화/복호화는 대칭 키에 비해 자원을 많이 사용하기 때문에 클라이언트와 서버가 최초로 비밀 값을 주고 받을 때에만 비대칭 키를 통해 암호화한다. 즉, 서버와 클라이언트 간에 처음 연결을 수립할 때만 비대칭 키를 사용하고 보안 연결 수립 뒤에는 대칭 키로 패킷을 암호화해 전송한다.
전체적인 과정을 한 눈에 정리하면 다음과 같다.
참고
