[컴퓨터보안] 5. 사용자 인증

1. 사용자 인증과 인증 요소

사용자 인증(User Authentication)

시스템을 이용하려는 주체가 자신이 주장하는 신원과 일치하는지 확인하는 과정이다

예를 들어 사용자가 특정 계정의 아이디를 입력하는 것은 “나는 이 계정의 사용자다”라고 주장하는 것이다. 시스템은 비밀번호나 다른 인증 수단을 통해 그 주장이 맞는지 확인한다

여기서 인증 대상인 주체(Entitiy)는 사람뿐 아니라 장치나 프로세스 등일 수도 있다

1.1 식별, 인증, 인가의 구분

사용자가 시스템에 접근하는 과정에서는 식별, 인증, 인가를 구분해야 한다

구분	의미	예시
식별(Identification)	자신이 누구인지 제시한다	아이디 alice를 입력한다
인증(Authentication)	주장한 신원이 맞는지 확인한다	비밀번호를 검증한다
인가(Authorization)	해당 주체가 어떤 작업을 할 수 있는지 결정한다	성적 조회는 허용하고 성적 수정은 제한한다

인증으로 확인한 신원은 이후 접근 권한을 판단하는 기준이 된다

인증 성공과 접근 권한

인증에 성공했다고 모든 자원에 접근할 수 있는 것은 아니다. 누구인지 확인하는 과정과 무엇을 허용할지 결정하는 과정은 구분된다

1.2 사용자 인증의 네 가지 요소

사용자 인증 수단은 사용자가 알고 있는 것, 가지고 있는 것, 신체적 특성, 행동적 특성을 기준으로 구분할 수 있다

인증 요소	의미	예시
지식 기반	사용자가 알고 있는 정보	비밀번호, PIN
소유 기반	사용자가 가지고 있는 물건이나 장치	열쇠, 토큰, 스마트카드
신체적 특성 기반	사용자의 신체적 특징	지문, 망막
행동적 특성 기반	사용자의 행동에서 나타나는 특징	음성, 서명 동작

1.2.1 지식 기반 인증

사용자가 알고 있는 정보를 시스템에 제시하여 신원을 확인한다

대표적인 예는 비밀번호와 PIN이다. 별도의 장치 없이 사용할 수 있지만, 정보가 추측되거나 유출되면 다른 사람이 사용자를 사칭할 수 있다

1.2.2 소유 기반 인증

사용자가 특정 물건이나 장치를 가지고 있는지 확인한다

대표적인 예는 토큰과 스마트카드이다. 다만 물건을 가지고 있다는 사실만으로 실제 소유자의 신원까지 확실하게 확인되는 것은 아니다. 분실, 도난, 복제 가능성을 고려해야 한다. 따라서 카드와 PIN을 함께 사용하는 것처럼 다른 인증 요소와 결합할 수 있다

1.2.3 신체적 특성 기반 인증

사용자의 신체적 특징을 이용한다. 정적 생체 인식(Static Biometrics)이라고도 한다

예를 들어 지문이나 망막의 특징을 측정하여, 미리 등록된 정보와 비교한다

1.2.4 행동적 특성 기반 인증

사용자의 행동에서 나타나는 특징을 이용한다. 동적 생체 인식(Dynamic Biometrics)이라고도 한다

예를 들어 서명할 때의 움직임이나 음성의 특징을 활용할 수 있다. 단순히 서명 이미지의 모양만 보는 것과 서명 과정의 움직임을 측정하는 것은 구분해야 한다

1.3 인증 요소의 결합

각 인증 수단은 단독으로 사용하거나 여러 요소를 결합하여 사용할 수 있다

사용 예시	사용되는 요소
비밀번호	지식
스마트카드	소유
지문	신체적 특성
스마트카드 + PIN	소유 + 지식
비밀번호 + 지문	지식 + 신체적 특성

다중 요소 인증(Multi-Factor Authentication, MFA)

서로 다른 종류의 인증 요소를 두 가지 이상 결합하여 사용자를 인증하는 방식이다

예를 들어 카드가 도난당하더라도 PIN을 모르면 인증을 통과하기 어렵게 만들 수 있다

비밀번호 두 개는 서로 다른 인증 요소가 아니다

비밀번호와 PIN은 모두 알고 있는 정보에 해당한다. 두 가지를 사용하더라도 서로 다른 종류의 요소를 결합한 것은 아니다

1.4 인증 수단의 한계

모든 인증 수단에는 약점이 있으며, 어떤 수단을 사용한다고 해서 문제가 완전히 사라지는 것은 아니다

인증 요소	주요 한계
지식	추측, 유출, 망각
소유	분실, 도난, 복제
신체적 특성	측정 오차, 잘못된 일치·불일치 판정
행동적 특성	상황에 따른 변화, 측정 오차

따라서 인증 방식을 선택할 때는 보안성뿐 아니라 사용 편의성, 비용, 오류 가능성도 함께 고려해야 한다

---

2. 비밀번호 인증과 공격, 대응 방법

2.1 비밀번호 인증의 기본 원리

비밀번호 인증(Password Authentication)

사용자가 제시한 계정 식별자와 비밀번호를 이용하여, 해당 계정의 사용자인지 확인하는 지식 기반 인증 방식이다

사용자는 아이디와 비밀번호를 입력하고, 시스템은 해당 계정에 저장된 검증 정보와 비교하여 인증 여부를 결정한다

인증된 계정의 신원은 이후 시스템 접근 허용 여부와 사용자 권한을 판단하는 기준이 된다. 재량적 접근 제어(DAC)에서도 이러한 사용자 신원을 바탕으로 자원에 대한 접근을 통제한다

2.2 해시를 이용한 비밀번호 저장과 검증

비밀번호를 평문으로 저장하면 비밀번호 파일이 유출될 때 원래 비밀번호가 그대로 드러난다. 이를 줄이기 위해 비밀번호 자체 대신 비밀번호로부터 계산한 해시값을 저장한다

2.2.1 비밀번호 등록

1. 사용자가 비밀번호를 설정한다
2. 시스템이 솔트(Salt)를 생성한다
3. 비밀번호와 솔트를 이용하여 비밀번호 해시값을 계산한다
4. 사용자 식별자, 솔트, 해시값을 저장한다

이를 간단히 나타내면 다음과 같다

$v=F(P,s)$

기호	의미
$P$	비밀번호
$s$	솔트
$F$	비밀번호 해시 함수
$v$	저장할 검증값

2.2.2 로그인 시 검증

1. 입력한 아이디에 해당하는 솔트와 검증값을 조회한다
2. 입력한 비밀번호 $P^{\prime }$와 저장된 솔트로 검증값을 다시 계산한다
3. 계산 결과와 저장된 검증값을 비교한다

$F(P^{\prime },s)\stackrel{?}{=}v$

두 값이 일치하면 비밀번호 검증에 성공한다. 저장된 해시값을 복호화하여 원래 비밀번호를 알아내는 과정은 필요하지 않다

2.3 솔트의 역할

솔트(Salt)

