커버로스 프로토콜(Kerberos Protocol)이란?

커버로스 프로토콜이란?

• 커버로스는 티켓(ticket) 기반의 컴퓨터 네트워크 인증 프로토콜이다.
• 보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 요청을 받는 서버가 서로의 신뢰성을 확보하기위해 사용된다.

 

티켓이 뭔가요? 왜 쓰는거죠?

• 커버로스에서 사용하는 티켓은 유저 아이디를 안전하게 전달하는 데 사용되는 정보 패킷이다.
• 티켓에 포함하는 대표적인 정보들은 다음과 같다.

1. 유저 아이디
2. 유저 호스트의 IP 주소
3. 타임 스탬프(time stamp, 시간 기록)
4. 티켓 수명을 정의하는 값
5. 세션 키

• 이러한 정보들을 담고 있는 티켓은 티켓을 발급하는 서버의 비밀 키(secret key)로 암호화(encrypt)된다.

 

커버로스 프로토콜의 동작 과정

[그림] 커버로스 프로토콜의 동작 과정

• AS(Authentication Server)는 요청을 보내는 유저의 아이디와 패스워드를 인증하고, TGS(Ticket Granting Service)와 통신하기 위한 티켓을 유저에게 발급해주는 서버이다.
• TGS는 SS(Service Server, =Resource Server)와 통신하기 위한 티켓을 유저에게 발급해주는 서비스이다.
• SS는 유저가 최종적으로 통신하고자 하는 목적지 서버이다.
• AS와 TGS, SS를 순차적으로 거치는 과정을 통해 유저와 서버가 서로를 신뢰할 수 있게 된다.
• 세션 키는 비밀 키와 다른 개념이다.
• 세션 키는 유저와 서비스 간의 통신에 필요한 키이다.
• 커버로스에서 유저는 TGS, SS와 통신을 하게 되므로, 두 개의 세션 키를 필요로 한다.
• 비밀 키는 서비스가 유저에게 만들어서 보내줄 티켓을 암호화하거나, 서비스가 유저로부터 전달받은 티켓의 복호화를 위해 가지고 있는 키이다.
• 티켓의 복호화를 위해 TGS는 TGS 비밀 키를 가지고 있고, SS는 SS 비밀 키를 가지고 있다.
• 티켓의 암호화를 위해 AS는 TGS 비밀 키를 가지고 있고, TGS는 SS 비밀 키를 가지고 있다.
• 또한 세션 키는 티켓 안에 들어갈 데이터 중 하나이기 때문에 AS는 TGS 세션 키를 가지고 있고, TGS는 SS 세션 키를 가지고 있다.

 

커버로스 프로토콜의 동작 과정 상세

