* Protocol
- 특정 상태에서 지켜야할 규칙들(eg. Human, networking, security)
- 프로토콜의 결함은 미묘한 문제이다.
> 하지만, 몇몇 보안 프로토콜의 결함은 심각한 오류를 가지고 온다.
> 구현시 환경에 따라 에러가 발생하는 경우가 많다.
- 이상적인 보안 프로토콜
1) 보안 요구사항을 만족
2) 효율성이 높아야 한다 > 계산 과정을 최소화 해야한다.
3) 견고성 : 환경이 변해도 동작해야 하며, 공격을 당하는 중에도 동작해야 한다.
4) 사용용이성, 구현 용이성, 유연성, .. ETC
※ 모든 조건을 충족하기는 힘들다.
* 인증 방법
- 상대방이 진짜인지를 판별하는데 사용하는 방법을 인증 방법이라고한다.
- 암호, 스마트카드, 생체인식(홍채, 지문, 얼굴)등을 이에 사용하고 있다.
- 약송된 인증 방법을 프로토콜이라고 한다.
eg) ATM
- 우리는 ATM카드를 사용할때 간단한 인증방법(프로토콜)을 사용한다.
> ATM카드를 인식하여 카드 주인임을 확인한다.
> 도난 여부등에 대해서 한번더 확인하기 위해서 비밀번호(PIN)을 입력한다.
* 인증 프로토콜
- 독립되 있는(네트워크에 연결되지 않은) 컴퓨터에서는 안전한 경로가 보장되고 있기 때문에 인증이 쉽다.
- 네트워크 상은 해결해야할 문제가 존재한다.
> 누구나 메세지를 관찰 할 수 있다. 주고 받는 정보가 노출 되있다.
> 메세지를 재사용 할 수 있다.
> 메세지를 변경도 할 수 있다.
- 네트워크에서의 인증 프로토콜 제약사항
> 인증 프로토콜은 단방향으로 발생해야 하므로, 쌍방이 인증을 하려면 2번의 인증이 필요하다.
> 세션키의 사용이 필요할 수도 있다.
> 요구사항에 따라서 사용되는 키가 다를 수 있으며, 해쉬 함수의 사용여부, 익명성, 부인 방지등이 추가적으로 적용되야한다.
- 인증 프로토콜을 알기위해 다음을 가정한다
> Alice는 Bob에게 자신을 인증하려고 한다.
> 이후에 사용하는 암호알고리즘은 안전하다고 가정한다.
ⓐ 단순한 인증(use Password)
- 자신만이 알고 있는 비밀 값을 사용한다.
- 독립적인 시스템에서는 문제가 없을지 모르지만, 네트워크 상에서는 문제가 발생한다.
> 비밀번호는 네트워크 상에 공개될 것이다.
> 공개된 정보를 이용하여 공격자는 재사용 공격을 할 수 있다.
> 상대방은 이미 자신의 비밀 번호를 알고 있어야 한다.
ⓑ 암호 + Hash
- 자신의 비밀번호를 숨길 수 있어서 유용하다.
- 문제점
> 공격자는 이 때 사용된 암호문 값을 재사용하여 접근이 가능하다.(재사용 공격)
ⓒ 질문-응답(Chanllenge - Response) / ⓑ+Nonce값 사용
- 재사용 공격을 막기 위해서 "질문-응답"을 사용한다.
- Bob은 Alice에게 질문을 하고, Alice는 이에 대한 올바른 대답을 해야지 인증이 된다.
- 이때, 사용되는 질문은 재사용이 불가능하게 해야한다.
- 일회성을 보증하기 위해 nonce값(일회용 수)을 사용한다.
- Steps
1) Alice가 시스템에 접속을 하려고하면 Bob은 Alice에게 nonce값을 전달해준다.
2) Alice는 Bob에게 받은 nonce값을 hash할 때, 첨가 시킨다.(h(Alice's password,nonce))
- 암호는 Alice가 갖고 있는(생성한) 고유의 값이고, Bob은 Alice의 암호를 알고 있어야 한다.
- 공격자의 입장
> Alice의 비밀 번호를 보지 못한다.(Hash에 의해서)
> nonce값을 보아도 Alice의 비밀 번호를 모르기 때문에 인증값을 생성할 수 없다.
> hash를 할 때, nonce 값(일회성 값)을 사용하기 때문에 재사용 공격이 불가능하다.
- hash값 이외에 대칭키 암호, 공개키 암호등 암호화 알고리즘을 직접 사용할 수 도 있다.
ⓓ 대칭키를 사용한 인증
- Alice와 Bob은 대칭키 K를 공유하고 있다.
- 질문-응답방식에서 nonce값을 대칭키로 암호화하여 보내, 자신을 인증한다.
이제, 다른 문제인 상호 인증에 대해서 생각해보자.
ⓔ 대칭키를 사용한 상호인증
1) 단순한 오류
- 상호인증을 위해서 Alice가 시스템에 접속할때, Bob에게 nonce값을 전송
- Bob은 nonce값을 K로 암호화해서 Alice에게 보낸다.(E(R,K))
- Alice는 Bob임을 확인하면, 자신또한 nonce 값을 암호화하여 보낸다.(E(R,K))
※ Alice의 위치에 누가오든지 Bob이 보낸 메세지를 그대로 재사용해서 보내면 되기 때문에 허점이 발생한다.
2) 안전한 단방향 프로토콜을 2번 사용
- ⓓ번의 방법은 단방향으로는 안전하다고 밝혀진 프로토콜이다. 이를 두번 사용한다.
- 상호인증을 위해서 Alice는 시스템을 접속할때, Bob에게 nonce값을 전송한다.(R[a])
- Bob은 R[a]를 K로 암호화하여 Alice에게 보내면서, 새로운 nonce값을 전송한다.(R[b],E(R[a],K))
- Alice는 E(R[a],K)를 이용하여 Bob을 인증하고, Bob에게 받은 nonce값을 암호화하여 전송한다.(E(R[b],K))
- 이는 두개의 세션을 쓰는 공격자에게 허점을 보이게 된다.
- 현재, 단방향에서 안전했다고 판단된 프로토콜은 상호인증에서 허점을 보이게 된다.
3) 사소한 추가는 이 문제를 해결 할 수 있다.
- 위 예에서는 단순히 아이드 값을 암호화 할때 추가 하였다.
- 공격자는 K값을 모르기 때문에 암호문을 풀어낼 수 없다.
- 또한 위2)에서 4번과정에 Bob의 아이디가 포함되어 암호화가 되기 때문에, 이를 재사용할 수 없게 된다.
ⓕ 공개키를 이용한 인증
1) 단순한 방법
- 단순히, 공개키나 개인키를 이용해서 상대방을 인증하려고 한다.
- 이 경우, 중간자 공격을 당하게 된다.(프로토콜은 특정 메세지가 오면 그에대한 대답을 자동으로 하기때문에)
- 위 경우 Bob은 Trudy를 Alice로 착각하게 된다.
- 세션키(Session Key)를 사용하여 이 문제를 해결할 수 있다.
※ 세션키
- 일정시간동안 사용하는 임시적인 키
- 특정 세션을 위한 대칭키로 사용을 한다.
- 완전 순방향 비밀성을 요구할 수 있다.
2) 공개키 + 세션키
- 공개키를 이용하여 암호화하여서 보낸다. 개인키를 사용할 경우 공격자에게 암호문이 들어나게 된다.
- Steps
> Alice > Bob : I'm Alice, R(Session key)
> Bob > Alice : {R,K}Alice
> Alice > Bob : {R+1,K}Bob
- 이는 상호 인증이 아니다.
3) 공개키 + 개인키 + 세션키
* 완전 순방향 비밀성(Forward Secrecy)
- 공격자는 예전에 암호화된 문서를 보관한다. 후에, 키 값을 해독했을때, 이 문서를 복호화하려고한다.
- 완전 순방향 비밀성은 시간이 지나 공격자가 키를 알아내더라도, 암호문을 복호화하지 못하는 것이다.
- 이는 세션키를 이용하여 구현이 가능하다.
ⓐ 단순한 세션키를 이용한 프로토콜
- 공격자는 모든 메세지 정보를 보관한다. 후에 K[ab]를 알게되면, K[s]도 알게된다.
- 완전 순방향 비밀성 보장 X
ⓑ 세션키로 Diffie-Hellman을 사용한다.
- Diffie-Hellman은 중간자 공격의 여지가 남아 있다.
1) 대칭키로 이용하여 Diffie-Hellman에 사용되는 값을 교환한다.
- 공격자가 K[AB]값을 알았다고하자.
> 그럼, 공격자는 g^a mod q와 g^b mod p값을 알게된다. 하지만, a와 b값을 모른다.
> 따라서, Session키를 생성해낼 수 없게 된다.
> 완전 순방향 비밀성 보장 O
2) 공개키를 이용한다.
3) Timestamps 사용
※ Timestamps
- 타임스탬프 T는 현재 시간을 나타낸다.
- 타임스탬프는 교환하는 메세지의 수를 줄일 수 있다.
- 어느정도 까지의 시간 오차를 허용해야 한다.(재사용 공격여부가 있기 때문에 허용 오차를 적절히 맞춰야 한다)
* 공개키를 사용한 인증(PPT 참고)
- Nonce와 함께 서명하고 암호화 하면 안전
- Nonce와 함께 암호화하고 서명해도 안전
- Timestamps와 함께 서명하고 암호화하면 안전
- Timestamps와 함꼐 암호화하고 서명하면 불안전
* TCP와 인증
- TCP 연결도 인증의 일종이다. 하지만 TCP는 인증을 보장하지 않는다.
- TCP 연결시 SEQ번호를 사용하여 인증을 한다. 하지만 이것은 좋지 않는 방법이다.
- 공격자가 SEQ번호가 만들어지는 규칙을 알게되면, 깨지게 되있다.
- 기본적으로 SEQ번호는 랜덤하게 만들어지지만, 이는 OS환경에 의존하여 랜덤하지 않게 된다.
- TCP를 통해서 인증하는 것은 좋지 않는 방법이다.