Apache SSL Server Setup and CA Apache SSL Server Setup and CA본 강의에서는 뛰어난 공용 Web server인 Apache Server와 SSL의 non-US 구현인 SSLeay를 사용하여 SSL web server를 설치 운영하는 방법과 원리에 대하여 설명한다. 또한, SSL에서 사용하는 증명서(Certificate)의 원리와 증명서의 발급 기관인 공증 사무소(CA: Certification Authority)를 설치 및 운영하는 하는 방법에 대해서도 설명한다. 실제로 CA 증명서, 서버 증명서, 사용자 증명서 등을 발급하는 방법에 대해서 Netscape Navigator를 중심으로 설명한다.
WWW의 사용자가 많아지고, 인터넷 상가(internet mall 혹은 market)등과 같은 상업적 응용이 필요해짐에 따라 WWW의 많은 부분들이 보안을 필요로 하게 되었다. 특히, browser와 WWW 서버간의 통신 자체의 보안이 가장 큰 문제가 되었다.
Ethernet이라는 media는 같은 subnet안의 통신 내용을 관찰 할 수 있고, 통신 경로상의 라우터나 proxy 서버의 조작으로도 browser와 서버간의 통신 내용을 도청할 수 있다. 따라서, 대금지불을 위해 입력한 신용카드의 번호와 같은 것들이 제 3 자에 의해서 도청되어 악용될 수 있고, 얼마전에 일어났던 홈 뱅킹 사건과 같이 중간에 거쳐야 하는 프로그램을 변경하여 정보를 빼내는 등의 불상사가 일어날 수 있다.
현재의 HTTP 프로토콜 상에서 상대에 대해서 알 수 있는것이라고는 호스트 이름과 IP 주소뿐이다. (물론 Basic Auth를 사용하면 username과 password를 얻을 수 있지만, 이것은 특별한 경우이므로 제외한다.) WWW 서버의 입장에서는 접속해 오는 고객들이 보내오는 내용이 사실인지, 정당한 사용자가 정당한 정보를 인출하고 있는지 확신할 수 없고, browser를 사용하는 사용자의 입장에서는 정보를 제공해 주는 서버가 정말 책임있게 전달해 주는 것인지, 아니면 누군가의 장난으로 만들어진 것인지 알 길이 없다.
이와 같은 공개된 환경에서의 통신 문제는 암호화를 통한 내용의 보안과 상호 확인에 의해 이론적으로 해결할 수 있다. 암호학의 이론적 바탕위에서 실제적으로 안전한 통신의 방법으로 여러가지 프로토콜과 방법들이 제안되었다. 그중의 하나가 SSL(Secure Socket Layer)이다.
본 강의에서는 SSL에 대해서 개략적으로 알아보고, 무료로 사용할 수 있는 SSL 서버인 Apache-SSL의 설치 방법과 운용방법에 대해서 알아본다.
여기서 신원 사취나 데이터 사취는 도청 (eavesdropping) 이라는 말로도 사용될 수 있으며, 사칭은 흉내 (impersonate) 라는 말로도 많이 사용된다. 변조 (tampering), 위조 (forgery) 란 말도 조작이나 재생 혹은 사칭에 해당하는 뜻으로 사용하기도 한다.
- 신원 사취 (identity interception)
- 통신에 참여하고 있는 하나이상의 사용자의 신원이 오용을 위해 관찰되는 경우
- 사칭 (masquerade)
- 정보에 접근하기 위해 또는 다른 특권을 취득하기 위해 임의 사용자가 타 사용자 처럼 행동하는 경우
- 재생 (replay)
- 기록 및 후일 시도되는 통신의 재생
- 데이터 사취 (data interception)
- 무자격 사용자에 의한 통신중인 사용자 데이터 관찰
- 조작 (manipulation)
- 무자격 사용자에 의한 통신 중인 사용자 데이터의 교체, 삽입, 삭제 또는 순서 변경
- 부인 (repudiation)
- 통신 전반에 걸쳐 혹은 부분적으로 통신에 참여한 사용자의 부인
현재 Ethernet을 사용하는 곳에서는 그 subnet안에서 (즉, 같은 선 혹은 dummy hub로 연결된 호스트들 끼리) 신원 및 데이터 사취가 가능할 뿐만 아니라, 이것을 기계화 해 주는 프로그램 까지 있는 실정이다. 만약, 라우터 관리자가 라우터를 적절한 보안 상태로 유지하지 못했다면, 어떤 네트워크에서도 라우터를 통해 사취 뿐만 아니라 조작도 가능하다.
인터넷의 경우 IP 중복 (duplicate IP) 을 통해서 (잠시 동안만 이라도) 다른 호스트로의 사칭이 가능하다. 또한, name 서비스를 하는 DNS (Domain Name Service) 서버의 내용을 변경함으로서 사칭을 할 수 있다.
단순 암호화만을 하여 잘못 설계된 프로토콜은 재생 공격에 무력하다. 암호화 되어 내용을 알 수 없다 하여도, 관찰한 통신 내용을 그대로 반복하면 동일한 결과를 얻을 수 있기 때문이다. 따라서, 이런 암호화 통신을 할 때에는 시계 도장 (timestamp: 현재 통신 발생 시각이나 유효 시간, 몇번째 connection등 시각에 의존적인 정보) 을 같이 포함하여 암호화 하는 것이 보통이다.
위와 같이 믿을 수 없는 네트워크에서는 사용자의 부인에 대해 무력하다. 예를 들어 짜장면을 배달해 달라고 해서 배달하라 갔더니 "우린 시킨적 없어요" 하면 중국집에서는 어떻게 할 수 없는 것과 같다.
보안에 사용되는 알고리즘은 다음과 같은 세 종류로 나누어서 생각할 수 있다.
위와 같은 알고리즘들을 혼용하여 다음과 같은 일들을 할 수 있다. 모든 경우에 각자의 비밀 열쇠는 보관이 잘 되어 있다고 가정한다.
- 단일 열쇠 암호화 알고리즘 (single key encryption algorithm)
- 일반적으로 우리가 알고 있는, 또한 전통적으로져 알려져 온 암호화 방식으로, 암호화 (encryption) 할때나 복호화 (decryption) 할때 동일한 하나의 열쇠를 사용하는 알고리즘을 말한다. 단일 열쇠 암호화 알고리즘을 이용하여 통신을 할 경우에는 수신자와 송신자가 통신에 사용될 암호화 열쇠를 미리 알고 있어야 하기 때문에 열쇠 배분의 문제가 생긴다.
- 공개 열쇠 암호화 알고리즘 (public key encryption algorithm)
- 암호화 하는 열쇠와 복호화 하는 열쇠가 다른 알고리즘을 말한다. 암호화 하는 열쇠를 일반에게 공개하고 복호화 하는 열쇠는 소유주 자신만이 안전하게 보관한다면, 다른 사람이 암호화 열쇠로 메시지를 암호화 하여 보낸 편지는 복호화 열쇠를 가지고 있는 소유주 밖에는 메시지를 읽을 수 없다. 즉, 열쇠 소유주에게 안전하게 메시지를 전달할 수 있다. 여기서 일반에게 공개되는 열쇠를 공개 열쇠 (public key), 열쇠 소유자 만이 가지고 있는 열쇠를 비밀 열쇠 (secret key) 라고 한다.
- 보안용 단방향 함수 (secure one-way function)
- 보안용 단방향 함수는 다음과 같은 조건을 만족해야 한다.
결국 어떤 데이타에 대한 단방향 함수의 결과값을 유지한 상태에서 그 데이타에 대한 조작이나 재생성을 시키는 것이 거의 불가능 하므로, 단방향 함수의 결과값이 변화가 없다면 데이터는 변하지 않았다고 인정할 수 있다.
- 단방향이어야 한다. (one-way) 즉, 동일한 결과를 생성하는 입력 메시지를 구성하는 것이 산술적으로 거의 실행 불가능해야 한다.
- 상충이 없어야 한다. (collison-free) 즉, 동일한 결과를 생성하는 2개의 서로 다른 입력 메시지를 구성하는 것이 산술적으로 거의 실행 불가능해야 한다.
보안용 단방향 함수는 해쉬 함수 혹은 message digest 알고리즘이라고 불리기도 한다.
이제, 이와 같은 암호화 기술이 어떻게 네트워크상에서의 공격 혹은 위협을 방지하는가 살펴보자.
- 안전한 메시지 전송
- 공개 열쇠 암호화 알고리즘을 이용하여 직접 구현할 수 있다. 좀더 효율적이면서 안전한 방법을 추구한다면 단일 열쇠 알고리즘과 같이 사용할 수 있다.
송신자는 단일열쇠를 임의로 만들어서 수신자에게 단일 열쇠만을 공개 열쇠 방식으로 암호화 하여 전송하고 실제 메시지는 단일 열쇠 방식으로 암호화하여 전달한다. 수신자는 먼저 받은 공개 열쇠를 가지고 메시지를 해독한다. (2)
이 방법은 같은 메시지를 암호화 하더라도 임의로 생성되는 단일 열쇠 때문에 암호문은 매번 다른 형태를 띄게 된다.- 전자 지문 (finger print)
- 공개 열쇠나 비밀 열쇠는 사람이 알아볼수 없는 부호의 연속으로 구성되어 있는 것이 보통이다. (정확히 말하면 큰 수자이지만...) 전송 도중에 사고로 혹은 누군가의 조작에 의해 공개 열쇠가 변형될 수 있어서, 전화나 그밖의 방법으로 제대로 전송되었는지 확인하는 것이 필요하다고 하자. 이 경우 사람이 인식 할 수 없는 공개 열쇠를 일일히 불러서 확인한다는 것은 귀챦은 일이다.
이런 경우, 공개 열쇠를 보안용 단방향 함수에 적용하면 적당히 작은 숫자를 얻을 수 있다. 여기서, 보안용 단방향 함수는 결과값이 같은 두개의 서로 다른 메시지를 만드는 것이 거의 불가능하다는 성질이 있다. 따라서, 양쪽에서 단방향 함수에 적용한 값만을 비교해서 둘이 같다면 공개 열되는 제대로 전달되었다고 믿을 수 있다.
이와 같이 어떤 메시지에 단방향 함수를 적용하여 나온 적당한 크기의 숫자를 전자 지문이라 한다.- 디지탈 서명 (digital signature)
- 만약 공개 열쇠 암호화 알고리즘이 역전 가능한(reversible) 것이라면, 즉, 비밀 열쇠로 암호화 한 것을 공개 열쇠로 복호화 할 수 있다면, 어떤 메시지를 비밀 열쇠로 암호화 하여 디지털 서명으로 쓸 수 있다. 왜냐하면, 비밀 열쇠는 열쇠의 소유주만이 가지고 있으므로 비밀 열쇠로 암호화된 메시지는 열쇠의 소유주 밖에 만들 수 밖에 없고, 공개 열쇠는 모두가 가지고 있으므로 모두가 그 서명을 검사할 수 있기 때문이다.
단순히 공개 열쇠 암호화 알고리즘만 적용한다면 서명의 길이는 메세지의 길이에 비례한다. 메세지의 길이와 관계없는 크기의 서명을 얻고 싶다면 메세지의 전자지문값을 구한 뒤 이것을 비밀 열쇠로 암호화 하면 일정한 크기의 서명을 얻을 수 있다.
안전한 메시지 전송은 데이터 사취 및 사칭, 조작을 불가능하게 한다. 디지탈 서명은 신원 사취, 사칭, 조작, 부인등을 방지한다. 보안용 단방향 함수의 사용, 즉, 전자 지문의 적용은 조작을 방지한다. 모든 경우에 있어서 전송하는 내용중에 시계도장이 포함되어 있다면 재생도 불가능하게 한다. 이것은 각각의 기술이 조작을 방지하기 때문이다.
따라서, 암호화 기술을 사용하면 필요에 따라 네트워크상에서의 위협을 방지할 수 있다.
안전한 공개 열쇠 사용을 위해, 모든 호스트가 통신을 해야되는 대상을 일일히 off-line에서 사실 확인을 한다면 많은 비용이 든다. 그래서, 공개 열쇠의 사실여부를 확인하고 공개 열쇠에다가 디지탈 서명을 함으로써 공개 열쇠가 틀림없음을 증명해 주는 기관을 따로 둘 수 있는데, 이것을 공증 사무소 (Certification Authority, 줄여서 CA) 라고 한다.
그림 1. CA를 통한 공개열쇠 증명 절차 및 사용
앞에서 서술한 공증 사무소의 운영 형태를 보면 다음과 같은 사실을 알 수 있다.
상업적 측면에서 본다면 기밀성을 유지하지 못하는 통신 수단은 전자 상거래나 보다 심각한 응용프로그램의 수단이 되지 못한다. 따라서 통신 내용이 보호되는 프로토콜이 필요했던 것이다.
비슷한 시기에 EIT사에서는 기존의 HTTP를 수정한 Secure-HTTP를 제안했고, Netscape사에서는 TCP/IP의 API라 할 수 있는 BSD Socket call을 변형한 Secure Socket Layer를 제안했다.
Secure-HTTP는 HTTP로 전송되는 내용을 보호하는데 치중했다. HTTP라는 특정한 프로토콜의 변형이므로 다른 통신 수단에 응용될 수 없는 대신 PEM (Privacy Enhanced Mail; RFC-1421, 1422) 이나 MOSS(MIME Object Security Services; RFC-1848), PGP 와 같은 전자 메일쪽에서의 기존 규정을 따랐다. 따라서, 전자 우편상에서의 전자 서명등과 같은 사용자가 직접 암호화를 주도하는 사용자 인터페이스를 제공하는 형태로 구현되었다.
SSL은 맨 끝자인 L (Layer) 가 의미하듯이 TCP/IP 또는 그밖의 네트워크 전송 (transport) 서비스 위의 하나의 Layer로 따로 구현한 것이다. Layer를 하나 더 올리는 대신 API를 기존의 Socket과 유사하게 유지함으로써, telnet이나 ftp와 같은 기존의 모든 TCP/IP 응용 프로그램들을 SSL로 porting 하기 쉽게 하였다. 따라서, 사용자는 암호화에 대해서는 거의 아무것도 신경 쓸 필요가 없다. 단지, 증명서를 받아서 설치하는 것만 신경쓰면 된다.
SSL과 유사한 아이디어로는 IP (Internet Protocol) Level에서 암호화를 수행하는 ESP (Encapsulating Secure Payload; RFC-1827) 과 IP level에서 사용자 확인을 하는 IP Authentication Header (RFC-1826)이 있다.
SSL은 그 안에서 SSL Record Layer와 SSL Handshake Layer로 나누어 진다. SSL Record Layer에서는 암호화 처리를 위한 기본 단위들로 나누고 그것을 구분하는 것을 담당하고, SSL Handshake Layer는 암호화 방법이나 열쇠의 결정 및 협상을 담당한다.
현재 SSL는 internet draft로 제출되어 보완 수정되어 RFC화 되는 과정을 거치고 있다.[Frier96]
실제 만드는 방법은 다음과 같은 4 단계로 나타낼 수 있다.
처음에는 UNIX library로만 만들 수 있었으나, 0.5.2부터는 Window NT와 MS-DOS가 0.6.0부터는 Windows 3.1 DLL으로도 만들 수 있게 되었다.
perl util/perlpath.pl 새로운_path와
perl util/ssldir.pl 새로운_ssl_path를 실행시킨다.
make -f Makefile.ssl links를 실행시켜 symbolic link를
만든다.
./Configure system_type을 실행한다. 잘 모르겠으면
./Configure만 실행하여 system의 예제를 보고 그중에
알맞은 것을 고른다. SSLeay code중에는 기계어 부분도 포함이 되어
있으므로 Solaris나 DG/UX같은 경우 CPU가 무엇인지 확실히 알고
system_type을 결정하여야 한다.
make clean; make depend를 실행하여 컴파일 준비를 한다.
make를 실행한다. 그러면 SSL library가 만들어진다.
make rehash; make test를 수행하여 만들어진 library가
제대로 동작하는지 자체 테스트를 수행한다. 여기서 테스트를 하나라도
통과하지 못한다면 문제가 있는 것이므로 Configure를 다시 수행하고
다시 컴파일 해보거나, 뭔가 문제가 있다고 생각되면
ssl-users@mincom.oz.au 메일링 리스트로 메일을 보낸다. 물론,
메일을 보내기 전에 ssl-users 메일링 리스트를 살펴 보면 더욱 좋다.
su를 하여 root가 된뒤
make install을 수행하여 SSLeay를 설치한다.
만약, Apache-SSL만을 설치할 것이라면 이 단계는 생략해도 좋다.
처음에는, Netscape으로 옮겨간 NCSA httpd의 저자 Rob McCool의 허락을 받아 NCSA httpd 1.3을 고쳐나가기 시작했다. 당시 Netscape Server와 NCSA httpd 1.4에 있던 server pool 기능을 구현하여 원래의 목표인 빠른 서버를 만들었다. CGI 프로그램의 fork 비용을 줄이고 서버 기능 확장을 용이하게 하기 위해, Netscape의 NS-API와 기능상으로는 비슷한 (그러나 방식은 다른) Apache API등을 구현하였다. 결국, 전체 서버의 구조를 Apache API로 통일하여 전부 다시 프로그램하게 되었고, 다른 많은 프로그래머들이 Apache API에 맞추어 새로운 기능들을 추가시켰다.
그러다보니 어느새인가 전세계에서 가장 널리 사용되는 서버로 정착하였고, 지금은 전세계 Web server의 37%가 Apache server를 사용하고 있다. (참고: http://www.netcraft.com/Survey/)
Apache Server의 특징중의 하나는 Apache API로, 서버 기능을 확장하기 쉽고, PHP/FI, mod_perl, Kerberos Authentication과 같은 유용한 모듈 및 스크립트 언어등이 지원된다. (Apache module에 대해서는 http://www.zyzzyva.com/server/module_registry/ 를 참조하기 바란다.
https://~로만 접속된다.)
별도 기능이 없는 Apache-SSL만 설치할 것이라면 이 부분은
그냥 지나가도 좋다.
src directory로 들어간다.
Configuration화일을 수정한다.
./Configure를 수행한다.
(바로 앞단계에서 수정한 Configuration화일과
혼동하지 않도록 한다.)
make를 수행한다. 컴파일이 끝나면 httpd화일이
생성된다.
conf directory안의 configuration 화일의 내용들을 조절한다.
덕분에 SSLeay의 구현뿐만 아니라 NCSA httpd, Mosaic의 patch도 신경써야 했던 Eric Young은 SSLeay 구현에만 신경쓸 수 있게 되었다. (그래서 더이상 NCSA httpd와 Mosaic의 patch는 나오지 않는다.)
README와 README.SSL화일을 살펴본다.
patch -l SSLpatch를 수행한다. patch 프로그램은 되도록이면
GNU의 patch를 쓰는 것이 좋다. (Solaris나 MIPS등에 포함되어 있는
patch 프로그램은 제대로 동작하지 않는 수가 있다.)
src directory로 들어가서 Configuration화일을
적절하게 수정한다.
./Configure를 수행한다.
(바로 앞단계에서 수정한 Configuration화일과
혼동하지 않도록 한다.)
make를 수행한다. 컴파일이 끝나면 httpsd화일이
생성된다. (httpd는 생기지 않는다.)
SSLconf/conf directory안의 화일들을 참조하여,
conf directory안의 configuration 화일의 내용들을 조절한다.
(실제 httpsd동작에서 SSLconf/conf directory안의
configuration file들은 영향을 미치치 않는다. 영향을 미치게 하려면
-d option이나 -f option으로
configuration file을 변경해야 한다.)
make certificate을 실행하면
SSLconf/conf/httpsd.pem이라는 화일이 생긴다. 이것은 다음 명령과 같은
의미이다.
req -new -x509 -out ../SSLconf/conf/httpsd.pem -keyout \
../SSLconf/conf/httpsd.pem
req -newkey 512 -new > new-req.pem
위와같은 명령을 실행하면 X.500 형식으로 서버의 정보 (이것을 고유 이름 - Distinguished Name : DN -이라 한다.) 를 입력하라는 요구가 나타난다. 여기서 국가 (Country : C) 는 ISO 3166 Country code를 따르는 두글자 표현으로써, 한국의 경우 KR이어야 한다. 또한, CN (Common Name) 은 서버의 호스트 명으로 하여야 한다. X.500형식에 관한 자세한 사항은 X.520[X520]을 참조하기 바란다.
열쇠쌍을 생성하면, new-req.pem과 privkey.pem의
두 화일이 생성된다. privkey.pem은 비밀열쇠로서 서버 관리자가
보관하고, new-req.pem을 공증 사무소에 보낸다.
공증 사무소에서 증명서를 보내주면, privkey.pem과 받은
증명서를 합쳐서 SSLconf/conf/httpsd.pem 혹은
httpd.conf에서 SSLCertificateFile directive로
지정한 화일 이름으로 저장한다.
서버 증명서를 증명할 수 있는 CA증명서가 없을 경우, Mozilla는 서버 증명서를 발급한 공증 사무소를 찾을 수 없다고 말하고, 사용자에게 서버 증명서를 신용하겠느냐는 질문을 한다. (여기서 "More Info"버튼을 누르면 서버의 고유 이름(DN)과 전자 지문 등을 확인 할 수 있다.) 만약 항상 신용한다고 대답하면 서버 증명서가 Mozilla에 설치된다.
IE 3.0의 경우에는 서버 증명서를 증명할 수 있는 CA 증명서가 없다면 통신을 거부한다.
CA 증명서는 Mozilla나 IE 3.0이 나올때 설치되어 나오는 경우가 많고, 새로운 CA의 경우는 link를 클릭함으로써 설치할 수 있다. 설치 할때는 browser가 CA 증명서를 설치한다는 것을 알리고 실제로 설치할 것인지 묻는다. Mozilla의 경우에는 어떤 이름으로 저장할 것인지도 묻는다.
Mozilla의 경우에는 HTML의 form tag 사이에 <KEYGEN&rt;이란 tag가 있으면 form을 submit하는 순간 사용자의 열쇠 쌍을 생성할 것인지 묻는다. 여기서, 열쇠 쌍을 생성하고 비밀 열쇠를 보호할 password를 입력하면, 비밀 열쇠는 Mozilla의 열쇠 저장소에 보관되고, 공개 열쇠는 form의 내용과 함께 서버로 전송된다.
공증 사무소의 정책에 따라 다르나, 어떤 공증 사무소의 경우는 form에 의해 공개 열쇠를 보내자 마자 즉시 증명서를 발급해 주는 수가 있다. 이런 경우에는 비밀 열쇠 보호를 위한 password 입력 직후 인증서를 설치 할 것인지 어떤 이름으로 저장할 것인지 물어온다.
일반적인 공증 사무소는 증명서 발급신청을 심사하고 그 결과를 전자 메일로 통보한다. 이때 사용자 인증서를 어디서 받아가는지도 같이 표시하는 것이 보통이다. 이 경우 해당 URL을 선택하면, 앞의 경우와 마찬가지로, Mozilla는 이 증명서를 설치할 것인지 묻는다.
사용자 증명서를 요구하는 서버에 접속하면 Mozilla는 어떤 사용자 증명서를 서버에게 보낼 것인지를 사용자에게 묻는다. 사용자는 그중에 적당한 것을 선택하면 Mozilla는 그 사용자 증명서를 서버에 보낸다. 서버는 적당하다고 판단되면 연결을 계속한다. (4)
IE 3.0에 대해서는 Mozilla와 유사하다고 하나 자세한 사항이 알려져 있지 않다.
Mozilla의 경우 Options/Security Preferences 메뉴에서 Personal Certificate 혹은 Site Certificate tab을 선택하면 증명서의 목록을 볼 수 있으며, 필요한 경우 살제를 할 수 있다.
IE 3.0 한국어판의 경우 보기/옵션 메뉴에서 시스템 보안 tab을 선택하면 보안증이라는 항목이 나온다. 거기서, 사용자, 사이트, 공급업체 등의 분류를 선택하면 해당 증명서의 목록을 볼 수 있다.
CA.sh와 ca
프로그램을 이용하여 공증 사무소를 운영하는 방법에 대해서 알아본다.
공증 사무소는 (앞의 2.3절에서 언급한 바와 같이) 네트워크에 물려있지 않아야 하며, 물리적으로도 담당자 이외의 접근이 불가능 하여야 한다. 가장 보안에 신경써야 할 부분은 공증 사무소의 비밀 열쇠로서 단일 열쇠 암호화 알고리즘에 의해 암호화 되도록 구현하여야 한다. 비밀 열쇠를 암호화 한 단일 열쇠의 역시 담당자 이외에는 알려지지 않도록 주의하여야 하며, 주기적으로 변경하는 것이 좋다. (단일 열쇠를 변경하는 것이지 비밀 열쇠를 변경하는 것이 아니다. 비밀 열쇠를 변경하면 증명서를 전부 다시 만들어야 한다.)
필요하다면 (암호화 된) 비밀 열쇠를 별도의 디스켓이나 스마트 카드등에 저장하여 물리적인 보안을 강화할 수 있다. 이런 경우, 비밀 열쇠를 획득하기 위해서는 password 혹은 pass phrase라 불리는 단일 열쇠와, 비밀 열쇠가 저장된 media 두 가지가 다 필요하므로 우연적인 비밀 열쇠 유출 가능성은 매우 낮아진다.
두번째로 보안에 신경써야 할 사항은 공증 사무소 자신의 증명서 (CA 증명서) 이다. 특히, 자기자신이 증명하는 형태의 증명서의 경우 얼마든지 같은 이름으로 위조 할 수 있으므로 위조 CA 증명서가 돌아다니고 있지 않은지 확인해야 한다. 이것은, 사용자들에게 적법한 CA 증명서의 습득 방법과 설치 방법을 안내해 주고, CA 증명서의 지문 (finger print) 을 다른 방법으로 공개하여 사용자들이 가지고 있는 CA 증명서가 위조인지 아닌지를 확인시킴으로써 위조 CA 증명서를 없앨 수 있다.
세번째로 보안에 신경써야 할 부분은 발급한 증명서 목록이다. 증명서 자체는 공개된 자료이므로 문제가 없으나, 증명서 목록은 취소 (revoke) 된 증명서의 목록 (CRL; Certificate Revocation List) 을 만들때 근거 자료로서 사용되므로 이것 역시 보안을 유지하여야 한다.
그밖의 보안사항으로는 공증 사무소 프로그램이 설치된 컴퓨터 자체의 보안, 담당자의 보안 의식 배양 (사실은 이것이 가장 중요할지 모른다) 등이 있다.
make install까지 했어야 한다.)
공증 사무소 대부분의 업무는 CA.sh이라는 프로그램으로
정리되어 있다. CA.sh는 shell script이므로 필요에 따라
공증 사무소 데이터의 위치나 directory 이름등을 변경할 수 있다.
CA.sh는 SSLeay 설치 경로를 바꾸지 않았다면
/usr/local/ssl/bin에 있다.
CA.sh -newca를 실행하면
./demoCA라는 directory를 만들고 그 밑에 공증 사무소 운영에
필요한 각종 화일을 설치한다. 이때, 공증 사무소의 비밀 열쇠와 CA 증명서도
같이 만든다. 비밀 열쇠는 demoCA/private/cakey.pem으로
저장되며 CA 증명서는 demoCA/cacert.pem으로 저장된다.
SSLeay의 응용 프로그램들은 PEM형식으로 되어 있는 cacert.pem을 사용하면 되나 Mozilla나 IE 3.0과 같은 DER 형식을 필요로 하는 응용프로그램에게는 DER 형식과 적당한 MIME type을 제공해 주어야 한다.
먼저 PEM화일을 DER화일로 바꾼다.
x509 -inform PEM -outform DER < cacert.pem > cacert.cacert
그리고 .cacert 형식을 application/x-x509-ca-cert의 MIME type을
가지도록 WWW 서버의 setting을 바꾸어 주고, cacert.cacert를 적당한
위치에 설치한다.
사용자가 Mozilla나 IE 3.0을 사용하여 cacert.cacert를 선택하면 CA 증명서가 해당 browser에 설치된다.
newreq.pem으로 저장하고
CA.sh -sign 을 실행한다.
그러면, CA 프로그램은 신청서에 적혀있는 서버의 고유 이름 (distinguished
name : DN) 을 표시한다. 담당자는 고유 이름이 틀림없는지를 확인하고
서명할 것인지를 결정한다. 특히, CN (Common Name) 이 서버의 호스트 이름과
동일한지 확인한다.
고유 이름 형식에 관한 자세한 사항은 X.520[X520]을 참조하기
바란다.
서명하면 증명서 목록에 새로운 증명서가 추가되면서 newcert.pem이란
화일이 나오는 데, 이것이 새로 발급된 서버 증명서이다. 이 화일을 신청자 한테
돌려주면 된다.
Mozilla의 사용자 증명서 신청 용지는
<FORM> tag 사이에 <KEYGEN> tag를 넣어서
만들 수 있다. <그림 2>에 그 예가 있다.
|
|
| 그림 2. 사용자 증명 신청서의 예 |
<KEYGEN NAME="name"
CHALLENGE="challenge string"> tag는 사용자의 열쇠 쌍
크기를 선택하는 form 으로 나타나며, form이 submit될때 열쇠 쌍을 생성한다.
(5)
생성된 비밀 열쇠는 Mozilla에 저장되며, 공개 열쇠는 CHALLANGE에서 지정하는
문자열과 연결된 뒤 비밀 열쇠로 서명된다.
(이것은 SignedPublicKeyAndChallenge = SPKAC 라고 한다.)
그리고, base64로 부호화 되어 NAME에서 지정하는 이름으로
다른 form value와 같이 서버로 전달된다. 그림 2의 경우에는
SPKAC=MIG0MGAwXD...와 같은 형태로 전달된다.
신청자의 신원이 확인되면 증명서를 발급한다.
ca -spkac spkac_file -out outfile.der
여기서, spkac_file은 사용자의 고유 이름 (DN)과 SPKAC의 내용이
포함된 아스키화일이며, 출력, 즉, 증명서는 DER 형식으로 저장된다.
(<그림 3>에 입력 화일의 예를 보였다.)
그리고, 발급된 증명서의 MIME type이 application/x-x509-user-cert가
되도록 만들어 놓는다.
|
|
| 그림 3. SPKAC 입력 화일의 예 |
발급된 증명서를 신청자에게 통보하여 설치하도록 한다. 단, 신청자는 증명 신청을 했던 그 browser를 사용하여야 한다. 왜냐하면, 증명 신청을 할때 비밀 열쇠가 생성 되었고 그것을 browser가 갖고 있기 때문이다.
어떤 경우에는 증명서 신청을 WWW로 받지 않을 수도 있다. 고유 이름과 신원 증명서류를 전자 메일이나 다른 방식으로 먼저 공증 사무소에 제출하고, 신원 확인이 완료되면 어떠한 확인 절차를 거쳐서 browser에서 열쇠 쌍을 생성하고 증명서를 바로 발급받는 것이다.
사용자 증명서는 Mozilla browser자체에 있는것이므로 Mozilla를 지워버린다던가 하면 같이 없어지고 만다. 서버 증명서나 CA증명서는 증명서만 다시 받으면 되지만, 사용자 증명서는 비밀 열쇠를 browser가 가지고 있기 때문에, 지워버리면 처음부터 다시 발급 받아야 한다.
따라서, Mozilla를 새로 설치한다던가 할 경우에는
key.db, cert.db, cert-nameidx.db등의
화일을 백업 받도록 사용자들에게 주의를 줄 필요가 있다.
또한 네트워크 보안의 중요한 역할을 담당하므 공증 사무소 (CA) 에 대해서도 알아보고 SSLeay에 포함된 프로그램을 이용하여 공증 사무소를 운영하는 방법에 대해서도 알어 보았다.
이 시스템은 정말로 안전한가? 이것만 설치하면 시스템 전체가 안전해 지는가?SSL에 대해서 이 질문은 두가지로 대답할 수 있다.
SSLtelnet의 경우 통신 내용 전체가 암호화 되므로 password만 암호화 되는 one-time password나 SecureID등보다 훨씬 안전하다. 또한, SSLtelnet의 서버와 클라이언트는 공증 사무소의 인정을 받아야 하므로 임으로 암호를 생성하여 연결하는 SSH(Secure Shell)보다 믿을만 하다. (단, 증명서를 발급받아야 하므로 귀챦다.)
TCP/IP 자체가 Security Payload를 지원하지 않는 한 SSL의 응용 분야는 이와 같이 계속 확장될 것으로 보인다.
httpd.conf에서
SSLVerifyClient를 1이나 2로 설정하면
사용자 증명서를 요구한다. 이 경우 접속할 때마다 사용자의 고유이름이
SSLLogFile에서 지정한 화일에 저장된다.