Kerberos 심층 이해

Kerberos 심층 이해

Kerberos를 공부하며 모호했던 점을 확실히 하고자 합니다.
계층 구조로 Kerberos를 그리고, 왜 사용하며, 무엇이 중요한지 등 핵심을 알아보겠습니다

Kerberos의 세부사항을 살펴보자

일단 상호간 무조건 암호화가 되어있다
C와 AS는 서로 공유하는 키로 무조건 암호화해서 보낸다
또한, 티켓은 C가 열어 볼 수 없다, 오직 서버 측을 위해 생성 된 것이다

• Kerberos의 핵심은 무엇인가?
  • 중앙 집중식 인증
  • 클라이언트 - 서버 상호 인증
  • 네트워크 상의 비밀 유지
• Kerberos의 전제 조건
  • 사전 키 공유 : AS(인증 서버)는 클라이언트의 비밀번호와 TGS의 비밀 키를 사전에 안전하게 받음
  • 시간 동기화 : 클라이언트와 서버의 시간을 동기화하여 재전송 공격 방어

Kerberos 전개 과정의 핵심 요소

C-AS와 C-TGS의 매커니즘은 사실상 동일합니다.
C(사용자)는 Authenticator와 Ticket으로 사용자 인증을 합니다

• Authenticator
  • C-AS의 공유키로 암호화
  • Ç의 ID와 주소 : 사용자 인증
  • TS+Lifetime : 재전송 공격 방어
• Ticket
  • AS의 고유키로 암호화
  • C의 ID와 AD : 사용자 인증
  • AS의 ID : AS가 무결성 체크를 하기 위해 사용
  • TS+Lifetime : 재전송 공격 방어
  • K_c,as : C와 AS의 세션 키 : Authenticator 복호화 및 클라이언트 ID와 타임 스탬프 유효성 검증

내가 놓친 부분

• 당연히 사전에 세션 키각 C와 AS 간에 공유 되었을거라 생각했다
  • AS의 개인 키로 암호화 된 Ticket을 복호화하여, AS는 처음 키를 얻는다
• 굳이 C의 ID와 AD를 티켓에도 넣고, 그냥도 보내야 하나?
  • 보내야 한다. 클라이언트 인증을 하기 위함
• 서버 측의 인증은 서버에서 일어난다.
  • C가 받은 서비스 티켓과 함께 Authenticator를 생성해 서버로 전송한다
  • 서비스 티켓 : 서비스 서버의 비밀키로 암호화
  • Authenticator : 서비스 세션 키로 암호화
  • 즉 내가 원하는 서버만 티켓을 열람 할 수 있음이 자명하기 때문에 서버 측 인증은 서버에서 일어난다

Kerberos 5 : 그래서 4에서 뭐가 부족했던건데?

• 환경적 결합 : 기존의 인프라(암호화 방식, 유효 기간 등)의 한계
• 기술적 결함 : 암호화 최적화(불필요한 연산, 암화화 강도 등)

인증 절차 추가 요소

• Realm(도메인): 사용자의 공동체 : 확장성을 위함
  • 여러 Kerberos 도메인 구분
  • 서로 다른 도메인 간 인증
• Nonce :
  • 재전송 공격 방지
  • 일회성 값으로, 요청을 전송 할 때마다 생성되며, AS가 확인
• Subkey : 양방향 인증
  • 세션 키를 보완하는 추가적인 암호화 키
  • 양쪽 통신을 독립적으로 보호
• 순서번호 : 메시지 무결성 유지
  • 메시지 전송 순서
  • 메시지 순서 추적 및 재정렬 지원
• 플래그 : 인증 프로세스에 대한 다양한 설정과 옵션