[Network Security] 커버로스(Kerberos) 동작 원리 이해하기

# 커버로스(Kerberos) 란?

커버로스는 티켓(ticket) 기반의 컴퓨터 네트워크 인증 프로토콜이다.

보안이 보장되지 않은 네트워크 환경에서 유저와 서버가 서로의 신뢰성 확인을 위해 사용한다.
유저와 서버간의 양방향 인증을 제공하고 커버로스 프로토콜의 메시지는 도청과 재전송 공격으로부터 보호된다. 
커버로스는 대칭 키(session key)를 주로 사용하며 TTP(Trusted third party, 신뢰할 수 있는 제 3자)를 요구한다. 

특정 인증 구간에서 비대칭 키를 이용함으로써 선택적으로 공개 키 암호 방식을 사용할 수 있다.
커버로스는 기본적으로 88번 포트를 사용한다.

# 커버로스 도입을 고려할 만한 상황

1.  서비스 서버가 점점 많아지고, 사용자의 수도 많아져서 사용자와 권한에 대한 관리 비용이 높아지는 경우
2. 서버 별로 접근 가능한 사용자를 관리해야 할 때
3. 서버가 추가될 때마다 혹은 유저가 추가/삭제 될 때마다 유저의 등록을 관리해야 하는 경우

EX) 서버가 적고, 각 서버를 사용하는 개발자가 몇 없다고 가정해보자.
이 경우에는 수동으로 A 서버에는 개발자 1, 2에게 권한을 주고, B 서버에는 개발자 2, 3에게 권할을 줄 수 있다. 

하지만 서버의 수가 많아지고 유저도 많아진다면 이들을 관리하는 비용은 기하급수적으로 늘어날 것이다.

 

이런 경우에 클라이언트/서버 외에 제 3의 인증 서버(AS)를 도입하고 - 이와 연동된 티켓 부여 서버(TGS)를 통해 티켓을 발급하여 유효한 티켓이 있는 유저만 - 서비스 서버(SS)에 접속할 수 있도록 제어하는 커버로스 프로토콜을 도입하여 편리하게 관리할 수 있다.

 

실제로 회사에서 사내망을 통해 서비스를 이용할 때 커버로스 인증방식을 사용하는 경우가 많다.
지금 개념을 익혀두면 나중에 사내 클라우드 API나 서비스를 이용할 때 커버로스 방식으로 인증한다고 하면 '아 커버로스 쓰는구나' 하면서 쉽게 이해할 수 있을 것이다!

 

# 커버로스 동작 과정

용어 정리

Ticket

티켓 : 유저 아이디 + 유저 호스트의 IP 주소 + 타임 스탬프 + 티켓 수명 + 세션키

티켓은 항상 비밀키로 암호화된다.

 

AS (Authentication Server)

인증 서버 : 요청을 보내는 유저의 아이디와 패스워드를 인증한다. 유저의 정보를 가지고 있다.

 

TGT (Ticket Granting Ticket)

발행한 티켓을 인증하는 티켓

 

TGS (Ticket Granting Server)

유저의 티켓을 발급해주는 서버

 

SS (Service Server)

유저가 최종적으로 통신하고자 하는 서버

 

Session Key

세션키 : 메시지 전달을 위한 대칭키라고도 할 수 있으며, 세션키는 항상 암호화되어 전달된다.

 

Secret Key

비밀키 : 비대칭키이며 외부에 노출되어서는 안된다.

티켓을 암호화하거나, 유저로부터 전달받은 티켓의 복호화를 위해 사용된다.

 

Authenticator

(유저 아이디 + 타임스탬프) 를 세션키로 암호화한 것.

TGS의 세션키와 SS의 세션키로 암호화하여 사용된다.

아이디를 비교해서 정상적으로 진행중인 요청인지 확인하는데 사용하고,

타임 스탬프를 비교해서 신뢰할 수 있는 서버인지 확인한다.

 

 

세부 동작

1. 사용자는 자신의 아이디를 AS에 보내서 TGT를 요청한다.
   • send data : 아이디(암호화 되지 않은 평문)
   • 아이디와 패스워드를 둘 다 알고 있지 않은 경우 아이디가 노출되어도 보안상 문제가 없기 때문이다.
     
     
2. AS는 전달받은 아이디가 AS의 DB에 있는지 확인하고, 있다면 TGT와 TGS 세션키를 생성해서 사용자에게 전달한다.
   • 전달받은 아이디가 데이터베이스에 있는지 확인한다.
   • 아이디를 통해서 패스워드를 확인한다.(암호화에 사용될 예정)
   • 유저 아이디 + 유저 호스트의 IP 주소 + 타임 스탬프 + 티켓 수명 + TGS 세션키 가 종합된 TGT를 만든다.
   • TGT는 TGS의 비밀키로 암호화 된다.
   • TGS의 세션키는 유저의 패스워드를 기반으로 암호화된다.
   • 암호화된 TGT와 암호화된 TGS 세션키를 반환한다.
   • AS는 TGS의 비밀키를 공유한다.
     AS와 TGS는 서로 신뢰하는 서버여야한다.
     
     
