윈도우 서버 2003을 이용하여 인증기관(CA)을 만들 수 있다. 이 인증기관에서는 인증서를 필요로 하는 서버나 클라이언트에게 인증서를 발급하고 인증한다. 3장에서 이러한 내부CA는 ‘상업적인 목적의 사용’이라는 측면에서는 완전하지 못하다는 설명을 한 바 있지만, 회사 내부적인 목적의 사용이라면 당연히 비싼 돈을 들여서 외부의 CA를 이용할 이유가 없다. 다만 ‘신뢰성’이 떨어진다는 측면만 고려하면 되는 것이었다. 여기서 말하는 ‘신뢰성’이라고 하는 측면은 클라이언트가 자신이 접속하고자 하는 서버로부터 인증서를 받았을 때 이것을 신뢰할 것인지의 여부에 달려있다. 회사의 네트워크 환경에서는 모든 클라이언트 컴퓨터의 ‘신뢰할 수 있는 인증기관의 목록’에 회사 내부에서 구성한 CA를 추가시켜 주면 해결된다. 기업에 Active Directory 환경을 구성하면 자동으로 클라이언트들의 목록에 내부CA의 목록이 추가된다. 또한 그룹정책을 사용하여 목록을 클라이언트들에게 일괄적으로 배포하는 작업도 가능하다. 뒤에서 Active Directory에 대해서는 자세히 설명하기로 한다.

또 다른 측면은 윈도우 서버 2003에 상업용 외부CA에 대한 자식CA를 구성하는 방법이 있다. 상업용외부 CA로부터 인증서를 발급받은 후 자신이 하부CA로서 클라이언트에게 인증서를 발급하도록 구성 할 수도 있다. 그렇다면 윈도우 서버2003 CA는 더 이상 내부CA라고만 하기에는 어렵다. 외부CA처럼 자신이 발급하는 인증서는 제3의 클라이이언트들이 신뢰할 수 있기 때문이다.

윈도우 서버 2003의 CA서비스는 크게 2가지, 또 거기서 다시 2가지로 세분화된다. 먼저 엔터프라이즈CA와 독립실행형 CA로 나눌 수가 있고, 이것은 각각 루트CA와 하위CA로 세분화된다. 엔터프라이즈CA와 독립실행형 CA를 구분하면 이것은 Active Directory의 유무를 근거로 판단할 수 있다. 엔터프라이즈CA를 구성하기 위해서는 Active Directory가 있어야 한다. 그밖의 경우는 독립실행형CA를 사용할 수 있다. 웹서버에서 SQL서버 데이터베이스에 저장된 사용자들에게 인증서를 발행해야 한다면 그때는 독립실행형CA를 사용해야 한다. 예제에서는 독립실행형CA를 구축해 보도록 하자.

