리눅스, 키보드 보안

태그를 제대로 정의했나 모르겠습니다.

각설하고,
왼쪽 goole custom search 에서 "키보드보안" 을 검색해보시면 실질적으로 키보드보안에 대해 논쟁한 두어개의 쓰레드를 보실 수 있습니다.
요약하면, "법으로 강제하느냐" 와 "필요있냐" 정도이며, 여러분들께서 나름대로의 주장을 펼쳤습니다.

"법으로" 와 "필요"에 대한 얘기는 이 쓰레드에서 보지 않기를 희망합니다.
순수하게 엔지니어의 "기술적" 소견만을 기술하여,
최소한..... 과연 "보안위험" 이라는 것이 존재하는 것인가, 존재한다면 "어디에" 있는 것인가에 대한 나름대로의 결론을 독자들이 내릴 수 있도록 도와주세요.

우연찮게도 제가 지난 9월 중순에 시작해서 10월말에 "코딩"을 끝낸 프로젝트가 "리눅스 키보드 보안" 이었습니다.
이제부터 주절댈 이야기는 코딩을 하기 전에 검토한 사항들과 코딩 중에 알게 된 사실들입니다.

시중에는(?) 이미 존재하는 많은 키로거들이 있습니다.
간단하게는 i8042 포트 스니핑, 좀 더 발전된 것으로는 콘솔/터미널 스니핑이 있습니다.
걔중에는 사악하게도 커널 모듈에서 네트웍을 이용 취득한 정보를 빼돌리도록 작성된 것도 있습니다.
(네트웍을 이용해서 뭔가 빼돌려지고 있다는 것조차도 사용자가 인지하지 못하도록 정말 사악하게 작성되어 있습니다)

실질적으로, "리눅스" 에서 "키보드보안" 을 한다는 것에는 적지않게 모순이 있습니다.

첫째로, 앞선 쓰레드에서 많은 분들이 지적하신 것 처럼 "키보드보안"을 위해 뭔가를 설치하는 것 자체가 "위험"합니다.
특성상 하드웨어를 밀착해서 다뤄야 하기 때문에 (조금 아래에 자세히 적겠습니다),
커널 모드에서 돌아가는 모듈이 필요합니다. 커널 모드에서 돌아가는 모듈을 설치하기 위해선 root 권한이 필요합니다.

두번째로, "키보드"만 보안의 대상이 될 수가 없습니다.
누군가 키로깅을 하고 있다면, 그 시스템은 이미 크랙당한 것이므로, "보안" 이 될 리가 없습니다.
단순하게 커널만 바꿔치기해도 아무 문제 없이 편안하게 키로깅이 됩니다.

상황이 이럼에도 불구하고, 정부(국정원)에서는 MS windows 적인 개념을 탑재하고 "키보드보안"에 대한 몇가지 요구조건을 내 걸었습니다.
이 요구조건의 목적은 "기술적으로 키보드를 보안" 하겠다는 것이 아니라 "사용자를 안심" 시키는 것에 목적이 있다고 보여집니다.
앞선 쓰레드에서 몇몇 분들께서 지적하신 것 처럼, 오히려 사용자를 나태하게 만드는 효과가 더 큽니다.
(실상, 위에서 말씀드린 모순은 MS windows 라 해도 별반 다르지 않습니다. 커널 엔지니어라면 동의하실 겁니다)

1. 커널 모드 모듈, 유저 모드 모듈의 소스가 공개되면 안된다.
2. 커널 모드 모듈과 유저 모드 모듈의 통신은 암호화 되어야 한다.
3. 개인 방화벽이 있어야 한다.

1,2 번은 그렇다치고 개인 방화벽은 이 글을 읽는 모든 분들께서 의아해하실 것입니다.
"xx 프로그램이 xx 포트를 사용하려 합니다. 허가하시겠습니까 ?"
라는 대화상자를 일반 유저가 봐야하고, 심지어 제어까지 할 수 있다면, 그게 바로 hole 이니까요.
"허가" "취소" 라는 액션이 중요한 게 아니라, 이 절차를 수행할 초월적인 존재가 필요하다는 것이 문제의 핵심입니다.
어찌됐든, 이 세번쨰 항목은 어떻게 해서든 국정원을 설득해야만 한다는 것이 제 동료 엔지니어들의 소견입니다.
여러분들 생각은 어떠하십니까 ?

