Draco님의 tweet에서 보고는 구글링해서 들어가 본 Unu라는 사람의 블로그에서 씁쓸한 글 하나를 읽었다. 요약하자면, 루마니아에 사는 자칭 화이트 해커(ㅋㅋ)라는 Unu라는 사람이 nProtect 홈페이지를 해킹해서 사용자 정보를 볼 수 있었다고 광고한 일이다. 국내 뉴스에서는 화이트해커라고 하던데, 뭐, 말하자면 공격해서 취약점은 밝혀서 망신을 주지만, 빼낸 정보를 악용하지는 않는다는 뭐 그런 얘기다. 그렇다고 하니 믿을 수밖에. :) Unu라는 사람은 SQL injection을 이용해서 홈페이지를 뚫긴 했는데, 나의 눈을 이끈 부분은 그런 자세한 해킹 기법이 아니고, nprotect에서 사용자의 패스워드를 clear text로 보관하고 있었다는 사실이다. 웃기는 짬뽕이다. 서버 해킹 당한 거는 이러저러한 연유로 그렇게 될 수도 있다 치지만, 사용자 패스워드를 clear text로 보관한다는 건, 사이트의 설계 당시부터 애초에 잘못된 보안 개념을 가지고 있었으며, 아직까지도 고칠 여유가 없었거나, 고칠 능력이 없었거나, 아니면 그게 잘못된 것인지를 아예 모르고 있었다는 얘기다.

이게 왜 잘못된 거냐 하면... 코딩이 짜증나니 머리도 식힐 겸 친절한 썰을 하나 풀도록 하자.

아이디와 패스워드는 대표적인 개인 인증 방식에 사용된다. 아이디는 자신의 이름과 같은 것이어서 각각의 개인을 구분하는 정보이고, 패스워드는 그 개인만이 알고 있는 비밀 정보이다. 패스워드를 알고 있는지 여부를 살펴서 그 아이디의 주인이 맞는지를 확인한다. 이게 대충 수박 겉핥기 식으로 정의하는 인증이다.

사실 이것보다는 우리가 허고헌날 쓰는 자물쇠와 열쇠의 비유를 쓰는 것이 좋겠다. 우리가 자물쇠를 열쇠로 열 때, 그 자물쇠에 꼭 맞는 열쇠가 있어야만 한다. 다른 말로 하자면, 자물쇠는 자신과 꼭 맞는 열쇠만을 인식한다. 자물쇠를 아무나 열지 못하게 하려면, 우리는 열쇠를 잘 간수해야 한다. (사실 우리는 열쇠를 꽁꽁 숨겨 다니지도 않고, 누가 열쇠를 쳐다 본다고 해서 그 열쇠를 도둑맞았다고 호들갑을 떨지는 않는다. 그래도 사진기와 같은 아주 정확한 기억력을 가진 누군가가 열쇠를 쳐다보고, 머리 속에 사진을 찍어 두었다가 그것과 똑같은 열쇠를 만든다면 열쇠를 도둑 맞은 것과 똑같은 상황이 되긴 한다. 물론, 보통 사람들은 그런 기억력을 가지고 있지 않기 때문에 우리는 열쇠를 누가 쳐다보는 것에 둔감하고, 그럴 만도 하다.) 열쇠의 모양은 자물쇠와 열쇠 사이의 비밀정보이다. 문지기가 자물쇠 옆에 늘상 붙어 있다고 해도, 자물쇠만 봐서는 열쇠의 모양을 알 수가 없다. 첩보 영화에 나오듯이 밀랍 덩어리를 자물쇠 안에 넣어서 모양을 짜내지 않는다면 ;)

