김 용묵의 절대공간 - 블로그

1. 고전적인 폭탄 테러

비행기는 타 교통수단보다 훨씬 더 빠르고 위험하고, 엔진이 꺼졌다가는 바로 추락해 버린다는 특성이 있다. 그래서 여객기의 경우 진작부터 테러의 표적이 되었으며, 보안의 필요성이 타 교통수단보다 더욱 부각되었다.
1970~80년대에 수하물 폭탄 테러가 몇 건 발생하자, 여객기 업계에서는 인원과 수하물이 무조건 일치해야만 비행기를 출발시키는 절차를 추가했다.

환승 등 어떤 형태로든 주인 없이 슬쩍 싣는 짐이 기내에 절대 존재하지 않게 한 것이다. 그 짐 속에 폭탄이 들어있을지는 아무도 모르니까. 짐과 짐 주인을 맞추는 게 마치 울나라 군대에서 탄피 개수를 맞추는 것과 비슷한 수준이 됐다.

여기까지는 그렇다 치는데..
누군가가 비행기 안에 들어갔다가 탑승을 포기하고 도로 내리는 경우, 이때도 객실과 수하물을 전부 싹 뒤지고 검사를 다시 하게 됐다. 이건 어디 건물에 폭탄 설치 협박 전화가 들어온 것과 완전히 동일 상황이라고 가정하는 거다.

비행기가 떴다가 응급환자 때문에 도로 회항하면.. 이번엔 승객들 짐은 건드리지 않지만 비행기가 비상 착륙을 위해 연료를 다 버려야 하는 민폐 상황이 벌어진다.
그런데 뜨기 전에 승객이 일부 빠져나가면, 이번엔 연료는 안 버리지만 저렇게 보안과 관련된 시간과 인력 낭비 민폐 상황이 벌어진다.;;

우리나라는 대한항공 858 (김 현희..) 이후로 수하물 폭탄 '테러'는 더 겪지 않고 있다.
그 대신, 화물기에 실렸던 리튬이온 배터리가 폭발하는 바람에 추락 사고가 난 적이 있었을 뿐.. (아시아나 항공 991편, 2011년. 조종사들 사망)

2. 자살 테러

짐칸에다가 폭탄을 못 실으면 사람이 직접 조종실로 쳐들어가서 조종사들을 제압한다~!!
우리나라는 1958년의 창랑호, 1969년 YS-11기 같은 북괴의 납북 테러 공작 때문에 진작부터 이런 거 대비를 하고 있었다.
그 반면, 미국은 2001년 9· 11 테러를 당한 뒤에야 보안이 뒤늦게 아주 아주 강화됐다.

20세기까지 항공 보안 이념에는 "테러리스트들이 아무리 비행기를 납치하더라도 설마 자기들까지 다 죽을 짓을 하지는 않을 것이다"라는 전제 조건, 선입관이 깔려 있었다.
그러나 9· 11 테러는 그 선입관을 정면으로 반박하고 부정해 버렸다. 그러니 충격이 더욱 클 수밖에 없었다.

이제 수하물뿐만 아니라 기내 반입 소지품도 더욱 까다롭게 검사하기 시작했다. 기내식 스테이크를 써는 플라스틱 나이프조차 안 주고 미리 다 썰어서 주기 시작했다. 식사 때 포크와 나이프를 통제하는 곳은 교도소밖에 없지 싶은데, 이거 뭐 여객기도 그 범주에 들게 된 것이다.;;
그리고 조종실은 무슨 일이 있어도 밖에서는 절대로 못 열고, 심지어 수류탄을 터뜨려도 안 열릴 정도로 문이 필요 이상으로 엄청 튼튼하게 개조됐다.

3. 조종사의 일탈

그랬는데.. 21세기에 와서는 비록 극소수이지만 정말 의외의 뜬금없는 상황이 벌어졌다.
바로, 외부 테러리스트가 아니라 내부의 조종사가 나쁜 마음 품고 일탈을 저지르는 경우가 있더라는 거다.
기장과 부기장 중 한 명이 화장실 갔을 때 남은 한 명이 조종실 문을 잠가 버리고 비행기를 고의 추락시키면.. 이건 아무도 저지할 수 없게 됐다.

아니, 여객기 조종사까지 될 정도로 인생 성공한 고소득 전문직 종사자가 도대체 저런 짓을 왜 하나 싶지만.. 인간의 욕심은 끝이 없으며, 기준이 절대적이 아니라 상대적이다.
그 파일럿들 엘리트 조직 안에서도 서로 꼴보기 싫은 사람이 있다. 나이 50이 넘도록 기장 진급 못 하고 눈칫밥 먹는 열등감 쩌는 찐따도 있고, 스트레스 때문에 우울증이나 조현병 따위에 시달리는 조종사도 없으란 법이 없다.

이 사람들 역시 받는 액수가 좀 상위권일 뿐, 사기업 다니는 월급쟁이 근로자의 범주를 벗어나지 않는다. 월급만으로 성이 안 차서 다른 데서 돈놀이 하다가 실패해서 빚더미에 앉은 케이스도 있다. 당장 울나라에서도 옛날에 무려 대학 교수가 돈 문제 때문에 지 애비 죽인 사례가 있었다.

1999년 이집트 항공 990편 추락, 2015년 저먼윙스 9525편 추락은 블박을 보아하니, 정말 충격적이게도 부기장에 의한 고의 추락이 거의 확실시됐다. 2014년에 실종된 말레이시아 항공 370편은 물증이 부족하긴 하지만 기체 결함이 절대 아니고 얘도 누군가에 의한 고의 추락으로 가닥이 기울어 있다.
작년 봄에 중국에서 거의 수직으로 내리꽂혔던 중국 동방 항공 5735편 사고도 정황상 조종사에 의한 고의 추락이다.

오늘날 정치· 군사 분야가 아니면서 한 사람이 수백 명의 목숨을 왔다갔다 할 수 있고 막대한 책임감과 스트레스가 부과되는 업종은 의료나 원자력이 아니면 비행기· 선박 같은 교통수단이지 싶다.

옛날에 항공기관사가 있어서 조종실 승무원이 3명이나 있던 시절에는 이런 고의 추락 따위 존재하지 않았다. 존재할 수가 없었다. -_-;;
옛날에 시내버스에 운전사뿐만 아니라 차장도 있던 시절에는 파주 시내버스 팔 끼임 사망 사고 따위 날 수 없었던 것과 비슷한 이치이다. 수동 변속기 시절에 요즘 같은 급발진 따위도 절대 없었을 테고.

이런 게 무인화 자동화가 가져오는 부작용이라면 부작용이다.
뭐, 조종실 문을 봉인한 것 자체가 잘못은 아닐 테니 요즘은 부기장· 기장 중 누가 화장실에 가면 객실승무원이라도 호출해서 조종실에 언제나 2명이 있게 운항 매뉴얼이 개정됐다.

사람이 935명이나 타는 KTX 열차는 1명이서 운전한다. 열차야 앞뒤로밖에 오가지 못하고, 안전성 면에서 타 교통수단의 추종을 아득히 압도하기 때문에 그게 가능하다.
오죽했으면 쟤들은 시속 300으로 달리는데도 좌석에 안전벨트가 없고 입석 승객까지 버젓이 받는다. 그리고 기관사가 생존 반응 확인 신호에 응답하지 않기만 해도 비상 정지한다.
이런 시스템은 오직 철도에서만 구현 가능하다. 그 반면, 여객기는 부기장마저 없어지는 1인 단독 조종이 될 일은 가까운 미래에 없을 것 같다. 이건 LPG 충전소가 무인화 셀프화되는 것과 동급이 아닐까 싶다.

