티스토리 툴바


2009/12/05 18:11 이기적인유전자

최근에 블룸필터가 논문 여기저기 등장하다 보니까 마침내는 이런 무책임한 시도들이 일고 있는 것 같습니다. 우선은 블룸필터와 MAC이 무엇인지 모르시는 분들을 위하여 간략히 설명드리겠습니다.

정보보호 분야에서 MAC은 Message Authentication Code를 줄여 부르는 말로 메시지가 전송 도중에 변조되지 않았음을 보장하는 추가적인 코드입니다. 흔히 비밀키가 들어가는 Keyed MAC과 들어가지 않는 MAC으로 나눠볼 수 있는데, 전자의 경우 메시지 뿐만 아니라 비밀키도 같이 넣음으로써, 비밀키를 알고 있는 사람만이 MAC을 생성할 수 있기 때문에, 비밀키를 소유하고 있는 두 노드만이 생성하고 확인하는 것이 가능합니다. 후자의 경우, 메시지만 입력으로 주게 됩니다. 추가적으로 전자서명(Digital Signature)와 이 Keyed MAC의 차이는 전자서명이 공개키 암호화 기법을 활용하여 공개적으로(in public) 확인 가능하다면 Keyed MAC의 경우 개인적으로(in private)만 확인이 가능합니다. 여기서 이야기하는 것은 Keyed MAC으로 HMAC(Hash-based Message Authentication Code)으로도 불리며 그냥 줄여서 MAC으로 부르도록 하겠습니다. RFC 2104에서 HMAC은 다음과 같이 정의하고 있습니다.

HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m))

블룸필터(Bloom filter)는 1970년 Burton Howard Bloom 이 고안한 통계적 특성을 갖는 데이터 구조의 일종으로써, sparse한 데이터를 저장하고 검색하기 좋은 구조로 flase positive를 갖게 되는 것이 특징입니다. 아래 그림을 보시면 바로 이해가 가실 겁니다.

블룸필터(출처, 위키피디아)


정보보호 분야에서는 서로 다른 몇개의 해시 함수(입력에 다양한 패딩을 줌으로써 쉽게 구현할 수있습니다.)를 사용함으로써, 한 메이지에 대해서 필터 위에 몇개의 점을 0에서 1로 바꾸어 전송하면 반대편에서도 동일한 해시 함수를 돌려 해당 위치가 제대로 1로 셋팅되어 있는지 확인함으로써 메시지를 변조되지 않았음을 확신할 수 있습니다.

자. 여기서 문제입니다. MAC의 경우 엔트로피가 높아서 세상에 알려진 어떠한 압축알고리즘으로도 잘 압축이 되지 않는 것으로 알려져 있습니다.(이는 MAC의 출력이 해시 함수의 출력이기 때문이지요.) 여기에 여러 메시지에 대한 MAC이 존재합니다. 이를 블룸필터를 써서 압축할 수 있을까요?

이런 말하기 참 곤란하지만, 몇몇 분들은 이게 가능하다고 생각하는 모양입니다. 사실 단순하게 생각하면 적당히 큰 블룸필터를 잡고 적당히 많은 해시 함수를 돌리고, 적당히 큰 갯수의 MAC이라면 블룸필터가 더 효율적일 수 있을 것만 같습니다.

그럼 지금부터 꼼꼼하게 따져보겠습니다.

여기에 md5 기반의 MAC이 1개 있습니다.(128비트겠네요.) 조합함수를 이용할 경우, 최대 조합 가능한 경우가 등장하는 경우는 꼭 전체의 절반을 선택하는 경우입니다.(예를 들어, 10개 중에 5개를 선택하는 경우가 10개 중에 4개나 6개를 선택하는 경우보다 경우의 수가 더 큽니다.) 따라서 MAC 하나를 블룸필터로 표시하기 위해서는 132개중에 66개를 선택하는 경우(3.77×10^38)에 128비트의 MAC(2^128 = 3.4×10^38)을 온전히 옮겨올 수 있습니다. 즉, 블룸필터가 132비트에 그중 66개의 비트가 1로 셋팅되어 있을 때 128비트 MAC과 유사한 역할을 수행할 수 있다는 것입니다. 만약 이 경우 블룸필터를 쓸 경우, 4비트나 더 큰 구조체를 사용해야 한다는 것이죠. 또한 엔트로피가 매우 높아서(132중 66비트가 1이므로) 압축이 잘 되지 않습니다. 따라서 1개의 MAC을 대체하기 위해서 블룸필터를 사용할 얼간이는 없다는 거죠.