그림으로 그리자면 이런 식이다.
발로 그린 그림이지만, 왼쪽이 자물쇠 오른쪽이 열쇠라고 너그럽게 봐 주도록 한다. (열쇠가 더 커 보이는 건 착시현상이다. 어찌됐든, 열쇠를 자물쇠에 넣는 것이 더 큰일 같아 보이긴 하다. ^^ ) 문지기는 사용자가 열쇠를 자물쇠에 넣는 짧은 동안에는 열쇠를 슬쩍 관찰할 수 있다. 문지기의 눈이 고감도 카메라라면 이 순간 열쇠는 도둑맞은 것이나 다름 없지만, 우리는 문지기의 관찰력이 그리 높지 않다고 대충 가정한다. 이러한 방식과 유사한 것이 대부분의 ID/PW 방식의 인증들이다. 사이트는 사용자가 전송한 패스워드를 짧은 기간동안 clear text로 볼 수 있다. 사이트 관리자가 딴 생각을 품고 이 패스워드를 다른 곳에 기록해 놓는다면 (문지기의 카메라 같은 시각) 이 사용자의 패스워드는 그 관리자에게 노출된다. 그런데, 암묵적으로 우리는 관리자가 인증 과정에서 관찰한 패스워드를 따로 몰래 저장해 놓지는 않는다고 가정한다.

앞의 nprotect 같이 패스워드를 평문으로 저장하는 것은 아래 그림과 같이 표현할 수 있다.
이게 뭔가. 열쇠를 관찰하는 사람 말고도 자물쇠를 관찰하는 사람도 열쇠의 모양을 알 수 있다. 이 경우에는 문지기의 눈을 가려 놓거나, 자물쇠를 또 다른 것으로 감싸고 거기에 또 다른 자물쇠를 달거나 하지 않으면 열쇠를 만들 능력이 되는 모든 사람이 자물쇠를 열 수 있다. 이런 바보 같은 자물쇠를 만드는 사람은 없을 것이다.

통상적인 Unix 패스워드 시스템에서는 자물쇠를 일방향 함수로 만든다. 일방향 함수라는 것은 순방향으로는 계산이 쉽지만, 역방향으로는 계산이 어려운 함수이다. 일방향 함수가 아닌 함수의 예는 쉽게 이런 것을 들 수 있을 것이다. f(x) = x + a. -.-;; f(x) = y 일 때, y를 알면 x는 당장 알 수 있다. x = y - a의 관계가 있기 때문이다. (물론 함수 자체는 완전히 주어진다. 즉, a가 공개된다.) 그런데 일방향 함수는 f(x)가 완전히 주어져 있을 때에도 역방향 계산이 어려운 함수이다. 사용자의 패스워드는 x(열쇠)에 대응되고, 서버가 보관하고 있는 것은 패스워드의 일방향 함수값 y(자물쇠)에 대응된다. 열쇠(x)가 들어오면, 서버는 일방향 함수를 통과시켜서 일방향 함수값(y)을 구하고 저장하고 있는 일방향 함수값과 같은지 비교한다. 같으면 통과, 틀리면 실패이다. 보통 자물쇠와 같이 서버는 저장하고 있는 일방향 함수값(y, 즉 자물쇠)만 가지고는 패스워드(x, 즉 열쇠)를 알 수 없고, 사용자가 패스워드를 주었을 때 맞춰 볼 수만 있다. (물론, 이 때 서버는 사용자가 전달한 패스워드를 인증이 끝나면 폐기한다는 조건이 있어야 한다.)

또다른 잡담으로, 앞의 보통 자물쇠의 경우 기술이 좋아서 자물쇠 내부를 잘 들여다 볼 수 있는 사람들이 있다. 시중에 떠도는 금고털이들이 그렇다. 그건 자물쇠의 구조적인 한계 때문이기도 하고, 그림처럼 열쇠의 모양을 마음대로 만드는 것이 아니라 생각해 볼 수 있는 열쇠의 모양의 가지수에 한계가 있기 때문이기도 하다. 이 경우, 문지기는 이런 공격을 시도할 수 있다. 열쇠 하나를 만든다. 자물쇠에 맞춰본다. 안 맞으면 다른 열쇠를 만든다. 또 맞춰본다. 이런 걸 몇백만번쯤 하면 자물쇠에 맞는 열쇠를 만들 수 있을 것이다. 더구나, 열쇠/자물쇠의 규격이 문제가 있어서, 열쇠의 모양에 한계가 있다면 만들어야 하는 열쇠의 수는 줄어든다. 톱니가 4개 달린 열쇠에 톱니 하나당 높이의 단계가 10개 뿐이라면, 열쇠를 만개만 만들어보면 된다. 실제 ID/PW 인증의 경우에는 열쇠를 만드는 게 정말 아무것도 아니다. 만개의 열쇠를 만들어서 자물쇠와 맞춰보는 작업을 몇초~몇시간 안에 할 수 있다. 그러니, 패스워드를 그냥 숫자 키패드에서 몇개 찍어서 쓰는 사람들은 몇초 안에 깨질 수 있는 패스워드를 쓰고 있다는 뜻이 된다.