(아 그러고 보니 1982년엔.. 기관사까지 버젓이 있는 와중에 기장이 기체를 고의로 추락시켰던 일본 항공 350편 같은 사례도 있긴 했다. 그건 얘기가 복잡해지는데, 일단 논외로 하자. -_-)

Posted by 사무엘

1. 90년대 중반의 제품 데모: 3D Studio R3, Windows 95

인터넷이란 게 없던(= 가정용으로 널리 보급되지 않은) 시절에 컴퓨터로 바깥의 최신 문물을 접하는 방법은 기껏해야 PC 통신, 아니면 컴퓨터 잡지와 함께 배포되던 부록 CD였다.
그런데 모뎀으로 접속하던 PC 통신은 접속 시간에 비례해서 부과되는 전화비의 압박이 심했으며, 전송 속도도 지금의 인터넷 전용선과는 비교조차 할 수 없을 정도로 느렸다. 그렇기 때문에 수십~수백 MB 이상의 대용량 자료를 배포하는 수단으로는 CD 같은 물리적인 매체가 여전히 의미가 있었다.

PC 통신 자료실이건, 잡지 부록 CD건, 이런 매체에는 유명 소프트웨어의 무료 체험판과 데모가 많이 포함돼 있었다. 유료로 판매되는 제품에서 일부 기능만 사용할 수 있거나 사용 기간이 제한된 것 말이다. 아니면 애초에 사용자가 조작해 볼 수 있는 기능은 없고 파워포인트 프레젠테이션처럼 일방적인 기능 소개와 화면 시연만 들어있는 데모 프로그램도 있었다.

그 중 본인이 인상깊게 봤던 것은 3D Studio R3.. 3DS에 MAX라는 이름이 붙기도 전, 게다가 도스용이 존재하던 시절 버전의 데모이다. 이거 화면을 유튜브에서 다시 보는 날이 오게 될 줄은 몰랐다. 정말 유튜브에 별별 것들이 다 올라온다..;; (☞ 링크)

요즘 같으면 파워포인트.. 하다못해 플래시로도 만들 수 있을 것 같은데.. 몇몇 화면 전환이나 프로그램 실제 화면 애니메이션 같은 건 난이도의 압박이 있을 것 같다.
1994년에는 아직 플래시도 없었기 때문에 도스에서 exe 형태로 저런 프레젠테이션 데모만 제작하는 전문 업체가 있었던 모양이다.

그리고 다음으로 소개하고 싶은 것은.. 국내에서 제작됐던 Windows 95의 데모 겸 기초 기능 튜토리얼이다. 95~96년 사이에 이거 보신 분 계신가..?? (☞ 링크)

"윈도우즈 구십오", "엠에스 더~스" 라고 또박또박 말하는 여성 나레이터 목소리가 찰지게 느껴진다.;;
도스와 Windows 3.1의 타성에 젖어 있던 사람들한테 시작 메뉴와 바탕 화면, 탐색기, 단축 아이콘(현재 명칭은 '바로가기') 개념을 처음으로 가르치고 홍보하느라 마소에서 그 당시에 돈 엄청 많이 쓰긴 했다.

이 데모 프로그램은 Windows 95 한글판의 CD에 포함된 프로그램은 아니었는데 어느 경로로 유포되었는지 궁금하다. 그냥 PC 통신이나 잡지 부록 CD였는지..?

2. 게임 데모

예전에도 한번 언급한 적이 있지 싶은데.. 과거에 스티브 잡스는 소수의 추종자 매니아를 양성하는 식으로 제품을 판매한 반면, 빌 게이츠는 정말 통 크게 남녀노소 가릴 것 없이 전세계에 컴퓨터를 보급해서 세계인들의 생활을 확 바꿔 놓고, 그 컴퓨터라는 기계에 우리 회사의 운영체제를 몽땅 뿌려 버리겠다는 심보로 장사를 했다.

그래서 Windows 95에서 드디어 32비트로 체제를 바꾸기도 했으니.. 얘를 본격적으로 게임용 홈 엔터테인먼트 플랫폼으로 만드는 일에 가히 사운을 걸었다. 그래서 거의 곧장 DirectX를 만들었으며, 특히 세계적인 히트를 치고 있던 Doom 2 게임 정말 0순위로 Windows용으로 포팅을 지원해 줬다.

PC에서, 그것도 DOS가 아닌 Windows에서 텍스처 매핑이 적용된 실시간 3D 게임이 돌아간다는 건 굉장히 획기적인 일이었다. Windows는 그저 지뢰찾기나 카드 게임 같은 가벼운 게임만 하는 플랫폼이라는 고정관념이 드디어 깨지기 시작했다.

애초에 Windows 95 원본 CD에는 Hover!이라고.. 범퍼카를 몰고 맵을 돌아다니며 깃발을 상대방보다 먼저 뺏는 게임이 있었다. 마소가 게임 전문 개발 업체는 아니지만, 이건 외주가 아니라 마소에서 직접 개발했던 듯하다.

얘는 비록 세계적인 명작인 Doom만치 막 박진감 넘치는 요소까지는 없지만, 그래도 그래픽은 Doom과 비슷한 수준이었다. 그리고 초보적이나마 1층 공간 위에 2층이 구현돼 있기도 했다는 점에서 Doom 엔진과 결정적인 차이가 있었다.

그리고 내 기억이 맞다면 Windows 95와 거의 동시에 Fury라고.. Hover의 공중 버전 내지 윙 커맨더의 축소판 같아 보이는 게임도 개발돼 나왔다. 얘는 외부 개발사와 합작 내지 외주 형태로 개발됐고 Windows 95에 포함돼 있지는 않았다.

게임 진행은.. 뭐 공중을 날아다니면서 총 쏘고 부수는 것 정도만 기억에 남아 있다.
마소는 Fury니, Hover!이니 하는 아기자기한 게임들을 같이 내놓으면서 우리 Windows 95는 저런 화려한 3D 그래픽이 가능한 게임용 플랫폼이라는 걸 기를 쓰고 내세웠던 듯하다.

그러고 보니 Win95의 발매 직후에는 DirectX라는 것도 아직 완전 듣보잡이거나, 버전이 2~3 이러던 시절이었을 텐데.. 3D 그래픽 가속이라는 건 퀘이크도 나오고 최소한 96~97년, Voodoo니 뭐니 하던 게 나온 시절부터 주목 받았을 텐데 저런 게임들은 CPU빨만으로 3D 그래픽 애니메이션을 구현했던 건지 궁금해진다.

끝으로, 비록 저렇게 1인칭 3D는 아니지만 3D 핀볼이라는 유명한 번들 게임도 있었다. 얘는 나름 Windows 3.1 + win32s에서도 돌아갔던 까마득한 옛날 프로그램이다.
마소에서 외부 업체로부터 소스 코드를 구입해서 자사 제품에다 포함시켰는데.. the old new thing 블로그에서의 회고에 따르면 코드가 주석 한 줄 없이 도저히 유지보수 가능한 상태가 아니었다고 한다.

훗날 Windows가 32비트에 이어 64비트로 갈아탈 때가 임박했는데, 얘는 내부적으로 오프셋 계산에 문제가 있었는지 64비트에서는 제대로 동작하지 않았다. 그런데 문제의 원인이 무엇이고 어디를 고쳐야 할지를 알 길이 없었고, 그렇다고 얘는 오픈소스화가 가능한 물건도 아니다 보니 64비트에서는 핀볼이 결국 짤리게 되었다.
그 외부 업체가 코드를 컴파일만 가능하고 유지 보수는 도저히 가능하지 않은 형태로 일부러 변조해서 줬던 것 같다.