<그림9-1. 독립실행형 인증기관(CA)설치 1>	“제어판à프로그램추가/제거àWindows구성요소à인증서서비스”를 체크하고 [다음]을 누른다.
<그림9-2. 독립실행형 인증기관(CA)설치 2>	인증서서비스를 설치하면 컴퓨터의 이름을 바꾸거나 도메인의 멤버가 되는 등의 작업은 할 수가 없다. 그럴 필요가 있다면 그것은 CA서비스를 제거한 후에나 가능한 일이다.
<그림9-3. 독립실행형 인증기관(CA)설치 3>	인증기관 종류 화면에서는 윈도우 서버 2003이 지원하는 4가지의 인증기관 종류를 보여준다. 필자의 테스트 환경에서 이 컴퓨터는 도메인 컨트롤러이고 현재 작업을 하는 사용자는 도메인의 관리자였다. 만일 당신의 테스트환경이 독립실행형 서버라면 “엔터프라이즈 CA”를 구성하는 옵션을 비활성화된다. 웹서버를 위한 인증서 발행을 목적으로 인증기관을 설치하고 있다면 세번째 메뉴인 ‘독립 실행형 루트 CA’를 선택한다.
<그림9-4. 독립실행형 인증기관(CA)설치 4>	‘CA확인정보’화면에서는 인증기관의 정보를 입력해 준다. CA의 공통이름(Common Name; CN)정보가 앞으로 자신이 발행할 인증서에 표기되는 정보이니 정확히 입력해야 한다. 예제에서는 “WindowsNetwork CA”라고 인증기관 이름을 결정하고 5년 기한의 유효기간을 설정하였다.
<그림9-5. 독립실행형 인증기관(CA)설치 5>	인증서 데이터베이스와 로그를 저장할 경로를 지정한다. 기본경로는 %WinDir%\system32\CertLog 이다.
<그림9-6. 독립실행형 인증기관(CA)설치 6>	IIS서비스를 멈추었다가 다시 시작해야 한다. 클라이언트가 인증기관에게 인증서 발급요청을 할 때 IIS를 통한 웹인터페이스를 통해서 접근하도록 이때 certsrv라는 가상디렉터리를 생성하게 된다.
<그림9-7. 독립실행형 인증기관(CA)설치 7>	설치가 진행되고 있다.
<그림9-8. 독립실행형 인증기관(CA)설치 8>	설치가 끝나면 관리도구에서 ‘인증 기관’ 관리콘솔을 찾을 수 있다. 실행해 보자. WindowsNetwork CA가 동작하고 있고, 해지된 인증서, 발급된 인증서, 대기 중인 요청, 실패된 요청 등의 메뉴를 볼 수 있다. 인증기관 설치가 완료되었다.

엔터프라이즈 CA가 설치되었다면 클라이언트는 인증서 관리콘솔과 웹브라우저, 이 두가지 방법을 통해서 인증서 발급요청을 할 수 있지만, 독립실행형 CA가 설치되었다면 오직 웹브라우저를 통해서만 인증서 발급요청을 할 수 있다.

<그림9-9. 인증서 발급 요청 화면>

IIS가 동작하고 있는 서버에서 인증기관이 설치되면 IIS서버의 기본웹사이트에는 %WinDir%\System32\CertSrv 를 물리적 경로로 하는 Certsrv 가상 디렉터리가 자동으로 생성된다. 인증서 발급요청을 하고자 하는 클라이언트는 http://서버의 IP 혹은 호스트이름/certsrv URL을 이용하여 인증서 발급 페이지에 연결할 수 있다. 아래의 <그림9-9>에서는http://192.168.0.16/certsrv 를 이용하여 인증서 서비스 웹페이지에 연결한 것을 보여준다.

3-4-1.인증기관의 필요성

공용키 암호화가 어떻게 동작하는지 위에서 설명했다. 앨리스가 보내는 데이터를 암호화하기 위해서는 먼저 밥의 공용키를 얻어야 한다고 했는데, 이때 앨리스는 밥으로부터 공용키를 얻고 나서 한가지 의문이 생긴다. 자신이 받은 공용키가 “진짜 밥의 공용키일까? 밥을 가장한 이브의 공용키는 아닐까?” 하는 의문이 들 것이다. 실제 환경에 적용시켜 보자. 여기서 밥은 웹서버에 해당하고, 앨리스는 웹브라우저에 해당한다. 당신은 인터넷 쇼핑몰을 운영하는 웹서버에 접속한 다음 마음에 드는 물건을 장바구니에 담았다. 마지막으로 구매를 결정하고 [결제하기]버튼을 클릭한 후 신용카드 번호, 유효기간 등의 개인정보를 웹서버에게 제공하려고 한다. 이때 안전하게 데이터를 보내기 위해 웹서버의 공용키를 웹서버로부터 받았다. 당신은 이 공용키를 이용해서 웹서버로 전송했지만 알고보니 이 공용키를 제공했던 것은 악의의 제3자였고, 당신의 중요한 개인정보는 외부로 유출이 되게 되었다.

