Key Establishment (키 확립 방식)

안전한 통신을 위해 양 종단 간에 비밀키를 설정하는 방법은 크게 두 가지로 나뉩니다.

• Key Transport (키 전송): 통신하는 두 주체 중 한쪽(One party)이 비밀키를 생성한 후, 이를 암호화하여 상대방에게 전달하는 방식입니다.
• Key Agreement (키 합의): 어느 한쪽이 일방적으로 키를 정하는 것이 아니라, 양쪽(Both parties)이 수학적 연산을 통해 공동으로 키를 도출해내는 방식입니다.
  • 필기 하단에 예시로 적힌 D-H Key Exchange (디피-헬만 키 교환)가 가장 대표적입니다.
  • 수식: $K_{AB} = \alpha^{ab} \bmod P$ (양측의 개인값 $a, b$와 공개 변수 $\alpha, P$를 혼합하여 동일한 대칭키 $K_{AB}$를 만들어냅니다.)

Naive Approach: The $n^2$ Key Distribution Problem

필기 하단의 네트워크 다이어그램은 대칭키를 가장 단순한 방식(Naive approach)으로 분배할 때 발생하는 치명적인 한계를 보여줍니다.

기본 가정 (Assumption)
네트워크 내의 모든 사용자가 1:1 통신을 위해 각각 고유한 비밀키(Pairwise secret keys)를 나눠 가져야 한다고 가정합니다.

$n=4$ 일 때의 상황 (첫 번째 이미지)Alice, Bob, Chris, David 4명이 통신망에 있습니다.

• Alice는 3개의 키가 필요합니다. ($K_{AB}, K_{AC}, K_{AD}$)
• Bob도 3개의 키가 필요합니다. ($K_{AB}, K_{BC}, K_{BD}$)
• 결과적으로 4명으로 구성된 전체 네트워크에는 총 6개의 고유한 대칭키가 필요합니다.

Frank의 등장: 새로운 사용자 'Frank'가 네트워크에 추가되어 $n=5$가 되었습니다. 빨간색 글씨로 표시된 것처럼, Frank 단 한 명이 추가되었을 뿐인데 기존 4명과 연결하기 위한 4개의 새로운 키($K_{AF}, K_{BF}, K_{CF}, K_{DF}$)가 즉각적으로 필요해집니다.

UH 65000+의 의미: 중앙에 적힌 'T.A.(Trusted Authority)' 아래의 "UH 65000+"는 휴스턴 대학교(University of Houston)의 학생 수 등을 예로 든 것입니다. 만약 65,000명의 사용자가 이 단순한 1:1 방식으로 대칭키를 관리한다면, 시스템 전체에 필요한 키의 개수는 $\frac{n(n-1)}{2}$ 공식에 의해 약 21억 개에 달하게 됩니다.

KDC 구조의 도입과 한계

기존에 모든 사용자가 1:1로 직접 키를 교환해야 했던 복잡도 $O(n^2)$의 문제를 해결하기 위해 KDC(Key Distribution Center)라는 신뢰할 수 있는 중앙 서버를 도입합니다.

KDC의 작동 원리와 장점

• 선형적 확장성: 통신망에 참여하는 사용자 수 $n$명에 대해 전체 네트워크가 관리해야 할 키의 개수가 $n$개로 크게 줄어듭니다.
• KEK (Key Encryption Key): 각 사용자(Alice, Bob 등)는 오직 KDC와 통신하기 위한 마스터키($K_A, K_B$)만 안전하게 나눠 가집니다. 이를 KEK라고 부릅니다.
• 새로운 사용자(Chris)가 추가될 때, 다른 모든 사용자와 키를 맞출 필요 없이 KDC와 단 한 번만 $K_C$를 초기 설정(Initialization)하면 되므로 인프라 확장이 매우 쉽습니다.

현실적인 시스템 취약점 (Weaknesses)

효율성이 높아진 대신 보안 구조상 두 가지 심각한 리스크가 발생합니다.

• SPOF (Single Point of Failure, 단일 장애점): KDC 서버가 다운되거나 해킹당하면 네트워크 전체의 암호화 통신이 완전히 마비됩니다.

