리눅스, 키보드 보안

bushi의 이미지

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

각설하고,
왼쪽 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를 비교해서 같으면 비운다."

라는 방법론이 특허를 받을 정도로 독보적이고 우량한 건가요 ? 저는 전혀 아니다라고 생각하는데.
queue 에서 head pointer 과 tail pointer 를 두고 각각 따로 처리하는 방법이라는 점.
filter 의 기본적인 동작은 "무언가를 비교" 한다는 것에서 부터 출발한다는 점.
순수하게 조합만으로도 특허의 대상이 될 수 있다는 것은 동의하지만,
정말로 이건 아니지 싶습니다.

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

국정원의 요구사항 중 "소스비공개" 부분입니다.
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 가 탄생할 수 있는 발판이 바랍니다.
내공은 잠시 접어두고 초식 얘기라도 듣고 싶습니다.

danskesb의 이미지

국가정보원이 그리도 대단하다면 외국의 사례를 참고하든가... 외국에서는 키보드 보안 같은 뻘짓 안하고도 인터넷 뱅킹 잘만 돌리고 있습니다. 모든 것을 윈도의 잣대에서 판단하는 국정원이 참 한심도 하네요.
---- 절취선 ----
http://blog.peremen.name

마잇의 이미지

필요에 대한 부분은 논외로 하자고 하셨지만 죄송하게도 그 부분에 대해 적어보겠습니다.

기술적인 부분은 모르고 사용자의 입장에서 생각은 이렇습니다.

키로그 방지 프로그램을 설치해서 키보드 후킹은 방지했습니다. 그런데 제가 사용하는 브라우저가 변조 당해서 은행 사이트와의 통신을 모조리 엉뚱한 곳으로 전송한다고 해보죠. 암호화를 담당하는 프로그램을 장악당하면 말짱 도루묵이라는 생각을 했는데요. 이런 경우가 가능할까요? 가능하다면 이것의 대처는 어떻게 해야 합니까.

기술적으로 완벽한 키로그 방지 프로그램을 설치했습니다. 근데 이걸 변조 당했습니다. 혹은 속아서 엉뚱한 놈을 설치했습니다. 정당한 키로그 방지 프로그램이 설치된 것으로 생각하고 안심하고 인터넷 뱅킹을 했습니다. 자 그럼 제대로 된 키로그 방지 프로그램이 설치될 수 있게 또 무슨 프로그램이 필요한 걸까요?

결국 키로그 방지 프로그램이 꼭 필요하다는 이야기는 제 시스템에서 설치 되고 실행되는 모든 프로그램(프로세스)을 통제하고 확인할 수 있어야 된다는 것 아닐까요?

키로그 방지 프로그램은 사용자 측에서 발생할 수 있는 문제를 방지하려는 생각에서 접근한 해결법입니다. 그런데 사용자 측에서 발생할 수 있는 문제가 키보드 후킹 뿐이냐는 이야기지요. 잘못될 수 있는 수많은 가능성중에 단 한가지이지요.

소수의 제한되고 환경을 통제할 수 있는 영역에 그러한 시도를 하는 것은 나쁘지 않다고 생각되지만 인터넷 뱅킹 같이 범용으로 사용되어질 기술의 보안 정책을 이런식으로 접근하는 것은 너무 비효율적인 방법입니다.

공공장소에 설치되어서 많은 사람이 공동으로 사용하고 따로 관리자가 있고 하는 경우라면 이런 시도를 통해서 보안의 수준을 높이는 것은 괜찮다는 생각입니다.

차라리 뱅킹용 라이브시디를 대량으로 제작해 보급하는게 실제 보안의 효과가 있을 것이라는 생각입니다.

--
마잇


--
마잇

tolkien의 이미지

internet banking을 하려면 지금 쓰고 있는 web이니 irc니 다 닫고 rebooting하라는 건데, 그거면 그냥 windows dual booting으로 만들어 놓고 windows에서 internet banking하는 게 더 편할 것같습니다. (조금 비꼬았습니다.)

국정원은 뭔가 internet banking이라는 신기술에 대한 보안 지침이 필요했고, 그 지침을 windows라는 플랫폼에 맞춘겁니다. secondary os인 linux는 그때 생각도 못했을테고, linux에서 internet banking을 하자니 법이 없으면 지멋대로 하면 그만인데, 이미 법 비스무리한 것이 있으니 법을 바꾸던가, 아니면 삽질해서 따라가야 합니다. (이게 현실입니다.)

그나마 정부에서 보편적인 접근성.이라는 주제에 조금 관심을 보이는 것같아서 다행입니다. (저 글 쓴 아찌가 한 프로젝트가 그것의 일환일 것같습니다.)

linux에서 internet banking은 한국에서 이렇게 삽질로나마 역사를 시작했으면 좋겠습니다. 불합리하거나 부당한 것은 따져서 바꾸면 되는 것이고, 제 생각에 중요한 것은 "linux로 internet banking"을 하려는 무리가 대한민국 국민에서 무시하지 못할만한 숫자라서 다음 정책을 수립할때 담당자의 고민사항으로 떠오르면 좋겠습니다. ^^;;;

마잇의 이미지

간략하게 말씀드리면 키보드 보안 프로그램이라는 시도 자체가 사용자측에서 발생할 수 있는 수많은 상황중에 단 하나의 상황을 체크해주는 것이고 이마저도 높은 신뢰도를 가지기는 힘든 것 이라는 생각입니다.

윈도우즈든 리눅스든 키보드 보안 프로그램의 설치를 의무화 하는 것은 실제 그게 뭔지도 모르고 '몸에 좋다니까 일단 하고 보는' 그런 방식의 접근으로 보입니다.

키보드 후킹 프로그램이 깔릴만한 컴퓨터면 운영체제 재설치 후 서비스팩, 업데이트, 방화벽 설치 확인, 이런것 부터 하는게 순서 아닐까 생각됩니다. 키보드 후킹이 가능한 컴퓨터이면 또 다른 뭔가도 있지 않겠습니까? 그런 상황에서 키보드 보안 프로그램 깔아라 하는 것은 눈가리고 아웅이라고 밖에는 생각이 안됩니다.

라이브 시디 얘기는 저도 비꼰 이야기였습니다.

저는 리눅스에서 인터넷 뱅킹 늦어지더라도 제대로 된 방식으로 되는 것이 낫다는 생각입니다.

이런식으로 풀려다 'XXX 리눅스 제품에서만 인터넷 뱅킹 됩니다'라고 할지도 모릅니다. 키보드 보안 프로그램이 거기서만 제대로 동작하게 했다는 이유만으로요.
--
마잇


--
마잇

bushi의 이미지

당부를 드렸는데도 정치적인 ...
이런들 어떠하리 저런들 어떠하리... 샛길로 빠져볼까요.