3. 왓콤 win386

1990년대에 왓콤(Watcom)이라는 컴파일러 제조사는 PC의 도스 환경에서 32비트 프로그램의 개발 환경을 시세 대비 매우 저렴하게 제공한 일등공신으로 칭송받았다.

그 시절에는 아직 386/486급 PC의 가격도 아주 비쌌고, 32비트 코드 생성을 지원하는 컴파일러도 비쌌고, 특히 도스에서 이런 프로그램을 돌아가게 해 주는 DOS Extender도 아주 고가였다. 그런데 왓콤은 32비트 컴파일러와 무료 번들용 DOS extender까지 아주 파격적인 가격에 보급했던 것이다. 그러니 아주 전문적인 대형 고급 소프트웨어를 개발하는 분야에서 수요와 고객을 확보할 수 있었다. 볼랜드나 마소 같은 주류 컴파일러 제조사들은 그저 16비트에 안주하고 있었기 때문이다.

그런데 왓콤의 무서운 면모는 도스용 32비트 개발툴만 만든 게 아니었다는 점이다. 1990년대 초, 아직 Windows NT 3.1이 정식으로 나오기도 전에 멀쩡한 Windows 3.0/3.1를 마개조해서 32비트 코드를 구동해 주는 win386 Extender를 개발했다~! 그리고 이 시스템을 기반으로 돌아가는 32비트 코드를 생성하는 Windows 타겟용 컴파일러를 덤으로 보급했다. 기존의 16비트짜리 도스/Windows API를 호출할 때는 물론 입출력값을 변환할 테고 말이다. (☞ 더 자세한 소개)

이게 내부적으로 어떤 원리로 동작했는지는 잘 모르겠다. 오늘날의 Windows NT처럼 PE 포맷을 사용하지도 않았을 텐데..
하긴, 16비트 시절에는 Windows용 한글 바이오스(한메한글~!!)도 있었으니, 뭔가 시스템 내부를 마개조하기가 더 쉬웠던 것 같다.
당장 마소에서 옛날에 개발했던 FoxPro 2.5~2.6이 왓콤 win386을 기반으로 개발됐다고 한다.

그로부터 몇 년 뒤에 마소 본가에서 Windows NT를 출시해서 32비트 Windows API가 제대로 정립되고, 32비트용 Visual C++ 1.0과 win32s 같은 게 줄줄이 나오면서 왓콤 win386의 시대는 막을 내리게 됐다.
Windows의 32비트화 내력을 요약하면 다음과 같다.

• real 모드: 1.0~3.0 (1985~1990) 사실상 640KB 기본 메모리밖에 사용하지 못하는 초 열악 모드.
  
• 286 standard: 2.0~3.1 (1987~1993) real보다는 나은 것 같지만 정확하게 언제 처음으로 등장했고 차이점이 뭔지 존재감이 매우 없음.
  
• 386 enhanced: 3.0~ (1990~??) 아직 32비트 코드를 시행하는 건 아니지만 도스창을 완전히 가상화할 수 있고 확장 메모리를 더 사용 가능함.
  
• Win32s: 3.1 (1992~1996) 딱 32비트 코드 실행만 가능한 최소한의 모드
  
• Windows 9x: 95~ME (1995~2000) 프로세스 별 주소 공간이 독립하고, 멀티스레드가 가능해짐
  
• Windows NT: 3.1~10 (1993~현재) 유니코드 기반, 온전한 메모리 보호, 16비트 코드의 완전 가상화까지 실현

사실 386 enhanced mode라는 건 Windows 3.0 이전에 2.x의 386 에디션에서 최초로 도입되긴 했다. 하지만 이건 마치 Windows XP의 x64 에디션만큼이나 존재감이 없다.

4. 오 성식 생활 영어 SOS

우와~~ 이거 정말.. 추억의 멀티미디어 CD 타이틀이었다. (☞ 링크)
그 시절에 ToolBook이라고 CBT 멀티미디어 교육용 소프트웨어 저작도구가 있었는데..
쟤도 바로 툴북을 기반으로 만들어졌었다.
컴터에서 avi 허접 동영상이 재생된다는 것만으로도 왕창 신기하던 시절에 나왔던 물건이다.
저 타이틀에서는 도움말 나레이션만 낭독한 이 보영 씨 역시 현재까지 현역으로 뛰고 있는 유명 영어 강사이다.

그 뒤 저런 멀티미디어 컨텐츠를 만드는 플랫폼은 플래시로 넘어갔다가..
요즘은 플래시를 쓸 필요도 없이 저런 건 그냥 웹에서 HTML5 자바스크립트만으로 다 처리 가능하게 된 지 오래다.

쟤는 프로그램을 바로 종료하려 하면.. "공부라는 건 최소한 50분은 넘게 집중해서 해야 효과가 납니다. 그래도 지금 바로 종료하시겠습니까..."라는 확인 질문이 떴다. 내가 태어나서 지금까지 접했던 소프트웨어들 중 가장 훈계조로 종료를 저지하는 물건이었다.
반대로 Doom 2 게임은 온갖 농담 조크를 날리면서 종료를 저지했던 프로그램이고..

인트로 화면 보소..
딱 미리내 소프트웨어 "그 날이 오면 3" 게임의 인트로와 비슷한 환상적이고 몽환적인 느낌이 들지 않는가..??

레 솔솔 라 레레 솔 라시 레 시라솔 라~~
25년 가까이 지난 지금도 나는 멜로디를 정~확하게 녹음기로 틀어 놓은 듯이 기억하고 있다. 초딩 나이로 워낙 환상적인 경험이어서...

Credits를 보니.. 요 아름다운 인트로 음악을 작곡한 사람이 이 영수 교수(1951-2018. 영남 대학교 음대 작곡과)였다고 나온다.
어머니의 마음 "낳실제 괴로움 다 잊으시고..."의 멜로디를 만든 작곡가 이 흥렬의 아들이다.

Posted by 사무엘

0. 들어가는 말

세상에는 누구나 드나들 수 있는 공공장소와 누구나 신호를 주고받을 수 있는 통신망이 있지만, 사람마다 사생활도 있고 비밀도 있다. 이런 게 보장되지 않으면 인간이 정상적으로 살아갈 수 없으며, 사실은 생존에 필요한 기본 욕구를 충족시킬 수도 없어진다.
그렇기 때문에 어떤 장소나 어떤 정보는 내부의 믿을 수 있는 사람, 우리 조직 소속인 사람만 접근할 수 있게 해야 한다.

이를 구현하기 위해 전자에 대해서는 열쇠와 자물쇠라는 게 만들어져 왔고, 후자를 위해서는 암호 기술이라는 게 개발되었다. 열쇠가 없는 사람, 암호를 모르는 사람은 문을 열고 들어갈 수 없고 그 자료를 열람할 수 없다. 심지어 정보가 담긴 매체라든가 물건이 담긴 금고 자체가 유출되더라도 그 안의 물건에 손댈 수는 없다.

열쇠와 암호는 서로 담당하는 영역이 다르지만 심상이 아주 비슷한 구석도 있다. 요즘은 자물쇠도 열쇠 대신 일종의 숫자 암호인 디지털 도어락으로 바뀌고 있고, 암호학에서도 key라는 용어가 즐겨 쓰이니 말이다.

