정보보안_6_Protocol

Protocol이란?

특정 그룹안에서 상호규약, 규칙

 

 

종류

Human protocol 

Networking protocol : HTTP, FTP

Security Protocol : 시스템 보안성을 위해 지켜야하는 규약

몇몇 알려진 보안 프로토콜들은 이미 이슈가,, wep, gsm,,,

구현하는 와중에 오류가 발생할 수 있음

 

 

Ideal Security Protocol

• Must statisfy security : 보안 요구사항이 만족되어야함
• Efficient : 최소한의 연산, 대역폭, 딜레이,, 
• Robust : 공격에도 견고해야하고 환경변화에도 괜찮아야함
• Easy to use and implement, flexible : 사용, 구현이 용이해야함.

 

 

Very Simple Authentication

단순히 비밀번호로 증명하는 경우를 생각해보자.

이 경우는 다음과 같은 문제들이 발생한다.

1. 메시지 훼손가능

2. 중간에서 가로채어 비밀번호 노출 가능

3. Bob이 사전에 Alice의 비밀번호를 알고 있어야한다는 점.

4. Alice가 진짜 Alice인지 확인할수도 없음. (비밀번호만 알 수도 있잖아!)

 

일단 그래서 Hash를 해볼까?

비밀번호를 hash해서 전달한다고 해보자

중간에서 누군가 비밀번호를 가로챌 수 있지만 진짜 비밀번호는 해시되어 알 수 없다! 

 

이 방법은 안전할까?

아니다, 이 역시 사전에 Bob이 Alice의 PW를 알고 있어야한다.

또한, 해당 메시지를 그대로 가로챘다가 다시 전달하는 Replay Attack이 가능하다.

 

Replay Attack을 방지하기 위해선, 그때 그때 새로운 신선함을 줄 수 있는 무언가가 필요한데 여기서 등장하는 개념이 Challenge-Release 이다.

 

Challenge - Response

replay attack을 방지하기 위해 현재 상황을 반영한 질문을 하고 Alice만 대답할 수 있는 응답을 기대하는것

Challenge

- 현재 상황을 반영한, 이 상황을 검증하는 quiz

- 오직 Alice만 대답할 수 있는 질문

- 재연이 불가능한 질문

Response

- 오직 그때의 Alice만 할 수 있는 응답 -> 이를 통해 진짜 Alice임을 검증할 수 있음.

 

Nonce

number used once의 약자로 한 번 사용된 숫자. 즉, 이 인증과정에서만 사용한 숫자를 의미한다.

Alice가 Bob에게 보내고

Bob이 이를 응답하든가 하는 방식

 

여기에는 정해야할 항목이 몇 개가 있다.

• 무엇을 nonce로 쓸건지?
• 그 Nonce를 가지고 Alice가 무엇을 할 수 있는지?
• Bob이 그것을 어떻게 검증할 수 있는지?
• pw or key에 의존하는지?

이렇게 nonce를 활용하면 bob이 alice에게 보낸 nonce에 대해 alice가 해시를 해서 보내는 방식으로 메시지를 주고 받을 수 있다. 이 경우 Challenge == nonce, Response == hash가 되는 것이다. 

이 방법을 통해 Replay attack을 방지할 수 있다.

그러나,이 경우에도  Bob이 Alice의 PW를 알아야한다는 문제가 있다.

 

 

Generic Challenge Response

목적 : Bob이 pw를 몰라도 유사한 인증을 가능하게!!!

 

따라서, 상대방의 비밀번호를 모르더라도 서로 인증하고 안전하게 메시지를 전달할 수 있게 프로토콜을 설계해야한다. 언제 Hash를 하고 Encryption을 할지를.. 잘 결정해야한다.

 

단순 password가 아니라 Protocol이 어떻게 뚫릴 수 있는지?

프로토콜의 관점에서 생각해보자!

 

 

Case Study 

 

PKES : Passive Keyless Entry System

자동차 키 시스템을 생각해보자. 실제 키를 넣어 문을 여는게 아니라 차와 key 사이의 상호 인증을 거친 뒤 문을 열어주는 시스템이다.

 

Car controller --> Key fob에  Nonce N을 보낸다.

