인증 (Authentication)

인증 개념

• 인증 단계
  식별(Identification) 단계와 검증(Verification) 단계로 구성
  식별 : 어떤 시스템에 로그인하려면 먼저 자신이 누군지를 알림
  검증 : 로그인을 허용하기 위한 확인

• 인증 방법 4가지

1. 개인이 알고 있는 것 (Something the individual knows)
   -> 패스워드, PIN, 사전에 작성된 질의에 대한 응답 등

2. 개인이 소지하고 있는 것 (Something the individual possesses)
   -> 암호 키, 전자 키 카드, 스마트 카드, 토큰 등

3. 개인 자체 (Something the individual is)
   -> 지문, 망막, 안면 등

4. 개인이 수행하는 것 (Something the individual behaves)
   -> 음성 패턴, 수기한 문자, 타이핑 리듬 등

인증 구분

• Standalone 컴퓨터에서 인증

• 네트워크 상의 원격 인증
  -> 도청, Replay, 위변조

단순한 인증

• Standalone에서는 문제 없음.
  Bob은 사전에 등록된 Alice의 패스워드를 갖고 있어야 함

• 네트워크 인증에는 불충분
  replay attack이 가능함.
  => 보안은 공격을 가정하고 공격에 대해 안전한 매커니즘을 만드는 것

Replay attack

Bob입장에서는 해당 패킷의 송신지가 Alice인지 Trudy인지 알 방법이 없음.공격자 Trudy가 Alice가 보낸 패킷을 그대로 Bob에게 재전송(Replay)하면 Bob은 Alice로 인식하고 정당한 패킷을 보냈기 때문에 인증해줌
(인증과 본인 확인은 별개)

패스워드 보호

Alice와 Bob사이의 통신 채널은 항상 Untrusted하기 때문에(Trusted한 채널은 없다 ㅋㅋ) 해당 채널에 패스워드가 직접적으로 돌아다니는 것은 위험함.

해시함수를 통해 패스워드를 직접적으로 노출시키지 않고 있다.
=> 하지만, 여전히 Replay attack이 가능하다.

Challenge-Response

Challenge로 Nonce를 전달
Response로 Nonce로 부터 유도된 + Alice를 확인할 수 있는 값 전달
=> Replay attack을 방지 할 수 있음(Nonce는 Replay attack을 방직하기 위한 것)

참고
Challenge-Response의 의의는 인증을 위해서 문제(Challenge)를 내면 그에 해당하는 응답(Response)을 제출하는 것으로 인증을 하는 과정임.
위에도 말 했듯이 패스워드를 직접적으로 채널에 전송하는 것은 위험함.
패스워드를 직접적으로 전송하는 것이 아닌, '내가 패스워드를 알고 있어야지만 풀 수 있는 문제'를 제출하기도 함 = (Alice임을 확인할 수 있는 값)
ex) 은행 보안카드 : 17번의 앞 두 자리, 30번의 뒷 두 자리를 입력해주세요.

대칭키 활용 인증

Challenge-Response에서 대칭키 활용
R : Nonce
Replay attack을 방지 할 수 있다. (why -> Nonce가 있으니깐)

상호인증

1, 2) 해당 프로토콜은 Alice는 Bob을 인증할 수 있지만,
-> I'm Alice와 함께 R(Replay attack을 막기 위한 Nonce이자 Alice가 Bob에게 보내는 Challenge)
3) Bob은 Alice를 인증할 수 없다.
-> Why? 3번은 Replay attack일 수 있다.

참고
3번이 왜 위험한가...
지금부터 Alice를 공격자 Trudy라고 생각해보자.

Bob의 시점에서 보면 위 그림과 같다.
1) Alice가 인증을 요청하는 구나 + 나를 인증하기 위한 Challenge를 전송하는 구나
2) 우리가 사전에 공유했던 키인 $K_{AB}$로 R을 암호화해서 보냈어. 우리 둘만 가지고 있는 비밀키로 암호화 했으니까 이 패킷을 보내는 사람은
나야, Bob
3) 오, 너도 $K_{AB}$로 R을 암호화해서 보냈구나!
너 Alice 구나~