자, 다음은 여러개가 MAC을 위해서 블룸필터를 사용하는 경우를 생각해봅시다. 앞선 경우와 동일한  블룸필터를 사용했을 때, 무슨 일이 벌어질지는 대충 예상할 수 있습니다. 66개의 해시 함수가 서로 다른 두 메시지에 대해서 충돌을 일으킬테고 어쩌고 해서 66개보다 많지만 132개보다 작은 수의 비트가 1로 세팅되겠네요. 이 경우, 블룸필터가 갖는 경우의 수가 낮아지게 되면서 MAC이 갖는 정보보다 훨씬 많은 정보가 블룸필터에서 사라지게 됩니다! 따라서 여러개의 MAC을 위해서는 블룸필터의 크기를 늘릴필요가 있습니다!

우리가 원하는 결론에 도달하는 여러가지 경로가 있지만 여기서는 아주 단순하게, MAC의 크기가 128비트에서 128×N비트로 증가했다고 가정합시다. 그러면 여기서 해당 MAC의 정보를 모두 갖게 되는 블룸필터의 크기와 해시 함수의 갯수를 생각해보면 됩니다. 블룸필터가 최대 엔트로피를 갖게 될 경우는 해당 블룸필터의 절반이 1로 셋팅되어 있는 경우라고 했고, 언젠가는 블룸필터가 MAC보다 더 효율적으로 되는 경우를 가정하여 블룸필터의 크기를 128×N로 가정할 때, 과연 N이 몇 이상이면 블룸필터가 효율적이 될까요. 수식으로 쓰면,


와 같이 되는 n을 찾으면 됩니다. 아.. 뭔가 대충 복잡하긴 한데, Stirling's approximation을 따르면
 

와 같이 된다고 합니다. 따라서 어떠한 n이 오더라도 앞의 √(1/32\pi n)은 1을 넘지 않습니다. 그런 n은 존재하지 않는 거죠.

따라서 블룸필터로 동일한 정보를 갖는 MAC을 대체할 수 없습니다!

그럼 MAC을 대체한다는 블룸필터 이야기는 도대체 뭐냐하면, 해당 논문들(!)이 원래 기법들이 갖는 보안 수준을 자의적으로 떨으뜨려놓고서는 자기들의 기법이 효율적이다라고 하는 것이죠. 그에 대한 근거 또한 빈약하기 그지 없습니다. 원래의 기법은 128비트의 MAC을 사용하고 자신들은 일정 크기의 블룸필터를 사용하므로, 몇 개 이상의 MAC이 모이게 되면 블룸필터가 효율적이 된다는 겁니다.

저는 블룸필터를 역으로 분석하여 보안성을 추정한 뒤, 그에 필요한 MAC의 크기에 대해서 고민해본적이 있습니다. 결과는 역시나 였지요. 굳이 128비트 MAC을 쓸게 아니라, 보안성을 낮출 수 있다면 그냥 앞의 몇 비트를 잘라서 사용하면 되는 거죠. 이게 더 쉬울 뿐만 아니라 연산도 더 효율적입니다.

앞으로는 이런 말도 안되는 촌극이 없기를 바랍니다.
저작자 표시 비영리 변경 금지
posted by 테일즈집사
2009/11/20 12:38 Open IdeA!

Open IdeA!에 공개된 모든 아이디어는 배타적 사용권을 주장하지 않습니다. 공개된 아이디어를 이용하여 무엇을 하든 자유이지만 해당 아이디어를 이용하여 발생할 수 있는 모든 문제에 대해서는 책임을 지지 않습니다. 아이디어를 이용, 또는 인용하여 출판 또는 발명을 할시에는 사사(Acknolegement)에 출처를 밝혀주어야 합니다.