이것을 해결하기 위해서는 당신이 사용하는 웹브라우저는 웹서버로부터 공용키를 얻게 되면 이것이 진짜 거래의 상대방인 웹서버가 발행한 공용키인지 확인해야 할 필요가 있다. 어떻게 확인할 것인가?

이것은 전자상거래가 오프라인상의 실제상거래에서도 마찬가지이다. 가게에서 물건을 하고 신용카드로 대금을 지불한다고 가정하면 가게에서는 고객을 믿고 물건을 내 주지는 않는다. 제3의 기관인 신용카드 회사(은행)를 믿고 물건을 내 주게 된다. 이것처럼 디지털 세계에서도 거래의 양자간의 각종 불신요소들을 해결하기 위하여 제3의 기관의 필요성이 대두된다.

인증기관(Certificate Authority, CA)은 그러한 필요성에서 의미를 찾을 수 있다. 인증기관은 서버의 신원을 증명해 준다. 때로는 클라이언트의 신원을 증명해 주기도 한다. 서버나 클라이언트가 디지털 세계에서 하고자 하는 작업에 신뢰를 부여하기 위한 인증서를 발행하는 작업, 이것이 인증기관의 주된 업무라고 할 수 있다. <그림3-5>를 통해서 인증기관의 역할을 알아보도록 하자.

그림의 예제는 웹서버와 사용자와의 통신을 그림으로 나타낸 것이다. 안전한 거래를 위해서 먼저 웹서버는 한 쌍의 공용키와 개인키를 생성한다(①). 개인키를 자신의 하드디스크에 안전하게 저장을 한 다음 공용키를 웹서버에 게시를 한다. 사용자들이 웹서버로 보내는 데이터를 웹서버의 공용키를 이용해서 암호화해서 보낼 수 있도록 하기 위한 조치이다. 하지만 사용자가 웹서버의 공용키를 신뢰할 수 없다는 것이 문제이다.

이에 웹서버는 웹서버에서 사용할 한 쌍의 키를 생성한 다음 공용키를 인증받기 위한 과정을 거친다. 자신의 공용키와 서버의 정보등을 첨부해서 CA에게 인증서 발급요청을 넘긴다(②). CA는 인증서 발급요청 정보를 잘 살펴보고 하자가 없다면 인증서를 발행하게 된다. 이 인증서에는 웹서버가 제시했던 공용키, 웹서버의 정보, 인증서의 주체, 마지막으로 CA의 전자서명이 들어있다. 결국 웹서버의 공용키를 제3자에 해당하는 CA가 인증을 해 주었다는 뜻이다(③).

이제 웹서버는 공용키만을 게시하는 것 대신에 CA로부터 받은 ‘인증서(Certificate)’를 게시하게 되고, 사용자가 웹서버로 중요한 데이터를 보내기 전에 웹서버로부터 인증서를 얻는다(④). (이 인증서에는 웹서버의 공용키가 저장되어 있음을 기억하라) 인증서를 받은 사용자는 인증서를 발행한 인증기관(CA)가 믿을만한 인증기관인지, 인증서의 날짜는 유효한지, 인증서의 주체와 현재 접근하는 사이트의 주소는 일치하는 지 등의 내용을 확인한다(⑤).

모든 확인이 끝났으면 이제 인증서안에 있는 공용키를 이용해서 자신이 보내는 데이터를 암호화할 수 있다. 믿고 거래할 수 있게 된 것이다. 이때의 인증서의 역할은 ‘서버의 신원증명’에 해당하는 사항이다.

반대로 생각할 수 있는 인증서의 용도는 인터넷 뱅킹에서 찾아볼 수 있다. 인터넷 뱅킹을 사용하기 위해서 우리는 먼저 은행을 직접 방문하여 인터넷 뱅킹 사용 신청서를 제출하고 사용자 계정을 발급받는다. 그것으로 끝나는 것이 아니라 자신의 컴퓨터에서 인터넷 뱅킹을 하기 위해서는 먼저 은행의 서버에 연결한 다음 ‘인증서’를 발급받아야 하는데 이때의 인증서는 ‘클라이언트의 신원을 증명’하기 위한 인증서에 해당한다.  