Key fob --> Car Controller : Keyfob의 ID, 사전에 공유된 키 K로 암호화된 Ek(ID,N)을 보낸다.

 

그러나, 이 간단한 시스템은 증폭기를 이용해 신호를 멀리서도 가진 다음에 가지고 있다가 공격을 할 수 있기 때문에 그렇게 안전하진 않다.

 

이를 방지하기 위해서 UWB(초광대역 고주파수)를 활용해 아주 정밀한 거리 단위를 구분하기도 한다.

 

 

Two-factor Authentication (OTP와 유사)

사용자는 두 가지 요소를 가지고 있어야한다.

1. Password generator(P)

2. 시스템에 로그인할 수 있는 PIN

 

시스템이 유저에게 nonce를 보낸다.

유저는 P에 Nonce와 PIN을 보낸다.

P는 유저에게 이를 K로 암호화해서 보낸다.

유저는 시스템에 이 값을 보내 인증한다.

 

 

MIG  in the middle : nonce를 토스하는것

그림으로만 알아두자

 

 

Symmetric key 기반 Authentication : 대칭키

비밀번호를 몰라도 서로 인증이 가능해야한다. 따라서, 우선 첫번째는 대칭키를 활용해서 문제를 해결하는 과정을 생각해보자.

 

Alice와 Bob은 동일한 대칭키 K를 사전에 공유하고 둘 외의 아무도 이를 모른다 (K가 공개되면 보안상 위험함..!)

이 때, 다음과 같은 이슈들을 처리해야한다.

• key를 드러내지 않아야함
• Replay attack 방지
• 검증이 필수임(Alice가 Alice가 맞는지..!)

그래서 가장 기본적인 과정을 생각해보면 다음과 같다.

 

1. Alice --> Bob : 나 앨리스야!

2. Bob --> Alice : Nonce R을 준다.

3. Alice --> Bob : Ek(R)을 보낸다.

 

이 경우에 재연 공격은 방지할 수 있지만.. 

Alice입장에선 상대가 내가 보내려던 Bob이 진짜 맞는지 알 방법이 없다.

(naver인지 navor인지..)

 

따라서 상호인증!을 어떻게 구현할 것인지가 중요한 포인트가 된다.

 

Mutual Authentication : 상호인증

서로 메시지를 주고 받는 상대가, 진짜 상대가 맞는지를 확인하고 검증하는 과정이 필요하다.

 

1. Bob 너도 R을 K로 암호화해서 보내봐!

일단 이건 바보고

이 방법은 일단 바보다. Bob - > Alice에게 가는 Ek(R)을 그대로 다시 전달하면 되니까 Alice가 아니더라도,, 이 프로토콜은 진짜 바보다.

 

Bob이 Alice를 인증할 방법이 없다.

 

이 경우를 통해, 단 방향에선 잘 이루어지던 인증 프로토콜을 두 방향으로 여러번 쓰니까 오히려 안 좋은 결과를 가지고 온다. 상호인증은 어렵다!

 

2. 같은 nonce가 아니라 각자의 nonce를 만들어볼까?

 

이렇게 하면 Alice가 메시지를 받을때 Bob이 진짜 Bob인지를 알 수 있고 다시 Ek(Rb)를 할 때 Bob도 Alice가 Alice가 맞는지를 확인할 수 있다.

 

그렇다면 이 프로토콜은 진짜 상호인증이 이루어진 것일까? 얼핏보면 그럴 수 있지만 아니다.

다음과 같은 Reflection Attack이 발생할 수 있다.

 

Reflection Attack

악성 공격자 Trudy가 2개의 계정을 이용해서 Bob에게 Alice인 척 대화를 시도하려고 한다. 

 

 

세션1

1. T --> B : 나 Alice야, Ra를 보낸다.

2. B --> Rb, Ek(Ra)를 보낸다.

 

이 때 Rb를 가지고 다른 계정으로 다른 세션을 열어서 다시 B에게 메시지를 보낸다.

 

세션2

3. T2 --> B : 나 Alice야, (bob이 준)Rb를 보낸다.