다만, password라는 개념의 '암호'와, 원본 정보를 password 없이는 알아볼 수 없게 변조하는 '암호화'(cryptography, encryption), 그리고 암호화가 적용된 텍스트를 작성하는 것 내지 그 결과물인 암호문(cipher).. 이게 우리말에서는 딱 부러지게 잘 구분되지는 않는다는 점을 감안할 필요가 있다. 마치 '뛰다'(jump/run), '다른'(other/different), '푸르다'(green/blue) 이런 게 잘 구분되지 않는 것처럼 말이다.

보이니치 괴문서처럼 암호 사용 여부와는 무관하게 단순히 체계와 의미가 파악되지 못한 물건도 decipher되지 못했다고 말한다.
그에 비해 한국어 ‘해독’은 동음이의어 한자의 특성 때문에 ‘독’에 read라는 뜻뿐만 아니라 poison이라는 뜻까지 있어서.. 미묘하게 중의적인 심상을 자아낸다. 마치 ‘충전’의 중의적인 심상처럼 말이다. (전기도 충전, 금액도 충전..)

1. 패스워드의 관리, 해시 함수

먼저, 암호화와 무관하게 로그인 패스워드 자체에 대한 보안을 논하는 기본 원칙이 있다. 이 주제에 대해서는 본인이 마지막으로 글을 썼던 때가 무려 7년 전이었구나.;; (☞ 이전 글)
사용자의 입장에서는 “다양한 종류의 문자를 섞어서 최소한 10자 이상의 긴 문자열로 정할 것, 주기적으로 바꿔 줄 것” 이런 게 있다.

물론 누군가의 원한을 사고 있어서 작정하고 당신의 계정을 뚫으려 노력하는 공격자라도 있는 게 아니라면.. 이런 얘기에 지나치게 민감해할 필요는 없다. 암호 좀 허술하게 만든다고 해서 현실에서 당장 위험에 빠지는 건 아니다. 하지만 그렇다고 해서 1234, asdf, iloveyou, 생일, 전화번호 정도로 암호를 너무 성의없게 만드는 건 정말 피해야 한다.

그리고 사용자의 접속 정보를 저장하는 운영자의 입장에서는 암호를 절~대로 평문 그대로 저장하지 말아야 한다. 게다가 암호 문자열이 무슨 도스 시절 파일 이름마냥 10~15자 같은 제약이 걸려 있거나 특정 특수문자 기호를 지정하지 못한다면.. 그건 정말 기본적인 보안 관념도 없던 쌍팔년도 시절 사고방식의 미개한 사이트라고 욕 먹어야 할 것이다.

사용자가 암호를 잊어버렸다면 사이트 운영자라도 그 암호를 알 수 없는 게 정상이다. 본인 인증을 시행한 뒤에 임의로 지정한 새 암호를 알려줘야지, 기존 암호를 그대로 알려주는 사이트는 그 자체가 보안이 매우 허술하다고 실토하는 것과 같다.

그러니 이런 패스워드는 딱히 key 없는 단방향 암호화라는 변조를 거쳐서 저장해야 하는데, 이럴 때 해시 함수라는 게 쓰인다. hash란 어떤 임의의 길이의 원본 문자열이 주어졌을 때 원본과는 완전히 다르고 무질서하게 변조된 다른 고정된 길이의 문자열 내지 바이트 시퀀스를 되돌리는 수학 함수이다. 원본 문자열이 조금만 바뀌어도 완전히 확 달라진 결과값이 나와야 한다.

F(X) → Y인데, 역으로 Y로부터 X를 복원하는 것은 수학적으로 불가능하다. 그리고 F(A) ≠ F(B) 라면 절대적으로 A≠B이지만, F(A)=F(B)이면서 여전히 A≠B일 확률은 매우 매우 낮은 확률로 존재한다. 비유하자면, 퀵 정렬의 시간 복잡도를 n^2로 만드는 input을 우연히 만들 수 있을 정도의 확률로 존재한다.

패스워드의 비교는 사용자가 입력한 문자열을 hash한 결과와, 저장된 패스워드 hash값을 비교함으로써 행해진다. 평문을 비교하는 게 아니라는 것이다.
사실, 이런 해시 함수는 패스워드의 보관뿐만 아니라 방대한 파일이 정확하게 잘 전송되었는지 동등성을 검증하는 용도로도 즐겨 쓰인다. 수 GB짜리 파일의 해시값이 얼마가 나와야 정상인데 엉뚱한 값이 나왔다면 중간에 오류가 있었다는 뜻이 되기 때문이다.

해시 함수가 튼튼하고 안전하려면 (1) F(X)로부터 X를 역으로 추적하는 것이 불가능해야 하고, (2) 서로 다른 두 입력 A, B에 대해서 동일한 해시값이 산출되는.. 다시 말해 ‘충돌’ 사례가 없어야 한다. 전자는 암호화된 값으로부터 패스워드를 복원하는 것이고, 후자는 의도하지 않았던 엉뚱한 암호로 원래 패스워드의 사칭을 가능하게 하기 때문이다.

성능 좋은 해시 알고리즘으로는 MD5니, SHA-256 이런 부류가 공개되어 쓰이고 있다. 이들도 한번 만들고 끝이 아니라 버전과 출력 해시의 길이가 올라가는 편인데, 기를 쓰고 공격하려 애쓰는 연구자에 의해 충돌하는 입력값 쌍이 발견되기도 한다. 그러면 그게 해당 알고리즘을 사용하는 소프트웨어의 잠재적 보안 결함으로 이어진다.

그리고 해시값으로부터 원래 입력을 역추적하기 위해 요즘은 상상을 초월하는 물량 데이터빨이 동원된다. “MD5 해시값을 자동으로 계산해서 구해 드립니다”라는 웹페이지를 개설한 뒤, 전세계 사용자가 입력했던 문자열과 그 해시값 수십억 개를 몽땅 보관해 놓는 것이다. 그래서 산술 연산을 하는 게 아니라 DB를 조회함으로써 해시값 복원을 한다. 우리가 남들도 떠올릴 만한 평범한 문자열로 패스워드를 만들면 위험한 이유가 이 때문이다.

2. 대칭 키 암호화

이게 우리가 흔히 생각하는 데이터 암호화이다. 발신자가 A라는 텍스트를 K라는 패스워드(혹은 key)를 이용해서 E라는 암호화 함수로 암호화해서 B라는 암호문을 얻는다. 수식으로 표현하면 B=E(A, K) 정도? 그러면 수신자는 D라는 복호화 함수를 이용해서 D(B, K)를 돌림으로써 A를 얻는다.
이걸로 끝.. ‘대칭’이라는 말은 발신자와 수신자가 K라는 동일한, ‘대칭인’ key를 공유하는 암호 체계라는 뜻이다.

암호화 함수는 해시 함수와는 달리 복호화 함수도 존재하며, key만 안다면 원문 복원이 가능하다는 차이가 있다. 해시 함수는 애초에 어떤 입력에도 128비트 같은 동일한 길이, 즉 동일한 정보량을 가진 해시값이 돌아오지만, 암호화 함수는 출력의 정보량이 입력의 정보량과 대등하다. 그러니 용도가 서로 근본적으로 완전히 다르다.

컴퓨터가 없던 시절에도 마치 VMS로부터 WNT (Windows NT)라는 명칭을 만드는 것처럼 글자들을 일정 간격 앞뒤의 것으로 변조하거나, 심지어 key 문자열의 형태를 토대로 각 글자들을 가변적인(하지만 규칙과 패턴은 물론 있는) 오프셋만치 변조하는 기법 정도는 응당 쓰였다. 모든 글자를 고정적인 오프셋만치 변조하는 암호는 각 글자들의 빈도수 분석을 통해 비교적 금방 깰 수 있을 것이다.

