Kerberos Protocol - Windows

마이크로소프트는 Windows NT에 이어서 Windows 2000을 발표하면서, 기존의 NTLM 인증을 대체하는 Kerberos라는 보안인증 프로토콜을 사용하여 사용자 인증을 처리하고 있다. Kerberos는 NTLM과 방식은 다르지만, 엄격히 따지면 NTLM을 업그레이드시킨 프로토콜이라고 할 수 있다. Unix나 기타 Kerberos와는 호환성은 유지되지만, 몇가지 차이점을 보인다. 그 차이점에 대해서는 다음번에 다루어 보도록 하자. 왜? 모르니까..

먼저 사용자를 인증(Authentication)한다는 것과 권한부여(Authorization)라는 것에 대한 기본개념을 살펴보자. 네트워크 상에서 자원을 가진 수많은 컴퓨터들(Server)과 이들 자원을 이용하는 다수의 사용자(client)가 있기 때문에 허락된 사용자만이 자원에 접근하도록 하는 작업이 반드시 필요하다. 이러한 작업이 안정적으로 동작하기 위해서는 사용자는 자신의 신원확인을 위한 데이터를 인증서버(Domain Controller)에 전송해 주어야 하고, 인증서버는 이 데이터를 받고 자신이 인정해 준 사용자라는 확인절차를 거치고 확인의 증표로서 사용자의 신원정보(SID)를 제공한다. 이 과정이 인증(Authentication)이다.

자원을 가진 서버는 인증받은 사용자의 신원증명을 기준으로 자원들에게 할당된 ACL(Access Control List)와 비교하여 사용자에게 자원에 대한 접근을 제어할 수 있게 된다. 이 과정이 Authorization이다.

 

<그림1> ACL(Access Control List) User Interface

이 과정에서 한가지 짚고 가야 할 것이 있다. 클라이언트 입장에서는 서버에게 사용자정보를 제시해야 하고, 서버 역시 인증받은 사용자를 위해서 인증데이타를 전송해 주어야 할 것이다. 이러한 정보를 전달함에 있어서바로 보안이라는 것이 필요하게 되고, 보안을 제공하는 방법으로 Kerberos라는 프로토콜이 사용되게 되는 것이다. 이제부터 Kerberos프로토콜이 어떻게 클라이언트와 서버간에 안정된 통신이 가능하게 해 주는지 살펴 볼 것이다.

Kerberos라는 용어는 그리스신화에서 지옥을 지키는 머리 셋 달린 개의 이름에서 유래되었다고 한다. 이 개의 역할은 산자와 죽은자를 구분하여 산자는 지옥으로 가지 못하게 막고, 역시 죽은자는 지옥에서 나오지 못하게 막는 일이었다고 하는데, Kerberos라는 프로토콜이 네트워크 상에서 클라이언트,서버,KDC 세 통신주체간에 인증받은 사용자만이 적절한 통신을 할 수 있게 하는 일인 것에 비교하면 참 적절한 이름이 아닌가 생각한다. Kerberos는 Authentication(인증), Identity(무결성),Privacy(데이타보안)을 제공한다. 이러한 서비스들을 제공하기 위해 보안에 있어서 가장 기본적인 키(key)를 이용한 암호화 방법을 이용한다.

흔히들 주변에서 접할 수 있는 PKI, DES, Symmetric Key, Public Key등이 Key를 이용한 암호화 알고리즘에서 나오는 용어이다. Key를 이용한 암호화 알고리즘의 기본개념은 암호를 거는(Encryption) Key를 가지고 암호화를 했다면, 반대로 암호를 푸는(Decryption) Key를 가지고 암호화된 데이터를 꺼낼 수 있다는 것이다. 이 때 사용되는 키 종류에 따라서, 대칭키(Symmetric Key) 혹은 공용키(Public Key, pair Key)등으로 구분할 수 있다. 대칭키는 잠그는 키와 푸는키가 하나임을 의미하는 것이고, 공용키는 잠그는 키와 푸는 키가 별개로써 한쌍을 이루고 있음을 의미한다. Kerberos는 약간의 차이는 있지만, 대칭키 알고리즘이라고 정리를 할 수가 있다. 그렇다면 Kerberos에서 사용하는 암호화 Key는 어떻게 생성되는 것일까?  