3-4-2.내부CA와 외부CA

인증기관을 크게 두가지로 구분해 볼 수 있다. 내부CA와 외부CA로 나누어 보겠다. 여기서 내부CA는 회사에서 임의로 설치한 내부적인 사용목적의 CA가 되겠고, 외부CA는 외부의 다른 서버 혹은 클라이언트와의 통신을 위해 사용할 수 있는 상업용CA라고 할 수 있다. 상업용CA중 대표적인 CA를 들라고 하면 ‘Verisign(베리사인)’을 들 수 있다. 관련분야에서 한마디로 잘 나가는 회사이다. 관심있게 보면 인터넷 쇼핑몰 웹서버의 상당수가 베리사인의 인증서를 사용하는 것을 알 수 있다.

웹서버를 운영하는데 내부CA로부터 인증서를 받을 수도 있고, 외부CA로부터 인증서를 받을 수 있다. 차이가 있다면 금전적인 부분을 먼저 들 수 있는데 외부CA로부터 웹서버 인증서를 하나 받으려면 보통 1년에 100만원 이상의 비용을 지불해야 한다. 상당수의 인터넷 쇼핑몰이 영세성을 면하지 못하고 있는 현실을 고려할 때 거리감을 느끼게 만드는 금액이다. 하지만 그러한 상업용 웹사이트의 경우 필요성을 찾을 수 있게 되는데, 그림을 통해서 접근을 해 보자.

<그림3-6>의 화면은 내부CA로부터 인증서를 받은 웹서버로 https://ssl.secure.pe.kr 를 통해서 접근했을 때 클라이언트의 화면에서 팝업되는 경고메시지이다. 3가지 항목중에서 첫번째 항목에는 노란색 느낌표가 들어있는 세모상자의 아이콘을 볼 수 있다. 메시지를 읽어보면 ‘신뢰 여부를 결정한 적이 없는 회사에서 발급한 보안 인증서입니다. 인증 기관의 신뢰 여부를 결정하려면 인증서를 확인하십시오.’라고 되어 있다. 당신이 관리하는 웹서버가 클라이언트에게 위와 같은 메시지를 주고 있다고 생각을 해 보면 어떠한가? 한글번역된 ‘신뢰여부를 결정한 적이 없다’라는 경고메시지도 치명적이라는 생각이 들게 만드는데, 이러한 메시지를 받은 사용자들이 선뜻 자신의 신용카드 정보등을 제공하고 싶어질까? 이 질문에 대해서는 ‘중요한 정보를 제공하고 싶지는 않지만 그래도 거래는 이루어질 것이다.’라고 개인적으로 생각한다. 그만큼 사용자들이 시스템이 내 보내는 오류, 경고 메시지에 둔감하기 때문에 가능한 일일 것이다. 실제로 국내에서 몇백만명 이상의 회원을 확보한 대규모 웹사이트들도 여전히 상당수의 사이트에서는 이러한 경고메시지를 발생시키는 웹사이트를 찾아 볼 수 있는 것이 현실이다.

언제까지 그렇게 사용자들이 무관심할 수 있을까? 라는 생각을 해 보면 그 시점까지가 내부CA를 이용해서 인증서를 발급받을 수 있는 시기라고 생각된다.

[인증서 보기]버튼을 눌러서 인증서를 확인하면 <그림3-7>과 같다.

그림에서 보면 발급대상이 ssl.secure.pe.kr 이다. 클라이언트가 접근할 때 https://ssl.secure.pe.kr 였으니 발급대상과 사이트 이름은 일치했다. 유효기간도 경과되지 않았으니 문제가 없다. <그림3-6>에서는 이 2가지 항목에 대해서는 녹색 체크 표시 아이콘을 보여준다. 하지만 인증서를 발행한 기관에 대한 신뢰성이 문제가 되는데 이것은 클라이언트가 신뢰하는 인증기관의 목록에서 웹서버의 인증서를 발급한 인증기관을 찾지 못했기 때문에 생기는 결과이다. 클라이언트 컴퓨터에서 ‘인터넷 익스플로러 à도구à인터넷 옵션à내용탭à인증서’ 순서로 접근해 보면 신뢰할 수 있는 인증기관의 목록이 이미 정의되어 있는 것을 알 수 있다. 여기에서 웹서버가 현재 사용하는 인증서를 발급해 준 인증기관의 이름을 찾지 못했다는 것이 경고메시지의 에러표시가 뜻하는 내용이다.

