Yellowbirds

Kirsten Ferguson-Boucher, "Cloud Computing: A Records and Information Management Perspective," IEEE COMPUTER, Nov/Dec 2011. 을 읽고 남기는 글입니다. 감상문이라서 그런지 내용에 특별한 주제는 없습니다. 클라우드 서비스에 대한 개인적인 견해로 읽어주시면 좋겠습니다.

"클라우드 컴퓨팅(cloud computing)은 새로운 기술은 아닙니다.  기존에 있던 기술을 바탕으로 컴퓨팅 자원을 전달하는 새로운 방식을 제안하는 것입니다."

라고 글에서는 말하고 있습니다. 여기서 말하는 기존에 있던 기술은 가상화(virtualization)가 가장 적합하겠네요. 예전부터 지금까지, 호스팅 서비스와 같은, 컴퓨팅 자원 제공 서비스는 있어 왔습니다. 하지만 가상화의 발전으로, 이런 서비스를 제공하는 비용이 더욱 낮아졌다는 점이, 더 많은 기업이 데이터를 저렴하게 보관해주겠다 혹은 원격으로 소프트웨어를 제공해주겠다는 세상으로 이끌고 있는 것 같습니다.

웹 검색으로 시작한 구글은 일반 사용자들에게 가장 친숙한 클라우드 서비스 업체라고 생각합니다. 많은 사람들이 개인 이메일을 구글에게 맡기고 있고, 문서를 독스(docs)에 보관하고 일정을 캘린더 서비스에서 관리하고 있습니다. 피카사를 통해 사진을 보관하기도 하지요. 그들의 비지니스 모델까지 여기서 언급할 필요는 없겠습니다만 최근 정식으로 출시된 크롬북만 보아도 그들이 제안하는 - 그리고 이끄는 - 미래를 볼 수 있습니다. 웹 브라우저 하나 달랑 떠 있는 노트북을, 왜 돈을 주고 사는가 싶은 사람이 아직은 많을 것입니다만, 우리가 노트북을 사용하면서 대부분의 시간을 웹 브라우저 상에서 보내고 있다는 것을 깨닫는다면, 그리 이상하지도 않습니다.

이건 오래전부터 제가 생각하고 있는 것인데, 웹 브라우저 상에서 게임이 잘 동작하고 프로그래밍이 가능해지면, 정말 그런 세상이 와도 거부하기 힘들 것 같습니다. 플래시 게임은 이미 많이 있고, WebGL을 통해 더 화려한 게임들도 동작하게 되겠지요. 프로그래밍은 아직 좀 멀어보입니다만 일반 사용자들이 개발할 일이 많지는 않으니 프로그래밍이 주요 걸림돌이 되진 않겠네요. 물론 대세가 될 확률은 아주 낮습니다만, 그래서 크롬북이 뜬금없이 보안을 주 강점으로 내세우고 있긴 합니다만, 약간의 마켓 쉐어를 가져도 이상하진 않을 수준에 현재 도달해 있다고 생각합니다.

VMWare 같은 프로그램을 써보면서 많이 놀랬던 건 그 기술의 발전이었습니다. 너무나도 빠르게 좋아지고 있었거든요. 얼마전에 보니 현재 쓰고 있는 운영체제의 상태를 그대로 가상화할 수 있더군요. 어딘가 출장을 갈 때 이미지를 떠서 디스크에 담고, VMWare 플레이어로 다른 컴퓨터에서 가동시키면 내 작업 환경을 그대로 쓸 수 있을 것입니다. 물론 출장에서 돌아와서 가상화된 이미지를 다시 내 컴퓨터와 동기화 시키는 것은 좀 어려운 작업이 될 수도 있겠습니다만, 출장지에서 많은 작업을 하진 않을테니 그 정도는 수동으로 해도 괜찮겠지요. 이 정도의 기술 발전은 stateless PC라고 부르기도 하는, 이미지에 내 컴퓨터를 담고, 어떤 PC든 가서 부팅하여 사용하는 그런 식의 세상을 만들 수도 있겠다는 생각이 듭니다. 좋은 하드웨어를 저렴한 가격으로 사용할 수 있게 하는 기업이 수 많은 stateless PC를 여러 곳이 넓게 제공하기만 한다면 말이죠.

사실 가상화는 앞서도 언급했듯이 서버 쪽에서 훨씬 이득이 많습니다. 컴퓨팅 자원이 정해진 하드웨어 상에서 상황에 맞게 아주 효율적으로 가상화 이미지들이 옯겨 다닐 수가 있게 되고, 덕분에 하드웨어를 백퍼센트 활용할 수 있다는 점에서 말이죠. 가상화의 발전으로 서비스 제공자는 싼 가격에 사용자를 끌어들이고 사용자도 자신이 직접 하드웨어와 네트워크를 구입하여 서비스를 설정하는 것보다 클라우드 서비스를 이용하는 것이 훨씬 저렴한 시대가 되었습니다. 구글 어플리케이션의 경우, 도메인만 가지고 있으면 50인까지 무료로 제공해주고 있지 않습니까? 작은 사업체에서는 메일 서버, 문서 공유 서버, 홈페이지 서버를 둘 필요도 없는 것이지요.

갑자기 내 회사가 잘 되어 사용자가 폭주하고 사원이 늘어나도 일은 쉬워집니다. 서버를 증축하고 네트워크 대역폭을 늘리고 할 필요가 없이 클라우드 서비스에 돈을 좀 더 납부해주면 알아서 해주니까요.