또또 다른 잡담으로, 인증 과정에서 열쇠를 슬쩍 훔쳐볼 수 있는 서버(또는 문지기)가 탐탁치 않을 경우에는 어떻게 하는가. 자물쇠와 열쇠의 예에서는 비교적 간단하다. 열쇠를 조심해서 꺼내고, 손으로 잘 감싼 후에 자물쇠와 열쇠를 잘 갈무리해서 열면 된다. 열고 나서도 손으로 잘 감싸서 주머니에 넣으면 된다. 그럼 ID/PW를 이용한 인증에서는? 사실 방법이 없다. 자물쇠와 문지기의 예에서는 자물쇠와 문지기가 별개의 객체인 것처럼 말을 했지만, 실제로는 그렇지가 않다. 굳이 비유하자면, 사용자가 열쇠를 문지기에게 주면, 실제 열쇠를 자물쇠에 맞춰보는 건 문지기가 한다. 문지기에게 줄 때까지 열쇠를 아무리 잘 갈무리해봤자 일단 문지기에게 주고 나면 문지기가 열쇠를 빼돌리지 않는다고 그냥 믿어야 한다.

이와 관련하여, 웹서버의 경우 https 통신을 하면 무조건 안전하다고 믿는 사람들이 있다. 뭐, 사실 안전도가 비약적으로 상승하는 것은 맞다. 앞의 비유에서는 사용자가 문지기의 바로 앞에서 열쇠를 꺼내 주는 것처럼 보이지만 그렇지가 않기 때문이다. 현실에서는 열쇠를 꺼내서 본을 뜨고 어쩌고 해서 열쇠의 (완전히 똑같은) 사본을 만든다. 그리고 속이 잘 비치는 편지 봉투에 넣고 우편함에 넣으면, 오토바이를 타고, 트럭을 타고, 기차나 비행기를 타고 문지기에게까지 배달된다. 그리고 문지기가 열쇠를 자물쇠에 맞춰본다. 그러니 배달 과정에 있는 수많은 사람들이나 또는 우편함 속에 몰래 숨어 있던 스파이가 열쇠를 빼돌릴 수 있다. https 통신을 하면 열쇠를 무지하게 튼튼한 봉투에 넣어서 전달하는 것과 같게 된다. 그러니, 걱정해야 하는 수많은 사람들은 나가 떨어지고 문지기만 남게 된다. 안전도는 비약적으로 상승한다. 하지만... 여전히 문지기는 남아 있다. ID/PW 방식을 사용하면 이건 어찌해 볼 수가 없는 문제이다. PKI 방식을 쓰는 수 밖에.


ps. 그림 그리는 게 제일 힘들었음. -.-;;
ps2. 왜 글이 점점 늘어나지 -.-;; 일하기 싫다는 증거.
ps3. 패스워드편 말고 다른 게 있을지는 며느리도 모름.

국내에서 개발되어 국제표준인 ISO/IEC 14888-3 에도 들어가 있는 두 개의 전자서명 알고리즘이다. 이걸 OpenSSL에 어울리도록 코딩한 것이다.

올 봄에 나의 지도교수님의 언질로 만들었던 것인데, 애초의 마음먹은 것과는 달리 뒤에 가니 OpenSSL에 제대로 어울리는 코드는 만들어내지 못한 것 같다. 결정적으로 국내 표준에 명시된 HAS-160을 만들어 넣지 않아서 모양새가 좀 이상하다. 국제 표준(ISO/IEC 14888-3)에 있는 numerical example은 HAS-160을 안 썼다고 하기도 그렇고, 썼다고 하기도 그런 애매한 상태다. 국내 표준에 있는 numerical example과 맞아떨어지는 것을 제대로 구현하려면 HAS-160은 필수. 뭐, 그래서 OpenSSL에 패치를 보내는 거는 지금 상태에서는 적절하지 않고, 시간이 나면 HAS-160 코드를 만들어 넣으려고 했던 것도 시간이 지나니까 귀찮아져서 코드와는 점점 소원해진다.