비밀번호 해시를 계산할 때 비밀번호와 함께 사용하는 부가 값이다. 사용자별로 서로 다른 솔트를 사용하면 동일한 비밀번호도 서로 다른 저장값을 갖게 할 수 있다

예를 들어 두 사용자가 같은 비밀번호를 사용하더라도 솔트가 다르면 일반적으로 서로 다른 해시값이 생성된다.

$F(P,s_A)\ne F(P,s_B)$

솔트의 주요 역할은 다음과 같다

• 같은 비밀번호를 사용하는 계정들이 저장값만으로 쉽게 드러나는 것을 줄인다
• 하나의 사전 계산 결과를 여러 계정에 재사용하기 어렵게 한다
• 공격자가 서로 다른 솔트에 대해 별도로 계산하도록 만든다

솔트는 비밀키가 아니다

솔트는 해시값과 함께 저장해도 된다. 솔트의 목적은 비밀을 추가하는 것이 아니라 사전 계산과 계산 결과의 재사용을 어렵게 하는 것이다. 솔트를 알아도 공격자는 비밀번호 후보를 대입하여 추측할 수 있다

2.4 전통적인 UNIX 비밀번호 구현

전통적인 UNIX 비밀번호 저장 방식은 DES를 변형하여 비밀번호 검증값을 생성한다

항목	내용
비밀번호 입력	최대 8문자에서 각 문자당 7비트를 사용
키 길이	총 56비트
솔트	12비트
내부 연산	솔트로 변형한 DES 연산
반복 횟수	0으로 이루어진 블록을 시작으로 25회 반복 암호화
출력	계산 결과를 11문자 문자열로 변환

비밀번호로부터 만든 키와 솔트를 이용하여 검증값을 계산하고, 로그인할 때 같은 과정을 수행하여 결과를 비교한다

12비트 솔트가 가질 수 있는 값은 다음과 같다

$2^{12}=4096$

이 방식은 짧은 비밀번호 길이와 제한된 솔트 공간, 상대적으로 적은 계산량이라는 한계가 있다

그림 1.솔트를 이용한 UNIX 비밀번호 검증값의 등록과 로그인 시 비교 과정

2.5 반복 계산을 이용한 구현

비밀번호 추측 공격의 비용을 높이기 위해서는 솔트뿐 아니라 각 후보를 검증하는 데 필요한 계산량도 늘릴 수 있다

MD5 기반 구현의 특징은 다음과 같다

항목	내용
솔트	48비트
비밀번호 길이	기존 8문자 제한을 제거
반복 계산	내부 반복 연산 1,000회
해시 출력	128비트

핵심은 솔트 공간을 늘리고 계산을 반복하여 공격자의 후보 대입 비용을 높이는 것이다. 다만 이 수치는 해당 구현을 설명하는 값이며, 모든 비밀번호 저장 방식에 공통으로 적용되는 것은 아니다

과거 구현 예시와 안전한 설계의 구분

전통적인 DES 기반 방식과 여기서 소개한 MD5 기반 방식은 과거의 구현 예시다. 일반 해시를 한 번 적용하거나 솔트만 추가했다고 해서 비밀번호가 안전하게 저장되는 것은 아니다

2.6 비밀번호 추측 공격

2.6.1 사전 공격

사전 공격(Dictionary Attack)

사람들이 사용할 가능성이 높은 단어와 그 변형을 비밀번호 후보로 대입하는 공격이다

공격자는 사전에 있는 단어뿐 아니라 숫자 추가, 대소문자 변경, 문자 치환 등의 변형도 시도한다

예를 들면 다음과 같다

• password
• Password1
• password123
• P@ssword

따라서 단어에 숫자나 특수문자를 조금 추가하는 것만으로 추측 가능성이 충분히 낮아지는 것은 아니다

2.6.2 레인보 테이블 공격

레인보 테이블 공격(Rainbow Table Attack)

해시 계산을 미리 수행해 만든 압축된 테이블을 이용하여, 주어진 해시값에 대응하는 비밀번호 후보를 찾는 공격이다

공격할 때마다 모든 후보의 해시를 새로 계산하는 대신 미리 수행한 계산 결과를 활용한다

서로 다른 솔트는 서로 다른 계산을 요구하므로, 충분히 큰 솔트 공간을 사용하면 모든 솔트를 대상으로 테이블을 미리 만드는 것이 어려워진다. 단, 솔트는 각 후보를 그때그때 계산하는 사전 공격 자체를 막지는 못한다

2.6.3 온라인 공격과 오프라인 공격

구분	온라인 공격	오프라인 공격
공격 대상	실제 로그인 서비스	탈취한 비밀번호 해시 파일
시도 방법	서버에 로그인 요청을 보낸다	공격자 환경에서 후보를 계산·비교한다
서버의 시도 제한	적용할 수 있다	직접 적용할 수 없다
주요 대응	시도 제한, 계정 잠금, 탐지	파일 보호, 솔트, 계산 비용이 높은 저장 방식

계정 잠금의 적용 범위

계정 잠금은 서버에 로그인 요청을 보내는 공격을 제한한다. 이미 해시 파일을 탈취한 공격자가 자신의 환경에서 수행하는 오프라인 추측은 막지 못한다

2.7 비밀번호 인증의 주요 취약점

취약점	설명
오프라인 사전 공격	탈취한 해시값에 비밀번호 후보를 대입한다
특정 계정 공격	하나의 계정을 대상으로 여러 비밀번호를 시도한다
흔한 비밀번호 공격	소수의 흔한 비밀번호를 여러 계정에 시도한다
특정 사용자에 대한 추측	이름, 생일, 관심사 등 개인 정보를 이용하여 추측한다
워크스테이션 탈취	사용자가 로그인한 상태로 자리를 비운 컴퓨터를 이용한다
사용자 실수 악용	비밀번호를 적어 두거나 속아서 알려 주는 행동을 악용한다
비밀번호 재사용 악용	다른 서비스에서 유출된 비밀번호를 동일 사용자의 계정에 대입한다
전자적 감시	통신 도청이나 입력 감시 등을 통해 비밀번호를 수집한다

사용자가 짧거나 추측하기 쉬운 비밀번호를 선택하는 것도 중요한 문제다. 공격자는 가능한 모든 문자열을 무작정 시도하기보다, 성공 가능성이 높은 후보부터 대입할 수 있다

2.8 공격에 대한 대응 방법

대응 방법	목적
비밀번호 파일 접근 제한	공격자가 해시 파일을 확보하기 어렵게 한다
침입 탐지	비정상적인 로그인 시도와 공격 징후를 탐지한다
계정 잠금, 시도 제한	반복적인 온라인 추측을 제한한다
추측하기 어려운 비밀번호 정책	흔한 비밀번호와 쉽게 예상되는 패턴을 줄인다
사용자 교육과 정책 시행	비밀번호 노출과 재사용 등의 실수를 줄인다
자동 로그아웃, 화면 잠금	자리를 비운 사용자의 세션이 악용되는 것을 줄인다
암호화된 통신 연결	전송 중 비밀번호가 도청되는 것을 줄인다