대개 직원들의 행동강령은 상관으로부터 내려오는 cascade형 압박인
"내가 깨지면 너는 죽어"
에 기반한다 볼 수 있겠습니다.
일반 사기업에선 어떻게 해서든 뭔가를 큰 잘못 없이 해내야만 위의 압박에서 벗어날 수 있지만,
철밥통 공직사회에선 어떤 핑계를 대서든 아무 것도 하지 않기만해도 대개의 경우는 밥그릇에 이상이 없습니다.

국정원이 MS windows 적인 개념을 탑재했다고 말씀드렸는데,
그분들 생각이 짧고 지식이 부족하다는 비난을 한 것은 아닙니다.
국가와 민족을 위해, 사회 발전의 밑거름이 되고자 적극적으로 뭔가를 해결하겠다는 자세가 아니라
혹시 이게 잘못 돼도 자기들의 인증방법이 아니라 리눅스라는 OS 에게 책임을 덮어씌우려는 의도가 뻔히 보인다는 것을 말한 것입니다.

이러한 의미로 "키보드만 보안" 하는 것은 필요가 없다고 말씀드렸습니다.
키로깅이 되는 시점은 이미 OS 가 해킹당한 후 입니다.
OS 를 해킹한 후에 할 수 있는 키로깅 방법은... 거의 제한이 없습니다. 흔적도 남지 않습니다.

정태영의 이미지

https 등의 인증서에는 위에서 얘기하신 것들을 방지하기 위한 메카니즘이 이미 탑재되어 있습니다.

verisign 등 상위 인증기관의 private 인증서가 외부로 유출되지 않는 이상 위 메카니즘은 충분히 신뢰할 수 있는 구조이구요.

--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

Vadis의 이미지

여담이지만, 제가 키로깅 관련으로 특허를 제출했는데요...키보드 측에서 행하는 물리적 해킹이나 소프트웨어적인 해킹을

아예 다른 루트를 통해 봉쇄하였습니다. 언제 특허가 통과될지 모르겠습니다..

후후후..어제 술을 먹어서 왠지 글에 대한 가독성이 엄청 떨어져 읽기가 괴롭습니다.

제 생각은 소프트웨어적으로 키로그를 완벽히 방어한다는 것은 한계가 있을 듯합니다.(그냥 추측입니다.)

특히 우리나라와 같이 많은 인프라를 가지고 있는 곳에서는 소프트웨어로 국한하지 말고 다양한 인프라를 이용하여

사용한다면 키로깅은 손쉽게 막을 수 있을 듯 합니다. 다만, 다른 해킹에 노출될 수 있다는 점이 있지만요...

좋은 날 즐거운 날....

bushi의 이미지

다른 쓰레드에 달린 댓글 중에 "가상키보드" 에 대한 글이 있습니다.
화면 상에 임의로 배열된 키버튼을 가지는 키보드 그림을 띄워서 계좌번호/비밀번호 등을 입력받는 방법입니다.
오래 전에 사용되다가 사용자들이 불편을 호소해서 폐기되었다고 하는군요.

기술적인 완성도도 중요하지만, 사용자들이 불편해하면 도루묵이 된다는 예가 될 것 같습니다.

Vadis의 이미지

그건 이미 ㄴ은행에서 쓰고 있습니다. 괜찮은 방법입니다. 저도 써보니 불편하지는

않지만, 습관으로 인해서 자주 사용하지 않습니다. 다만 익숙하지 않을 뿐이죠..

Random화게 처리된 화면은 아니였습니다. 좌표값을 통해서 그값을 추측할 수는 있으니

보안적인면에서는 크게 발전한거는 아니지만, 다양한 방법을 통해서 더욱 발전 시킬 수 있습니다.

좋은 날 즐거운 날....

cwryu의 이미지

"소스비공개" 부분에 대해...

불가능한 것 아닐까요? EXPORT_SYMBOL_GPL()을 안 썼다고 해서 GPL을 피해가는 건 아닙니다. EXPORT_SYMBOL_GPL()은 "명백하게 GPL이다"라고 알리는 용도이고 이 심볼을 사용하지 않은 경우에도 애매한 상황에 들어가게 됩니다.

이 경우에는 절대로 독립적으로 개발된 것도 아니고, 따로 떨어뜨려 놓고 생각할 수 있는 결과물도 아닌 명백한 리눅스의 derived work로 보입니다만..

bushi의 이미지

커널만 다룬지 5년 된 것 같습니다.
불순하게도 "피해가는 방법" 만 따지면 가장 손쉬운 방법이 있습니다.

커널의 GPL 은 "OS 로 경쟁하자" 는 것을 막기 위한 선한 의도일 뿐,
h/w 업체나 포럼의 고유한 재산을 포기하고 h/w 또는 spec 무한경쟁으로 내몰기 위한 강제성을 띈다고 보지는 않습니다.
그럼에도 불구하고 GPL 은 GPL 이죠.

실제로 GPL 이 아니라는 전제로 작성되는 바람에 깔끔하고 사용하기 쉽고, 게다가 호환성까지 보장되는 설비를 포기하고 꼼수로 작성할 수 밖에 없었습니다.
예를 들면, input subsystem 의 input_dev 를 제대로 다루기 위해선 GPL 일 필요가 있습니다. 크래커의 스니핑 프로그램을 속이기 위해 가상의 키보드를 만들면 간단할 것을 에둘러 돌아가야 했습니다. 다행히 input_handler 를 다룰 땐 제약이 없었습니다.

GPL 을 좋아하고 존중합니다만, 2.6 커널의 class device 파트는 정말로 악질적입니다. 심지어 혐오스러울 정도로 싫어하는 프레임웍임에도 불구하고 udev 와 연동하려니 선택의 여지가 없이 사용해야 되는데 unregister 쪽은 거의 GPL 입니다.
(앞서 말씀드린 input_dev 도 unregister 쪽만 GPL 입니다)
그래서 unload 가 불가능한 모듈로 배포가 될 거라 예상합니다. 드라이버 업데이트하고 리부팅을 해야만하는 나름대로 익숙한 시츄에이션이 펼쳐지겠죠.
udev 를 포기하고 /tmp/ 따위에 노드를 유저모드 모듈에서 직접 만들어도 별 상관은 없지만, 이것과는 상관없이 애초부터 unload 를 못하게하려고 했기때문에 class device 에 대한 GPL 의존적인 부분은 고려를 하지 않고 있습니다.

GPL 을 비난하거나 EXPORT_SYMBOL_GPL() 을 소극적으로만 보자는 뜻으로 이 글을 쓰는 것은 아닙니다. 다만 EXPORT_SYMBOL_GPL() 이 사용된 곳을 보면 커널이 궁극적으로 원하는 것이 무엇인지 개발자들이 파악할 수가 있다고 봅니다.
개발자들이 파악못하고 법리계 인사들만이 그 정의를 내릴 수 있다면 GPL 이라는 이름이 아깝지 않을까요.