여기서부터 기술적인 내용이 들어가므로 이해를 돕기 위해서 커널 파트를 2.6 을 중심으로 잠시 개략적으로 설명드려야겠습니다.
부족한 내공에 초식이 잘못 나갈까 염려되기도 하지만, 설마 죽을 정도의 반격을 받겠냐하는 심정으로 씁니다.

먼저 리눅스 커널의 input subsystem 중 키보드 부분입니다.

event driven 이며, 크게 나눠 event generator 와 event handler 로 구분됩니다.
input core 에서는 handle 단위로 관리하며 handle 은 generator 와 handler 를 연결지어주는 객체라 보시면 됩니다.
N 개의 generator 와 M 개의 handler 가 있다면, 일반적으로는 N*M 개의 handle 이 생성됩니다.
다시말하면 어떤 generator 에서 발생한 event 는 모든 handler 에게 전파됩니다.

generator 로는 일반적으로 serio bus 에 속한 부류와 USB bus 에 속한 부류가 있고,
handler 로는 일반적으로 콘솔과 디버깅 혹은 유저모드 핸들러용의 설비, 이렇게 두가지 뿐입니다.

두번째로,
serio bus 도 event driven 이며, 크게 나눠 event generator 와 event handler 로 구분됩니다.
generator 로는 i8042(또는 그 호환)칩과 serio decipline 으로 작성된 serial keyboard 등이 있습니다.
handler 는 input event generator 의 역할을 하도록 구현되어 있습니다

세번째로.
USB bus 도 event driven 이며, 크게 나눠 event generator 와 event handler 로 구분됩니다.
generator 는 USB core 이고,
handler 는 HID class 드라이버이며, 이 역시 input event generator 의 역할을 하도록 구현되어 있습니다.

주변에서 보는 키보드의 동작과정을 알기 쉽게 그림으로 그려보면

 PS/2 keyboard  <-> i8042 <-> serio subsystem <-> input subsystem <-> console
            serial keyboard <-> serio subsystem <-> input subsystem <-> console
               USB keyboard <-> USB subsystem <-> input subsystem <-> console

이 되겠고, 일반적인 상황이라면 위의 세가지로 모든 키보드를 정의할 수 있습니다.
구태여 이렇게 주절댄 이유는, 위의 그림에서 보시는 <-> 표시의 화살표가 sniff/crack point 이기 때문입니다.
밑에서 부터 차근차근 기어올라가서 console 까지 짚어보겠습니다.

i8042 는 지금은 그 데이타시트조차도 구하기 힘든 정말 오래된 물건이지만,
호환칩을 장착하건 super I/O 칩셋에 포함을 시키건 방법을 가리지 않고 모든 x86 desktop 메인보드에 포함되어 있으며
x86 뿐만 아니라 PS/2 키보드를 사용하는 거의 모든 workstation 에 들어있습니다.
이 i8042 를 주목해야 되는 이유는,
이것이 memory mapped I/O 방식으로 CPU 에 붙어야 되는 칩이고,
리눅스에선 physical address 만 알 수 있다면 유저모드에서도 접근이 별로 어렵지 않은데다가,
워낙 오래 전에 나온 스펙이라 한번 발생한 event 는 다음 번에 다른 event 가 발생되기 전까지 언제 어느 때나 칩에서 읽어내는 것이 가능하기 때문입니다.
기본적으로 interrupt 신호를 제공하기는 하지만, polling 방식으로 드라이버를 구현해도 무리가 없도록 만들어진 칩입니다.
x86 계열에선 ia64 를 제외하면 인터럽트 번호와 포트 주소가 모든 데스크탑에서 동일합니다.
사실, 가변이라도 크래커 입장에서는 별로 상관없습니다. 어찌됐건 /proc/ 의 정보를 읽어보면 죄다 나오니까요.
유저모드에서 physical address 를 사용해서 직접 접근을 하려면 /dev/mem 을 사용하는 것으로 충분하지만,
x86 에선 특별히 iopl() 부류의 함수를 제공해서 좀 더 쉽게 I/O 공간에 접근을 할 수 있습니다.
물론, 어느 방법이나 root 권한이 필요합니다.
다시말해 root 권한만 있으면 i8042 포트를 유저모드에서조차도 직접 읽어낼 수 있으며,
결국 PS/2 키보드가 발생시킨 키 코드를 거의 아무런 문제도 발생시키지 않고 그대로 캡쳐할 수 있습니다.