각 대응책은 적용 범위가 다르므로 함께 사용해야 한다. 예를 들어 통신을 암호화해도 서버에 저장된 해시 파일의 유출까지 막을 수 있는 것은 아니다

2.9 비밀번호 파일의 접근 통제

2.9.1 섀도 비밀번호 파일

섀도 비밀번호 파일(Shadow Password File)

비밀번호 해시 등 민감한 인증 정보를 일반 계정 정보와 분리하여 저장하고, 권한이 있는 사용자나 프로세스만 접근하도록 제한한 파일이다

해시 파일에 대한 접근을 차단하면 공격자가 검증값을 확보하여 오프라인 추측을 수행하기 어려워진다

2.9.2 접근 통제의 한계

비밀번호 파일을 보호하더라도 다음 경로로 인증 정보가 노출될 수 있다

• 운영체제 취약점 악용
• 잘못된 파일 권한 설정
• 보호되지 않은 백업 매체
• 같은 비밀번호를 사용하는 다른 시스템의 침해
• 보호되지 않은 네트워크 통신 도청

따라서 비밀번호 저장 방식, 파일 권한, 백업 보호, 통신 보호, 사용자 행동을 함께 관리해야 한다

---

3.2 비밀번호 선택을 개선하는 방법

3.2.1 사용자 교육

사용자에게 안전한 비밀번호 선택과 관리 방법을 안내한다

이름이나 생일처럼 쉽게 알 수 있는 정보, 흔한 단어, 단순한 반복 패턴 등을 피하도록 교육할 수 있다. 다만 교육만으로 모든 사용자가 적절한 비밀번호를 선택한다고 보장할 수는 없다

3.2.2 컴퓨터 생성 비밀번호

시스템이 비밀번호를 생성하면 사용자가 흔한 단어나 개인 정보를 선택하는 문제를 줄일 수 있다

그러나 기억하기 어려운 비밀번호가 제공되면 사용자가 이를 적어 두는 등 다른 문제가 발생할 수 있다

3.2.3 사후 비밀번호 검사

사후 비밀번호 검사(Reactive Password Checking)

이미 설정된 비밀번호에 대해 추측 공격 등을 수행하여 취약한 비밀번호를 찾아내는 방법이다

취약한 비밀번호가 발견되면 사용자에게 변경을 요구한다

다만 검사에 시간과 계산 자원이 필요하며, 취약한 비밀번호가 발견되고 변경되기 전까지 사용될 수 있다

3.2.4 사전 비밀번호 검사

사전 비밀번호 검사(Proactive Password Checking)

사용자가 비밀번호를 설정하거나 변경할 때 취약한 비밀번호인지 미리 검사하여 거부하는 방법이다

취약한 비밀번호가 처음부터 등록되지 않도록 한다는 점에서 사후 검사와 구분된다

3.3 사전 비밀번호 검사의 방법

3.3.1 규칙 적용과 사용자 안내

길이와 문자 구성 등의 규칙을 적용하고, 선택이 거부된 이유를 사용자에게 안내할 수 있다

예를 들어 일정 길이 이상을 요구하거나 대문자·소문자·숫자·특수문자의 조합을 검사할 수 있다. 그러나 형식적인 조건을 만족해도 Password1!처럼 쉽게 예상할 수 있는 비밀번호가 만들어질 수 있다

따라서 문자 종류가 다양하다는 사실만으로 추측하기 어려운 비밀번호라고 판단해서는 안 된다

3.3.2 비밀번호 크래커 활용

비밀번호 크래커가 사용하는 사전과 변형 규칙 등을 이용하여, 선택한 비밀번호가 쉽게 추측되는지 검사한다

다만 큰 사전과 많은 변형을 검사하면 처리 시간과 저장 공간이 문제가 될 수 있다

3.3.3 블룸 필터 활용

흔한 비밀번호 목록을 작은 공간에 표현하고, 사용자가 선택한 비밀번호가 그 목록에 포함될 가능성이 있는지 빠르게 검사한다

3.4 블룸 필터의 개념과 구성

블룸 필터(Bloom Filter)

비트 배열과 여러 해시 함수를 이용하여, 어떤 값이 집합에 포함되는지 확률적으로 검사하는 자료구조이다

비밀번호 검사에서는 사용을 제한할 흔한 비밀번호 집합을 표현하는 데 사용할 수 있다

기호	의미
$N$	비트 배열의 크기
$D$	등록할 비밀번호 수
$k$	해시 함수의 수
$H_1,\dots ,H_k$	각 비밀번호를 비트 위치로 변환하는 해시 함수

각 해시 함수는 비밀번호를 다음 범위의 위치로 대응시킨다

$H_i(x)\in \{0,1,\dots ,N-1\}$

블룸 필터는 비밀번호별 해시값을 개별 항목으로 저장하는 대신, 여러 비밀번호가 하나의 비트 배열을 공유한다

3.5 블룸 필터 생성 과정

1. $N$비트 배열을 만들고 모든 비트를 0으로 초기화한다
2. 제한할 비밀번호 $D$개를 준비한다
3. 각 비밀번호에 대해 $k$개의 해시값을 계산한다
4. 계산된 위치의 비트를 모두 1로 설정한다

비밀번호 (x)를 등록할 때의 연산은 다음과 같다

$B[H_i(x)]\leftarrow 1(i=1,\dots ,k)$

이미 1인 비트는 그대로 1로 유지한다. 다시 0으로 바꾸는 토글 연산이 아니다

3.5.1 등록 예시

비트 배열의 크기가 (N=15), 해시 함수 수가 (k=3), 등록할 비밀번호 수가 (D=3)이라고 하자

배열의 인덱스를 0부터 14까지로 정하면, 예제의 등록 위치는 다음과 같다

비밀번호	세 해시 함수가 가리키는 위치
(X)	1, 4, 9
(Y)	4, 8, 11
(Z)	9, 11, 14

등록 후 1이 되는 위치는 다음과 같다

$\{1,4,8,9,11,14\}$

총 9번의 비트 설정을 수행하지만, 여러 해시 결과가 같은 위치를 가리키므로 1인 비트는 6개다

그림 2. 세 비밀번호의 해시 결과를 15비트 배열에 등록하는 과정

3.6 새 비밀번호 검사 과정

사용자가 새 비밀번호 $w$를 제시하면 다음 순서로 검사한다

1. 등록할 때와 동일한 $k$개의 해시 함수로 위치를 계산한다
2. 해당 위치의 비트들을 확인한다
3. 모든 비트가 1이면 비밀번호를 거부한다
4. 하나라도 0이면 제한 목록에 없다고 판단한다

검사 결과	집합 포함 여부의 해석	비밀번호 검사에서의 처리
하나라도 0	등록된 집합에 확실히 없다	이 검사를 통과한다
모두 1	등록된 집합에 있을 가능성이 있다	거부한다

블룸 필터를 통과하더라도 길이 등 다른 비밀번호 정책은 별도로 만족해야 한다

