- MIT 하드웨어 보안 프로젝트는 웹 브라우저에서 가능한 머신러닝 보조 사이드채널 공격을 재현하다가, 높은 모델 정확도가 실제 원인을 증명하지 못한다는 함정을 드러냄
- 기존 웹사이트 핑거프린팅 연구는 CPU 캐시 경합을 원인으로 봤지만, 캐시 접근을 없애고 단순 카운터만 증가시키는 방식이 여러 환경에서 더 높은 정확도를 냄
- 연구팀은 CPU 주파수 스케일링, CPU 코어 경합, 캐시 가설을 차례로 배제했고, eBPF 계측으로 100ns 이상 멈춘 구간의 99% 이상이 인터럽트 처리였음을 확인함
- 시스템 인터럽트 신호만으로도 웹사이트 로딩 활동이 드러났고, Chrome/Linux에서는 100개 웹사이트 중 피해 사이트를 식별하는 정확도가 96.6% 까지 나타남
- 방어책을 설계하려면 모델이 맞혔다는 사실보다 사이드채널의 실제 메커니즘을 확인하는 분석이 먼저 필요함
연구가 시작된 계기
- 2020년 MIT의 Secure Hardware Design 수업에서 웹 개발과 머신러닝 경험을 바탕으로 웹사이트 핑거프린팅 공격을 재구현하는 프로젝트가 시작됨
- Mengjia Yan은 머신러닝으로 하드웨어 약점을 공격하는 최신 웹사이트 핑거프린팅 연구에 뭔가 맞지 않는 부분이 있다고 보고, 재구현을 제안함
- 프로젝트는 이후 There’s Always a Bigger Fish: A Clarifying Analysis of a Machine-Learning-Assisted Side-Channel Attack 논문으로 이어짐
- 논문은 Intel의 2024 Hardware Security Academic Award 1위와 2023년 IEEE Micro Top Picks에 포함됨
- 연구는 브라우저 공격, 시스템 인터럽트 누출, 머신러닝 해석 오류라는 세 축을 다룸
사이드채널과 웹사이트 핑거프린팅
- 프로세스 격리는 애플리케이션의 메모리와 자원을 분리하지만, 실제 컴퓨터에서는 네트워크 카드, GPU, CPU 같은 자원이 계속 공유됨
- 공유 자원은 의도치 않게 사용자 활동 정보를 흘릴 수 있음
- 같은 Wi-Fi 라우터를 쓰는 사람이 대용량 영상을 보면 다른 사용자의 다운로드 시간이 느려질 수 있음
- 전력 소비 변화나 전자기 방출도 암호화 키나 사용자 활동을 추정하는 사이드채널이 될 수 있음
- 웹사이트 핑거프린팅은 한 탭의 공격자 웹사이트가 다른 탭에서 열린 피해 웹사이트를 식별하려는 공격임
- Shusterman et al.의 기존 연구는 CPU 캐시를 이용해 100개 후보 웹사이트 중 열린 사이트를 맞히는 공격을 제시함
- 공격자는 CPU 캐시 크기의 배열을 만들고 1로 채움
- 피해 웹사이트가 로드되는 동안 2ms마다 배열 접근 시간을 측정함
- 15초 동안 총 7,500개 측정값을 수집함
- 웹사이트마다 스크립트, 이미지, 스타일시트, 렌더링 패턴이 비슷하게 반복되므로 측정 트레이스가 지문처럼 쓰임
- 100개 웹사이트에서 각 100개 트레이스를 모아 총 10,000개의 라벨링된 데이터셋을 만들고 머신러닝 모델을 학습함
- 여러 브라우저와 운영체제에서 최대 91.4% 정확도를 얻음
캐시를 제거한 카운터 공격
- 초기 재구현에서는 4개 웹사이트 분류가 쉬웠고, 단순 Random Forest 분류기로 98% 정확도를 얻음
- 실험을 10개 웹사이트로 확장했을 때 처음에는 75% 정확도였지만, 이후 10개, 50개, 100개 웹사이트 분류까지 개선됨
- 결정적인 변화는 캐시 배열 접근을 없애고, 공격자가 가능한 한 빠르게
value++를 반복하도록 만든 방식임- 일정 시간마다 카운터 값을 저장하면 컴퓨터가 그 기간 동안 얼마나 많이 실행됐는지 트레이스로 남음
- 브라우저 창 크기 조정이나 새 탭 열기 같은 다른 활동도 카운터 트레이스에 반영됨
- 논문에서는 5ms마다 값을 저장해 고정 시간 안에서 더 많은 정보를 얻음
- 카운터 트레이스로 학습한 모델은 기존 캐시 지연 트레이스보다 더 높은 웹사이트 식별 정확도를 보임
- 이 결과는 기존 공격이 실제로 캐시 경합을 이용했는지 의문을 만들었고, 원인을 찾기 위한 분석으로 이어짐
모델 정확도와 원인 분석의 간극
- 머신러닝 보조 사이드채널 공격에서 모델이 사용자 활동을 안정적으로 예측한다는 사실은 신호의 존재만 보여줌
- 높은 정확도는 그 신호가 어떤 사이드채널에서 왔는지를 증명하지 못함
- Shusterman et al.의 모델이 91.4% 정확도로 피해 웹사이트를 맞혔더라도, 그것이 CPU 캐시 경합을 포착했다는 뜻은 아님
- 모델이 찾는 것은 상관관계이며, 신호의 원인을 설명하지 않음
- 잘못된 원인 분석은 방어책 설계를 오도할 수 있음
- 연구자들은 공격 논문을 바탕으로 컴퓨터를 더 안전하게 만드는 방어책을 설계함
- 공격 원인을 잘못 이해하면 시간과 노력이 낭비될 수 있음
가설 검증: 주파수, 코어, 인터럽트
- 연구팀은 기존 캐시 기반 공격과 새 카운터 기반 공격을 여러 환경에서 비교함
- 100개 웹사이트 식별 과제에서 카운터 기반 공격은 거의 모든 실험 구성에서 더 높은 정확도를 냄
- macOS의 Safari에서는 캐시 공격이 72.6%, 카운터 공격이 96.6% 정확도를 보임
- 기본 구성에서는 100개 웹사이트 중 정답을 95.2% 정확도로 식별함
-
CPU 주파수 스케일링 가설
- 현대 CPU는 작업량에 따라 주파수를 올리거나 낮춰 에너지를 절약함
- 피해 웹사이트 로딩 중 CPU 주파수가 변해 카운터 값이 달라질 수 있다는 가설을 세움
- BIOS에서 주파수 스케일링을 비활성화한 뒤 새 데이터를 수집하고 모델을 학습함
- 정확도는 95.2%에서 94.2% 로 1%포인트만 줄어, 카운터 값 변화가 CPU 주파수 변화로 설명되기 어려웠음
-
CPU 코어 경합 가설
- 공격자와 피해 탭이 같은 CPU 코어에서 실행되면 피해 탭 로딩이 공격자의 카운터 실행 시간을 줄일 수 있음
- Linux의
taskset으로 공격자와 피해 탭을 서로 다른 코어에서 실행하도록 고정함 - CPU 주파수 스케일링을 끈 상태에서도 정확도는 94.0% 로 유지됨
- CPU 코어 경합도 주요 원인으로 보기 어려움
-
시스템 인터럽트 가설
- 다음 가설은 시스템 인터럽트가 카운터 기반 공격의 신호라는 것임
- 운영체제는 키보드, 마우스, 디스플레이, 네트워크 카드 같은 하드웨어 장치와 통신하기 위해 인터럽트를 사용함
- 인터럽트가 CPU 코어에 도착하면 해당 코어에서 실행 중인 프로그램은 즉시 멈추고 인터럽트 핸들러가 실행됨
- 피해 웹사이트가 로드되는 동안 네트워크, 그래픽 등 다양한 장치가 인터럽트를 발생시키고, 공격자와 같은 코어에서 처리되면 공격자의 카운터 값이 낮아질 수 있음
- Linux에서는
cat /proc/interrupts로 인터럽트 처리를 확인할 수 있음
이동 가능한 인터럽트와 이동 불가능한 인터럽트
- Linux는 일부 이동 가능한 인터럽트를 특정 코어로 라우팅할 수 있음
- 숫자 ID를 가진 인터럽트가 여기에 해당함
- 키보드, 네트워크 카드 같은 외부 하드웨어 장치에서 오는 경우가 많음
- 많은 이동 불가능한 인터럽트는 특정 코어로 격리할 수 없음
- 세 글자 ID를 가진 인터럽트가 여기에 해당함
- CPU 코어 간 활동 동기화에 쓰이므로 모든 코어에서 처리되어야 함
- 실험 환경에서 인터럽트 활동의 대부분을 차지함
irqbalance로 이동 가능한 인터럽트를 코어 1로 보내고,taskset으로 공격자와 피해자를 코어 2와 3에서 실행하게 함- CPU 주파수도 고정한 상태에서 정확도는 거의 6%포인트 하락해, 인터럽트 가설이 더 유력해짐
eBPF로 확인한 실제 원인
- 이동 불가능한 인터럽트까지 완전히 격리하는 실험은 운영체제 구조상 불가능했기 때문에, eBPF로 실행을 계측함
- eBPF를 통해 두 가지 시점을 기록함
- 공격자 프로그램이 시작하고 멈추는 시점
- 인터럽트 핸들러가 시작하고 멈추는 시점
- CPU 주파수가 고정되어 있으므로, 공격자가 방해받지 않으면 고정 시간 안에서 거의 같은 수의 명령을 실행해야 함
- Jonathan Behrens가 작성한 eBPF 코드로 공격자가 멈춘 구간과 인터럽트 처리 구간을 비교함
- 100ns 이상 지속된 공격자 실행 중단 구간의 99% 이상이 인터럽트 처리 시간으로 확인됨
- 공격자의 CPU 코어는 사실상 카운팅 코드 실행과 인터럽트 처리 중 하나를 하고 있었고, 인터럽트 처리 시간이 줄면 카운터 값이 올라가고 늘면 내려가는 패턴이 나타남
논문의 두 가지 주요 결과
- 첫 번째 결과는 시스템 인터럽트가 사용자 활동을 누출한다는 점임
- 시스템 인터럽트의 보안 속성은 기존 문헌에서 연구된 적이 없었음
- 연구팀은 시스템 인터럽트 기반 사이드채널을 처음으로 분석함
- 두 번째 결과는 머신러닝 보조 사이드채널 공격을 조심해서 분석해야 한다는 점임
- 머신러닝 모델은 사이드채널을 이해하지 못해도 강력한 공격을 만들 수 있음
- 운영체제를 계측하지 않았다면 어떤 사이드채널을 이용하는지 결론 내릴 수 없었음
- 기존 캐시 기반 공격 방어책은 CPU 캐시를 반복적으로 축출해 노이즈를 넣는 방식이었음
- 로컬 IP 주소로 네트워크 요청을 보내는 등 많은 인터럽트를 만드는 방어가 캐시 기반 공격과 카운터 기반 공격 모두에 더 잘 작동함
- 이 비교는 Shusterman et al.의 공격이 캐시보다 인터럽트 신호를 주로 이용한다는 근거를 강화함
추가 실험과 방어 가능성
- 논문에는 추가 결과도 포함됨
- JavaScript에 제공되는 브라우저 클록을 수정해 공격을 완전히 완화하는 방법을 제안함
- 공격자와 피해자를 별도 가상머신에 넣어 격리하는 실험을 수행함
- 여러 이동 불가능한 인터럽트의 빈도와 처리 시간을 분석함
- 브라우저는 JavaScript에 제공하는 클록 정밀도를 줄여 고정밀 타이밍 기반 공격을 어렵게 만듦
- Chrome은 0.1ms 단위로 반올림하고 임의 노이즈를 추가함
- Firefox와 Safari는 1ms 단위로 반올림함
- Tor Browser는 100ms 단위로 반올림해 공격 정확도를 Chrome의 96.6%에서 49.8% 로 낮춤
- 클록 정밀도 축소에는 트레이드오프가 있음
- 브라우저 기반 게임 엔진은 렌더링과 애니메이션에 고정밀 타이머가 필요함
- Tor Browser 사용자는 대부분의 게임을 플레이하기 어렵지만, 보안을 중시하는 사용자에게는 문제가 아닐 수 있음
남은 연구 질문
- 시스템 인터럽트는 Spectre와 Meltdown처럼 현대 컴퓨터 깊숙한 곳에 있는 하드웨어 메커니즘과 연결됨
- 이동 불가능한 인터럽트를 공격자로부터 격리하는 방어는 현재 구현할 수 없고, 이를 가능하게 하려면 컴퓨터를 어떻게 재설계해야 하는지 불명확함
- 웹사이트 활동과 인터럽트 사이의 관계도 충분히 이해되지 않았음
- weather.com은 많은 rescheduling interrupt를 유발했지만 nytimes.com과 amazon.com은 그렇지 않았음
- 추가 이미지, 광고, 스크립트가 카운터 트레이스에 어떤 영향을 주는지는 분석되지 않음
- 공격은 더 강해질 수 있음
- 논문은 “공격 논문”보다 “분석 논문”에 가까움
- Chrome/Linux에서 얻은 96.6% 정확도는 상한이 아니라 하한일 수 있음
- 더 나은 모델이나 다른 방법론으로 1,000개 웹사이트 분류, 영화 시청 여부, VPN 사용 여부, Robinhood 확인 빈도 같은 과제에 적용될 가능성이 남아 있음
- 브라우저 기반 방어도 실제 브라우저에 구현하고 일반 사용자에게 실용적인지 검토해야 함
연구가 개인 경로에 남긴 영향
- 이 프로젝트 전에는 대학원 진학이 진지한 선택지가 아니었고, NVIDIA 딥러닝 연구 인턴 경험 이후 대형 기술 기업이나 AI 스타트업 취업을 생각하고 있었음
- 프로젝트 이후 연구가 재미있고 아름다울 수 있다는 경험을 얻음
- MIT 졸업 후 컴퓨터과학 MEng 과정을 1년 더 진행했고, 이후 Rhodes scholarship을 받아 University of Oxford에서 2년간 공부함
- 다음 해 MIT에서 6년짜리 컴퓨터과학 PhD를 시작할 예정임