2차 세계 대전까지만 하더라도 전자식 컴퓨터라는 게 사실상 없던 시절이었고, 지금에 비하면 매우 단순하고 원시적인 암호가 쓰였다. 연합군이 승리한 것에는 적국(일본, 독일) 군대의 암호를 풀어낸 것이 아주 큰 기여를 했음이 주지의 사실이다.
컴퓨터가 등장한 뒤부터는 매우 컴퓨터 친화적인 비트 회전과 XOR 연산이 암호화에 즐겨 쓰이고 있으며 그 수준이 과거엔 상상도 할 수 없을 정도로 복잡해졌다. 문자열을 암호화하기 위해서는 문자열을 구상하는 각 문자들을 숫자처럼 취급하는 게 필수이다.

정보 보호라는 업계에서 이런 암호화와 관련하여 통용되는 철칙이 있다. 암호화 알고리즘은 자신의 동작 방식과 로직이 소스 코드 차원에서 몽땅 공개되어 있더라도 절대적으로 안전해야 한다는 것이다. 데이터의 안전은 key가 보장해야지, 알고리즘을 공격자가 알고 있는지의 여부와는 무관해야 한다.
그렇기 때문에 이 바닥은 소스를 공개할 수 없는 우리만의 초특급 비밀 노하우 원천기술 같은 게 없다. 모든 게 투명하게 공개돼 있고 심지어 취약점이 발견된 것, 수정 내역도 공개된다. 이런 열린 관행 덕분에 컴퓨터 세계는 역설적으로 더 안전해질 수 있었다.

여담이지만, 지난 2009년엔 ‘코드소프트’라는 정체를 알 수 없는 어느 스타트업 기업에서 상금까지 걸면서 자기네 암호화 알고리즘에 대한 크랙 공모전을 주최했으나 비슷한 시기의 T-max 운영체제 같은 흑역사만 남겼던 적이 있다. 자기네 핵심 기술이라던 암호화 알고리즘은 허술하기 짝이 없어서 겨우 몇 시간 만에 뚫려서 큰 망신을 당했으며, 그 회사도 얼마 못 가 통째로 폐업했기 때문이다(소스는 비공개이고 임의의 데이터에 대한 암호화 결과 확인만 가능). 걔들은 암호화 알고리즘의 전문가는 고사하고 보안에 대한 기본 관념이 있긴 한 기업이었는지가 의문이 든다.

대칭 키 암호화 알고리즘으로는 AES, DES 같은 기성 표준 알고리즘이 있고 이것도 버전 내지 사용하는 정보량(비트수)이 올라가고 있다. AES는 오늘날의 컴퓨터 성능으로는 뚫리는 데 걸리는 시간이 위험할 정도로 짧아졌기 때문에 이제 사용이 권장되지 않는 지경이 되었다.
우리나라에서도 SEED, ARIA, LEA라는 알고리즘을 자체 개발해서 국가 표준으로 지정한 바 있다. 국정원 내지 한국 인터넷 진흥원 이런 데서 날고 기는 수학 박사를 채용해서 머리 굴려서 개발한 듯하다.

문서나 압축 파일에 암호를 거는 기능에도 응당 이런 암호화 알고리즘이 쓰인다.파일 내부에다가 패스워드를 평문으로 저장하는 미친 짓을 하지는 말아야 할 것이다. 혹은 파일 내용 자체를 암호화하지 않아서 헤더의 패스워드 부분만 건너뛰고 나면 나머지 내용을 고스란히 읽을 수 있게 하는 것도 치명적으로 잘못된 설계이다.
틀린 패스워드를 주면 해독이 잘못되어 완전히 엉뚱한 파일이 생성될 텐데, 패스워드가 맞는지 틀린지를 확인하는 건 정상적으로 해독됐을 때의 파일 checksum hash 같은 걸 별도로 둬서 확인해야 한다. 암호화 알고리즘 다음에 붙는 CBC, GCM 같은 모드 명칭은 바로 이런 검증 방식을 가리킨다.

안전한 암호화 알고리즘이라면 평문이나 key가 조금만 달라져도 이들의 원래 형태와 통계적 특성을 전혀 알 수 없는 엉뚱한 암호화 결과가 출력으로 나와야(혼돈과 확산) 안전할 것이다. 이 점에서는 해시와 비슷한 구석이 존재하며 심지어 난수 생성 알고리즘과도 비슷하다고 볼 수 있다. 입력을 0, 1, 2 .. 순차적으로 주고 이를 hash시킨 결과가 난수나 마찬가지이고 암호화도 이와 크게 다르지 않을 테니까.. 하지만 암호화, 해시, 난수는 전문적으로 들어가면 지향하는 목표가 다른 분야라고 한다.

말이 나왔으니 말인데.. 임의로 생성 가능한 문자열과 이를 hash한 문자열을 혼합하면.. 올바른 번호와 잘못된 번호의 구분이 존재하는 일련번호(serial key) 체계도 생성할 수 있다.
간단하게는 우리나라 주민등록번호가 대표적인 예이다. 검증용으로 쓰이는 마지막 자리 숫자가 hash 함수의 결과값이니까 말이다.

소프트웨어에서 불법 복제를 감지하고 예방하기 위해 발급되는 제품 key도 다 이런 원리로 발급된다. 상업용 소프트웨어야 처음부터 고정된 시리얼 키가 제품 패키지에 들어있으니 사용자 이름과 무관하겠지만, 셰어웨어 등록판을 생성하는 시리얼 키는 사용자의 이름도 공식에 응당 반영된다.

규칙에 어긋난 잘못된 문자열을 입력하면 해당 제품의 설치 프로그램은 에러 메시지를 내뱉으면서 다음 단계로 진행을 하지 않을 것이다. key의 생성 규칙은 그 제품 개발사의 중대한 영업 기밀이다.

하지만 이렇게 수학적인 방법, 소프트웨어적인 방법은 역공학을 통해서 뚫리기도 너무 쉽다. 암호학에서 알고리즘이 아니라 key만 믿어야 한다고 괜히 강조하는 게 아니다.
옛날에 불법 복제 어둠의 경로를 가 보면 도대체 어떻게 알아냈는지 특정 소프트웨어의 제품 key를 생성해 주는 툴이 버젓이 굴러다니곤 했다. 그렇기 때문에 요즘은 이 제품 key가 실제 구매자가 사용하는지의 여부를 제품 개발사 서버로부터 일일이 추가로 확인받곤 한다.

설계 차원에서 결함이 있지 않은 안전한 암호화 알고리즘이라면 key 없이 복호화를 하는 방법이 존재하지 않는다. 그렇기 때문에 이런 암호문은 그냥 a부터 z까지 모든 글자 조합을 무식하게 일일이 대입하는 brute force 방식으로만 풀 수 있다.
패스워드의 길이가 한 글자 늘어날 때마다 공격에 소요되는 시간이 수십 배씩 기하급수적으로 늘어나니.. 이 시간 덕분에 오늘도 인간의 컴퓨팅 세계는 딱히 금융 사고나 개인정보 유출 사고가 별로 없이 안전하게 돌아가고 있다.

