[네트워크 보안] 키 분배와 사용자 인증
키 분배와 사용자 인증 방법
[네트워크 보안] 키 분배와 사용자 인증
3장에서는 message authentication 4장에서는 user authentication
✏️ 원격 사용자 인증 원칙
원격 사용자 인증은 사용자가 주장하는 신원을 검증하는 과정이다. 이 과정은 식별(identification)과 검증(verification) 단계로 나뉜다.
- identification: 나의 식별자를 보안 시스템에 제시
- verification: [엔티티(사용자) - 식별자] 간의 binding을 입증하는 인증 정보 생성
■ 전자 사용자 인증 모델
전자 사용자 인증 모델은 사용자의 신원에 대해 신뢰성을 보장하는 과정을 말한다.
- RA (Registration Authority): 사용자의 신원을 보장해주는 기관.
- CSP (Credential Service Provider): Credential을 가입자에게 발행하는 기관.
- Credential: 가입자가 소유한 토큰(예: 비밀번호)과 결합된 자료 구조.
- Claimant (청구인): 인증을 요청하는 사용자.
- Verifier (검증인): 인증을 검증하는 시스템.
- RP (Relying Party): 인증에 의존하는 서비스 제공자.
절차
- 사용자는 RA에게 CSP 가입 요청을 한다.
- CSP는 사용자의 신원을 검증한 후 Credential을 발행한다.
- 사용자는 이 Credential을 이용해 원격 시스템에 로그인하거나, 인증을 요청할 수 있다.
✏️ 대칭 암호를 이용한 대칭키 분배
대칭키 분배에는 4가지 방법이 있다:
- A가 대칭키를 선택하여 B에게 직접 전달
- 적합한 경우: 통신 링크가 하나일 때.
- 부적합한 경우: end-to-end 통신인 경우.
- 제 3자가 대칭키를 선택하여 A와 B에게 전달
- 적합한 경우: 통신 링크가 하나일 때.
- 부적합한 경우: end-to-end 통신인 경우.
- A 또는 B가 대칭키로 새로운 키를 생성하고 상대방에게 전달
- 적합한 경우: end-to-end 통신.
- 주의: 키가 노출되면 그 이후 키도 모두 노출 가능.
- A와 B가 제 3자인 C와 암호화된 연결을 맺고, C가 A와 B에게 키를 전달 (BEST)
- 적합한 경우: end-to-end 통신.
■ 세션키와 영구키
위의 4번째 방법에서 A와 C, B와 C는 영구키를 사용해서 연결을 맺는다. C는 A와 B에게 세션키를 분배한다.
- 세션키: 특정 세션(논리적 연결) 동안 사용되는 일회용 대칭키. 모든 데이터는 이 세션키로 암호화된다.
- 영구키: 세션키 분배를 위해 사용하는 키로, 여러 세션에서 복수회 사용된다. 영구키는 KDC(Key Distribution Center)에서 활용된다.
■ KDC 키 분배 절차
- A가 B와 통신하려면, KDC에게 연결 요청을 전송한다.
- [A-KDC], [KDC-B] 간의 통신은 영구키로 암호화된다.
- KDC는 요청을 수락한 후, 일회용 세션키를 생성하여 A와 B에게 전달한다.
- 세션키는 A와 B 각각의 영구키로 암호화되어 전달된다.
- A와 B는 세션키를 사용하여 암호화된 논리적 연결을 설정한다.
✏️ Kerberos
Kerberos는 키 분배와 사용자 인증 서비스를 제공하는 중앙집중식 인증 시스템으로, 대칭 암호를 기반으로 한다.
위협 요소
- 정상 사용자로 위장: 악의적인 사용자가 정상 사용자처럼 가장하는 위협.
- 네트워크 주소 변경: 악성 사용자가 네트워크 주소를 변경해 정상 워크스테이션으로 위장.
- 재전송 공격 (Replay Attack): 이전에 발생한 접근 정보를 재사용하여 서버 접근 권한을 획득하는 공격.
■ Kerberos Version 4
- DES 알고리즘을 사용하여 사용자 인증과 키 분배를 처리한다.
- Authentication Server (AS)는 사용자와 서버 간 인증을 전담하며, 각 서버와 유일한 비밀키를 공유한다.
주요 용어
| 용어 | 설명 | | - | - | | C | 클라이언트 (Client) | | AS | 인증 서버 (Authentication Server) | | V | 서비스 서버 (Service Server) | | ID_C | 클라이언트의 식별자 | | ID_V | 서버의 식별자 | | P_C | 클라이언트의 비밀번호 (Password) |
■ Kerberos Version 4의 동작 과정 - 단순과정
- C->AS
ID_C || P_C || ID_V나의 Password는 뭐다~- AS->C Ticket 전송
Ticket = Encryption K_V(ID_C || AD_C || ID_V )- C->V
ID_C || TicketTicket과 함께 ID 전송
티켓의 특징
- Ticket은 변경 및 위조를 방지하기 위해 K_V(AS와 서버 간에 공유되는 비밀키)로 암호화된다.
- 티켓은 클라이언트가 직접 해독할 수 없으며, 서버가 티켓을 복호화하여 검증한다.
- 티켓에는 클라이언트 ID, 서버 ID, 클라이언트 주소가 포함됨
ID_V: 서버가 티켓이 올바르게 복호화 되었는지 확인가능ID_C: 티켓이 C에게 발행되었음을 명시- 클라이언트 주소: 재전송 공격 방지 티켓을 요청한 워크스테이션에서만 티켓을 사용할 수 있게 한다.
단순 방식의 문제점
- 비밀번호 평문 전송: 패스워드가 평문으로 전송되어 도청에 취약.
- 해결책: 티켓 발행 서버(TGS)를 도입하여 비밀번호 평문 전송 문제를 해결.
- 잦은 비밀번호 입력: 서버에 접속할 때마다 비밀번호 입력 필요.
- 해결책: 티켓 재사용을 통해 비밀번호 입력 빈도를 줄임.
■ Kerberos Version 4의 동작 과정 - TGS 도입
개선된 Kerberos는 TGS (Ticket-Granting Server)를 도입하여 비밀번호 입력 빈도를 줄이고, 평문 비밀번호 전송 문제를 해결했다.
- C -> AS
ID_C || ID_TGS나 클라이언튼데 이런 TGS 서버에서 인증 받을래- AS -> C
E[K_C(Ticket_TGS)]
- Kc는 Pc(client password)로부터 생성됨
- E_Kc는 클라이언트만 열어볼 수 있음
- Kc는 클라이언트와 AS가 공유하는 비밀키이다.
- C -> TGS
ID_C || ID_V || Ticket_tgsTGS는 실제 서버에 대한 티켓을 제공해주는 서버이다.- TGS -> C
Tickt_V- C -> V
ID_C || Ticket_V
1,2 과정 - 로그인 할 때 한번씩 실행 3,4 과정 - 다른 서버에 접속할 때 한번씩 실행 5 과정 - 서버에 접속할 때마다 실행
Ticket_TGS
Ticket_TGS = E[K_TGS(ID_C || AD_C || ID_tgs || TS1 || Lifetime1)]
K_TGS는 TGS와 AS 간에 공유되는 비밀키
Ticket_TGS는 AS가 만든 것이기 때문이다.Ticket_TGS는 3번에서 TGS가 복호화한다.- ⚠️ 클라이언트는 Ticket을 풀어보지 못한다.
Ticket_V
Ticket_V = E[K_V(ID_C || AD_C || ID_V || TS2 || Lifetime2)]
K_V는 TGS와 V 간에 공유되는 비밀키
- TGS가
K_V를 사용해서 암호화를 한다.- V가
K_V를 사용해서 복호화를 한다.
특징
- 클라이언트는 자신의 비밀번호 P_C를 직접 제출하지 않는다.
Ticket_TGS(티켓 승인 티켓) 재사용이 가능해져, 로그인 시 한 번 발급받은 티켓을 여러 서버에 접속할 때 사용할 수 있다.- 로그인 했을 때 한번 발행
- 접속할 때마다 저거 쓰면 됨
- AS와 TGS간 비밀키로 암호화
- 사용자 패스워드로부터 만들어진 Kc를 이용해서 암호화(사용자 인증)
- TimeStamp와 Lifetime을 사용하여 티켓의 도난 및 재사용을 방지한다.
- TimeStamp: 티켓 발행 시간
- LifeTime: 티켓 만료 기간
문제점 첫 번째 시나리오보다 안전해짐
- 또 다른 두 가지 문제점 발생
- 티켓 유효기간 문제: Ticket을 가로챈 뒤 해당 워크스테이션에서 로그오프 할 때까지 대기 -> 타임스탬프로 대비 티켓 제시자와 티켓 발행 받은 자의 동일성 확인 필요
- 서버를 사용자에게 인증하는 절차가 없음 공격자가 특정 서버로 전달되는 메시지를 다른 곳으로 송신, 위장(가짜) 서버 가능
■ 더 개선된 Kerberos
기존 클라이언트 인증
- 서버 인증
- 키 분배까지
- Authenticator_C: 티켓을 확인하기 위해 클라이언트가 생성하는 인증자, 짧은 인증 시간, 클라이언트의 신원 인증
- 상호간의 인증이 필요한 경우 TS_5 +1: C는 Kc,v로 TS_5 + 1을 복호화해서 V를 인증
핵심은 Authenticator와 비밀키들이 생성되었다는 것 비밀키: (C,TGS), (C,V)
■ Kerberos Version 5
|
Ticket_TGS를 만들어내기 위해 K_TGS로 암호화 -> K_C로 암호화
자세히 과정을 하지는 않음
- Time은 시작시간부터 끝나는 시간까지 명시
- rtimeL 요구되는 재시작부터 만료시간까지의 시간
- Nonce 메시지2 에서 반복 사용되는 랜덤넘버
- 응답이 재전송된 것이 아님을 확신
- Subkey: 특정 세션 보호를 위한 키 -> 클라이언트가 선택한다.
- 생략시, 티켓에 있는 세션키(K_C,V)를 사용한다.
✏️ 비대칭 암호를 이용한 키 분배
공개키 방식을 사용한 키 분배 공개키 방식을 사용해서 비밀키 분배, 대칭키 분배를 할 수 있다.
공개키 인증서
- 공개키와 사용자(키 소유자) ID로 구성
- 공개키 인증서는 신뢰할 만한 제 3자가 서명한다.
- 제 3자: CA
서명 안된 인증서: 사용자 ID와 공개키
- 서명 안된 인증서의 해시코드 생성
- CA의 개인키로 해당 해시코드를 암호화
- 서명을 인증서에 추가 -> 수신자는 CA의 공개키로 서명을 확인할 수 있다.
공개키를 이용한 비밀키 분배
Diffie-Hellman 키 교환을 이용 두 통신자 사이에 인증을 제공하지 않음(중간자 공격)
<대안> - 공개키 인증서 사용 1. B는 A에게 보낼 메시지(M)를 준비 2. B는 일회용 세션키(K)를 이용하는 관용암호 기법으로 메시지를 암호화(`E_K(M)`) 3. B는 A의 공개키를 이용해서 그 세션키를 암호화(`E_puA(K)`) 4. B는 암호화된 세션키를 메시지에 첨부해서 A에게 보냄(`E_K(M)` || `E_PUA(K)`) 목표: 메시지를 알아내기 그럴려면 비밀키를 알아야함 A의 개인키로 Decryption D(E_puA(K))---
## ✏️ X.509 **X.509**는 **ITU-T**라는 표준화 기구에서 정의한 인증서 표준으로, 다양한 보안 프로토콜에서 활용된다. ### ■ 사용되는 영역 - **S/MIME**: 이메일 보안 - **IP Security**: 네트워크 보안 - **SSL/TLS**: HTTPS - **SET**: 전자상거래 보안
### ■ 인증서 형식 - **버전1**: 초기 인증서 형식. - **버전2**: 주체 및 발행자 유일 식별자가 추가됨. - **버전3**: 확장 필드가 추가되어 다양한 인증서 정보를 포함할 수 있음.
| X.509 인증서 | | - | | 버전| | 인증서 일련번호| | 서명 알고리즘 식별자| | 발행자 이름| | 유효 기간| | 주체 이름| | 주체의 공개키 정보| | 발행자 유일 식별자| | 주체 유일 식별자| | 확장| | 서명| **서명 방식**: 인증서의 모든 구성 요소에 대해 서명이 적용된다. **CA가 서명한 공개키 인증서**는 `CA<>`로 표기되며, 이는 CA가 A라는 주체의 공개키에 CA 자신의 개인키로 서명한 것이다. - `CA{I}`: **서명된 해시코드와 I**를 CA가 서명한 것. - `CA<> == CA{인증서 구성요소}`
### ■ 인증서의 특성 CA가 발행한 인증서는 다음과 같은 특성을 지닌다: - **CA의 공개키**를 가진 사람은 **다른 주체**의 공개키를 확인할 수 있다. - **CA 외에는 인증서**를 변경할 수 없다.
### ■ 인증서 체인 A가 B의 공개키를 얻으려면, **인증서 체인**을 통해 확인할 수 있다. 예를 들어, A의 CA는 `X1`이며 `X1<
A는 X2의 공개키를 통해 B의 공개키를 얻는다. - **순방향 인증서**: 다른 주체가 생성한 나의 인증서. - **역방향 인증서**: 내가 생성한 다른 주체의 인증서.
### ■ 인증서 취소 > #### CRL(Certificate Revocation List) : 취소되었지만 유효기간이 남은 인증서 목록을 보관한다. 인증서가 취소되는 이유는 다음과 같다: - **개인키 노출** 또는 훼손. - CA의 서명 불가 상태. - **CA의 인증서 노출** 등.
---
## ✏️ 공개키 기반 구조 (PKI) > #### PKI(Public-Key Infrastructure) **디지털 인증서를 생성 및 관리**하는 데 필요한 정책 및 절차를 정의한 구조이다. - **목적**: 공개키를 편리하게 얻고 인증할 수 있게 하여 보안성을 높인다. - **RA(Registration Authority)와 CRL issuer**는 선택적으로 존재할 수 있다.
---
## ✏️ 통합 신원 관리 사용자가 많을 경우 **신원 관리**를 효율적으로 수행하기 위해 **통합 신원 관리**가 필요하다. > #### 신원 관리 : 개인이 자원에 접근하는 절차를 **중앙화 및 자동화**하여 관리하는 시스템.
### ■ SSO (Single Sign-On) > #### SSO : **한 번 인증**을 통해 **네트워크의 모든 자원에 접근**할 수 있도록 하는 시스템이다. 이는 **신원 관리 시스템**의 핵심 개념으로, 네트워크상의 모든 자원에 대해 단일 인증만으로 접근을 가능하게 한다.
### ■ 신원 통합 **한 번의 인증** 후, **다른 시스템**에서도 자동으로 접속할 수 있는 기능이다. 이는 **다중 보안 도메인** 간에 **디지털 신원을 공유**하는 방식이다. - 내부 비즈니스 단위, 외부 비즈니스 파트너, 기타 제 3자 응용 서비스 등에 공유 가능 - ⚠️ 중앙화가 불가능하다는 단점! - ⚠️ **표준화 필요**: XML, SOAP, WS-Security, SAML 등을 통해 보안성을 유지.
### ■ 통합의 예시 - **계정 연결 기반 통합**: 예를 들어, Health.com과 Workplace.com이 계약하여 Workplace.com의 사용자 DB를 Health.com과 공유. - **역할 기반 통합**: 특정 역할이 부여된 사용자에게만 접근 권한을 제공. - **연쇄 웹 서비스**: SOAP 등을 사용하여 다중 서비스를 연계.
This post is licensed under
CC BY 4.0
by the author.