데이터를 잃어버릴 일도 별로 없습니다. 클라우드 서비스 업체들은 백업에 열중할테니까요. 만약 데이터를 분실하는 사건이 발생하고 이것이 알려지면 사람들은 그 업체를 떠날 것이기 때문에 업체들은 최선을 다할 것입니다. 그리고 그들은 전문가를 뽑아서 관리할 것이기 때문에 데이터 자체의 안전성(integrity) 뿐만 아니라 보안(security)에서도 유리할 가능성이 높습니다.

물론 안 좋은 점도 많겠지요. 우선 클라우드 서비스 업체가 항상 서비스를 잘 제공해준다는 보장(availability)이 없습니다. 가끔 지메일이 열리지 않아 답답함을 느끼는 사용자들이 계실 것입니다. 많은 클라우드 서비스 제공자들이 광고를 할 때 99% 또는 99.99%의 가용성(availability)을 제공한다고 하지만 그건 모를 일이지요.

클라우드 서비스 업체를 믿을 수 있을 것인가 하는 문제도 있습니다. 그들이 마음만 먹으면 우리 회사의 기밀 문서를 열어볼 수 있을 것이고, 내 메일을 읽을 수도 있을 것입니다. 이런 점에서 Free Software Foundation의 리차드 스톨만 씨는 클라우드 서비스에 대한 큰 반감을 표현하기도 했지요. 개인적으로는 저 역시 이 문제가 클라우드 서비스를 좋게 보기 힘든, 클라우드 서비스가 가지는 가장 큰 단점으로 보고 있습니다.

제가 보안 전공이라 그럴 수도 있겠습니다. 이걸 해결하기 위해서는 모든 것을 개인이 관리하고 네트워크를 이용할 때는 항상 암호화/복호화 작업을 스스로 수행해야 하는데 그렇게 할 사람이 많을지는 모르겠습니다. 예를 들어, 내 카카오톡 메시지를 누가 보면 안 되기 때문에, 메시지를 보낼 때마다 내 폰이 암호화하고 메시지를 받을 때마다 복호화한다면 속도도 느리고 배터리도 더 빨리 닳게 되는 것이지요. 그런 서비스가 성공할 가능성이 높아 보이진 않습니다. 사용자 참여의 문제 외에도 사업자 측에서의 비지니스 모델 상 이런 서비스가 나오긴 힘들긴 합니다. 여기에 대한 이유까지 이야기하기엔 글이 너무 길어졌네요.

다음의 짧은 논문을 읽고 떠오른 생각들 정리해본다. Vassils Kostakos, et al. "NFC on mobile phones: issues, lessons, and future research", 2007

NFC의 편의성

두 폰이 서로 데이터를 주고 받을 일이 있을 때, 블루투스나 NFC를 이용할 수 있다. 논문에서는 두 가지를 이용해서 전화번호를 교환하는 프로그램을 각각 작성한 후에 사람들에게 얼마나 편리한지 질문했다. (실험 결과에 대한 구체적인 이야기가 없었지만!) 전반적으로 NFC가 편리하다는 평이었다고 한다. 그 첫 번째 이유는 사용자가 별로 할 일이 없다는 것. 블루투스는 기기 간의 페어링(pairing)을 해야 한다. 반면 NFC는 접촉만으로 바로 데이터 교환이 가능하다. 단, NFC는 읽고 쓰기 중 하나를 선택하여 단방향(one-way) 통신만 가능하기 때문에 사용자가 개입하여 내가 데이터를 받을 것인지 줄 것인지를 선택해야 하는 문제가 있는데, 여기서는 두 장치가 서로 번갈아가며 주고 받기를 서로 알아서 하도록 프로그래밍했기 때문에 사용자가 할 일이 거의 없었다. 사용자 입장에서는 폰을 서로 갖다대는 것만으로 데이터 교환이 되는 것이 신기하고 편리했을 것이다. 그리고 이것이 두 번째 이유로 연결되는데, 터치로 데이터를 교환하는 것은 블루투스를 이용한 원격(물론 멀지 않은 거리지만) 교환보다 더 원시적인 방법처럼 보이지만 오히려 '중간에 다른 디바이스가 끼어들어 내 정보가 세어나가진 않을까?' 하는 우려를 줄여준다. 내가 보고 있는 상대방과 정확히 정보를 교환하고 있다는 느낌을 사용자에게 주는 것이다. NFC가 근거리 통신 방식이기 때문에 보안 측면에서 유리하다는 것은 이미 많이 언급된 내용이다.

QR code와의 비교

NFC를 사용하면 태그를 폰에 접촉하는 것만으로 바로 데이터를 가져올 수 있다. 반면 QR code를 읽기 위해선 카메라를 이용하는 리더 앱을 가동해야 하는 번거로움이 있다. 얼마전에 코엑스에 갔을 때 재밌게 본 시연이 있었는데, TV에서 나오는 아이유의 음악에 폰이 가까이 두니 관련 링크를 열어 보여주는 것이었다. 물론 여기에 사용된 아이유의 음악은 사람이 듣지 못하는 주파수 영역에 데이터를 주입해서 보내는 것이었고 폰은 그것을 듣고 데이터를 뽑아내는 것이었다.  아이디어는 재밌으나 폰에서는 데이터를 해석할 수 있는 앱을 역시 가동하고 있어야 한다. 이 앱은 카메라 대신에 마이크를 켜두고 있어야 한다는 것이 차이점일 뿐이다. 결국 사용자 편의성 면에서는 QR code와 별다른 차이가 없다고 볼 수 있다.

NFC의 단점? 1. 화면과 멀어지는 사용자