하지만 컴퓨터의 계산 성능은 하루가 다르게 향상되고 있고 암호 공격은 병렬화에도 아주 유리한 분야이다.
이런 brute force 공격을 저지하기 위해 요즘 암호를 입력받는 프로그램, 웹사이트 등에서는 암호가 틀릴 때마다 수 초씩 딜레이를 일부러 주고, n번 이상 암호를 틀리면 계정을 정지시키는 조치까지 취한다. 그 어떤 암호 시스템도 하나하나 다 대입해 보는 제일 무식하고 원천적인 전수조사에는 언젠가 뚫릴 수밖에 없는데.. key가 너무 허술하게 만들어져 있으면 거기에 더욱 취약해질 것이다.

3. 공개 키 암호화

지금까지 key를 따로 받지 않는 대표값 변조(해싱), 그리고 key를 받는 대칭 키 암호화까지 얘기가 나왔다. 대칭 키 암호화는 입력 데이터를 받아들이는 방식에 따라 블록 암호화 내지 스트림 암호화로도 나뉘는데, AES/DES 같은 것들은 블록 암호화로 분류된다.
그런데 1970년대에는 이런 것과는 성격이 근본적으로 다른 완전히 새로운 암호화 분야가 개척되었다. 바로 대칭이 아닌 비대칭, 또는 공개 키 알고리즘이라는 개념이 제안되고 개발된 것이다.

왜냐하면 제아무리 날고 기는 복잡 정교한 암호화 알고리즘이 있다 하더라도 그것들은 발신자와 수신자가 모두 동일한 key를 알아야 하고 보안을 위해서는 수시로 교체해야 하고, 그 바뀐 key를 모든 구성원에게 전해 줘야 한다는 원천적인 한계와 위험성이 있기 때문이다. 군대에서 새 암구호를 어떤 절차를 통해 전파하는지를 생각해 보자.

key를 주고 받는 건 암호라는 걸 운용하는 모든 조직이 감내해야 하는 어쩔 수 없는 숙명인 것 같다. 하지만 암호화 때 사용되는 key와 복호화 때 사용되는 key가 다르고(비대칭), 전자는 마음대로 주변에 공개해도 되는(공개 키) 알고리즘은 이런 한계를 극복해 준다. 이런 마법 같은 일이 어떻게 가능할까..?

이 암호화는 수학적 비가역성 내지 난해함에 근거를 두고 있다. 자릿수가 많은 두 수를 곱하는 건 사람의 입장에서 몹시 고된 노가다이겠지만.. 역으로 이미 곱해진 듣보잡 수를 아예 소인수분해 하는 것은.. 뭐 차원이 다를 정도로 난감하고 시간이 오래 걸리는 일일 것이다. 페르마 수 같은 게 n이 조금만 커져도 합성수인 것만 알려졌을 뿐 완전한 소인수분해가 안 된 놈들이 부지기수인 게 이 때문이다.

공개 키 암호화 중 하나로 유명한 RSA는 수십 자리 이상의 엄청나게 큰 소수 둘을 골라서 이 원천으로부터 공개 key와 개인 key pair를 만들어 낸다. 즉, 처음부터 동일한 원천으로부터 두 key 쌍이 계산에 의해 만들어진다는 것이다. 비록 계산이긴 해도 한 key로부터 나머지 key를 역으로 유도하는 것은 무진장 어렵고 시간이 많이 걸린다.

이런 공개 키 암호화는 제약이 크다. 앞서 살펴봤던 재래식(?) 암호화처럼 임의의 메모리 블록이나 문자열을 취급하지는 못하며, 평문과 key, 암호화 결과 모두 그냥 숫자 달랑 하나일 뿐이다. 숫자에다가 문자열에 맞먹는 정보를 담으려면 그 수가 엄청나게 커져야 한다.
그리고 얘는 그런 주제에 계산량이 차원이 다르게 많다. 컴퓨터 친화적인 XOR이나 비트 회전 같은 게 아니라 거대 정수에 대한 산술 연산을 무진장 해야 하기 때문이다.

그렇기 때문에 이런 암호화 알고리즘은 재래식 블록 암호화처럼 몇 MB짜리 데이터 자체를 암호화하는 단순한 용도로 쓸 수 없다.
그 대신 재래식 암호화 알고리즘에다가 돌릴 짤막한 key만을 암호화하는 용도로 병행해서 쓰인다. 멀티스레드 프로그램에서 TLS 슬롯은 공간이 한정되어 있으니 거기에다가 생 데이터를 몽땅 저장하는 게 아니라 그냥 포인터만 저장해 놓는 것과 비슷한 이치랄까..? 마치 손실 압축과 비손실 압축만큼이나 고유한 용도가 있는 셈이다.

https 보안 사이트 내지 인터넷 뱅킹에서 로그인을 할 때 시간이 0.n초나마 랙이 있는 이유는 네트워크 트래픽 때문이 아니라 순수하게 계산 때문에 그렇다. 그때마다 암호 해독을 위해 OpenSSL에 구현된 BigInt 같은 라이브러리의 코드가 실행되면서 큰 수 연산과 값 비교가 행해진다고 생각하면 되겠다.

공개 키 암호화로서 RSA가 아주 유명하지만 이런 소수와 소인수분해 말고 타원곡선이나 이산로그 같은 다른 어려운 연산에 기반을 둔 알고리즘도 있다.
이 암호화 기술은 인터넷의 발달과 더불어 우리의 생활을 크게 바꿔 놓았다. key를 위험하게 통째로 주고받지 않아도 되는 암호화 덕분에 인터넷 상으로 금융 거래도 할 수 있게 되고 디지털 서명, 인증서라는 것도 존재할 수 있게 됐기 때문이다!

보통은 공개 key로 암호화를 해서 개인 key로 복호화를 하는데, 반대로 어떤 문서를 개인 key로 암호화하고 공개 key로 복호화하게 하면 된다. 그러면 이 문서는 누구나 열람은 가능하지만, 만든 사람은 그 공개 key에 대응하는 개인 key의 소유자밖에 없다는 것이 입증된다. 놀랍지 않은가?

hash가 어떤 데이터가 원본과 동일한지 무결성을 보장한다면, 공개 key 암호화는 어떤 데이터가 반드시 특정인으로부터 만들어졌고 변조되지 않았다는 것을 보장할 수 있다.
도장이고 자필 서명이고 자물쇠와 열쇠 같은 모든 실물은 조작이 가능하며 컴퓨터야 뭐 0과 1 무엇이건 해킹이 가능한 디지털 세상이다. 이런 바닥에서 믿을 것은 수학적인 비가역성밖에 없어진다는 것이다.

이 세상에서 생명을 다루는 의료 다음으로 중요하고 착오가 절대로 없어야 하는 크리티컬한 임무는 아무래도 돈 거래, 기밀 거래일 텐데, 이 정도 기반은 갖춰진 뒤에야 인터넷이 안전하게 돌아가고 있다. 그러나 초창기에 인터넷은 기반 프로토콜 차원에서 이런 암호화 알고리즘이 제공되지 않았다.

그렇기 때문에 전자상거래나 인터넷 뱅킹을 남보다 일찍 서둘러 구현하려면 특정 운영체제에 종속적인 온갖 비표준 편법 기술이 동원돼야 했다. 오죽했으면 2000년대 초에 SEED 같은 알고리즘까지 개발한 걸 보면 공개 키뿐만 아니라 대칭 키 암호화까지 모두 허술했던가 보다.
허나 이게 바로 우리나라 특유의 IE + ActiveX 의존이라는 독이 되어서 오늘에 이르고 있다. 일본이 일찍부터 철도 왕국이 되긴 했지만 협궤 때문에 발목 잡힌 것과 비슷한 현상이랄까..?

