키보드 보안

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

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

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

PS/2 키보드 인터페이스

키보드컨트롤러 인터페이스

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

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

키보드컨트롤러제어코드

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

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

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

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

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

방안 I의 문제점 • 상태 레지스터 C/D 비트의 하향 에지노출 • 비 휘발성 출력버퍼의스캔코드 노출 • 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 보안채널 구성이 필요 • 사용자의 키보드와 서버 간의 암호화 채널

키보드 보안

키보드 보안

Presentation Transcript