[스크랩] 커버로스 (Kerberos)

real-dongsoo7.tistory.com/117

커버로스(Kerberos) 프로토콜

커버로스란?

커버로스(Kerberos)는 "티켓"(ticket)을 기반으로 동작하는 컴퓨터 네트워크 인증 암호화 프로토콜로서 비보안 네트워크에서 통신하는 노드가 보안 방식으로 다른 노드에 대해 식별할 수 있게 허용한다.

 

클라이언트 서버 모델을 목적으로 개발되었으며 사용자와 서버가 서로 식별할 수 있는 상호 인증(양방향 인증)을 제공한다. 커버로스 프로토콜의 메시지는 도청과 재전송 공격으로부터 보호된다.

 

커버로스는 대칭 키 암호로 빌드되며 TTP(신뢰된 서드 파티)를 요구한다. 또, 특정 인증 구간에서 비대칭 키 암호 방식을 이용함으로써 선택적으로 공개 키 암호 방식을 사용할 수 있다. 커버로스는 기본으로 포트 88을 사용한다.

 

출처 : 위키백과

 

간단하게 이야기 정리하면?

 

• 클라이언트 - 서버 구조에서
• 서버 접근권한에 대한 관리를 위해
• 대칭키 방식을 이용하여 인증하는
• 네트워크 인증 암호화 프로토콜입니다.

 

어떤 경우에 사용할까?

 

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

 

커버로스 동작 과정과 주요 개념

• Client, AS, TGS, SS
• 대칭키(공통 키) 암호화

 

커버로스는 크게 4가지 대상이 맞물려 작동합니다.

 

• 서비스를 제공받을 Client
• 인증을 제공할 AS(Authentication Server)
• 티켓을 발행해주는 TGS(Ticket Granting Server)
• 서비스를 제공해주는 SS(Service Server)

커버로스(kerberos) 동작 과정

 

커버로스(kerberos) 동작과정

 

사용자 클라이언트 기반 로그인

 

(1) 클라이언트는 사용자로부터 아이디와 비밀번호를 입력받습니다.

(2) 비밀번호를 대칭키로 변환하여 암호키를 생성합니다.

 

클라이언트 인증

 

(3) 클라이언트는 AS에게 사용자 아이디를 전송합니다.

(4) AS는 사용자 아이디로 데이터베이스를 조회하고 두 개의 메시지를 생성합니다.

 

• 메시지 A → 클라이언트 비밀번호를 기반으로 Client / TGS 세션 키 생성
• 메시지 B → TGS의 비밀키로 TGT를 암호화
• TGT = (Client ID + network ip + expired time + TGS session key)

 

(5) (2)에서 만든 암호키를 기반으로 메시지 A를 해독(DB의 비밀번호와 사용자가 입력한 비밀번호가 동일하면 성공)하고 TGS 세션 키를 획득합니다. 클라이언트는 TGS 비밀키를 가지고 있지 않으므로 해독하지 않고 가지고 있습니다.

 

고객 서비스 인증

 

(6) 클라이언트는 메시지 A, B를 통해 메시지 C와 D를 생성합니다

 

• 메시지 C → TGT + Service ID
• 메시지 D → (클라이언트 ID + Timestamp)를 TGS 세션 키로 암호화 생성된 메시지는 AS의 TGS로 전송됩니다.

 

(7) TGS는 메시지 C, D를 기반으로 메시지 E, F를 생성합니다.

 

• 메시지 E → Client to Server Ticket ⇒ Server Secret key로 암호화 (TGS와 SS는 Server Secret Key를 알고 있으므로 해독 가능합니다.)
• 메시지 F → Client / Server Session Key ⇒ Client / TGS 세션 키로 암호화

여기서 생성된 메시지는 클라이언트에게로 전송됩니다.

 

고객 서비스 요청

 

(8) 메시지 E와 F를 받은 사용자는 서비스를 이용할 자격을 갖추게 되었습니다. 클라이언트를 서비스를 제공받기 위해 메시지 E, G를 SS에게 전송합니다.

 

• 메시지 E → (7)에서 받은 Client to Server Ticket
• 메시지 G → (클라이언트 ID + Timestamp) ⇒ Client / Server 세션 키로 암호화

(9) SS는 E와 G를 통해 클라이언트의 신원을 확인하고 정보가 일치하는 경우 메시지 H를 통해 Client에게 신원을 확인시켜 줍니다.

 

• 메시지 H → (메시지 D의 Timestamp + 메시지 G의 Timestamp) ⇒ Client/Server 세션 키를 통해 암호화

(10) 메시지 H를 받은 Client는 해독 후 Timestamp를 확인하고 SS에 서비스를 요청하기 시작합니다.

 

 

커버로스 프로토콜의 단점

 

• 사용자 몰림으로 인해 과도한 티켓 생성 시 서버 부하가 발생할 수 있다.
• AS 다운 시 인증과정이 중단된다.
• 각 서버의 시간 설정이 잘못되어있는 경우 인증 과정에서 문제가 발생한다.
• 프로토콜의 표준화가 진행되지 않아 서버마다 구현이 상이합니다.

 

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

 

 

-----------------------

 

aahc.tistory.com/16

커버로스 프로토콜(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/