이상이다. 인증서가 어떻고 공개 키, 개인 키, 디지털 서명 이러는 바닥은 통상적인 hash나 블록 암호화와는 영역이 상당히 다르다는 것, 그리고 이런 공개 키 암호화 덕분에 인터넷 보안 수준의 차원이 달라졌다는 것이 핵심이다. 이 바닥도 날고 기는 괴수들이 너무 많다..;;

Posted by 사무엘

요즘 학교나 관공서의 전산망에서는 인터넷 접속을 위해서 특정 보안 솔루션 ActiveX들과 그것도 모자라서 바이러스 백신까지 무조건 설치하라고 강요하는 걸 볼 수 있다. 그걸 안 하면 사이트 접속이 되질 않게 해 놓았다.  허나 본인은 그런 보안 솔루션들에 대해 정서적으로 굉장한 반감을 갖고 있으며, 그것들을 몸서리치게 싫어한다.

여러 보안 솔루션 중 키보드 보안 프로그램이 하는 역할은 아마도 사용자의 키 입력(비밀번호 같은)을 메시지 훅킹으로 가로챌 수 없게 하고, 반대로 없는 키 입력을 소프트웨어적으로 생성할 수 없게 하는 일일 것이다(온라인 게임에서 오토의 실행 차단). 또한, 은행 돈거래 관련 정보가 담긴 패킷은 정보가 유출되더라도 의미 파악이나 변조가 거의 불가능하게 아주 복잡한 계산을 동원한 암호화/해독이 클라이언트에서 행해져야 할 필요가 있을 것이다. 그런 기술적인 필요를 본인은 모르는 건 아니다.

다만, 웹 표준만으로 도저히 구현할 수 없는 운영체제 커널 기술 수준의 보안이 불가피하게 필요하다면, 차라리 무리해서 웹 애플리케이션을 만드는 걸 포기하고 깨끗하게 로컬 환경에서 돌아가는 exe 형태의 프로그램과 배포 패키지를 만들었으면 좋겠다.

nProtect 부류의 이상한 프로그램들은 웹브라우저를 끈 뒤에도 계속 메모리 차지하면서 남아 있는 것 정도나 보기 싫은 수준이고 그나마 ‘낫다’. 하지만 이놈의 빌어먹을 백신은 답이 없다. 바이러스나 악성 코드에 걸리지 말라고 설치하는 솔루션들이, 깔고 나면 악성 코드나 그 이상 수준으로 민폐 끼치면서 컴퓨터 성능을 쪽쪽 갉아먹기 때문이다. 좀 심하게 표현하면 컴을 완전히 병신으로 만들어 놓는다.

마치 치안과 국방을 담당해야 할 자국의 정규군이나 경찰이 하라는 일은 안 하고 자기네들부터 민폐 끼치고 민간인들을 등쳐 먹는다거나, 반공을 빌미로 공권력이 심심하면 멀쩡한 생사람을 빨갱이로 몰아서 잡아 죽인다거나 하는 상황을 생각하면 되겠다.

맥북 이전 4대 노트북을 쓰던 시절의 일이다. 본인이 다니는 학교는 내부에서 와이파이로 인터넷에 접속할 때 NetCare인지 뭔지 하는 보안 ActiveX와 바이로봇 백신을 반드시 설치하도록 강요를 하고 있다. 둘 중 하나라도 설치를 안 하면, 몇몇 사이트는 아예 접속이 되지 않거나 쿠키가 저장되지 않아서 로그인을 할 수가 없으며, 되는 사이트도 보안 솔루션들을 설치하라고 협박하는 문구가 든 프레임이 웹사이트에 제멋대로 추가되어 나오곤 했다.

그래서 본인은 어쩔 수 없이, 울며 겨자 먹기로 마지못해 깔라는 것들을 다 설치해 줬다. 그러자 저런 성가신 현상이 모두 없어지고 인터넷은 잘 되기 시작했다. 그러나 그 뒤부터 내 컴에서는 끔찍한 헬게이트가 시작되었다.

부팅 직후에 시스템이 시작 메뉴 구동 같은 각종 조작에 응답하는 속도가 눈에 띄게 느려졌고, 웹브라우저가 페이지를 여는 속도, 전반적인 파일 액세스 속도도 인내심의 한계를 느끼는 수준이 되었다. 최대 절전 모드에서 복귀하는 시간까지 예전보다 훨씬 더 길어졌다. 멀쩡하던 컴퓨터가 진짜 만신창이 장애인이 된 느낌이었다. 평상시에 운영체제의 메모리 사용량도 예전보다 수십 MB가량 늘었다.

나는 운영체제의 업데이트들은 목록만 자동으로 받게 한 뒤, 다운로드와 설치는 내가 지정한 것만 수동으로 하게 해 놓고 있었다. 그랬는데 그 보안 솔루션은 나의 설정을 씹고, 인터넷만 됐다 하면 마구잡이로 온갖 업데이트들을 제멋대로 받아서 설치했다.

언제부턴가 MS 오피스가 SP2이던 게 느닷없이 SP3으로 바뀌어 있었다. 프로그램이 버전업되어서 좋은 게 아니라 도리어 부아가 치밀었다. “이 자식, 지금까지 왜 이리 느리고 쓸데없이 디스크 액세스를 하는가 했더니, 그 수백 MB짜리 업데이트를 내 동의도 없이 제멋대로 설치하느라 그랬군.” 하는 생각에 말이다.

참다못해 하루는 넷케어고 백신이고 전부 다 모조리 지워 버렸다. 요즘은 백신도 용량이 몇백 MB 수준으로 뭘 하느라 그리도 커졌는지 모르겠다. 이것들을 다 지우고 나자 내 컴퓨터는 거짓말처럼 평화가 찾아왔다. 모든 성능이 예전 상태로 돌아갔다. 보안 솔루션들이 그들의 퇴치 대상인 악성 코드가 하는 짓을 동일하게 하고 있음이 입증된 순간이었다.

이제 맥북을 사용하면서 뜻하지 않게 얻은 큰 수확이 있다. 보안 솔루션 제약은 Windows 운영체제에만 적용되며, 맥에서는 그런 게 전혀 없이도 인터넷을 곧바로 자유롭게 이용할 수 있다는 것. 야호! 빌어먹을 넷케어니 바이로봇 따위를 설치하지 않아도 된다. 맥OS가 날 구했다. 스잡빠니 애플빠니 난 그딴 건 모르지만, 어쨌든 이거 덕분에 맥OS 호감도가 급상승했다.

한편, 고향에서도 비슷한 일을 최근에 겪었다. 고향집 컴퓨터가 언제부턴가 병신 중의 상병신이 돼 있었다. 부팅 후에 시작 메뉴를 눌러도 한참 동안 반응이 없고, 웹브라우저를 띄운 뒤에 창이 나타나기까지 몇 분이 족히 걸리고 있었다. 레지스트리나 파일 디렉터리를 살펴봐도 딱히 악성 코드에 걸린 것 같지는 않은데 영문을 모를 노릇이었다.

이 현상의 주범은 바로 V3 Lite였다. 이놈을 당장 지우자 컴퓨터는 운영체제를 갓 설치한 직후처럼 아주 쌩쌩해졌다! 그러니 난 도대체 진짜 악성 코드란 어떤 놈인지 가치관의 혼란을 겪을 수밖에 없었다.

바이러스가 묻은 메일 첨부 파일을 클릭한 것도 아니고, 이상한 사이트를 돌아다니다가 ActiveX 설치에 ‘예’를 누른 것도 아니었다. 이 V3은 어머니께서 집에서 인터넷으로 업무를 보시기 위해 어쩔 수 없이 설치한 것이었다. 이거랑 무슨 희한한 듣보잡 ActiveX들을 설치하지 않으면 직장의 업무 자동화 시스템에 접속이 되질 않기 때문이었다.

