신원확인 방법 (Entity Authentication)

온라인에서 신원확인을 하기 위해선?

1. 신원확인 방법(Types of Identification)

1) 알고 있는 정보 : 비밀번호, 비밀 (password, secret)

2) 내가 가지고 있는 것 : 스마트 카드 (다른 곳으로 옮기기 힘든 하드웨어 토큰)

3) 나의 몸 : 지문, 홍채 (fingerprint, Iris)

2. 어떤 종류의 공격이 가능할까?

1) Impersonation 

- 자기가 아니면서 위장해서 공격

2) Replay attack

- 프로토콜 메시지를 관측 후 캡처, 똑같은 메시지를 다시 재전송 한다

3) Interleaving attack

- 프로토콜을 여러명이서 사용할 경우

- 흘러다니는 메시지를 캡처해서 다른 사람에게 보냄

- 동시 세션이 열렸을 때 섞어서 보내는 공격

- 받는 사람은 다른 사람과 통신한다고 믿게 된다.

3. 어떤 종류의 인증프로토콜이 있을까?

1) Password

2) Symmetric key

3) Public key

4) ZKIP based (Zero-knowledge Interactive Proof)

4. Password 기반

1) ID와 패스워드를 같이 보낼 경우 공격자가 가로챌 수 있다.

2) 또는 패스워드 파일이 유출되면 위험하다.

3) 따라서 직접적인 패스워드 대신 해쉬함수로 연산한 결과를 보내준다.

4) 하지만 이 방법은 딕셔너리 어택(dictionary attack) 으로 인해 취약하다

5) 미리 사전파일을 만들 수 없도록 salt를 추가해서 암호화 한다.

6) 또는 패스워드가 노출되어도 한번만 사용하도록 one time password를 사용한다.

- Lamport의 one time password

1) 단순히 hash 체인을 만든다.

2) 해쉬(해쉬(해쉬(해쉬(....해쉬(난수 w)))))))) 방법으로

3) 인증방법은 다음그림과 같다.

4) 이 방법은 해쉬는 일방향이기 때문에 해쉬화 전의 값은 알 수 없다는 점을 이용한 방법이다.

5) 예를 들어 해쉬5번 하면 처음엔 해쉬4번한 값을 전달 

6) 서버는 이 값을 해쉬화 해서 비교 후 맞으면 4번한 값을 저장

7) 그 다음 쓰려면 해쉬 3번 한 값을 전달

8) 서버는 이 값을 해쉬화 한다음 6)에서 저장한 값이랑 비교

9) .... 다 쓰게 되면 또 새로 만들면 된다.

5. 대칭키 기반

1) 단방향 인증 (Unilateral authentication)

- 여기서 델타의 값이 너무 작으면 인터넷 상황이 안좋을 경우 받지 못한다. 

- 즉 정당한 사용자도 받지 못함을 의미한다.

- 델타의 값이 너무 길경우엔 replay attack이 가능해지므로 적당한 길이로 해야만 한다.

- 유효한 암호문을 읽으려면 유효한 키가 있어야 하는데 A는 그 키를 가지고 있다.

- 이를 통해 B에게 A임을 인증할 수 있다.

- 메시지를 재활용 불가능하기 위해 여기서는 타임스탬프를 사용했다.

- 하지만 서로 시간이 다르거나 전송속도가 느릴 경우 문제가 발생할 수 있으므로 다른 것도 생각해보자!

- 타임스탬프 대신 난수(rB)를 사용했다. 이러면 시간 동기화의 문제가 해결된다.

2) 양방향 인증 (mutual authentication)

- A의 인증은 단방향인증과 다를 것이 없다. 다만 여기선 rA 만들어 함께 암호화해서 보낸다.

- B는 rA와 rB의 순서를 바꾸어 암호화한다.

- 이는 B만 할 수 있으므로 B임을 인증할 수 있다.

6. 공개키 기반

- B 혼자서는 시그니처를 만들 수 없었으나 프로토콜을 수행하다보면 secret key의 정보를 계속 얻게 된다.

- 만약 B가 나쁜 의도를 가지고 있으면 위 그림과 같이 평문을 받아볼 수 도 있다.

- 이는 chosen ciphertext attack에서 decryption orcacle을 통해 B도 모르는 것을 A를 통해서 알 수 있는 것과 같다.

- 이와 같이 해쉬 값을 함께 보내면 B의 CCA 공격이 불가능해진다.

7. ZKIP 기반 (Zero-knowledge Interactive Proof)

- 공개키 기반은 프로토콜을 수행할수록 knowledge가 증가하는 단점이 있다.

- 그런 단점을 해결하면서 내가 무언가에 대해 알고있음을 알리고 싶을 때 어떻게 해야할까

- 바로 그 해답이 ZKIP이다.

- ZKIP 의 요구사항은 다음과 같이 3가지를 만족해야한다.

1) completeness : prover가 비밀을 알고 있다면 verifier은 이를 수용해야 한다.

2) soundness : 만약 verifier가 받아들인다면 prover은 비밀에 대해 알고 있어야 한다.

3) Zero-knowledge : verifier는 비밀에 대해 어떠한 정보도 얻을 수 없다.

- 이를 간단한 예로 표현하면 알리바바와 40인의 도적들로 표현할 수 있다.

1) 두개의 갈림길이 있다.

2) 알리바바는 한쪽으로 도망간다.

3) 도둑들은 50%의 확률로 놓친다.

4) 40인의 도둑들 모두 50%의 확률로 놓치게 된다.

5) 그런데 만약 다 놓친다면?

6) 이런 확률은 매우 낮지만 트랩도어가 존재한다면 가능하다.

7) 이 때 도둑들은 알리바바에게 트랩도어를 알려주지 않으면서 트랩도어가 존재함을 증명하려고 한다.

8. 위의 3가지 중에서 Zero-knowledgeness를 증명해 본다.

1) 실제 일어나는 일을 증명하고 싶으면 시뮬레이션을 만든 뒤 테스트를 해보면 된다.

2) 서로 일어나는 확률 분포가 비슷하면 제대로된 시뮬레이션을 만든 것이다.