내부CA를 사용하면서 외부의 클라이언트의 웹브라우저에게 이것을 속이는 것은 불가능한 방법이다. 그렇기 때문에 에러메시지는 어쩔 수 없는 결과가 될 것이다. 해결할 수 있는 방법은 이 신뢰된 루트 인증기관의 목록에 있는 인증기관(CA)으로부터 인증서를 받아서 사용하는 방법이다.

<그림3-9>에서는 아무런 에러가 없는 잘 설정된 인증서의 정보를 보여준다. 누구나 알만한 대기업들의 웹사이트들도 이러한 PKI를 도입한 것이 그리 오래 되지 않은 일이다. 그중에서도 상당수의 기업들은 제대로 설정되지 않은 사이트를 오픈하고 있는 실정이니 ‘이제 시작이라 어쩔 수 없는 것인가?’라는 생각을 가지게 만든다. Windows Server 2003에 CA서비스를 추가하는 방법에 대해서는 9장에서 다룬다.

보통 줄여서 PKI라고 부르는 Public Key 구조는 앞에서 설명한 대칭키 기법과는 다른 알고리즘을 가지고 있다. 물론 암호화를 하겠다는 기본적인 생각은 차이가 없다. 대칭키를 사용하는데 있어서의 문제점으로 2가지를 거론했는데 Public Key는 이것을 해결해 주고 있다.

Public Key를 다른 용어로 표현한다면 비대칭키, 페어키(Pair Key)라는 용어를 들 수 있다. 용어에서 느껴지는 것이 있을 것이다. 앞에서 설명한 대칭키 알고리즘은 잠그는 키(암호화키)와 푸는 키(복호화키)가 동일하다는 의미에서 대칭키라고 불리운다고 했다. 그렇다면 비대칭키라는 뜻은 이 두개의 키가 서로 같지 않다는 것을 의미하는 것? 그렇다. Public Key알고리즘에서는 암호화키와 복호화키가 한쌍의 키(Pair Key)를 이루고 있다.

이 한쌍의 키는 Public Key(공용키)와 Private Key(개인키)로 구성되어 있다. 공용키는 누구라도 사용할 수 있도록 공개가 되며, 개인키는 HDD, Smart Card등의 공간에 보관하면서 오로지 키쌍을 만든 주체만 사용할 수 있다는 것이 보장되어야 한다.

이 키들은 다음과 같이 사용된다. Public Key 기법을 사용하기 위해서는 먼저 ‘공용키’와 ‘개인키’라는 한쌍의 키를 생성해야 하고, 공용키로 암호화한 데이터는 오직 해당 공용키와 한쌍으로 생성된 개인키로만 해독할 수 있다는 것이다. 그렇다고 무조건 공용키는 암호화키이고 개인키는 복호화키라는 개념은 아니다. 반대상황도 있다. 개인키로 데이터를 암호화하면? 이번에는 한쌍에 해당하는 공용키로만 해독이 가능하다.

공용키는 이름에서 느껴지는 것처럼 누구나 사용할 수 있는 키다. 공개가 되는 키라는 뜻이다. 이 키는 웹서버에 게시되거나 파일서버에 공유되거나 안전하지 않은 전자메일을 통해서 상대방에게 보내져도 아무 문제가 없다. 대칭키에서 가졌던 비밀키 전송의 문제점을 해결해 주는 것이다. 예를 들어 웹서버가 키쌍을 만든다음 앨리스에게 공용키를 전송해 주었다고 하자. ‘앨리스’는 공용키를 이용해서 웹서버로 보내는 데이터를 암호화할 것이다. ‘이브’역시 이 공용키를 구하는 것이 어렵지 않다. 하지만 공용키를 이용해서 앨리스의 암호화된 데이터를 해독하는 것은 불가능하다. 공용키로 암호화된 데이터는 한쌍이 되는 개인키로만 해독이 가능하기 때문이다.