이런 일련의 사건을 겪은 뒤, 나는 더욱 더 백신 따위는 죽어도 절대로 쓰지 말아야겠다는 생각을 굳게 하게 되었다. 옛날처럼 백신이 그냥 사용자가 요청할 때만 파일이나 메모리를 스캔하면서 바이러스 검사를 해 주던 시절이 그립다. 저런 거지 같은 잉여 쓰레기 프로그램을 얹고도 작업을 원활하게 하려면, 가히 정말 최신식 최고급 컴퓨터를 써야겠다. 아니, 내 컴퓨터가 아무리 빠르고 메모리가 썩어 넘친다 해도 저런 프로그램에게 컴퓨터 자원을 내어 주기는 싫다.

보안을 빌미로 원치 않는 프로그램의 설치를 강요하는 이런 못돼먹은 풍조가 좀 없어졌으면 하는 바람이 있다. 이런 일이 계속될수록 이에 대한 반발 심리로 나의 컴퓨터 보안 위협 불감증은 더욱 커질 것이다.

Posted by 사무엘

1.
병특 회사에서 근무하던 시절의 일이다.
그때 본인은 본업을 넘어-_-, ActiveX 컨트롤을 만들어 관리하던 적이 있었다.
(사용자들이 아무리 ActiveX 욕하고 우리나라가 무슨 MS 공화국이네 뭐네 하면서 까도, 일선 개발자들은 위에서 까라면 깔 수밖에 없다. 더구나 본인은 국방부 시계가 돌아가던 중! ^^;;; )
ActiveX는 내부에 플래시 UI를 하나 만들어서 플래시는 웹 상에서 사용자와 소통을 하고, ActiveX는 플래시와 소통을 하면서 플래시만으로 하기 힘든 네이티브 코드를 수행했다. 내가 왕년에 저런 일까지 했다니..

그런데 문제가 있었다. 정확하게는 기억이 안 나지만, ActiveX든 플래시든.. 뭔가 로컬에 있는 파일을 참조하는 건 아무 문제가 없었는데 웹에 있는 놈을 가져오는 건 아무 이유 없이 도무지 되지 않고 작동을 거부하는 것이었다.
먼 옛날 일이 됐으니 망정이지, 이것 때문에 당시 회사에 환멸을 느낄 정도로 좌절하고 삽질했었다. -_-;;

문제의 원인은 보안이었다. 그 당시 갓 출시된 플래시 7이던가 8이던가.. 하필 그때부터 보안 정책이 딱 바뀌어 플래시의 액션스크립트는 아무 웹에서나 정보를 덥석 가져오지 못하게 되었다.
그 반면, 내 로컬 컴퓨터의 ....\flash player\#security\flashplayertrust 이런 디렉터리에다가 configuration file을 만들어서 접근을 허용하는 웹 주소를 먼저 적어 줘야 하고, 플래시는 허용된 웹으로만 접근할 수 있다.
자세한 정보: http://kb2.adobe.com/cps/116/1165eb90.html

어쨌든 이것 때문에.. 가장 권한이 많고 강력한 ActiveX가 DllRegisterServer를 통해 등록될 때 저 flashplayertrust에다가 우리 플래시에 대한 정보를 덩달아 등록해 주고, 등록 해제될 때 그 정보를 삭제하도록 함으로써 문제는 일단락되었던 걸로 기억한다. ActiveX는 네이티브 코드인 관계로 파일, 레지스트리, 웹 등에 다 접근이 되고, 심지어 Win32 API를 직접 호출해서 뭐든 다 할 수 있으니.. 사기 유닛이다.

물론 오늘날은 다른 웹 표준과 RIA 기술도 풍부한데 저런 무식한 방법을 쓰는 건 곤란하다.
참고로 플래시에 전설의 flv 동영상이 추가된 게 그 무렵부터일 것이다. 유튜브가 그때 막 태동했으니 말이다. 플래시가 벡터 드로잉 애니메이션뿐만 아니라 일반 비디오 플레이어 분야도 섭렵하기 시작했으며, 덕분에 이제 인터넷으로 동영상 볼 때 ActiveX 설치를 요구하는 사이트는 개념 없다는 소리를 듣기 시작하게 됐다.

2.
안드로이드 어플 만들면서도 비슷한 경험을 했다. 아놔 다른 프로그램에서는 잘 되는 환경설정 변경이 왜 도대체 안 되고, 기껏 되더라도 왜 내가 바꾼 환경설정이 다른 곳에 도무지 적용이 안 되는지.. 함수 호출 결과는 성공인데.. 그 뒤 결과는 그냥 씹히고 있던 것이다.
하루를 삽질하고 났더니 원인은 역시 매니페스트 파일에다가 android.permission.WRITE_SETTINGS , android.permission.CHANGE_CONFIGURATION 요 따위 퍼미션 요청을 안 해 놨기 때문이었다.

3.
그동안 유닉스 계열 OS에 비해 권한이나 보안 같은 관념이 너무 약하던 윈도우도, 비스타부터는 그쪽으로 좀더 엄격해졌다.
잘 알다시피 사용자 계정 컨트롤(UAC)라는 게 추가됐으며, 프로그램을 관리자 권한으로 실행할 때와 그렇지 않을 때에 허용되는 권한의 차이가 매우 커졌다. 가령, 관리자 권한이 아니면 '내 문서' 말고 다른 디렉터리에다가는 파일을 제대로 만들지도 못한다.

그리고 이 프로그램이 요구하는 권한을 명시하는 게 가능해졌다.
아무 권한에서나 실행 가능한지, 무조건 관리자 모드에서 실행돼야 하는지 하는 걸 말이다.
지정은 EXE 내부의 매니페스트 XML에다가 하면 된다. 그 개념은 이미 윈도우 XP에서 시스템 DLL의 로딩 방식을 제어하기 위해 도입된 바 있으므로 새삼스러울 게 없다.
비주얼 C++ 2008부터는 링커 옵션에 이걸 바로 지정해 주는 게 추가됐다. 그 이전 버전에서는 사용자가 직접 xml 파일을 손으로 써서 링크해 주면 된다.

스크린 키보드처럼 장애인 Accessbility용 프로그램은 의외로 높은 보안 수준이 필요하다.
내가 받은 입력에 대한 결과를 시스템 모든 프로그램에다가 끼쳐야(키보드 입력 흉내) 하기 때문에
이런 프로그램은 별도의 인증을 거쳐야 운영체제가 그 정도의 권한을 허락하게 되어 있다.
그런 인증을 거치지 않은 "<날개셋> 입력 패드"는, 사용자가 직접 관리자 권한으로 실행해 주지 않으면,
자기보다 권한 등급이 높은 프로그램에다가는 글자 입력을 전달해 줄 수 없다.

글을 맺는 소감:
삽질해야 하는 게 싫다. -_-;;
지금 유닉스 명령어 익히느라 땀 뻘뻘 흘리는 걸 보면, 옛날에 지금보다 영어도 훨씬 더 못 하던 시절에 도스 명령은 어째 알아서 외웠는지 궁금하다.
지금 이놈의 안드로이드 때문에 삽질하는 걸 보면, 옛날에 윈도우 API는 어째 공부했는지 내가 생각해도 나 자신을 이해할 수 없다.
그때는 삽질을 삽질이라고 여기지 않고 전적으로 재미로 했기 때문에 프로그래밍에 재미를 붙일 수 있었던 것 같다.

Posted by 사무엘

Posted by 사무엘