1. 유저는 자신의 아이디를 AS에 보내서 TGT을 요청한다.
• 아이디는 일반 텍스트(plaintext)로 전송된다.
• 이는 아이디와 패스워드를 둘 다 알고 있지 않은 경우 아이디가 노출되어도 보안상 문제가 없기 때문이다.
2. AS는 전송받은 아이디가 AS의 데이터베이스에 있는지 확인하고, 있다면 두 가지 정보를 생성해 유저에게 보내준다.
• 두 가지 정보란 다음과 같다.
• 데이터베이스 안에 있는 요청을 보낸 유저의 패스워드를 통해 만든 키로 암호화한 TGS 세션 키
• TGT(Ticket Granting Ticket, 티켓을 받기 위한 티켓)
• TGT는 앞서 티켓 설명에서 말한 유저 아이디와 TGS 세션 키 등 여러 정보들을 TGS 비밀 키로 암호화한 티켓이다.
• AS는 TGS의 비밀 키를 가지고 있기 때문에 TGT를 만드는 것이 가능하다.
3. 유저는 AS로부터 받은 두 가지 정보를 통해 TGS 세션 키를 얻고, Authenticator를 만들어 TGT와 함께 TGS에 보내준다.
• AS는 TGS 세션 키를 유저의 패스워드를 통해 암호화해서 보냈다고 앞서 말했다.
• 유저는 당연히 자신의 패스워드를 알고 있으므로, AS로부터 받은 정보를 복호화하여 TGS 세션 키를 얻을 수 있다.
• TGS 세션 키를 얻어 냈으므로, 이제 유저는 TGS에게 보낼 Authenticator를 만들 수 있다.
• Authenticator는 유저 아이디와 타임 스탬프를 TGS 세션 키로 암호화 한 데이터이다.
• TGT는 별다른 처리과정을 거치지 않고, Authenticator와 함께 TGS에 보내진다.
4. TGS는 유저로부터 받은 TGT와 Authenticator를 복호화하여 유저 아이디가 일치하는지 확인하고, 일치한다면 유저에게 티켓과 SS 세션 키를 발급해준다.
• TGT와 Authenticator를 복호화하는 과정에서, TGT부터 복호화가 진행된다.
• TGS는 TGS 비밀 키를 통해 TGT를 복호화할 수 있는데, TGT를 먼저 복호화해야만 Authenticator를 복호화할 수 있는 키인 TGS 세션 키를 얻을 수 있기 때문이다.
• TGT와 Authenticator 둘 다 유저 아이디를 포함하고 있으므로, 두 개의 유저 아이디가 같은지를 확인하면 유저가 정상적으로 AS를 거쳐 TGS에 요청이 보냈다는 것을 입증할 수 있다.
• TGS는 유저에게 SS와 통신할 권한을 주기 위해 SS 세션 키를 발급하고, 티켓 또한 발급해줘야 한다.
• SS 세션 키는 TGS 세션 키로 암호화한다.
• 티켓은 유저 아이디와 SS 세션 키 등을 SS 비밀 키로 암호화하여 만든다.
5. 유저는 TGS로부터 암호화된 SS 세션 키와 티켓을 받고, 암호화된 SS 세션 키를 복호화하여 또 다른 Authenticator를 만들어 티켓과 함께 SS에게 보내준다.
• TGS로부터 받은 SS 세션 키는 TGS 세션 키로 암호화되어있으므로, 유저는 이미 TGS 세션 키를 가지고 있기 때문에 SS 세션 키를 쉽게 얻을 수 있다.
• 유저가 SS에게 보내야 하는 Authenticator는 이전 단계에서 TGS에 만들어 보낸 Authenticator와 거의 비슷하다.
• 한 가지 다른 점은 Authenticator를 SS 세션 키로 암호화한다는 것이다.
• Authenticator는 유저 아이디와 함께 타임 스탬프를 포함하고 있는데, 이 중 타임 스탬프를 SS로부터 답장받는 타임 스탬프와 비교하여 SS의 신뢰성을 확인받는다.
• 이렇게 만든 Authenticator를 TGS로부터 받은 티켓과 함께 SS에 보내준다.
6. SS는 유저로부터 받은 Authenticator와 티켓을 복호화하여 유저 아이디가 일치하는지 확인한 후, 일치한다면 Authenticator에 들어 있던 타임 스탬프를 SS 세션 키로 암호화하여 유저에게 보내준다.
• SS는 Authenticator보다 티켓을 먼저 복호화해야 한다.
• 티켓을 SS 비밀 키로 복호화하면 SS 세션 키를 얻을 수 있다.
• Authenticator는 SS 세션 키를 통해 암호화되어 있으므로, 얻어낸 SS 세션 키를 통해 Authenticator를 복호화하고 Authenticator와 티켓 각각에 들어있던 유저 아이디를 비교해준다.
• 유저 아이디가 일치한다면 유저가 정상적으로 AS와 TGS를 거쳐 왔음을 신뢰할 수 있다는 의미이다.
• 그 후 유저가 보낸 Authenticator 안의 타임 스탬프를 SS 세션 키로 암호화해서 유저에게 답신해준다.
7. 유저는 답신받은 데이터를 SS 세션 키로 복호화하여 앞서 SS에게 보낸 타임 스탬프와 일치하는지의 여부를 체크한다.
• 두 개의 타임스탬프가 서로 일치한다면, SS를 신뢰할 수 있다는 의미이다.
• SS는 최종적으로 유저가 요청을 보내려는 서버이므로, 이 단계까지 성공적으로 수행됐다면 유저와 서버는 서로를 신뢰하는 통신이 가능해진다.

 

커버로스 프로토콜의 단점

• 커버로스 서버는 하나이기 때문에 서버가 다운될 경우, 새로운 유저는 로그인할 수가 없다. 따라서 여러 개의 서버를 운용하는 등 서버가 작동하지 않을 때를 대비할 수 있는 메커니즘을 구현해야 한다.
• 요청 시간에 대한 요구가 엄격하다(통상적으로 5분). 만약 요청을 주고받는 호스트들 간에 시간 동기화가 되어있지 않을 경우 통신이 불가능하다.

 

참고한 자료

https://en.wikipedia.org/wiki/Kerberos_(protocol)

https://docs.oracle.com/cd/E26925_01/html/E25888/refer-11.html

https://www.letmecompile.com/kerberos-protocol/