3.7 오탐과 미탐

오탐(False Positive)

실제로 집합에 없는 값을 집합에 있을 가능성이 있다고 판정하는 오류다. 비밀번호 검사에서는 제한 목록에 없는 비밀번호를 거부하는 결과로 나타난다

3.7.1 오탐이 발생하는 이유

등록되지 않은 비밀번호라도, 그 해시 위치들이 다른 비밀번호를 등록하면서 모두 1이 되었을 수 있다

앞의 배열에서 등록하지 않은 비밀번호 (W)의 해시 위치가 다음과 같다고 하자

$H_1(W)=1,H_2(W)=8,H_3(W)=14$

세 위치가 모두 1이므로 (W)는 거부된다. 그러나 (W) 자체는 등록된 비밀번호가 아니다

3.7.2 기본 블룸 필터의 오류 특성

구분	의미	발생 여부
오탐(False Positive)	미등록 값을 등록된 값일 가능성이 있다고 판단	발생할 수 있다
미탐(False Negative)	등록된 값을 미등록 값이라고 판단	기본 블룸 필터에서는 발생하지 않는다

등록된 비밀번호가 가리키는 비트는 이미 모두 1로 설정되어 있으므로, 정상적으로 유지된 배열에서는 등록된 값을 놓치지 않는다

‘목록에 없음’과 ‘안전함’의 구분

블룸 필터가 비밀번호를 통과시켰다는 것은 등록한 제한 목록에 없다는 뜻이다. 그 비밀번호가 안전하거나 추측하기 어렵다는 사실까지 보장하지는 않는다

3.8 오탐 확률

해시 결과가 균등하고 독립적이라고 가정하면, 특정 비트가 등록 과정 이후에도 0일 확률은 다음과 같다

${\left(1-\frac{1}{N}\right)}^{kD}\approx e^{-kD/N}$

따라서 특정 비트가 1일 확률은 대략 다음과 같다

$1-e^{-kD/N}$

미등록 비밀번호가 가리키는 (k)개 위치가 모두 1일 확률, 즉 오탐 확률은 다음과 같이 근사한다

$P_{\mathrm{FP}}\approx {\left(1-e^{-kD/N}\right)}^k$

비밀번호 하나당 할당된 비트 수를 다음과 같이 정의하면

$R=\frac{N}{D}$

공식을 다음처럼 표현할 수 있다

$\boxed{P_{\mathrm{FP}}\approx {\left(1-e^{-k/R}\right)}^k}$

3.8.1 계산 예시

앞의 예시에서 $N=15$, $D=3$, $k=3$이므로

$R=\frac{15}{3}=5$ $P_{\mathrm{FP}}\approx (1-e^{-3/5}{)}^3\approx 0.0918$

따라서 공식으로 추정한 오탐 확률은 약 9.2%다. 이는 무작위 해시 모델의 근사값이며, 특정 배열에서 실제로 관찰한 오탐률과 반드시 같지는 않다

3.9 공간과 해시 함수 수의 영향

3.9.1 비트 배열의 크기

등록할 비밀번호 수 $D$와 해시 함수 수 $k$가 같다면, 배열 크기 $N$이 커질수록 비트가 덜 채워진다. 따라서 비밀번호 하나당 비트 수 $R=N/D$가 커질수록 오탐 확률이 낮아진다

반대로 같은 배열에 더 많은 비밀번호를 등록하면 1인 비트가 많아져 오탐 가능성이 커진다

3.9.2 해시 함수의 수

해시 함수 수를 늘리면 검사할 위치가 많아지지만, 등록할 때도 더 많은 비트를 1로 만든다. 따라서 해시 함수가 많을수록 항상 좋은 것은 아니다. 주어진 배열 크기와 등록 항목 수에 맞는 값을 선택해야 한다

그림 3. 비밀번호당 비트 수와 해시 함수 수에 따른 블룸 필터의 오탐 확률

그래프의 가로축은 $R=N/D$, 세로축은 오탐 확률의 로그 눈금이다. 곡선이 교차하므로 해시 함수 수에 따른 성능이 $R$에 따라 달라진다는 점도 확인할 수 있다

---

4. 토큰 기반 인증

4.1 토큰 기반 인증의 개념

토큰 기반 인증(Token Authentication)

사용자가 소유하고 있는 물건이나 장치를 이용하여 신원을 확인하는 인증 방식이다

대표적인 예로 자기 띠 카드, 메모리 카드, 스마트카드가 있다

토큰에 저장된 정보를 읽어 인증하거나, 토큰이 인증 프로토콜에 참여하여 필요한 연산을 수행할 수 있다

종류	주요 특징
자기 띠 카드	자기 띠에 정보를 저장한다
메모리 카드	전자 메모리에 정보를 저장하지만 자체적인 데이터 처리는 하지 않는다
스마트카드	메모리와 프로세서를 갖추고 인증에 필요한 연산을 수행한다

4.2 자기 띠 카드

자기 띠 카드(Magnetic Stripe Card)

카드의 자기 띠에 있는 미세한 자성 입자의 자화 상태를 변화시켜 데이터를 저장하는 카드이다

리더기는 자기 띠에 기록된 정보를 읽어 카드와 관련된 계정 등을 식별한다

저장되는 정보에는 다음과 같은 항목이 포함될 수 있다

• 이름
• 카드 번호 또는 계좌 번호
• 유효기간
• 서비스 코드
• 카드 검증용 코드

카드 검증용 코드는 자기 띠에 기록된 값과 카드 표면에 인쇄된 보안 코드가 구분될 수 있다

자기 띠 카드는 정보를 저장하는 역할을 하며, 자체 프로세서로 암호 연산이나 인증 프로토콜을 수행하지 않는다. 저장 기능을 기준으로 보면 넓은 의미의 메모리 카드에 포함할 수 있다

4.3 메모리 카드

메모리 카드(Memory Card)

EEPROM이나 플래시 메모리 등에 데이터를 저장하지만, 자체적으로 데이터를 처리하는 프로세서를 갖추지 않은 카드이다

핵심적인 특징은 정보를 저장하는 기능과 처리하는 기능의 구분이다. 메모리 카드에서는 외부 리더기나 컴퓨터가 저장된 정보를 읽고 처리한다

4.3.1 사용 방식

사용 방식	예시
카드 단독 사용	출입 통제에서 카드 소지 여부를 확인
카드와 비밀번호, PIN 결합	카드 정보를 읽고 PIN을 추가로 확인

카드와 PIN을 결합하면 소유 요소와 지식 요소를 함께 확인할 수 있다

4.3.2 한계

한계	설명
전용 리더기 필요	카드의 정보를 읽는 장치가 필요하다
분실·도난	다른 사람이 카드를 확보하여 악용할 수 있다
사용 불편	카드를 휴대하고 제시해야 한다
복제 가능성	저장된 정보를 복사하여 다른 카드에 재현할 수 있다

카드 소유와 실제 사용자 신원의 구분