cwryu의 이미지

엉뚱한 얘기를 하고 계신데요..

EXPORT_SYMBOL_GPL()만 피해간다고 해서 GPL을 피해가는 게 아니라고 말씀드린 겁니다. 일단 커널 모듈이면 GPL이 된다는 게 요즘의 지배적인 의견입니다. 얼마나 독립적인 작업물이냐, 분리되었냐에 따라 애매한 상황도 있지만요.

이미 존재하는 라이센스의 합치/불치 여부의 사실 확인 문제를 개발자/개발업체의 편의나 실용성을 이유로 논의하는 건 무의미합니다.

익명사용자의 이미지

지배적인 의견이라는 것이 법적인 소견 또는 판단을 말씀하시는거라면,
리눅스를 탑재한 스마트폰,
리눅스를 탑재한 pmp
류의 제품들은 모두 불법이네요. GPL 에 의거 제가 제조사를 고발할 권리도 있는거죠 ?

폰에 잘 쓰이는 SD 메모리카드는 SD포럼에 의해 드라이버의 소스공개가 금지되어 있습니다.
GPL 이 그리 엄격하다면 SD 드라이버는 커널에 포함될 수 없죠.
voice modem 과의 연결을 위해 종종 사용되는 dualport ram 도 마찬가지 입니다.
dpram 자체는 별볼일 없지만, modem s/w 의 protocol 일부를 구현하고 있으므로 벤더측은 소스비공개를 원칙으로 합니다. 따라서 커널에 드라이버를 포함하는 것이 불가능하네요.

더불어 이런 논란에 대한 명확하고 절대적 지침이 있고
그 지침이란 것이 "GPL 임을 요구함" 이라는 것이라면 module load 에서 구현하면되겠습니다.

EXPORT_SYMBOL_GPL() 을 제외한 애매한 상황이라는 것이 뭔지 전혀 모르겠습니다.
아, 혹시 EXPORT_SYMBOL_GPL()된 함수를 사용하지 못하니 그 함수와 똑같은 함수를 자체적으로 비슷하게 구현하거나 풀어쓰거나 ... 이런 걸 말씀하시는 건가요 ?
만약 이런거라면 말씀과는 정반대로 철저하게 실용적인 측면에서 접근하며 판단을 내려야 할 문제지
법적인 면만을 따지고 들자면 빠져나갈 구멍이 너무 많은데요 ?

정말 애매한 상황이라면...
GPL 은 아니지만 소스가 공개된 드라이버가 있고, 커널의 mutex 설비만을 이용한다고 가정하죠.
커널의 mutex 설비는 GPL 이 아니지만 mutex 디버깅을 위한 설비는 GPL 이라 가정합니다.
대개의 배포본은 kernel-devel 에 상당하는 패키지를 가지고 있습니다.
커널 소스 전체가 아니라 모듈 컴파일에 필요한 것들만을 묶은 패키지입니다.
어떤 배포본의 커널이 mutex 디버깅 옵션이 켜진 상태로 컴파일되었다면
그에 해당하는 devel 패키지의 config 에도 옵션이 켜져 있을 겁니다.
이 상태에서 사용자가 위의 GPL 아닌 소스를 가져다 컴파일을 해서 모듈을 올리면 올라가지 않습니다.

조금 더 복잡하게 mutex 디버깅 옵션을 켜면 mutex 자료구조까지 바뀐다고 가정해보죠.
위에서 예로 든 배포본을 위해 바이너리 모듈을 만드는 것조차도 불가능해집니다.
소스 안에서 mutex 디버깅 설비가 사용되지 않도록 아무리 애를 써봐야
배포본의 커널에 있는 mutex 설비가 사용하는 자료구조는 이미 틀리기 때문입니다.

커널의 EXPORT_SYMBOL_GPL() 에 어떤 견해를 가지고 계신지 모르지만,
module init 에 GPL을 걸 것이 아니라면 저 매크로만으로도 충분히 날카롭습니다.
이 날카로움 때문인지 몰라도,
커널의 메인테이너들은 GPL 인척 하면서 뒤로 호박씨까는 경우를 오히려 더 신경쓰는 것 같던데요.
예를 들자면 모종의 펌웨어를 읽어들인다던가 모종의 라이브러리와 링크한다던가 하는 경우.

cwryu의 이미지

다시 말씀드리지만, 허용되느냐 아니냐의 문제이지 허용하는 게 좋냐 나쁘냐 논란할 필요가 없습니다.

Q: "리눅스를 탑재한 스마트폰, 리눅스를 탑재한 pmp류의 제품들은 모두 불법인가?"
A: 모두는 아니고 "커널 모듈을 숨기고 있는" 많은 제품는 GPL 위반으로 판단되거나 상당히 의심됩니다. (하지만 저작권 위반은 친고죄이므로.. 커널 저작권자들이 직접 혹은 법적인 권리대행을 통해야 고발이 가능합니다 :-)

Q: SD 카드 지원은?
A: 예전에 자우루스에 들어갔던 비공개 SD 드라이버같은 경우 불법일 수 있습니다. (최근의 커널에는 SD 지원 기능이 들어가 있지만.. 그건 어떻게 가능한지 모르겠군요.)

"...수 있다", "...의심된다"라고 명확하게 불법이다 아니다 이야기하지 못하는 건 GPL에 "reasonably independent and separate work"라고 충분히 독립적이고 별도로 떨어뜨려 생각할 수 있으면 해당 조항의 지배를 받지 않는다라고 명시되어 있고, 해당 드라이버가 충분히 독립적으로 작성되었을 경우에는 합법적으로 볼 수도 있기 때문입니다. 현재 nvidia/ati 드라이버나 다른 시스템에서 포팅한 일부 비공개 드라이버는 그렇게 애매한 상황에 놓여있습니다. 앞서 말씀드린 애매한 상황이라는 건 이렇게 독립적인 작업으로 불 수 있느냐 그걸 말씀드리는 거구요.

그런데 과연 그 "리눅스 키보드 보안" 모듈이 리눅스와 독립적이며 별도의 작업이라고 말할 수 있을까요?

커널 모듈이 일단 GPL이 된다는 건 제 의견이 아니라 많은 커널 개발자들의 의견입니다.

bushi의 이미지

"reasonably independent and separate work" 가 아닌 것 중에 EXPORT_SYMBOL_GPL() 을 피해가는 것이 있을 수 있다는 말에는 전혀 동의 못하겠습니다.

EXPORT_SYMBOL_GPL() 은 상당히 사려깊게, 아주 주도면밀하게 사용되어 있습니다.
GPL 이 아닌 것들은 다 죽어라라는 식의 강제는 적어도 아닙니다.