serial keyboard 는... PDA 를 사용하시는 분들은 간혹 접해보셨겠지만 처음 들어보시는 분이 더 많으실겁니다.
2000년 쯤의 ipaq 용으로 출시된 stowaway 키보드를 기억하시는 분이 계시다면 이해가 빠르시겠습니다.
RS232 protocol 을 사용하며 대개가 9600bps 정도입니다.
리눅스 커널의 serial decipline 은 serio 와 tty 를 연결시켜주는 유저모드 드라이버(데몬)의 개념입니다.
짐작하시다시피 터미널 스니핑 기법을 이용하면 tty 스니핑이 가능하므로 키보드에서 발생한 키코드를 캡쳐하는 것이 가능합니다.
하지만, 이런 키보드를 데스크탑에서 쓰는 경우는 아마도 거의 없을거라 짐작됩니다.
미래에 인터넷뱅킹 전용 kiosk 등에서 제조비 절감의 목적으로 사용할 여지는 있습니다만.

USB keyboard 는 설명드릴 건덕지도 없고, 능력도 부족하네요.
bus 특성상 generator 한개에 handler 한개라는 1:1 매칭이며,
HID 특성상 대부분을 input subsystem 에 의존하기 때문에 별도의 복잡하고 유연한 설비는 없습니다.

장치는 이쯤하고, serio bus subsystem 과 USB bus subsystem 을 짚어보겠습니다.

serio bus subsystem 은 generator 한개당 handler 한개라는 1:1 정책을 가지고 있습니다.
이를 binding 이라 부르며 기존의 커널을 변조하지 않은 상태에서 event 를 가로채는 것이 불가능하다는 것이 제 소견입니다.
다만, 디버깅 설비를 사용하여 printk() 로 메시지가 찍히도록 할 수 있을 것 같은데,
아무리 해도 안되더군요. 코드 상으로는 될 것 같았는데.
serial decipline 을 이용할 시, 유저모드 핸들러 드라이버가 사용하는 tty 를 스니핑하는 것은 가능하지만
serial keyboard 를 사용하는 예가 없다고 봐도 될 정도므로 제껴도 된다는 것이 제 소견입니다.

USB bus subsystem 도 generator 한개당 handler 한개라는 1:1 정책을 가지고 있습니다.
이를 claim 이라 부르며 어떤 장치(USB 개념으로 표현하자면 interface) 에 대해 복수의 claim 을 허용하지 않습니다.
커널이 제공하는 usbfs 와 libusb 라는 유저모드 라이브러리를 사용할 시 usbfs 의 I/O 를 스니핑하는 것이 가능하지만,
HID class 드라이버들은 이미 커널 모드로 존재하며, 유저모드 핸들러 드라이버가 필요없고,
usbfs 는 유저모드와 커널모드 드라이버의 공생을 허용하지 않으므로 기존 커널의 변조 없이는 스니핑이 불가능하다는 것이 제 소견입니다.