4. B --> T2 : 아하! 새로운 nonce Rc, Ek(Rb) 즉, Rb를 암호화한 값을 같이 보낸다.

 

트루디는 이렇게 해당 세션2는 버리고 다시 세션1로 돌아가서 자신이 Alice임을 인증하고 대화를 할 수 있다.

즉, Alice와 Bob 사이의 상호 인증 대칭키 K를 모르더라도 Alice인척 속여서 Bob과 메시지를 주고 받을 수 있는 것이다.

 

 

단 방향으로 성곡적인 프로토콜을 2번 쓰는 것으로는 상호인증이 어렵다... 

 

이를 해결하기 위해 가로챌 수 있는 Nonce값이 아닌, Alice와 Bob이 각자 고유한 정보(신분, 개인정보)를 활용해 제3자가 Alice인 척을 못하게 함으로써 Refelction Attack을 막는 방법이 있다.

 

Nonce --> 개인만 입력할 수 있는 정보! (이게 뭔데 그래서..?)

하지만,,! 여기서는 다시 잊고 있던 Replay attack이 발생가능하다.

 

즉, 대칭키를 이용해서 상호인증을 구현하는 건 어렵다... 

 

 

Public key Authentication : 비대칭키

대칭키를 사용해서 상호인증을 하는 것은 어렵다.

 

인증 프로세스에서 원하는건  뭘까?

상호 세션에서 활용할 세션키

Perfect forward Secrecy(PFS) 완벽한 순방향 비밀성 : 인증과 인증 후에 주고받는 정보가 얼마나 안전한지

효율적으로 최소한의 메시지 교환

 

또한 완전한 프로토콜은 환경이 변화하더라도 유지되어야한다.

 

이미 우리는 대칭키의 문제를 안다. 그렇기에 이번엔 비대칭키로 상호 인증을 한 후, 세션키로 이후의 인증 과정을 거쳐보자.

 

가장 기본적으로 다음과 같은 프로토콜이 있다고 보자.

Alice가 자신을 알리면 bob이 넌스를 Alice의 공개키로 암호화해서 보낸다. 이렇게 되면 Bob은 상대가 앨리스라는 것을 알 수 있지만, 이 프로토콜은 ALice의 공개키로 암호화된 모든 것을 복호화해주는 프로토콜이다.

즉, Bob이 나쁜 마음을 먹고 Alice로 암호화된 모든것들을 복호화해서 돌려받을 수 있는 프로토콜이 된다.

 

반대로 Alice가 자신을 알리고 받은 nonce R을 Alice가 서명을 해주는 프로토콜은 어떨까?

이 역시 어떤 메시지든 Alice의 서명을 받아내는 프로토콜로 악용될 수 있다.

 

따라서, key하나를 이용한 인증과정은 다소,, 문제가 많다. 

 

 Q&A

 

1. 선 서명 후 암호화

 

2. 선 암호화 후 서명

 

위 두 가지 방법으로 상호 인증을 진행하지 않는 이유는?

CH4에서 언급했던 문제점대로

1. 수신자가 이를 악용해 타인에게 전달할 수 있다는점

2. 중간에 제3자가 껴서 자신이라고 속여서 보낼 수 있기 때문에

 

이 이유인지..?

 

또한, 왜 이 방법이 문제가 없다면 쓰지 않는 이유는 비용 때문인지?

 

아무쪼록, 서명이나 암호화만을 이용하는 방법에는 문제가 있음이 드러났다. 

따라서, 인증과정과 상호 커뮤니케이션 과정에서 사용하는 키를 분리해보는 것은 어떨까?

 

Session key :세션키

상호인증은 public key를 이용하고 이 과정에서 둘만 아는 새로운 키를 주고받아 이를 커뮤니케이션에 활용하는 '세션키'의 개념이 등장했다.

 

세션키는 대칭키다. 둘만 알고 나머지는 알지 못한다!  따라서, 제3자는 세션키를 알지 못하기때문에 둘의 대화 과정에 끼어들 수 없다.

 

세션키 암호화 프로토콜

Alice가 nonce를 보내면 bob이 세션키와 함께 R을 Alice의 공개키로 암호화해서 보낸다.