• 완전 전방향 무결성(Perfect Forward Secrecy, PFS) 부재: 만약 해커가 특정 사용자의 KEK를 탈취하는 데 성공한다면, 현재의 통신뿐만 아니라 과거에 저장해 두었던 모든 통신 기록까지 소급하여 해독해 낼 수 있습니다. 과거의 세션 키들이 모두 이 KEK로 암호화되어 분배되었기 때문입니다.

• 참고: 이 KDC 구조는 오늘날 윈도우 네트워크 등에서 널리 쓰이는 인증 프로토콜인 Kerberos(커베로스)의 근간이 됩니다.

KDC 취약점을 노린 공격 시나리오

노트는 KDC를 매개로 통신할 때 발생할 수 있는 구체적인 공격 기법 두 가지를 보여줍니다. (필기의 'Reply Attack'은 'Replay Attack'의 오기로 보입니다. 학술적 표준 명칭은 Replay Attack입니다.)

2.1. Replay Attack (재전송 공격)

전제: 능동형 공격자(Active Attacker)인 Trudy가 과거 통신에서 사용되었던 낡은 세션 키(Old session key)를 어떠한 방법으로 알아낸 상태입니다.

이 과거의 키와 암호문을 통신망에 다시 주입하여, 마치 현재 유효한 통신인 것처럼 시스템을 속이는 공격입니다.

2.2. Key Confirmation Attack (키 확인 공격 / 중간자 공격)

이 공격은 KDC의 메시지 응답 구조에 '상호 인증'이 빠져 있을 때 발생하는 치명적인 논리적 결함을 파고듭니다. 릴레이 경주에서 주자가 눈을 가린 채 뛰고 있을 때, 누군가 몰래 트랙의 목적지를 바꿔버리는 상황과 같습니다.

[공격의 단계별 흐름]

1. 가로채기와 조작: Alice는 Bob과 통신하기 위해 KDC에 RQST(ID_A, ID_B)를 보냅니다. 하지만 Trudy가 이를 중간에서 가로채어 목적지를 자신으로 바꾼 RQST(ID_A, ID_T)로 위조하여 KDC에 보냅니다.

2. KDC의 착각: KDC는 Alice가 Trudy와 통신하길 원한다고 생각하고, 두 사람이 쓸 일회용 세션 키 $K_{ses}$를 생성합니다. 그리고 이를 각각의 KEK로 암호화하여 $Y_A = e_{K_A}(K_{ses})$ 와 $Y_T = e_{K_T}(K_{ses})$ 를 만들어 Trudy에게 보냅니다.

3. Alice의 착각 (맹점): Trudy는 KDC가 준 $Y_A, Y_T$를 Alice에게 넘깁니다. Alice는 자신의 키 $K_A$로 $Y_A$를 해독하여 $K_{ses}$를 얻습니다. 이때 Alice는 자신이 처음에 Bob을 불렀으므로, 이 세션 키가 당연히 Bob과 공유하는 트랙이라고 굳게 믿습니다. (KDC의 응답에 "이 키는 Trudy용이다"라는 식별표가 없었기 때문입니다.)

4. 해독 완료: Alice는 기밀 데이터 $X$를 방금 얻은 세션 키로 암호화하여 $Y = e_{K_{ses}}(X)$를 만들고, $Y, Y_T$를 전송합니다. 기다리고 있던 Trudy는 자신의 키 $K_T$로 $Y_T$를 열어 $K_{ses}$를 확보한 뒤, Alice의 메시지 $Y$를 완벽하게 해독해 냅니다.

커베로스(Kerberos) 프로토콜의 단순화 버전

1. 통신 요청 (Alice $\rightarrow$ KDC)

$RQST(ID_A, ID_B, r_A)$

• Alice는 KDC에게 "나($ID_A$) Bob($ID_B$)이랑 통신하고 싶어"라고 요청합니다.
• 핵심 방어 무기 1 - 난수($r_A$): 여기서 Alice는 $r_A$라는 일회용 난수(Nonce)를 생성해서 함께 보냅니다. 이는 나중에 KDC의 응답이 '과거의 응답을 재전송한 것'이 아니라 '지금 막 만들어진 신선한 응답'임을 증명하는 용도로 쓰입니다.