버스는 이쯤하고, 이제 리눅스 커널의 input subsystem 을 짚어보겠습니다.
input subsystem 은 매우 유연하며 확장성이 좋고,
그럼에도 불구하고 의외로 복잡하지도 않고 더 이상 개선의 여지도 없을 정도입니다.
앞서 설명드린대로 복수개의 generator 에 대해 복수개의 handler 를 허용합니다.
바꿔 말하면 한 개의 generator 에 여러 개의 handler 가 붙을 수도 있고,
반대로 한 개의 handler 가 여러 개의 generator 를 다룰 수도 있습니다.
크래커가 작성한 input handler 드라이버가 등록된다면,
그 핸들러는 커널에서 다루는 모든 키보드 장치의 키코드를 편안하게 받아볼 수 있습니다.
예외적으로 어떤 handler 가 어떤 generator 를 배타적으로 점유하는 것이 가능(이를 grab 이라 부릅니다) 한데,
커널모드 핸들러 드라이버에서는 사용하는 곳이 없으며,
디버깅 혹은 유저모드 드라이버용으로 제공되는 event device 설비에서만 이 grab 기능을 사용합니다.
바꿔말하면 유저모드에서 어떤 키보드에 대한 event device 를 open() 하는 순간,
그 키보드를 담당한 generator 에서 발생한 모든 event 들은 유저모드 핸들러 드라이버에게만 전파됩니다.
크래커의 유저모드 핸들러 드라이버가 도는 것을 숨기기 위해선 모종의 방법을 써서 키코드를 다시 커널 또는 X 로 포워딩 해야만 합니다.

대망의, 궁극의 그 무엇인 console 을 짚어보겠습니다.
input event handler 의 역할을 하도록 구현되어 있습니다.

(너무 간단한가요 ? 헛헛. 급하시기는. 아래 계속됩니다)

앞선 설명에 input subsystem 은 N 개의 handler 과 M 개의 generator 에 대해 N*M 개의 handle 을 만들어서 관리한다고 했습니다.
정확하게 말하면 "handle 을 만드는" 것은 input core 의 역할이 아니라 input handler 의 역할입니다.
핸들러 객체를 input core 에 등록하면 객체중 .connect 콜백이 input core 에 의해 호출됩니다.
호출될 때 인자로 넘어오는 것은 generator 에 대한 정보이고, input core 에 등록된 모든 generator 에 대해 .connect 콜백을 호출해줍니다.
바로 이 .connect 콜백에서 generator 의 종류등을 검사해서 적절하다면 handle 을 생성하고 handler 와 generator 의 정보를 넣어줍니다.
크래커가 작성한 input handler 드라이버가 스니핑용 input handler 객체를 등록할 때도 마찬가지입니다.
크래커가 작성한 .connect 콜백이 호출되면서 모든 generator에 대한 모든 정보를 얻을 수 있습니다.
물론, generator 자체에 대한 정보는 대수로울 것이 없습니다.
단지... generator 객체를 참조하면 그 generator 와 연결된 모든 handle 을 탐색하는 것이 가능하고,
handle 객체를 얻어올 수 있다는 말은 handler 에 대한 객체를 얻어오는 것도 가능하다는 뜻이며,
그것들 중에서, 자랑스러운 우리 console 의 handler 객체를 선별해내는 것은 일도 아니고,
선별해 낸 handler 객체의 .event 콜백을 크래커의 루틴으로 교체하는 것은 "함수 포인터"에 대한 지식만으로 충분하며,
input core 에서 handle->handler->event() 를 호출하면 크래커의 루틴이 먼저 실행되고 진짜 콘솔루틴이 실행될 것이므로,
이렇게 console 의 함수를 성공적으로 hijack 하는 경우 크래커의 input handler 를 input core 에서 해제해도 상관없습니다.
이미 함수 포인터를 획득했으니까요.

여기까지가 제가 생각해 본 것이고,
나름대로의 방어를 코드로 구현했습니다. 용역이라 제 것이 아니라는 것이 아쉽지만.

