11.Authentication

KyoungJae Jung ·2022년 3월 1일

목록 보기

6/7

실제 우리의 통신은 아래와 같은 형식인 Challge-Response형식을 통해 상호 인증을 하고 있다.
이는 통신의 처음부분에 발생한다.

위의 그림과 같이 서버를 인증하는 것은 Cert면 충분하지만 사용자 인증은 그렇게 쉽지는 않다.

사용자 인증 방식

ID/PW
Cert
OTP
Bio
SNS/ARS/Email

이러한 방식은 아래의 사진에서 말하는 방식에 대해 기초하고 있다.

이러한 방식을 하나만 사용하는 것이 아니라 2~3개를 합쳐서 인증한다.

인증방식들 비교

인증 방식들에 대한 설명

1. Password-based authentication

password를 구축하는 이유는 구축비용이 저렴하다는 장점이 있고 사용자도 편리하다.(별도의 저장공간이 필요 X)

Navie 한방법

이 방법에는 2가지의 문제가 있다.
- 통신은 보안채널이 필요하다.
- 서버의 PW파일이 노출된다면 문제가 심각하다.
- alice에서 매번 PW를 입력할 때 내부에서 탈취한다면 공격자가 이를 탈취해 사용할 수 있다.(키보드 보안이 필요하다)
PW에 대한 간단한 해결 아이디어

이것이 안전한가?
Pw를 Hash하면 더 안전하지만 흘러가는 Hash값을 보고 PW를 추축하기 쉽다.
PW의 entropy가 낮기에 이를 원본값을 알 수 있다.
또한 hash값을 탈취한 후에 이를 그대로 사용가능하다.
해결방법 1(Hashing the passwords and storing them)

서버에서 PW를 저장할 때 Hash한 값을 넣어 둔다면 탈취당해도 공격자가 Hash된 값에서 PW를 알기에 비용이 든다.
그러니 이는 공격자가 사전에 미리 가능한 PW에 대한 미리 Hash값을 구하고 본인이 탈취한 PW파일과 비교하면 된다.
(Dictionary attack)
이에 대한 공격을 늦추는 방법은?
해결방법 2(Salting the passwords)

사용자의 PW와 Salt라는 random String을 함께 넣은 값을 Hash해 저장하고 salt값을 저장해둔다.
이러한 방식으로 사용한다면 PW한개에 가능한 Salt를 모두 대입해야하므로 공격시간이 늘어나게 된다.
but 공격을 막는것이 아닌 지연시키는 것이다

2. One-Time Password(OTP)

by Lamport

random한 P0에 대해 n번 Hash한 값을 서버에 IP와 함께 저장해둔다.
그리고 사용자는 P0에 대해 n-1번에 해당하는 Hash값을 보내주면 서버는 이를 한번더 hash 해서 원본 값과 비교하고 같다면 로그인을 하고 사용자는 n을 n-1로 서버는 PW를 이전의 hash값으로 변경한다.
장점은 서버의 파일이 탈취당해도 n을보 n-1의 값을 알 수 없다.(Hash의 일방향성을 깨야한다)
추가적으로 둘 사이에 보안채널이 필요 없다.
그러나 사용자는 state정보를 알고 있어야한다
이러한 단점은 모바일의 안전한 공간에 이를 저장해서 사용하는 방법으로 진화하고 있다.
S/KEY OTP
위의 단점을 극복하기 위한 방식이다.

보는 방법과 같이 state정보와 Pw를 모두 서버에서 기억을 하고 이를 사용자에게 전달학고 이에 대한 값을 받아 이전과 같이 동작하는 방식으로 설계하였다.
하지만 이 역시도 문제가 발생한다.
P0를 추축해 공격하는 방식은 가능하다.
그러나 본질적으로 Man-in-the-middle attack이 가 능하드는 점이 문제이다.