태그를 읽기 위해 - 혹은 다른 NFC 장치에게 데이터를 전송하기 위해 - 서는 접촉을 해야 하므로, 내 폰을 내 눈과 먼 거리에 두어야 할 경우가 발생할 수 있다. 데이터 교환 상황이나 완료 여부, 에러 발생 여부 등을 알아보기가 다소 힘들 수 있다. 물론 예로 든 수준의 알림은 화면에 큰 글자를 출력하거나 깜빡임을 이용하거나 소리를 내거나 진동을 발생시킴으로써 해결할 수 있다. 그러나 화면을 터치함으로써 어떤 interaction을 이어나가야 하는 경우라면 작업을 진행하기에 까다로워질 수 있다.  선택 버튼을 눌러야 한다거나 패스워드를 입력해야 한다거나 따위가 예가 될 수 있다. 결론적으로 interaction이 많은 작업보다는 접촉만으로 바로 데이터가 교환되고 바로 통신이 종료되는 어플리케이션이 적합하다.

NFC의 단점? 2. 악성 데이터

이 문제는 사실 NFC 만의 문제는 아니다. NFC를 이용할 때도 역시 조심해야 한다 정도가 좋겠다. 태그로부터 읽히는 정보에는 스팸이나 악성 페이지로의 링크가 있을 수 있어 주의해야 한다. 조금 더 주의를 기울여야 하는 부분은 태그로부터 정보를 읽어오는 것뿐만 아니라 어떤 명령을 받아들일 수도 있다는 점이다. 어떤 사람의 명함에 폰을 대면 바로 그 사람에게 전화가 걸리거나 이메일을 보내거나 문자를 보낼 수 있도록 폰이 동작하는 것이 그 예가 되겠다. 접촉을 하는 즉시 폰이 어떤 행위를 하게 되는 것은 편리할 때도 많지만 악성 행위를 동작시키는 태그가 이용될 수도 있기 때문에 주의해야 한다

다음 논문을 읽고 남기는 생각.

Csapodi, M.; Nagy, A.; , "New Applications for NFC Devices," Mobile and Wireless Communications Summit, 2007. 16th IST , vol., no., pp.1-5, 1-5 July 2007
doi: 10.1109/ISTMWC.2007.4299077
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4299077&isnumber=4299029

NFC의 장점으로 매번 이야기하는 것은

• 네트워크를 따로 구성하지 않아도 된다는 것
• 비교적 빠르다는 것
• 아주 근접한 상태에서만 통신이 되기 때문에 안전하다는 것
  

정도이다. 간단히 줄이면 "Simple and Secure". 이러한 장점으로 기기 간의 상호 인증을 할 때 NFC는 좋은 수단이 된다. 직접 터치하는 방식이기 때문에 man in the middle attack, eavesdropping에 다른 방법론보다 비교적 강하다. 기기 간 상호 인증 (키 교환)을 자연스럽게 사람이 개입하여 인증해주게 되는 것이다.

NFC는 2002년 가을 Sony와 Phillips, 두 회사가 협정한 기술이라 한다. 둘은 ECMA Internation에 표준 초안을 제출하는 것을 시작으로 표준화를 진행했고 두 개의 프로토콜 NFCIP-1, NFCIP-2가 각각 ISO/IEC 18092, ISO/IEC 21481로 제정되었다. NFC 포럼이 2004년 3월 설립되어 HP, NXP (Phillips), Sony, Texas Instruments, Nokia, NEC, Samsung, Motorola, MasterCard, VISA, Panasonic, Microsoft, Gemalto, Vodafone, Siemens 등이 참여하고 있다고. 모바일 통신 업체 그리고 통신 기기를 만드는 업체가 포함되어 있다. 개인적으로 재밌는 건 MasterCard, VISA가 참여하고 있는 것인데, 모바일 결제를 할 때 비교적 안전하고 신속하게 통신 과정을 진행 할 수 있다는 점에서 NFC가 모바일 결제 분야에서 핵심 기술로 인정받고 있다는 것을 알 수 있다.

NFCIP-1 프로토콜은 Philips의 Mifare 기술과 Sony의 FeliCa contactless IC card 기술과 호환된다고 한다. 각자 기술을 개발하다가 둘을 아우르는 프로토콜을 만들게 된 것 같다. 두 기술은 이미 교통 카드나 출입 보안 카드 등에 사용되고 있었다고 한다.

NFC의 접촉 범위는 20cm 정도.

많은 양의 통신이 필요하거나 빠른 통신이 필요한 경우 블루투스나 와이파이 등 기존 기술을 사용하는 것이 좋은데, 이런 설정을 두 기기가 빠르게 공유하기 위해서 NFC가 역시 좋은 수단이 된다.

NFC가 passive mode를 제공한다는 것도 장점이다. 모바일 기기는 배터리에 민감하기 때문에 one party의 파워로 양쪽이 통신할 수 있는 것은 큰 장점이다. NFC 통신을 할 때 한 쪽이 모바일, 한 쪽이 전원을 공급 받는 고정된 기기인 경우 이 성질은 큰 장점으로 작용할 것이다.