그러다 보니 이제 웹서버는 1만명의 회원을 위해서 1만개의 키를 생성할 필요가 없다. 오직 하나의 공용키만 가지면 되는 것이다. 1만명의 회원들이 동일한 공용키를 가지게 될 테지만 이들은 공용키로 암호화를 할 수는 있지만 공용키로 암호화된 데이터를 해독하는데 사용할 수는 없다는 것을 기억하라.

개념을 알고 나면 단지 그렇구나! 라고 생각할 수 있겠지만 처음 이러한 알고리즘을 만든 사람들은 대단하다는 생각이 든다. Public Key 알고리즘은 MIT공대에서 개발되었다고 한다. 개발한 사람들의 이니셜을 딴 RSA 프로토콜이 가장 널리 사용되고 있다.

3-3-2.Public Key 암호화 (Confidentiality제공)

Public Key를 이용한 암호화에 대해서 <그림3-2>를 보면서 살펴보도록 하자. 앨리스가 밥에게 데이터를 전송하려고 한다. 중요한 데이터인데 이브의 도청이 염려스럽다. 안전하게 보내기 위해서 데이터를 암호화하기로 결정했는데 암호화키가 필요하다. 암호화키로써 데이터를 암호화해서 보내면 데이터를 받은 밥은 복호화를 해야 한다. 역시 복호화키가 필요할 것이다.

먼저 앨리스는 밥의 공용키를 구하는 것이 선행되어야 한다. 그 다음에 자신이 보내고자 하는 데이터를 밥의 공용키로서 암호화하여 전송해 준다. 밥은 암호화된 메시지를 받은 다음 앨리스가 암호화하는데 사용한 공용키와 한쌍으로 생성해 두었던 개인키를 이용해서 복호화하게 된다. 결국 데이터를 꺼낼 수가 있게 되었다.

한가지는 정리하고 가자. PKI를 이용하고자 할 때 상대방에게 안전하게 암호화된 데이터를 전송하고 싶다면 상대방의 공용키를 얻는 것이 첫번째 할일이다. 데이터에는 여러가지가 있을 것이다. 인터넷 쇼핑몰이 운영되고 있는 웹서버로 신용카드와 유효기간 등의 정보를 보낼 수도 있을 것이고, 회사의 중요데이터를 담은 전자메일 메시지일 수도 있다. 웹서버와의 안전한 통신을 위해서는 웹서버로부터, 전자메일을 보내고자 한다면 상대방으로부터, 먼저 할 일은 공용키를 얻어내는 과정이 필요하다는 것이다. 그 공용키로써 암호화를 했을 때 해독할 수 있는 사람은 오직 공용키와 쌍이 되는 개인키를 소유한 사람이다.

3-3-3.Private Key 암호화 (Authenticity제공)

이번엔 다른 관점이다. 개인키를 이용한 암호화가 어떠한 용도로 사용되는지에 대해 정리해 본다. 이번엔 밥의 입장에서 고려를 해 보자. 밥이 앨리스라고 주장(?)하는 사람으로부터 메시지를 받았다고 가정한다. 밥은 자신이 받은 메시지가 정말 앨리스가 보낸 것인지를 확인하고 싶어한다.

현실세계에서 요즘 거의 종이에 펜을 이용해서 글씨를 쓰고 편지를 보내는 일이 드문일이 되었다. 우리는 무엇인가 문서를 만들고 나서 자신이 확인했다는 표시로 ‘자필서명’이라는 것을 하곤 한다. 그러면 상대방은 그 서명을 통해서 받은 편지를 신뢰한다. 디지털 세상에서도 이와 동일한 알고리즘의 작업이 행해지고 있다.