1. 인지(인식) 기반 인증이 도대체 뭐야!

사용자들이 사용하는 패스워드는 안전하지 않다. 물론, 환경에 따라 다르겠지만, 어느정도로 안전하지 않은가 하면, 성능좋은 컴퓨터로 OFF-LINE 사전 탐색 공격을 할 수 있을 경우, 대략 몇 초 안에 패스워드를 찾아낼 수 있을 정도로 안전하지 않다. 그런데도 우리는 이러한 패스워드를 사용하고 있다. 오! 마이갓.

그런데 왜 패스워드는 안전하지 않은가. 다른 소리 다 집어치우고, 사람이 기억하려고 노력하지 않는 게으른 동물이기 때문이다. 어쩔 수 없는 상황에서는 '복무신조'같이 긴 문장도 술술 외우는게 인간이지만, 자신의 비밀을 지켜줄 소중한 패스워드는 너무나도 허술하게 관리할 정도로 게으르다.

그러면 기억이 용이한 녀석으로 패스워드를 바꾸면 되는 거 아냐?라고 생각했다면 당신은 앞선 연구자들의 뒤를 쫓을 가능성만 있는자다. 그 기억이 용이한 녀석이라는 게 결국 영어 사전에 있거나 국어사전에 있는 단어의 조합이란다. 기껏해야 6만개의 단어의 조합이 길어봐야 얼마나 길겠는가. 그래서 사전 탐색 공격이 가능한거다.

패스워드 자체를 다른, 그러니까 문자나 숫자가 아니라, 다른 개체로 바꾸면 되는 거 아냐?라고 생각한 당신은 앞선 연구자들의 뒤를 쉽게 쫓아갈 수 있는 가능성이 충분하다. 당장 전공을 바꾸고 우리 연구실로 오도록.

그래서 어떤 연구자들은 이미지를 패스워드로 사용하려고 하는 거다. 이름도 붙였다, 'Graphical Password' 라고. 뭔가 있어보이지 않냐. 사실 이러한 연구는 수도 없이 많다. 대충 유명한 것만 이야기하자면, PassFace, PassIcon, PassPoint, De Javu, .... 이름도 참.... 이름만 보고도 어떤 기법인지 알 것같지 않은가. 모르겠다면 다음 그림들을 보자.

PassIcon: 이거 꽤 유명하다

S3PAS: 조금 유명하지만, 우리 연구실에서는 아주 우숩게 작살낸 녀석이다.

PassFace: 하나같이 이모양이다.


2. 거리 기반 인증 기법의 탄생

이렇게 논문이 쓰기 쉬운줄 알았으면, 진작에 이쪽이나 연구할 걸 하는 생각도 들때가 있다. 뭔가 세상은 불공평한 느낌이다. 그래서 나도 만들어보기로 했다. 남들이 하는데 내가 못할 이유는 없잖아? 그리고 무심코 덤볐다.

아놔.

만만찮다. 그래도 이런 저런 생각하면서 알게 된게 많다. 겉으로 보이는 것보다 저러한 기법들이 약하다는 거다. 결론적으로 말하자면, 사람의 패스워드를 입력하는 과정에서 정보의 누수가 생기고, 그 정보의 누수가 모여서 패스워드가 드러날 수밖에 없는 구조를 가지고 있다. 처음부터 고려대상이 아닐수도 있지만, 이왕하는 거 안전하게 설계했으면 좋았을 텐데, 왜 이러는지 알 수가 없었다. 그냥 어느 단계에서 생각하기를 그만 둔 느낌이랄까.