NFC가 탑재된 두 기기 간의 데이터 교환이 NFC를 이용한 주된 어플리케이션이지만 조금 구체적으로 응용한 예가 논문에 몇 가지 언급된다. 그 중 하나 재밌는 것은, PC와 연동하여 내 패스워드 정보 - 를 비롯한 웹 폼을 채울 수 있는 정보 - 를 내가 폰을 PC와 접촉시켜 둔 동안에만 해당 PC에서 적용되게 하는 것이다. 도서관 등의 공공 컴퓨터에 갔을 때 웹 서핑을 하게 되면 모든 웹 사이트에서 로그인을 다시 해야 한다. 귀찮지만 당연히 해야 하는 작업이다. 내 폰을 PC 옆에 마련된 NFC reader 위에 올려둠으로써 모든 로그인 절차가 자동으로 된다면 편리하지 않겠는가? 물론 폰을 분실했을 경우, 도난 당했을 경우가 아주 위험해진다.

위의 예처럼 터치를 통한 사용자 또는 기기 인증의 개념이 도입되면 폰이 일종의 보안 토큰이 되는 것이다. 클라우드 컴퓨팅이 발전하고 점차 컴퓨팅 기기는 네트워크가 가능한 더미 터미널이 되어가는 추세(크롬북이 얼마나 성공할 지는 모르지만) 라고 봤을 때, NFC 덕분에 거의 모든 사람이 소지하고 있는 스마트폰을 보안 토큰으로 활용할 수 있게 된 점은 확실히 사용자 편의성을 높이는데 한 몫을 할 수 있을 것이라 생각한다.

지난 글에서 사물에 RFID tag를 부착하고 그것들을 coupling해서 함께 다녀야 하는 물건들 중에 무언가가 누락되거나 내것이 아닌 물건이 내게 딸려오는 등의 사고를 막는 이야기를 했었다. 지난 글의 저자들이 조금 더 예전에 다른 제목의 논문을 또 낸 것을 확인하고 읽어보았는데, 내용상 거의 차이는 없었다. 논문 제목은

    Ubi-Check - A Pervasive Integrity Checking System
    Michel Banatre, et al.
    INRIA Rennes / IRISA

이들의 연구를 보면 아이디어는 단순하지만 실제 구현을 직접 해봤다는 점에서 의미가 있어 보인다.

모든 태그를 빠르고 정확하게 인식시키는 것이 상당히 어렵다고 한다. 여러 명의 사람이 문을 통과할 경우 사람들이 지니고 있는 물건에 붙어 있는 모든 태그를 동시에 읽는 것이 만만치 않은 모양이다. 논문에서는 한 명씩 통과하는 것을 권고하고 있고, 사람이 들어오기 시작한 후 다음 사람이 들어오기까지 2초 ~ 3초의 간격이 있으면 좋다고 말한다.

인식률을 높이는 것이 결국 어렵다는 결론이 나온다면, 문을 회전문 방식으로 만들고 한 명씩 들어가게 하는 것도 방법일 듯 하다. 회전문은 개별 공간이 나름 밀폐된 공간이므로 reader를 여러 군데에 부착하기도 좋을 것 같고, 특수한 재질로 설계한다면 칸마다 Faraday cage와 같은 효과를 낼 수도 있지 않을까 생각이 든다.

회전문이 아니면 어떨까. 일반적인 건물의 문이라면 여러 사람에 동시에 들어올 것이다. 사람마다 미리 coupling된 물건들을 가지고 있을 것이므로 사물이 어떻게 grouping되었는지는 coupled signature (group의 ID를 hash하여 얻는 값)을 보면 될 것이다. 같은 그룹은 같은 signature를 가지고 있을 것이니까. 하긴, 문제는 인식률이라고 하니까.

또 하나 생각해볼 수 있는 것은 문을 통과할 때 이 coupled signature가 틀리는 경우다.

1. 내가 1개 이상의 내 물건을 어딘가 다른 곳에 두고 문을 지나는 경우
2. 내가 1개 이상의 타인 물건을 지니고 문을 지나는 경우
3. 내가 1개 이상의 내 물건을 빠뜨리고 1개 이상의 타인 물건을 지니고 문을 지나는 경우
   

정도로 구분해볼 수 있겠다. 3번과 같은 케이스는 논문에서 언급이 되지 않고 있는데 내 카메라와 다른 사람 카메라가 똑같아서 내 것인줄 알고 가지고 가는 경우를 생각해볼 수 있다. 의외로 빈번히 발생할 수 있다고 본다.

각 케이스에 대해 정확히 판단을 내려줄 수 있는 방법은 없을까? 논문에서는 특정 디바이스에 전체 그룹의 구성원 수를 기록해둬서 그것을 이용해 판단한다는 이야기가 있다. 예를 들어 내가 지니고 있는 물건이 5개인데, 문을 나갈 때 6개의 사물이 인식이 되면 2번의 케이스라고 판단하고, 3개의 사물이 인식되면 1번의 케이스라고 판단한다는 것이다. 그러나 이것은 3번 케이스를 전혀 고려하지 않은 이야기다. 즉, 논문은 각 케이스를 구분하는 방법을 정확히 제시하지 못하고 있다. 전체 ID를 모아서 해시한 값을 모든 태그나 나눠서 가지기 때문에 당연한 결과인데, Bloom filter 등의 기법을 도입하여 다른 그룹 멤버에 대한 정보도 일부 가질 필요가 있다고 본다. 물론 각 케이스를 구분해야 하는 상황에서만. 구분할 필요 없이 이상이 있다 없다만으로 충분하다면 논문이 제시하는 이야기로도 충분히 해결이 된다.

논문을 보니 이것을 실제로 구현해서 전시회도 했다고 하는데, 이렇게 직접 구현하고 실험하고 하는 모습이 상당히 좋아보인다. 물론 귀찮겠지만 :p

다음 논문을 읽고 감상을 남긴다.

Pervasive Integrity Checking With Coupled Objects
Paul Couderc, et al.
INRIA Rennes, Compus Universitaire de Beaulieu, FRANCE