그랴서... 그냥 썩혀 두기는 아깝고, 제대로 만들어 보자니 귀찮은... 계륵(?)과 비슷한 것이려나. 뭐, 어쨌든 여기에라도 포스팅해서 미끼를 던지고, 관심 두는 사람이 있는지 낚시질이나 해봐야겠다.

원래 올라가 있던 페이지: http://islab.postech.ac.kr/kcdsa.html

라이센스는 GPL v3

작성자는 Yeon-Hyeong Yang <yhyang@oberon.postech.ac.kr> <lbird94@gmail.com>

소스 코드:

windows에서 설치하기. 다음의 파일을 참조. 아래에 설명 보충.



1. perl 설치
http://www.activestate.com/Products/ActivePerl/ 에서 activestate perl을 download한다.
특별한 이유가 없는 한 MSI 패키지를 download한다.
msi 파일은 더블클릭하면 설치가 시작된다. 특별히 건드릴 일은 없으니 default setting으로 설치.

2. compiler
windows에 cygwin이나 borland c 등을 설치해서 쓸 정도의 사람은 아마도 여기의 설명이
필요 없을 것이니, visuall c++을 사용한다고 가정한다. 설명서에도 나와 있다시피
MS의 MASM이라는 assembler가 아마도 visuall c++에 기본으로 포함돼 있을 것이다.

MASM이 없는 경우(ml.exe가 없는 경우) more...를 참조.
more..
암호 관련 라이브러리들은 대부분 극한의 속도를 목적으로 하기 때문에 assembler를 이용한
빠른 코드를 당근 사용해주는 게 좋겠다.

3. configure
1번의 perl 설치는 사실 configure script를 실행하기 위한 용도이다.
cmd창을 띄워서 다음과 같이 실행한다. (시작->실행->cmd.exe)

> cd <현재 소스 루트>
> perl Configure VC-WIN32 --prefix=D:/project/lib/ssl

이런 식으로 된다. prefix는 openssl library와 header file들이 설치될 위치이다.
다음으로 실제 compile할 때 사용될 Makefile과 assembly code들을 만든다.
위에서 MASM을 사용하기로 했으니 ms\do_masm을 실행한다.

원래의 설명서에 보면 VC++ environment에서 다음을 진행하라고 되어 있는데,
VC++의 명령행 프롬프트는 다음과 같이 띄운다.
사용하는 visual studio의 버젼에 따라서 조금 다를 수는 있다. VC++ 6.0 같은 경우는
일단 cmd 창을 띄운 후(시작->실행->cmd.exe)에 vcvars32.bat 를 실행하면 된다.
이제 library를 build한다.

그런데 visual studio 2005를 사용하는 경우는 cp949에서 특정 문자를 표시할 수 없다는
에러가 나온다. 그럴 경우는 아래 more... 를 참조. 그런 에러가 안 난다면 상관 없다.
more..
컴파일이 정상적으로 끝났으면 이제 위에서 prefix로 정한 위치에 install을 해야 하는데
그전에 nmake test 를 통해서 library가 잘 만들어졌는지 확인해 볼 수 있다. 하지만 꼭 필요한
것은 아니고, 만족감을 얻고 싶거나, 정말 제대로 만들어졌는지 확인해 봐야 할 경우에만 한다.
마지막에 passed all tests라고 나오면 된다.
> nmake -f ms\ntdll.mak test

이제 install을 한다.
> nmake -f ms\ntdll.mak install
위와 같이 prefix로 정한 위치에 저런 디렉토리들이 만들어졌고 bin 디렉토리에
libeay32.dll, ssleay32.dll, openssl.exe 같은 파일들이 만들어졌는지 확인한다.
또 include\ssl 디렉토리에 각종 헤더파일들이 역시 존재하는지도 확인한다.

모두 다 제대로 들어 있다면 install은 ok.

linux에서 설치하기 위한 방법.




일단 소스 코드를 다운로드 한다.
http://www.openssl.org/source/에서 소스 코드를 다운로드 할 수 있다.
2007년 2월 23일 현재 최신 버젼은 0.9.8e 이다. http://www.openssl.org/source/openssl-0.9.8e.tar.gz
console에서 wget 같은 프로그램을 사용해서 다운로드한다.
그리고 tar 명령을 사용해서 압축을 푼다.

