SSD 활동 패턴으로 사용자를 추적한다 — 새로운 브라우저 핑거프린팅 공격

또 하나의 추적 기술, 이번엔 SSD를 본다

웹사이트가 사용자를 식별하는 방법은 시간이 지날수록 점점 교묘해지고 있어요. 처음엔 쿠키였고, 다음엔 LocalStorage, 그 다음엔 캔버스 핑거프린팅(Canvas Fingerprinting, 브라우저가 그림을 그리는 미세한 차이로 사용자를 식별하는 기법), 오디오 핑거프린팅, 글꼴 목록 분석 같은 것들이 나왔죠. 그런데 이번에 Ars Technica가 보도한 연구는 한 단계 더 깊이 들어갔어요. SSD(반도체 저장장치)의 동작 패턴을 분석해서 사용자를 식별하거나 다른 활동을 엿볼 수 있다는 거예요.

핑거프린팅이 뭐냐면, 쿠키처럼 명시적인 식별자를 심지 않아도 브라우저·기기·환경의 미세한 차이를 조합하면 "이 사람 어제 왔던 그 사람"이라고 알아낼 수 있는 기술이에요. 광고 추적부터 부정 사용 탐지까지 다양한 용도로 쓰이는데, 사용자 입장에선 사실상 통제할 방법이 없어서 늘 논란이 돼요.

SSD를 어떻게 들여다보는가

이 공격의 원리를 풀어볼게요. SSD는 내부에 컨트롤러와 캐시를 갖고 있어요. 운영체제가 데이터를 읽거나 쓸 때, SSD는 그걸 처리하는 과정에서 미세한 지연(latency) 패턴을 만들어내요. 이 지연은 SSD 모델, 펌웨어 버전, 사용량, 심지어 동시에 다른 프로그램이 디스크를 얼마나 쓰는지에 따라 달라지죠.

연구자들은 브라우저에서 디스크 접근을 유발하는 작업(예: 대용량 파일을 IndexedDB에 쓰거나, 큰 캐시를 만드는 작업)을 시키면서 그 응답 시간을 정밀하게 측정하면, "이 기기의 SSD가 지금 다른 작업을 얼마나 하고 있는지" 까지 추정할 수 있다는 걸 보였어요. 이걸 활용하면 단순한 기기 식별을 넘어서, 사용자가 다른 탭에서 뭘 하고 있는지, 백그라운드에서 어떤 앱이 디스크를 쓰는지까지 흐릿하게나마 엿볼 가능성이 생겨요. 이건 사이드 채널 공격(side-channel attack, 정상 인터페이스가 아닌 부수적 신호로 정보를 빼내는 공격)의 새로운 변종이에요.

기존 기법과 뭐가 다른가

비슷한 결의 연구로는 CPU 캐시 타이밍 공격(Spectre, Meltdown 계열), GPU 핑거프린팅, 메모리 버스 노이즈 측정 같은 게 있었어요. 모두 "브라우저가 직접 접근할 수 없는 하드웨어 정보를 간접적으로 추정한다"는 공통점이 있죠. SSD 기반 기법이 무서운 이유는 거의 모든 사용자가 SSD를 쓰고 있고, 디스크 I/O는 웹 표준 API로 합법적으로 유발할 수 있기 때문이에요. 즉 특별한 권한 없이도 사이트가 사용자의 디스크에 "테스트 부하"를 걸고 응답을 측정할 수 있다는 뜻이에요.

방어는 쉽지 않아요. JavaScript의 시간 측정 정밀도를 의도적으로 낮추는 방식은 Spectre 이후 이미 브라우저들이 쓰고 있는데(performance.now()의 해상도를 5μs 단위로 떨어뜨리는 식), 공격자가 통계적 방법으로 노이즈를 평균내면 정밀도 저하만으론 부족하다는 게 이미 알려져 있고요. 결국 디스크 I/O 자체에 대한 격리(샌드박싱)나 비율 제한 같은 더 깊은 차원의 대응이 필요해요.

광고·트래킹 생태계 흐름 안에서

Apple은 Safari에서 ITP(Intelligent Tracking Prevention)를 도입해서 제3자 쿠키를 강력히 차단했고, Firefox도 Total Cookie Protection을 켰어요. Chrome도 결국 제3자 쿠키 단계적 폐지를 선언했죠. 그런데 쿠키가 막히면 광고·분석 업체들은 더 우회적인 식별 기법을 개발해요. SSD 사이드 채널은 아직 학술적 단계지만, 같은 흐름의 더 깊은 층위에서 "식별을 멈추지 않으려는 시도"가 계속되고 있다는 신호예요.

한국 개발자에게 주는 시사점

프론트엔드나 보안 쪽 일을 하시는 분이라면 두 가지 관점에서 챙겨볼 만해요. 첫째, 우리 서비스가 사용하는 분석 SDK가 어디까지 정보를 수집하는지 다시 점검해보세요. 개인정보보호법은 "식별 가능성"을 폭넓게 해석하기 때문에, 핑거프린팅 기법은 점점 더 명시적 동의 영역으로 끌려 들어올 가능성이 커요. 둘째, 고정밀 타이밍 API를 다루는 코드를 작성할 때, 의도치 않게 사이드 채널을 노출시키지 않는지 살펴볼 필요가 있어요. SharedArrayBuffer 같은 기능을 쓸 땐 COOP/COEP 헤더 설정으로 격리를 명확히 해주는 게 기본이고요.

마무리

웹은 기능이 늘어날수록 추적의 표면도 같이 넓어져요. 사용자를 식별하지 않고도 좋은 제품을 만들 수 있을지, 아니면 식별 없이는 비즈니스가 불가능한 구조인지 — 이 질문을 회사 안에서 한 번쯤 던져봐야 할 시점인 것 같아요. 여러분의 서비스는 사용자를 얼마나 알고 있나요, 그리고 그만큼 알아야만 동작하는 게 맞나요?