이번에 ANT 2011이라는 학회에 운 좋게 참석하게 되었다. 캐나다의 나이아가라 폴스에서 개최되는 학회라 나이아가라 폭포까지 감상할 수 있었다. 정말 운도 좋다. 심지어 학회장이 폭포가 보이는 거리에서 100미터 정도밖에 떨어지지 않은 거리.

이 학회에서 위 논문의 발표를 들을 수 있었는데, 들었던 발표중 가장 기억에 남는 아이디어라 한국에 도착해서 프로시딩 CD를 뜯고 가장 먼저 읽어보게 되었다. 이 논문에서 이야기하는 주 아이디어는 RFID tag coupling이다. RFID tag에는 고유한 아이디가 있을 것이다. RFID가 막 뜨기 시작할 때 많이 언급된 어플리케이션으로 물류가 있었는데, 모든 아이템에 태그가 붙어 있으면, 리더가 원거리에서도 사물을 읽을 수 있으므로, 태그마다 고유 아이디를 가지고 있다면 해당 물품을 정확히 인식할 수 있다는 것이었다. 태그에 아이디는 MIT에서 제안한 Auto-ID 같은 것을 쓸 수 있겠다. 이 논문에서는 EPC ID라는 것을 언급했는데 96 bits라고 한다.

논문에서는 개별 사물의 인식이 아닌 그룹 구성원에 대한 인식에 초점을 맞춘다. 그룹 구성원의 변동이 없어야 하는 상황에 대해 언급하고 있는데 생각외로 이렇게 시각을 바꿈으로써 적용해볼 수 있는 어플리케이션이 많아지더라.

• 유치원 선생님이 박물관에 아이들을 데려갔다고 하자. 30~40명 정도를 데리고 다녀야 하는 경우 한 두 명이 이탈하는 것을 파악하는 것이 쉽지 않다. 아이들에게 태그를 모두 부착해두면 어떨까? 선생님이 쉽게 이탈자 여부를 파악할 수 있지 않을까?
• 식당과 같은 곳에 갔을 때 내가 가지고 들어갔던 사물들(핸드폰, 가방, 노트북, 지갑 등)을 식당 입구에서 체크해둔다. 내가 식당을 빠져나갈 때 '물건을 두고 나오셨습니다!'라고 알려줄 수 있다면 좋지 않을까? 식당보다 택시를 예로 든다면 더 좋겠다. 택시에 뭔가 떨어뜨리고 나오는 것은 생각만해도 아찔하지 않은가!
  

요즘 NFC가 사물 인식에 대세로 떠오르고 있지만 이 경우에는 RFID가 더 편할 듯하다. 사용자가 특별히 인식하지 않고도 서비스를 받을 수 있어야 하니까.

여기까지 이야기를 들으면 서비스 제공자가 사용자가 가지고 있는 태그들을 특정 시점에 모두 스캔하여 보관하고 있다가 후에 체크하는 방식을 취하면 되겠다고 생각할 수 있다. 예를 들어 내가 식당에 A, B, C, 세 가지 물건을 가지고 들어갔다면 식당은 이 정보를 보관하고 있다가 후에 나갈 때 A, B, C가 함께 나가는지 체크해주면 된다. 하지만 여기서 문제는 A, B, C가 그룹을 형성하고 있다는 것을 어떻게 알 수 있는가 하는 것이다. 식당에 들어올 때 한 명씩 시간 간격을 두고 들어와준다면 (나갈 때도 마찬가지) 구현 가능할 듯 하지만 불편함은 있다.

이 논문은 조금 다른 방식으로 접근한다. 그룹을 맺어야 하는 사물들이 미리 그룹을 형성한다. A, B, C, 세 가지 사물은 당연히 각자 자신들의 아이디를 가지고 있을 것이다. 여기에 더해서, 자신을 제외한 그룹 멤버들의 정보 또한 가지고 있자는 것이다. 즉, A의 경우 B와 C의 아이디를 저장하고 있으면 된다. 그런데 RFID의 메모리는 넉넉하지 않다. 일반적으로 512 bits 정도라고 하는데 아까 말했듯 식별 아이디 자체가 96 bits 정도이니 그룹 구성원의 수가 대여섯개가 넘어가기 시작하면 이 방식은 구현이 불가능하다. 영어 좀 쓰면 scalability 측면에서 좋지 못하다.

그래서 제안하는 방법은 해시를 이용하는 것이다. SHA-256을 사용했다고 한다. 자신을 포함한 모든 구성원의 아이디를 이용해 해시값을 얻는다. 모든 그룹 구성원이 같은 값을 얻게 될 것이다. 이것을 태그에 모두 저장해둔다. 이렇게되면 space 문제는 해결할 수 있다. 모든 태그가 2 * [the length of ID] 만큼의 공간만 있으면 된다.

이 방식을 사용해도  점검자(예를 들면 식당이나 공항의 출입구)가 체크를 할 때 어떤 범위로 태그 집합을 인식하고 그것을 바탕으로 해시값 비교를 할 것인가는 여전히 어려운 문제다. A, B, C, 세 사물을 커플링해둔 상태에서 입구로 들어갔을 때, reader가 A, B만 인식했다면, 또는 타인의 사물인 D까지 포함해서 A, B, C, D, 네 개의 사물을 인식했다면 오류를 일으킬 것이기 때문이다. 이 문제에 대해 논문은 별다른 언급을 하진 않았지만, 후자의 경우는 D가 다른 해시값을 가지고 있을 것이니 쉽게 제외시킬 수도 있을 것으로 생각된다. 그러나 전자의 경우는 방법이 없다.