앨리스는 밥에게 보낼 메시지를 만든 다음 자신이 보냈다는 것을 증명하기 위해 “서명”을 한다. 바로 전자서명이 되는 것이다. 서명이 유효하기 위해서는 지켜져야 할 조건이 있다. 당사자가 아닌 다른 사람은 동일한 서명을 할 수 있어서는 안된다는 것이다. 그렇다면 앨리스가 밥에게 보낼 메시지에 서명을 할때는 다른 사람은 가지고 있지 못한 자신만이 가진 유일한 증표를 사용해야 할 것이다. 그것은 바로 자신의 Private Key(개인키)를 이용하는 것이다. 앞에서 공용키는 누구에게나 공개가 되지만 개인키는 오직 키쌍을 생성한 주체만이 가지고 있다고 한 것을 기억하면 될 것이다. 과정을 <그림3-3>을 통해서 설명한다.

그림에서 앨리스는 밥에게 데이터를 전송하고자 한다. 밥에게 자신이 보내는 메시지라는 것을 신뢰할 수 있도록 하기 위해서 자신만이 가지고 있는 개인키를 이용하여 메시지를 암호화한다. 이것을 가리켜서 “Digital Signature (전자서명)”이라고 부른다. 결국 앨리스는 자신이 서명한 메시지를 네트워크를 통해서 밥에게 보낸다. 이 메시지를 받은 밥은 앨리스의 공용키를 이용해서 복호화를 하고, 앨리스의 공용키로써 복호화가 이루어지면 자신이 받은 메시지가 앨리스가 보낸 것이 맞다고 판단을 한다. 앨리스를 가장한 제3자가 보낸 메시지라면 앨리스의 공용키로 해독이 되지 않을 것이다.

만일 이 메시지를 도중에 이브가 가로챘다면? 이브는 당연히 이 메시지를 읽을 수가 있다. 앨리스의 공용키만 있다면 얼마든지 해독이 가능할 것이기 때문이다. 기밀성은 제공되지 않는다는 것을 의미한다.

이렇듯 개인키를 이용해서 암호화하는 것(전자서명)은 제3자가 데이터를 열지 못하게 하기 위한 방법은 아니다. 다만 상대방에게 자신을 가장한 제3자가 아닌 진짜 자신이 보낸 메시지라는 것을 알려주기 위한 방법일 뿐이다.

3-3-4.Hash함수와 Digest (Integrity 제공)

개인키를 이용한 전자서명과 더불어 추가로 고려해야 하는 내용이 있다. 밥이 앨리스로부터 데이터를 받았을 때 밥은 이 데이터가 앨리스가 보낸 원본데이터 그대로인지, 즉 중간에서 변조가 되었다거나 바이러스코드가 추가되었다거나 하는 등의 훼손된 것은 아닌지를 알고 싶다는 것이다. 결국 무결성(integrity)이 보장되어야 한다는 것인데, 이것은 바로 Hash(해시)라고 부르는 함수(Function)와 관련이 있다.

해시는 주로 원본을 감추고 확인하기 위한 용도의 함수인데, ‘단방향 함수’이며 원본이 1비트만 달라져도 두 개의 문서는 서로 다른 결과값을 가진다는 특징을 가지고 있다. Y=f(x) 라는 일반적인 공식에 대입시켜 보자. 해시함수 역시 모든 함수가 그렇듯이 x값을 대입시키면 결과값(y)이 나오는데, 거꾸로 y값을 가지고는 x가 무엇이었는지를 구할 수가 없다는 특징을 가진 함수이기 때문에 ‘단방향 함수’라고 부른다. 이것은 네트워크 상에서 상당히 유용하게 쓰일 수 있다. 어떤 사용자가 서버로 자신의 암호인 1234 를 전송하고 있다고 가정을 했을 때, 1234를 그대로 전송하면 제3자의 도청위험에 노출되게 된다. 하지만 1234를 그대로 전송하는 것이 아니라 해시함수를 이용해서 해시하여 전송하게 되면 설사 제3자가 이 패킷을 도청했다고 하더라도 1234라는 암호는 감출 수가 있기 때문이다.