2. KDC의 응답 및 티켓 발급 (KDC $\rightarrow$ Alice)

KDC는 세션 키($K_{ses}$)와 유효기간($T$, Lifetime)을 생성한 뒤, 두 개의 암호문($Y_A, Y_B$)을 만들어 Alice에게 보냅니다.

Alice용 암호문 ($Y_A$): $e_{K_A}(K_{ses}, r_A, T, ID_B)$

• Alice의 마스터키($K_A$)로 암호화되어 있습니다.

Bob용 티켓 ($Y_B$): $e_{K_B}(K_{ses}, T, ID_A)$

• Bob의 마스터키($K_B$)로 암호화되어 있습니다. KDC가 Bob에게 직접 주지 않고 Alice에게 들려 보냅니다. 이를 티켓(Ticket)이라고 부릅니다.

3. Alice의 검증 (약점 완벽 방어)

Alice는 자신의 키 $K_A$로 $Y_A$를 해독하여 내부의 값들을 철저히 검증합니다. 여기서 이전의 공격들이 모두 막힙니다.

1. $r_A = r_A'$ 확인 (KDC Authentication): 자신이 보냈던 난수 $r_A$가 응답에 그대로 들어있는지 확인합니다. 맞다면 이 응답은 누군가 가로채서 재전송(Replay)한 것이 아니라, KDC가 지금 막 응답한 것임을 확신할 수 있습니다.

2. $ID_B$ 확인 (Key Confirmation Attack 방어): 필기의 초록색 박스 부분입니다. KDC가 준 암호문 안에 내가 통신하고자 했던 상대방의 이름($ID_B$)이 명시되어 있습니다. 따라서 해커(Trudy)가 중간에서 목적지를 조작하더라도, Alice는 "어? 난 Bob이랑 통신한다고 했는데 왜 증명서엔 Trudy라고 적혀있지?" 하고 즉시 공격을 알아채고 통신을 끊을 수 있습니다.

3. $T$ (Lifetime) 확인: 발급받은 키의 유효기간이 지나지 않았는지 확인합니다.

4. Alice의 증명서 생성 및 전송 (Alice $\rightarrow$ Bob)

검증을 마친 Alice는 Bob에게 통신을 시도합니다. 이때 KDC에게 받았던 Bob용 티켓($Y_B$)과 함께, 자신이 진짜 Alice임을 증명하는 Authenticator(인증자, $Y_{AB}$)를 직접 만들어 보냅니다.

• 핵심 방어 무기 2 - 타임스탬프($T_S$): $Y_{AB} = e_{K_{ses}}(ID_A, T_S)$
• 자신이 Alice라는 정보와 현재 시간($T_S$)을 세션 키로 암호화합니다. (필기 우측 상단에 "Rough syn Alice & Bob"이라고 적힌 이유는 타임스탬프를 확인하려면 양측의 시계가 대략적으로 동기화되어 있어야 하기 때문입니다.)

5. Bob의 최종 검증

메시지를 받은 Bob은 두 가지를 해독합니다.

1. KDC가 만든 티켓($Y_B$)을 자신의 마스터키($K_B$)로 열어 세션 키($K_{ses}$)와 통신 상대방이 Alice($ID_A$)임을 확인합니다.

2. 방금 얻은 세션 키($K_{ses}$)로 Alice가 보낸 Authenticator($Y_{AB}$)를 열어봅니다.

• 안에 적힌 $ID_A'$가 티켓에 적힌 $ID_A$와 일치하는지 확인합니다. (진짜 Alice가 보낸 것이 맞음)
• 타임스탬프 $T_S$를 확인하여, 이 메시지가 옛날에 해커가 훔쳐둔 메시지를 재전송(Replay)한 것이 아니라 지금 막 보낸 신선한 메시지인지 확인합니다.

모든 검증이 끝나면 비로소 세션 키($K_{ses}$)를 이용해 안전하게 실제 데이터 $X$를 암호화($Y = e_{K_{ses}}(X)$)하여 통신을 시작합니다.