DBSC란 무엇이며 세션을 어떻게 보호하나요?

DBSC는 세션 쿠키를 TPM 칩에 바인딩: 개인 키는 하드웨어에서 생성되어 새로고침 시 챌린지를 서명합니다. 원본 디바이스 없이는 도난 토큰 무용지물.

DBSC를 위해 프론트엔드를 변경해야 하나요?

아니요, 브라우저가 모든 암호화를 처리합니다. 백엔드에 공개 키 검증과 함께 /register 및 /refresh 엔드포인트를 추가하세요.

DBSC가 Windows 외 다른 플랫폼을 지원하나요?

macOS — 향후 릴리스에서 Secure Enclave를 통해. Linux 미지원, 모바일 플랫폼은 미정.

Chrome 146의 DBSC: TPM 세션 보호

크롬 146, 보안 강화를 위한 TPM 기반 세션 인증(DBSC) 도입

윈도우용 크롬 146부터 디바이스 바운드 세션 자격 증명(DBSC)을 지원합니다. 이 프로토콜은 탈취된 세션 쿠키가 비인가 장치에서 사용 불가능하도록 만듭니다. 세션의 개인 키는 TPM 칩 내부에 안전하게 저장되며, 절대 외부로 나가지 않으며, 토큰 갱신을 위해서는 하드웨어 기반 서명이 필요합니다. 이는 소프트웨어 중심 솔루션의 한계를 극복하고, 인증 보안의 본질적인 전환을 이룹니다.

DBSC 작동 원리: 키 생성부터 갱신까지

DBSC는 루마C2나 비다르와 같은 피싱 공격으로부터 메모리에서 쿠키를 탈취하는 위협을 해결합니다. 장기 유효 토큰 대신 서버는 단기 유효 토큰을 발급하며, 이 토큰은 TPM에 저장된 개인 키의 소유권을 암호학적으로 입증한 후에만 갱신됩니다.

작동 방식은 다음과 같습니다:

세션 등록: 크롬이 TPM에서 키 쌍을 요청합니다. 개인 키는 칩 내부에 유지되고, 공개 키는 서버에 전송됩니다.
초기 쿠키: 서버는 공개 키를 저장하고 단기 유효 토큰을 발급합니다.
갱신: 쿠키 만료 시 브라우저는 도전 과제를 수신하고, TPM을 통해 개인 키로 서명한 후 서명을 다시 전송합니다.
검증: 서버는 공개 키를 사용해 서명을 검증하고 새로운 토큰을 발급하여 세션을 연장합니다.

핵심 트레이드오프는 세션이 디바이스에 묶여 있다는 점입니다. 원래 TPM 없이는 복사된 쿠키도 사용할 수 없습니다. 구글은 오크타와 함께 테스트했으며, 세션 탈취 사례가 크게 감소했지만 구체적인 수치는 공개하지 않았습니다.

하드웨어 보안의 장점:

크롬이나 악성코드조차 개인 키에 접근할 수 없습니다.
세션별 고유 키로 사이트 간 추적을 방지합니다.
DBSC를 지원하지 않는 브라우저에 대한 유연한 백업 기능 제공합니다.

앱 바운드 암호화의 교훈: 왜 TPM이 승리하는가?

구글은 크롬 127에서 앱 바운드 암호화를 시도했으나, 윈도우 시스템 서비스를 이용해 쿠키를 암호화했습니다. 그러나 악성코드는 단 두 달 만에 이를 우회했습니다. 메두자스틸러, 루마C2, 라다만티스는 시스템 권한 없이 역공학을 통해 이를 해독했습니다.

DBSC는 로직을 하드웨어로 이전합니다:

| 항목 | 앱 바운드 암호화 | DBSC |

|------|------------------|------|

| 키 저장소 | 윈도우 메모리 | TPM 칩 |

| 악성코드 접근 가능성 | 소프트웨어 공격 가능 | 물리적 접근 필요 |

| 우회 소요 시간 | 2개월 | 하드웨어 없이 불가능 |

| 개인정보 보호 | 디바이스 ID 노출 가능성 | 공개 키만 공유 |

이것은 단순한 가시성 조작이 아니라 신뢰의 근원을 전환하는 것입니다. 윈도우 11에서 필수 요구사항인 TPM 2.0은 내보내기 불가능한 키를 제공해 진정한 하드웨어 기반 보안 솔루션을 실현합니다.

백엔드 구현: 최소한의 변경만 필요

프론트엔드는 그대로 유지됩니다. 크롬이 암호화를 자동으로 처리합니다. 단지 두 개의 엔드포인트만 추가하면 됩니다.

/register-session: 공개 키(웹크립토 형식)를 수신하고 세션과 연결합니다.
/refresh-session: 도전 과제를 발행하고 서명을 검증하며 쿠키를 회전합니다.

구현 로직:

쿠키의 TTL을 짧게 설정 (예: 5~15분).
갱신 시: 난수 생성, ECDSA 서명 검증.
백업: DBSC 미지원 시 기존 쿠키 방식으로 전환.

예시 의사코드 (Node.js/Express):

const crypto = require('crypto');

app.post('/register-session', (req, res) => {
  const publicKey = req.body.publicKey; // JWK
  session.publicKey = publicKey;
  res.cookie('session', shortToken, { httpOnly: true, secure: true });
});

app.post('/refresh-session', (req, res) => {
  const { challenge, signature } = req.body;
  const isValid = crypto.verify(session.publicKey, Buffer.from(challenge), signature);
  if (isValid) {
    res.cookie('session', newShortToken, { httpOnly: true, secure: true });
  } else {
    res.status(401).end();
  }
});

W3C 사양은 오픈소스이며, 구글과 마이크로소프트 공동 개발 중입니다. 엣지 브라우저는 이를 채택할 예정이며, 파이어폭스와 사파리는 아직 불확실합니다.

플랫폼 제약과 미래 전망

윈도우: 크롬 146부터 TPM 2.0 지원 완료.
macOS: 향후 버전에서 세이프 엔클레이브 기대.
리눅스: 아직 표준 TPM 대체품 없음.
모바일: 안드로이드 스트롱박스 가능; 아이폰은 사파리 지원 여부에 따라 달라짐.

TPM이 고장 나면 (예: 하드웨어 교체), 사용자는 재로그인 후 새 키 쌍을 생성해야 합니다. 하드웨어 TPM이 없는 가상 데스크톱 환경(VDI)에는 적합하지 않습니다.

핵심 요약:

DBSC는 정보 탈취범의 사업 모델을 무력화합니다: TPM 없이 탈취된 쿠키는 무용지물입니다.
2단계 인증을 대체하는 것이 아니라, 로그인 후 세션을 보호함으로써 보완합니다.
백엔드 변경은 최소: 단 두 개의 엔드포인트와 TTL 로직만 필요합니다.
하드웨어 바인딩으로 다중 디바이스 오남용을 방지합니다.
오픈 W3C 표준으로 확산 가능성 높음.

중급 이상 엔지니어에게: 인증 관리, 금융 서비스 등 고가치 서비스에 적용하세요. 백업 경로와 특수 케이스(예: TPM 미지원)를 반드시 테스트하세요.

— Editorial Team

Chrome 146의 DBSC: TPM 세션 보호