제3자는 이 패킷을 가지고 원래 암호를 알아내기 위해 노력하겠지만 해시함수의 특성상 원본을 알아내는 것은 어렵다고 판단된다. 해킹에 조금 관심을 가진 독자라면 흔히 ‘패스워드 크랙킹 툴’들에 대한 이야기를 접할 수 있을 것이다. 이러한 암호 크랙킹 툴들중에는 “사전공격(Dictionary Attack)’이라는 공격방법을 이용하는 툴들이 많은데, 이러한 툴들은 해시값을 역으로 추적해서 원본데이터를 알아내는 것이 아니라 원본데이터를 유추하는 방식을 사용한다. 즉 암호를 짐작하여 생성한 다음 해시함수를 이용하여 해시하고 그 값을 자신이 네트워크에서 훔쳐낸 값과 비교하는 방법을 이용한다. 두 값이 같으면 자신이 유추한 암호가 사용자의 암호라고 판단하는 것이다. 이 때 원본데이터에 해당하는 단어들을 정의한 사전파일을 사용하고 있어서 이를 “사전공격(Dictionary Attack)’이라고 한다. 대부분의 보안지침에서 ‘사전에서 쉽게 찾을 수 있는 단어를 암호로 사용하지 말라’라고 하는 이유는 바로 이러한 공격의 위험을 염두에 둔 것이다.

원본데이터를 해시함수를 이용하여 계산하여 나오는 값을 Digest(요약)이라고 부른다. 원본데이터중에서 뽑아낸 요약된 비트라는 의미에서다.

구체적으로 무결성(Integrity)을 보장하기 위해서 어떻게 해시함수가 사용되는지 <그림3-4>를 통해서 설명한다. 그림의 번호순으로 차근차근 접근해 보자.

그림에서는 앨리스가 밥에게 데이터를 전송하려고 한다. 먼저 앨리스는 데이터를 해시하여 다이제스트를 생성한다. 다이제스트는 해시함수를 이용하여 얻은 결과값이다. 이 다이제스트를 자신의 개인키를 이용하여 암호화한다. 개인키를 가진 사람만이 할 수 있는 이 작업이 ‘전자서명’이라고 설명한 바 있다. 그 다음에 네트워크를 통해서 밥에게 ‘전자서명된 데이터’를 전송한다. ‘전자서명된 데이터’라는 표현을 잘 음미해 보라. 앨리스가 전자서명을 어떻게 만든 것인지를 보면 결국 앨리스가 보내는 ‘전자서명된 데이터’가 의미하는 것은 ‘원본데이터+다이제스트’라는 것을 알 수 있을 것이다.

이 메시지를 받은 밥은 몇 가지 작업을 거친다. 먼저 앨리스가 보낸 메시지라는 것을 확인하기 위해 앨리스의 공용키를 이용해서 ‘전자서명’이라는 암호문을 해독한다. 이 복호화의 결과로 얻는 것은 앨리스가 보내준 ‘다이제스트’이다. 그 다음에 원본데이터를 앨리스가 사용한 것과 동일한 해시함수로 해시하여 다이제스트를 생성한다. 그리고 2개의 다이제스트를 비교하는 일을 한다. 이 2개의 다이제스트가 정확히 일치한다는 것이 밝혀지면 다이제스트를 생성한 원본이 동일하는 것을 증명해 주는 것이다. 밥이 받은 데이터가 도중에 훼손되었다면 밥이 직접 생성한 다이제스트는 앨리스가 만들어서 보낸 다이제스트와 ‘불일치’라는 결과를 보일 것이다.

이러한 방법을 이용해서 데이터 무결성을 보장해 줄 수 있다.

그림의 내용을 다시 정리해 보았다.