Google은 2024년 4월 처음 발표한 이후, Chrome 146에서 Windows용 Device Bound Session Credentials (DBSC) 기술을 일반 사용자에게 제공하기 시작했으며, 향후 Chrome 출시 버전에서 macOS로 확대할 예정이다. 이 기술은 세션 보안에서 가장 흔한 문제 중 하나인 쿠키 탈취를 겨냥한다. 쿠키가 탈취되면 공격자는 비밀번호 없이도 계정에 접근할 수 있다.
세션 탈취는 일반적으로 사용자가 실수로 악성 소프트웨어를 다운로드할 때 발생한다. 악성 소프트웨어는 실행된 뒤 브라우저에서 현재 쿠키를 추출하거나 사용자가 새 계정에 로그인할 때까지 기다린 다음, 해당 토큰을 공격자가 통제하는 서버로 전송할 수 있다. Google은 LummaC2와 같은 정보 탈취 악성 소프트웨어군이 자격 증명 수집에서 더욱 정교해지고 있다고 지적한다.
일부 쿠키의 유효 기간이 길어지면서 이러한 파일의 위험성은 더욱 커진다. 공격자는 쿠키를 사용해 계정에 무단으로 접근한 뒤 이를 수집하거나 범죄 조직 간에 유통하거나 판매할 수 있다. 또한 고도화된 악성 소프트웨어는 기기에 접근한 뒤 브라우저가 인증 쿠키를 저장하는 파일과 메모리를 읽을 수 있다. 따라서 Google은 운영체제와 관계없이 소프트웨어만으로 쿠키 추출을 막을 신뢰할 만한 방법은 없다고 본다.
기기를 떠나지 않는 키에 세션 연결
DBSC는 인증 세션을 특정 기기에 암호화 방식으로 연결해 이러한 구조를 바꾼다. 이 기술은 Windows의 TPM과 macOS의 Secure Enclave 같은 하드웨어 기반 보안 모듈을 사용해 고유한 공개 키와 개인 키 쌍을 생성한다. 개인 키는 기기에서 내보낼 수 없다.
서버는 Chrome이 세션에 연결된 개인 키를 보유하고 있음을 증명한 뒤에만 새로운 단기 쿠키를 발급한다. 공격자는 이 키를 훔칠 수 없으므로, 추출된 쿠키는 빠르게 만료되어 계정 접근에 쓸모가 없게 된다. Google은 지난해 초기 버전의 프로토콜을 도입한 이후 DBSC로 보호되는 세션 탈취가 크게 감소했다고 밝혔다.
대규모 사이트와 소규모 사이트 모두 백엔드 시스템에 전용 등록 및 갱신 엔드포인트를 추가해 하드웨어에 연결된 세션을 도입할 수 있으며, 기존 프런트엔드 호환성은 유지된다. 브라우저는 복잡한 암호화 작업과 쿠키 교체를 백그라운드에서 처리하고, 웹 애플리케이션은 표준 쿠키를 계속 사용해 서비스에 접근한다.
사용자 추적 없이 세션 보호
DBSC는 개인정보 보호를 고려해 설계되었다. 각 세션은 별도의 키를 기반으로 하므로 사이트가 해당 자격 증명을 사용해 동일한 기기에서 여러 세션 간 또는 여러 사이트 간 사용자의 활동을 연결할 수 없다. 또한 프로토콜은 개인 키 보유를 증명하는 데 필요한 세션별 공개 키를 제외하고 기기 식별자나 인증 데이터를 서버로 전송하지 않는다.
Google에 따르면 이러한 정보 교환 제한은 사이트 간 추적이나 기기 식별 지문 구축에 이 기술이 악용될 위험을 줄인다.
개방형 표준과 지속적인 개발
DBSC는 처음부터 W3C 경로와 웹 애플리케이션 보안 워킹 그룹의 채택을 통해 개방형 웹 표준으로 설계되었다. Google은 Microsoft와 함께 표준을 설계했으며, Okta를 비롯한 여러 웹 플랫폼이 지난해 두 차례의 Origin Trials에 참여해 테스트와 사용을 바탕으로 의견을 제공했다.
Google은 개발자에게 구현 가이드와 함께 프로토콜 사양, GitHub 저장소, 버그 신고 또는 기능 제안 페이지를 제공한다.
향후 개발 분야는 다음과 같다.
- 통합 ID 보안: DBSC를 확장해 서로 다른 자산 간 연결을 지원한다. 이에 따라 신뢰 당사자의 세션은 통합 로그인 과정 전체에서 ID 제공업체에 사용된 원래 기기 키에 연결된 상태로 유지된다.
- 고급 등록 기능: 로그인할 때 새 키를 생성하는 대신 mTLS 인증서나 하드웨어 보안 키 등 기존의 신뢰할 수 있는 키 자료에 세션을 연결한다.
- 더 폭넓은 기기 지원: 전용 보안 하드웨어가 없는 기기를 보호하기 위해 소프트웨어 기반 키를 추가하는 방안을 검토한다.