예로 든 SD메모리 카드 드라이버에서는 printk() 를 제외하면 block device, scheduler(task=work) 에 대한 커널 설비만 사용해도 충분하겠습니다. 이것들은 2.4 에서 2.6 으로 넘어오면서 전면개수를 받은 것들이죠.
그런데도 EXPORT_SYMBOL_GPL() 로 바뀌진 않았습니다.

예로 든 dualport ram 도 사용해봐야 커널의 interrupt 관련 설비외엔 없습니다.
조금 더 user friendly 하게 작성하기 위해 tty 에뮬레이션으로 작성됐다고 가정하죠.
2.6 으로 올라오면서 tty 설비 중 일부가 GPL 로 보호되기 시작했습니다.
기존의 것을 GPL 로 전환한 것이 아니라, 예전에 사용되던 함수들을 모아서 capsule한 새로운 함수를 만들고 그 함수를 GPL 로 보호하고 있습니다.
GPL 함수를 사용하면 코드가 깔끔해집니다. 하지만 2.4 커널처럼 분리된 함수를 너저분하게 각각 호출해도 수행결과는 같습니다.

2.6 의 비교적 최근커널부턴 예고됐던대로 devfs 가 빠졌습니다. 저자의 코딩스타일이 linux indent 가 아니어서라는 우스개소리도 있지만 각종 removable 장치에 대해 지원이 충분하지 못하다는 현장의 아우성이 반영된거죠.
어쨌든 대안으로 제시된 helper udev 는 GNU 입니다. 이와 관련된 커널 설비들은 대부분 GPL 로 보호되어 있습니다.
udev 를 아예 사용하지 못하게 하는 수준이 아니라 udev 의 장점을 전혀 활용하지 못하도록 보호되어 있습니다.

"reasonably independent and separate work" 에 대해 각 코드 또는 프레임웍 저자들은 이미 분명하게 선을 긋고 있습니다.

또 다시 반복될까 사족 한마디 붙이겠습니다.
이쯤했으면 "좋다""나쁘다" 를 얘기 하는게 아니라,
실제로 "허가""불허" 에 대해 어떤식으로 어느만큼을 할지 저작권자들이 이미 코드로 충분히 말한다는 것을 설명드림을 파악하셨으리라 믿습니다.
다시 말씀드리지만 EXPORT_SYMBOL_GPL() 은 충분히 날카로우며, 그만큼 사려깊고 신중하게 사용되고 있습니다.
문제는 마음먹고 GPL 을 위반하는 경우와 GPL 인척하면서 실제로 그렇지 않은 경우죠.

아주 영세한 소규모 업체가 아니라면,
적어도 "리눅스를 탑재" 했다고 광고하는 제품들이 정면으로 GPL 을 위반하고 있을 가능성은 희박합니다.
모든 비용을 고려했을 때,
새로운 프레임웍을 만들고 설비를 추가하는 편이 꼼수를 사용하는 것보다 훨씬 싸게 먹힙니다.
하지만, 말씀하신대로 desktop 분야에선 상황이 좀 다르긴 합니다.

개인적으로는 init_module 에 GPL 을 걸기를 희망합니다.
h/w 벤더, 각종 포럼들로 부터 외면을 받는 OS 가 될지라도.
용역받는 코더 입장에선 불편하기만 합니다. 여기가서 설명하고 저기가서 설명하고, 했던 말 또 하고.

잠깐 샛길,
nvidia 나 vmware 에서 사용하는 각 커널모듈들의 소스가 비록 GPL 은 아닐지라도 소스 공개는 된 것으로 알고 있는데... 오해를 했나보네요. 라이브러리 링크나 펌웨어로딩같은 편법을 사용하나보죠 ?

ganadist의 이미지

소스 공개는 커널과의 인터페이스 부분 (보통 glue라고 하나요?)만 되어 있습니다.

그리고 glue부분과 라이브러리를 링크해서 커널 모듈을 만들어 냅니다.

라이브러리는 사악하게도 심볼들을 위조해놓아서 안에서 무슨짓을 하는지 추측조차 하기 힘들게 해놓았습니다.

$ nm nv-kernel.o  |more
00000000 R __module_license
00000994 d _nv000000rm
00174224 t _nv000001rm
00174404 t _nv000002rm
00174040 t _nv000003rm
00078828 t _nv000004rm
00078698 t _nv000005rm
....

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

bushi의 이미지

(thank you, Mr. Cha)

이런 방식은, 제가 알기론 GPL 이 아닌데요.
glue 코드내에서 커널의 어떤 설비를 사용하는지 몰라도 GPL 은 절대 안됩니다.
논란의 여지도 없고 의심의 여지도 없네요.
GPL 인척하며 설비를 맘껏 사용하고, 뒷구멍으로 호박씨까는 대표적인 부류이고,
이런 것들은 GPL 이 아니라고 일찌감치 정리가 된 것 아니었던가요 ?
심지어 MS windows 의 드라이버를 리눅스에서 사용하게 해주는 드라이버조차도
소스가 없는 뭔가를 로드한다는 이유로 GPL 이 아닌 것으로 찍혔는데.

