암호화 기반 인증기술
우리가 화면 너머에 있는 누군가와 통신할 때는 인증이 매우 중요하다.
그래서 정당한 사용자인지 확인하는 사용자 인증 기술과 송신자가 전송한 내용이 수신자에게 정보의 변형 없이 전송되었는가를 상호 확인할 수 있어야하는 메시지 인증 기술이 나오게되었다.
사용자 인증 기술
패스워드 기반 인증기술
고정(fixed) 패스워드 기법
우리가 로그인할 때 적는 비밀번호가 이 기법에 해당한다.
내가 레드라는 사람으로서 네이버에 로그인하고싶은데 네이버는 내가 레드인지 블루인지 모른다.
그래서 이를 인증하기위해 내가 누구인지를 아이디에 적고 레드만 아는 비밀번호를 적어 내가 레드임을 인증하는것이다.
이 기법은 구현이 쉬운 장점이 있지만 패스워드가 유출될 위험이 있다는 단점이 있다.
(Bruteforce 공격, replay 공격, sniffing 공격, spoofing 공격 등에 취약)
일회용 패스워드 기법
OTP(One Time Passwords)라고 부르기도 하는데, 인증할 때 쓰이는 패스워드를 한번만 사용하는것이다.
통신 때마다 새로운 세션 패스워드를 생성하므로 도청, 재전송 공격 등으로부터 안전하게 사용자를 인증하는 기법이다.
S/Key 일회용 패스워드 동작 과정
1. Pass Phrase S를 서로 공유한다.
2. 서버가 Seed 값을 생성해 M값을 만들어낸다(M값은 노출되면 안된다).
3. M을 계속 해시함수에 넣어 계산한다.
4. Xn+1(M을 n+1번 해시한 값), N+1, Seed값을 저장한다.
--------------지금까지 초기화단계----------------
5. 호스트 쪽에서 N과 Seed값을 유저에게 넘겨준다.
6. 유저는 1에서 공유한 S값과 5에서 받은 Seed값으로 M값을 만들어내고 이를 N번 해시해서 Xn을 만들어낸다.
7. 호스트가 이를 받아 한번 해시 후 4번에서 만들어진 Xn+1과 비교하여 맞으면 인증이 된다.
+ 이것이 OTP인 이유는?
이 과정에서 우리가 사용하는 패스워드는 Xn이 된다.
그래서 다음에 연결할 때 서버쪽에선 N, Seed, Xn값을 저장하고 유저는 Xn-1을 서버에 전달한다.
만약 이 OTP가 다 떨어진다면 새로 갱신하게된다.
++ Xn+1을 사용하지 않은 이유
보통 우리가 통신할 때는 그 내용이 해커들한테 털릴 위험이 있다(그래서 암호화를 해 털려도 유출이 안되도록 하는것).
만약 Xn이 노출되었는데 다음 비밀번호가 Xn+1이라면 해커들이 Xn을 해시해서 쉽게 Xn+1을 알아낼 수 있다.
그래서 Xn-1을 사용할 수 밖에 없다(Xn으로 Xn-1을 찾는것은 매우 힘들다).
Challenge-Response 기법
위에서 나온 OTP와 유사한 개념으로, 서버쪽에서 문제를 내서 정답을 맞추면 응답하는 방식이라고 이해하면 된다.
과거에는 서버와 통신할 때 패스워드를 평문 형식으로 보내었다. 하지만 이렇게 되면 해커들이 중간에서 가로채 악용하는 위험이 있어서 이 문제를 해결한게 Challenge Response 기법이다.
Challenge 값은 패스워드와 아무 관련이 없기 때문에 노출되어도 상관이 없다.
위에서 본 S/Key값도 여기에 포함된다.
+ 이것이 OTP인 이유는?
서버쪽에서 난수를 생성하기때문에 이것이 계속 바뀌고 자연스레 Challenge 값도 바뀌게된다.
시간 동기화(time synchronous) 기법
일회용 패스워드의 특별한 형태로, 패스워드가 시스템과 사용자의 인증 장치의 알고리즘에 의해 변경된다.
지금은 통신이 되서 Challenge를 받아오는게 쉽지않지만 과거에는 기계에 통신모듈이 없어서 받는게 쉽지않았다.
그래서 시간을 Challenge로 설정하여 이 문제를 해결하였다.
먼저 단말기에서 패스워드를 만들고( Es(Seed||T) ), 서버도 동시에 패스워드를 만든다 ( Es(Seed||T) ) .
Seed값은 공유하는 값이므로 시간이 같으면 값이 같게된다.
이 기법의 단점은 오래되어 시간이 맞지않거나 시간이 너무 세세하면 인증이 안될수도있다.
대칭키 기반 인증기술
대칭키 기반 암호 알고리즘을 사용하여 사용자를 인증하는 기술을 의미한다.
대표적인 기술로 커버로스(Kerberos)가 있다.
커버로스(Kerberos) 인증 기술
- 클라이언트 워크스테이션(노트북, 컴퓨터 등등)
- 인증 서버(Authentication Server) : 사용자를 인증하여 티켓 발행 서버에서 티켓을 받을 수 있는 티켓(TGT)을 제공한다.
- 티켓 발행 서버(Ticker-Granting Server) :AS로부터 클라이언트가 서비스를 받을 수 있는 티켓(SGT)을 제공한다.
- 응용 서버(Application Server) : 클라이언트를 통해 사용자에게 원하는 서비스를 제공한다.
이를 쉽게 이해하기위해서 놀이공원에 가는 상황을 가정해보자
먼저 놀이공원에 입장할 때는 티켓 없이 누구인지 인증만 되면 들어갈 수 있다. 이 역할을 하는것이 인증 서버이다.
다음으로 돌아다니는건 자유지만 특정한 놀이기구를 타기 위해선 티켓이 필요하다. 이 티켓을 발행하는 역할을 하는것이
티켓발행서버이다.
그리고 그 놀이기구 역할을 하는것이 응용 서버이다.
이 모든 과정들은 자동화이다.
+ SSO(Single Sign On) : 한번 인증하면 다른 곳에서 인증을 하지 않아도 권한을 얻는것
커버로스 과정
1. [사용자 → 인증 서버] IDc || IDtgs || TS1 을 보내 인증한다.
IDc : 사용자의 ID
IDtgs : 접속하고자하는 tgs의 ID
TS1 : 타임스탬프(접속을 시도하는 시간.
2. [인증 서버 → 사용자] E( Kc' [Kctgs || IDtgs || TS2 || Lifetime2 || Tickettgs ] )세션키와 티켓을 Kc로 암호화해서 제공한다.
Kc : 사용자와 AS가 공유하는 마스터키(키는 처음 통신할때 생성됨)
Kctgs : 사용자와 tgs가 공유하는 세션키
Ktgs : tgs의 마스터키
Lifetime2 : 티켓의 유효기간
Tickettgs : tgs에 접근할 수 있는 티켓
Tickettgs = E(Ktgs[Kctgs || IDc || ADc || IDtgs || TS2 || Lifetime2]) -> 이걸 열수있는사람은 tgs밖에 없다(티켓은 클라이언트가 손댈수없다).
ADc : 사용자의 ip주소
3. [사용자 → 티켓 발행 서버] IDv || Tickettgs || Authenticatorc 을 보낸다
IDv : 접속하고자하는 응용 서버의 아이디
Authenticatorc = E(Kctgs [IDc || ADc || TS3])
4. [티켓 발행 서버 → 사용자] E(Kctgs'[Kcv || IDv || TS4 || Ticketv]) 티켓과 세션키를 제공
Kcv : 사용자와 응용서버와 공유하는 세션키
Ticketv = E(Kv[Kcv || IDc || ADc || IDv || TS4 || Lifetime4])
Kv은 응용서버만 알기때문에 사용자가 열 수 없음
5. [사용자 → 응용 서버] Ticketv || Authenticatorc 을 보낸다
Authenticatorc = E(Kcv [IDc || ADc || TS3])
6. [사용자 → 응용 서버] E(Kcv[TS5 + 1])을 발급한다.
커버로스 V4 vs V5
공개키 기반 인증기술
공개키 기반 알고리즘을 사용하여 사용하는 기술이다.
대칭키 기반 알고리즘의 핵심이 Challenge response 였는데 공개키 기반 인증기술도 똑같다.
공개키 기반 인증 진행과정
1. 엘리스가 통신을 요청한다.
2. 밥이 난수 R을 보낸다.
3. 엘리스는 이 R을 자신의 개인키로 암호화해 보낸다.
4. 밥이 엘리스의 공개키를 받아 이를 풀어서 R이 나오면 엘리스임이 인증된다. Ka+(Ka-(R))
하지만 이 공개키 기반 인증의 치명적인 단점이 있었는데, 바로 Man in the middle 공격에 취약하다는것이다.
Man in the middle 공격
여기서 엘리스와 밥 이외의 사람인 트루디가 중간에 끼어들었다고 가정하자.
1. 엘리스가 통신을 요청한다.
1.5. 트루디가 이 정보를 밥에게 보낸다.
2. 밥이 난수 R을 보낸다.
2.5. 트루디 자신의 개인키로 암호화해 밥에게 보낸다.
3. 엘리스는 이 R을 자신의 개인키로 암호화해 보낸다.
3.5 트루디가 자신의 공개키를 밥에게 보낸다.
4. 밥이 엘리스 트루디의 공개키를 받아 이를 풀어서 R이 나오면 엘리스임이 인증된다. Kt+(Kt-(R))
5. 이후 통신을 할 때 밥은 트루디의 공개키로 암호화해 엘리스 트루디에게 보내게되고 트루디는 엘리스의 공개키로 암호화해 엘리스에게 보내게된다.
이때 문제점은 트루디의 공개키로 풀어도 R이 나오기때문에 밥은 상대가 엘리스라고 생각할 수 밖에 없다.
그래서 이 문제를 해결하려면 마지막에 공개키를 받을 때 엘리스의 공개키가 맞는지 확인을 해야한다.
하지만 특정 공개키가 엘리스것인지 트루디것인지 알기 힘든데, 이를 해결하기 위해 나온 개념이 CA이다.
CA(Certification Authorities)
CA는 쉽게말해 공인인증서를 발급해주는 기관이다.
밥이 자신의 신분을 증명하고, 자신의 공개키를 기관에 등록하면 인증서를 발급한다.
인증서에는 밥이 누구인지, 밥의 키가 무엇인지 등 정보들이 적혀있다.
하지만 이 인증서를 아무나 발급하면 그 내용을 수정하거나 악용할 수 있으므로 CA가 서명을 한다(개인키로 암호화).
만약 엘리스가 밥의 공개키를 원한다면 밥의 인증서를 CA에서 받은 공개키로 열어서 밥의 키가 맞는지 확인한다.
메시지 인증기술
전자서명(digital signature)
전자서명은 실세계에서 사용되고 있는 문서 인증 도구인 도장이나 수기 서명 등을 디지털 정보로 구현한것이다.
이때 요구사항이 몇가지 있는데
위조가 불가능해야하고 재사용이 불가능해야하며, 서명 후 변경이 불가능해야하고 위조가 불가능해야하고 서명 후 자신이 서명한 사실을 부인할 수 없어야한다.
서명 원리
1. 밥이 엘리스에게 m || Kb-(m)을 보낸다(이 자체가 m에대한 서명).
2. 엘리스는 밥의 공개키를 안전하게 받아와 서명된 Kb-(m)을 해독한다.
3. 서명 앞에 붙어있는 원본이랑 비교해 일치하면 밥이 보낸것으로 확인이 된다.
왼쪽에 있는 m과 오른쪽에 있는 Kb-(m)을 푼것이 일치하다면
먼저 밥이 보낸것으로 확인할 수 있고(밥의 공개키로 풀었는데 열렸으므로)(수신자 인증,Sender authentication),
메시지에 변형이 없었다는것을 뜻한다(무결성,Message integrity).
또한 밥이 썼는데 자신이 쓰지 않았다고 발뺌이 불가능하다(부인 방지, non- repudiation) <- 이는 전자서명만이 가지는 기능
하지만 이러한 서명도 장점만 있는것은 아니다.
보통 메시지의 크기는 큰 편인데, 이를 암호화한 Kb-(m)도 크기가 같으므로(다르면 복호화가 불가능) 이 두가지를 붙인것은 크기가 아주 커진다는 단점이 있다.
그래서 실제 서명은 조금 다르게 진행된다.
먼저 큰 메시지 m을 해시함수에 넣어 해시한후 밥의 비밀키로 잠그게된다( m || Kb-(H(m)) ).
이후 엘리스는 받은 m을 해시함수에 넣고 잠긴 메시지를 밥의 개인키로 푼 뒤 나온 값을 서로 비교한다.
'암호학' 카테고리의 다른 글
| [암호학] 정수론 (1) | 2024.12.16 |
|---|---|
| [암호학] 키 관리와 해쉬 함수 (1) | 2024.10.29 |
| [암호학] 공개키 암호화 방식 (2) | 2024.10.28 |
| [암호학] DES란? (1) | 2024.10.25 |
| [암호학] 대칭키 암호화 방식 (1) | 2024.10.22 |