카드에 저장된 정보만 확인하는 방식에서는 도난 카드나 복제 카드가 사용될 수 있다. 카드를 가지고 있다는 사실만으로 정당한 사용자라고 확신할 수는 없다

4.4 스마트카드

스마트카드(Smartcard)

프로세서, 메모리, 입출력 기능을 갖추어 데이터를 저장하고 인증에 필요한 연산을 수행할 수 있는 카드이다

일반적으로 신용카드와 비슷한 형태이며, 메모리 카드와 달리 카드 자체가 인증 프로토콜을 실행할 수 있다

4.4.1 구성 요소

구성 요소	역할
프로세서	프로그램과 인증 프로토콜을 실행한다
ROM	기본 프로그램 등 변경하지 않는 정보를 저장한다
EEPROM	전원이 꺼져도 유지해야 하는 키와 데이터를 저장한다
RAM	실행 중 필요한 임시 데이터를 저장한다
입출력 인터페이스	리더기나 컴퓨터와 통신한다
암호 연산 보조 프로세서	암호 연산을 지원한다. 카드에 따라 포함될 수 있다

4.4.2 접촉식과 비접촉식

방식	설명
접촉식	카드의 접점을 리더기에 연결하여 통신한다
비접촉식	무선 인터페이스로 리더기와 통신한다

접촉 방식은 통신 인터페이스의 구분이다. 비접촉식이라는 사실만으로 스마트카드인지 판단할 수는 없으며, 자체 처리 기능이 있는지도 구분해야 한다

4.4.3 인증 기능과 장점

스마트카드는 단순히 저장된 정보를 제공하는 것 외에 다음 기능을 수행할 수 있다

• 리더기나 컴퓨터와 인증 프로토콜 실행
• 암호화된 통신 지원
• 하드웨어 수준의 메모리 접근 보호
• 개인키 저장과 전자서명 생성

예를 들어 카드 내부에 개인키를 보관하고, 서명이 필요할 때 카드 안에서 서명 연산을 수행한 뒤 결과만 외부로 전달할 수 있다

스마트카드의 보안 기능

스마트카드는 키 보호와 암호 연산을 지원할 수 있지만, 모든 카드가 모든 기능을 제공하는 것은 아니다. 실제 보호 수준은 카드의 구현과 사용하는 인증 프로토콜에 따라 달라진다

4.5 메모리 카드와 스마트카드의 비교

비교 항목	메모리 카드	스마트카드
데이터 저장	가능	가능
자체 데이터 처리	하지 않음	가능
프로세서	없음	있음
인증 판단을 위한 처리	주로 외부 시스템에서 수행	카드도 프로토콜에 참여
카드 내부 암호 연산	지원하지 않음	지원 가능
개인키를 내부에 보관한 채 서명	자체 수행 불가	가능

두 카드의 핵심 차이는 저장 용량이나 외형이 아니라, 카드 자체에서 연산을 수행할 수 있는지이다

---

5. 생체 인증과 정확도

생체 인증(Biometric Authentication)

사용자의 신체적·행동적 특징을 측정하고 등록된 정보와 비교하여 신원을 확인하는 인증 방식이다

지문, 얼굴, 홍채, 음성 등에서 추출한 특징을 인증에 활용한다

비밀번호처럼 정보를 기억하거나 별도의 카드를 휴대할 필요를 줄일 수 있지만, 측정 환경과 사용자 상태에 따라 결과가 달라질 수 있다

5.1 생체 인증 시스템의 구성

구성 요소	역할
사용자 인터페이스(User Interface)	사용자 식별 정보와 생체 정보 입력을 받는다
생체 센서(Biometric Sensor)	지문이나 얼굴 등 생체 정보를 측정한다
특징 추출기(Feature Extractor)	측정한 정보에서 비교에 사용할 특징을 추출한다
저장소	등록된 사용자의 생체 특징 정보를 보관한다
특징 비교기(Feature Matcher)	입력된 특징과 저장된 특징을 비교하여 결과를 판단한다

생체 템플릿(Biometric Template)

생체 정보에서 추출하여 등록·비교에 사용하는 특징 표현이다. 반드시 지문이나 얼굴의 원본 이미지 자체를 뜻하는 것은 아니다

생체 인증 시스템의 동작은 등록, 검증, 식별로 나눌 수 있다

5.2 생체 정보 등록

등록 과정은 다음과 같다

1. 사용자의 이름이나 식별 정보를 입력한다
2. 센서로 생체 정보를 측정한다
3. 측정한 정보에서 특징을 추출한다
4. 사용자 식별 정보와 연결하여 템플릿을 저장한다

이후 인증에서는 새로 측정한 특징을 이 템플릿과 비교한다

5.3 검증과 식별

5.3.1 검증

사용자가 주장한 신원에 해당하는 하나의 템플릿과 입력 정보를 비교하여, 그 사용자가 맞는지 확인하는 과정이다

예를 들어 사용자가 “나는 Alice다”라고 계정을 제시하면, 시스템은 새로 입력한 지문을 Alice의 등록 템플릿과 비교한다

1. 사용자가 계정 등 식별 정보를 제시한다
2. 새 생체 정보를 측정하고 특징을 추출한다
3. 해당 계정의 템플릿 하나를 조회한다
4. 두 특징을 비교하여 일치 여부를 판단한다

비교 방식은 1:1 비교다

5.3.2 식별

입력된 생체 정보를 여러 사용자의 템플릿과 비교하여, 누구의 정보인지 찾는 과정이다

사용자가 특정 계정을 먼저 제시하지 않고 지문을 입력하면, 시스템은 등록된 여러 템플릿에서 일치하는 사용자를 찾는다

1. 생체 정보를 측정하고 특징을 추출한다
2. 등록된 여러 사용자의 템플릿과 비교한다
3. 일치하는 사용자의 신원을 반환하거나 식별 실패로 처리한다

비교 방식은 1:N 비교다. 여기서 $N$은 비교 대상 템플릿의 수다

5.3.3 검증과 식별의 비교

구분	검증	식별
확인하는 질문	“주장한 사용자가 맞는가?”	“이 사용자는 누구인가?”
신원 주장	먼저 제시한다	특정 신원을 먼저 제시하지 않는다
비교 대상	해당 사용자의 템플릿 하나	여러 사용자의 템플릿
비교 방식	1:1	1:N
결과	일치, 불일치	사용자 신원 또는 식별 실패

그림 4. 생체 정보의 등록과 1:1 검증, 1:N 식별 과정

5.4 생체 정보 비교의 특성

동일한 사람의 생체 정보라도 측정할 때마다 완전히 같은 결과가 나오지는 않는다

예를 들어 지문을 입력하는 각도나 압력, 얼굴을 촬영하는 조명과 자세 등이 달라질 수 있다. 따라서 비밀번호처럼 두 값이 완전히 동일한지 확인하는 방식만으로 판단하기 어렵다. 대신 특징 사이의 유사도를 계산하고, 기준을 만족하는지 확인한다

5.4.1 임계값을 이용한 판단

값이 클수록 더 유사한 유사도 점수 (S)를 사용한다고 하자. 임계값을 (T)라고 하면 다음과 같이 판단할 수 있다