키보드 보안 커널 모드 모듈도 심볼이름을 바꿉니다. 사악하죠.
뭔가 도움이 되리란 생각은 없고, 재미있으니까 했습니다. ;)
덕분에.. 릴리즈 용으로 컴파일 해놓고 로그를 보려면 거의 죽음입니다. :(

cwryu의 이미지

결국 EXPORT_SYMBOL_GPL()로 GPL여부를 (separate work) 충분히 구분할 수 있다고 판단하시는 거군요.

하지만 그렇지 않습니다. 그러면 "별도의 작업이냐, 아니냐를 뭘로 판단하느냐?" 사용하는 심볼이 하나의 기준이 될 수 있겠고 그걸 조금이라도 명확하게 하기 위해 만든 게 EXPORT_SYMBOL_GPL()입니다. 하지만 그걸 안 쓰면 명백하게 derived work가 아니냐? 그건 아니라는 거죠. 개별적으로 판단할 사항이고 전문 변호사와 상의할 일입니다. :> 하지만 제가 보기에 위에서 리눅스 키보드 보안을 설명하신 내용은 전혀 separate work로 보이지 않습니다.

EXPORT_SYMBOL_GPL()과 바이너리 모듈의 라이센스, 이 문제에 대해서는 예전부터 수많은 논란이 있었습니다만 결론은 derived work냐 아니냐의 문제이지 심볼을 쓰고 안 쓰고가 아니었습니다. 몇가지 인용만 해 보지요.

http://lkml.org/lkml/2003/12/4/84

It still doesn't make the gray area go away, but it limits it a bit ("if you need this export, you're clearly doing something that requires the GPL").

http://www.linuxdevices.com/articles/AT5041108431.html

Similary, I consider anything that has intimate knowledge about kernel internals to be a derived work.

What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-containted [SIC] that doesn't really have any impact on the rest of the kernel...

http://kerneltrap.org/node/3148

"The only thing with legal implications is the "derivative work" argument. The EXPORT_SYMBOL_GPL is only a legal "hint": if you need a symbol exported only to GPL modules then likely your kernel module has to be GPL'd too because likely the "derivative work" argument would apply to your kernel module"

http://www.kroah.com/log/linux/ols_2006_keynote.html

That's it, it is very simple. I've had the misfortune of talking to a lot of different IP lawyers over the years about this topic, and every one that I've talked to all agree that there is no way that anyone can create a Linux kernel module, today, that can be closed source. It just violates the GPL due to fun things like derivative works and linking and other stuff. Again, it's very simple.

원글에 쓰신 것처럼 국정원의 소스 비공개 원칙때문에 -> GPL 불가 -> EXPORT_SYMBOL_GPL() 사용을 하지 않고 제작하는 방향으로 진행을 하셨지만 GPL을 피해갈 수는 없다고 보입니다. 과연 그만큼 독립적으로 개발되었고 커널 내부 구조와는 별 관계없이 동작한다고 볼 수 있을까요?

익명사용자의 이미지

쌩뚱맞은 소리일 수도 있습니다만...

현재 한국 법원은 GPL(의 강제력)을 인정하지 않습니다.
만약 소송 당사자 중 한 쪽이 국가기관이 된다면 그 날로 이 땅의 GPL은 최후를 맞이할 수도 있겠다 싶네요.

본질과 관련없는 무의미한 논쟁이 되어가는 것 같습니다...
굳이 GPL에 관해 이야기하고 싶으시다면 GPL 위반이 아니라, 그 이전에 당사자인 커널 개발자(이 경우 링크된 부분의 개발자가 되려나요)가 소를 제기할 가능성에 대해서 먼저 말을 꺼내봐야 할 것 같네요.

cwryu의 이미지

이게 진짜 무의미한 이야기입니다. 그러면 기소 안 되게 증거 안 남기고, 증거 남더라도 재판에서 이길 수 있는 화려한 변호인을 갖췄다면 세상 범죄 다 저질러도 되겠군요.

오히려 지금까지 GPL 위반 논란은 대상자가 큰 기업일 수록 더 컸습니다. 소송까지 갈 필요도 없었죠. 큰 조직일 수록 법적인 문제는 더 철저히 합니다.

익명사용자의 이미지

국내 법원에서 GPL을 근본적으로 인정하지 않은 판례를 냈다는 말을 못읽으셨나보군요.
FSF도 안타깝지만 속수무책이었는데 cwryu님은 어디에 믿는 구석이 있어서 그렇게 단정하시는지 궁금하네요.

cwryu의 이미지

엘림넷/하이온넷 판결은 재판부가 GPL 내용은 전혀 고려하지 않은 채, 라이센스 규칙과 영업비밀 여부를 별개로 (잘못) 판단하고 내린 판결이었습니다. GPL 사안을 아예 쳐다보지도 않은 게 분명한 오판이라고 생각하지만, 근본적으로 인정하지 않는다 그런 이야기는 판결문에 없었고 이 라이센스 규칙이 이 사안과 관계없다라고만 되어있습니다. 다시 판결문을 읽어보시기 바랍니다.

sephiron의 이미지

GPL은 저작권자가 자신의 저작권 행사에 관한 사항을 기술해 놓은 것입니다. 일종의 약관이라 할 수 있겠죠. 따라서 GPL이 강제성이 없을리가 없겠죠.
----
Forensic Computing On Linux

아직 멀었어

bushi의 이미지

쓸 데 없는 토론을 한 것 같습니다. 제가 전혀 다른 곳을 쳐다보고 있었습니다.

저 처럼 처음 접하는 분들을 위해 "기술" 과 "법" 의 관점에서만 해석된
EXPORT_SYMBOL() 과 EXPORT_SYMBOL_GPL() 을 적습니다.
위 둘은 접근 통로를 제한하는 "기술" 일 뿐,
license 에 대한 어떤 차이도 없습니다. 이름을 보고 오해를 하면 안됩니다.
리눅스 커널은 GPL 이므로 모든 symbol 은 GPL 입니다.
아울러 커널 헤더파일에 정의된 모든 것들도 GPL 입니다.
따라서 법적으로 따지면 모든 binary only module 은 GPL 위반입니다.

아래 내용들은 위의 법적인 해석과 일부 모순이 있지만,
저작권자인 linus 가 주장하는 내용을 담습니다.

EXPORT_SYMBOL_GPL() 을 도대체 뭐하러 정의해서 혼란에 빠지게 만드냐는 질문엔
어느 누구도 답변을 달지 않습니다.
linus 는 GPL-only 라는 점을 강조하기 위해서 정의했고,
새로 제작되는 인터페이스에 한해서만 저작권자들이 적당히 사용할 일이라고 말했습니다.

"separated" 와 "independent" 에 대한 구체적인 예를 linus 가 제시했군요.
정확히 말하면 "derived work" 에 대한 정의입니다.
linus 가 인정한 단 하나의 예는 AFS 입니다.
그것이 리눅스의 내부 구조(VFS)와 얼마만큼 밀착되어 있는지에 상관없이
리눅스가 존재하기 전부터 있던 코드를 리눅스로 포팅한 것이므로 완전히 독립적이라고 선언했습니다.

linus 스스로 "separated" 와 "independent" 를 "derived" 라는 말로 설명하므로
"독립적", "커널 내부 구조 이용" 에 대한 정의는 AFS 의 예로써 충분하겠습니다.

nvidia 가 제공하는 binary only module 등에 대한 linus 의 comment 는 "의심간다" 입니다.
그것들의 내부적으로 어떤 코드가 어떻게 쓰이는지 알 수 없으나,
어쨌건간에 기존에 없었던 것들이고,
AFS 의 예처럼 커널의 내부 구조와 얼마나 밀착되어 있는지와는 별개로,
모듈을 동작시키기 위한 주요 지식은 nvidia 의 고유한 것이므로 "독립성" 은 인정하기 때문에 수년째 저작권자로써 두고보는 것 같습니다.
다른 OS 용으로 작성된 것을 리눅스 용으로 옮긴 것뿐이다라는 nvidia 의 주장을 무시할 근거가 별로...

SUSE 가 제공하는 또는 제공했던 수십 개의 binary only module 이나,
vmware 에서 사용되는 수 개의 binary only module 들에 대해서도,
이런 류의 논쟁이 벌어질 때 마다 언급되는 것들이지만 이렇다 할 제재가 없습니다.
한결같이 리눅스용으로 옮긴 것 뿐이라다는 주장을 하겠지요.

키보드 보안 커널 드라이버가 과연 얼마만큼 derived 냐라고 자아비판을 해보면,
character device 를 다루기 위한 설비,
input 검사를 위한 input handler 사용,
이 정도가 리눅스 커널용으로 작성되었고,
나머지는 특허분쟁이 염려되는 상황이라 발주처에서 준 소스들을 리눅스 커널에 맞게 번역하는 수준이고, scrambler/filter, crypto 쪽은 아예 #include "*.c" 형식으로 되어 있습니다. ... 리눅스용으로 옮긴 것 뿐이군요.
os 의존적으로 번역된것이... mutex, interrupt, malloc, free, printf, schedule, spinlock, thread, timer, 더 이상은 없는 것 같습니다.

이 정도가 derived work 에 속한다면,
국정원을 설득하던가 (행여나), 프로젝트drop 하던가 선택을 해야된다고 보고를 해야겠습니다.

cwryu의 이미지

네, AFS의 경우에는 사실 리눅스 VFS나 유닉스에 있는 파일시스템 레이어나 별다를게 없기 때문에 단순 포팅일 것이다라고 인정한 것입니다.

어느정도가 derived냐.. 이건 사실 애매한 문제이고 정답이 없으므로 법률 전문가에게 의뢰를 하셔야 할 듯 하구요. (리누스조차도 AFS에 대해 자기 생각이 오케이라고 말했을 뿐 명백하게 선언은 하지 못했습니다.) 제가 independent하지 않다고 생각한 이유는, 원글에서 커널 드라이버가 어떻게 동작하는지는 설명하지 않으셨지만 리눅스의 키보드 입력 경로를 꽤 자세히 설명하셨고 위에서 설명하신 각 경로의 스니핑 통로를 차단하려면 내부 구조에 상당히 영향을 끼치는 역할을 할 거라고 생각했기 때문입니다.

그런데 이 모듈이 단순히 input handler / chardev일 뿐이라면, (위에서 설명하신 스니핑중에 몇가지에는 어차피 필요한) 루트 권한만 있으면 얼마든지 스니핑할 수 있는 방법이 많겠네요? 이런 이야기를 하면 "필요"에 대한 이야기가 되나요? :-)

