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의 동작 과정 - 단순과정
1. C->AS
ID_C || P_C || ID_V
나의 Password는 뭐다~
2. AS->C
Ticket 전송
Ticket = Encryption K_V(ID_C || AD_C || ID_V )
3. C->V
ID_C || Ticket
Ticket과 함께 ID 전송
티켓의 특징
- Ticket은 변경 및 위조를 방지하기 위해 K_V(AS와 서버 간에 공유되는 비밀키)로 암호화된다.
- 티켓은 클라이언트가 직접 해독할 수 없으며, 서버가 티켓을 복호화하여 검증한다.
- 티켓에는 클라이언트 ID, 서버 ID, 클라이언트 주소가 포함됨
ID_V: 서버가 티켓이 올바르게 복호화 되었는지 확인가능ID_C: 티켓이 C에게 발행되었음을 명시- 클라이언트 주소: 재전송 공격 방지
티켓을 요청한 워크스테이션에서만 티켓을 사용할 수 있게 한다.
단순 방식의 문제점
-
비밀번호 평문 전송: 패스워드가 평문으로 전송되어 도청에 취약.
- 해결책: 티켓 발행 서버(TGS)를 도입하여 비밀번호 평문 전송 문제를 해결.
-
잦은 비밀번호 입력: 서버에 접속할 때마다 비밀번호 입력 필요.
- 해결책: 티켓 재사용을 통해 비밀번호 입력 빈도를 줄임.
■ Kerberos Version 4의 동작 과정 - TGS 도입
개선된 Kerberos는 TGS (Ticket-Granting Server)를 도입하여 비밀번호 입력 빈도를 줄이고, 평문 비밀번호 전송 문제를 해결했다.
1. C -> AS
ID_C || ID_TGS
나 클라이언튼데 이런 TGS 서버에서 인증 받을래
2. AS -> C
E[K_C(Ticket_TGS)]
- Kc는 Pc(client password)로부터 생성됨
- E_Kc는 클라이언트만 열어볼 수 있음
- Kc는 클라이언트와 AS가 공유하는 비밀키이다.
- C -> TGS
ID_C || ID_V || Ticket_tgs
TGS는 실제 서버에 대한 티켓을 제공해주는 서버이다.
- 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
| 결함 | Version 4 | Version 5 |
|---|---|---|
| 암호화 방식 | DES를 사용한다. | 원하는 암호화 방식을 마음대로 사용할 수 있다. (명시 가능) |
| 인터넷 프로토콜 | IP 주소를 사용했다. | 프로토콜을 정할 수 있다. |
| 바이트 순서 | 빅 엔디안/리틀 엔디안을 명시해야 한다. | ASN.1, BER을 사용한다. |
| 유효기간 | 최대 유효기간은 1280분이다. | 티켓에 시작과 종료 시간을 명시한다. |
| 인증서 전달 | 클라이언트들 간에 인증서를 전달해서 사용할 수 없다. | 인증서 전달이 가능하다. |
| 관계 복잡도 | N개의 공동체에 대해 O(N^2)의 Kerberos 관계 맺기가 필요하다. | 관계 설정을 줄였다. |
| 이중 암호화 | Ticket 이중 암호화로 인한 낭비 | 1번만 암호화하도록 변경 |
| PCBC 암호화 | DES 비표준 모드인 PCBC 사용 | 표준 CBC 모드 사용 |
| 세션키 | 세션키를 사용해서 메시지 암호화 -> 재전송 공격에 취약 | 클라이언트와 서버 간에 서브 세션키 협상 가능 |
| 패스워드 공격 | P_C로 K_C를 만들어냄 -> 패스워드 공격에 취약 | 사전인증 기법 이용 |
Ticket_TGS를 만들어내기 위해 K_TGS로 암호화 -> K_C로 암호화
자세히 과정을 하지는 않음
- Time은 시작시간부터 끝나는 시간까지 명시
- rtimeL 요구되는 재시작부터 만료시간까지의 시간
- Nonce 메시지2 에서 반복 사용되는 랜덤넘버
- 응답이 재전송된 것이 아님을 확신
- Subkey: 특정 세션 보호를 위한 키 -> 클라이언트가 선택한다.
- 생략시, 티켓에 있는 세션키(K_C,V)를 사용한다.
✏️ 비대칭 암호를 이용한 키 분배
공개키 방식을 사용한 키 분배
공개키 방식을 사용해서 비밀키 분배, 대칭키 분배를 할 수 있다.
공개키 인증서
- 공개키와 사용자(키 소유자) ID로 구성
- 공개키 인증서는 신뢰할 만한 제 3자가 서명한다.
- 제 3자: CA
서명 안된 인증서: 사용자 ID와 공개키
- 서명 안된 인증서의 해시코드 생성
- CA의 개인키로 해당 해시코드를 암호화
- 서명을 인증서에 추가 -> 수신자는 CA의 공개키로 서명을 확인할 수 있다.
공개키를 이용한 비밀키 분배
Diffie-Hellman 키 교환을 이용
두 통신자 사이에 인증을 제공하지 않음(중간자 공격)
<대안>
- 공개키 인증서 사용
- B는 A에게 보낼 메시지(M)를 준비
- B는 일회용 세션키(K)를 이용하는 관용암호 기법으로 메시지를 암호화(
E_K(M)) - B는 A의 공개키를 이용해서 그 세션키를 암호화(
E_puA(K)) - 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<<A>>로 표기되며, 이는 CA가 A라는 주체의 공개키에 CA 자신의 개인키로 서명한 것이다.
CA{I}: 서명된 해시코드와 I를 CA가 서명한 것.CA<<A>> == CA{인증서 구성요소}
■ 인증서의 특성
CA가 발행한 인증서는 다음과 같은 특성을 지닌다:
- CA의 공개키를 가진 사람은 다른 주체의 공개키를 확인할 수 있다.
- CA 외에는 인증서를 변경할 수 없다.
■ 인증서 체인
A가 B의 공개키를 얻으려면, 인증서 체인을 통해 확인할 수 있다.
예를 들어, A의 CA는 X1이며 X1<<X2>>, X2<<B>>와 같은 체인이 있을 때를 가정해보자.
- B의 공개키는 X2의 개인키로 서명되어 있음.
X2<<B>>- B의 공개키를 얻으려면 X2의 공개키가 필요.
X2<<B>>- X2의 공개키는 X1의 개인키로 서명되어 있음.
X1<<X2>>- X2의 공개키를 얻으려면 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 등을 사용하여 다중 서비스를 연계.