$S\ge T\Rightarrow \text{일치로 판단}$ $S<T\Rightarrow \text{불일치로 판단}$

실제 시스템이 거리처럼 작을수록 유사한 값을 사용한다면 부등호 방향은 달라진다

5.5 잘못된 일치와 잘못된 불일치

생체 정보를 완벽하게 구분하기 어려우므로 두 종류의 오류가 발생할 수 있다

5.5.1 잘못된 일치

서로 다른 사람의 생체 정보를 같은 사람의 것으로 판단하는 오류다

예를 들어 다른 사람의 지문을 Alice의 등록 지문과 일치한다고 판단하는 경우다

잘못된 일치율(False Match Rate, FMR)은 다음과 같이 나타낼 수 있다

$\mathrm{FMR}=\frac{\text{다른 사람 간 비교에서 일치로 잘못 판단한 횟수}}{\text{다른 사람 간 비교 횟수}}$

5.5.2 잘못된 불일치

같은 사람의 생체 정보를 서로 다른 사람의 것으로 판단하는 오류다

예를 들어 Alice가 자신의 지문을 입력했는데, Alice의 등록 템플릿과 불일치한다고 판단하는 경우다

잘못된 불일치율(False Non-Match Rate, FNMR)은 다음과 같다

$\mathrm{FNMR}=\frac{\text{같은 사람 간 비교에서 불일치로 잘못 판단한 횟수}}{\text{같은 사람 간 비교 횟수}}$

5.5.3 두 오류의 비교

구분	잘못된 일치	잘못된 불일치
비교 대상의 실제 관계	다른 사람	같은 사람
잘못된 판단	같은 사람이라고 판단	다른 사람이라고 판단
주요 영향	타인의 인증 통과 가능성	정상 사용자의 인증 실패
오류율	FMR	FNMR

5.6 임계값과 오류율의 관계

같은 시스템에서 임계값을 조절하면 두 오류율 사이에 상충 관계가 나타난다

유사도 점수가 높을수록 일치한다고 판단하는 방식에서는 다음과 같다

임계값 조정	판단 기준	FMR	FNMR
임계값 상승	더 엄격하게 일치를 인정	감소	증가
임계값 하락	더 쉽게 일치를 인정	증가	감소

기준을 엄격하게 하면 타인을 잘못 받아들이는 경우가 줄지만, 정상 사용자를 거부하는 경우가 늘어난다

반대로 기준을 완화하면 정상 사용자는 쉽게 통과하지만, 타인을 잘못 받아들일 가능성이 커진다

두 오류율의 상충 관계

임계값 조절만으로 FMR과 FNMR을 동시에 낮출 수는 없다. 보안 요구와 사용 편의성을 고려하여 운영 기준을 정해야 한다

5.7 생체 인증 정확도 그래프

그림 5. 생체 인식 방식별 잘못된 일치율과 잘못된 불일치율의 관계

생체 인증의 성능은 서로 다른 임계값에서 측정한 FMR과 FNMR의 관계로 표현할 수 있다

그래프 요소	의미
가로축	잘못된 일치율(FMR)
세로축	잘못된 불일치율(FNMR)
곡선 위의 점	특정 임계값에서의 두 오류율
왼쪽 아래 방향	두 오류율이 모두 낮은 방향

이 그래프는 얼굴, 지문, 음성, 손, 홍채 시스템의 특정 측정 결과를 비교하며, 두 축 모두 로그 눈금이다. 따라서 눈금 간격을 일정한 퍼센트 차이로 읽으면 안 된다

그래프의 측정 결과와 일반적 우열

이 그래프만으로 특정 생체 인식 방식이 항상 가장 정확하다고 단정하면 안 된다. 성능은 센서, 알고리즘, 측정 환경과 운영 기준에 따라 달라진다

---

6. 원격 인증과 Needham-Schroeder 프로토콜

6.1 원격 사용자 인증의 위협

원격 사용자 인증(Remote User Authentication)

네트워크나 통신 회선을 통해 접속한 사용자가 주장하는 신원이 맞는지 확인하는 과정이다

원격 인증에서는 인증 정보가 통신망을 지나므로 다음 위협을 고려해야 한다

위협	설명
도청(Eavesdropping)	통신 중인 인증 정보를 관찰한다
비밀번호 탈취	전송되는 비밀번호를 확보하여 사용자를 사칭한다
재전송 공격(Replay Attack)	이전에 관찰한 인증 메시지를 다시 보내 인증을 통과하려 한다

암호화된 메시지라도 공격자가 복사하여 다시 보낼 수 있다. 따라서 메시지의 내용을 보호하는 것과 이번 인증에서 생성된 메시지인지 확인하는 것을 구분해야 한다

6.2 도전, 응답과 논스

6.2.1 도전, 응답 방식

도전·응답(Challenge–Response)

검증자가 제시한 값에 대해 상대방이 비밀정보를 알아야 생성할 수 있는 응답을 보내도록 하는 인증 방식이다

검증자는 응답을 확인하여 상대방이 필요한 비밀정보를 가지고 있는지 판단한다

매번 다른 도전값을 사용하고 응답을 해당 도전값과 연결하면, 과거 응답을 그대로 재사용하는 공격을 방지할 수 있다

6.2.2 논스의 역할

논스(Nonce)

프로토콜에서 한 번만 사용하도록 생성하는 값이다. 난수나 순차적인 값 등을 사용할 수 있으며, 메시지를 특정 실행과 연결하여 신선성을 확인하는 데 사용한다

예를 들어 이번 도전값이 $N$이라면, 상대방에게 $N$에 대응하는 암호학적 응답을 요구한다. 검증자는 자신이 보낸 값과 응답의 관계를 확인한다

논스의 포함과 검증

메시지에 논스를 넣는 것만으로 재전송 공격이 방지되는 것은 아니다. 기대한 논스와 일치하는지 확인하고, 해당 응답이 올바르게 보호되었는지 검증해야 한다

6.3 키 분배 센터

키 분배 센터(Key Distribution Center, KDC)

통신 참여자들이 신뢰하는 제3자로서, 참여자 사이에서 사용할 세션키를 분배하는 기관이다

Alice와 Bob이 직접 공유한 키가 없더라도, 각각 KDC와 비밀키를 공유하고 있다면 KDC를 통해 세션키를 전달받을 수 있다

6.3.1 키와 표기법

기호	의미	키를 아는 주체
$K_A$	Alice와 KDC의 장기 비밀키	Alice, KDC
$K_B$	Bob과 KDC의 장기 비밀키	Bob, KDC
$K_{AB}$	Alice와 Bob의 통신에 사용할 세션키	Alice, Bob, 이를 생성한 KDC
$\{X{\}}_K$	키 $K$로 암호화한 내용 $X$	—

여기서 $K_A$와 $K_B$는 대칭키인 비밀키다. 공개키와 짝을 이루는 개인키가 아니다

6.3.2 티켓의 개념

티켓(Ticket)