파도의 이미지

글 잘 읽었습니다. 그래도 희망적인 글 같습니다.

윈도우즈 같은 경우에는 커널이 변조 되었는지, 악성모듈이 설치되었는지를 감시해주는 상용툴(안티바이러스 같은)이 있어서, 기존의 키보드 보안 프로그램들이 어느정도 효력이 있다고 생각됩니다만, 리눅스에서는 커널이 컴파일 하는 사람마다 달라 변조되었는지 확인할 방법을 찾기 힘들다는 문제점 등이 있어서, 기존의 윈도우즈용 키보드보안 프로그램의 논리로는 어렵다고 생각됩니다.
인증된(?) 리눅스 커널을 사용한다면 가능성이 있을까요?
소스 공개 불가는 좀 암담한 부분이군요.
보안 모듈과 그 보안 모듈을 필요로 하는 응용프로그램간의 공개키/비밀키 방식 같은 것을 생각했었는데, 그런건 아닌 듯 하네요.

위에서 언급한 스니핑 방지를 위한 특허는 독보적인지 아닌지의 문제를 떠나서, 약간 비켜가는 방식으로 피할 수 있을 듯합니다.
필터를 사용하는 방식이 아닌 재조합 같은 다른 방식을 사용한다던가 하는 식으로 말입니다.

계속 수고해 주셔서 리눅스에서도 하루 빨리 금융거래를 할 수 있도록 해 주시면 감사하겠습니다.^^

/** 시그너쳐의 시작 ******************************************/
/* _______________________ AHAHHAH ! _______________________ */
/******************************************** 시그너쳐의 끝 **/

--------Signature--------
시스니쳐 생각 중..

bushi의 이미지

날카로우시네요.

커널변조를 알아낼 수 있는 방법을 찾다가 못 찾았습니다.
기껏 생각해봐야 배포본별로 패키지 매니저에 의해 설치된 커널만을 사용한다고 가정한다면
적어도 부팅용도로 사용되는 커널 파일이 오염되었는지 정도는 파악된다는 정도고.
실제 운용중인 커널에 대한 오염은 도무지 알아낼 방법이 없더군요.
좋은 생각 있으신 분은 흔적 좀...

bwahn의 이미지

커널을 접한지 몇년 안되지만, 상당한 매력을 발견할 만 한것은 못 찾고 있습니다.

오히려, 하면 할 수록 애매하거나, 문제가 되거나등등의 부작용만 생기고 있습니다.

키보드 보안도 사실 커널 모듈 이기때문에

상당한 문제들을 내포하고 있는것 같습니다.

Windows 에서의 커널 후킹과 linux에서의 커널 후킹은 사실 동일하다고 생각합니다.

어떤 OS든 마찬가지겠지요.

방법들만 다를뿐...

초보자인 저로써는 다음 생애에 태어난다면,

이런 말도 안되는 일을 하면서 시간을 허비하고 싶지 않다고 생각합니다.

그냥 답답한 소견이였습니다.

bushi의 이미지

키보드 보안이 상당한 문제를 내포하고 있는 것은 맞습니다.
가장 큰 원인은 키보드만 보안한다는 데 있습니다.

앞선 글에 밝혔지만,
리눅스 시스템 보안이 완벽하다면 키보드 보안은 필요가 없고,
리눅스 시스템 보안에 조그만 헛점이라도 있다면 키보드 보안은 소용이 없습니다.
키보드 보안을 위해 뭔가를 하는 것이 시스템 보안에 구멍을 만들 여지가 있다면 하지 않는 것이 좋지요.

리눅스 쪽은... 사실 복잡하고 불안한 커널후킹을 할 바에야 커널을 통째로 갈아버리는 편을 추천합니다.
터미널 후킹은 예외로 하고요.

alee의 이미지

1. 커널 모드 모듈, 유저 모드 모듈의 소스가 공개되면 안된다.

이 조항 때문에 문제가 되고 있는 것 같은데, 제 생각에 둘 중 한 쪽 소스는 공개해도 보안을 유지할 수
있다고 생각합니다. 예를 들어 PGP나 GnuPG의 경우 이미 알고리듬이 다 공개되어 있지만, 키만 잘
간수하면 보안을 유지한 채 메시지를 주고받을 수 있습니다. 이건 꼭 PGP나 GnuPG에 국한된 얘기가
아니고, RSA 같은 공개 키 암호화 알고리듬의 경우 다 그렇죠. 비슷하게 공개 키 암호화 알고리듬을
사용하면, 커널 모듈은 소스를 공개하고 유저 모듈만 비공개로 만들어서 보안을 유지할 수 있지 않을까요?