이미지를 패스워드 대신 사용하려고 할 때, 인간의 기억력 어쩌고를 떠나서, 사람의 패턴, 주변 환경 어쩌고를 떠나서 반드시 고려해야하는 상황이 있다.

  1. 사진의 개체를 패스워드로 사용해서는 안된다.: 개체의 노출빈도가 다르고 지나치게 많은 개체가 현실 세계에 존재하기 때문에 빈도수 계측 공격(Frequency Attack)에 특정 개체가 쉽게 노출된다. 또한 컴퓨터에게 해당 개체의 존재를 일일이 가르쳐야 한다. 노가다의 결정판 같은 짓이다.
  2. 모든 인증에서 동일한 패스워드 후보 이미지 셋을 사용해야 한다.: 그렇지 않으면 역시 혼자서 튀는 이미지가 있다. 유독 그 이미지의 노출이 많다면 당연히 그게 패스워드라고 의심해 봐야 하지 않을까.


이 둘을 만족하는 방법을 찾아야 앞선 연구자들의 전철을 밟지 않을 것 같았다. 그게 최선이라고 생각했다. 하루, 이틀, 사흘, 나흘, 한달, 두달, 세달.....

아놔!

못 찾겠다. 그러니까 괜히 앞선 연구자들이 저따구 물건을 내놓은게 아니라는 거다. 그들도 나름 머리 싸매고 고민하고, 그래서 결론적으로 그래도 없는 것보다는 낫지 않을까 하는 생각에서 내놓은 거란 거다. 하아. 그러다가 저 PassFace를 보면서 한숨을 쉬었다. 얼굴 인식할 때에는 군순이도 내 옆에 있었는데, 지금은 아무도 없구나.....

얼굴인식에서는 가장 가까운 것만 찾으면 되었는데.....

이 작은 한 토막의 지금 이 글을 존재하게 했다.


3. 거리 기반 인증 기법의 소개

절대적인 한 점을 찾으려니까 문제가 되는 거다. 대충 거기 인것 같은 것을 찾게 하면 되지. 좋아, 이제 뭔가 일을 풀어갈 수 있을 것 같다. 그러니까, 사람의 인식과 컴퓨터의 인식이 대충 비슷하면 되는 거다. 솔직히 지금도 나쁘지 않은 생각 같다. 그림을 보면서 이야기를 계속 하자.

거리 기반 인증 기법: 예를 들자면, 얼굴 같은 걸 이용할 수 있다.


위 그림은 실제로 연구실 내부에서 교수님께 상담할 때 사용했던 이미지다.

사용자는 우선 인증의 비밀로써 사람의 얼굴 1개와 숫자로 이루어진 패스워드를 기억하고 있다. 서버(사용자를 인증한다. 그냥 편의상 서버라고 하자.)는 자신이 가지고 있는 얼굴 DB에서 무작위로 10개의 이미지를 뽑아 화면에 뿌려주고, 사용자의 입력을 기다린다. 사용자는 우선 자신의 아이디를 입력하고, 자신의 비밀번호 첫번째 자리와 자신이 기억하고 있는 얼굴과 가장 유사한 얼굴(도대체 모르겠으면 리로드 버튼을 누른다.)을 찾아 그 얼굴에 적혀 있는 숫자와 더하기 연산을 수행한다. 그리고 그 중에서 1의 자리만을 취하여(예를 들면, 5+7 = 12이지만 여기서는 2이다.) 패스워드 폼에 입력한다. 이 작업이 끝나면 서버는 다시 10개의 얼굴을 다시 뽑아서 화면에 출력하고 사용자의 다음 입력을 기다린다. 이러한 작업을 비밀번호가 끝날때까지 반복한다.

외부에서 이를 지켜본 공격자라고 하더라도 사용자가 어떠한 얼굴을 선택했는지 알 수 없기 때문에, 패스워드가 무엇인지 알지 못한다. 가장 가까운 얼굴을 선택하는 것이므로, 화면에 출력되는 얼굴의 분포로부터 공격자가 알아낼 수 있는 정보는 없다. 얼굴을 기억하고 있어야 하는게 조금 부담이긴 하지만, 못할 정도는 아닌 것 같았다. 어느정도 실험도 해서 보완할 건 보완하고 하면 괜찮은 기법이 될 것 같았다.
 
그러나 교수님 曰,