Alice 아닌데~ Alice 아닌데~ ㅋㅋ
1) Trudy는 자신이 Alice인 척 Bob에게 패킷을 전송함
2) 그에 대한 응답이 옴 (Trudy는 관심 없어 너가 Bob인지)
3) Alice인 척 하려고 2번에서 온 응답을 다시 재전송함

=> 그럼 어떻게 해결해야 할까?
Alice가 1번에서 Bob을 인증하기 위해 Challenge를 보냈던 것 처럼
Bob도 Alice를 인증하기 위해 Challenge를 보내면 된다.

상호인증 적용 버전

1번은 이전 그림과 동일.
2번에서 Bob이 Alice를 인증하기 위한 Challenge인 $R_B$가 추가됨.
3번은 그에 대한 응답

=> Replay attack은 해결되었으나, 다음과 같은 상황이 발생할 수도

위 그림은 공격자 Trudy가 Bob이 보낸 Challenge인 $R_B$에 대하여 Response인 $E(K_{AB}, R_B)$의 값을 얻기 위한 방법을 나타내고 있다.

참고
위의 부분(1,2,5번 패킷)에서 Bob이 인증을 위한 Challenge($R_B$)를 전송하고 있다.
Trudy는 $K_{AB}$가 당연히 없기 때문에, 5번 패킷을 만들어 낼 수 없다.
어쩌지?
3번 패킷을 만들어서 전송함(이때, $R_B$를 Challenge로 전송함)
Bob은 자신을 인증하기 위해서 바보같이 응답을 해버림.
(이때, Trudy는 손 쉽게 $E(K_{AB}, R_B)$를 얻음 + $R_C$는 안중에도 없음.
$E(K_{AB}, R_B)$을 얻었기 때문에 5번의 패킷 전송이 가능해짐.
3,4번 과정이 아주아주 짧은 시간에 진행된다면, Bob은 눈뜨고 코 베임 ㅋ

---

보안 프로토콜, 매커니즘은 여러 공격에 취약하고 가정이나 환경이 바뀌면 더 이상 안전하지 않을 수 있다.

우리의 Bob의 코를 지켜주기 위해서는 어떻게 해야할까?
메시지의 발원지를 추가함으로써 상호인증에 대한 공격을 방지할 수 있다.

공개키 활용 인증

참고

• Notation
  Alice의 Public key로 암호화 : $\{M\}_{Alice}$
  Alice의 Private key로 암호화 : $[M]_{Alice}$
• RSA의 특징(공개키/비밀키 암복호화 가능)을 이용하여
  1) 상대방의 공개키로 암호화하여 전송 : 메시지 전송을 위한 암호화
  2) 자신의 비밀키로 암호화하여 전송 : 서명을 위한 암호화

챌린지를 복호화해서 보낼 것을 요구

Bob이 Challenge를 Alice의 공개키로 암호화하여 전송하고 있다.
(위 참고에 써둔 1번 과정 : 메시지 전송을 위한 암호화)

해당 Challenge를 성공적으로 복호화했다는 것은
해당 공개키와 한 쌍을 이루는 비밀키를 가지고 있다는 것 == 나야, Alice.

Trudy는 인증 프로토콜을 이용해서 Alice에게 무엇이든 decrypt 시킬 수 있다.
Trudy가 이전에 도청한 암호문을 Challenge인 척 Alice에게 전달하면 Alice는 Response를 위해 해당 암호문을 복호화하여 전달해준다.

=> Message encryption을 위한 키 쌍과 Authentication을 위한 키 쌍을 별개로 사용해야 한다.

서명 기능 이용 : 챌린지 값에 서명할 것을 요구

이번에는 서명 기능을 이용한 프로토콜을 보자.
위 그림의 프로토콜은 안전한가?