Alice는 R+1,K로 잘 받았음을 Bob에게 전달한다.

 

Bob은 회신받은 메시지로 자신이 Alice와 소통하고 있음을 인증할 수 있다.

그러나, Alice는 {R,K}a로는 Bob이 이 메시지를 전달했는지 알 수 없다.

 

상호인증이 실패했다.

 

세션키 서명 프로토콜

반대로 암호화 대신 서명을 해서 보내는건? ...바보다. 누구나 각자의 공개키로 복호화가 가능하기 때문이다.

세션키가 보호되지 않는다.

 

따라서, 세션키를 교환하고 상호인증을 하기위해선 서명, 암호화 둘 다 필요하다.

 

선 서명 후 암호화

 

 

Alice만 Bob의 서명 내역을 알 수 있고 Bob의 서명임으로 보낸 상대를 인증할 수 있다.

BOb도 마찬가지다.

 

이 방법은 상호인증과 세션키 교환을 성공적으로 진행한다.

 

반대로 선 암호화 후 서명은 어떨까?

 

일반적으론 선 각자의 공개키가 다 알려져있으니 서명을 하면 .. 암에 {R,K}a가 풀릴 수 있어 보안성이 떨어질 것이라고 생각된다.

 

그러나, 최종적으로 안에 있는 {}은 Alice, Bob만 알 수 있고 각각은 전달 받을때 상대의 서명된 내용을 받기때문에 상호 인증도 가능하다..?

 

Q&A 중간에 Trudy가 낀다면?

1) 2)의 과정을 통해

Trudy가 중간에 껴서 K를 알 수 있을 것 같다.

 

그러나, Trudy가 2) 이후에 Bob에게 Alice의 회신 받은 메시지를 조작할때 Alice의 서명을 할 수 없으므로 아마 이 이후에 Bob이 도착 안했으니 K를 사용하지 않지 않을까?

아무튼 Public key로 서명, 암호화 두 단계를 거쳐 세션키를 교환하는 과정은 안전하다! 

 

 

Perfect Forward Secrecy : PFS

이렇게 전달되어 진행되는 A와 B의 메시지는 절대적으로 보존되어야한다. 나중에라도 복호화를 하면 안되는데...

이 경우를 생각해보자.

 

A와 B가 세션키 K를 통해 암호문으로 잘 전달하다가 Trudy가 이 메시지를 약 10년 보관해서 K를 결국 찾았다고 생각해보자.

이러면 PFS가 지켜지지 않는 상황이 된다. PFS를 지키려면 Trudy는 절대 복호화에 성공할 수 없어야한다.

 

우선, Trudy는 어떻게 세션키를 get할 수 있었을까?

Alice와 Bob은 공유대칭키 Kab를 통해 세션키Ks를 교환했다. 트루디가 언젠가 공유대칭키 Kab를 알게 된다면, 세션키 또한 공개될 수 밖에 없다.

 

Diffie-Hellman for PFS

사전에 공유된 공유 대칭키 Kab로 디피헬만 키교환을 한다.

Q&A 공유 대칭키는 위에서 언급한 Public key 방식으로 만드는 것인가?

 

공유대칭키로 한 번 더 암호화를 진행해 세션키를 만든다.

 

만든 이후엔, a,b를 잊어버린다. 아예 기록에 남기지 않는다. 그렇게 되면 메시지를 기록해도 세션키를 알 수 없다.

 

즉, Publice key --> Kab공유대칭키 생성 --> g^a mod p , g^b mod p 교환 ---> 세션키 생성

 

Kab를 알아도, 결국은 세션키를 알 수 없다.

 

 

디피헬만을 사용해 발생할 수 있는 MIM attack 가능성은?

Kab로 암호화 되어있기에 중간자가 개입할 수 없다.

이와 같이 Trudy가 안에껴도 Kab로 암호화 되어있기에 장난을 칠 수 없다.

 

결과적으로 아래와 같은 방법으로 암호화, 서명을 거친 후 a,b를 각각 잊어버리면 안전하게 서로의 세션키를 교환할 수 있다.

 

Alice 수신

Rb : Replay 공격 방지할 도구