대칭키를 사용하는데 있어서 가장 큰 문제점은 통신의 2주체(sender와 receiver)간에 하나의 키를 교환하여 가지고 있어야만 통신이 가능하다는 데 있다. 하나의 서버는 수많은 클라이언트에게 서비스를 제공한다. 이러한 통신마다 별도의 키를 사용해야 한다면 키를 교환하는 작업자체가 보통 일이 아닐 수밖에 없다. 이 키를 교환하는 작업은 어떻게 보호를 할 수가 있겠는가.  효율적인 방법이 있다. 사용자가 로그온을 할 때 사용하는 password를 바로 Kerberos의 키로써 사용하게 되는 것이다. 이 키는 처음 작업에만 사용되며 데이터 통신에는 별도의 키가 사용이 된다. 간단하게 말하자면 사용자는 로그온할 때 password를 입력하고, 로그온을 받아들이는 서버 역시 사용자의 패스워드를 알고 있기 때문에 그 패스워드를 암호화 Key로 사용을 하게 된다면 이미 2주체간에는 대칭키를 가지고 있기 때문에 암호화된 인증을 사용할 수가 있게 되는 것이다.

서버에서는 로그온을 처리하는 서비스만 있는 것이 아니다. 수많은 서버서비스를 가지고 있기 때문에 단순히 패스워드를 이용한 키방식만을 사용한다면 모든 서비스마다 동일한 키를 사용하는 결과를 가지게 될 것이다. 그렇다면 그때마다 서로 다른 키를 사용해야 한다는 얘기인데, 클라이언트 입장에서는 각종 서비스들과 통신을 하기 위해서 그때마다 서로 다른 키를 유지하여야 할 것이기 때문에 이것 역시 번거로운 일일 수밖에 없다. 어떻게 하면 좋을 것인가? 내가 하기 싫다면 남을 시키면 된다. 물론 실제로는 쉬운 일이 아니겠지만. 이것을 해결할 수 있는 방법으로 Kerberos는 "티켓(ticket)"이라는 것을 사용하여 사용자의 신원을 증명하는 방법을 사용하고 있다. Kerberos를 이루고 있는 구성요소 중에 KDC(Key distribution Center)는 티켓을 발행하는 TGS(Ticket Granting Service)를 맡고 있다. 결국 하나의 KDC라는 구성요소가 네트워크 상의 전반적인 키를 발행하는 서비스를 하고 있고, 그것에 접근하는 최초의 통신에만 사용자의 패스워드가 사용이 되고 있는 것이다.

이제부터 Windows2000의 Kerberos가 어떻게 동작하고 있는지를 보도록 하자. 아래의 그림을 예로 들어서 설명한다. Windows2000 Kerberos의 특징이라면 실제 인증작업을 하기 위해서 Pre-Authentication 절차가 있음을 상기하자. 특정service를 하고 있는 서버에 승인을 얻기 위해서는 그 서비스에 접근할 수 있는 ticket을 제시해야 하는데, ticket을 얻기 위해서는 TGT(Ticket Granting Ticket)를 먼저 얻어야만 한다. TGT는 TGS에 ticket 발행요청을 하기 위한 ticket이다. 이 TGT를 얻는 과정을 Pre-Authentication 절차라고 한다.

<그림2> Kerberos Process sample / 클라이언트의 파일서버 접근인증

<그림2>에서 사용자는 파일서버의 자원에 접근하고자 한다. 이 과정에서 클라이언트 인증을 위하여 발생되는 과정을 도식화 해 보았다. ①과 ②가 Pre-Authentication과정이다. ③과 ④는 파일서버의 서버서비스에 접근하기 위한 티켓을 얻기 위한 과정이고, ⑤와 ⑥이 ④에서 얻은 티켓을 가지고 파일서버에 접근하고, 서버로부터 권한부여(Authorization)를 받아서 자원에 접근하게 되는 예제이다. 이러한 6가지 절차에 대해서 구체적으로 진행과정을 살펴보도록 하자. 이 과정을 통해서 Kerberos의 동작원리를 알 수가 있게 될 것이다. 다소 복잡하고 어려운 개념이 될 수도 있지만, 차근차근 접근하면 이해할 수 있으리라 생각된다.

사용자가 Windows2000환경에서 도메인으로 로그온을 할 때 최초로 Kerberos를 이용한 티켓이 필요하게 된다. 도메인 컨트롤러에 접근해야 로그온을 할 수 있을 것이고, 그러기 위해서는 도메인컨트롤러의 인증서비스에 접근할 수 있는 티켓을 발급받아야 할 것이기 때문이다. 이 티켓을 발급받기 위한 과정이 최초의 과정이다.사용자 입장에서는 아주 단순한 작업을 하면 그뿐이다. 로그온대화상자가 뜨면 사용자계정, 패스워드, 도메인지정 등의 내용만 입력하면 나머지는 Windows 2000 시스템이 처리하니 말이다. 쉽게 생각하면 사용자 계정과 패스워드 정보가 네트워크 상에 전송이 되면 되겠구나 라고 생각할 수도 있겠지만, 그렇게 패스워드를 네트워크에 패킷으로 발송한다면 누군가 도청의 위험이 있을 수밖에 없다.