중간에 공격자가 사용자에게 서버인 척을 하고 서버에게는 사용자인 척을 해서 공격을 할 수 있다.
또한 n-k의 값을 조정해서 Hash Chain의 값을 알 수 있다.
이 방버이 가능한이유는?
- alice가 받는 값이 인증서버에서 온것인지 공격자가 보낸 것인지 알 수 없다.
  즉 서명을 통해 이를 해결해야 한다.
  
  그러나 이는 보다 싶이 인증채널이 형성된다.

중요 Challenge-Response

이 방법은 replay공격을 막기 위해 사용되는 방식이다.
따라서 이 방식에는 nonce라는 number used once 한번사용되는 숫자가 필요하다.

매 세션이 진행될 때마다 nonce를 바꾸면 되기에 replay 공격을 자연스럽게 막을 수 있다.
위의 사진은 Pw의 경우이다.
이 방법이 안전한 것은 아니다.
그러나 nonce를 주기에 공격자가 공격을 할 시 nonce'으로 변경되기에 과거의 것이 재사용되는 것이 자동적으로 막아진다.

3. CR Authentication using SKE

둘간에 사전에 미리 대칭키를 공유 했다고 했을 경우 한방향 인증하는 방법은 다음과 같다.

Rb를 challge로 주고 이 Rb에 대해 MAC을 주고 이를 bob이 정상적으로 MAC을 검증한다면 이는 bob에게 alice를 인증하게 된다.
또 다른 방법 Timestamp

이 역시 timestamp의 도움을 받는다면 한번으로 인증이 가능하다.
이 방법은 Oauth와 같이 SNS로그인에서 사용된다.

이는 상호인증이 아닌 일방향인증이므로 이를 아래와 같이 구성한다면 상호인증이 가능하다.
상호인증 방법

근대 이러한 방식의 상호인증이 과연 안전할까?
그러나 이는 안전하지 않다.

위의 사진에서 보다싶이 공격자가 alice인척하면 서버에서 Rb에 대하 묻는다면 공격자는 이를 잠시 멈추고 다른 것으로 가서 Rb를 주면 서버는 이에 대한 MAC을 주므로 이를 위의 통신에서 사용하면 alice인척 입장이 가능하다.
이는 실제로 bob이 서버에 해당한다. 즉 서버는 자동반사적으로 respose와 challge를 자동으로 주므로 이렇게 구성하면 문제가 발생한다.
이것이 발생하는 이유는 Challge에 대응하는 response가 대칭성을 가지면 문제가 발생한다.
해결방법

둘간의 response를 바꿔 대칭성을 없애거나
둘이 받은 모든 메시지를 모두 넣어 MAC을 만든다.

4. CR Authentication using MAC

이 역시 흘러가는 모든정보를 MAC으로 넣어 bob이 이를 확인하는 방법이다.
이 방식이 Timestamp 방식의 OTP이다.

이 방식은 timestamp 대신 nonce를 이용해 한방향 인증 방식이다.
상호 인증 역시 위에서 배운 방법으로 구성하면 된다.
이 역시 앞에서 보다 싶이 좌우 대칭이면 같은 문제가 발생한다.

이 방식 역시 Man-in-the-middle attack이 가능하다.

위의 그림에 대한 방식은 모든 메시지를 넣어 MAC을 만든다면 이러한 문제는 쉽게 해결 된다.
현재는 대칭키 대신에 MAC을 사용한다.
대칭키의 방식은 message가 길어지면 그에 대한 key나 output이 길어지는 문제점을 지니므로 일정한 output을 내는 MAC을 사용한다.

5. One-Time Password: Something you have

를 가진 OTP기기를 가지고 진행을 한다.

와 같은 방식으로 실제 은행과 사용자가 인증을 하려할 때 timestamp방식의 MAC을 서버에 전달하면 서버는 k, timestamp(전달 시간을 고려한 bound내) 를 넣어 MAC을 생성해 이를 비교하고 맞다면 인증을 아니면 거절하는 방식을 사용한다.
숫자가 커질 수 있으므로이는 mod 연산을 통해 줄이기도 한다.
이 방식은 secure한 channel이 필요 없다는 장점을 가진다.
그러나 실제로는 secure한 망 위에서 동작을 한다.
구체화한 방법은 아래와 같이 동작을 한다.