3. 유저는 AS로부터 받은 암호화된 TGT와 암호화된 TGS 세션키를 통해 TGS 세션키를 얻고, Authenticator를 만들어서 TGT(그대로)와 함께 TGS로 보낸다.
   • 유저는 자신의 비밀번호로 암호화된 TGS 세션키를 복호화해서 TGS 세션키를 얻어낸다.
   • 유저의 아이디와 타임 스탬프를 TGS 세션키로 암호화해서 Authenticator를 생성한다.
   • TGT는 별도의 처리를 하지 않는다.
   • 유저는 Authenticator와 TGT를 TGS로 전송한다.
     
     
4. TGS는 유저로부터 받은 Authenticator와 TGT를 복호화하여 유저 아이디가 일치하는지 확인하고, 일치한다면 유저에게 티켓과 SS 세션키를 발급해준다.
   • TGS는 TGS 비밀키를 가지고 있다.
   • TGS 비밀키를 사용해서 TGT를 복호화한다.
   • 복호화된 TGT에서 TGS 세션키와 유저 아이디를 얻는다.
   • TGS 세션키를 사용해서 Authenticator를 복호화한다.
   • Authenticator에서 유저 아이디를 얻는다.
   • TGT에서 얻어낸 유저 아이디와 Authenticator에서 얻어낸 유저 아이디를 비교해서 같은지를 확인한다.
     만약 같다면 유저가 정상적으로 AS를 거쳐서 TGS에 요청을 보냈다는 것이 증명된다.
   • TGS는 SS와 통신할 권한을 주기 위해 SS 세션키와 티켓을 생성한다.
   • SS 세션키는 TGS 세션키로 암호화된다.
   • 티켓은 유저 아이디 + 유저 호스트의 IP 주소 + 타임 스탬프 + 티켓 수명 + SS 세션키로 이루어진다.
   • 티켓은 SS 비밀키로 암호화된다.
     
     
   • 2번 과정과 마찬가지로 TGS와 SS는 서로 신뢰하는 사이이며 비밀키를 공유한다.
     
     
5. 유저는 TGS로부터 SS 세션키와 티켓을 받고 또 다른 Authenticator를 만들어 티켓(그대로)과 함께 SS에게 보내준다.
   • 유저는 3번 과정을 통해서 TGS 세션키를 알고있다.
   • 그래서 암호화된 SS 세션키를 TGS 세션키로 쉽게 복호화 할 수 있어서 SS 세션키를 쉽게 알아낼 수 있다.
   • 유저의 아이디와 타임 스탬프를 SS 세션키로 암호화해서 Authenticator를 생성한다.
   • 티켓은 별도의 처리를 하지 않는다.
   • 유저는 Authenticator와 티켓을 SS로 전송한다.
     
     
6. SS는 유저로부터 받은 Authenticator와 티켓을 복호화하여 유저 아이디가 일치하는지 확인하고, 일치한다면 Authenticator에 들어있던 타임 스탬프를 SS 세션키로 암호화하여 유저에게 보내준다.
   • 4번 과정과 비슷하게, SS는 자신의 비밀키를 사용해서 유저가 보내준 티켓을 복호화한다.
   • 티켓에서 SS 세션키와 유저 아이디를 얻는다.
   • SS 세션키를 사용해서 Authenticator를 복호화한다.
   • Authenticator에서 유저 아이디와 타임스탬프를 얻는다.
   • 티켓에서 얻어낸 유저 아이디와 Authenticator에서 얻어낸 유저 아이디를 비교해서 같은지를 확인한다.
     만약 같다면 유저가 정상적으로 TGS를 거쳐서 SS에 요청을 보냈다는 것이 증명된다.
   • SS는 최종적으로 Authenticator에 포함된 타임스탬프를 SS 세션키로 암호화해서 유저에게 전송한다.
     
     
7. 유저는 SS로부터 받은 타임 스탬프를 SS 세션키로 복호화하여 자신이 보냈던 타임스탬프와 일치하는지 확인한다.
   • 자신이 보냈던 타임 스탬프와 SS로 부터 받은 타임 스탬프가 일치하면 SS의 신뢰성이 증명된다.
   • 이후로 SS와 유저는 신뢰적인 통신이 가능해진다.

 

커버로스의 단점

1. 커버로스 서버는 SPOF(Single Point Of Failure) 특성을 가진다.
   따라서 커버로스 서버가 다운되면 이미 로그인 된 유저를 제외하고 새롭게 로그인을 시도하는 유저가 서버에 접속할 수 없게된다.
   -> 여러 개의 서버를 운용하는 등 장애 상황에 대한 아키텍처를 구축해야 한다.
2. AS, TGS, SS는 서로의 비밀키를 미리 알고있어야 해서 동기화 이슈가 존재한다.
3. 요청 시간에 대한 요구가 엄격하다.(통상적으로 5분)
   만약 요청을 주고받는 호스트들 간에 시간 동기화가 되어있지 않을 경우 통신이 불가능하다.
4. 인증이 한번 완료되면 유효기간이 존재하긴 하지만 티켓이 클라이언트에 보관되므로 탈취될 가능성이 있다.

---

커버로스 그림으로 이해하기(최종)

 

초록색 키 : 유저의 비밀번호

노란색 키 : TGS 비밀키

빨간색 키 : TGS 세션키

검은색 키 : SS 비밀키

파란색 키 : SS 세션키

 

세부 동작 부분을 모두 이해했다면 위 그림의 플로우가 모두 이해될 것이다!

---

REF.

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

https://real-dongsoo7.tistory.com/117

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

https://juneyr.dev/2018-10-31/kerberos