KDC가 특정 수신자를 위해 생성한 암호화된 정보다. 해당 수신자가 KDC와 공유하는 키로 보호하며, 세션키와 통신 상대의 신원 등을 포함한다

Bob에게 전달할 티켓은 다음처럼 표현할 수 있다

$T_B=\{K_{AB},A{\}}_{K_B}$

Alice는 이 티켓을 Bob에게 전달하지만, $K_B$를 모르므로 티켓 내부를 직접 복호화할 수 없다

Bob은 자신의 비밀키 $K_B$로 티켓을 열어 세션키 $K_{AB}$와 상대방의 신원을 확인한다

6.4 기본 Needham–Schroeder 프로토콜

Needham–Schroeder의 대칭키 프로토콜은 KDC를 통한 키 분배와 인증을 결합한다. 여기서는 논스를 이용하는 다음 메시지 흐름을 살펴본다

6.4.1 전체 메시지 흐름

$T_B=\{K_{AB},A{\}}_{K_B}$

단계	방향	메시지
1	Alice → KDC	$N_1,A,B$
2	KDC → Alice	$\{N_1,B,K_{AB},T_B{\}}_{K_A}$
3	Alice → Bob	$T_B,\{N_2{\}}_{K_{AB}}$
4	Bob → Alice	$\{N_2-1,N_3{\}}_{K_{AB}}$
5	Alice → Bob	$\{N_3-1{\}}_{K_{AB}}$

6.4.2 단계별 동작

1. Alice가 세션키를 요청한다

• Alice는 논스 $N_1$을 생성하고, 자신과 통신 상대인 Bob의 식별자를 KDC에 보낸다

2. KDC가 세션키와 티켓을 전달한다

• KDC는 세션키 $K_{AB}$와 Bob용 티켓 $T_B$를 생성한다. 이를 $N_1$, Bob의 식별자와 함께 Alice의 비밀키 $K_A$로 암호화한다
• Alice는 복호화한 뒤 논스가 자신이 보낸 $N_1$인지, 상대가 Bob인지 확인하고 세션키를 얻는다

3. Alice가 Bob에게 티켓과 도전값을 보낸다

• Alice는 Bob용 티켓과 세션키로 암호화한 $N_2$를 보낸다
• Bob은 $K_B$로 티켓을 복호화하여 $K_{AB}$를 얻고, 이 키로 $N_2$를 확인한다

4. Bob이 응답하면서 새로운 도전값을 보낸다

• Bob은 $N_2-1$과 자신이 생성한 논스 $N_3$를 세션키로 암호화하여 보낸다
• Alice는 $N_2-1$을 확인하여 상대방이 세션키를 가지고 있음을 확인한다

5. Alice가 Bob의 도전값에 응답한다

• Alice는 $N_3-1$을 세션키로 암호화하여 보낸다. Bob은 이를 확인하여 상대방이 세션키를 가지고 있음을 확인한다
• 여기서 1을 빼는 연산 자체가 보안을 제공하는 것은 아니다. 도전값에 대응하는 응답을 세션키로 보호하고 검증하는 것이 핵심이다

6.5 기본 방식의 재전송 취약점

기본 방식에서 Alice는 $N_1$을 통해 KDC 응답이 자신의 요청에 대응하는지 확인한다. 그러나 Bob에게 전달되는 티켓은 다음 정보만 포함한다

$T_B=\{K_{AB},A{\}}_{K_B}$

티켓 안에는 Bob이 이번 실행에서 생성한 값이 없다. 따라서 Bob은 티켓만 보고 세션키가 이번 통신을 위해 새로 발급되었는지 확인하기 어렵다

6.5.1 과거 세션키가 유출된 경우

공격자가 과거 티켓과 그 티켓에 해당하는 세션키 $K_{\text{old}}$를 확보했다고 하자

1. 공격자가 과거 티켓을 Bob에게 다시 보낸다
2. 공격자는 알고 있는 (K_{\text{old}})로 새로운 도전값을 암호화하여 함께 보낸다
3. Bob이 과거 티켓을 받아들이면 이전 세션키를 사용하게 된다
4. 공격자는 그 키를 알고 있으므로 Bob의 도전에 응답하여 Alice를 사칭할 수 있다

논스가 있어도 남는 취약점

기본 방식에도 논스가 있지만, Bob이 받은 티켓의 신선성까지 보장하지는 않는다. 과거 세션키가 유출되면 해당 키로 새로운 도전에 응답할 수 있어, 단순한 도전·응답만으로는 이 공격을 막지 못한다

6.6 확장 Needham–Schroeder 프로토콜

확장 방식에서는 Bob이 생성한 새로운 논스 (N_B)를 KDC가 발급하는 티켓에 포함한다

6.6.1 전체 메시지 흐름

확장 티켓을 다음과 같이 정의한다

$T_B^{\prime }=\{K_{AB},A,N_B{\}}_{K_B}$

단계	방향	메시지
1	Alice → Bob	통신 요청
2	Bob → Alice	$\{N_B{\}}_{K_B}$
3	Alice → KDC	$N_1,A,B,\{N_B{\}}_{K_B}$
4	KDC → Alice	$\{N_1,B,K_{AB},T_B^{\prime }{\}}_{K_A}$
5	Alice → Bob	$T_B^{\prime },\{N_2{\}}_{K_{AB}}$
6	Bob → Alice	$\{N_2-1,N_3{\}}_{K_{AB}}$
7	Alice → Bob	$\{N_3-1{\}}_{K_{AB}}$

6.6.2 Bob의 논스 전달

Bob은 새 논스 $N_B$를 생성하고, KDC와 공유하는 키 $K_B$로 암호화하여 Alice에게 보낸다

Alice는 이를 직접 복호화하지 않고 암호문 그대로 KDC에 전달한다

KDC는 $K_B$를 알고 있으므로 $N_B$를 복호화할 수 있다

6.6.3 논스를 포함한 티켓 발급

KDC는 새로운 세션키와 Alice의 신원, Bob의 논스 $N_B$를 티켓에 포함한다

Bob은 전달받은 티켓을 복호화한 뒤, 내부의 $N_B$가 자신이 이번 통신 요청에 대해 생성한 값인지 확인한다

과거 티켓에는 이번 $N_B$가 없으므로 이를 재전송해도 해당 검사를 통과하지 못한다

6.6.4 세션키를 이용한 상호 확인

티켓을 확인한 뒤에는 $N_2$, $N_3$를 이용한 도전, 응답으로 양쪽이 세션키를 가지고 있는지 확인한다

논스	주요 역할
$N_1$	Alice가 KDC의 응답을 자신의 요청과 연결
$N_B$	Bob이 티켓을 이번 실행과 연결
$N_2$	Alice가 상대방의 세션키 보유 여부 확인
$N_3$	Bob이 상대방의 세션키 보유 여부 확인

6.7 기본 방식과 확장 방식의 비교