즉,
1. 커널 모듈은 공개 키 암호화 알고리듬으로 정보를 암호화 해서 유저 모듈로 보내주는 역할을 하도록
만듭니다.
2. 복호화 키는 유저 모듈 안에 감춰져 있어서 유저 모듈의 소스가 없이는 알아내기 어렵도록 만듭니다.
이런 식이면 커널 모듈을 GPL로 만들어도 문제가 없지 않을까요? 만약 이 방법에 문제가 없다면 위의
조항을 커널 모듈이나 유저 모듈 둘 중 어느 한쪽 소스만 공개하지 않아도 되는 쪽으로 정책을 바꾸도록
국정원을 설득해 보는 것이 어떨까요?

적고 보니 이미 앞에서 파도님이 비슷한 이야기를 하셨네요. :)

bushi의 이미지

저기 위에 정부(국정원)의 지침에 대한 글을 적었습니다만,
그들은 책임회피에 모든 촛점이 맞춰져 있습니다.
word 나 excel 로 프로젝트를 끝내는 사람들입니다.
private key... 유저모듈에 탑재.... key가 어느 고정된 장소에 노출되어 있으면 안된다는 작업지침도 있습니다.
꼭, 국정원의 지침이나 발주처의 요구사항이 아니더라도,
우선 저부터가 제게 책임이 돌아도는 상황을 피하기위해서라도 이런 식의 구현은 배제했습니다.
소스의 공개여부는 둘째고 개발한 당사자라 하더라도 해킹이 불가능해야 합니다.

alee의 이미지

윗동네 사람들의 책임 회피에 대해서는 할 말이 없습니다만,
key에 대한 부분은 금방 해결이 가능합니다. 키를 소스에 아예 포함시키는 대신에 그때그때
유저모듈에서 키쌍을 생성해서 공개키를 커널모듈로 보내주도록 하면 됩니다.

그런데 개발한 당사자도 해킹이 불가능하다면 소스를 공개해도 상관 없는거 아닌가요?
역시 책임 회피 때문이겠군요.

bushi의 이미지

은행권이 아니라 일반적인 온라인 게임에서 사용하는 키보드 보안도 있습니다.

어줍잖은 kid 들께서 사용하는 메시지 후킹에 의한 키로거를 방지하는 목적이라 보입니다.
임의의 키 이벤트 메시지를 발생시키는 scrambler 와 이에 대한 filter 의 조합일 것으로 추정되며,
아마도 맨 첫글에서 말씀드린 "scrambler 와 filter 에 관한 특허" 를 침해하지 않나하는 의심을 합니다.
어쨌거나... 구현하려면 제대로 구현하든가 할것이지 애매하게 만들어서 종종 짜증날 때가 많습니다.

이런 류의 보안은 그렇게 시스템 의존적인 것도 아니므로 리눅스 진영에서도 충분히 가능하다 생각합니다.
X 도 결국은 이벤트 메시지로 키코드를 보내는데 말이죠.
문제는 뭐.. 항상 그렇듯.. 왠지 거부감이 느껴지는 "설치" 입니다.

잠깐 샛길로 빠져서,

제가 애용하는 M모 온라인게임에선, 예전에 마우스 보안까지 했습니다.
보안이라고까지 부를 것은 없지만...
아이템을 생산해 내는 게임 인터페이스에서
생산품의 품질은 마우스로 클릭한 점의 좌표 정확도에 따라 달라지는 시스템이었습니다.

위젯 표면에 표시되었다 사라진 6개 점들의 위치를 뇌리에 기억했다가
제한된 시간 내에 정확하게 그 위치를 마우스로 클릭하라는 것은,
귀차니즘을 최대의 적으로 여기는 프로그래머를 자극시키기에 충분하지 않습니까 ?

짐작하시듯 다른 프로그램을 이용해서 이미지 프로세싱 후에
찍어야 할 점의 정확한 좌표로 마우스 이벤트를 날리는 것은 일도 아니죠.

게임사 측에서 어떻게 방어를 했냐먼...
해당 인터페이스(위젯)에선 상대좌표로 날아오는 마우스 이벤트만 받아들이고,
절대좌표로 날아오는 마우스 이벤트는 무시하도록 한겁니다.
여기에 한 술 더떠서 정상적인 마우스 이벤트를 받으면
위젯내 임의의 절대좌표로 이동하는 마우스 이벤트를 만들어서 뿌립니다.

역시 짐작하시듯 위젯 외부로 일단 절대좌표 이동 후,
위젯 내부의 점까지 상대좌표로 조금씩 이동하면 뚫을 수 있습니다.
결국은 게임사에서 이 시스템을 포기하고 아이템의 품질을 다른 방식으로 결정하도록 바꿨습니다.

이걸 뚫을 때 가장 고생한 것은...
MS windows 에서 제공하는 마우스 가속기능을 끄는 방법을 찾는 것과
새로 출시된 delphi 7 의 IDE 에 적응하는 것이었습니다.

더 샛길로 빠져보자면,
그 M모 게임 프로그램은 GPL 라이브러리를 '내장'하고 있답니다.
압축 관련된 라이브러리인데 홈페이지를 찾아가 보니 그렇더군요. 개인이 아니고 회사였습니다.
프로그램 본체에 박혀있었는지 로딩하는 DLL 중에 박혀있었는지는 기억이 잘 안납니다.
불순하게도... 크래킹을 위해 이것저것 해보다 발견한 것이고,
그놈의 게임이 모든 것을 서버와의 통신에 의해 처리한다는 것을 알게된 후 호기심을 잃는 바람에...

ganadist의 이미지

잠시 이야기를 딴데로 새도록 하겠습니다만, 언급이 필요할 것 같습니다.

저도 이쪽 방면에 대해서는 잘 알지 못하지만, 여기저기 주워 들은 것을 정리하면 다음과 같습니다.

윈도에서 인터넷 뱅킹을 할 때 무식하게 이것저것 많이 까는데, 그중 키보드 보안 모듈 프로그램이 보호하는 것은 딱 2가지 종류의 키보드 타입이라고 합니다.

PS/2와 USB키보드이죠.

그리고 그 외의 입력장치, 또는 입력방식을 사용하는 것은 보안모듈의 보호대상이 아니라고 합니다.

ex:
Windows XP에 기본 내장되어 있는 필기인식 입력, 화면 키보드 입력
RDP같은 원격 제어로 들어오는 입력이벤트
Bluetooth같은 새로운 연결방식을 이용한 입력

키보드 입력이 힘든 장애인이라면 화면 키보드같은 보조입력 프로그램으로 인터넷 뱅킹을 해야 합니다. 하지만 키보드 보안 프로그램의 보호대상이 되지 않습니다.

그리고 비싼 돈들여서 블루투스 고급 키보드를 질렀는데.. 인터넷 뱅킹을 안심하고 쓰려면 싸구려 usb키보드를 다시 연결해서 인터넷 뱅킹을 해야 할지도 모릅니다 ;;

