Transcript 슬라이드 1

키보드 보안
2008. 05. 29
순천향대학교 정보보호학과
임강빈 교수
하드웨어(시스템) 보안 기술
• 보편적 해석 (보안 하드웨어)
- 보안 장비 개발 기술 = 시스템 설계 + 보안 소프트웨어 기술
- 보안 알고리즘의 하드웨어 구현 기술 = 칩 설계 기술
- 사이드 채널 공격 기술 = 암호 알고리즘에 제한적
• 제한적 해석
- 보안 문제에 안전한 하드웨어 설계
- 보안에 불안한 하드웨어 은닉을 위한 소프트웨어 설계
• 요구사항
- 이벤트 노출 방지 인터페이스 사용
- 휘발성 인터페이스 사용
• 우리가 늘 사용하는 하드웨어인 IBM-PC는?
2
접근권한 관리 하드웨어
• 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단계)
- 사용자 드라이버를 커널레벨에서 분리
3
PS/2 키보드 인터페이스
4
키보드컨트롤러 인터페이스
포트 이름
읽기
쓰기
컨트롤 (0x64)
상태레지스터
제어코드
데이터 (0x60)
스캔코드
제어응답
명령응답
제어인자
명령코드
명령인자
5
키보드컨트롤러 상태 레지스터
6
키보드컨트롤러 설정 레지스터
7
키보드컨트롤러 제어코드
8
키보드컨트롤러 오퍼레이션
• 제어코드, 제어인자, 제어응답
// 키보드컨트롤러 내부 프로그램 구조
- 호스트는 인터럽트 루틴으로 처리
- 호스트의 지속적 다이렉트 폴링은
오버헤드 과다
// 호스트 루틴 구성 요소 (i8042prt.sys)
while (IBF) ;
Write DATA @ 0x60
0x64
C/D  1,
IBF  1
while (IBF) ;
Write CONTROL @ 0x64 ;
while (IBF) ;
Write PARAM @ 0x60 ;
while (!OBF) ;
Read RETURN @ 0x60
INT
0x60
INT
C/D  0,
IBF  1
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 ;
}
}
9
하위 소프트웨어 구조
• 인터럽트 처리 구조로서 제어권 탈취 용이
10
스니퍼 또는 보안프로그램의 접근법
• 키보드 인터럽트 처리기의 대체
11
기존 키보드보안 환경
• 현황
- 인터럽트 처리기를 교체하여 스캔코드 수집
- 인터럽트 처리기는 드라이버를 사용하여 스캔코드 수집
system32/drivers/i8042prt.sys(i8042dep.c)를 이용
- 특수한 경우를 제외하고는
다이렉트 폴링을 수행하지 않는 것으로 판단
- 스니퍼의 다이렉트 폴링에는 무방비
• 문제
- 보안 프로그램이 다이렉트 폴링을 수행하는 경우
스니퍼와 경쟁상태에 빠져 상호 정상적인 스캔코드 수집 실패
 스니퍼의 스니핑 포기를 유도하는 것이 가능
- 보안 프로그램이 다이렉트 폴링을 수행할 경우
지나친 오버헤드를 유발하여 많은 환경에서 보안 서비스 불가
12
대응 방안 I
• 제어코드 0xD2를 이용하여 감시 프로그램을 교란
13
방안 I의 문제점
• 상태 레지스터 C/D 비트의 하향 에지 노출
• 비 휘발성 출력버퍼의 스캔코드 노출
• C/D 비트 하향 에지 은닉과 출력버퍼 비움 필요
14
대응 방안 II
• 응답이 있으나 인자가 없는 제어코드 0x20을 이용하여
산발적인 시간에 설정레지스터를 읽어 내어 스니퍼를 교란
15
방안 II의 문제점
• 예측 가능한 응답 코드 발생
• 비 논리적인 응답 코드 발생
• 예측 불가하며 스캔코드와 구별할 수 없는 코드 발생 필요
16
대응 방안 III
• 인자 및 응답이 없는 단독 제어코드를 0xD2 뒤에 연결하여 사용
- 0xD2로 스캔코드 교란, 단독 제어코드로 C/D 비트 변화 은닉
- 0xA6, 0xA7, 0xA8, 0xAD, 0xAE, 0xC1, 0xC2 등이 사용 가능
- 효과 증대하나 큰 임계영역 설정이 필요하므로 과부하 발생
17
대응 방안 IV
• 키보드컨트롤러 내부 메모리 이용
- 미사용의 31바이트 메모리 존재
- 0x20 및 0x60 제어코드를 활용하여 접근 가능
18
방안 IV의 동작
• 준비루틴을 비 주기적으로 실행하여 임의 값 준비
• 교란루틴을 필요할 경우 실행하여 교란코드 생성
• 상대적으로 적은 오버헤드 실현
19
기타 제어코드를 이용한 방지 방안
• 인자는 없고 응답이 있는 제어코드 이용
• 대개 0xD2, 0x20보다 불우
-
0xAA : Self Test  0x55
0xAB : Interface Test  0x00 ~ 0x04
0xC0 : Read Input Port  거의 고정 값
0xD0 : Read Output Port  거의 고정 값
0xE0 : Read Test Port  거의 고정 값
• 스니퍼가 값을 추적 가능하여 걸러낼 수 있음
20
USB 키보드의 보안
• 현황
- USB 보안 문제는 USB 키보드 보안 문제와 직결
- PS/2에서와 같은 선점 경쟁에 돌입 우려
- 크게 세 포인트에서 보안 문제 고려 필요
21
사용자 드라이버 주변의 보안 문제
• 위험성 평가
- 미니 드라이버, 필터 드라이버 등을 이용하여 스캔코드 선점
- 드라이버 오브젝트, 디바이스 오브젝트 등을 통한 정보 획득
- 현재 URB(USB Request Block) 수준까지 스니핑
• USB Transfer 수준까지 공격 가능
• USB Transaction을 관리하는 BUS 드라이버, HC 드라이버의
상위 부분 논리적 구조에 접근
22
USB 전송 구조에서의 보안 문제
• 상위의 디바이스 오브젝트와 연결된 REQUEST 버퍼 존재
- URB를 통하여 전달된 임시 데이터를 조작 가능
• HC와 연결된 스케줄링(TRANSACTION) 버퍼 존재
- 타깃 디바이스의 주소(엔트포인트)와 연결된 버퍼
- USB 타깃에 대하여 최소의 버스 전송 단위
• 각 버퍼에 대하여 스푸핑 등이 가능함 (usbd.sys, usbehci.sys 조작)
23
USB 프로토콜에서의 보안
•
•
•
•
Transaction 단위로 전송
토큰 패킷에 의하여 라우팅
프로토콜 구성의 구속성이 없음
악의적 타깃에 의하여 NAK 전송 등이 가능
24
USB HC 드라이버에서의 보안 문제
25
해결 과제
• End-to-end 보안 채널 구성이 필요
- 사용자의 키보드와 서버 간의 암호화 채널
26