"사람이 비슷하다고 판단하는 것과 컴퓨터가 비슷하다고 판단하는 것이 일치한다고 보장할 수 있니?"

참, 이때 대답이라는 게 궁색했던 것 같다.

"사용자 실험 해보면 알 수 있겠지요. 얼굴 인식이야 대충...."

덕분에 실험은 영원히 중지되었다. 될지 안될지도 모르는 실험에 시간을 투자한 여력이 연구실에는 없다는 말이었다.


4. 마음 껏 가져다 써라.

어차피 실험도 못할 거.... 위와 같이 머릿속으로만 존재하였던 기법을 공개하는 바이다.
이걸 만든지는 벌써 몇 개월이 흘렀지만, 아무도 신경도 안쓸거고.... 이미 누군가 만들었을 수도 있지만, 아직까지 그러한 논문을 본 적이 없기 때문에, 아마도 여기에, 도대체 몇 명이나 볼지 안볼지 모르는 블로그에 공개하는 것이 최초라고 생각한다.

까잇꺼. 그냥 마음 껏 가져다 써라.
저작자 표시 비영리 변경 금지
posted by 테일즈집사
2009/07/12 14:00 사람보안연구실

ActiveX(액티브엑스)는 마이크로소프트사가 개발한 재사용 가능한 객체지향적인 소프트웨어 구성 요소를 개발하는 데 사용되는 기술이다. ActiveX는 OLE 자동화의 다른 이름이며, 이 둘은 서로 관련되어 있다. 자동화는 전반적인 기술을 가리키며, "ActiveX"는 자동화를 통해 만들어지고 제어되는 객체를 말한다. 대부분 ActiveX는 인터넷 익스플로러의 플러그인을 만드는 데 사용된다.

ActiveX 컨트롤은 자바 애플릿과 비슷하다. 그러나 ActiveX 컨트롤은 자바 애플릿과는 다르게 코드 실행에 대한 제약이 적기 때문에, 보안적으로 취약해 소프트웨어와 데이터를 손상시킬 수 있는 위험성이 있다. 이를 위해 마이크로소프트는 등록 시스템을 개발하여, 브라우저가 ActiveX 컨트롤을 다운로드하기 전에 해당 컨트롤의 디지털 서명과 인증서를 확인하고, 적절한 프로그램인지 인증할 수 있게 하였다.

- Wikipedia 한글 버전에서

ActiveX는 사실 브라우저한테 엄청난 권한을 줘버렸습니다. 그러니 보안 문제에 취약할 수밖에 없습니다. 다른 브라우저처럼 Plugin을 사용하면 오늘날 한국에서와 같은 짜증나는 상황을 피할 수 있었을 겁니다. 원칙적으로 ActiveX의 사용은 지양하는 것이 옳습니다.

하지만 마치 ActiveX가 모든 보안 문제의 원흉인 것처럼 말하는 것에 대해서는 동의하지 않습니다. 또한 ActiveX가 보안성 향상에 도움을 주는 측면도 동시에 있는 것을 간과해서는 안됩니다. 또한 보안성 향상에 도움을 준다고 했지만, 그 방향이 올바른 방향은 절대로 아니라는 것을 잊지 말아야 합니다.

이게 뭔 양비론의 극치를 달리는 소리냐면...

ActiveX를 줄였다고 해도 보안 문제는 여전히 계속 될 것이라는 겁니다. 자, 여기 여러분이 악성코드를 만들어 배포하는 해커라고 가정해봅시다. 여러분은 ActiveX를 더이상 사용할 수 없습니다. 그럼 어떻게 하시겠습니까.

다른 방법을 쓰면 됩니다.

메일에 첨부되어 마치 좋은 프로그램인것처럼 속이는 수법은 지금도 사용되고 있는 수법입니다. 메신저로 친구인 척 악성코드를 전송하는 수법도 전혀 새롭지 않습니다. 홈페이지에서 무슨무슨 프로그램의 크랙이라고 해서 악성코드를 배포하는 것도, P2P에서 악성코드를 다른 프로그램으로 속여서 올리는 것도 현재 사용되고 있는 방법입니다. 사이비 보안업체에서 악성코드를 지들이 만들어 배포하고 지들이 치료하고 돈 받은 일은 아직도 유명합니다.

