저는 컴퓨터 관련 서적 자체를 잘 추천 안하는 편입니다. 요즘 같이 급박하게 기술이 바뀌는 세상에서는 사실상 공식 페이지가 최고의 레퍼런스가 되는 것이 현실이다 보니, 주변에서 기술 관련 서적을 산다고 하면 적극적으로 말리는 편입니다.

그러나 이 책은 정말 감히 추천할 만 합니다. 사실 저는 원서(Android NDK , Beginner's Guide)로 봤는데, 저자의 소스코드만 보더라도 상당한 내공이 느껴집니다. C++ 이나 Object Oriented Programming 에 상당한 조예가 느껴집니다. 팀원이 한글판으로 보고 있는데도 상당히 괜찮다고 하니 번역도 괜찮게 되어 있는 편인가 봅니다. 

안드로이드에서 가장 어려운 축에 드는 NDK(Native Development Kit) 부분을 '따라하기' 식으로 쉽게 풀어서 설명했을 뿐 아니라, 따라하기의 예로 든 것이 바로 '게임' 입니다. 더구나 철저하게 Bottom-up 식으로 설명을 하고 있기 때문에 아니 이게 이런 게임이 되는거야? 하는 신기함도 느끼실 수가 있습니다.

더구나 C 의 함수로 돌아가는 형태를 객체화를 시키는 능력을 보자면 코드를 만들어내는 사람의 내공을 느낄 수가 있는데 그런면에서 이 저자는 가히 탁월한 능력을 보여줍니다.

단 책이 몇 개의 심각한 오타를 가지고 있습니다. (국내판은 확인도 안하고 그대로 번역한 것 같은 느낌까지 준다고 하는군요. ) 따라하기 소스는 필히 원작자의 돌아가는 소스코드를 가지고 공부하시길 추천합니다. 

 
   저번에 올린 Emacs 와 JDEE 를 가지고 안드로이드를 개발하는 방법에 대해서 글을 올렸습니다. 그런데 최근 화두는 어떻게 하면 Mavenpom.xml 을 이용해서 JDEE 의 개발환경에 접목을 시킬까 하는 것이였습니다. 아.. 진짜 힘들었습니다. 그래도 몇가지 테스트와 노력을 끝으로 드디어 성공했습니다. 

참고한 사이트입니다. 


여기에서 근본적인 pom-parser.el 을 다운 받을 수 있었습니다. 그런데 제대로 동작을 하지 않더군요. 이유는 maven 의 실행 옵션들이 변해서 그렇답니다. 


위 사이트를 참조하시면 어떻게 변경해야 하는지 알 수가 있습니다. 위 까지만 적용하면 다 될 줄 알았는데 제가 기본적으로 jde-global-classpath 에 넣어둔 것이 사라지면서 에러가 발생하더군요. 그래서 기존에 있는 클래스 패스를 포함하는 버젼으로 수정했습니다. 
    올려둔 파일을 다운 받으시고 ~/.emacs.d/ 에 복사하시고 maven 프로젝트가 있는 곳 (정확히는 pom.xml 파일이 있는 곳)에 다음과 같은 파일 prj.el 을 만들어 주시면 됩니다. 


(jde-project-file-version "1.0")
(jde-set-variables
'(jde-compile-option-command-line-args
(quote ("-Xlint:all" "-Xlint:-serial"))))
(require 'pom-parser)
  (with-pom ()
  (pom-set-jde-variables *pom-node*))


프로그래머들이 너무 많은 고민을 할 필요가 없다. 그대 앞에는 키보드가 놓여 있지 않은가? 

- 누군가의 말 - 


누가 했는지 기억이 안나지만 제가 가끔 인용하곤 하는 말입니다. 너무 기술 문서를 보다 보면 '내가 지금 뭐하고 있나' 라는 생각이 들 때가 있는데 그때마다 이 말을 기억하고 바로 뭔가를 만들어 볼려고 노력하게 됩니다. 

어쨌건 키보드를 잡으면 어지간하면 졸음이 달아나기 때문이지요 ㅎㅎ

 
MySQL 이 오라클 손에 넘어가고 부터 걱정한 사람들이 많았는데 MySQL 을 개발했던 담당자들도 걱정이 많았나 봅니다. MySQL 이 5.5.30 부터 변화가 없던 것을 우려해서 만들었다고 하는데요. (결국 그 우려는 현실로 드러났지요 http://goo.gl/a7AOs )

그것은 바로 마리아디비  (https://mariadb.org/ )입니다.  MySQL 하고 현재 100% 호환이라고 합니다. 즉 MySQL 서버대신 마리아디비로 바꿔버려도 그대로 동작한다고 합니다. (심지어 인스토 파일 이름도 install_mysql 어쩌구 입니다 ㅎㅎ) 

오라클이 하는 짓이 짜증나신다면 한번쯤 생각해볼만한 대안이라고 볼 수 있습니다.
 

MySQL 5.5.31 버젼에서 라이센스 변화가 아무도 모르게(?) 살짝 진행됐나 보네요. 

기존 MAN Page

This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License.

바뀐 Man Page

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

음.. 이제 대세는 PostgreSQL 이 될려나요? 

만약 이게 의도적이라면, 오라클은 기존의 FSF 재단이 운영하던 MySQL 의 모든 소스를 훔친거나 다름 없습니다. MySQL 은 거기에 고용된 개발자 뿐만 아니라 오픈소스 프로젝트로 참여하고 있던 사람들의 소스도 포함됐기 때문입니다. 

참조 블로그: https://blog.mariadb.org/mysql-man-pages-silently-relicensed-away-from-gpl/
예전 포스트 에서 해결하는 방법을 올렸지만 unity-2d 랑 gnome-classic 등이 동작 안하는 현상이 13.04에서 발견됐습니다. 새로운 방법을 올리겠습니다. 

1. 기존에 쓰여져 있던 .xsession 을 지웁니다. (만약 존재한다면)  

2. 다음과 같이 차례로 입력합니다.

sudo apt-get install gnome-session-fallback
$ echo "gnome-session --session=gnome-fallback" > .xsession
$ sudo /etc/init.d/xrdp restart 



unity-2d 가 gnome-fallback 으로 바꼈다는 소리를 들었습니다. (카더라 통신입니다만..)
 
예전 포스트 에서 새로 배우는 가장 좋은 방법에 대해서 이야기 한적이 있습니다. 그 때는 영어로 표현됐지만, 결국 핵심은 

"그 것을 사용할 수밖에 없는 환경으로 자신을 몰아 넣으라는 것"



입니다. 저의 몇가지 경험담을 소개하겠습니다.

첫째. 세벌식

저는 세벌식 390 유저입니다. (세벌식 최종보다는 390이 더 손에 맞더군요). 이걸 95년도부터 사용했으니 꽤 오래 사용했습니다. 물론 이것을 배워서 쓰기전에는 저는 두벌식 유저였습니다. 틈만나면 꾸준히 한메타자로 연습했기 때문에 분당 400타를 넘나들 정도로 빠른 타수를 자랑했습니다. 그러던 어느날 공병호 박사의 세벌식에 관한 글을 읽고 나서 세벌식으로 바꿔야 겠다고 생각했습니다. 제가 한 일은 그냥 집에 있는 모든 자판 환경을 세벌식으로 변경한거였습니다. 두벌식을 쓰고 싶어도 꾹꾹 참았습니다. 레포트를 쓸때도 (제 연령대가 짐작되는 사람들도 계시겠군요 ㅎㅎ) 아무리 타수가 느려도 세벌식으로 작성했습니다. 작성하는 시간이 대폭 늘어 나버렸지만 계속해서 (미련하게) 세벌식으로 작성했습니다. 제일 힘든건 채팅할 때였습니다. 그 때 한창 나우누리나 하이텔에서 채팅이 성행하던 때였는데, 여성 유저가 들어오면 서로 말을 조금이라도 더 할려고 난리가 나던 시절이였습니다. 그럴때 세벌식 자판으로 떠듬 떠듬 거리면서 글을 치는것은 너무나 가혹한 행위였습니다. 짜증난다 하고 두벌식으로 바꾸면 분당 400타가 폭발하듯 글을 만들어 냈을 테니까요 ㅎㅎ. 그래도 참고 참고 했더니 오래 걸리지도 않았습니다. 한달도 안걸려서 분당 600타를 돌파하는 위업을 달성했습니다. 


둘째. 이맥스 (Emacs) 

저는 이맥스 유저 입니다. 이 에디터를 쓴지도 어언 몇년이 지났습니다. 참으로 쓰기 어려운 에디터라고 생각하지만 또 잘 쓰게 되면 이것만큼 편하게 작업을 도와주는 도구가 따로 없다고 할 정도입니다. 원래 클라이언트 (client) 프로그램부터 시작했던 나는 비쥬얼 스튜디오 (Visual Studio)를 잘 사용했습니다. 간단한 텍스트를 적을때는 VS 를 띄워서 사용하곤 하는 이상한 사람이였습니다. 그러다 저를 잘 지도해줄 수 있는 분과 만나서 vi 를 배웠습니다. 다른 세상이 열린것 같았습니다. 그래서 꾸준히 몇년동안 연습을 해서 VI 를 잘 쓰게됐는데, 어느날 후배의 한마디가 저를 바꿨습니다. 

"진짜 고수는 이맥스를 쓴대요 형"

역시 배우는 방법은 동일했습니다. 그날로 gVim 을 지워버렸습니다. (그 당시에는 윈도에서 개발하는 경우가 많았습니다) 그리고 아무리 속도가 느리더라도 이맥스에서 모든 개발을 할려고 노력했습니다. 다 늙어서(?) 날 새는 일이 많아졌습니다. 프로그래밍이 어려워서? 우습게도 에디터가 익숙하지 않아서 그랬습니다. 그냥 눈 딱 감고 vi를 가지고 개발 시작하면 순식간에 개발할 수 있었겠지만 역시 참으면서 이맥스로 느리게 느리게 개발했습니다. 그때 당시에는 효율이 정말 정말 떨어지는 행위였지만, 지금에 와서 생각해 보면 그렇게 했기 때문에 지금처럼 이맥스를 왠만큼 쓸 수 있는게 아닐까 싶습니다. 


셋째. OS 

두번째 사항에서도 쓰여져 있듯이 저는 출발이 윈도우 프로그래밍에서 시작했기 때문에, 윈도 환경이 익숙한 사람이였습니다. 그러던 어느날 리눅스를 잘 쓰고 싶다는 생각이 들더군요. 그래서 그날로 메인 OS를 지우고 우분투를 설치했습니다. 그리고 모든 개발을 리눅스 환경에서 했을뿐만 아니라, 회사에서 몰래 동영상을 볼때도 리눅스에서 동영상 플레이어를 설치하고 보기 시작했습니다. 익숙하지 않으니 정말 힘들었지만, 그 때마다 기능을 찾아가면서 외워가면서 사용했습니다. 얼마 걸리지 않아서 리눅스 환경을 윈도 환경만큼 쓸 수 있게 되더군요. 이 방식은 그대로 Mac OSX 에도 적용됐습니다. 

 
일단 링크부터 

https://github.com/facebook/hiphop-php/wiki

입니다.  php 로 시작한 페이스북이 대용량 접속을 처리하기 위해서 php 모듈을 c++ 로 변환해주는 방식을 쓴다고 알려져 있었습니다. 그런데 요즘 페이스북이 베타버젼중인 Node.js 로 갈아탔다고 합니다. 그러더니 자신들이 사용하고 있던 그 라이브러리를 오픈소스화 시켰습니다. (사실 이때쯤 유명해지기 시작했다는 것이 더 사실에 가까울 것입니다) 예전 Scribe 때와 똑같은 현상입니다. 카산드라도 그랬던가? 이건 확실하지 않네요. 

구글은 자신들이 계속 사용할 기술들을 오픈소스화 시키는 반면에 페이스북은 자신들이 더이상 사용하지 않을 기술들을 오픈소스화 시킨다는 느낌이 강합니다.



만약 제가 PHP 사이트를 운영중인 회사의 CTO 고, 그 사이트가 최근 대폭적인 사용자의 증가로 계속해서 하드웨어를 늘리면서 버티고 있는 상황에서 기술을 도입해야 할 고민에 쌓여있다면,  고민에 빠져들만도 합니다. 

hiphop-php 를 써야 하나?
그런데 저는 node.js 로 전 사이트를 리팩토링 하는 방법을 선택할것도 같습니다. 왜냐면 페이스북도 hiphop-php 대신 node.js 를 선택했기 때문이지요.

제가 그래서 공개시점이 항상 애매하다고 생각하는 것입니다. 물론 기술적으로는 문제가 없겠지만, 페이스북이 node.js 를 선택한 시점에서 기술 선택을 해야 한다면 node.js 쪽으로 기울지 않겠습니까? 

제가 이런 막되먹은 생각을 마구 하는 이유는 Scribe 가지고 테스트 하다가 현행화가 안되서 고생한 것 때문에 삐져서 이러는 거 아닙니다 쿨럭.. (그리고 공개는 몇년전에 되어 있더군요 최근 활성화 되기 시작한것이지) 

같이 일하는 후배분들에게 PKI 기본 개념을 설명해 주기 위해서 만들었던 자료입니다. 기왕 만든 김에 공개해 볼까 합니다. (10년도 더 전에 했던 내용을 정리한 거라 요즘 트렌드랑은 안 맞을 수도 있지만 기본이야 어디 가겠습니까? ㅎㅎ) 

PKIPublic Key Infrastructure 의 약자 입니다. 그대로 해석해서 '공개 키 기반' , 또는 '공개 키 인프라' 라고 해석할 수가 있습니다.  

 
RFC 2459 바로 그 표준에 관한 문서입니다. 이 문서를 보시면 PKI 에 관한 상세한 내용을 다 아실 수가 있습니다. 예전에 눈에 모래바람이 일어날 정도로 열심히 봤던 기억이 나는군요. X.509 는 인증서 포맷을 의미합니다.



PKI 기반을 이해할려면 3가지 기본적으로 알고 있어야 하는게 있습니다. 바로 위의 세가지 입니다. 보통 '해쉬 함수' 라고 불리는 Message Digest 와 (그렇지만 일반적으로 Computer Science 에서 부르는 Hash 는 Data Structure 에서 쓰이는 형식을 의미 하기 때문에 보안쪽에서 쓰이는 '해쉬 함수'는 Cryptographic Hash Function 이라고 구별해서 부릅니다. ) 대칭키 (Symmetric Key Algorithm) 과 비 대칭키 (Asymmetric Key Algorithm) 입니다. 


해쉬 (Cryptographic Hash - 암호화 해쉬) 함수입니다. 주로 하는일은 메시지 축약 (Message Digest) 입니다. 아무리 긴 파일이라도 간단하게 축약시킵니다. 대표적인 암호화 해쉬 알고리즘으로는 MD5 와 SHA-1 이 있습니다. MD5 는 128bit 이고 SHA-1 은 160bit 입니다. 즉 결과가 MD5 는 16바이트 , SHA-1 은 20 바이트로 나온다는 것입니다.
사실 토렌트를 사용하시는 분이면 이 암호화 해쉬가 사용된 부분을 심심치 않게 볼 수가 있습니다. 토렌트상에 존재하는 영화파일들은 파일 이름을 자기 맘대로 정할수가 있기 때문에, 이 해쉬값으로 같은 파일인지 체크할 수가 있습니다. 즉 파일 이름이 다르더라도, 크기와 해쉬값이 같다면 같은 파일이라고 볼 수 있다는 것이지요. 
 


일반적으로 '암호화' , '복호화' 라는 말을 쓰긴 합니다. 그런데 이 용어는 나중에 전자서명쪽을 설명 하다보면 혼선을 줄 수가 있습니다.  따라서 EncryptionDecryption 이라는 용어로 통일하기로 합니다.  무엇인가 변경을 가하는 것을 인크립션 (Encryption) 이라 하고, 변경된 것을 다시 원 상태로 돌리는 것을 디크립션(Decryption) 이라고 보시면 됩니다. 

 
대칭키 알고리즘 입니다. 말 그대로 키를 한개만 이용하는 것을 말합니다. 즉 인크립션 (Encryption) 과 디크립션 (Decryption) 시 한개의 같은 키를 이용합니다. (원리만 설명하는 것이니 패딩이니 , 이니셜 벡터니 하는 것을 건너 뛰겠습니다) 일반적으로 영화 같은데서 나오는 암호관련한 비밀번호 원리는  거의 이것에 해당합니다. 물론 유닉스의 비밀번호는 단방향이라 암호화 해쉬 함수를 쓰긴 합니다만. 무엇인가 암호화 된 것을 풀어낸다는 말이 나온다면 거의 이것을 의미합니다. 알고리즘 자체는 바이트열에 대해서 XOR 연산등을 적용하는 것들이 대부분 이기 때문에 속도가 빠른편에 속합니다. 트리플 데스 (3DES) 나 AES 가 대표적인 알고리즘 입니다. 


바로 이런식으로 활용됩니다. 평문(Plain Text) 는 아무 변조가 가해지지 않은 글을 의미합니다. 원본이라고 보셔도 무방합니다. 일반적으로 누구나 볼 수 있는 문서 같은 의미로 받아들이면 됩니다. 반면 싸이퍼 텍스트(Cipher Text)는 변조된 문서입니다. 암호문이라고도 볼 수 있습니다. 내용을 알아볼 수가 없는 문서라고 보시면 됩니다.
이런 변경은 양방향이며 인크립션 (Encryption)과 디크립션 (Decryption)시 같은 대칭키 (Symmetric Key)를 이용합니다.

 
비대칭키 알고리즘 (Asymmetric Key) 입니다. 대칭키가 아니라는 말입니다. 이 알고리즘은 두개의 키를 이용합니다. 개인키 (Private Key)공개키 (Public Key) 가 바로 그것입니다. 키를 두개 쓰기 때문에 '대칭키가 아니다' 라는 비대칭키 알고리즘이라고 합니다. 이 알고리즘은 인크립션(Encryption)과 디크립션(Decryption)시 서로 다른 키를 씁니다.  대표적인 알고리즘으로 RSA가 있습니다. 세사람의 이름을 따서 부릅니다. 이 알고리즘은 소수(Prime Number: 1과 그 자신외에는 나눠지는 수가 없는 수)를 이용합니다. 따라서 조금 긴 내용을 인크립션(Encryption) 이나 디크립션 (Decryption)하면 시간이 걸립니다. 이 알고리즘의 근거는 리만 가설에 근거하기 때문에 미드 넘버스(Numbers) 에서는 이 가설을 깨서 모든 보안 상황을 다 제거하는 내용도 등장합니다. (뭐 현실은... -ㅅ- )

 


평문 (Plain Text)를 공개키(Public Key) 를 이용해서 인크립션(Encryption)합니다. 여기서 싸이퍼 텍스트(Cipher Text)라는 말을 안쓰고 Encrypted Text 라는 용어를 쓴것은 이게 딱히 암호화다 아니다 라고 말하기가 애매하기 때문입니다. 바로 뒷 장에 개인키(Private Key)를 이용해서 인크립션(Encryption)하는 내용도 나오기 때문입니다. 그림에서 보듯이 공개키(Public Key)를 이용해서 인크립션(Encryption)을 한다면 다시 디크립션(Decryption)할려면 꼭 쌍이 이루어 지는 개인키(Private Key)를 이용해야 합니다. 

보통 공개키를 가지고 인크립션을 하능 경우는 원하는 상대만 풀어주기를 바라기 때문에 암호화쪽에서 많이 씁니다. 그래서 통칭 공개키 '암호화', 개인키 '복호화' 라는 용어를 쓸때도 있습니다. (절대적인것이 절대 아닙니다) 


이 부분은 개인키(Private Key)를 가지고 인크립션(Encryption) 하는 경우입니다. 역시나 Encrypted Text 를 쌍이 되는 공개키(Public Key)로 풀어줍니다. 개인키 (Private Key)는 개인만 가지고 있고 공개키(Public Key)는 공개적으로 공개가 되어 있다는 가정하에 이러한 케이스는 개인이 보낸 내용을 증명할 때 많이 쓰입니다.  따라서 이러한 경우를 보통 개인키'전자서명' , 공개키 '서명 검증' 이라고 불립니다. 




이런 내용의 기반이 되는 가정이 있습니다. 바로 이름 그대로의 '공개키(Public Key)' 와 '개인키(Private Key)' 입니다. 

개인키 (Private Key) 
오직 개인 혼자만이 가지고 있는 키 입니다. 누구에게도 공유하지 않고 자기 자신만 가지고 있습니다. 

공개키 (Public Key)
공개적으로 공개가 되어 있는 키입니다. 누구나 이 공개키를 얻을 수 있습니다. 


위와 같은 가정하에서 A 라는 사람만 풀어볼 수 있는 내용을 전달하고 싶으면, 만천하에 공개되어 있는 공개키로 인크립션 (Encryption) 한다면 , 그 당사자만 풀어볼 수가 있습니다. (A의 개인키는 A만 가지고 있으니까요) 

또 A 라는 사람이 어떠한 문서를 보냈다는 것을 확인하고 싶다면, A의 개인키로 인크립션 (Enctyption) 한 내용을 추가하면 됩니다. 그러면 공개키로 디크립션(Decryption) 해서 A 가 보냈는지 증명할 수가 있습니다.   

이 두가지가 바로 공개키 암호화 와 전자서명의 원리입니다. 그리고 이런 공개키 암호화와 전자서명을 사용할 수 있게 기반을 마련해둔 것이 PKI (Public Key Infrastructure) 입니다. 


그러면 실제세계에서 어떻게 쓰이는지 알아보기로 합니다. 설명에서 잠깐 언급했듯이 비대칭키 알고리즘은 대칭키 알고리즘에 비해서 많이 느립니다. 이 속도차이 때문에 현실세계에서는 살짝 복잡한 구조를 이용합니다. 


공개키 암호화에 쓰이는 포맷입니다. 물론 이보다 더 자세히 들어가면 더 복잡해지지만, 일단 이정도로 개념을 알고 있어도 충분할 것입니다. 앞에서 설명했듯이 공개키 암호화의 핵심은 받을 당사자만 풀어볼 수 있게 당사자의 공개키로 내용을 인크립션 (Encryption) 하는 것이 목적입니다.

그런데 위의 그림을 보면 임시 대칭키를 생성합니다. 이 이유가 바로 속도 차이입니다. 평문 (Plain Text) 가 만약 크기가 많이 크다면 이를 공개키를 이용해서 Encrypt 하는데 시간이 많이 걸립니다. 그래서 임시 대칭키를 자동으로 생성하고 이 대칭키로 평문 (Plain Text)을 Encrypt 해서 싸이퍼 문(Cipher Text)로 변경합니다. 그리고 그 생성한 대칭키를 메시지를 받을 A의 공개키(Public Key)Encrypt 합니다. (이 Encrypt 된 임시 대칭키를 풀 수 있는 사람은 세상에 A 본인 밖에 없습니다) 그래서 'Cipher Text' 와 A의 공개키로 Encrypt 한 'Encrypted Key' 를 한꺼번에 A에게 보내면 A는 'Encrypted Key'를 자신의 개인키 (Private Key) 로 Decrypt 해서 임시 대칭키를 얻어내고 그 임시 대칭키로 다시 Cipher Text 를 Decrypt 합니다. 그러면 평문(Plain Text)를 얻어낼 수 있는 것이지요. 


전자서명 프로세스의 간단한 설명입니다. 전자서명은 보낸 당사자가 보냈다는 것을 확인하는 절차입니다. 즉 평문 (Plain Text) 자체를 Encrypt 할 필요가 없다는 것입니다. 따라서 평문(Plain Text)를 암호화 해쉬 함수 (Cryptographic Hash Function) 로 축약을 하고 그 축약된 결과를 개인키(Private Key)로 Encrypt 합니다. 이 것을 Signature 라고 편의상 부르기로 합니다. (16 바이트 아니면 20바이트를 Encrypt 하기 때문에 속도가 빠릅니다) 이 Encrypt 한 결과와 평문(Plain Text)을 함께 받을 사람에게 보냅니다. 그러면 메시지를 받는 사람은 보낸 사람의 공개키(Public Key)를 구해서 (공개키 이기 때문에 쉽게 구할 수가 있습니다) Signature 를 Decrypt 합니다. 그러면 축약된 결과가 나오면 같이 들어 있는 평문 (Plain Text) 을 암호화 해쉬 함수로 축약을 하고 그 결과를 앞에서 Signature 를 Decrypt 한 결과와 비교합니다. 같다면 A 가 보낸 문서임을 확신할 수가 있는 것입니다. 말 그대로 서명을 확인 하는 것입니다. 



자 그렇다면 '공인 인증서'란 무엇일까요? 인터넷 뱅킹을 이용한다면 필수적으로 사용할 수밖에 없는 '공인 인증서' 그것에 관해서 이야기 해 보겠습니다. 


PKI 의 기본 가정중에서 개인키(Private Key)는 자신만이 소유하고, 공개키 (Public Key)는 공개해서 다른 사람도 쉽게 구할 수 있다고 했었습니다. 사실 PKI 란 이런 일이 쉽게 가능하도록 인프라를 갖춰두는 것입니다. 


그래서 공인 인증 기관이 등장하는 것입니다. 인증서 비밀번호니, 인증서를 다운 받는다는 둥, 모든 것이 인증서에 집중되어 있는 것처럼 보이지만 사실 가장 중요한 것은 개인키(Private Key)입니다. 보안회사들이나 은행권들은 저 개인키(Private Key)의 존재를 숨기고 싶어서 숨긴것이 아니라, 이 PKI 개념 자체를 설명하기가 부담스러워서 숨긴 것입니다. (사실 은행의 담당자들도 제대로 알지 못할것입니다 ㅎㅎ) 


그래서 공인 인증 기관은 인증서를 발행하는 것이 주요 업무가 아니라 실은 개인키와 공개키 쌍을 만들고 자신이 그 키들을 만들었다고 인증서를 발행하는 것입니다. 

즉 제일 중요한 개인키(Private Key)와 공개키(Public Key) 쌍을 만들고, 그 개인키(Private Key)를 공인 인증 기관에서 적법한 절차를 통해서 만들었다고 인증서를 발행하는 것입니다. (명품백이나 보석류를 사면 주는 인증서나, 강아지 분양 보증서 등등하고 연관 지어보면 명확할 것입니다) 그 개인키(Private Key) 를 보증하기 위해서 그 쌍이 되는 공개키(Public Key)가 바로 인증서에 들어 있습니다. 그리고 그 인증서를 공인 인증 기관이 정식으로 발행했다는 것을 알리기 위해서 '공인 인증 기관의 전자 서명'이 바로 인증서에 들어 있습니다. (그리고 인증서의 대상, 유효기간 등등도 포함되어 있습니다.) 그리고 나서 이 인증서는 신청한 사람한테만 주는 것이 아니라, 공개된 위치에 저장해서 요청하는 사람에게 내려보내 줄 수 있는 시스템이 갖춰져 있습니다. (보통 공인 인증 기관의 LDAP 에 저장됩니다) 

그래서 은행에서 발급받는 '공인 인증서'라는 것은 실은 '개인키 + 인증서' 쌍으로 되어 있습니다. 못 믿겠으면 Windows 사용자 분들은 NPKI 폴더를 뒤져서 자신의 CN 폴더 안에 저장된 파일들을 살펴보세요. 


그러면 공개가 원칙인 인증서에 왠 비밀번호 인가? 라는 생각이 드실만 할것입니다. 이제 지금까지 설명을 통해서 대충 눈치를 채셨겠지만, 바로 개인키 (Private Key)에 대한 비밀번호입니다. 


개인만이 소유해야 하는 개인키(Private Key)가 아무런 보안 장치 없이 공개되어 있으면 곤란하겠지요? 그래서 개인키(Private Key)에는 기본적으로 저장하는 형식이 있습니다. (물론 비밀번호를 필요로 하는 형식입니다) PKCS7 이나 PKCS12 가 바로 그것입니다. 


이상으로 길고 긴 글을 마치게 되었습니다. 이걸 통해서 PKI 를 다 이해할 수 있을 것이라고는 생각하지 않고 만들었습니다. 다만 같이 일하게 되는 후학들에게 PKI 의 기본 개념을 조금이라도 쉽게 설명하고 싶어서 작성한 KeyNote 입니다. 이 블로그에 올리는 이유는 혹시라도 이 내용을 바탕으로 또 다른 사람에게 이 자료를 가지고 설명할 때 설명이 조금이라도 매끄러우면 좋겠다고 사족을 달아둔 것입니다. 올려둔 그림으로 충분하리라 판단하지만 KeyNote 원본을 요청하실 분은 메일 주소를 달아 주시거나, 아니면 제가 전달할 수 있는 다른 방법을 찾아보겠습니다. 



후학들에게 보여주고 싶은 내용입니다. 역시 개발자들이라 그런지 Bottom-up 이라던지 프로토타이핑에 관한 언급이 살짝 살짝 나오는 군요 

+ Recent posts