패스워드 하니까 생각나는 우화(?)가 있다. 동생이 즐겨찾는 성인사이트에 접근하기 위해서 동생이 패스워드를 입력할 때 몰래 훔쳐보고, 나중에 그 사이트에 접근해서 asterisk(*)만 6개를 입력하고는 인터넷이 문제있다며 죄없는 모ADSL통신사 도우미 언니들만 붙잡고 시비를 걸었다는 어느 누나의 비애.. 갈길이 먼데 이야기가 삼천포로 빠지고 있다.

결론은 이러한 패스워드를 제시해서 합법적인 사용자라는 사실을 서버에 제공하고 인증을 얻어내야 할 것인데 이 과정을 패스워드를 직접 전송하지 않고도 사용자를 확인할 수 있는 방법으로써 Kerberos는 잘 맞춰진 톱니바퀴처럼 한치의 어긋남이 없이 처리해 주고 있다는 것이다. 기본원칙은 어긋날 수 없다. 두 시스템간의 데이타는 오직 두 시스템에서만 이해할 수 있어야 한다는 것이다.중간에 누군가가 데이터를 훔쳤다고 하더라도 승인받지 못한 제 3자는 그 데이터를 읽을 수 있어서는 안된다.계속 이야기가 되는 도중에 이 기본원칙은 상기할 수 있길 바란다.

<그림3> Authentication Service Exchange

최초의 통신부터 살펴보자. Pre-Authentication과정을 그림으로 표현한 것이다. 사용자가 처음 로그온을 할 때, 사용자 시스템의 Kerberos는 KDC (Key Distribution Center)에 첫 번째 메시지를 보내게 된다. 그 메시지에는 username, pre-authentication data, TGT요청 등이 담겨 있다. 이 메시지를받은 KDC는 적절한 응답을 해야 할 것이다. KDC는 이 메시지를 기반으로 로그온을 요청하는 사용자가 정상적인 사용자라는 사실을 판단할 수 있어야 하는데, 그것은 단순히 사용자가 제시한 username만 가지고는 판단 할 수 없는 일이다. 그렇기 때문에 패스워드가 필요한 것이지만, 이 패스워드는 네트워크 상에서 적법한 사용자라는 것을 판단하는 유일한 기준이라고 할 수 있기 때문에 암호화되지 않은 상태로 네트워크에서 전송되는 일이 있어서는 안 된다. 그래서 패스워드를 암호화해서 전송하는 방법을 생각할 수 있지만, 패스워드를 암호화하자면 이 암호화 작업에 필요한 Key를 만들어야 하는 작업이 선행되어야 할 것이기 때문에 그다지 바람직하지 않은 방법이 될 것이다. 그래서 선택한 방법이 패스워드를 Key로써 암호화작업을 진행하는 방법이 나오게 된다. 기본개념은 그렇지만,정확히 말하자면 패스워드를 Key로써 사용하는 것이 아닌, 패스워드를 해시(hash)라는 함수를 이용해서 산출된 값(다이제스트)을 Key로써 사용하는 것이다. Windows2000은 기본적으로 Message Digest 5 (MD5)알고리즘을 사용하며, RC4로써 암호화를 제공하고 있다.

정리하면 클라이언트의 Kerberos는 pre-authentication data (time stamp)를 패스워드의 hash(그림3.에서 "Kc"에 해당함)로써 암호화한 데이터를 전송하게 되는 것이다.

당연히 KDC에서는 사용자의 패스워드의 hash값을 저장해 두고 있기 때문에 KDC에서 가지고 있던 사용자의 패스워드에 해당하는 hash로써 사용자의 pre-authentication data가 풀린다면 정상적인 사용자의 로그온이라는 판단을 할 수가 있게 되는 것이다. 이렇듯 사용자와 패스워드가 확인이 된다면 KDC는 사용자가 TGS(Ticket Granting Service)에 접근하여 티켓발행 요청을 할 수 있도록 TGT(Ticket Granting Ticket)을 발행한다. 이 때 TGT를 다른 사용자는 열어볼 수 없도록 KDC자신의 비밀키(long-term key)로써 암호화를 하게 된다. 그리고, 다음에 Client가 Server의 TGS와 통신할 때 사용을 하게 될 둘만의 session Key(그림3.에서 'Kc,k'에 해당된다)를 발행하고, 이 키 역시 사용자의 비밀키(Kc)로써 암호화하여 전송하게 되는 것이다.