그 다음은 소스코드를 컴파일 가능한 상태로 만든다. 물론, 그냥 이 상태에서 make 명령으로
컴파일해도 컴파일은 되지만, config 같은 명령을 제공하는 소스코드는 config 명령으로
미리 설정해 주는 것이 좋다.

linux-elf 환경으로 설정했다고 나오고 끝난다. 이건 자기 환경에 따라 다를 수도 있다.

어차피 그냥 설치만 하고 끝날 것이 아니기 때문에 Makefile을 잠깐 살펴본다.
소스코드를 build하고 나서 설치할 위치가 나온다. 시스템에 이미 openssl package가 깔려
있을 수도 있으니 겹치지 않도록 저 위치에 그냥 설치하게 둔다.
위의 내용을 참고하여 최소한 프로그램들이 설치되어 있는지 확인한다. 사실 한번이라도
뭔가를 컴파일했던 환경이라면 대부분은 설치되어 있을 것이고, perl 은 혹시 모르니
와 같이 해서 확인한다.
계속해서 Makefile을 살펴보면
어떤 것들을 library에 포함시킬 것인지를 정하고 있다. SDIRS 항목을 잠시 살펴보면
1. 각종 hash function들과 message authentication code가 들어 있다.
2. block cipher (또는 대칭키 암호)들이 들어 있다.
3. 공개키 암호를 구현하기 위한 모듈들이 들어 있다. bn은 32-bit이나 64-bit 이상의 큰 수를
   다루기 위한 모듈이다. bn 모듈은 기본적으로 거의 모든 공개키 모듈에서 사용된다.
   ec는 타원곡선 연산을 위한 모듈이다. 타원곡선 연산은 ecdsa, ecdh 등에서 사용된다.
4. 암호 알고리즘을 구현하기 위한 기타 필수 요소들이다. string buffer, 입출력, random number
   generation 등등이 들어 있다.
5. 각종 암호학 알고리즘의 입력, 혹은 출력을 표현하기 위한 형식들이 정의된다.
   예를 들면 X.509 인증서 형식, ASN.1 데이터 표현형식 pkcs 등의 SSL에서의
   인증서 형식 등등이다.
마지막에 써 있듯이 config (혹은 Configure) 명령을 통해서 어떤 모듈을 포함시킬 것인지를
정해 줄 수 있다. 일단은 default 상태로 둔다.

두가지 주요 라이브러리를 생성하고 이것으로부터 shared object 등을 만든다.
사실 SSL 프로토콜을 위해서는 libssl.a가 필요하지만, 암호 라이브러리만을 위해서라면
libcrypto.a 만 있으면 된다. 물론, 다른 입출력이나 데이터 표현과 관련된 기능도
있어야 한다. 그 이후는 특별히 살펴볼 필요는 없을 것 같다.

이제 컴파일을 한다. 컴파일과 설치 자체는 대단히 간단하다.
$ make
라고 하면 컴파일이 시작된다. 끝날 때까지 할 일은 없고 기다리면 된다.
command prompt가 다시 나오면 끝난 것이다. 이때
와 같이 깨끗하게 끝나야 한다. error가 떴다면 문제를 수정해야 한다. 특별히 컴파일에 문제를
일으킬 만한 것은 당장 생각나지 않으니 일단 패스! -.-;

make까지는 자신의 홈디렉토리에서 수행해도 되지만 /usr/local 과 같은 곳에 설치를 하려면
root 권한이 있어야 한다. root 권한이 없거나 자신의 홈디렉토리에만 설치하고자 할 때는
config 명령으로 소스코드를 설정할 때 설치 디렉토리를 설정해 주어야 한다.
$ ./config --prefix=디렉토리이름
과 같은 식으로 하면 된다. config를 다시 했으면 컴파일을 다시 해주는 것이 좋다.
만약 뭔가가 꼬여서 처음의 깨끗한 상태에서 다시 시작하고 싶다면
$ make clean
이라고 한 다음에 다시 make하면 된다.

make가 끝났으면 install을 한다. install은
$ make install
이라고 하면 문제없이 수행되어야 한다. 설치하려는 곳에 권한이 없으면 에러가 출력될
것이다. 이때는 config를 다시 하고 make clean을 수행하고 다시 make하고 이어서
make install을 하는 게 안전하다.