---
url: 'https://www.corbado.com/ko/blog/device-bound-session-credentials-dbsc'
title: '기기 바인딩 세션 자격 증명(DBSC) 설명'
description: '기기 바인딩 세션 자격 증명(DBSC)이 세션 하이재킹 및 쿠키 탈취를 방지하는 방법을 알아보세요. 브라우저 지원 상태와 엔터프라이즈 보안에 대해 알아봅니다.'
lang: 'ko'
author: 'Vincent Delitz'
date: '2026-06-15T13:59:58.604Z'
lastModified: '2026-06-16T06:09:29.590Z'
keywords: '기기 바인딩 세션 자격 증명, DBSC, 세션 하이재킹 방지, 쿠키 탈취 보호, TPM 세션 바인딩'
category: 'Authentication'
---
# 기기 바인딩 세션 자격 증명(DBSC) 설명
**브라우저 지원 상태**
> **최신(2026년 4월):** Chrome 146은 Windows에서
> [DBSC를 일반 출시(GA)로 제공](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)하여
> 오리진 트라이얼(Origin Trial)에서 정식 기능으로 전환했습니다. macOS 지원(Secure Enclave
> 사용)은 향후 Chrome 릴리스에서 제공될 예정입니다. Google은 또한 페더레이션 ID(교차 출처
> [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) 바인딩), 고급 등록(mTLS / 하드웨어 키) 및 보안
> 하드웨어가 없는 기기를 위한 소프트웨어 기반 키에 대한 공개 로드맵을 발표했습니다.
| 브라우저 | Windows | macOS | Linux | Android | iOS | 상태 |
| ----------- | ----------------------- | ------------------------ | -------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Chrome** | ✅ GA (Chrome 146, TPM) | 🚧 예정 (Secure Enclave) | ❌ | ❌ | ❌ | [Windows에서 GA](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/) (2026년 4월), 향후 릴리스에서 macOS 지원 |
| **Edge** | ⏸️ 트라이얼 종료 | ❌ | ❌ | ❌ | ❌ | 2025년 10월 오리진 트라이얼 종료, GA 발표 없음 |
| **Safari** | 해당 없음 | 🔄 평가 중 | 해당 없음 | 해당 없음 | 🔄 평가 중 | WebKit 논의 중, 구현 발표 없음 |
| **Firefox** | 🔄 모니터링 중 | 🔄 모니터링 중 | 🔄 모니터링 중 | 🔄 모니터링 중 | 🔄 모니터링 중 | 평가 중, 구현에 대한 확약 없음 |
**범례:** ✅ 일반 출시 | 🚧 발표됨 / 개발 중 | ⏸️ 트라이얼 종료 | 🔄 평가/모니터링 중 | ❌
아직 사용 불가
**참고:** [DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc)는 Chrome 146(2026년 4월)부터
Windows에서 TPM을 통해 일반 출시(GA)되었습니다.
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave)를 통한 macOS 지원이 다음에 출시될 예정입니다.
Google이 밝힌 로드맵에는 전용 보안 하드웨어가 없는 기기까지 보호를 확장하기 위한
소프트웨어 기반 키도 포함되어 있습니다.
**주요 이점: DBSC vs 현재 모델**
| **기능** | **현재 쿠키 모델** | **DBSC 모델** |
| --------------- | ------------------------ | --------------------------------- |
| **토큰 유형** | 무기명 (소유 = 액세스) | 바인딩됨 (소유 + 키 = 액세스) |
| **탈취 결과** | 완전한 계정 탈취 | 쓸모없는 토큰 (새로 고침 불가) |
| **세션 기간** | 짧음 (보안을 위해) | 길거나 무기한 (설계상 안전함) |
| **사용자 마찰** | 높음 (잦은 로그인) | 낮음 (눈에 띄지 않는 보안) |
| **MFA 우회** | 취약함 (Pass-the-cookie) | 저항성 (기기 필요) |
| **취소** | 느림 (만료 대기) | 거의 실시간 (다음 새로 고침 실패) |
## Key Facts
- **DBSC**는 웹 세션을 기기에 저장된 암호화 키에 바인딩하여, 다른 기기에서 새로 고칠 수
없기 때문에 탈취된 쿠키를 무용지물로 만듭니다.
- 브라우저는 내보낼 수 없는 개인 키를 **TPM**에 저장하고 5분마다 서버 챌린지에 서명하여
사용자의 개입 없이 기기 소유를 증명합니다.
- TLS 계층 인프라의 복잡성으로 인해 실패한 \*\*토큰 바인딩(Token Binding)\*\*과 달리,
DBSC는 HTTP 애플리케이션 계층에서 작동하며 기존 로드 밸런서 및 CDN과 투명하게
작동합니다.
- \*\*Chrome 146은 Windows에서 DBSC를 GA로 제공(2026년 4월)\*\*하며, macOS Secure Enclave
지원은 향후 릴리스에서 예정되어 있습니다. Google의 공개 로드맵은 페더레이션 ID(교차 출처
SSO 바인딩), 고급 등록(mTLS / 하드웨어 키) 및 보안 하드웨어가 없는 기기를 위한
소프트웨어 기반 키도 다루고 있습니다. Safari와 Firefox는 여전히 평가 중이며, Edge의
오리진 트라이얼은 2025년 10월에 종료되었고 GA는 발표되지 않았습니다.
## 1. 소개: 기기 바인딩 세션 자격 증명(DBSC)
월드 와이드 웹의 아키텍처는 무상태(statelessness)라는 원칙 위에 세워졌습니다. 처음 HTTP가
설계되었을 때는 요청 간에 사용자에 대한 정보를 유지하지 않았습니다. 이를 해결하기 위해
웹사이트에서 전송되어 사용자 컴퓨터에 저장되고 이후의 모든 요청과 함께 웹사이트로 다시
전송되는 작은 데이터 조각인 "쿠키"가 발명되었습니다. 수십 년 동안 이 메커니즘은 세션
관리의 기반이 되었습니다. 사용자가 로그인하면 서버는 자격 증명을 검증하고 쿠키를
발급합니다. 이 쿠키는 "무기명 토큰(bearer token)" 역할을 합니다. 현실 세계에서 무기명
증서란 소지자에게 그것이 나타내는 권리나 자산에 대한 자격을 부여하는 문서입니다. 채권을
가지고 있으면 채권을 소유한 것입니다. 마찬가지로 HTTP라는 디지털 세계에서는 쿠키를
소유하고 있으면 그 사용자로 인정받습니다.
이러한 무기명 특성은 웹의 가장 큰 유틸리티인 동시에 가장 심각한 취약점이기도 합니다. 전체
세션, 나아가 사용자의 ID, 데이터 및 금융 자산의 보안은 해당 쿠키 문자열의 비밀 유지에
전적으로 의존합니다. 악의적인 행위자가 그 문자열을 복사할 수 있다면 세계 어디에서나 어떤
기기에서든 사용자를 사칭하여 초기 인증 검사를 완전히 우회할 수 있습니다. 이 특정한
취약점은 "쿠키 탈취"와 "세션 하이재킹"이라는 산업적 규모의 지하 경제를 탄생시켰습니다.
업계가 FIDO(Fast Identity Online) 표준과 패스키 채택을 통해 인증이라는 "현관문"을
성공적으로 강화함에 따라 공격자들은 "뒷문", 즉 활성 세션으로 초점을 옮기고 있습니다.
비밀번호를 피싱하는 것은 점점 더 어려워지고 있지만, 세션 쿠키를 탈취하는 것은 여전히
위험할 정도로 효과적입니다. 이러한 확대되는 위협에 대한 업계의 대응이 바로 \*\*기기 바인딩
세션 자격 증명(DBSC)\*\*입니다.
[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc)는 웹 세션을 유지하는 방식의 패러다임
전환을 나타냅니다. 이는 단순한 무기명 토큰에서 벗어나 세션이
[암호화 방식으로 기기에 바인딩되는](https://www.w3.org/TR/dbsc/) 모델로의 전환을
제안합니다.
[Chrome 146(2026년 4월)이 Windows에서 DBSC를 GA로 제공](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)함에
따라 표준은 실험 단계에서 벗어나 웹 팀이 지금 당장 배포할 수 있는 프로덕션 기능으로
이동했습니다. Chrome은 Windows에서 TPM을 사용하며 다음으로 macOS의
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) 지원을 출시할 예정입니다. 사양 자체는 키
스토리지에 대해 알지 못하며 "설명된 위협에 대해 강력할 것"만을 요구합니다. 이는 탈취된
쿠키의 가치를 크게 떨어뜨립니다. 바인딩된 키가 없으면 다른 기기에서 이를 새로 고칠 수
없습니다.
이 글은 보안 아키텍트, 제품 관리자 및 개발자를 위해 설계된
[DBSC](https://www.corbado.com/blog/device-bound-session-credentials-dbsc)에 대한 철저한 분석을 제공합니다. 기술
아키텍처, "마찰 없는 보안"의 비즈니스적 시사점, 공유 신호(Shared Signals, CAEP/RISC)와
같은 신흥 표준과의 관계, 그리고 Corbado와 같은 플랫폼을 사용하여 조직이 이 미래를 어떻게
준비할 수 있는지 탐구합니다.
**이 문서에서 답변하는 주요 질문**
1. 현재의 세션 관리가 계정 탈취를 방지하지 못하는 이유는 무엇인가요?
2. DBSC는 기존의 "안전한(Secure)" 쿠키 및 HttpOnly 플래그와 어떻게 다른가요?
3. 더 강력한 피싱 저항성을 위해 DBSC와 패스키는 어떻게 함께 작동하나요?
4. 토큰 바인딩은 어떻게 되었으며, 왜 DBSC는 실패한 곳에서 성공하고 있나요?
5. 제품 관리자(Product Manager)를 위한 비즈니스적 의미와 ROI는 무엇인가요?
6. 현재 어떤 브라우저와 운영 체제가 DBSC를 지원하나요?
7. 조직은 처음부터 구축하지 않고도 DBSC를 어떻게 구현할 수 있나요?
8. DBSC, DPoP, [OAuth 2.0](https://www.corbado.com/glossary/oauth2) 간의 관계는 무엇인가요?
9. 실시간 위협 대응을 위해 DBSC는 공유 신호(CAEP/RISC)와 어떻게 통합되나요?
## 2. 핵심 문제 및 솔루션 이해
이 새로운 표준의 복잡성을 탐색하려면 먼저 현재 세션 관리의 근본적인 문제와 DBSC가 어떻게
솔루션을 제공하는지 이해해야 합니다. 이들 각각의 영역은 DBSC가 해결하는 중요한 취약점이나
한계를 나타냅니다.
### 2.1 현재 세션 관리의 실패
현재 세션 관리의 근본적인 실패는 신뢰의 "이동성(portability)"입니다. 서버가 세션 쿠키를
발급할 때 기본적으로 이를 소지한 누구에게나 작동하는 여권을 발급하는 것과 같습니다.
브라우저가
[HttpOnly 및 Secure 플래그](https://www.wisp.blog/blog/understanding-token-storage-local-storage-vs-httponly-cookies)와
같은 방어 수단을 구현했지만(JavaScript 액세스를 방지하고 HTTPS를 통한 전송 보장), 이러한
방어 수단은 교차 사이트 스크립팅(XSS)이나 네트워크 스니핑과 같은 특정 추출 벡터에 대해서만
보호합니다. 호스트 기기에서 실행되는 맬웨어에 대해서는 보호를 제공하지 않습니다. "정보
탈취 악성코드(Infostealers)"는 디스크에서 브라우저의 쿠키 저장소 파일을 찾아 (종종 사용자
자신의 OS 수준 자격 증명을 사용하여) 암호 해독하고 내용을 명령 및
제어(command-and-control) 서버로 빼내도록 특별히 설계된 맬웨어입니다. 공격자가 쿠키를
소유하면 그들은 자신의 브라우저에 탈취한 토큰을 삽입하여 세션을 하이재킹하는
[Pass-the-Cookie 공격](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)을
수행할 수 있습니다. 유효한 쿠키를 확인한 서버는 해당 요청이 합법적이라고 가정합니다.
### 2.2 기존의 안전한 쿠키 대비 DBSC의 암호화 이점
DBSC는 세션 유지 관리 루프 자체에 인증의 두 번째 요소를 도입합니다. 정적인 비밀인 일반적인
보안 쿠키와 달리 DBSC 세션은 수명이 짧은 무기명 토큰과 암호화된 소유 증명으로 구성됩니다.
브라우저는 기기에 안전하게 저장되는 공개-개인 키 쌍을 생성합니다. 서버는 세션을 공개 키에
바인딩합니다. 주기적으로 브라우저는 서버의 챌린지에 서명하여 여전히 개인 키를 소지하고
있음을 증명해야 합니다. [사양은 키 스토리지가](https://www.w3.org/TR/dbsc/) "설명된 위협에
대해 강력할 것"을 요구합니다. Chrome은 사용 가능한 경우 Windows에서 TPM을 사용합니다.
공격자가 다른 기기에서 쿠키를 탈취하더라도 필요한 암호화 서명을 생성할 수 없으므로 이를
새로 고칠 수 없습니다. "무기명(bearer)" 측면은 매우 짧은 기간으로 최소화되는 반면,
"바인딩(binding)" 측면은 장기적인 연속성을 제공합니다.
### 2.3 패스키와 DBSC 간의 시너지
패스키와 DBSC는 사용자 수명 주기의 각기 다른 단계를 보호하는 보완적인 기술입니다.
패스키(FIDO2)는 비밀번호 없이 세션을 시작할 수 있도록 ID를 증명하는 _인증_ 문제를 해결하여
자격 증명 피싱을 제거합니다. DBSC는 쿠키 탈취를 통한 세션 하이재킹을 훨씬 더 어렵게 만들어
_인증 후_ 문제를 해결합니다.
[FIDO 얼라이언스는 DBSC를](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
세션 하이재킹에 대한 방어벽을 "높이는" 보완적인 기술로 구성합니다. 함께, 로그인 및 세션
수명 주기 전반의 공격 표면을 줄이지만 DBSC가 기기에 지속적인 액세스 권한을 가진 맬웨어나
동일한 기기에서의 실시간 브라우저 중간자 공격(browser-in-the-middle attacks)으로부터
보호하는 것은 아닙니다.
| 기술 | 원격 피싱 | 크리덴셜 스터핑 | 토큰 탈취 |
| ------------------------ | --------- | --------------- | --------- |
| **패스키** | ✅ | ✅ | ❌ |
| **DBSC / DPoP** | ❌ | ❌ | ✅ |
| **패스키 + DBSC / DPoP** | ✅ | ✅ | ✅ |
**패스키와 DBSC가 함께 작동하는 방법**
| **측면** | **패스키** | **DBSC** | **결합 시 이점** |
| ----------------- | -------------------------------------- | ----------------------------- | -------------------------------------- |
| **범위** | 인증 (로그인) | 세션 관리 | 엔드투엔드 보호 |
| **완화되는 위협** | 비밀번호 피싱, 크리덴셜 스터핑 | 원격 세션 하이재킹, 쿠키 탈취 | 계정 탈취에 대해 크게 높아진 방어 수준 |
| **사용자 경험** | 비밀번호 없는 로그인 | 투명한 세션 보호 | 매끄럽고 안전한 경험 |
| **키 스토리지** | 기기에 바인딩되거나 동기화된 자격 증명 | 기기 바인딩 (가능한 경우 HSM) | 유연한 인증, 엄격한 세션 바인딩 |
| **배포** | 비밀번호 대체 | 기존 세션 강화 | 점진적인 보안 개선 |
### 2.4 토큰 바인딩 실패에서 얻은 교훈
DBSC가 이 문제를 해결하려는 첫 번째 시도는 아닙니다. "토큰 바인딩(Token Binding)"은 쿠키를
기본 TLS(전송 계층 보안, Transport Layer Security) 연결에 바인딩하려는 이전
표준이었습니다. 암호화 관점에서 볼 때는 건전했지만 토큰 바인딩은 TLS 계층에 대한 과도한
의존으로 인해 채택에 실패했습니다. 현대 웹에서 TLS 연결은 로드 밸런서, CDN 또는 리버스
프록시에서 종종 종료되며, 애플리케이션 로직은 그 뒤에 있는 서버에 있습니다. 이 복잡한
네트워크 계층을 통해 토큰 바인딩 정보를 전파하는 것은 너무 어려운 것으로 판명되었습니다.
DBSC는 이러한 실패에서 교훈을 얻어
[전적으로 애플리케이션 계층(HTTP)에서 작동합니다](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/).
기본 네트워크 연결에 의존하지 않으므로 기존 로드 밸런서, 프록시 및 클라우드 인프라와
호환됩니다.
### 2.5 비즈니스 의미 및 ROI 기회
제품 리더들에게 DBSC는 사용자 경험(UX)을 동시에 개선하면서 보안을 향상시킬 수 있는 기회를
제공합니다. 전통적으로 높은 보안은 짧은 세션 시간 초과를 의미했으며 사용자에게 잦은
로그인(마찰)을 강요했습니다. 세션을 기기에 바인딩함으로써 _원격_ 쿠키 탈취의 위험이 크게
줄어듭니다. 탈취된 쿠키는 다른 기기에서 새로 고칠 수 없다는 것을 알기 때문에 기업은 더 긴
세션 기간을 고려할 수 있습니다. 그러나 DBSC는 기기 도난, 기기의 지속적인 맬웨어 또는
악의적인 사용자에 의한 남용으로부터 보호하지 않으므로 세션 수명 정책은 여전히 이러한 잔여
위험을 반영해야 합니다.
## 3. 위협 지형: 쿠키 탈취의 산업화
DBSC 이면의 시급성을 이해하려면 현대 위협 환경의 정교함을 인식해야 합니다. 세션 쿠키
탈취는 틈새 해커의 속임수에서 확장 가능하고 자동화된 산업으로 발전했습니다.
### 3.1 정보 탈취 악성코드(Infostealers)의 부상
```mermaid
graph TD
A[사용자가
악성 소프트웨어 다운로드] -->|실행| B[기기에서
Infostealer 활성화]
B --> C[브라우저 데이터 찾기]
C --> D[Chrome/Edge/Firefox
쿠키 저장소]
C --> E[비밀번호 데이터베이스]
C --> F[암호화폐 지갑]
D --> G[OS 자격 증명을
사용하여 암호 해독]
E --> G
F --> G
G --> H[탈취한 데이터가 포함된
로그 파일 생성]
H --> I[C2 서버로 유출]
I --> J[다크 웹 마켓플레이스]
J --> K[공격자가 로그 구매]
K --> L[자신의 브라우저로
쿠키 가져오기]
L --> M[MFA 우회]
M --> N[계정 탈취
완료]
style A fill:#ff6b6b,color:#fff
style B fill:#ff6b6b,color:#fff
style N fill:#ff6b6b,color:#fff
style J fill:#495057,color:#fff
style M fill:#ffd43b,color:#000
```
서비스형 맬웨어(MaaS)는 사이버 범죄자들의 진입 장벽을 낮췄습니다. RedLine, Raccoon, Vidar
및 Taurus와 같은 "Infostealers"는 상업적으로 이용 가능한 맬웨어 계열로 웹 브라우저에서의
데이터 유출이라는 하나의 주요 목표를 가지고 설계되었습니다. 이러한 탈취 프로그램은 피싱
이메일, 크랙된 소프트웨어 또는 악성 광고를 통해 배포됩니다. 설치가 되면 이들은 Chrome,
Edge, Firefox와 같은 브라우저가 데이터를 저장하는 특정 파일 경로를 표적으로 삼습니다.
- **표적:** 쿠키 데이터베이스(일반적으로 [SQLite](https://www.corbado.com/blog/passkey-webauthn-database-guide)
파일) 및 로그인 데이터 데이터베이스(저장된 비밀번호).
- **메커니즘:** 브라우저는 사용자의 OS 로그인에 연결된 데이터 보호 API(Windows의 경우
DPAPI)를 사용하여 이러한 데이터베이스를 암호화합니다. 맬웨어는 _사용자 권한으로_
실행되므로 해당 파일의 암호 해독을 손쉽게 요청할 수 있습니다.
- **출력:** 맬웨어는 암호 해독된 쿠키, 비밀번호, 시스템 정보 및 경우에 따라 암호화폐 지갑
키가 포함된 zip 파일인 "로그"를 생성합니다.
### 3.2 "로그" 시장
이러한 로그들은 집계되어 Genesis Market(압류 전) 및 Russian Market과 같은 다크 웹
[마켓플레이스](https://www.corbado.com/passkeys-for-e-commerce)에서 판매됩니다. 구매자는 "Salesforce", "Gmail",
"Bank of America" 또는 "[AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) Console"과 같은 특정 고가치
표적에 대한 활성 쿠키가 포함된 로그를 검색할 수 있습니다.
**우회:** 쿠키 로그의 가치는 다중 요소 인증(MFA)을 우회할 수 있는 능력에 있습니다.
대부분의 [MFA](https://www.corbado.com/ko/blog/medibank-data-breach) 챌린지(SMS, TOTP, 푸시)는 _로그인_ 이벤트
중에만 발생합니다. 세션이 설정되고 쿠키가 발급되면 서버는 사용자를 신뢰할 수 있다고
가정합니다. 유효한 세션 쿠키를 가져오는 공격자는
[MFA 게이트를 그대로 통과하여](https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc)
서버에 활성 탭으로 돌아온 사용자처럼 보이게 됩니다.
### 3.3 Google Workspace 및 Microsoft Entra 위협
클라우드 생산성 제품군은 주요 표적입니다. Google Workspace 또는 Microsoft Entra ID(이전의
Azure AD) 계정의 도난된 세션 쿠키는 공격자에게 회사 이메일, 문서 및 내부 시스템에 대한
액세스 권한을 부여할 수 있습니다.
[Google 자체의 위협 인텔리전스](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)는
Google 계정에 액세스하기 위한 주요 벡터로 쿠키 탈취가 크게 증가했음을 보고했으며, 이를
DBSC에 투자하는 동인으로 명시적으로 지정했습니다. 2단계 인증(2SV) 및 패스키를 강제
활성화함에 따라 공격자들은 [2SV](https://www.corbado.com/blog/2sv-vs-2fa)/패스키가 차단하는 자격 증명 피싱에서
종종 [2SV](https://www.corbado.com/blog/2sv-vs-2fa)/패스키가 차단하지 못하는 쿠키 탈취로 전술을 단순히 전환했다고
언급합니다.
### 3.4 "기기 지문(Device Fingerprinting)"의 한계
역사적으로 리스크 엔진은 [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
문자열, 화면 해상도, 설치된 글꼴 및 IP 주소를 분석하여 기기 지문을 확인하는 방식으로 세션
탈취를 감지하려 했습니다. 약간 다른 캔버스 지문을 가진 새 IP에서 세션 쿠키가 갑자기
나타나면 서버가 이를 무효화할 수 있습니다. **문제:** 브라우저의 개인정보 보호
이니셔티브(예: Safari의 Intelligent Tracking Prevention 및 Chrome의 Privacy Sandbox)는
광고 추적을 차단하기 위해 이러한 지문의 엔트로피를 적극적으로 줄이고 있습니다. 이로 인해
보안을 위한 "좋은" 지문 채취가 점점 더 어려워지고 있습니다. 또한 공격자들은 이제 완벽하게
위장하여 피해자의 프로필과 일치시키는 "안티 디텍트 브라우저(Anti-Detect Browsers)"를
사용하여 휴리스틱 탐지를 무력화합니다. DBSC는 이 확률적 추측 게임을 결정론적 암호화
증명으로 대체합니다.
## 4. 기술 아키텍처: DBSC 작동 방식
기기 바인딩 세션 자격 증명(DBSC)은 클라이언트 기기의 키에 바인딩된 세션을 생성하기 위한
[표준화된 API 및 프로토콜](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials)을
도입합니다. 사양은 "설명된 위협에 대해 강력할 것"을 키 스토리지에 요구하지만 구현에
대해서는 특정 방식을 요구하지 않습니다. Chrome은 사용 가능한 경우 Windows에서 TPM을
사용합니다. 이 섹션에서는 W3C 작업 초안(Working Draft) 및 Chrome 문서에 정의된 메커니즘을
자세히 설명합니다.
### 4.1 핵심 구성 요소
| **구성 요소** | **설명** | **DBSC에서의 역할** |
| ----------------------------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **사용자 에이전트(브라우저)** | 클라이언트 애플리케이션(Chrome, Edge 등). | 키 쌍을 관리하고 HSM 상호 작용을 처리하며 네트워크 요청을 가로채서 증명을 첨부합니다. |
| **신뢰 당사자(서버)** | 웹 애플리케이션(예: 뱅킹 포털). | 챌린지를 발행하고 서명을 확인하며 세션 수명 주기를 관리합니다. |
| **키 스토리지** | 보안 스토리지(TPM, Secure Enclave 등) | 개인 키를 저장합니다. Chrome은 가능할 때 Windows에서 TPM을 사용합니다. 사양은 구현에 대해 특정 방식을 지정하지 않습니다. |
| **세션 쿠키** | 표준 HTTP 쿠키. | 무기명 토큰으로 사용되지만 수명이 매우 짧습니다(예: 5\~10분). |
| **소유 증명** | 암호화 서명. | 브라우저가 여전히 개인 키를 가지고 있음을 증명하기 위해 브라우저에서 보낸 JWT입니다. |
### 4.2 DBSC 프로토콜 수명 주기
DBSC 수명 주기를 통해 표준 세션에서 바인딩된 세션으로 원활하게 전환하여 이전 버전과의
호환성 및 점진적인 향상(progressive enhancement)을 보장할 수 있습니다.
```mermaid
sequenceDiagram
participant User as 사용자
participant Browser as 브라우저
participant HSM as HSM (TPM/Secure Enclave)
participant Server as 서버
Note over User,Server: 1단계: 인증 및 바인딩
User->>Browser: 자격 증명/패스키로 로그인
Browser->>Server: 인증 요청
Server->>Browser: 성공 + DBSC 등록 헤더
Browser->>HSM: 키 쌍 생성
HSM->>Browser: 공개/개인 키(개인 키 내보내기 불가)
Browser->>Server: 공개 키 등록(JWT 서명됨)
Server->>Server: 공개 키에 세션 바인딩
Server->>Browser: 수명이 짧은 쿠키(5분)
Note over User,Server: 2단계: 정상 사용
loop 5분 이내 모든 요청
Browser->>Server: 쿠키 포함 요청
Server->>Browser: 응답
end
Note over User,Server: 3단계: 새로 고침(만료 후)
Browser->>Server: 만료된 쿠키 포함 요청
Server->>Browser: 401 + 챌린지 논스
Browser->>HSM: 챌린지 서명
HSM->>Browser: 서명
Browser->>Server: 서명 증명
Server->>Server: 저장된 공개 키로 확인
Server->>Browser: 새로운 수명이 짧은 쿠키
Browser->>Server: 원래 요청 재시도
Server->>Browser: 성공 응답
```
#### 4.2.1 1단계: 개시 및 바인딩
바인딩 프로세스는 사용자가 표준 방법(비밀번호, 패스키 등)을 사용하여 인증을 완료한 직후에
시작됩니다.
1. **서버 신호:** 성공적인 로그인 시 서버는 (평소처럼) 세션 쿠키를 설정하지만 DBSC 지원을
나타내는 특정 헤더를 추가합니다.
```
HTTP
HTTP/1.1 200 OK
Set-Cookie: session_id=xyz123...; Secure; HttpOnly; SameSite=Strict
Secure-Session-Registration: (ES256 RS256); path="/auth/dbsc/register"
```
- Secure-Session-Registration 헤더는 브라우저에게 "나는 알고리즘 ES256과 RS256을
지원합니다. 엔드포인트 /auth/dbsc/register에 바인딩된 세션을 등록해주세요."라고
지시합니다.
2. **키 생성:** 브라우저가 이 헤더를 구문 분석합니다. 기기에 안전하게 저장된 새로운 비대칭
키 쌍(예: 타원 곡선 P-256)을 생성합니다.
- **구현 참고:** Chrome은 가능한 경우 Windows에서 TPM을 사용합니다. 사양은 스토리지
메커니즘에 대해 독립적이며, "설명된 위협에 대해 강력할 것"만을 요구합니다.
- **개인정보 보호 범위:** 키는 웹 오리진(예: bank.com) 범위로 제한됩니다. 브라우저는
이 키가 retailer.com에서 결코 사용되지 않도록 하여 교차 사이트 추적을 방지합니다.
3. **등록 요청:** 브라우저는 지정된 등록 경로로 요청을 보냅니다. 이 요청에는 개인 키로
서명된(자체 서명된 증명) JSON Web Token(JWT) 내에 새로 생성된 **공개 키**가 포함됩니다.
```
HTTP
POST /auth/dbsc/register HTTP/1.1
Content-Type: application/jwt
\.\.\
```
4. **세션 바인딩:** 서버는 서명을 검증하여 공개 키가 작동하는지 확인합니다. 그런 다음
데이터베이스를 업데이트하여 사용자의 세션(session_id=xyz123)을 이 특정 공개 키에
연결합니다. 이 순간부터 세션은 "바인딩"됩니다.
#### 4.2.2 2단계: 수명이 짧은 쿠키 루프
성능과 보안의 균형을 맞추기 위해(보안 키 작업으로 대기 시간이 추가될 수 있음) DBSC는 듀얼
토큰 시스템을 사용합니다.
1. **발급:** 서버가 수명이 짧은 _새_ 쿠키(예: 5분간 유효)를 발급합니다. 이것을
access_token이라고 부르겠습니다.
2. **사용:** 브라우저는 모든 정상적인 요청(이미지 가져오기, API 호출, 페이지 탐색)에 이
access_token을 사용합니다. 쿠키가 유효한 한, 암호화 작업은 수행되지 않습니다. 이를 통해
브라우징이 빠른 상태로 유지됩니다.
3. **만료:** 5분 후 access_token이 만료됩니다.
#### 4.2.3 3단계: 새로 고침(소유 증명)
이것이 보안 메커니즘의 핵심입니다. 수명이 짧은 쿠키가 만료되면 다른 기기의 공격자는
차단되지만, (바인딩된 키에 액세스할 수 있는) 합법적인 사용자는 계속할 수 있습니다.
1. **감지:** 브라우저가 요청을 시도합니다. 쿠키가 만료되었음을 인식합니다(또는 서버가 401
또는 특정 Secure-Session-Challenge 헤더를 반환합니다).
2. **가로채기:** 브라우저는 네트워크 요청을 \_일시 중지\_합니다. 사용자에게 오류를
표시하지 않습니다.
3. **새로 고침 요청:** 브라우저는 세션 구성에 정의된 새로 고침 엔드포인트를 자동으로
호출합니다.
- 서버는 암호화 **챌린지**(논스)를 보냅니다.
- 브라우저는 바인딩된 키를 사용하여 이 챌린지에 서명합니다.
- 서명은 개인 키의 소유를 증명합니다.
4. **제출:** 브라우저가 서명된 챌린지를 서버로 다시 보냅니다.
```
HTTP
POST /auth/dbsc/refresh HTTP/1.1
Sec-Secure-Session-Id: \
Secure-Session-Response: \
```
5. **검증:** 서버는 저장된 공개 키를 사용하여 서명을 확인합니다.
- _유효한 경우:_ 서버는 요청이 세션을 시작한 동일한 물리적 기기에서 온 것임을 알게
됩니다. (또 다른 5분 동안 유효한) _새로운_ 수명이 짧은 access_token을 발급합니다.
- _유효하지 않은 경우:_ 요청이 거부됩니다. 세션이 종료됩니다.
6. **재개:** 브라우저는 새 쿠키를 가져와 일시 중지된 원래 요청을 투명하게 재시도합니다.
[사용자는 아무런 중단도 경험하지 않습니다](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials).
### 4.3 구현 뉘앙스
#### 4.3.1 "리프트 앤 시프트(Lift and Shift)" 방어
```mermaid
graph LR
subgraph "피해자의 기기"
A[DBSC 적용
사용자 세션]
B[HSM/TPM
개인 키]
C[쿠키 +
세션 ID]
A --> B
A --> C
B -.->|내보내기 불가| X[개인 키
추출 불가]
end
subgraph "공격 시나리오"
D[기기를 감염시키는
RedLine Stealer]
D --> E[쿠키 및
세션 ID 탈취]
E --> F[공격자에게
내보내기]
end
subgraph "공격자의 기기"
G[탈취한 쿠키
가져오기]
H[세션 사용
시도]
I[서버에서 DBSC
새로 고침 요청]
J[챌린지 서명
불가]
K[세션 거부됨]
G --> H
H --> I
I --> J
J --> K
end
C -.->|탈취됨| E
F --> G
style D fill:#ff6b6b,color:#fff
style K fill:#51cf66,color:#fff
style B fill:#4c6ef5,color:#fff
style X fill:#51cf66,color:#fff
style J fill:#ff6b6b,color:#fff
```
RedLine Stealer로 사용자의 PC를 감염시킨 공격자를 고려해 보겠습니다. 그들은
`access_token`과 `session_id`를 훔쳐 자신의 브라우저로 가져옵니다.
- **시나리오 A (5분 이내):** 공격자는 수명이 짧은 토큰이 만료될 때까지 몇 분 동안 액세스할
수 있습니다.
- **시나리오 B (만료 후):** 공격자의 브라우저(다른 기기)가 토큰 사용을 시도합니다. 서버가
이를 거부하고 새로 고침을 요구합니다. 공격자의 브라우저는 DBSC 헤더를 보지만, 바인딩된
개인 키가 없기 때문에 새로 고침을 수행할 수 없습니다. 공격이 실패합니다.
#### 4.3.2 범위 및 개인정보 보호
개인정보 보호는 DBSC의 핵심 설계 목표입니다. [W3C 사양](https://www.w3.org/TR/dbsc/)은
사이트 전반에서 사용자를 추적할 수 있는 글로벌 식별자 사용을 명시적으로 금지합니다.
- **오리진별 키:** 브라우저는 모든 사이트에 대해 고유한 키 쌍을 생성합니다. google.com은
키 A를, amazon.com은 키 B를 확인합니다. 그들 사이에는 아무런 상관관계가 없습니다.
- **사용자 지우기:** 사용자가 쿠키/사이트 데이터를 지우면 브라우저도 관련된 DBSC 키를
삭제합니다. 이를 통해 삭제된 ID를 되살리는 "슈퍼 쿠키(super-cookie)"로 DBSC가 사용되는
것을 방지합니다.
#### 4.3.3 서버 측 고려 사항
DBSC를 구현하려면 서버가 공개 키에 대한 상태를 유지해야 합니다.
- **데이터베이스 스키마:** 세션 테이블은 `user_id` 및 `session_expiry`와 함께 `public_key`
및 `last_challenge`를 저장하도록 업데이트되어야 합니다.
- **성능:** 새로 고침 작업에는 암호화 검증(예: ECDSA 서명 검증)이 포함됩니다. 빠르긴
하지만 단순한 문자열을 확인하는 것보다 CPU 집약적입니다. 하지만 매 요청마다 새로 고침이
일어나는 것이 아니라 몇 분마다 발생하기 때문에 오버헤드는 미미합니다.
## 5. 비즈니스 및 제품 의미
기술적 사양 외에도 DBSC는 비즈니스 전략, 제품 로드맵 및 규정 준수 태세에 중요한 의미를
갖습니다.
### 5.1 마찰 없는 보안의 ROI
보안 이니셔티브는 종종 비용 센터나 마찰 발생기로 간주됩니다. DBSC는 이 내러티브를
뒤집습니다. 다음 다이어그램은 기기 바인딩이 어떻게 일련의 비즈니스 이점을 창출하는지
보여줍니다.
- **사기 감소:** 계정 탈취(ATO)의 주요 벡터를 무력화함으로써 기업은 사기 손실을 수백만
달러 절감할 수 있습니다.
- **지원 비용:** 계정 복구에는 많은 비용이 듭니다.
[처음부터 해킹을 방지하면](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
이러한 운영 부담이 직접적으로 줄어듭니다.
- **전환율 최적화:** [전자상거래](https://www.corbado.com/passkeys-for-e-commerce)에서 모든 로그인 프롬프트는
잠재적인 이탈 지점입니다. DBSC는 공격적인 "로그인 유지" 정책을 허용하여 비밀번호
프롬프트 없는 즉시 결제를 가능하게 합니다.
### 5.2 규정 준수 및 "최첨단(State of the Art)"
유럽의 [GDPR](https://www.corbado.com/ko/blog/secure-document-handling)(일반 데이터 보호 규정)과 같은 규제
프레임워크는 조직이 보안을 보장하기 위해 "적절한 기술적 및 조직적 조치"를 구현하도록
요구합니다.
- **방어 가능한 보안:** DBSC가 표준이 됨에 따라 이는 세션 관리의 "최첨단"으로 해석될
가능성이 높습니다. 침해가 발생한 경우 DBSC를 구현했음을 증명하는 것은 과실 주장에 대한
강력한 방어가 될 수 있습니다.
- **뱅킹 표준(PSD2):** [결제(Payment)](https://www.corbado.com/passkeys-for-payment) 서비스 지침 2(PSD2)는
"강력한 고객 인증(SCA)"을 요구합니다. [SCA](https://www.corbado.com/ko/blog/device-bound-synced-passkeys)는
로그인에 초점을 맞추지만, 세션을 기기에 동적으로 연결하는 것은 인증을 특정 금액 및
수취인에 바인딩하려는 지침의 목표와 완벽하게 일치합니다.
### 5.3 높은 보증(High Assurance) vs 보통 보증(Moderate Assurance)
[FIDO 얼라이언스 백서](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/)는
"보증 수준(Assurance Levels)"이라는 개념을 강조합니다.
- **보통 보증:** (iCloud 키체인과 같은) 동기화된 패스키를 사용합니다. 소비자 앱에 훌륭하고
복구 가능하며 사용하기 쉽습니다.
- **높은 보증:** 기기 바인딩 키가 필요합니다. 이 부분에서 DBSC가 빛을 발합니다.
엔터프라이즈 리소스(인사 포털, 코드 리포지토리) 또는 고가치
[금융(뱅킹)](https://www.corbado.com/passkeys-for-banking)의 경우 조직은 관리 기기에 바인딩된 세션에서만
액세스를 허용하는 정책을 시행할 수 있습니다. DBSC는 이 정책을 위한 기술적 시행
메커니즘을 제공합니다.
## 6. DBSC vs 대안
DBSC의 가치를 완전히 이해하려면 비슷한 문제를 해결하려고 시도했던 다른 기술들과 비교해야
합니다.
```mermaid
graph RL
subgraph "기존 쿠키"
TC1[무기명 토큰 전용]
TC2[탈취에 취약함]
TC3[긴 세션 = 위험]
TC1 --> TC2
TC2 --> TC3
end
subgraph "토큰 바인딩"
TB1[TLS 계층 바인딩]
TB2[❌ 실패: 복잡한 인프라]
TB3[로드 밸런서에서 끊김]
TB1 --> TB2
TB2 --> TB3
end
subgraph "DPoP"
DP1[OAuth 토큰 바인딩]
DP2[✅ API 보호]
DP3[브라우저 세션용 아님]
DP1 --> DP2
DP2 --> DP3
end
subgraph "DBSC"
D1[HTTP 계층 바인딩]
D2[✅ 하드웨어 키 보호]
D3[✅ CDN/로드 밸런서와 호환됨]
D4[✅ 브라우저 세션]
D1 --> D2
D2 --> D3
D3 --> D4
end
style TC2 fill:#ff6b6b,color:#fff
style TB2 fill:#ff6b6b,color:#fff
style D2 fill:#51cf66,color:#fff
style D3 fill:#51cf66,color:#fff
style D4 fill:#51cf66,color:#fff
style DP2 fill:#51cf66,color:#fff
```
### 6.1 DBSC vs 토큰 바인딩
앞서 언급했듯이 토큰 바인딩은 세션을 TLS 계층에 바인딩하려 했습니다.
- **토큰 바인딩:** 클라이언트, 서버 _그리고_ 그 사이의 모든 홉(로드 밸런서, TLS 종단기)의
지원이 필요했습니다. 연결이 종료되고 다시 암호화될 때 중단되었습니다.
- **DBSC:**
[HTTP 애플리케이션 계층에서 작동합니다](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/).
로드 밸런서를 통해 표준 헤더/쿠키로 투명하게 통과합니다. TLS가 종종 클라우드 제공업체의
엣지 네트워크에 의해 처리되는 현대 클라우드 아키텍처(AWS/GCP/Azure)에서 배포하기가 훨씬
더 쉽습니다.
### 6.2 DBSC vs DPoP (Demonstrating Proof of Possession)
[DPoP(RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449)는 "발신자
제한(sender-constrained)" OAuth 토큰에 대한 표준입니다. 액세스 토큰과 새로 고침 토큰을
모두 공개 키에 바인딩합니다. 새로 고침 토큰 역시 수명이 긴 무기명 자격 증명이므로 이는
매우 중요합니다. 각 API 요청에는 HTTP 메서드, URL, 타임스탬프 및 고유 식별자가 포함된
서명된 JWT인 DPoP 증명이 포함됩니다.
[FAPI 2.0](https://openid.net/specs/fapi-2_0-security-profile.html)과 같은 높은 보증
사양은 발신자 제한 토큰을 의무화하며, mTLS를 사용할 수 없을 때는 DPoP가 권장 방법입니다.
**주요 차이점:** DPoP 키는 애플리케이션 컨텍스트에 있습니다. 추출 불가능한 스토리지를 위해
OS API를 사용하는 것이 모범 사례이지만 강제되지는 않으며, 많은 구현에서 키를 JavaScript로
액세스할 수 있는 메모리에 보관합니다. 공격자가 임의의 코드(XSS, 맬웨어)를 실행할 수 있는
경우 DPoP 키에 액세스하거나 필요에 따라 증명을 생성할 수 있습니다. DPoP는 _서로 다른
클라이언트 간의_ 토큰 재전송을 막지만 침해된 브라우저 컨텍스트를 보호할 수는 없습니다.
DBSC는 소유 증명을 브라우저와 하드웨어로 이동시킵니다. 개인 키는 JavaScript가 읽거나
내보낼 수 없는 TPM 또는 [Secure Enclave](https://www.corbado.com/glossary/secure-enclave)에 보관됩니다.
브라우저가 프로토콜을 처리하고 애플리케이션 코드에 키를 노출하지 않고 서명을 생성합니다.
웹 앱이 완전히 손상되더라도 공격자는 다른 기기에서 도난당한 쿠키에 대한 새로운 증명을
생성할 수 없습니다.
| 측면 | DPoP | DBSC |
| --------------- | ------------------------------ | ------------------- |
| **대상** | OAuth 액세스 + 새로 고침 토큰 | 브라우저 세션 쿠키 |
| **키 스토리지** | 앱 컨텍스트(모범 사례: OS API) | 하드웨어 기반(TPM) |
| **XSS 저항성** | ⚠️ 구현에 따라 다름 | ✅ 키 내보내기 불가 |
| **주요 용도** | 네이티브 앱, SPA, FAPI 2.0 | 사용자 대상 웹 세션 |
**시너지:**
[FIDO 얼라이언스에서 언급하듯](https://fidoalliance.org/white-paper-dbsc-dpop-as-complementary-technologies-to-fido-authentication/)
패스키는 로그인 시 피싱을 제거하고 DBSC/DPoP는 인증 후 토큰을 보호합니다. 최신 아키텍처는
둘 다 결합합니다. OAuth API(특히 규제 대상 오픈 [뱅킹](https://www.corbado.com/passkeys-for-banking))에는 DPoP를,
브라우저 세션에는 DBSC를 사용합니다. 이들은 함께 전체 세션 수명 주기에 걸쳐 "리프트 앤
시프트(lift and shift)" 공격 벡터를 차단합니다.
### 6.3 DBSC vs 수명이 짧은 쿠키 (단독)
단순히 쿠키 수명을(예: 15분으로) 단축하면 보안은 향상되지만 UX가 파괴됩니다. 사용자는
끊임없이 로그인해야 합니다. DBSC는 5분 쿠키의 _효과적인_ 보안을 30일 쿠키의 \_사용자
경험\_으로 달성하게 합니다.
## 7. 공유 신호 및 동적 대응(CAEP/RISC)
```mermaid
%%{init: {
"theme": "default",
"themeVariables": {
"actorBkg": "#ffffff",
"actorBorder": "#000000",
"noteBkgColor": "#f1f3f5",
"noteTextColor": "#000000",
"activationBkgColor": "#e0e0e0",
"actorColours": {
"ST": "#ff6b6b",
"IdP": "#4c6ef5"
}
}
}}%%
sequenceDiagram
participant ST as 보안 도구
(CrowdStrike, Defender)
participant IdP as ID 공급자
(Okta, Google, Azure)
participant SP1 as 서비스 공급자 1
(Slack)
participant SP2 as 서비스 공급자 2
(Salesforce)
participant SP3 as 서비스 공급자 3
(뱅킹 앱)
participant Session as 사용자 세션
(DBSC 보호됨)
Note over ST,Session: 위협 탐지 단계
ST->>ST: 사용자 기기에서
맬웨어 탐지
ST->>IdP: RISC 신호:
"기기 침해"
Note over IdP,SP3: 신호 전파 단계
IdP->>SP1: CAEP 이벤트:
"기기 침해"
IdP->>SP2: CAEP 이벤트:
"기기 침해"
IdP->>SP3: CAEP 이벤트:
"기기 침해"
Note over SP1,Session: 시행 단계 (DBSC 적용)
Session->>SP1: 다음 새로 고침 시도
(몇 분 이내)
SP1-->>Session: x 서명 거부
Session->>SP2: 다음 새로 고침 시도
SP2-->>Session: x 서명 거부
Session->>SP3: 다음 새로 고침 시도
SP3-->>Session: x 서명 거부
Note over Session: 다음 새로 고침 시도 시 세션 종료 가능
```
DBSC의 잠재력은
[**공유 신호 프레임워크(SSF)**](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/),
특히 **지속적인 액세스 평가 프로파일(Continuous Access Evaluation Profile, CAEP)** 및
\*\*위험 관리(Risk Management, RISC)\*\*와 결합될 때 더욱 커집니다. 참고: SSF/CAEP는
새롭게 부상하는 생태계 기능으로, 아키텍처 패턴은 정의되어 있지만 여러 벤더 간의 광범위한
배포는 여전히 성숙 단계에 있습니다.
기존 모델에서는 사용자의 기기가 침해된 경우 ID 공급자(IdP)가 서비스 공급자(SP)에게 _지금
당장_ 세션을 종료하라고 지시할 방법이 없었습니다. SP는 쿠키가 만료될 때까지 기다려야만
했습니다.
예상되는 DBSC + CAEP 흐름:
1. **트리거:** 엔드포인트 보안 도구(CrowdStrike 또는 Microsoft Defender 등)가 사용자의
노트북에서 맬웨어를 탐지합니다.
2. **신호:** 보안 도구가 ID 공급자(예: Okta/Google)로 RISC 신호를 보냅니다.
3. **전파:** IdP가 연결된 앱에 CAEP 이벤트를 푸시합니다: "기기 침해(Device Compromised)."
4. **시행 (DBSC):** 브라우저가 수명이 짧은 DBSC 쿠키를 새로 고치려고 다음 번에 시도할 때
서버는 서명을 거부하고 세션을 종료합니다.\
이 [아키텍처 패턴](https://fidoalliance.org/white-paper-fido-and-the-shared-signals-framework/)을
통해 더 빠른 취소가 가능해집니다. 실제 지연 시간은 사이트의 새로 고침 주기와 사이트가
DBSC 및 SSF를 모두 구현했는지 여부에 따라 달라집니다.
## 8. 브라우저 및 생태계 지원
DBSC의 채택은 브라우저 공급업체에 달려 있습니다. 2026년의 환경은 크게 변했습니다. Chrome은
DBSC를 오리진 트라이얼에서 2026년 4월 Windows의 일반 출시로 전환했으며 macOS가 그 뒤를
이을 것입니다. 다른 브라우저들은 아직 평가 단계에 있습니다.
### 8.1 Google Chrome
Google은 DBSC의 주요 추진체이자 이 기능을 가장 광범위하게 출시한 최초의 브라우저입니다.
- **상태 (2026년 4월):**
[Chrome 146은 Windows에서 DBSC를 일반 출시(GA)로 제공](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)하여
오리진 트라이얼 단계를 종료했습니다. Secure Enclave를 사용하는 macOS 지원은 향후 Chrome
릴리스에서 발표되었습니다.
- **하드웨어:** Windows는 TPM을 사용하고 macOS는 Secure Enclave를 사용할 예정입니다.
Google은 전용 보안 하드웨어가 없는 기기까지 DBSC 보호를 확장하기 위해 **소프트웨어 기반
키**도 탐색하고 있다고 밝혔습니다.
- **로드맵:** Google의 GA 발표에서는 다음 단계 로드맵도 게시되었습니다:
- **페더레이션 ID 보호:** 신뢰 당사자(RP) 세션이 ID 공급자(IdP) 세션과 동일한 기기
키에 바인딩된 상태를 유지하도록 하는 교차 출처 DBSC 바인딩을 통해
[SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) 과정에서 신뢰의 사슬을 끊어지지 않게
보존합니다.
- **고급 등록:** 로그인 시 새 키를 생성하는 대신 **mTLS 인증서**나 **하드웨어 보안
키**와 같은 기존의 신뢰할 수 있는 키 구성 요소에 DBSC 세션을 바인딩합니다.
- **더 폭넓은 기기 지원:** TPM / Secure Enclave가 없는 기기를 위한 소프트웨어 기반 키.
- **운영 결과:** 롤아웃 중에 Google은 DBSC로 보호되는 세션에 대해 "세션 탈취의 상당한
감소"를 보고했습니다.
- **Google 계정:** 별도로 Google은 엔터프라이즈 정책을 통해 제어되는
[Windows용 Chrome의 Google 계정 쿠키](https://support.google.com/chrome/a/answer/2657289)에
대해 DBSC 스타일의 보호 기능을 이미 출시한 바 있습니다. 이는 Gmail/Workspace를 보호하며
이제는 일반 웹에서 GA인 동일한 기술군입니다.
### 8.2 Microsoft Edge 및 Windows
Microsoft는 적극적으로 참여하고 있습니다.
- **상태:** Edge는 2025년 10월에 종료된 Windows에서의
[DBSC 오리진 트라이얼](https://developer.microsoft.com/microsoft-edge/origin-trials/trials/0c292c9b-58fe-4f23-b066-c3b58911024d)을
실행했습니다. 이를 대체하는 트라이얼이나 GA는 발표되지 않았습니다.
- **엔터프라이즈 컨텍스트:** Edge는 개념적으로 DBSC와 유사한 Entra/Azure AD
[SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)용
["기본 새로 고침 토큰(Primary Refresh Token, PRT)" 아키텍처](https://learn.microsoft.com/en-us/entra/identity/devices/concept-primary-refresh-token)를
활용합니다. PRT는 Microsoft 전용 메커니즘으로 유지됩니다. 서드파티 사이트를 위해 이를
DBSC 웹 표준과 통합하겠다는 계획은 발표되지 않았습니다.
### 8.3 Apple Safari (WebKit)
모바일 커버리지를 위해 Apple의 입장은 중요합니다.
- **상태:** WebKit에는 사용성/개인정보 보호 문제가 제기된 채로 DBSC를 평가하는
[표준 위치 이슈(standards-position issue)](https://github.com/WebKit/standards-positions/issues/281)가
있습니다. Safari 릴리스 노트에서는 DBSC를 언급하지 않습니다. "적극적으로 구현 중"이라는
공개적인 성명은 존재하지 않습니다.
- **개인정보 최우선:** Apple의 주요 우려 사항은 DBSC가 "슈퍼 쿠키(삭제 불가능한 추적)"에
사용될 수 있다는 점입니다. W3C 사양은 웹사이트 데이터와 함께 키가 삭제되도록 하여 이를
해결합니다.
- **참여:** WebKit은 표준 프로세스에 참여하고 있지만, 구현 상태는 "개발 중"이라기보다는
"논의 중"으로 불분명합니다.
### 8.4 Mozilla Firefox
Mozilla에는 복잡성 및 개인정보 보호에 대한 우려가 언급된 채로 DBSC를 평가하는
[표준 위치 이슈](https://github.com/mozilla/standards-positions/issues/912)가 있습니다.
표준이 안정화된 후 구현하겠다는 공개적인 확약은 없습니다.
## 9. 권장 사항: 오늘 사용자 보호
현재의 DBSC 및 패스키에 대한 생태계 지원을 감안할 때 조직은 이러한 보완적인 기술을
구현하기 위해 단계별 접근 방식을 취해야 합니다. 아래의 로드맵은 즉각적인 조치 및 전략적
계획의 마일스톤을 간략하게 설명합니다.
### 9.1 즉각적인 조치 (현재 Chrome 146 GA 상태)
1. **가장 먼저 패스키 배포**: 패스키 구현으로 시작하여 인증 계층을 보호합니다. 이는 자격
증명 피싱에 대한 즉각적인 보호를 제공하며 DBSC에서 실질적인 가치를 얻기 위한 전제
조건입니다.
2. **DBSC 등록 및 새로 고침 엔드포인트 출시**: Chrome 146 GA를 통해, 로그인 응답에
`Secure-Session-Registration` 헤더를 추가하고 `/dbsc/register` 및 서명된 챌린지를
확인하는 새로 고침 엔드포인트를 구현하는 등 백엔드 통합 작업이 이제 현실화되었습니다.
프론트엔드 코드는 변경할 필요가 없습니다.
3. **새로 고침 토큰과 함께 수명이 짧은 세션 구현**: 아직 DBSC를 적용할 준비가 되지
않았다면 새로 고침 메커니즘을 사용하는 수명이 짧은 토큰의 아키텍처 패턴을 채택하십시오.
이렇게 하면 오늘날 보안을 향상시키면서 향후 DBSC를 위한 백엔드를 준비할 수 있습니다.
### 9.2 전략적 계획 (향후 12개월)
1. **하이브리드 접근 방식 채택**: 기능 감지를 사용하여 호환되는 브라우저(현재 Windows 기반
Chrome 146+, 향후 macOS Secure Enclave)에는 DBSC를 제공하는 동시에 대체
옵션(fallback)을 유지합니다. 이는 Safari, Firefox 또는 Edge 사용자를 배제하지 않으면서
보안을 극대화합니다.
2. **다음 로드맵 항목 준비**: Google은 페더레이션 ID(교차 출처 SSO 바인딩), 고급 등록(mTLS
/ 하드웨어 키) 및 폭넓은 기기 커버리지를 위한 소프트웨어 기반 키를 명시적으로
언급했습니다. SSO 또는 IdP 계층을 운영하는 경우 지금 교차 출처 바인딩의 범위를 지정하기
시작하십시오.
3. **ID 공급자와의 통합**: Okta, [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis) 또는 유사한 IdP를
사용하는 경우 그들과 협력하여 SDK에서 DBSC 지원을 활성화하십시오. 많은 업체들이 오리진
트라이얼에 참여했으며 현재 Chrome이 GA가 됨에 따라 DBSC 기능을 적극적으로 출시하고
있습니다.
### 9.3 구현 모범 사례
- **고가치 표적으로 시작**: 관리자 패널, 금융 거래, 민감한 데이터 액세스에 대해 DBSC를
우선시합니다.
- **관리형 솔루션 사용**: DBSC 구현의 복잡성과 브라우저 호환성을 처리하는 Corbado와 같은
플랫폼을 고려하십시오.
- **측정 및 반복**: 세션 하이재킹 시도, 지원 티켓, 사용자 마찰과 같은 지표를 추적하여
ROI를 증명합니다.
- **규정 준수 준비**: DBSC 구현은 민감한 데이터를 처리하기 위한 규정 준수 요건이 될
가능성이 높으므로 문서화하십시오.
## 10. Corbado가 돕는 방법: 미래를 향한 다리
DBSC를 처음부터 구현하는 것은 막대한 엔지니어링 작업입니다. 암호화 전문 지식, 브라우저
불일치에 대한 깊은 지식, 키와 챌린지를 관리하는 강력한 서버 측 인프라가 필요합니다. 이
지점에서 **Corbado**가 인에이블러(enabler) 역할을 합니다.
### 10.1 기반: 패스키
보증 수준이 낮은 로그인 위에 보증 수준이 높은 세션을 구축할 수는 없습니다. 사용자가 약한
비밀번호로 로그인하면 세션의 보안 수준은 해당 비밀번호만큼만 안전합니다. Corbado의 핵심
제품(**관리형 패스키**)은 필요한 기반을 제공합니다. Corbado를 통합함으로써 조직은 패스키를
쉽게 배포하여 세션 시작 단계부터 피싱 저항성을 확보할 수 있습니다.
### 10.2 미래: 신뢰할 수 기기 감지를 위한 DBSC
Corbado는 DBSC를 활용하여 신뢰할 수 있는 기기 감지를 강화할 것입니다. DBSC 신호를 사용할
수 있는 경우, 세션이 특정 기기에서 시작되었음을 암호학적으로 증명하여 Corbado가 그에 따라
인증 신뢰 수준을 높일 수 있게 합니다.
- **동기화된 패스키의 모호성 해결:** 동기화된 패스키는 편리하지만 신뢰 간격을 만듭니다.
사용자가 동기화된 패스키로 인증할 때 평소 사용하는 노트북인지 자격 증명을 방금 동기화한
완전히 새로운 기기인지 알 수 없습니다. DBSC는 이 간격을 좁힙니다. 기기에 확립된 DBSC
바인딩이 있는지 확인함으로써 Corbado는 기기가 단지 처음 동기화된 것이 아니라 정말로
알려져 있고 신뢰할 수 있는지 검증할 수 있습니다.
- **알려진 기기에 대한 더 높은 신뢰:** DBSC 신호가 기기가 이전에 확인되었음을 확인하면
Corbado는 보다 확실한 위험 결정을 내릴 수 있습니다. 인증된 재방문 사용자에게는 더 적은
스텝업(step-up) 인증 프롬프트를 요구하고, 인식할 수 없는 기기에서 들어오는 세션에
대해서는 더 엄격한 조사를 실시합니다.
- **패스키 인텔리전스 보완:** DBSC 신호는 Corbado의 기존
[**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
엔진과 통합됩니다. 패스키 기반 인증과 DBSC 기반 기기 바인딩의 결합은 로그인부터 전체
세션 수명 주기에 걸쳐 완벽한 신뢰의 사슬을 만듭니다.
Corbado가 DBSC를 플랫폼에 어떻게 통합할 계획인지에 대한 질문은
[팀에 문의해 주세요](https://www.corbado.com/contact).
### 10.3 우아한 대체(Graceful Fallback) (하이브리드 현실)
향후 몇 년 동안 웹은 하이브리드 형태가 될 것입니다. 일부 사용자는 DBSC를 지원하는
브라우저(Windows 11의 Chrome)를 사용하고, 다른 사용자는 구형 시스템을 사용할 것입니다.
이러한 단편화를 처리하는 것은 어렵습니다. Corbado의
[**Passkey Intelligence**](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
엔진은 바로 이러한 종류의 대체(fallback) 로직을 처리하도록 설계되어 지원 기기에는
패스키를, 그 외 기기에는 대체 수단을 제공합니다. 세션 바인딩에도 동일한 인텔리전스가
적용되어 기기의 기능에 따라 모든 사용자의 보안이 극대화되도록 보장합니다.
## 11. 결론: DBSC를 향한 경로
"무기명 토큰(Bearer Token)"의 시대는 저물어가고 있습니다. 무기명 토큰은 산업적 규모의
맬웨어 운영 조직에 의해 탈취될 수 있으며 어떤 기기에서든 사용되어 가장 강력한 인증
방식마저 우회하는 계정 탈취를 가능하게 하므로 현재의 세션 관리는 처참하게 실패하고
있습니다. 이 근본적인 취약점은 수십억 달러 규모의 지하 경제를 창출했습니다.
기기 바인딩 세션 자격 증명(DBSC)은 업계에서 새롭게 부상하는 해답을 제시합니다. HttpOnly
플래그와 정적 암호를 지닌 전통적인 보안 쿠키와 달리, DBSC는 기기 바인딩 키를 통한 암호화된
소유 증명을 추가합니다. 이는 도난당한 쿠키의 가치를 크게 떨어뜨립니다. 탈취된 쿠키는 다른
기기에서 새로 고칠 수 없습니다. 토큰 바인딩이 모든 인프라에 걸쳐 복잡한 TLS 계층 변경을
요구하여 실패했던 반면, DBSC는 HTTP 애플리케이션 계층에서 작동하며 기존 로드 밸런서 및 CDN
아키텍처와 호환됨으로써 성공합니다. 참고: DBSC는 브라우저가 바인딩을 건너뛰는(TPM 사용
불가, 네트워크 오류 등) 문서화된 대체 경로(fallback path)를 가지고 있으므로 쿠키 탈취
위험을 크게 줄여주지만 완전히 제거하지는 못합니다.
DBSC와 패스키의 시너지는 사용자 여정 전반에 걸쳐 공격자에 대한 방어벽을 크게 높입니다.
패스키는 로그인 시의 자격 증명 피싱을 제거하고, DBSC는 원격 쿠키 탈취를 통한 세션
하이재킹을 훨씬 어렵게 만듭니다. 이 둘은 합쳐져 FIDO 얼라이언스가 구상하는 "높은 보증(high
assurance)"의 ID 프레임워크를 형성합니다.
[Chrome 146이 2026년 4월 Windows에서 DBSC를 GA로 제공](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/)하고
macOS Secure Enclave 지원이 다음으로 상륙함에 따라 표준은 준비 단계를 넘어 롤아웃 단계로
진입했습니다. Google의 공개 로드맵(페더레이션 ID, mTLS / 하드웨어 키 등록, 소프트웨어 기반
키)은 향후 12개월 간의 확장을 예고합니다.
제품 관리자에게 비즈니스 사례는 설득력이 있습니다. DBSC는 끝없는 로그인 마찰을 대폭
줄이면서 사기 손실 및 지원 비용을 동시에 절감하는 "무한한" 보안 세션을 가능하게 합니다.
ROI는 더 높은 전환율, 더 적은 비밀번호 재설정 티켓, 그리고 근절된 계정 탈취 사고로
나타납니다. OAuth를 사용하는 조직은 API 토큰에 대한 DPoP를 통해 동일한 키 바인딩 개념을
활용할 수 있으며, 공유 신호(CAEP/RISC)와의 통합으로 실시간 위협 대응이 가능해져 침해된
세션을 다음 새로 고침 시도에서 즉시 취소할 수 있습니다.
구현하기 위해 처음부터 다시 구축할 필요는 없습니다.
[Corbado](https://www.corbado.com/features)와 같은 플랫폼은 패스키 인프라를 제공하며
브라우저 지원이 성숙해짐에 따라 기기 바인딩을 통합하기 위해 DBSC의 발전을 추적하고
있습니다. [W3C 사양](https://www.w3.org/TR/dbsc/)은 활발한 작업 초안 상태이며, Chrome
146은 Windows에서 GA이며 macOS로 출시될 예정이고 기타 브라우저는 여전히 이 표준을 평가
중입니다.
조직이 패스키와 DBSC를 오늘 도입하기 시작한다면 비밀번호가 없고 피싱 저항성을 갖춘 미래에
가장 잘 대비하게 될 것이라는 궤적은 분명합니다. 문제는 기기 바인딩 세션을 구현할지 여부가
아니라, 사용자 및 비즈니스를 보호하기 위해 이를 얼마나 빨리 배포할 수 있느냐입니다. 웹
보안의 미래는 단지 인증되는 것을 넘어, 우리가 신뢰하는 기기에 암호화로 바인딩되는
것입니다.
## 자주 묻는 질문(FAQ)
### DBSC는 침해된 세션을 실시간으로 취소하기 위해 CAEP 및 RISC와 어떻게 연동되나요?
CrowdStrike와 같은 엔드포인트 보안 도구가 맬웨어를 탐지하면, ID 공급자에게 RISC 신호를
전송하고, ID 공급자는 연결된 앱에 CAEP '기기 침해(Device Compromised)' 이벤트를
푸시합니다. 다음 DBSC 새로 고침 시도(몇 분 이내) 시 해당 앱은 세션 서명을 거부하고
액세스를 종료합니다. 교차 벤더 간의 CAEP/RISC 배포는 아직 성숙해지는 단계입니다.
### 웹 애플리케이션 세션을 보호하는 데 있어 DBSC와 DPoP의 차이점은 무엇인가요?
DPoP(RFC 9449)는 애플리케이션 계층에서 OAuth 액세스 및 새로 고침 토큰을 공개 키에
바인딩하여, 주로 네이티브 앱과 SPA의 API 호출을 보호합니다. DBSC는 브라우저 세션 쿠키를
JavaScript로 읽거나 내보낼 수 없는 하드웨어 기반 TPM 키에 바인딩하여, 웹 앱 자체가 XSS나
맬웨어에 의해 침해되더라도 사용자 대상 세션을 보호합니다.
### DBSC가 보안 위험을 증가시키지 않으면서 더 긴 세션 기간을 허용하는 이유는 무엇인가요?
기존의 보안 설계는 쿠키가 탈취되어 원격에서 재전송될 경우의 피해를 제한하기 위해 짧은 세션
시간 초과를 의무화합니다. DBSC는 새로 고침 기능을 원본 기기의 개인 키에 바인딩하므로, 다른
기기에서 탈취된 쿠키를 사용하면 암호화 챌린지에 실패하게 됩니다. 원격 재전송 공격이
무력화되기 때문에 세션을 효과적으로 무기한 유지할 수 있습니다.
### 기업이 DBSC를 배포하여 기대할 수 있는 비즈니스 ROI는 무엇인가요?
DBSC는 주요 계정 탈취(Account Takeover) 벡터인 쿠키 탈취를 무력화하여, 직접적으로 사기
손실과 계정 복구 지원 비용을 줄입니다. 안전한 장기 세션은 반복적인 로그인 프롬프트를
제거하여 전자상거래에서 전환율을 높이고 이탈률을 줄입니다. FIDO 얼라이언스는 DBSC를 사용자
마찰을 낮추면서 동시에 보안 수준을 높이는 기술로 정의합니다.