논문은 태그를 읽는 방식을 soft, hard로 나누어서 구현 시 이슈로 언급하고 있다. 소프트는 차례로 태그들을 읽어가는 것을 말하며 하드는 - inventory read라고 불리는 - 하드웨어적으로 한 번에 여려 태그를 인식하는 방식을 말한다. 인식률면에서는 소프트가 좋다고 한다. 인벤토리 리드는 태그의 수가 많을 때 전체를 인식하지 못하고 상당한 수의 태그를 놓치게 된다고 한다. 물론 인식 속도는 당연히 하드가 빠르다. 소프트는 순차적으로 모든 태그를 읽어야 하기 때문에 태그의 수에 비례하여 읽는 시간이 소요된다.

예전에 RFID tag에 대해 한참 이야기를 많이 할 때, 이를 이용하여 계산대에서 바로 계산되는 어플리케이션을 많이들 이야기 했었다. 카트를 전속력으로 밀고 계산대를 지나가버리면 몇 개 물품은 계산되지 않는 문제가 있다고 살짝은 농담 섞어 이야기들을 하곤 했는데, 아주 심각한 문제였다. 상용화가 되려면 이런 오류는 용납되지 않으니까. 이런 이야기를 한 것이 벌써 5~6년은 된 것 같은데 아직도 이 문제는 해결되지 않았나보다.

논문을 읽다 궁금했던 점은 태그가 가지는 ID가 copy(clone)되는 일은 없을까 하는 것이다. 태그의 아이디는 쉽게 얻을 수 있는 값이므로 복사하여 바꿔치기할 수도 있을 것 같다는 생각이 든다. 논문에서 이에 대한 언급은 없다.

또 하나 논문에서 언급한 것은 proxy fragment인데, 여기서 fragment는 커플링되는 개별 사물을 말한다. 프록시 프래그먼트는 실존하지 않는 사물에게도 아이디나 기타 다른 비트스트링을 부여하여 함께 해시값을 얻을 수 있다는 것이다. 예를들어, 자전거와 자전거 주인을 커플링할 수 있다. 누군가가 자전거 보관소에서 내 자전거를 훔쳐 자기 것인 듯 끌고 나갔을 때 자전거 보관소의 입구에서 내 자전거의 태그와 그 사람의 정보를 가지고 해시값 비교를 해볼 수 있다. 그 사람이 나인 척 impersonation에 성공하지 않는 이상 간단히 도둑질이 발각될 것이다.

아주 심플한 아이디어고 태그에 데이터를 저장하기 때문에 별도의 데이터베이스도 필요없다. 별도의 데이터베이스에 정보를 저장하지 않기 때문에 프라이버시 측면에서도 나쁘지 않은 디자인이다. 태그 인식률과 속도가 개선되고 태그값이 복사되거나 스푸핑되지 않도록 할 수 있다면 심플하면서도 상당히 쓸모가 많은 아이디어가 아닌가 생각된다.

The Most Expensive One-byte Mistake라는 글을 읽었다. acmqueue에 실린 글이고 Poul-Henning Kamp가 쓴 글이다. Kamp씨는 FreeBSD 커뮤니티에서 활동하는 사람이라 괜히 정감이 간다. 각설하고.

글쓴이는 역사상 가장 큰 비용의 실수는 뭔가? 하는 질문을 던진다. IT와 CS의 역사에서 잘못된 선택으로 인해 고생했던 몇 가지 예를 서두에 언급하지만 결국 하고자 하는 이야기는 NUL-terminated text string이다.

텍스트 스트링은 상당히 자주 사용되는 자료형이다. 자바 프로그램에서 가장 많이 생성되는 객체는 String이라는 글을 읽은 적이 있다. 초기에 C를 만든 세 명은 스트링을 표현하기 위해 다음 두 가지의 선택사항을 가지고 있었다. 물론 현재에도 누군가가 언어를 설계한다면 둘 중에 하나를 선택해야 할 것이다.

1. address + length
2. address + magic_marker (NULL)
   

그들은 2번을 선택했다. 최적화라는 취지에서 2번이 좋아보였을 것이다. 길이를 저장하기 위한 별도의 공간을 마련하지 않아도 되니까.

의외로, 그 당시 많은 언어들이 1번을 채택하고 있었다고 한다. 2번을 택했던 언어는 어셈블리였다고. 앞서 언급한대로 1번은 길이를 매번 따로 저장해야 하니 비효율적일 것이다라는 느낌을 준다. 하지만 유리한 점도 있다. 데이터 복사나 이동을 할 때 대상 데이터의 크기를 즉시 알 수가 있다는 점. Cache를 활용할 때도 유리할 수 있다. 2번과 같이 매직 마커를 쓰면 마커를 찾아야 하는 비용이 높다. 크기를 미리 안다면 블록 단위의 복사를 바로 실행할 수가 있는데, 마커를 사용하면 마커를 우선 찾고 복사를 시작해야 한다. memcpy와 strcpy가 다를 수밖에 없는 이유가 되는 것이다. Constant string의 경우 컴파일러가 그 크기를 알고 있기 때문에 사용자가 strcpy를 요청해도 memcpy로 대체하여 스피드면에서 이득을 얻기도 한다고 한다.

앞서 언급한 효율의 문제를 떠나 보안의 입장에서 바라보자. 2번을 택한 것이 훗날 버퍼 오버플로우가 일어날 수 있는 여지를 주었다. 이것은 정말 큰 문제고, 저자가 이 글을 쓴 이유다. gets()의 절망적인 보안 수준은 다들 공감할 것이다.