Trudy는 Alice에게 무엇이든 서명(Sign)하게 시킬 수 있음
(위 참고에 써둔 2번 과정 : 서명을 위한 암호화)

’Alice가 Trudy에게 10억을 송금한다‘라는 내용의 메시지를 Challenge인 척 전달 하면
Alice는 해당 메시지를 Sign하여 Response로 전달하는 위험이 있다.

참고

$[R]_{Alice}$는 "난 바보임"을 Alice가 서명했다.
Alice는 눈뜨고 코 베였다.

=> Authentication 과 Digital signature에는 서로 다른 키 쌍을 사용해야 한다.

---

세션 키 (Session Key)

세션 : 사용자와 시스템 또는 두 시스템 사이의 현재 활성화 되어있는 접속을 의미함

세션 키는 해당 세션의 암호화나 인증에 사용

• 보통 대칭키가 세션키로 사용됨
• 암호화, MAC에 사용됨
  보통 인증을 하면서 세션키를 교환하게 됨

인증과 세션키 교환

• 암호화를 사용하였고 안전하지만, 상호 인증이 안됨

• 서명을 이용하여 상호 인증이 되지만, 키가 노출됨
  (공개키로 해당 서명을 복호화 하면 키가 노출됨)

• 서명을 암호화함으로써 세션키와 상호인증 모두 제공한다.

Perfect Forward Secrecy

PFS(Perfect Forward Secrecy)란 이전에 암호화하여 전송한 패킷들이 추후에 해당 암호화에 사용되었던 키가 유출되더라도 복호화할 수 없음을 보장하는 보안성을 의미하다.

PFS를 보장하려면 어떻게 해야할까?
암호화에 사용된 키를 완벽히 지워야 한다.
=> 세션키(세션에서만 사용하는 키)를 이용하고, 세션이 끝나면(통신이 끝나면) 이를 완벽히 지우자.

Naive Session Key Protocol

일반적인 상황에서는 Alice와 Bob사이에 공유키($K_{AB}$)를 이용하여 $K_S$를 암호화하여 전송한다.
하지만 이는, 해당 공유키가 노출되면 PFS를 보장하지 않는다.

Diffie-Hellman version

DH 키교환 알고리즘을 이용하여 세션키를 생성하자.
세션키 : $K_S = g^{ab} \space mod \space p$
키 교환 이후 a, b는 삭제하기 때문에 공격자는 세션키를 복구할 수 없다.

=> 하지만, MITM(Man In The Middle, 중간자 공격)에 취약하다.

참고

MITM 공격 과정

MITM 공격은 중간자인 Trudy가
Alice에게는 Bob인 척,
Bob에게는 Alice인 척 하는 것이다.
DH 키교환 알고리즘에서의 비밀키로 사용되는 z를 새롭게 만들어서
$R_2 = g^{z} \space mod \space p$를 생성하고 이를 Alice와 Bob에게 전송한다.
Alice와 Bob은 각자의 비밀키 x, y로 만든 $R_1, R_3$를 Trudy로 전송하고 각자 이를 통해 $K_1 (= g^{xz} \space mod \space p), K_2 (= g^{yz} \space mod \space p)$를 생성한다.
Alice입장에서는 생성된 세션키인 $K_1$이 Bob과의 세션키인줄 알고 열심히 해당 세션키를 통해 통신한다.
Bob도 마찬가지로 $K_2$가 Alice와의 세션키인줄 알고 열심히 통신한다.
??? : Alice와 Bob의 코는 이제 제껍니다.

상호인증, 세션키, PFS

오늘 배운 모든 것을 조합하여 사용하자!!

상호 인증을 위해서 $R_A$, $R_B$, 암호문을 서명하는 모습
세션키를 위해 DH($K_S = g^{ab} \space mod \space p$)를 사용한 모습
PFS를 위해 암호문과 서명을 적용한 모습(MITM 공격 방지)
=> MITM은 서로가 인증이 안되서 발생하는 문제이므로 서명을 이용하면 됨.