아... i8042 포트 스니핑을 방어하는 방법은 거의 유일하게 하나 있는데,
이 방법에서 사용할 수 있는 가장 효율적인 메카니즘은 특허가 걸려있다고 합니다. 어느 업체에서 걸었는지 모르지만.
그 메커니즘이란게... 아주 일반적인 것이라 웃음도 안 나옵니다.
어차피 특허로 공개되어 있으니 여기서 간단히 그것을 설명드리겠습니다.
i8042 포트 스니핑을 막는 방법은 없습니다. 어느 정도는 되겠지만 100% 막지는 못합니다.
그래서 사용하는 방법이... 스니핑을 하더라도 뭐가뭔지 구별하지 못하도록 쓰레기를 잔뜩 뿌리는 것인데요,
문제는 이 쓰레기 키코드를 방어 모듈에서 필터링해야 한다는 겁니다.
어떤 방법이 떠오르십니까 ?

   "scrambler 와 filter 가 공유하는 queue 를 만들고,
    scrambler 는 쓰레기 코드를 queue에 채우고,
    filter는 발생된 이벤트와 queue를 비교해서 같으면 비운다."

마지막으로 남은 것들을 짚어보겠습니다.

국정원의 요구사항 중 "소스비공개" 부분입니다.
GPL 이면 안됨을 강요받는 수준인데, 기술적으론 이것이 가장 힘들었습니다.
GPL 함수를 사용하지 못하니까요. 정말로 맨땅에 헤딩하는 수준의 생쑈를 해야만 했습니다.
이 소스비공개 부분은 심지어 발주처에서도 마음에 들어하지 않습니다.
실 배포시 각종 배포본 및 사용자들의 커널에 맞게 빌드된 바이너리를 배포해야 된단 얘긴데... 참 암담합니다.
부끄럽게도, 엔지니어로써 이렇다 할 대책을 못 내놓고 있습니다.
*.o 와 *.mod.c 를 사용하면 "버전번호" 에 대한 회피는 되지만 이걸로는 감당이 안되네요.

그리고, 국정원의 요구사항 중 "암호화" 부분이 남았죠 ?
다른 쓰레드의 글들에서 "SEED 라는 protocol 표준을 국정원이 정하고..." 라는 글에 대해
다른 분이 "SEED 는 cipher/crypto 다" 라고 댓글을 다셨던데, 두 분 다 맞는 말씀입니다.
키보드 보안은 커널모드 모듈과 유저모드 모듈로 구성되는데,
이 둘 사이에 어떤 형태로든 데이타가 교환됩니다.
이 데이타가 스니핑이 되지 않으리라는 보장은 없습니다.
많은 분이 지적하셨듯 system call hooking 은 커널모드에서도 가능하고 유저모드에서도 가능합니다.
(2.4 에 비해 2.6 은 좀 더 까칠해진 면이 없지않지만 여전히 가능합니다)
스니핑 된다는 것을 전제로 하고, 데이타교환을 해야하므로 encryption 이 필요하고, decryption 도 되야합니다.
SEED 알고리즘은 간단함과 효율성이라는 성능의 측면에서 아주 구닥다리임에도 불구하고 그럭저럭 쓸만합니다.
국정원이 "표준"으로까지 가이드라인에서 제시하는 지는 알고 있지도 못하고, 알고 싶지도 않지만,
"SEED 는 데이타교환 protocol 에서 사용할 수 있는 crypto 입니다"
흔히 PKI 라 불리는 web browser -> web server 사이의 crypto 는 각 사이트(은행)에서 선정한 업체마다 모두 틀리겠지요.

노파심에서 글의 서두에 썼던 것을 다시 당부드립니다.

"법적으로 강제" 는 사실여부와 관계없이 논외로 합니다.
"필요성" 의 부분은 기술적인 입장에서 부정하고 있습디만, 기술적이던 정치적이던 논외로 합니다.
("script kid 가 사용할 수 있는, 각 배포본별로 준비된 변조커널" 이 나올 가능성은 인간적인 관점에서 거의 없다 보여지지만,
설마 리눅서 중에 ... 약간의 지식만으로 누구나 손쉽게 커널을 바꿀 수 있다는 것이 "우리의 자랑" 임을 부정하실 분이 계실리는...)

여러 선후배 기술자/사용자 분들의 기술적인 고견을 듣고 싶습니다.
각종 구멍과 방어기법들이 모두 모여 대적할 자가 없는 open source 가 탄생할 수 있는 발판이 바랍니다.
내공은 잠시 접어두고 초식 얘기라도 듣고 싶습니다.