커버로스 프로토콜이란?
- 커버로스는 티켓(ticket) 기반의 컴퓨터 네트워크 인증 프로토콜이다.
- 보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 요청을 받는 서버가 서로의 신뢰성을 확보하기위해 사용된다.
티켓이 뭔가요? 왜 쓰는거죠?
- 커버로스에서 사용하는 티켓은 유저 아이디를 안전하게 전달하는 데 사용되는 정보 패킷이다.
- 티켓에 포함하는 대표적인 정보들은 다음과 같다.
- 유저 아이디
- 유저 호스트의 IP 주소
- 타임 스탬프(time stamp, 시간 기록)
- 티켓 수명을 정의하는 값
- 세션 키
- 이러한 정보들을 담고 있는 티켓은 티켓을 발급하는 서버의 비밀 키(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 세션 키를 가지고 있다.
커버로스 프로토콜의 동작 과정 상세
- 유저는 자신의 아이디를 AS에 보내서 TGT을 요청한다.
- 아이디는 일반 텍스트(plaintext)로 전송된다.
- 이는 아이디와 패스워드를 둘 다 알고 있지 않은 경우 아이디가 노출되어도 보안상 문제가 없기 때문이다.
- AS는 전송받은 아이디가 AS의 데이터베이스에 있는지 확인하고, 있다면 두 가지 정보를 생성해 유저에게 보내준다.
- 두 가지 정보란 다음과 같다.
- 데이터베이스 안에 있는 요청을 보낸 유저의 패스워드를 통해 만든 키로 암호화한 TGS 세션 키
- TGT(Ticket Granting Ticket, 티켓을 받기 위한 티켓)
- TGT는 앞서 티켓 설명에서 말한 유저 아이디와 TGS 세션 키 등 여러 정보들을 TGS 비밀 키로 암호화한 티켓이다.
- AS는 TGS의 비밀 키를 가지고 있기 때문에 TGT를 만드는 것이 가능하다.
- 유저는 AS로부터 받은 두 가지 정보를 통해 TGS 세션 키를 얻고, Authenticator를 만들어 TGT와 함께 TGS에 보내준다.
- AS는 TGS 세션 키를 유저의 패스워드를 통해 암호화해서 보냈다고 앞서 말했다.
- 유저는 당연히 자신의 패스워드를 알고 있으므로, AS로부터 받은 정보를 복호화하여 TGS 세션 키를 얻을 수 있다.
- TGS 세션 키를 얻어 냈으므로, 이제 유저는 TGS에게 보낼 Authenticator를 만들 수 있다.
- Authenticator는 유저 아이디와 타임 스탬프를 TGS 세션 키로 암호화 한 데이터이다.
- TGT는 별다른 처리과정을 거치지 않고, Authenticator와 함께 TGS에 보내진다.
- TGS는 유저로부터 받은 TGT와 Authenticator를 복호화하여 유저 아이디가 일치하는지 확인하고, 일치한다면 유저에게 티켓과 SS 세션 키를 발급해준다.
- TGT와 Authenticator를 복호화하는 과정에서, TGT부터 복호화가 진행된다.
- TGS는 TGS 비밀 키를 통해 TGT를 복호화할 수 있는데, TGT를 먼저 복호화해야만 Authenticator를 복호화할 수 있는 키인 TGS 세션 키를 얻을 수 있기 때문이다.
- TGT와 Authenticator 둘 다 유저 아이디를 포함하고 있으므로, 두 개의 유저 아이디가 같은지를 확인하면 유저가 정상적으로 AS를 거쳐 TGS에 요청이 보냈다는 것을 입증할 수 있다.
- TGS는 유저에게 SS와 통신할 권한을 주기 위해 SS 세션 키를 발급하고, 티켓 또한 발급해줘야 한다.
- SS 세션 키는 TGS 세션 키로 암호화한다.
- 티켓은 유저 아이디와 SS 세션 키 등을 SS 비밀 키로 암호화하여 만든다.
- 유저는 TGS로부터 암호화된 SS 세션 키와 티켓을 받고, 암호화된 SS 세션 키를 복호화하여 또 다른 Authenticator를 만들어 티켓과 함께 SS에게 보내준다.
- TGS로부터 받은 SS 세션 키는 TGS 세션 키로 암호화되어있으므로, 유저는 이미 TGS 세션 키를 가지고 있기 때문에 SS 세션 키를 쉽게 얻을 수 있다.
- 유저가 SS에게 보내야 하는 Authenticator는 이전 단계에서 TGS에 만들어 보낸 Authenticator와 거의 비슷하다.
- 한 가지 다른 점은 Authenticator를 SS 세션 키로 암호화한다는 것이다.
- Authenticator는 유저 아이디와 함께 타임 스탬프를 포함하고 있는데, 이 중 타임 스탬프를 SS로부터 답장받는 타임 스탬프와 비교하여 SS의 신뢰성을 확인받는다.
- 이렇게 만든 Authenticator를 TGS로부터 받은 티켓과 함께 SS에 보내준다.
- SS는 유저로부터 받은 Authenticator와 티켓을 복호화하여 유저 아이디가 일치하는지 확인한 후, 일치한다면 Authenticator에 들어 있던 타임 스탬프를 SS 세션 키로 암호화하여 유저에게 보내준다.
- SS는 Authenticator보다 티켓을 먼저 복호화해야 한다.
- 티켓을 SS 비밀 키로 복호화하면 SS 세션 키를 얻을 수 있다.
- Authenticator는 SS 세션 키를 통해 암호화되어 있으므로, 얻어낸 SS 세션 키를 통해 Authenticator를 복호화하고 Authenticator와 티켓 각각에 들어있던 유저 아이디를 비교해준다.
- 유저 아이디가 일치한다면 유저가 정상적으로 AS와 TGS를 거쳐 왔음을 신뢰할 수 있다는 의미이다.
- 그 후 유저가 보낸 Authenticator 안의 타임 스탬프를 SS 세션 키로 암호화해서 유저에게 답신해준다.
- 유저는 답신받은 데이터를 SS 세션 키로 복호화하여 앞서 SS에게 보낸 타임 스탬프와 일치하는지의 여부를 체크한다.
- 두 개의 타임스탬프가 서로 일치한다면, SS를 신뢰할 수 있다는 의미이다.
- SS는 최종적으로 유저가 요청을 보내려는 서버이므로, 이 단계까지 성공적으로 수행됐다면 유저와 서버는 서로를 신뢰하는 통신이 가능해진다.
커버로스 프로토콜의 단점
- 커버로스 서버는 하나이기 때문에 서버가 다운될 경우, 새로운 유저는 로그인할 수가 없다. 따라서 여러 개의 서버를 운용하는 등 서버가 작동하지 않을 때를 대비할 수 있는 메커니즘을 구현해야 한다.
- 요청 시간에 대한 요구가 엄격하다(통상적으로 5분). 만약 요청을 주고받는 호스트들 간에 시간 동기화가 되어있지 않을 경우 통신이 불가능하다.
참고한 자료
https://en.wikipedia.org/wiki/Kerberos_(protocol)
https://docs.oracle.com/cd/E26925_01/html/E25888/refer-11.html
'개발' 카테고리의 다른 글
펜윅 트리(Fenwick Tree)란? (0) | 2019.12.22 |
---|---|
함수 포인터(Function Pointer)란? (0) | 2019.12.02 |
CSS 선택자(Selector)란? (0) | 2019.11.15 |
패키지 매니저(Package Manager)란? (0) | 2019.11.12 |
어떤 정렬 알고리즘을 사용할 것인가? (0) | 2019.05.28 |