전자서명과 CA

 

https://www.getoutsidedoor.com/2021/02/13/ssl-tls-%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C/

SSL/TLS 에 대해서 - Real Insight Comes From Fixing Error

위 글을 참고하여 공부한 내용입니다. 자세한 내용은 위 블로그를 참고해주세요.

 

전자서명

일반적으로 문서에 서명을 한다고하면 해당 문서를 읽어보았고 동의한다는 뜻으로 서명을 하게 된다. 디지털 세계에서는 서명은 해당 데이터가 자신이 보낸 데이터라는 것을 증명하기 위해서 사용된다. 이를 우리는 전자 서명이라고 부른다.

전자 서명을 한 데이터는 다음과 같은 특성을 지녀야 한다.

• 전자 서명이 된 데이터는 소유주가 자신이 서명을 했다는 것을 증명할 수 있어야 한다.
• 오직 소유주만이 전자 서명을 한 데이터를 만들 수 있어야 한다.

Bob이 m이라는 데이터에 전자 서명을 하려고 한다. Bob은 전자 서명을 하기 위해서 자신의 비공개키, KB–를 이용하여 KB–(m)을 만든다. 우리가 잘 알고 있는 RSA 알고리즘을 암호화를 하는데 사용할 수 있고 우리는 이러한 과정을 서명을 한다고 한다. 다시 한번 짚고 넘어가면 이렇게 알 수 없는 값으로 원본 데이터를 변형시키는 것은 원본 데이터를 알 수 없게 만드는 것에 목적이 있는 것이 아니라 해당 데이터를 Bob이 보냈다는 것을 증명하고자하기 위함이다.

 

https://www.getoutsidedoor.com

 

데이터 수신자 Alice는 정말 자신이 받은 데이터가 Bob으로부터 온 데이터인지 확인하고 싶다. 이런 경우 Alice는 Bob의 공개키, KB+를 가지고 전자 서명된 데이터 KB–(m)에 복호화를 시도해볼 수 있다. 복호화 결과가 원본 데이터와 동일하다면 이 데이터는 Bob이 보냈다는 것을 확신할 수 있게 된다. 그 근거는 다음과 같다.

• Alice가 받은 데이터는 비공개키 KB–를 통해서 암호화가된 데이터이다. 왜냐하면 공개키 KB+를 이용하여 복호화를 하였을 때 원본 데이터가 나왔기 때문이다.
• 비밀키 KB–를 가진 사람은 Bob뿐이다. (이 가정은 Bob이 자신의 비밀키를 다른 누구에게도 탈취당하지 않았다는 가정이 있다.)

그런데 위의 과정 중에 데이터에 전자 서명을 하는 과정 그리고 해독하는 과정에 사용되는 암호화, 복호화 과정이 컴퓨팅 리소스적으로 비싸다는 단점이 있다. 그렇기 때문에 전송하고자하는 데이터 전체에 서명을 하는 것은 너무 비효율적이다. 이러한 문제를 개선할 수 있는 방식 중 하나가 전자 서명에 해시 함수를 사용하는 것이다. 해시 함수는 간단히 말하면 어떤 함수인데 입력값으로 어떤 메세지 m을 받는다. 그리고 결과 값으로는 고정된 길이의 어떤 값 H(m)을 얻을 수 있다.

 

이제 Bob은 전체 메세지에 대해 서명을 하는 것이 아니라 전체 메세지를 해싱한 결과 값에 대해서 서명을 하게 된다. KB-(H(m)). 이전 방식과 비교해보면 H(m)은 m보다 길이가 훨씬 짧기 때문에 컴퓨팅 리소스가 적게 든다.

 

해시값을 통해서 전자 서명하는 과정을 이제 Bob이 Alice에게 메세지를 보내는 과정을 놓고 생각해보자. Bob은 먼저 원본 데이터를 해시 함수에 넣어 해시값을 만든 뒤 그 값에 자신의 비밀키를 이용해 서명을 한다. 그리고 Alice에게 원본 데이터와 전자 서명 값을 보낸다.