TGT는 분명히 클라이언트가 제시해야 할 티켓이지만, 클라이언트가 직접 확인할 필요는 없는 값이다. 왜냐면 이 티켓의 쓰임새는 서버 입장에서 이 티켓을 가지고 접근하는 클라이언트만 받아들이면 되는 것이기 때문에 결국 서버에서 확인해야 할 값인 것이다. 자신이 발행하고 자신이 확인하는 셈이 된다. 우리가 극장에 들어갈 때 사용하는 혹은 차를 탈 때 사용하는 티켓과 개념이 같다고 볼 수 있다. 사실 KDC가 제공하는 TGT는 클라이언트와 통신에서 사용할 Session key와 같은 값이다. 이 값이 일치하도록 만든 것은 KDC의 부담을 덜어 줄 수 있는 좋은 해결책이다.

클라이언트가 세션키를 가지고 자신의 서비스에 요청을 보낼 때, TGT라는 티켓을 제시를 할 것이고, 그 TGT는 KDC자신의 비밀키로 암호화 된 티켓이기 때문에 오직 자신만이 확인할 수 있게 된다. 결국 KDC입장에서는 수많은 사용자들에게 발행한 티켓을 일일이 기억하고 있을 필요는 없다는 얘기가 된다. 개인적으로는 입이 떡 벌어질 만큼 잘 만들어 놓은 알고리즘이 아닌가 싶다.

<그림4> Ticket Granting Service Exchange & Client Server Exchange

위의 첫 번째 과정을 이해한다면 다음과정은 크게 차이가 없다. 첫 번째 과정을 통해서 사용자는 로그인을 하게 된 것이고, 자원을 가지고 있는 서버에 접근하기 위하여 먼저 자원을 가진 서버에 접근할 수 있는 티켓을 얻기 위한 작업을 진행해야 한다. TGT를 받았기 때문에 이 TGT를 가지고, 자원을 가진 서버에 접근할 수 있는티켓을 발급받기 위하여 TGS에 서비스 티켓 발급 요청을 보낼 수가 있다. 이 메시지에는 TGT, TGS와의 세션키로 암호화된 Authenticator (user,time), 티켓발급이 필요한 서버의 서비스(application) 등의 요청이 담겨 있다.  이 요청을 받은 KDC의 TGS는 TGT를 자신의 비밀키(Kk)로 해독하고 (TGT와 session key가 같다는 걸 상기하자), session key로써 암호화된 Authenticator를 해독하여 사용자의 신원과 타임스탬프를 확인한다.

사용자 인증이 되었다면, 해당 서비스와 통신할 수 있도록 티켓을 발행해 주어야 한다. Client가 Server의 서비스와 통신할 때 사용을 하게 될 둘만의 session Key(그림4.에서 'Kc,s'에 해당된다)를 발행하고, 이 키 역시 사용자와의 세션키(Kc,k)로써 암호화하여 전송하게 되는 것이다. 더불어 서비스에 접근할 수 있는 티켓을 발행하는데 이 티켓은 Server의 비밀키(Ks)를 가지고 암호화를 하여 전송한다. 이렇듯 비밀키를 통해서 전송함으로써 Privacy를 유지해 줄 수 있게 된다. 클라이언트는 이 과정을 통해서 얻은 서버와의 세션키를 이용해서 서버에 서비스를 요청할 수 있다. 예를 들어서 파일서버라면 파일서비스에 요청을 하게 되는 것이고, 서버는 사용자가 유용한 티켓을 가지고 접근을 했기 때문에 이 티켓을 가지고 있는 사용자를 믿고 서비스를 제공할 수가 있게 되는 것이다. 이것이 바로 인증(Authentication)이다.

Kerberos는 서비스 티켓을 발행해서 사용자의 신원을 증명하는 것이 목표이다. 그 다음과정에 해당하는 Authorization(권한부여)은 Kerberos의 몫이 아니다. 자원을 가진 서버의 Security Decriptor라는 프로세스는사용자가 제공한 티켓의 SID를 기준으로 자원이 가지고 있는 ACL (Access Control List)와 비교를 하여 사용자의 접근여부를 결정하게 된다.

Kerberos는 Windows2000에서 사용하는 "사용자와 서비스(Security Principal)를 인증하기 위한 "보안인증 프로토콜" 이다.