하지만 C를 만든 Ken, Dennis, Brian을 마냥 욕할 수는 없다. 그들이 C를 만들고 15년이 지나서야 사람들은 이게 보안적인 측면에서 나쁘다는 걸 알았다고 한다. 그러니 잘못된 선택을 했다고 비난하기는 힘들지 않은가.

현재 C로 직접 프로그래밍하는 사람이 예전만큼 많지는 않다. 그러나 대부분의 언어가 C로 구현되어있다. 다른 언어로 프로그래밍을 해도 결국엔 libc가 호출되고 여전히 NUL-terminated string은 쓰인다.

그럼 이제와서라도 2번을 버리고 1번을 선택해볼 것인가? 지금까지 만들어둔 프로그램이 아깝기 때문에, 당장 모든 대체 프로그램을 만들 수가 없기 때문에 바꿀 수는 없을 것이다. 이미 만들어진 프로그램의 수보다 앞으로 만들어질 프로그램의 수가 훨씬 많음에도 바꿀 수가 없는 것이다.

ps. 처음 이 글을 쓸 때는 살아있던 Dennis가 티스토리로 글을 옮기는 현재 세상에 있지 않다. 고인의 명복을 빈다.

크롬에 대해서 보다가 HSTS라는 것을 보게 되었습니다. HTTP Strict Transport Security의 약자인데요, (정확히 이해했는지 확신이 아직 좀 없지만) 쉽게 말하면 "무조건 HTTPS를 쓸 것!"이 됩니다.

크롬을 사용하고 있다면,

chrome://net-internals/#hsts

이 링크로 접근 가능합니다.

여기에 등록해두면 해당 사이트에 접근할 때, 명시적으로 앞에 https:// 를 타이핑하지 않아도 무조건 https로 접속을 시도합니다.

그런데 사용자가 일일이 이 리스트를 입력하고 관리하는 것이 꽤나 귀찮은 일이죠. 그래서 크롬은 preloaded HSTS list라는 것을 built-in으로 가지고 있습니다. 몇 가지 예를 들면

• www.paypal.com
• (chrome|checkout|health|docs|spreadsheets|sites|appengine|encrypted).google.com
• market.android.com
  

이런 사이트들이 포함되어 있지요. 이 리스트는 구글이 정해둔 것도 있겠지만 해당 웹사이트에서 요청한 것이 대부분입니다. 여러분 누구나 내 웹사이트는 무조건 https를 사용도록 강제하고 싶다면 구글에 요청 메일을 보내면 됩니다. (아마 사이트의 규모가 좀 있어야 해주겠죠?)

앞서 작성한 DigiNotar의 가짜 구글 인증서에 이어서 쓰는 글입니다.

IE의 경우 MS에서 windows update를 통해 처리한 것으로 들었습니다. 여기서 처리했다 함은 웹브라우저가 DigiNotar를 Root CA로 인정하지 않도록 하는 것을 말합니다. 심플한 대처지요.

파이어폭스의 경우에도 업데이트를 통해 동일한 처리를 했고, 업데이트가 싫으신 분은 설정에 인증서 관리에 가셔서 직접 제거하셔도 된다고 합니다.

크롬도 마찬가지로 제외시켰다고 했는데, 크롬을 사용하고 있었다면 '혹시 내가 당하지 않았나?'하는 생각을 하지 않아도 됩니다. 왜냐하면 이 사건이 알려진 것이 크롬의 역할이 컸으니까요.

구글의 지메일 포럼에다가 누가 이런 글을 올렸는데, 크롬이 인증서가 이상하다며 경고 메시지를 보내줬다는 것이죠. 그래서 이게 man-in-the-middle attack이 아닌가하고 질문을 했고, 세상에 알려지게 되었습니다.

크롬 입장에서는 은근 자랑할만한 사건이 생긴 것이 되겠네요.

크롬이 경고를 날릴 수 있었던 것은 certificate pinning이라는 개념을 크롬이 도입하고 있어서인데, 개념이라고 하니 무척 고급 기술이 들어간 것 같지만, 별거 아니고, 특정 사이트의 인증서에 대한 root CA 리스트를 강제해두는 것입니다. 좀 더 쉽게 말하면 구글의 인증서를 인증해줄 수 있는 기관은 여기 여기뿐이다라고 정해두는 것이죠. 즉, 사이트별로 root CA whitelist를 가지는 것입니다.

구글은 (2011년 5월 4일 시간 기준으로) 구글 사이트들에 대한 인증을 해줄 수 있는 기관을 Verisign, Google Internet Authority, Equifax, GeoTrust 이렇게 4개의 인증기관으로 한정지어 두고 있습니다. 그러니 DigiNotar가 비록 root CA로써 활동하고 있는 인증 기관임에도 여기서 발행된 *.google.com에 대한 인증서는 크롬 입장에서는 '이상한데?' 하고 의심할 수 있게 되는 것이죠.

친구(@skyisle)의 페이스북 글에서 가짜 구글 인증서 사건이 있었다는 것을 알게 되었다. DigiNotar라는 곳에서 구글(정확히 말하면 *.google.com)에 대한 인증서를 발행했다는 것이다. DigiNotar는 네덜란드의 인증 기관(certificate authority, CA)이다.

문제는 DigiNotar가 Root CA 중에 하나라는 것인데, 이것이 왜 문제인지 내가 아는데까지 간단히 설명을 해보면,

