SSL 인증서 HOWTOFranck Martin양배 박
1Chapter. 일반적인 글1.1. 소개이 글을 읽는 독자들은 아마 필자처럼 OpenSSL 프로젝트에 있는 메뉴얼을 뚫어지게 읽어보았으리라 생각된다. 그리고 아마 필자처럼 읽고나서도 뭐부터 시작해야될지, 어떻게 인증서를 다뤄야될지 헷갈렸을 것으로 생각된다. 이 문서는 그런 여러분들에게 좋은 해답이 될 것이다. 이 HOWTO 문서에서는 비 리눅스 환경의 응용프로그램들도 다루고 있다: 만약 리눅스에서만 인증서를 사용할 수 있다면 이 글을 읽을 필요도 없을 것이다... 모든 OS, 응용프로그램들을 다루기는 힘들겠지만, 최대한 언급할 예정이다. 만약 필자에게 해줄 조언이나 수정사항이 있다면 franck@sopac.org로 e-mail을 보내주기 바란다. 이 HOWTO 문서는 리눅스 문서화 프로젝트(The Linux Documentation Project)에 발간된 문서이다. 최신 버전은 이 사이트에 올라올 것이다. 1.1.1. 라이센스이 문서는 어떠한 방법으로 배포해도 무방하다. 단, 문서에 대해 어떠한 보증도 할 수 없다; 상용 목적에 대한 것은 더더욱 할 수 없다. 간단히 말해서, 만약 여러분이 이 문서를 참조하다 상용 프로그램이 망가지면 여러분이 책임을 져야 한다. 필자는 이에 대한 어떠한 책임도 없다. Copyright (c) 2001 by Franck Martin and others from the openssl-users mailing list under GFDL (the GNU Free Documentation License). Please freely copy and distribute (sell or give away) this document in any format. It's requested that corrections and/or comments be forwarded to the document maintainer. You may create a derivative work and distribute it provided that you:
만약 이 HOWTO를 제본할 계획이 있다면 필자에게 리뷰 목적으로 샘플 한부를 보내주면 감사하겠다. :-) 기타 어떠한 조언 등도 감사히 받겠다. ;-) 1.1.2. 기본 지식서론에서 소개했다시피, 이 문서는 OpenSSL 메뉴얼을 읽어본 사람들 기준으로 만들어졌다. 만약 여러분이 OpenSSL 내의 메뉴얼을 보지 않았다면 그것부터 보길 권한다. 혹여 보안에 대한 기초지식을 모른다면, 보안 관련 책자를 한권 사보길 권한다. 인증서를 제대로 활용하기 위해서는 이러한 지식이 바탕이 되어야 한다. 보안을 강화하기 위해 어떤 조치를 해야하는지, OpenSSL이 어떤 기능을 제공할 수 있고 그렇지 못한지를 모른다면 이 문서만 가지고는 아무 것도 할 수 없을 것이다. 1.2. SSL은 뭐고, 인증서는 뭔가?Secure Socket Layer(SSL) 프로토콜은 넷스케이프사에서 웹서버와 브라우저 간의 보안 통신을 위해 만들어졌다. SSL은 통신할 때 인증기관(Certificate Authority, CA)라는 것을 이용해서 서로 인식하게끔 되어 있다. 이 과정을 간단하게 설명하면 다음과 같다.
위 개념은 SSL의 기본 동작 원리이므로 반드시 이해하고 넘어가야 한다. 다음 장에서 각 용어에 대해 자세히 설명할 것이다. 1.2.1. Private Key/Public Key:개인키/공개키개인키/공개키 암호의 가장 큰 특징은 하나의 키로 암호화를 하면, 해당되는 쌍의 다른 키로만 풀 수 있는 점이다. 예를 들어 A키와 B키가 하나의 쌍이라면, A키로 암호화를 하면 B키로만 풀 수 있으며, B키로 암호화를 하면 A키로만 풀 수 있다. 이 특징이 이해하기 어려울 수도 있지만, 일단 그렇다고 암기하는 것이 좋다. 이러한 키는 소수(Prime numbers)를 기반으로 생성되며, 그 길이(bit단위)가 길수록 암호화의 강도가 쎄진다. 개인키/공개키는 이러한 이론을 바탕으로 약간 응용한 기법이다. 하나의 키는 비밀로 간직하고, 다른 키는 모두에게 공개한다. 그렇게하면 다른 사람들이 여러분에게 메시지를 보낼 때 공개키를 이용해서 암호화된 메시지를 보낼 수 있다. 이 메시지는 비밀키를 가지고 있는, 여러분 혼자만이 풀 수 있다. 그렇다면 반대의 경우엔 어떻게 될까? 메시지를 개인키로 암호화해서 보낸다면 어떻게 될까? 이 경우에는 모든 사람이 메시지를 열어볼 수 있을 것이다. 하지만 특정 개인키를 가지고 암호화했다는 것이 증명되기 때문에, 특정인이 보낸 메시지라는 것을 증명할 수 있다. 주의해야할 점은 메시지를 보낸 사람이 누구라는 것을 증명할 뿐이지, 메시지 자체는 모든 사람이 열어볼 수 있다는 것이다! 이제 서로 간에 공개키를 주고받기만 하면 된다. 그냥 상대방에게 공개키를 보내달라고만 하자. 어짜피 공개되어도 무방한 키이기 때문에 별다른 보안장치 필요없이 인증서와 함께 전송하면 된다.
1.2.2. 인증서자. 앞에서 개인키/공개키 기법을 익혔으니 그것을 적용하기만 하면 된다. 하지만 잘 생각해보면 뭔가 문제가 있다는 것을 깨달을 수 있을 것이다. 내가 받은 공개키가 그 사람(또는 웹사이트)의 것이라는 것을 어떻게 알 수 있을까? 혹시 제3자가 상대방을 가장해서 보낸 것이 아닐까? 이를 확인하기 위해 일일히 직접 상대방을 찾아가 볼 수도 없는 노릇이다. 이를 해결하기 위해서 모든 사람이 믿을 수 있는 제 3자가 나서게 된다. 그 사람의 인증서는 너무나도 유명해서 기본적으로 모든 사람이 알고 있다고 해보자. 그 사람은 특정 키가 그 사람의 것이라는 서명한 인증서를 발급한다. 여기에는 E-mail 주소, 소유자의 이름, 인증서 사용 용도, 유효기간, 위치, Common Name(CN, 웹사이트 주소나 E-mail 주소), 인증서ID 등등의 정보가 저장되어 있다. 그리고 마지막으로 이 정보를 공개키와 공개키의 해쉬값과 같이 저장해서 인증서를 만든다. 이러한 개념은 신뢰하고 있는 사람이 서명한 인증서 역시 신뢰할 수 있다는 생각을 전제로 한 것이다. 이런 신뢰 관계가 트리 형태로 형성되어 점점 불어난다. 웹브라우저의 경우를 살펴보자. 신뢰할 수 있는 제 3자의 인증서는 인증기관(Certification Authorities, CA), 또는 루트 인증기관(Root CA)이라고 불리며, 브라우저속에 기본적으로 내장되어 있다. 이러한 CA는 인증서나 인증 철회된 인증서 목록을 전문적으로 관리하는 기관이다. CA가 서명한 인증서는 조금이라도 변경되면 서명이 깨지기 때문에 안전하다. 인증서를 서명할 때 자신의 개인키로 서명할 수도 있다. 이러한 인증서는 자체 서명 인증서(Self signed certificate)라고 불린다. 모든 루트 인증기관의 인증서는 자체 서명되어 있다.
위 내용은 인증서 샘플이다. 위에서 볼 수 있다시피 인증서는 서명자의 정보, 인증서 주인의 공개키, 인증서 유효기간, 인증서 서명값 등으로 이루어져 있다. 비밀키는 인증서에 들어가 있지 않으며, 절대로 들어가서도 안되고 노출되어서도 안된다. 이 인증서를 가지고 인증서 주인에게 암호화된 메시지를 보낼 수 있으며, 인증서 주인이 보낸 메시지가 진짜라는 것을 확인할 수 있다. 1.2.3. 대칭키공개키 기반 암호화 알고리즘은 정말 강력한 알고리즘이다. 하지만 실전에서 써먹을려고 하면 좀 생각해봐야 한다. 공개키 기반 암호화 알고리즘은 비대칭 형태이기 때문에 복호화를 하기 위해서는 다른 키가 반드시 필요하다. 암호화한 키로는 암호화만 가능할 뿐, 풀 수가 없다. 반면에 대칭키 기반 알고리즘은 하나의 키로 암호화하고 해독한다. 보안 측면에서는 키가 노출될 가능성이 적은 공개키 기반 암호화 알고리즘이 안전하다. 하지만 공개키 기반 알고리즘의 문제점은 너무 느리다는 것이다. 그렇다면 안전하고 속도도 빠른 방법은 없을까? 해결책은 대칭키를 공개키로 암호화해서 전송하면 된다. 물론 개인키는 전송할 필요도 없고, 해서도 안된다. 이렇게 하면 대칭키는 송,수신자만 알아볼 수 있다. 여기에다 대칭키를 랜덤으로 생성하는 기능까지 넣으면 혹시 한번 누출되더라도 다음 통신할 때는 다른 키를 사용하기 때문에 안전하다. 이렇게 대칭키를 송신한 후에는 대칭키를 가지고 암호화해서 통신하면 된다.
1.2.4. 암호화 알고리즘암호화 알고리즘의 종류에는 여러가지가 있다. 크게 대칭키/비대칭키로 나누기도 하며, 키의 길이도 다양하다. 일반적으로 암호화 알고리즘은 특허로 등록할 수 없다. 예외적으로 미국에서는 특허 등록이 가능하며, 법으로 보호받을 수 있다. OpenSSL은 암호화 알고리즘이 군법이나 보안법 등에 위배되지 않는 국가에서 개발된 프로그램이다. 이렇듯 알고리즘의 종류도 많고, 각 국가마다도 사용할 수 있는 알고리즘이 다르기 때문에 본격적인 통신에 앞서 어떤 알고리즘을 써서 통신해야할지 결정해야 한다. 초기화 과정(Negotiation)에서 웹브라우저와 웹서버는 서로 선호하는 알고리즘을 주고받는다. 그리고 상호간에 일치하는 알고리즘 중 가장 선호도가 높은 알고리즘을 선택해서 통신한다. OpenSSL은 컴파일 시에 다양한 알고리즘을 선택해서 컴파일할 수 있으므로, 각 국가별로 적절한 옵션을 선택해서 사용하면 된다. 1.2.5. 해쉬해쉬는 해쉬 함수에 의해서 연산된 결과(숫자값)다. 단방향 함수라고 불리기도 하는데, 이는 일단 해쉬값을 가지고는 원본을 복구하기가 불가능하게 만들어졌기 때문이다. 해쉬값은 원본에 조그마한 변화만 생겨도 엄청나게 바뀌고, 원본을 조작해서 원본 해쉬값과 똑같은 값을 얻기가 거의 불가능하도록 되어 있다. 해쉬는 Message digest라고 불리기도 한다. 해쉬는 주로 패스워드 메커니즘과 원본 메시지/파일의 손상/조작 유무를 파악하는데 유용하게 쓰인다. Internet Enginering Task Force (IETF)라는 단체에서는 여러가지 기술적인 이유로 SHA1이나 MD5 등의 해쉬 알고리즘을 사용하길 권장한다. (참고 : RFC2459 7.1.2 와 7.1.3) 1.2.6. 서명서명은 서명자가 특정 메시지의 내용이 변조되지 않았다는 것을 보증하는 역할을 한다. (일반적으로 여러분이 특정 메시지를 작성했다는 것을 증명하는데 많이 쓰인다) 단순한 텍스트 메시지에 서명할 수도 있고, 인증서에도 서명할 수 있다. 서명하기 위해서는 우선 대상 메시지의 해쉬값을 계산해야 한다. 다음에 여러분의 개인키로 해쉬값을 암호화하고, 이 해쉬값과 서명된 인증서, 메시지를 함께 전송하면 된다. 수신측에서는 공개키를 이용해서 암호화된 해쉬값을 푼다. 그리고 자체적으로 원본 메시지의 해쉬값을 다시 생성해서 수신한 해쉬값과 비교한다. 만약 일치하면 서명한 내용이 변조되지 않았다는 것을 뜻하며, 일치하지 않으면 서명 이후 전달 과정 중 변조된 것이다. 이 과정에서 인증서도 같이 전달되기 때문에, 서명은 여러분의 공개키와 인증서를 전파하는데도 활용할 수 있다. 서명하는 방법은 크게 2가지가 있다. 메시지를 통째로 인코딩해서 서명하는 방법이 있으며, 서명과 별도로 원본 메시지를 첨부하는 방법도 있다. (일반적으로 구분 기호를 이용해서 첨부한다) 첫번째 방법은 기본적인 암호화 방법을 그대로 사용한 형태다. 공개키를 이용해서 메시지를 복호화하면 된다. 이 방법은 반드시 복호화를 해야지만 메시지를 열어볼 수 있다. 반면에 두번째 방법은 복호화를 하지 않아도 바로 메시지를 읽어볼 수 있다. 수신자들 중에 암호를 풀 수 있는 사람이 적다면 두번째 방법을 사용하는 것이 좋다. 1.2.7. 암호문“암호문(Passphrase)은 패스워드(Password)의 확장판이다.”. 오래전에 유닉스 시스템에서의 패스워드는 최대 8자리로 제한되어 있었다. 암호문은 이러한 제한이 없다. 암호는 길면 길수록 깨기 어렵다. 참고로 최근 유닉스 시스템에서는 MD5 해쉬를 사용하기 때문에 패스워드의 제한이 없어졌다. 1.2.8. Public Key InfrastructurePublic Key Infrastructure(PKI)는 공개키 기반 알고리즘을 이용한 통합 보안 시스템이다. PKI는 인증서를 서명/철회하고, 철회인증서 리스트를 관리하고, 공개키를 배포하는 등 보안에 필요한 시스템과 데이터베이스를 관리하는 소프트웨어를 말한다. 일반적으로 공개키를 배포할 때는 웹사이트나 LDAP서버를 이용해서 배포한다. 이러한 PKI는 누구든지 만들어서 관리할 수 있다. 하지만 몇몇 신용있는 업체에서 상용 PKI를 만들어서 운영하고 있다. 이 업체의 PKI 인증서는 기본적으로 웹브라우저나 응용 프로그램에 내장되어 있다. 구체적으로 E-mail 보안을 위해선 어떻게 해야하는지 살펴보자. 상용 PKI를 이용해서 E-mail등에 쓰기 위한 범용 인증서를 발급받기 위해서는 미국 돈으로 메일 주소당 연간 약 $100를 지불해야 한다. 이러한 업체에서는 공개키를 배포하지 않기 때문에, 여러분이 어떤 사람의 공개키를 알고 싶다면 그 사람으로부터 인증서(공개키)를 메일 등을 통해 받는 방법 밖에 없다. 1.3. S/Mime은 무엇을 의미하는지? 그리고 다른 프로토콜들은?SSL은 원래 웹서버에서 사용하기 위해 개발된 프로토콜이다. SSL은 네트워크 계층 구조로 설계되어 있기 때문에 상위 계층에 어떤 프로토콜이 오더라도 잘 작동되도록 설계되어 있다. 따라서 조금만 응용하면 여러 프로토콜에도 사용할 수 있다. IMAP에 SSL을 적용해서 IMAPS가 되며, POP는 POPS, SMTP는 SMTPS 등으로 응용해서 쓸 수 있다. 이러한 보안 프로토콜들은 기존의 프로토콜과 혼란을 피하기 위해 다른 포트를 사용한다. 트랜잭션 같은 부분에도 SSL을 사용할 수 있다. SSL이 실시간 통신에서 사용하기 위한 프로토콜이라면, S/Mime은 E-mail과 같은 비실시간 네트워크에서 보안 통신을 하기 위한 프로토콜이다. 수신자의 공개키를 이용해서 암호화하기 때문에 수신자만 내용을 확인할 수 있다. 이때 수신자의 공개키는 여러분이 알아서 구해야 한다. 여러분과 수신자는 항상 온라인 상태가 아니기 때문에, 공개키를 웹사이트나 저장소, 또는 E-mail 등을 통해 요청해서 얻어와야 한다. (일반적으로 공개키 뿐만 아니라 인증서까지 받아와서 수신자의 신원을 확인한다.) 반대로 클라이언트에서 인증서를 송신할 수도 있다. 웹브라우저가 웹서버에게 인증을 받기 위해 자신의 인증서를 보내게 된다. 이러한 웹브라우저용 인증서는 CA 웹사이트에서 받을 수 있다. 이 인증서는 CA의 개인키로 서명되어있기 때문에 변조의 위험은 걱정하지 않아도 된다. 2Chapter. 인증서 관리2.1. 설치최근에는 배포본의 발달로 OpenSSL을 매우 쉽게 설치할 수 있다: 대부분의 배포본은 패키지 관리 시스템을 갖추고 있으며, 이를 이용하면 간단하게 설치할 수 있다. 자세한 것은 배포본에 딸려있는 문서나, OpenSSL 타블(tarball) 파일의 README, INSTALL 파일을 읽어보길 권한다. 이 HOWTO는 인증서를 사용하는 방법에 관련된 내용이기 때문에, 설치와 관련된 내용은 언급하지 않겠다. 다음은 필자가 설치한 OpenSSL 옵션들이다. 여러분의 설치 방법이나 배포본에 따라 다소 차이가 있을 수 있을 것이다. 이 HOWTO에서는 필자의 설정을 기준으로 설명하겠다. 필자의 OpenSSL 디렉토리는 /var/ssl/ 이다. 이후에 설명할 OpenSSL의 모든 명령은 저 경로에 기반한다. 여러분은 굳이 저 경로로 설정하지 않아도 된다. 단지 필자의 설정이 이렇다라는 것을 알고 있으면 예제를 이해하는데 도움이 될 것이다. OpenSSL은 기본적으로 /usr/lib/ssl/openssl.cnf 파일을 설정파일로 사용한다. 만약 /etc/openssl.cnf를 설정파일로 쓰고 싶다면 openssl ca 명령이나 openssl req 명령에 -config /etc/openssl.cnf 옵션을 적어줘야 한다. 필자는 /etc/openssl.cnf 파일을 비롯한 모든 설정파일을 /etc 경로로 사용한다. 다른 유틸리티라든지 라이브러리는 /usr/lib/ssl 에 설치되어 있다. 2.1.1. CA.pl 유틸리티일단 CA.pl 유틸리티가 /usr/sbin 과 같은 실행경로에 있는지 확인해봐야 한다. 원본 파일은 /usr/lib/ssl 디렉토리에서 찾을 수 있다. CA.pl 유틸리티는 openssl의 복잡한 명령을 줄여주는 유틸리티다. 이 문서에서는 CA.pl 유틸리티를 사용하는 예제에는 반드시 같은 역할을 하는 openssl 명령을 같이 명시할 것이다. 실행경로에 있는 것을 확인했으면 /usr/sbin/CA.pl 파일을 편집해서 ca와 req 명령에서 -config /etc/openssl.cnf 옵션을 포함하도록 수정해야 한다.
2.1.2. openssl.cnf 파일/etc/openssl.cnf 파일에는 OpenSSL의 기본 설정이 들어있다. 귀찮은 옵션들을 입력하기 싫다면 이 파일을 편집해서 옵션을 줄일 수 있다.
openssl.cnf파일에 대해 약간의 부연설명을 하겠다.
2.1.3. 인증기관 생성하기인증기관(Certification Authority, CA)을 생성하기 위해서는 openssl.cnf파일을 수정한 후 다음과 같은 명령을 입력해야 한다:
위와 같이 실행하면 CA로 사용할 인증서를 선택하라고 뜬다. 그냥 엔터를 치면 새로운 인증서를 생성한다. 이렇게 생성된 인증서는 기본적으로 365일간 유효하다. 다음 장에서 유효기간이 좀더 긴 CA를 생성해 볼 것이다. 2.2. 루트 인증기관(Root CA) 인증서 생성하기
위 명령을 실행하면 자체 서명 인증서(Self signed certificate)가 만들어진다. 인증서는 newreq.pem로 저장된다. Common Name(CN) 부분은 “ACME root Certificate”와 같이 설정하면 무방하다. 이렇게 생성된 newreq.pem 파일은 개인키와 공개키가 함께 들어있으므로 분리해야 한다. -RSA PRIVATE KEY-부분은 개인키 부분이므로 private/cakey.pem 파일로 분리하고, -CERTIFICATE- 부분은 공개키 부분이므로 cacert.pem 파일로 분리하자. 이 작업이 끝나면 newreq.pem 파일을 삭제하자. 이제 index.txt파일이 비어있는 것을 확인해보자. serial파일에는 01이란 숫자가 들어가 있을 것이다. 이 파일은 인증기관의 이력을 관리하는 역할을 하며, 하위 인증서를 생성할 때마다 index.txt에 내용이 추가되며 일련번호(serial)가 증가한다. 위 명령으로 생성한 루트 인증서는 365일간 유효하다. 유효기간이 지나면 루트 인증서 뿐만 아니라 그 인증서로 서명한 하위 인증서까지 모두 만료되고, 새로운 인증서로 갈아치워야 할 것이다. 아마 대부분의 회사들은 이런 번거로움을 피하기 위해 루트 인증서의 유효기간을 5년에서 10년 정도로 설정한다.
위 예제는 “CA.pl -newcert” 명령과 비슷하지만, 인증서의 유효기간을 10년으로 늘인 명령이다. 루트 인증기관 인증서는 SSL에서 매우 중요한 역할을 한다. 이 인증서가 뚫리면, 하위 인증서 모두가 변조될 수 있다. 따라서 인증서가 손상되지 않고, 개인키가 노출되지 않도록 각별히 주의해야 한다. 물론 암호문(Passphrase)도 없애면 위험하다. 몇몇 사람들은 이런 위험을 피하기 위해 아예 개인키 파일을 플로피 디스크나 이동식 디스크 등에 보관하기도 한다. 그렇게 한다면 컴퓨터 자체가 해킹당해도 안전할 것이다. 지금까지 루트 인증기관의 인증서를 생성하는 법에 대해서 알아보았다. 이제 생성한 루트 인증기관 인증서를 배포하는 일만 남았다. 다른 사람들이 인증서를 받아서 웹브라우저에 등록하면 끝이다. 암호문(Passphrase)은 하위 인증서를 서명할 때마다 입력해야 하므로 까먹지 말자. 2.3. 하위 인증기관 인증서(Non root Certification Authority Certificate) 생성하기FIXME because I'm not sure about the procedure. 서명된 인증서로 또다른 인증서를 서명하는 것도 가능하다. 서명을 통해 상위 인증기관이 하위 인증기관을 신용한다는 것을 증명할 수 있다. 이렇게 생성한 하위 인증기관 인증서로 또다시 1단계 더 하위 인증기관 인증서를 서명하는 것도 가능하다. 인증서는 이와같이 트리 형태로 구성된다. 다른 인증기관으로부터 서명받기 위해서는 개인키와 인증요청서(Certificate Request)를 생성한 후, 인증요청서를 상위 인증기관에게 보내야 한다. 서명된 인증서를 받으면 인증서(-CERTIFICATE- 부분)은 cacert.pem파일로 저장하자. 인증요청서 생성시 만들어졌던 개인키(-PRIVATE KEY-부분)는 private/cakey.pem파일로 저장하면 된다. 2.4. 루트 인증기관 인증서를 신뢰할 수 있는 루트 인증서 저장소에 설치하기우선 인증서에서 -CERTIFICATE- 부분만 잘라내야 한다.
이 파일을 http://mysite.com/ssl/cacert.crt 와 같이 웹사이트에 올려놓자. 다음엔 웹서버 MIME설정에서 확장자가 .crt인 파일에 대해서 인증서로 인식하게끔 수정하자. 이와 같은 작업 후에 웹브라우저에서 인증서를 받아서 저장하면 된다. 웹사이트에 인증서를 올리는 것은 배포하는데 상당히 괜찮은 방법이다. 단지 주의해야할 점은 다른 사람이 여러분의 웹사이트를 가장해서 가짜 인증서를 배포할 수도 있다는 것이다. 이렇게 가짜 인증서가 배포되면 해커는 모든 것을 뒤엎어버릴 수 있다. 마이크로소프트사는 윈도우 업데이트 기능을 이용해서 인터넷 익스플로러의 루트 인증서를 검사한다. 만약 차후 마이크로소프트사 제품에 여러분의 인증서가 탑재되길 원한다면 마이크로소프트사에 연락을 하기 바란다. 2.4.1. 넷스케이프/모질라/파이어폭스웹서버에 MIME설정이 제대로 되어 있다면, 인증서를 받을 때 자동으로 루트인증서 설치 마법사 화면이 뜬다. 마법사를 통해서 인증서를 설치하면 된다. 최종적으로 인증서 용도에 대해서 물어보는데, 필요에 따라 웹사이트 보안(Web site security), E-mail 서명(E-mail signing), 디지털 코드 서명(Code signing)을 선택하면 된다. 2.4.4. 인터넷 익스플로러인증서 파일을 다운로드한 후에 받은 파일을 더블클릭하자. 그러면 인증서 내용이 나오는데, 인증서 설치 버튼을 누르면 인증서 가져오기 마법사가 실행된다. 인증서가 자체 서명(Self signed)되어 있기 때문에 인터넷 익스플로러는 자동적으로 인증서를 '신뢰할 수 있는 루트 인증기관' 저장소에 설치할 것이다. 이 과정이 끝나면 인터넷 익스플로러는 해당 인증서와 그 하위 인증서들에 대해서 더이상 신뢰할 수 없다는 에러를 출력하지 않을 것이다. 인터넷 익스플로러의 도구 -> 인터넷 옵션 -> 내용 -> 인증서 메뉴를 통해서도 인증서 설치 마법사를 실행할 수 있다. 2.5. 인증서 관리2.5.1. 인증요청서(Certificate Request) 생성/서명 방법
위 명령은 newreq.pem이란 이름으로 개인키와 인증요청서를 만드는 명령이다. Common Name (CN) 입력 시에 인증서를 사용할 웹사이트 또는 E-mail 주소를 넣으면 된다. 예를 들어 www.sopec.org라는 웹사이트에서 사용할 인증서라면 www.sopec.org를 입력하면 되고, franck@sopac.org 란 E-mail에서 사용할 인증서라면 franck@sopac.org라고 입력하면 된다.
위 명령은 인증기관으로 인증요청서에 서명하는 명령이다. 인증기관의 자세한 정보(개인키, 공개키 등등)는 openssl.cnf 파일에 담겨있다. 위 명령을 입력하면 암호문(Passphrase)을 입력하라고 뜨는데, 이때 인증기관 생성 시에 입력했던 암호문을 입력하면 된다. 그러면 최종적으로 newcert.pem이란 이름으로 서명된 인증서가 생성된다. 추가적으로 인증기관의 디렉토리에 newcerts/xx.pem파일도 생성되고, index.txt와 serial도 업데이트된다. newreq.pem파일의 -PRIVATE KEY- 부분은 개인키 부분이고, newcert.pem파일의 -CERTIFICATE- 부분은 인증서 부분이므로, 용도에 따라 잘라서 사용하면 된다. 인증기관의 newcerts/ 디렉토리에 생기는 파일은 newcert.pem 파일의 복사본이다. 인증기관으로 서명할때마다 여기에 복사본이 저장되며, index.txt에도 그 내용이 삽입된다. 혹여 발급한(서명한) 인증서가 의심스럽다면 이 정보들을 이용해서 확인할 수 있다. 이 과정 중에 정말 주의해야할 점이 있다. newreq.pem파일을 보면 인증요청서 부분(-CERTIFICATE REQUEST-) 뿐만 아니라, 개인키(-PRIVATE KEY-)도 함께 포함되어 있다. 인증기관은 서명할 때 인증요청서만 필요하지, 개인키는 전혀 필요치 않다. 다시한번 강조하지만 개인키는 누구에게도 공개되어선 안된다. 이는 인증기관이라 할지라도 마찬가지이다. 혹여 인증기관으로 인증요청서를 보낼 때는 반드시 개인키 부분은 잘라내서 따로 보관하고, 인증요청서 부분만 보내도록 하자. 2.5.2. 인증서 철회방법인증서가 도난이나 분실, 기타 이유로 더이상 사용할 수 없는 상태라면 CA에서는 해당 인증서를 철회할 수 있다. 이미 서명한 인증서를 철회하려면 다음의 명령을 입력하면 된다.
그러면 데이터베이스에 인증서가 철회되었다고 표시된다. 다음으로 인증철회목록(Certificate Revoked List, CRL)을 업데이트하자.
인증철회목록은 웹사이트 같은 곳에 올려서 공개하면 된다. crldays나 crlhours 옵션을 이용하면 인증철회목록에 다음 CRL 발행일자를 표시할 수 있다. crlexts 옵션을 이용하면 openssl.cnf파일의 crl_exts 영역이 포함된 CRL 버전2가 생성된다. (기본적으로 버전1이 생성된다)
2.5.3. 인증서 갱신방법클라이언트가 여러분에게 기존의 인증서 대신에 새로운 키로 새 인증서를 만들어 달라고 할 수 있다. 이 경우 우선 기존의 인증서를 파기하고, 이후에 새로운 인증요청서에 서명해야 한다. 기존 인증서는 index.txt 파일을 참조하면 알 수 있다. 이 파일에서 해당하는 인증서의 Distinguished Name(DN, 일련번호(serial)를 찾은 후에 cert/ 디렉토리를 찾아보면 해당 인증서가 있다. 이걸 가지고 인증서 철회작업을 하면 된다. 인증서 유효기간을 직접 설정하고 싶다면 다음과 같은 명령으로 할 수 있다.
위에서 [now] 부분과 [previous enddate+365days] 부분을 적당한 값으로 치환하면 된다. 2.5.4. 인증서 확인방법인증서는 인코딩되어 있기 때문에, 눈으로 알아보기 어렵다. 다음의 명령을 입력하면 텍스트형태로 볼 수 있다:
2.5.5. index.txt 파일index.txt 파일을 열어보면 OpenSSL에서 관리하는 인증서의 정보를 볼 수 있다. R는 철회된 인증서, V는 유효한 인증서, E는 유효기간이 만료된 인증서를 뜻한다. 2.5.6. 웹기반 인증기관 관리웹을 통해서 인증기관(CA)을 관리하고 싶다면 몇가지 조건이 필요하다.:
이 모든 작업들은 웹서버에서 스크립트 작업으로 할 수 있다. FIXME: some code here for the web interface... 3Chapter. 응용프로그램에서 인증서 활용하기3.1. 인터넷 프로토콜 보안3.1.1. Apache에서 mod_ssl을 이용하여 인증서 사용하기응용프로그램에는 절대로 자체서명된 루트 인증서를 사용해선 안된다. 특히 Apache와 같이 개인키에서 비밀문구를 제거해야하는 프로그램일 경우 더욱 그렇다. 우선 Apache에 사용해야 할 인증서를 생성해야 한다. 이때 Common Name (CN)을 입력할 때 www.mysite.com과 같이 웹사이트의 이름을 입력해야 한다. 다음에 생성된 인증서를 편집해서 ---CERTIFCATE --- 부분만 남기고 제거하자. 다음에는 개인키의 비밀문구를 제거해야 한다. 그래야 부팅시에 웹서버가 패스워드 입력없이 정상적으로 동작한다. 개인키가 포함된 newreq.pem파일을 가지고 다음의 명령을 통해 비밀문구를 제거할 수 있다.
위 작업을 거치면 비밀문구가 제거된 wwwcakeyunsecure.pem 이름의 개인키 파일이 생길 것이다. 이 파일에는 비밀문구가 빠졌기 때문에 보안상 대단히 위험하다. 때문에 이에 대한 조치를 취해야 한다: 예를 들어 파일 권한을 변경해서 관리자만 볼 수 있게 한다든지 등의 조치가 필요하다. 만약 이 파일이 누출된다면 여러분의 사이트는 망가지게 될 것이다. wwwkeyunsecure.pem 파일을 /etc/httpd/conf/ssl/ 디렉토리에 복사하자. 그리고 newcert.pem 파일도 같은 디렉토리에 newcert.crt 라는 이름으로 복사하자. /etc/httpd/conf/ssl/ssl.default-vhost.conf 파일을 다음과 같이 수정하자.
위 작업을 마치면 httpd를 재시작해야 한다. 우선 httpd를 멈추고(/etc/rc.d/init.d/httpd stop), 모든 httpd 프로세스가 죽었는지 확인하자(killall httpd). 그리고 httpd를 시작하면 된다.(/etc/rc.d/init.d/httpd start) 3.1.3. POPS에서 인증서 사용하기ipop3sd 에서 인증서를 사용하기 위해서는 인증서를 생성한 다음, 개인키에 비밀문구를 제거하고, 공개키와 개인키를 합쳐서 /etc/ssl/imap/ipop3sd.pem 파일로 저장하자. 이 경로는 Mandrake 9.0 리눅스 imap RPM 패키지의 경로이므로 배포본마다 다를 수도 있다. IMAPS에서 인증서를 사용하기 위해서는 동일한 파일을 /etc/ssl/imap/imapsd.pem 경로에 두면 된다. CN 필드는 반드시 메일 클라이언트가 접속할 사이트의 이름을 넣어야 한다. (예:mail.xyz.org). 클라이언트에서 MS-Outlook을 이용해서 접속하려면 설정 메뉴의 서버 탭에서 받는 메일 서버를 mail.xyz.org 로 입력하고, 기타 설정의 고급 탭에 들어가서 암호화된 연결(SSL) 필요라는 곳에 체크하면 된다. 포트번호는 자동으로 995번으로 바뀌게 될 것이다. (imaps) 반드시 MS 인터넷 익스플로러에 해당 루트인증서가 신뢰할 수 있는 루트 인증기관 저장소에 설치되어있어야 접속할 수 있다. 3.1.6. 마이크로소프트 키 관리자(Microsoft Key Manager)로 키 생성하고 서명하기마이크로소프트 키 관리자에서 키를 생성하려면 우선 용도를 선택해야 한다. 예를 들어서 IMAP이나 WWW 등을 선택하면 된다. 이후에 마법사를 이용해서 키를 생성할 수 있다. Distinguished Name은 반드시 예전에 생성했던 키와 다른 값을 사용해야 한다. Common Name (CN)은 예를 들어 imap.mycompany.com 과 같은 것을 사용하면 된다. 마법사는 그 결과를 C:\NewKeyRq.txt 파일에 저장한다. 이때 키 관리자는 해당 키가 서명이 되어있지 않다고 알려준다. 이 파일을 OpenSSL OpenSSL /var/ssl 디렉토리에 복사해서 newreq.pem 파일로 이름을 바꾼 후에 서명하자.
newcert.pem 파일은 잡다한 텍스트가 들어있어서 키 관리자용으로 적합치 않다. newcert.pem 파일을 열어서 -CERTIFICATE- 부분을 제외하고는 삭제하자. 다음의 명령으로 간단하게 해결할 수 있다:
기타 다른 텍스트 에디터를 이용해서 -CERTIFICATE- 부분을 제외한 나머지를 삭제해도 무방하다. 위 작업을 마치면 newcertx509.pem 파일에는 -CERTIFICATE- 부분만 남게 된다. newcertx509.pem 파일을 키 관리자가 실행되고 있는 컴퓨터로 복사하고, 해당 키 파일의 아이콘에다가 마우스 우측버튼을 누르면 "인증서 설치"라는 메뉴가 뜬다. 이 메뉴를 선택해서 설치를 누르고 비밀문구를 입력하면 해당 키를 설치할 수 있다. 3.2. E-mail 보안3.2.1. S/MIME 인증서 생성과 사용앞에서 배운 방법으로 인증서를 생성하고 서명하자. 단, Common Name (CN) 필드는 여러분의 E-mail 주소를 입력해야 한다. 그리고 다음의 명령으로 원본 메시지(test.txt)를 인증서(newcert.pem)와 키파일(newreq.pem)로 서명해서 test.msg라는 파일로 출력하자:
이제 여러분은 test.msg 파일을 다른 사람에게 보내면 된다. 이런 방법을 이용해서 공식 보고서나 문서 등에 서명할 수 있다. 3.2.2. MS Outlook에서 인증서 사용하기MS Outlook에서 인증서를 사용하려면 pkcs12 포맷의 파일이 필요하다. 다음의 명령으로 newcert.pem 파일과 newreq.pem 파일에서 pkcs12 포맷의 파일을 생성할 수 있다:
또는 다음의 명령을 이용해서 서명된 인증서를 pkcs12 파일에 탑재할 수 있다.
이렇게 뽑아낸 파일은 공개키와 개인키가 같이 묶여있고, 개인키는 비밀문구에 의해서만 보호되고 있다. 따라서 이 파일이 타인에게 알려지지 않도록 주의해야 한다. MS Outlook 에서 도구 메뉴로 간 뒤에 옵션과 보안을 선택하자. 가져오기/내보내기 버튼을 누르고 newcert.p12 파일을 가져오면, 내보낼 때 입력했던 암호와 디지털 ID "Franck Martin"를 입력하라고 뜬다. (Franck Martin은 필자의 이름이며 위의 예제에서 입력한 이름을 사용하면 된다.) 그 다음에 확인 버튼을 클릭하자. 이제 설정 버튼을 누르면 기본 보안 설정을 할 수 있다. 새로 만들기를 통해 보안 설정을 변경하고 확인 버튼을 누르면 적용된다. 이 작업을 마치면 E-nmail에 서명을 붙여서 보낼 수 있다. 앞으로 E-mail을 송신하면 본문, 공개키, 서명이 함께 전송된다. 차후 수신자 쪽에서는 이렇게 받은 공개키를 이용해서 암호화된 메일을 보낼 수 있다. 앞에서 인증서를 자체 서명 인증서(루트 CA 인증서)로 서명했기 때문에, 수신자 측에서 신뢰할 수 있는 인증서로 등록되어 있지 않다면 경고메시지가 뜰 것이다. 이때 루트 인증기관 인증서를 다운로드를 해서 설치하면 경고메시지가 없어진다. "인터넷 익스플로러에서 루트 인증기관 인증서를 신뢰할 수 있는 루트 인증서 저장소에 설치하기"장을 참고해서 설치하자. 여러분이 메일을 보낼 때 메시지 전체를 암호화할 것인지, 일반 텍스트로 보낼 것인지 선택할 수 있다. 사실 이때의 암호화란 진정한 의미의 암호화가 아니다. 공개키가 함께 전송되기 때문에 누구나 메시지를 복호화해서 볼 수 있다. 단지 S/MIME 을 지원하는 수신자만 읽을 수 있게 제한을 걸 뿐이다. MS-Outlook XP 이전 버전에서는 인증서를 수신하면 인터넷에 검색해서 확인하도록 되어 있다. 때문에 E-mail이 화면에 표시되기 전에 몇초간 소요된다. 만약 인터넷 접속이 끊겨 있다면 메일 내용을 볼 수 없을 것이다. MS-Outlook XP 이전 버전은 이러한 옵션이 선택불가능한 버그가 있기 때문에 시스템이 오작동할 수도 있다. 3.2.5. Evolution에서 인증서 사용하기Evolution 1.0 버전은 S/MIME을 지원하지 않는다. 단, PGP를 지원하기 때문에 그것을 이용하면 된다. S/MIME 기능은 차후 지원하도록 예정되어 있다. (Evolution 버그 데이터베이스에 등록되어 있다) 그러나 평문으로 서명되어 있다면, 서명을 확인하지는 못하지만 내용은 볼 수 있다. (이전 버전의 Evolution은 MS-Outlook에서 사용하는 3 MIME 서명 형태도 제대로 인식하지 못한다.) 3.3. 파일 보안Securing Files3.3.1. WinCryptWinCrypt는 마이크로소프트 암호화 API를 이용한 파일 암호화/서명 프로그램이다. 이 프로그램은 부가적으로 파일/폴더들을 zip파일로 압축해서 서명하는 기능도 제공하고 있다. 또한 자체적으로 인증서 저장소 기능이 있기 때문에, 사용자가 원하는 인증서를 설치하거나 삭제할 수 있다. 서명 시에는 설치된 인증서 중에서 사용할 것을 선택해서 서명하면 된다. 인증서 생성 방법은 MS Outlook과 동일하다. 또한 같은 인증서 저장소를 사용하고 있기 때문에 WinCrypt는 MS Outlook과 완벽하게 호환된다. WinCrypt로 서명된 filename.sgn 파일은 다음의 명령으로 확인할 수 있다:
OpenSSL을 이용해서 호환되는 포맷으로 서명하고 싶다면 다음의 명령으로 서명할 수 있다:
인증서의 구조나 기타 정보를 보기 위해서는 다음의 명령으로 확인할 수 있다:
3.4. 디지털 코드 인증서3.4.1. 마이크로소프트 코드여러분은 문서 외에도 여러분이 개발한 프로그램이나 애플릿에도 서명할 수 있다. 이렇게 서명된 프로그램은 사용자에게 바이러스나 백도어로 감염되지 않았다는 것을 보증할 수 있다. 이렇게 프로그램에 서명하기 위해서는 Microsoft Authenticode SDK가 필요하다. 이 SDK는 MSDN에 나와있는 마이크로소프트 웹사이트에서 받을 수 있다. 앞에서 배운 방법을 이용해서 인증서를 생성하자. 단 Common Name (CN)은 “ACME Software Cert”로 생성하자. 그 후에 인증서를 서명하고 그 파일을 pkcs12 포맷으로 변환하자.
생성된 newcert.p12 파일을 윈도우에서 더블클릭하면 해당 인증서를 인증서 저장소에 설치할 수 있다. 이 작업을 마쳤으면 최종적으로 다음의 명령을 이용해서 프로그램에 서명할 수 있다.
이렇게 서명된 프로그램을 설치하거나 실행하려고 하면 “My Application” 이란 제목의 창이 뜰 것이다. 제목을 클릭하면 -i옵션에서 입력한 링크로 연결될 것이다. 3.5. IPSecIPSec은 TCP/IP에서 IP Layer 위에서 동작하는 새로운 형태의 프로토콜이다. 이 프로토콜을 이용하면 인터넷의 2개의 호스트 간에 ad-hoc 암호화 링크를 만들 수 있다. IPSec은 IPv6에서 완벽하게 지원되지만, IPv4에도 적용해서 사용할 수 있다. IPSec은 호스트 간의 키 교환 등의 메커니즘이 상당히 어려워서 상당히 구현하기 어려운 프로토콜이다. 키 교환을 DNS 프로토콜로 할 수도 있지만 거의 이렇게 쓰이지는 않는다. 또한 아직 유명한 인증기관들도 엔터프라이즈 환경에 필요한 인증 기능을 다 제공하지 않고 있다. 3.5.1. FreeS/WANFreeS/WAN 프로그램은 GNU/Linux에서 IPSec을 구현한 대표적인 프로그램이다. 현재 버전은 1.9.7 인데, 이 버전은 x.509 와의 호환성 문제로 인해서 패치가 필요하다. 패치는 http://www.freeswan.ca/ 에서 받을 수 있다. 몇몇 GNU/Linux 배포본에는 이미 패치가 적용된 패키지가 내장되어 있을 것이다. 이 경우 내장 패키지를 설치해도 무방하다. 이 버전을 이용하면 openssl을 통해 FreeS/WAN이나 DNS CERT records에서 쓸 수 있는 인증서를 생성할 수 있다. FReeS/WAN은 Microsoft 에서 구현한 IPSec과 호환된다. 더 자세한 정보는 Nate의 페이지를 참조하기 바란다. 3.5.1.1. FreeS/WAN 게이트웨이 머신IPSec 게이트웨이의 인증서를 생성할 때 CN(Common Name)은 FQDN(Fully Qualified Domain Name)이 되어야 한다. 예를 들어 [host.example.com.]과 같이 쓰면 된다. 인증서를 생성하고 나서 서명하는 것을 잊지 말자. 작업을 끝내면 newcert.pem 파일과 newreq.pem 파일이 생길 것이다. newreq.pem 파일은 개인키와 기타 정보들이 담겨있는 파일이다. 이 파일을 편집해서 --BEGIN RSA PRIVATE KEY-- 에서 --END RSA PRIVATE KEY-- 사이의 내용을 제외한 라인은 삭제하자. 그리고 파일을 게이트웨이에 옮기면 된다. 개인키가 유출되지 않도록 주의하자. 아래의 예제는 FreeS/WAN 설정 디렉토리가 /etc/freeswan 일때의 예제이다. 여러분의 환경에 맞게 수정해서 입력하면 된다.
루트 인증서도 FreeS/WAN 디렉토리에 복사하자. 개인키는 필요없고 인증서만 복사하면 된다.
인증철회목록(CRL)을 생성해서 FreeS/WAN 설정 디렉토리에 복사하자. 기존에 사용하던 인증철회목록이 있다면 그것을 복사하면 된다.
게이트웨이의 ipsec.secrets 파일을 편집해서 다음의 라인을 추가하자:
패스워드는 공개키/비밀키를 생성할 때 입력했던 것을 적으면 된다. ipsec.conf 파일은 다음과 같이 편집하자:
위 설정파일에서 보다시피 2개의 접속이 이루어진다. 하나는 게이트웨이와의 접속이고, 다른 하나는 게이트웨이 뒤의 네트워크 접속이다. 이 설정은 게이트웨이에 방화벽이나 NAT를 운영하는 환경에 유용하다. 위 설정을 마치면 제대로 된 인증서를 가지고 있는 클라이언트라면 게이트웨이에 접속할 수 있다. 3.5.1.2. FreeS/WAN 클라이언트클라이언트의 작업도 서버의 설정 작업과 비슷하다. 인증서를 생성하되, CN 필드는 클라이언트의 FQDN으로 입력하면 된다. 예를 들어 [clienthost.example.com.]과 같이 입력하면 된다. 이렇게 생성한 인증요청서는 반드시 게이트웨이 인증서의 인증기관에서 서명해야 한다. 이 방법으로 해당 링크가 인증되는 것이다. 게이트웨이에서 다음의 파일을 설정 디렉토리로 복사하자:
또한 개인키를 제외한 루트 인증서도 FreeS/WAN 설정 디렉토리에 복사하자.
인증철회목록(CRL)도 생성하자.
마지막으로 여러분의 인증서(개인키말고)를 게이트웨이에 복사하자.
ipsec.secrets 파일을 수정해서 클라이언트 개인키를 읽을 수 있도록 만들자.
그리고 ipsec.conf 파일을 다음과 같이 수정해서 해당 네트워크 연결을 활성화하면 된다:
이제 VPN 링크를 올리자
자동으로 링크가 올라가도록 하려면, 설정 파일에서 'auto=add' 부분을 'auto=start'로 바꾸자. 3.5.1.3. MS 윈도우 2000/XP 클라이언트 머신이 작업은 FreeS/WAN 클라이언트에서의 작업과 유사하다. 인증서를 생성하되, CN 필드는 FQDN으로 생성하자. (예:winhost.example.com) 단 이 인증서를 pkcs12 포맷의 파일로 변환해야 한다. “MS-Outlook에서 인증서를 사용하기”장을 참고해서 변환하자. pkcs12 포맷의 파일에 루트 인증서가 포함되어 있는지 확인하자 다음의 명령으로 세부사항을 확인할 수 있다:
이 파일을 MS 윈도우에 복사하자. 복사할때 외부에 누출되지 않도록 주의하자. Marcus Muller의 ipsec.exe 프로그램을 C:\ipsec 디렉토리에 복사하자. 마이크로소프트 관리 콘솔(Microsoft Management Console, MMC)을 실행해서 '스냅인 추가/제거' 메뉴를 선택하자. '추가' 버튼을 누른 후에 '인증서'를 선택하고 '컴퓨터 계정'을 선택하고 '다음' 버튼을 누르자. '로컬 컴퓨터'를 선택하고 '마침'버튼을 누르면 된다. 이번에는 'IP 보안 정책 관리'를 선택하고 '추가' 버튼을 누르자. '로컬 컴퓨터'를 선택하고 '마침' 버튼을 누르면 된다. 이제 pkcs12 포맷의 인증서를 등록하자. '인증서(로컬 컴퓨터)'를 선택 후에 '개인'을 선택하자. 동작'메뉴의 '모든 작업'을 누른 후에 '가져오기'를 선택하면 인증서 가져오기 마법사가 실행된다. 다음에 pkcs12 파일을 선택하고 '다음'버튼을 누르면 암호를 입력하라는 메시지가 뜨는데, 암호를 입력하고 '다음'버튼을 누르면 된다. 인증서 저장소는 자동으로 선택에 놓고 '다음'을 누른 후에 '마침'을 누르면 된다. 이후 정말 설치할 것이냐는 팝업창이 뜨면 예를 누르고 MMC를 종료하면 인증서가 저장된다. 한번 저장한 인증서는 다시 추가하지 않아도 된다. ipsec 프로그램의 문서에 나와있는 방법대로 ipsecpol.exe(Windows 2000)이나 ipseccmd.exe(Windows XP)를 설치하자. 윈도우의 ipsec.conf 파일을 편집해서 "RightCA"부분을 'openssl x509 -in cacert.pem -noout -subject' 명령의 결과로 바꾸자. 다음은 그 예제이다. (몇몇 이름이 바뀌고, '/' 문자가 콤마로 바뀐 것에 주의하자)
다음은 링크를 활성화할 차례다. 'ipsec.exe'를 실행하자. 다음처럼 출력될 것이다:
그럼 이제 게이트웨이로 핑을 날려보자. 'Negotiating IP Security'라고 몇번 나올 것이다. 일반적으로 한번에 되지 않고 몇번 출력되므로 당황하지 말자. T1 회선의 VPN 서버와 케이블 모뎀에서 테스트해본 결과 약 3-4 핑 정도가 출력되었다. 이와 같이 내부 내트워크에서 외부로 나갈 때 위와 같은 작업이 이루어진다. 4Chapter. 글로벌 PKI4.1. 현재 운영되고 있는 PKI이제 여러분은 상용 PKI를 사용할건지, 개인 PKI를 만들 것인지 선택해야한다. 인터넷에서 보안 HTTP 통신을 위해 상용 PKI로부터 인증서를 서명받는다고 가정해보자. 일반적으로 인증서의 가격은 호스트 숫자와 용도에 따라서 매겨진다. 이 가격은 일반적으로 호스트의 신원을 분석하는 비용과 상용 PKI업체의 이윤이 포함되기 때문에 도메인 이름 비용보다 훨씬 비싸다. POP나 IMAP에 추가적으로 SSL을 적용하고 싶을때까지는 그럭저럭 비용이 감당될 것이다. 하지만 각 사용자별로 E-mail 인증서를 발급받는다면? 인증서에 대해 엄청난 비용을 지출해야될 것이며, 매년 유효기간이 만료될때마다 갱신하는 금액, 노력이 엄청나게 들 것이다. 이 외에도 위 방법을 이용하면 다른 인증서에 서명하는 작업을 할 수 없기 때문에, 클라이언트/서버 환경에서 인증서로 클라이언트를 인증하는 작업을 할 수 없다.(Web server, IPsec, 등등..) 다른 인증서에 서명할 수 있는 인증서는 만들 수 없을까? 현재까지 배운 바로는 이 문서에 나와있는 방법을 이용해서 스스로 인증기관을 만드는 수 밖에 없다. 이 방법은 인증서를 관리하는 입장에서는 편리하지만, 다른사람의 입장에서는 그 인증기관이 신뢰할만한 기관인지 파악하기가 힘들다. 해결책은 DNS와 같이 계층적으로 인증할 수 있는 시스템을 만드는 것이다. 이 시스템을 Global PKI라고 한다. 4.2. 글로벌 PKI의 필요성오늘날 PC 보안의 중요성은 갈수록 커지고 있다. 빌게이츠(Bill Gates)는 앞으로 마이크로소프트가 기능과 보안 중에 선택해야 한다면 보안을 선택해야 한다고 말할 만큼 그 중요성이 크다. 인터넷에서 악의를 가진 사람들은 계속 증가하는 추세다. 누구나 여러분에게 데이터를 보낼 수 있으며, PC에 악성 소프트웨어를 설치하도록 유도할 수 있다. 해결책은 통신하기 전에 상대방이 누구인지 확인하고 접속하면 된다. 만약 어떤 사람과 통신하다가 공격을 받았다면, 앞으로 그 사람에 대해 차단하면 될 것이다. 불행히도 이 방법은 스팸 메일에 대해서는 적용하기 힘들다. 스팸 메일은 발송자를 추적하기 어려운 경우가 많기 때문에 수신을 하기 싫어도 받을 수 밖에 없다. 만약 E-mail을 수신할 때 인증서를 통해 신원정보를 함께 받는다면 어떨까? 여러분은 그 메일을 신뢰하고 열어볼 수 있을 것이다. 이 방법은 일반전화의 송신자 번호 알림 기능과 비슷하다. 이와 같이 E-mail(S/MIME)이나 인터넷뱅킹(HTTPS), 소프트웨어설치(코드 서명) 등에 인증서를 사용하면 상대방에게 한층 더 신뢰감을 줄 수 있다. 아쉬운 점은 인증서는 아직까지 비용 문제로 인해 널리 쓰이고 있지 않다는 점이다. 특히 Yahoo, Hotmail, CA Online 등의 대형 메일업체에서 지원하고 있지 않다는 점이 걸림돌이다. 물론 일부 무료로 E-mail 인증서를 발급하는 기관이 있지만 단지 E-mail 주소가 실존한다는 것만 증명할 뿐, 실제로 그 사람의 신원을 증명해주지는 못하고 있다. 글로벌 PKI가 필요하다. 이미 프로토콜과 표준이 정해져 있으며, 이는 기존의 것을 뜯어고치지 않고도 적용할 수 있다. IETF에서 이미 모든 메커니즘을 다 구현해 놓았다. LDAP서버로 인증서를 저장할 수 있고, DNS서버로 저장소를 찾을 수 있다. HTTP를 사용해서 다른 응용 프로그램에 인증서를 전송할 수 있고, S/MIME을 통해 E-mail을 보호할 수 있다. 남은건 기술적인 문제가 아니라 정책적인 문제이다. 어떤 다른 표준이 글로벌 PKI와 연동해서 돌아가게 될까? 그리고 어떤 기관이 이런 서비스를 제공해줄까? 제공되는 보안 등급은 얼마나 높을까? 여러분이나 누군가가 이런 문제에 대한 해답을 알고 있다면 적극적으로 추진해주길 바란다. 필자는 이 부분을 후에 Internet Society의 PKI 워킹그룹의 연구내용으로 업데이트할 예정이다. Internet Society는 .org에 대한 탑레벨 도메인 이름도 관리하고 있는 단체이다. 여기서 스팸메일차단에 대한 많은 연구가 이루어지고 있다. |
Lend money to a bad debtor and he will hate you.    
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