6. CR Authentication using PKE

아래는 대칭키가 아닌 PKE방식이다.
한방향인증 방식

이는 Pk를 통한 인증은 가능하지만 Pk의 원소유자임을 알기 위해서는 필히 Cert가 필요하다.
Cert가 없을 경우 공격자가 중간에서 공격하는 Man in the middle attack이 가능하다.
또 방법에서 message를 노출하면 replay attack이 가능하므로 위와 같이 Rb를 MAC의 key로 해서 MAC을 생성해서 보낸다.
실제로는 KDF를 돌려 key를 구한다.
양방향 인증 방식

이 역시 message를 그대로 주는 것이 아닌 MAC을 통해 전달한다.
단 전제조건은 둘이 암호화용 Cert를 가져야한다.
현재는 이 방식을 사용하고 있지 않는다.

7. CR Authentication using DSS

인증서 로그인을 하면 alice는 id와 cert를 보내고 이에 대해 Challenge-Response를 통해 이를 해결한다.
이 방식은 Rb가 무엇인지 모른다.
즉 alice에게 불리한 내용에 sign을 할 수 있다.
따라서 실제로는 아래의 방식을 사용한다.

자신이 뽑은 random Ra를 붙여 sign을 한다.
이는 상대방의 random에만 의존하지 않는다.
이 방법들은 alice가 bob에게 인증하는 방식이다.
그렇다면 상호인증을 하려면 위에서 본것과 동일하게 프로토콜을 구성하면 된다.

이러한 방식보다는 위의 모든 내용을 집어 넣어 message를 구성하는 방식이 적절하다.
구조에서 문제가 없지만 인증프로토콜에서의 설계가 안전에 문제로 인해 공격당할 수 있다.

Authentication: Something you are(생체 인증)

Biometric Authentication

사용자의 디바이스에서 생체 정보를 읽고 생체정보가 서버에 저장되지 않고 생체정보로 만들어지는 정보를 저장한다.
생체정보가 탈취당하면 변경이 불가능하기 때문이다.
따라서 사용자와 서버의 인증방법은
Only user authentication (user à auth. server)
Not considered server auth. (user ß auth. Server)

서버의 인증은 Cert를 통해 인증이 가능하다.
그러나 사용자 인증이 문제이므로 PW,OTP, Cert, ... 등등의 방법이 나온것이다.
생체인증에서 어려운점: 인식을 할때마다 오차범위내에서 값들이 변경이 된다.
즉 일정범위의 오차를 처리하는 것이 문제이다.

사용자가 자신의 생체정보를 등록하고 이러한 정보를 통해 인증하는 방식이다.
따라서 생체정보를 인식하고 전자서명용 Pk, Sk를 만들어고 Sk를 생체정보로 도출된 key를 가지고 암호화 한다.
그리고 PK를 서버에 보내면 등록이 마무리 된다.
추후 사용자를 인증할 때는 사용자의 생체정보를 인식하고 이 정보로 SK를 복호화하여 서버에서 주는 random Challenge를 sign을 해서 Response를 준다.
중요한 관건은 생제정보를 인식하는 f함수가 얼마나 정교한가에 달려있다.
이를 통한 ATM기기와 같은 Universal device에서 사용

위의 과정과 비슷하나 Universal device는 등록에서 값을 생성하고 삭제한다.
추후 인증 방식은 동일하게 구성되어있다.

FIDO(Fast IDentity Online)

현재 생체정보를 인식하고 사용하는 방식

사용자의 생체정보를 읽어 template파일로 저장하고 Pk,Sk를 만드는 것은 동일하지만 생체정보를 통해 인식할 때 패턴매칭이나 특이점을 통해 사용자를 인식한 후 template 파일을 통해 PK, SK를 생성해서 사용자의 인증을 수반한다.