비교 항목	기본 방식	확장 방식
KDC와 공유하는 장기 비밀키	사용	사용
Alice의 KDC 응답 확인	$N_1$ 사용	$N_1$ 사용
Bob용 티켓	$\{K_{AB},A{\}}_{K_B}$	$\{K_{AB},A,N_B{\}}_{K_B}$
Bob이 이번에 생성한 논스	티켓에 없음	티켓에 포함
과거 키 유출 시 티켓 재사용	취약	이번 $N_B$ 검사로 해당 공격 방지
메시지 수	5개	7개

확장 방식의 핵심은 메시지 수를 늘리는 것 자체가 아니라, Bob이 세션키와 티켓의 신선성을 확인할 근거를 추가하는 것이다

---

7. Kerberos와 EAP

7.1 Kerberos

Kerberos

MIT에서 개발한 신뢰할 수 있는 제3자 기반의 네트워크 인증·키 분배 시스템이다. 중앙 인증 서버를 이용하여 분산된 서비스에 접근하는 사용자의 신원을 확인한다

분산 클라이언트·서버 환경에서는 사용자가 여러 서버의 서비스를 이용한다. Kerberos는 이러한 환경에서 중앙의 신뢰 기관을 통해 인증을 제공한다

기본 구조는 대칭키를 사용하며, Needham–Schroeder의 대칭키 인증 프로토콜을 바탕으로 발전했다

7.2 중앙 인증 서버에 대한 신뢰

각 서비스가 모든 사용자 워크스테이션의 신원 주장을 그대로 믿는 대신, 중앙 인증 서버가 발급한 인증 정보를 검증하도록 한다

구성 요소	역할
클라이언트	사용자를 대신하여 인증을 요청하고 서비스에 접근한다
Kerberos 서버	인증과 서비스 이용에 필요한 티켓·세션키 발급을 담당한다
서비스 서버	티켓 등 인증 정보를 검증하고 서비스를 제공한다

환경에 따라 하나 이상의 Kerberos 서버를 둘 수 있다

중앙 신뢰의 의미

서비스 서버가 클라이언트의 주장만으로 신원을 인정하지 않고, 신뢰하는 인증 기관이 발급한 정보를 검증한다는 의미다. 사용자 단말이 침해되어도 안전하다는 뜻은 아니다

7.3 티켓을 이용한 인증의 기본 흐름

Kerberos는 티켓을 이용하여 사용자가 네트워크에 분산된 서비스를 이용하도록 한다. 개념적인 흐름은 다음과 같다

1. 클라이언트가 중앙 인증 기관을 통해 초기 인증을 수행한다
2. 필요한 서비스에 접근하기 위한 티켓과 세션키를 얻는다
3. 클라이언트가 서비스 서버에 티켓과 필요한 인증 정보를 제시한다
4. 서비스 서버가 이를 검증하여 사용자의 신원을 확인한다

티켓은 해당 서버가 검증할 수 있도록 보호된다. 클라이언트가 티켓을 전달하더라도 티켓 내부의 내용을 임의로 바꿀 수 있는 것은 아니다

또한 티켓을 복사한 사람이 이를 그대로 악용하지 못하도록, 티켓 외에 세션키 보유와 요청의 신선성을 확인하는 절차가 필요하다

7.3.1 Needham–Schroeder와의 관계

공통 개념	설명
신뢰하는 제3자	중앙 기관이 인증과 키 분배에 관여한다
장기 비밀키	중앙 기관과 참여자 사이의 보호에 사용한다
세션키	특정 통신에서 사용할 키를 분배한다
티켓	상대 서버가 검증할 수 있는 정보를 전달한다

Kerberos가 Needham–Schroeder를 바탕으로 한다고 해서 메시지 흐름이나 신선성 확인 방식이 완전히 같다는 뜻은 아니다

Kerberos에서는 타임스탬프와 티켓의 유효기간 등이 중요한 역할을 하므로, 앞의 논스 기반 메시지 흐름을 그대로 Kerberos의 동작으로 외우면 안 된다

7.3.2 버전 구분

Kerberos의 버전으로 버전 4와 버전 5가 소개된다. 두 버전이 있다는 사실과 별개로, 이를 모두 현재 사용을 권장하는 버전이라는 의미로 해석해서는 안 된다

7.4 EAP

EAP(Extensible Authentication Protocol)

여러 종류의 인증 방법을 사용할 수 있도록 공통적인 인증 메시지 교환 구조를 제공하는 확장 가능한 인증 프레임워크이다

EAP는 하나의 고정된 인증 알고리즘이 아니다. 실제로 어떤 자격 증명을 사용하고 어떻게 검증할지는 선택한 EAP 방식(EAP Method)에 따라 달라진다

예를 들어 인증서 기반 방식이나, 보호된 터널 안에서 사용자 인증을 수행하는 방식을 사용할 수 있다

7.5 EAP와 네트워크 접근 인증

EAP는 유선·무선 네트워크 접근 인증에 활용할 수 있다

관련 기술	관계
IEEE 802.3	유선 이더넷 환경
IEEE 802.11	무선 LAN 환경
IEEE 802.16	광대역 무선 접속 환경
IEEE 802.1X	네트워크 접근을 제어하는 인증 구조에서 EAP 사용

IEEE 802.1X와 EAP는 같은 개념이 아니다. 802.1X는 네트워크 접근 제어 구조를 제공하고, 그 안에서 EAP를 이용하여 인증 메시지를 교환할 수 있다

EAP의 키 관리 프레임워크와 관련된 문서로는 RFC 5247이 있다

7.6 대표적인 EAP 방식

방식	주요 특징
EAP-MD5	MD5 기반 도전·응답 방식이다. 상호 인증을 제공하지 않는다
EAP-TLS	TLS와 인증서를 이용하여 클라이언트와 서버의 상호 인증을 수행한다
EAP-TTLS	TLS 터널을 구성하고, 그 안에서 추가적인 사용자 인증을 수행한다
EAP-FAST	보호된 터널을 활용하는 인증 방식이다
PEAP	TLS로 보호된 터널 안에서 다른 인증 방식을 수행한다

이 밖에도 다양한 EAP 방식이 있으며, 방식마다 필요한 자격 증명과 보안 특성이 다르다

모든 EAP 방식이 공개키 기반 상호 인증을 제공하는 것은 아니다

EAP는 여러 인증 방식을 수용하는 프레임워크다. 공개키 사용 여부, 상호 인증 여부, 키 생성 기능은 선택한 방식에 따라 달라진다. 특히 EAP-MD5를 EAP-TLS와 같은 특성을 가진 방식으로 이해하면 안 된다

7.7 Kerberos와 EAP의 비교

비교 항목	Kerberos	EAP
성격	인증·키 분배 시스템	확장 가능한 인증 프레임워크
핵심 구조	신뢰하는 중앙 기관과 티켓	다양한 EAP 방식의 메시지 교환
암호 기술	기본 구조는 대칭키 기반	선택한 방식에 따라 다름
주요 활용	분산된 네트워크 서비스의 사용자 인증	유선·무선 네트워크 접근 인증
이해할 핵심	중앙 신뢰, 티켓, 세션키	프레임워크와 개별 인증 방식의 구분