ActiveX를 못 쓴다면 악성코드 배포에 약간의 차질을 빚을 지언정 크게 어려워지거나 아주 못하는 상황에 빠지진 않는다는 겁니다. 그런데도 이놈의 기자놈들이나 MS 안티팬보이들은 그놈의 ActiveX 타령은 죽어라고 합니다. 마치 모든 것의 원융은 ActiveX에 있다는 듯이 말입니다.

현재 은행 사이트에서 ActiveX를 사용하는 이유는 단순합니다. '100% 안전하진 않다'라는 명제 때문인데, 그나마 자기들이 뭔가를 만들어서 올려야 안심하겠다는 거죠. 이 기도 안차는 주장은 한 편 어느정도 타당합니다. 사용자가 어떠한 환경에서 자신들의 사이트에 접속할지 장담하지 못한다는 겁니다. 아무리 웹 사이트가 완전무결하다고 그 사이트를 접속하는 웹브라우저가 안전한지는 장담하지 못합니다. 예를 들어 보겠습니다.

현재로서는 그런 일이 거의 없지만, 어떠한 해커가 파이어폭스의 소스코드에 패스워드 필드를 자신에게 전송하는 코드를 삽입하고 여기저기 손봐서 마치 자신이 만든 웹브라우저인것처럼 배포했다고 가정해보죠. 사용자는 어떠한 징후도 없이 평온하게 인터넷 뱅킹을 하고 아무것도 느끼지 못한채 브라우저는 닫았습니다. 단지 다음 날 내 계좌에서 돈이 없어졌을 뿐입니다. 부랴부랴 경찰에 신고했더니 은행에서 돌아온 답변은 정상적인 절차로 이체가 되었다는 겁니다. 사이버수사대에 신고하고 브라우저 배포자를 찾으려고 했더니 유감스럽게도 그게 중국이었던 겁니다.

이런 극단적인 경우에 ActiveX는 어느정도 사용자의 환경을 지켜줍니다.

말도 안되는 소리하고 있네! 하시는 분들 계실텐데요. 보안이라는 것은 사용자가 편하면 편할 수록 더 쉽게 뚫리는 녀석입니다. 사용자가 Windows 안쓰고 MAC OX나 리눅스 쓰면 보안 문제가 사라질까요? 사용자가 IE 안쓰고 FF나 사파리나 Chrome 쓰면 보안 문제가 사라질까요? 모르긴 몰라도 그렇지는 않을 겁니다. 다운 받아 실행시켜버리는 사용자까지 무슨 수로 책임을 지라는 말입니까.

이렇게 글을 써놓고 보면, 저 새끼 마이크로소프트 추종자 새끼..... 라고 하는 분들 계실테지만, 다시 한 번 이 글의 주제를 말하자면, '사용자의 보안 의식이 높아지지 않는 이상, 아무리 ActiveX를 쓰지 못하게 해도 결과는 같다'입니다.

ActiveX의 사용은 분명히 줄여야 합니다. 여러 곳에서 보안 문제가 있는데, 이걸 그냥 놔둘 수는 없습니다. 그렇지만 ActiveX만 없어지면 보안 문제가 한결 나아질 것 같은 착각은 해서는 안됩니다.

ps. 우리나라 대부분의 보안업체는 사실상 ActiveX를 만드는 회사들이라고 하는 군요. 이거야 말로 진정한 아이러니가 아닐까요?
저작자 표시 비영리 변경 금지

'사람보안연구실' 카테고리의 다른 글

그 놈의 ActiveX 타령  (0) 2009/07/12
웹 마스터 vs. 보안 전문가  (0) 2009/04/12
너는 이미 낚여있다.  (0) 2009/04/08
내가 낚였는데, 네 책임이다.  (0) 2009/04/08
해커와 크랙커  (0) 2009/04/08
보안, 그 진실과 오해  (0) 2009/04/08
posted by 테일즈집사