극단적인 예를 들었습니다만, 충분히 가능한 시나리오이고, 실제로 위의 상황을 맏닿는 분들도 많을 것입니다.

뭐.. 이 이야기의 결론은 현재 현재 윈도에서 사용하는 키보드 보안이라는 것도 만사 OK라는 것이 아니며, 자주 쓰이는 일부 testcase에 대해서 어느정도 선에서만 보호를 해준다는 것입니다.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

익명사용자의 이미지

가상 키보드를 얘기하시는 분들이 계신데, 이게 위험한 이유가, 뒤에서 누가 모니터 들여다보면 끝장입니다. 집에서 혼자 인터넷 뱅킹을 하면 모를까 직장, 학교, PC방 등의 외부인에게 노출된 장소에서 이용하면 매우 위험하죠. 안전한 패스워드 시스템을 연구하면서 이걸 생각해본 적이 있었는데, 이거 키보드보다 더 위험하더군요. 사실 키보드를 통한 입력도 소형 캠코더로 찍으면 끝장이긴 한데... 그래도 육안으로는 고속으로 타자하는 패스워드를 확인하긴 힘들죠 ㅋ

이 문제와 관련된 최선의 해결책은 소형 계산기 크기의 패스워드 제너레이터를 사용자들에게 나눠주는 것 뿐. 로그인할 때마다 은행에서 보내주는 매번 달라지는 확인용 key를 받아서 제너레이터를 통해서 임시 패스워드를 생성한 후, 그걸 다시 은행으로 보내는 거죠. 이때 제너레이터는 반드시 매번 사용자에게 사용자의 패스워드를 입력받아야 합니다. 미리 저장해놨다가 자동으로 생성해주는 경우에는, 제너레이터 잃어버리면 끝장이죠.

패스워드 제너레이터는 충돌이 드문 일방통행 함수 정도만 돌아갈 수 있으면 되는데, md5 정도면 비교적 저가의 칩으로 쉽게 구현가능하지 않을까 싶군요. 기왕이면 RSA가 돌아가면 좋겠지만...

esrevinu의 이미지

누군가 뒤에서 보고 있다면 뭔가 이상하지 않나요? 비밀번호를 입력하는 상황이 아니라도 말이죠. 인터넷뱅킹 뿐만 아니라 다른 일 할 때라도 누군가 지켜보고 있다면 이상할 텐데. 누군가가 뒤에서 보고 있는데 인터넷뱅킹을 떳떳이 한다면 대담한 사람일 겁니다.
PC방 처럼 공용으로 쓰는 컴퓨터에서 인터넷뱅킹을 자제하는 것은 상식일테고요.

송효진의 이미지

chkrootkit, rkhunter 등 루트킷 찾아주는 프로그램에서 안걸릴정도면,
키보드보안이 되었다고 인정해주자 라는 제안은 현실성이 어느정도일까요?

emerge money

eccebae의 이미지

근데 과연 국정원이 인증하는 키보드 보안 프로그램이 진정한 보안 프로그램일지...

"상황이 이럼에도 불구하고, 정부(국정원)에서는 MS windows 적인 개념을 탑재하고 "키보드보안"에 대한 몇가지 요구조건을 내 걸었습니다.
이 요구조건의 목적은 "기술적으로 키보드를 보안" 하겠다는 것이 아니라 "사용자를 안심" 시키는 것에 목적이 있다고 보여집니다."

이 부분이... 뭐... 결국 보안은 시지프의 바위라는...

P.S. 커억. 기술적 고견을 듣고자 만드신 글타래에...
패배주의적 발언을 댓글로 올려 놓았습니다.
이런... 댓글은 삭제할 수도 없고... 죄송합니다.

dynamism2002의 이미지

http://dynasystem.mireene.com. (<-제가 창업한 리눅스 데스크탑 회사입니다)

저는 윈도우 개발 경험 밖에 없어서 위에 열거된 기술적인 설명을 솔직히 이해는 못 했습니다만...

인터넷 뱅킹에 관련된 부분만 별도의 하드웨어로 분리하는 것은 어떨까 하는 생각이 들었습니다. 일본에서 살면서 보니까 소니에서 만든 전자화폐 edy의 경우 PC에 usb로 연결할 수 있는 edy리더기를 한 대에 얼마씩 받고 고객에게 팔더군요.

그게 있으면 꼭 편의점에 가서 충전할 필요없이 집에서도 전자화폐 충전이 가능합니다. 지금 자기 edy에 돈이 얼마 들어있나 확인도 되고요...

자기 집에서 국민은행 카드리더기를 usb로 연결해서 평상시에 ATM기에 넣던 바로 그 국민은행 카드를 넣지 않으면 절대로 인터넷 뱅킹이 안 되게 하면...SEED고 키보드 보안 프로그램 설치고 다 필요없는 거 아닌지....요즘엔 은행카드들도 다 바뀌어서 안에 IC칩 들어가지 않나요?

시스템 후로그래밍에 대한 전문지식이 전혀 없는 저의 발상에 황당한 부분이 있을지도 모르지만요...소프트웨어적으로 해결이 어려운 부분은 물리적으로 해결하면 되지 않나 하는 생각입니다. 예를 들면 정말로 중요한 국가기관에서는 신원을 확인할 때 홍채검사를 하듯이...인터넷 뱅킹처럼 절대로 해킹당해서는 안 되는 정말 중요한 부분에는 물리적인 해결책이 필요하지 않나 생각합니다.

ssmin의 이미지

부시님 이메일을 알고싶어요 ^^

문의드리고 싶은게 많은데요 연락처나 이메일이 없네요

mikado22001@yahoo.co.kr

GG

pinebud의 이미지

심심하니까 적어봅니다 -_-;
1, 2 : 어차피 유저모드 모듈이 디코딩을 해야한다면 키보드 드라이버를 유저모드로 옮겨도 되겠군요. 유저모드 모듈이란 브라우저 플러그인인가요? 커널 모드 드라이버에서는 레지스터 혹은 포트 엑세스, 인터럽트 전달 경로 등만을 제공하구요. 어차피 커널소스 건드려서 하드웨어 공격하려고 든다면 막을 수 없을 것 같구요.
3. 국정원에 역으로 개인방화벽 프로젝트를 신청해야될 것 같습니다. 오픈소소로 개발해서 뿌리고 인터넷 뱅킹도 한다고 하면 국정원에서도 좋아하지 않을까요? 나름 광도 팔고.. 방화벽 기능이야 옵션만 켜면되니 설정 GUI만 그럴듯하게 만들면 될 것 같습니다. 물론 포트 엑세스때 팝업을 띄우려면 커널 방화벽 기능에도 손을 대야할지도 모르겠네요 -_-;

A rose is a rose is a rose..