키보드 보안

키보드 보안

2008. 05. 29

순천향대학교 정보보호학과 임강빈 교수

2

하드웨어 ( 시스템 ) 보안 기술

• 보편적 해석 ( 보안 하드웨어 )- 보안 장비 개발 기술 = 시스템 설계 + 보안 소프트웨어 기술- 보안 알고리즘의 하드웨어 구현 기술 = 칩 설계 기술 - 사이드 채널 공격 기술 = 암호 알고리즘에 제한적

• 제한적 해석 - 보안 문제에 안전한 하드웨어 설계 - 보안에 불안한 하드웨어 은닉을 위한 소프트웨어 설계

• 요구사항- 이벤트 노출 방지 인터페이스 사용- 휘발성 인터페이스 사용

• 우리가 늘 사용하는 하드웨어인 IBM-PC 는 ?

3

접근권한 관리 하드웨어

• 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 단계 ) - 사용자 드라이버를 커널레벨에서 분리

4

PS/2 키보드 인터페이스

5

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

포트 이름 읽기 쓰기

컨트롤 (0x64) 상태레지스터 제어코드

데이터 (0x60)스캔코드제어응답명령응답

제어인자명령코드명령인자

6

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

7

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

8

키보드컨트롤러 제어코드

9

키보드컨트롤러 오퍼레이션

• 제어코드 , 제어인자 , 제어응답- 호스트는 인터럽트 루틴으로 처리- 호스트의 지속적 다이렉트 폴링은

오버헤드 과다

// 호스트 루틴 구성 요소 (i8042prt.sys)

while (IBF) ;Write DATA @ 0x60

while (IBF) ; Write CONTROL @ 0x64 ;

while (IBF) ; Write PARAM @ 0x60 ;

while (!OBF) ; Read RETURN @ 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) { 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

C/D 1, IBF 1

0x64

C/D 0, IBF 1

INT0x60

10

• 인터럽트 처리 구조로서 제어권 탈취 용이

하위 소프트웨어 구조

11

• 키보드 인터럽트 처리기의 대체

스니퍼 또는 보안프로그램의 접근법

12

기존 키보드보안 환경

• 현황- 인터럽트 처리기를 교체하여 스캔코드 수집 - 인터럽트 처리기는 드라이버를 사용하여 스캔코드 수집

system32/drivers/i8042prt.sys(i8042dep.c) 를 이용 - 특수한 경우를 제외하고는

다이렉트 폴링을 수행하지 않는 것으로 판단 - 스니퍼의 다이렉트 폴링에는 무방비

• 문제- 보안 프로그램이 다이렉트 폴링을 수행하는 경우

스니퍼와 경쟁상태에 빠져 상호 정상적인 스캔코드 수집 실패 스니퍼의 스니핑 포기를 유도하는 것이 가능

- 보안 프로그램이 다이렉트 폴링을 수행할 경우 지나친 오버헤드를 유발하여 많은 환경에서 보안 서비스 불가

13

대응 방안 I

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

14

방안 I 의 문제점

• 상태 레지스터 C/D 비트의 하향 에지 노출• 비 휘발성 출력버퍼의 스캔코드 노출 • C/D 비트 하향 에지 은닉과 출력버퍼 비움 필요

15

대응 방안 II

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

16

방안 II 의 문제점

• 예측 가능한 응답 코드 발생• 비 논리적인 응답 코드 발생 • 예측 불가하며 스캔코드와 구별할 수 없는 코드 발생 필요

17

대응 방안 III

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

18

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

대응 방안 IV

19

방안 IV 의 동작

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

20

기타 제어코드를 이용한 방지 방안

• 인자는 없고 응답이 있는 제어코드 이용 • 대개 0xD2, 0x20 보다 불우

- 0xAA : Self Test 0x55- 0xAB : Interface Test 0x00 ~ 0x04- 0xC0 : Read Input Port 거의 고정 값- 0xD0 : Read Output Port 거의 고정 값- 0xE0 : Read Test Port 거의 고정 값

• 스니퍼가 값을 추적 가능하여 걸러낼 수 있음

21

USB 키보드의 보안

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

22

사용자 드라이버 주변의 보안 문제

• 위험성 평가- 미니 드라이버 , 필터 드라이버 등을 이용하여 스캔코드 선점- 드라이버 오브젝트 , 디바이스 오브젝트 등을 통한 정보 획득- 현재 URB(USB Request Block) 수준까지 스니핑

• USB Transfer 수준까지 공격 가능 • USB Transaction 을 관리하는 BUS 드라이버 , HC 드라이버의

상위 부분 논리적 구조에 접근

23

USB 전송 구조에서의 보안 문제

• 상위의 디바이스 오브젝트와 연결된 REQUEST 버퍼 존재 - URB 를 통하여 전달된 임시 데이터를 조작 가능

• HC 와 연결된 스케줄링 (TRANSACTION) 버퍼 존재- 타깃 디바이스의 주소 ( 엔트포인트 ) 와 연결된 버퍼- USB 타깃에 대하여 최소의 버스 전송 단위

• 각 버퍼에 대하여 스푸핑 등이 가능함 (usbd.sys, usbehci.sys 조작 )

24

USB 프로토콜에서의 보안

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

25

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

26

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

해결 과제