Ra : 제 3자가 Replay Attack을 하지 않고 보냈음을 증명

g^b mod p : 세션키를 만들 재료

 

 

효율적으로 최소한의 메시지 교환

이제 상호인증을 만족하고 보안성은 어느정도 확보했다.

 

지금부터는, 효율성을 고려해볼 것이다.

 

우선, 불필요한 Nonce 교환 과정을 줄이고 이를 시간 Timestamp T로 대체하는 프로토콜을 고려해보자.

물론! 서버마다 서버시간이 다르기 때문에 시간이 어느정도 뒤틀릴 수 있고 이 과정에서 우리가 방어하려했던 리스크들이 다시 발생할 수 있다. 따라서, 이걸 방어하기 위해 시간 오차를 어느정도로 설정할지 고려하는 것 또한 중요한 과제이다.

 

아래의 프로토콜을 보자. Nonce 대신 시간을 활용하는 것이다.

 

nonce를 교환할 필요가 없으니 Alice가 bob에 nonce를 보내는 과정의 메시지가 하나 생략되었다. 대신 바로, 시간과 세션키를 활용해 선 서명 후 암호화를 해 세션키 K를 보냈다.

 

이 과정은 별문제 없어보인다.

 

그럼 반대로 선 암호화 후 서명은 어떨까?

이 경우는 조금 다르다. Alice와 bob의 공개키가 공개되어있으니 누구나 {T,K}b를 얻을 수 있다.

이것을 얻은 Trudy가 다시 [{T,K}b]t로 서명을 해서 Bob에게 메시지를 요청하면?

bob은 [{T+1,K}t]bob으로 회신을 하고 Trudy는 K를 알 수 있게 된다. 

세션키 K가 노출된다.

 

다만, Trudy는 Bob에게 메시지를 보낼때 자신이 나 T시간에 보낸ㄴ다~~ 하고 보낼 것이기 때문에 해당 작업을 빠르게 해야한다는 시간제약이 주어진다.

 

 

Q) 같은 선 암호화 후 서명에선 왜 안전했지?

A) Bob이 키를 결정했다. 그리고 Alice로 암호화했기에 Trudy가 이를 읽고 활용할 수 없었지!

(활용해도 결국 마지막에 bob이 인증을 못했음)

 

 

사실 Alice는 이미 key를 알고 있기 때문에 alice에게 회신할때 K를 보내지 않아도 된다.

이를 해결하기 위한 방법으로는 K를 포함하지 않고 보내는 다음 방법이 있다.

 

Remote Key Management

Key를 어떻게 분배하고 사용자들의 키를 공유하고 관리할지에 대한 생각도 필요하다.

 

키를 분배하는 신뢰된 제3자 기관 S가 있다고 가정하고 다음 프로토콜을 보자.

(A와 B는 사전에 S에 등록한 유저들이다.)

A는 B와 대화가 하고 싶다.

 

A --> S : 나 A, B와 대화하고 싶음!

S --> A : Ekas(A, B, Kab, T), Ekbs(A, B, Kab, T)

A에게 B와 대화할 수 있는 공유키 Kab를 A와 S만 아는 Kas키로 암호화해서 전달한다.

A는 이를 Ekas를 통해 복호화하고 B에게 메시지를 보낸다.

A --> B: Ekbs(A,B,Kab,T), Ekab(msg)

A : S가 너랑 이야기하라고 이거 줬는데 확인해봐!

B : 오 진짜네 ㅇㅋㅇㅋ

 

여기서 Ekbs(A,B,Kab,T)가 인증 토큰의 역할을 한다.

 

이 과정을 조금더 classfic하고 secure하게 만든 Needham-schroeder protocol(1978)이 존재한다.

그런데, 이렇게 상호 인증 키를 발급 받았는데 이 키는 얼마나 유효할까? 

발급받아놓고 2년 후에 대화를 한다면 키가 fresh할까?

 

이를 위해 3가지 서버에서 등장하는 Kerberos 프로토콜이 존재함

 

 

 

암튼 여기선 서버 3개를 동기화 해야한다는 이슈가 있다는 것만 알아두자!

 

 

 

 

상호인증 / PFS 어떻게 구현하는지!