우선 공개키 방식에 대해서 이해할 필요가 있다. 공개키 방식은 1977년인가에 Diffie와 Hellman이라는 두 사람이 공식적으로 제안한 것으로 유명하다. 그 이전까지는 하나의 키를 두 사람이 남들 모르게 공유하고 이것을 가지고 암호화 및 복호화를 하는 방식에만 모두가 집중하고 있었다. 그래서 키를 어떻게 몰래 나눠가질 것인가가 주요 이슈였다.

서로 뭔가 비밀 정보를 알고 있다면 그것을 이용해서 암호화해서 키를 보내주면 되는데, 뭔가 비밀 정보를 이미 공유하고 있다면 이미 그 자체가 키가 아닌가! 그래서 예전에는 키를 보낼 때 등기 우편으로 보내거나 사람을 사서 안전하게 전달한다는 내용이 논문이 당연하다는 듯이 기술되어 있다. 하지만 이건 사람이 개입되는 것이니 비용이 높고 속도가 느리다. 네트워크를 통해서 쉽게 할 수는 없을까? 하고 당연한 의문이 생겼을 터.

공개키 방식은 말 그대로 키를 공개할 수 있다는 것인데, 그렇게만 된다면 키를 누가 보게 되더라도(즉, 도청을 당할 위협을 고려하지 않고) 필요한 녀석들에게 던져줄 수가 있다. 하지만 공개된 로또 번호가 의미가 없듯, 남들 다 아는 주식 정보가 의미가 없듯, 키가 공개되는 건 이미 그 자체로 의미가 없다.

그럼에도 불구하고 이런 개념이 나올 수 있었던 것은 키가 하나가 아니라 두개이기 때문이다. Key pair를 만들어서 하나는 비밀로 숨기고 하나를 공개한다. 내부적으로 많은 알고리즘이 있을 수 있지만 다음 규칙을 따르면 공개키 방식에 사용될 수 있다.

(1) 공개키로 암호화한 것은 비밀키로 복호화할 수 있다. 반대로,
(2) 비밀키로 암호화한 것은 공개키로 복호화할 수 있다.

첫 번째 방식을 이용해서 안전하게 데이터를 전달하거나 혹은 비밀키를 전달한다.
두 번째 방식을 이용해서 전자서명을 한다.

이것이 디피와 헬만이 제안한 내용이다. 획기적이고 멋진 아이디어지만 여기서 문제가 하나 있다. 공개키가 말 그대로 공개되기 때문에 다른 녀석이 나를 사칭하여 자신의 공개키를 내 것이라고 다른 사람들에게 거짓말을 할 수 있기 때문이다.

즉, A가 B에게 어떤 비밀 메시지를 보내려고 B의 공개키로 암호화를 한다. 그럼 B는 자신만의 비밀키로 풀어서 그 내용을 볼 수가 있다. B의 공개키는 공개되어 있지만 누구도 비밀키는 모르므로 비밀 메시지를 볼 수가 없다.

이 때, E가 B인척 A를 쉽게 속일 수 있다. A가 B의 공개키가 뭔지 알아볼 때 E가 끼어들어 자신의 공개키를 A에게 알려주면서 "이거 B꺼야." 한다. A는 E의 공개키로 암호화 한다. E는 자신의 비밀키로 풀어서 메시지를 쉽게 읽을 수 있다.

이것 때문에 나온 것이 certificate이다. (인증서 개념은 역시 70년대 말에 MIT의 어떤 학부 학생의 졸업 논문에서 제안되었다고 하는데, 학부생이라니! MIT는 MIT다.) 인증 기관이 있어서 이 공개키는 B의 것이 맞소, 하고 인증해주는거다. E가 이것이 B의 인증서이다하면서 자기 인증서를 A에게 들이 밀어도 A가 인증기관에 알아보면 쉽게 이것이 뻥이라는 것을 알 수 있게 된다.

현재 인증서는 누구든 발행할 수 있고 대신에 chain을 형성하면 된다. Chain을 형성해야 한다는 것 자체가 아무나 발생할 수 없다는 소리가 되긴 하지만... 여튼 누군가가 "이 물건이 믿을만한 것이요."라고 말했을 때 못 믿겠다면 그 사람이 믿을만한 사람인지 또 누군가에게 물어봐야 한다. 이렇게 점점 연결 고리가 형성되는데 이 방식대로라면 최후에 절대 신뢰할 수 있는 누군가가 있어야 한다. 뭐, 정부의 인증! KS 마크! 이런 거라고 보면 될까? 비유가 안 좋았다. 하여튼 이걸 Root CA라고 한다.

이야기가 굽이굽이 많이도 돌았다. 결론적으로 하고 싶은 이야기는 DigiNotar는 root CA라서 여기서 발행된 인증서를 봤을 때 사용자는 믿을 수 있다고 생각한다.

이 인증서가 DigiNotar가 직접 발행한 건지 아니면 누군가가 DigiNotar를 해킹해서 한 건지는 내가 본 기사에서는 누구도 다루지 않았지만 여튼 이 인증서는 유효한 인증서였고 이란에 있는 많은 사용자들이 이 가짜 인증서를 사용했다. 아까 말했듯 인증서에는 공개키가 있고 사람들은 이 조작된 공개키를 암호화에 활용했을 것이다. 적발될 때까지 두 달 정도 사용되었다고 하니 꽤 많은 사람들의 지메일이나 구글독스가 털렸을 수도 있겠다.

여기 위키 페이지가 관련 링크로 넘어가기 좋다.

어떻게 적발되었고, 현재는 어떻게 대처하고 있는지는 다음 번으로 미룬다. 힘들다.