Public Key Infrastructure?
보통 줄여서 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 프로토콜이 가장 널리 사용되고 있다.
Public Key 암호화
Public Key를 이용한 암호화에 대해서 그림을 보면서 살펴보도록 하자. 앨리스가 밥에게 데이터를 전송하려고 한다. 중요한 데이터인데 이브의 도청이 염려스럽다. 안전하게 보내기 위해서 데이터를 암호화하기로 결정했는데 암호화키가 필요하다. 암호화키로써 데이터를 암호화해서 보내면 데이터를 받은 밥은 복호화를 해야 한다. 역시 복호화키가 필요할 것이다.
<공캐키를 이용한 암호화>
먼저 앨리스는 밥의 공용키를 구하는 것이 선행되어야 한다. 그 다음에 자신이 보내고자 하는 데이터를 밥의 공용키로서 암호화하여 전송해 준다. 밥은 암호화된 메시지를 받은 다음 앨리스가 암호화하는데 사용한 공용키와 한쌍으로 생성해 두었던 개인키를 이용해서 복호화하게 된다. 결국 데이터를 꺼낼 수가 있게 되었다.
한가지는 정리하고 가자. PKI를 이용하고자 할 때 상대방에게 안전하게 암호화된 데이터를 전송하고 싶다면 상대방의 공용키를 얻는 것이 첫번째 할일이다. 데이터에는 여러가지가 있을 것이다. 인터넷 쇼핑몰이 운영되고 있는 웹서버로 신용카드와 유효기간 등의 정보를 보낼 수도 있을 것이고, 회사의 중요데이터를 담은 전자메일 메시지일 수도 있다. 웹서버와의 안전한 통신을 위해서는 웹서버로부터, 전자메일을 보내고자 한다면 상대방으로부터, 먼저 할 일은 공용키를 얻어내는 과정이 필요하다는 것이다. 그 공용키로써 암호화를 했을 때 해독할 수 있는 사람은 오직 공용키와 쌍이 되는 개인키를 소유한 사람이다.
Private Key 암호화
이번엔 다른 관점이다. 개인키를 이용한 암호화가 어떠한 용도로 사용되는지에 대해 정리해 본다. 이번엔 밥의 입장에서 고려를 해 보자. 밥이 앨리스라고 주장하는 사람으로부터 메시지를 받았다고 가정한다. 밥은 자신이 받은 메시지가 정말 앨리스가 보낸 것인지를 확인하고 싶어한다.
현실세계에서 요즘 거의 종이에 펜을 이용해서 글씨를 쓰고 편지를 보내는 일이 드문일이 되었다. 우리는 무엇인가 문서를 만들고 나서 자신이 확인했다는 표시로 ‘자필서명’이라는 것을 하곤 한다. 그러면 상대방은 그 서명을 통해서 받은 편지를 신뢰한다. 디지털 세상에서도 이와 동일한 알고리즘의 작업이 행해지고 있다.
앨리스는 밥에게 보낼 메시지를 만든 다음 자신이 보냈다는 것을 증명하기 위해 “서명”을 한다. 바로 전자서명이 되는 것이다. 서명이 유효하기 위해서는 지켜져야 할 조건이 있다. 당사자가 아닌 다른 사람은 동일한 서명을 할 수 있어서는 안된다는 것이다. 그렇다면 앨리스가 밥에게 보낼 메시지에 서명을 할때는 다른 사람은 가지고 있지 못한 자신만이 가진 유일한 증표를 사용해야 할 것이다. 그것은 바로 자신의 Private Key(개인키)를 이용하는 것이다. 앞에서 공용키는 누구에게나 공개가 되지만 개인키는 오직 키쌍을 생성한 주체만이 가지고 있다고 한 것을 기억하면 될 것이다. 과정을 아래 그림을 통해서 설명한다.
<개인키를 이용한 암호화>
그림에서 앨리스는 밥에게 데이터를 전송하고자 한다. 밥에게 자신이 보내는 메시지라는 것을 신뢰할 수 있도록 하기 위해서 자신만이 가지고 있는 개인키를 이용하여 메시지를 암호화한다. 이것을 가리켜서 “Digital Signature (전자서명)”이라고 부른다. 결국 앨리스는 자신이 서명한 메시지를 네트워크를 통해서 밥에게 보낸다. 이 메시지를 받은 밥은 앨리스의 공용키를 이용해서 복호화를 하고, 앨리스의 공용키로써 복호화가 이루어지면 자신이 받은 메시지가 앨리스가 보낸 것이 맞다고 판단을 한다. 앨리스를 가장한 제3자가 보낸 메시지라면 앨리스의 공용키로 해독이 되지 않을 것이다.
만일 이 메시지를 도중에 이브가 가로챘다면? 이브는 당연히 이 메시지를 읽을 수가 있다. 앨리스의 공용키만 있다면 얼마든지 해독이 가능할 것이기 때문이다. 기밀성은 제공되지 않는다는 것을 의미한다.
이렇듯 개인키를 이용해서 암호화하는 것(전자서명)은 제3자가 데이터를 열지 못하게 하기 위한 방법은 아니다. 다만 상대방에게 자신을 가장한 제3자가 아닌 진짜 자신이 보낸 메시지라는 것을 알려주기 위한 방법일 뿐이다.
공개키와 개인키의 사용용도
(1) 공용키: 데이터를 암호화하여 기밀성을 유지한다. 또한 상대방이 개인키로 암호화한 메시지를 해독하여 상대방을 확인할 용도로 사용한다.
(2) 개인키: 상대방이 자신의 공용키를 이용해 암호화해서 보낸 메시지를 해독하는데 사용한다. 또한 자신의 메시지에 전자서명을 만드는데 사용한다.
Hash 함수와 Digest
개인키를 이용한 전자서명과 더불어 추가로 고려해야 하는 내용이 있다. 밥이 앨리스로부터 데이터를 받았을 때 밥은 이 데이터가 앨리스가 보낸 원본데이터 그대로인지, 즉 중간에서 변조가 되었다거나 바이러스코드가 추가되었다거나 하는 등의 훼손된 것은 아닌지를 알고 싶다는 것이다. 결국 무결성(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개의 다이제스트가 정확히 일치한다는 것이 밝혀지면 다이제스트를 생성한 원본이 동일하는 것을 증명해 주는 것이다. 밥이 받은 데이터가 도중에 훼손되었다면 밥이 직접 생성한 다이제스트는 앨리스가 만들어서 보낸 다이제스트와 ‘불일치’라는 결과를 보일 것이다.
이러한 방법을 이용해서 데이터 무결성을 보장해 줄 수 있다.그림의 내용을 다시 정리해 보았다.
① Alice는 자신이 만든 데이터를 Hash한 다음 자신의 개인키로 서명한다.
② 전자서명된 원본 데이터를 전송한다.
③ Bob은 Alice의 공용키를 이용하여 전자서명을 해독한후 Alice의 신원을 확인하고 Digest를 꺼낸다.
④ 받은 데이터를 동일한 함수로 Hash하여 Digest를 생성한다.
⑤ 이 두 Digest를 비교하여 정확히 일치하면 원본의 훼손이 없었다는 것(무결성)이 보장된다. Digest가 다른 결과가 나왔다면 원본이 훼손되었다는 것을 의미한다.
출처: 정보|기술|커뮤니케이션|사람들 Information Communication Technology & People
'IT 자격증 > MCTS, MCSE, MCITP' 카테고리의 다른 글
Windows Server 2008 바이블 소개합니다. (0) | 2009.12.07 |
---|---|
70-652 덤프 문제 (0) | 2009.12.05 |
70-403 덤프 문제 (0) | 2009.11.29 |
70-680 덤프 문제 (0) | 2009.09.25 |
대칭키(Symmetric Key) (0) | 2009.08.29 |