두 값을 받은 Alice는 Bob의 공개키를 이용하여 전자 서명에 들어있는 해시값을 얻어내고, 또한 원본 메세지를 해시값으로 만들어 두 값을 비교한다. 만약 두 값이 일치한다면 Bob이 메세지를 보냈다는 것을 알 수 있을뿐만 아니라 데이터가 중간에 변조되지 않았다는 것을 알 수 있다.

 

Public Key Certification

전자 서명을 활용한 것이 바로 public key certification이다. public key certification은 공개키가 누구의 소유인지를 증명해주는 것을 말한다. Public key certification은 보안을 위한 네트워크 프로토콜에 다양하게 응용된다. 대표적인 예가 IPsec과 아래에서 살펴볼 SSL이 있다.

 

Public key certification이 등장한 배경을 이해하기 위해서 다음과 같은 상황을 상상해보자.

Alice가 피자 배송 서비스를 운영하고 웹사이트에서 주문을 받는다. Bob은 Alice가 운영하는 피자 가게에서 평문으로 Bob의 집 주소와 주문할 피자 종류를 Alice에게 보낸다. 또한 Bob은 이 주문을 넣은 사람이 자신임을 증명할 전자 서명을 같이 보내게된다. 주문을 받은 Alice는 Bob의 공개키를 이용하여 전자 서명이 Bob의 것이 맞다는 것을 확인한다.

 

그런데 여기서도 문제가 존재한다. Alice는 사실 자신이 받은 전자 서명이 누구의 것인지 알지 못한다. 악의적인 의도를 가진 Trudy가 Bob의 배송지와 피자 종류를 메세지에 적고 Trudy의 전자 서명과 공개키를 전달하면 어떻게 될까? Alice는 전자 서명이 ‘누군가’의 것이 맞다는 것만 알 뿐 메세지를 보낸 사람이 누구인지는 알지 못한다.

 

위와 같은 문제를 해결하기 위해서는 전자 서명과 같이 전송된 공개키가 누구의 것인지를 알 방법이 필요하다. 이와 같이 공개키와 해당 공개키가 누구의 소유인지를 확인시켜주는 일을 Certification Authority (CA)가 하게 된다.

 

CA는 다음과 같은 역할을 가진다.

• CA는 자신에게 등록한 주체가 누구인지 적법한 절차를 통해 알아내는 책임을 가진다.
• CA 해당 주체에게 인증서(certificate)를 발급해주고 해당 인증서와 주체가 등록한 공개키를 바인딩시킨다. 인증서에는 공개키 정보와 해당 주체가 누구인지를 알려주는 정보가 들어가있다. CA가 발급한 인증서는 CA가 전자 서명을 한 형태로 제공된다.

 

https://www.getoutsidedoor.com

 

CA에게 인증서를 발급받기 위해서는 인증서 서명 요청 (Certificate Signing Request, CSR)을 작성해서 보내야한다. CSR에는 일반적으로 다음과 같은 정보가 포함된다.

• 인증서에 포함할 공개키
• 인증서가 적용되는 도메인
• 인증서가 대표하는 주체에 대한 정보

 

인증서가 가지고 있는 정보는 다음과 같다. ( RFC5280 를 살펴보면 더욱 다양한 정보가 있다.)

• 인증서가 증명하고 있는 주체의 이름
• 인증서가 증명하고 있는 주체의 공개키

이제 CA가 발급해준 인증서가 이전에 설명한 피자 배송 서비스에 어떻게 적용될 수 있는지 살펴보자.

Bob은 피자 주문할 때 CA가 서명한 인증서를 그의 주문과 함께 보내게 된다. Alice는 CA의 공개키를 이용하여 인증서가 CA에 의해 서명된 것을 확인하고 인증서로부터 Bob의 공개키를 추출하고 Bob의 전자 서명이 맞는지를 확인한다. 이제 이전과 달리 자신이 전달받은 공개키가 누구의 것인지를 확실히 알 수 있다.

 

참고: 인증서의 유형
단일 도메인: 단 하나의 도메인(www.naver.com)에 적용되는 인증서
와일드카드: 도메인의 하위 도메인도 포함하는 인증서
멀티 도메인: 이름이 의미하는 것처럼 멀티 도메인 SSL 인증서는 관련되지 않은 다수의 도메인에 적용될 수 있는 인증서