키보드 보안 2008. 05. 29 순천향대학교 정보보호학과 임강빈 교수

하드웨어(시스템) 보안 기술 보편적 해석 (보안 하드웨어) 제한적 해석 요구사항 우리가 늘 사용하는 하드웨어인 IBM-PC는? 보안 장비 개발 기술 = 시스템 설계 + 보안 소프트웨어 기술 보안 알고리즘의 하드웨어 구현 기술 = 칩 설계 기술 사이드 채널 공격 기술 = 암호 알고리즘에 제한적 제한적 해석 보안 문제에 안전한 하드웨어 설계 보안에 불안한 하드웨어 은닉을 위한 소프트웨어 설계 요구사항 이벤트 노출 방지 인터페이스 사용 휘발성 인터페이스 사용 우리가 늘 사용하는 하드웨어인 IBM-PC는?

접근권한 관리 하드웨어 Pentium Processor 운영체제의 접근권한 관리 하드웨어 활용 Protected Mode 를 통한 하드웨어 기반 접근권한 관리 Segment 기반의 메모리 보호 IO Permission Map에 의한 프로세스별 I/O 보호 PL0 ~ PL3의 4단계 Privilege Levels 운영체제의 접근권한 관리 하드웨어 활용 Protected Mode 기능을 제한적으로 사용 Page 기반의 메모리 보호 (Segment 보호 특성 축소) PL0, PL3의 두 Privilege Level만을 이용 (다이렉트 폴링 문제 발생) 앞으로는 무엇을 어떻게 해야 하는가? 4단계 Privilege Levels 모두 지원 (최소 3단계) 사용자 드라이버를 커널레벨에서 분리

PS/2 키보드 인터페이스

키보드컨트롤러 인터페이스 포트 이름 읽기 쓰기 컨트롤 (0x64) 상태레지스터 제어코드 데이터 (0x60) 스캔코드 제어응답 명령응답 제어인자 명령코드 명령인자

키보드컨트롤러 상태 레지스터

키보드컨트롤러 설정 레지스터

키보드컨트롤러 제어코드

키보드컨트롤러 오퍼레이션 제어코드, 제어인자, 제어응답 호스트는 인터럽트 루틴으로 처리 호스트의 지속적 다이렉트 폴링은 오버헤드 과다 // 키보드컨트롤러 내부 프로그램 구조 for (1) { while (!IBF) ; if (C/D) { Read CONTROL @ IB ; Clear IBF ; Decode CONTROL ; Set STATE on for PARAM and/or RETURN ; } else { if (STATE is on for PARAM, RETURN) { Read PARAM @ IB ; Clear IBF ; while (OBF) ; Write RETURN @ OB ; else if (STATE is on for PARAM only) { else if (STATE is on for RETURN only) { Read DATA @ IB ; Clear IBF ; Clear STATE ; // 호스트 루틴 구성 요소 (i8042prt.sys) while (IBF) ; Write DATA @ 0x60 Write CONTROL @ 0x64 ; Write PARAM @ 0x60 ; while (!OBF) ; Read RETURN @ 0x60 INT C/D  1, IBF  1 0x64 C/D  0, IBF  1 INT 0x60

하위 소프트웨어 구조 인터럽트 처리 구조로서 제어권 탈취 용이

스니퍼 또는 보안프로그램의 접근법 키보드 인터럽트 처리기의 대체

기존 키보드보안 환경 현황 문제 인터럽트 처리기를 교체하여 스캔코드 수집 인터럽트 처리기는 드라이버를 사용하여 스캔코드 수집 system32/drivers/i8042prt.sys(i8042dep.c)를 이용 특수한 경우를 제외하고는 다이렉트 폴링을 수행하지 않는 것으로 판단 스니퍼의 다이렉트 폴링에는 무방비 문제 보안 프로그램이 다이렉트 폴링을 수행하는 경우 스니퍼와 경쟁상태에 빠져 상호 정상적인 스캔코드 수집 실패  스니퍼의 스니핑 포기를 유도하는 것이 가능 보안 프로그램이 다이렉트 폴링을 수행할 경우 지나친 오버헤드를 유발하여 많은 환경에서 보안 서비스 불가

대응 방안 I 제어코드 0xD2를 이용하여 감시 프로그램을 교란

방안 I의 문제점 상태 레지스터 C/D 비트의 하향 에지 노출 비 휘발성 출력버퍼의 스캔코드 노출

대응 방안 II 응답이 있으나 인자가 없는 제어코드 0x20을 이용하여 산발적인 시간에 설정레지스터를 읽어 내어 스니퍼를 교란

방안 II의 문제점 예측 가능한 응답 코드 발생 비 논리적인 응답 코드 발생 예측 불가하며 스캔코드와 구별할 수 없는 코드 발생 필요

대응 방안 III 인자 및 응답이 없는 단독 제어코드를 0xD2 뒤에 연결하여 사용 0xD2로 스캔코드 교란, 단독 제어코드로 C/D 비트 변화 은닉 0xA6, 0xA7, 0xA8, 0xAD, 0xAE, 0xC1, 0xC2 등이 사용 가능 효과 증대하나 큰 임계영역 설정이 필요하므로 과부하 발생

대응 방안 IV 키보드컨트롤러 내부 메모리 이용 미사용의 31바이트 메모리 존재 0x20 및 0x60 제어코드를 활용하여 접근 가능

방안 IV의 동작 준비루틴을 비 주기적으로 실행하여 임의 값 준비 교란루틴을 필요할 경우 실행하여 교란코드 생성 상대적으로 적은 오버헤드 실현

기타 제어코드를 이용한 방지 방안 인자는 없고 응답이 있는 제어코드 이용 대개 0xD2, 0x20보다 불우 0xAA : Self Test  0x55 0xAB : Interface Test  0x00 ~ 0x04 0xC0 : Read Input Port  거의 고정 값 0xD0 : Read Output Port  거의 고정 값 0xE0 : Read Test Port  거의 고정 값 스니퍼가 값을 추적 가능하여 걸러낼 수 있음

USB 키보드의 보안 현황 USB 보안 문제는 USB 키보드 보안 문제와 직결 PS/2에서와 같은 선점 경쟁에 돌입 우려 크게 세 포인트에서 보안 문제 고려 필요

사용자 드라이버 주변의 보안 문제 위험성 평가 미니 드라이버, 필터 드라이버 등을 이용하여 스캔코드 선점 드라이버 오브젝트, 디바이스 오브젝트 등을 통한 정보 획득 현재 URB(USB Request Block) 수준까지 스니핑 USB Transfer 수준까지 공격 가능 USB Transaction을 관리하는 BUS 드라이버, HC 드라이버의 상위 부분 논리적 구조에 접근

USB 전송 구조에서의 보안 문제 상위의 디바이스 오브젝트와 연결된 REQUEST 버퍼 존재 URB를 통하여 전달된 임시 데이터를 조작 가능 HC와 연결된 스케줄링(TRANSACTION) 버퍼 존재 타깃 디바이스의 주소(엔트포인트)와 연결된 버퍼 USB 타깃에 대하여 최소의 버스 전송 단위 각 버퍼에 대하여 스푸핑 등이 가능함 (usbd.sys, usbehci.sys 조작)

USB 프로토콜에서의 보안 Transaction 단위로 전송 토큰 패킷에 의하여 라우팅 프로토콜 구성의 구속성이 없음 악의적 타깃에 의하여 NAK 전송 등이 가능

USB HC 드라이버에서의 보안 문제

해결 과제 End-to-end 보안 채널 구성이 필요 사용자의 키보드와 서버 간의 암호화 채널