Intro

• 웹 인증에서 패스워드는 큰 위협
• 보안성, 개인정보, 편의성 측면 때문에 계속해서 사용되어 왔음
  - 그러면서 SSO를 이용해 편의성을 높이거나 브라우저 메타데이터를 활용하여 의심스러운 로그인을 감지하는 기법들 등장
• FIDO2표준(패스키: 패스워드리스)의 도입으로 생체정보나 PIN을 통해 공개키 기반 인증이 가능해짐
  - 그러나 이로인해 접근권한 상실 가능성 증대
• 클라우드 저장소, 이메일 서비스에 E2EE 도입중
  - 데이터 보안은 강화되지만 복구성 측면에서 클라이언트의 부담 증대(트레이드 오프)

• 해당 논문에서 수행한 일

1. 현대 웹 인증 및 복구 메커니즘을 체계화하고, 특히 E2EE 기반 인증의 보안·프라이버시·사용성·복구 가능성을 분석
2. 2024년 기준 미국 내 인기 웹사이트에서의 패스워드리스 인증 도입 현황을 조사하고, E2EE 클라우드/이메일/메신저 서비스들의 인증 및 복구 방식을 심층 분석
   • 특히 복구 메커니즘의 보안이 종종 취약점이 되는 점을 지적하며, 사용자가 직접 복구 키를 저장해야 하는 방식이 오히려 E2EE의 채택을 저해할 수 있음을 강조
   • 신뢰할 수 있는 연락처 인증(trusted contacts) 등 일부 오래된 인증 방식이 E2EE 복구에서는 재조명될 필요가 있음을 제안

웹 인증 및 복구의 현황

• 우리는 현대의 인증 방식을 사용되는 맥락에 따라 크게 두 가지 범주로 나눈다:
  1. 기본(primary) 인증 방식
  2. 보조(secondary) 인증 방식

  기본 인증 메커니즘은 신원 확인을 위한 첫 번째이자 (종종 유일한) 단계로 사용
  반면, 보조 인증 메커니즘은 기본 인증이 성공적으로 완료된 후에만 작동되는 방식

주요 인증 메커니즘

1) 비밀번호

• 비밀번호의 보안성과 사용성 문제는 너무나 많음

• 수십 년간의 학술 연구 결과에 따르면,
  1. 사용자는 비밀번호를 자주 잊어버리고,
  2. 쉽게 추측 가능한 비밀번호를 사용하며,
  3. 여러 계정에서 같은 비밀번호를 재사용하는 경향이 있고,
  4. 비밀번호가 유출되거나 재사용되었다는 알림을 받아도 비밀번호를 바꾸지 않는 경우가 많음

• 하지만 오늘날의 위협 환경에서는,비밀번호 강도를 높이더라도 피싱 공격, 대규모 데이터 유출로부터 사용자를 충분히 보호할 수 없음

• 최근 사용자의 자격증명이 유출되었는지 확인할 수 있는 DB가 존재하고, 업계에서는 암호 기반 자동 알림 시스템도 도입 중

• 예를 들어, Meta의 Private Data Lookup(PDL) 도구는 Private Set Intersection(사적인 교집합 계산)을 통해 사용자의 비밀번호가 유출된 비밀번호 목록에 포함되어 있는지 서버 측에서 확인해줌
• 그러나,학계에서는 이러한 알림의 실질적인 효과가 제한적이라는 점을 여러 차례 입증함
  • 경고를 받은 사용자 중 실제로 비밀번호를 바꾸는 비율은 약 25% 정도에 불과함

이처럼, 비밀번호 기반 인증은 보안성과 사용성 사이의 근본적인 긴장을 피할 수 없기 때문에, 점점 더 많은 전문가들이 비밀번호를 "레거시 인증 메커니즘", 즉 시대에 뒤떨어진 방식으로 간주 중임

비밀번호 관리자(Password Manager)

• 많은 자격 증명 정보를 보다 쉽게 관리할 수 있도록 돕기 위한 대응 전략 중 하나는, 사용자에게 비밀번호 관리자(Password Manager)사용을 권장하는 것

• 기술 커뮤니티에서는 비밀번호 관리자를 보안상 이유로 선호하는데, 이를 사용하면 고복잡도(높은 엔트로피)의 비밀번호를 쉽게 사용할 수 있고, 모든 자격 증명을 기억할 필요가 없어지기 때문

• 그러나 학술 연구에서는, 사용자가 비밀번호 관리자를 사용하는 주된 이유는 보안이 아니라 편의성이라는 점이 밝혀짐

• 심지어 일부 사용자들은, 민감한 계정의 자격 증명은 비밀번호 관리자에 저장하지 않고, 덜 민감한 계정에만 활용하는 경향을 보임
• 또한 비밀번호 관리자에 접근해야하는 마스터키는 기억해야함

실제로는, 사용자들은 비밀번호 관리자의 보안 기능을 최대한 활용하지 않고,자동 완성용으로 단순하고 약한(low-entropy) 비밀번호만 저장하는 데 그치는 경우가 많음 -> "보안성" 보다 "편의성" 용도로 씀

SSO(Single Sign On)

• 싱글 사인온(SSO)은 연합 로그인(federated login) 기술로, OAuth와 OpenID Connect 같은 접근 위임 프로토콜을 통해, 사용자 인증 책임을 하나의 주요 제공자(예: Google, Apple)에 중앙 집중시키는 방식

• 하지만 SSO의 도입은 다음과 같은 이유들로 인해 제한적이었음
  1. 개인정보 보호에 대한 우려: 사용자 인증 시 빅테크 기업과 데이터가 공유된다는 점에 대한 합리적인 우려
  2. 기술에 대한 신뢰 부족: 근본 기술에 대한 불신으로 인해 도입을 꺼리는 사례들

• 실제로 과거 연구에서는 민감한 계정일수록 SSO를 사용하지 않는 경향이 있다는 점도 확인

• 보안 측면에서도,SSO의 기반 프로토콜 자체에 존재하는 보안 취약점, 서비스 구현 과정에서 발생하는 취약점이 학술 연구에서 많이 보고됨

• 심지어 현실에서는, OAuth 액세스 토큰을 수집하는 허니팟(honeypot) 웹사이트를 운영하는 사이버 범죄 조직들도 발견된 바 있음

• 이러한 개별적인 보안/프라이버시 문제 외에도,SSO 방식은 구조적으로 단일 실패 지점(Single Point of Failure)을 가지기 때문에,공격자에게 매우 매력적인 목표가 되기도 함

• 단일 실패 지점(Single Point of Failure, SPOF):
  시스템 구성 요소 중 하나라도 실패하면 전체 시스템이 작동을 멈추게 되는 구조적인 약점

2)Device-Bound Credentials

• 하드웨어 토큰과 스마트폰 내 보안 하드웨어 칩의 보급이 늘어남에 따라, 단 하나의 강력한 하드웨어 기반 요소(사용자의 스마트폰)만으로도 인증이 가능해짐
  -> 이를 통해 서비스 제공자들은 일상적인 인증 절차에서 비밀번호를 완전히 제거 가능해짐

• 장치 결합 자격 증명은 공개키 암호화 방식을 사용

• 스마트폰의 보안 하드웨어 모듈이 각 웹 계정마다 고유한 키쌍을 생성하고, 개인키(private key)는 하드웨어 모듈에 안전하게 저장하며, 공개키(public key)는 웹 서버에 전달합니다. 웹 서비스에 로그인할 때 사용자는 지문·PIN·패턴 등 평소 사용하는 디바이스 잠금 해제 수단으로만 로컬 디바이스 인증을 거치면 되므로, 이 방식을 흔히 ‘패스워드리스(passwordless)’ 인증이라고 함

• 장치 결합 자격 증명의 주된 이점은 피싱 공격 및 대규모 계정 탈취 위험을 크게 줄인다는 점

• 각 계정마다 고유한 키쌍이 생성되므로, 인증 과정에서 디바이스는 해당 개인키를 사용해 서버가 보낸 챌린지(challenge)에 서명하고, 이를 통해 본인 소유임을 증명함.

• 또한, 인증기는 원래 등록된 웹 서비스에만 반응하도록 설계되어 있어, 악성 사이트의 인증 요청에는 서명하지 않습니다.

• 반면, 단점은 자격 증명의 보안이 곧 디바이스 보안에 달려 있다는 것임.

• 디바이스가 탈취·침해되면 모든 서비스에 대한 접근 권한이 위험해질 수 있음.

• 이를 방지하기 위해 스마트폰 제조사들은 패스키 사용 시마다 생체 인증을 요구하거나, 디바이스 잠금 해제 시도를 일정 횟수 이상 실패하면 잠금 속도를 늦추는 등 다양한 보안 조치를 도입하고 있지만, 구체적인 보호 수준은 플랫폼과 사용자 설정에 따라 달라짐.

• FIDO2 자격 증명이 처음부터 장치 결합 전용으로 설계되었기 때문에, 디바이스 분실 시 복구 방안은 여전히 큰 문제.

• 패스키(passkey)는 여러 디바이스 간 동기화가 가능하지만, 모든 디바이스를 잃어버리면 모든 패스키도 함께 사라짐 -> 이거를 클라우드로 커버침

• 디바이스는 자주 분실·훼손·업그레이드로 교체되며, 여행 중 노트북을 놓고 왔거나 단 한 대의 FIDO 호환 기기만 소지하고 있을 수도 있음.

  이 복구 문제를 해결하기 위한 업계의 합의는 "패스키"

패스키

• Passkeys(패스키): FIDO2 기반의 패스워드리스 인증 방식을
• 사용 편의성을 높이고 패스키 분실 위험을 줄이기 위해, 주요 운영체제 제공업체들은 패스워드리스 자격 증명을 각자의 클라우드 백업 서비스에 자동 동기화하도록 구현
• 클라우드 백업 복구 절차는 Apple과 Google 모두 비슷한데, 먼저 클라우드 서비스(예: Google 계정 또는 iCloud)에 로그인한 뒤, 스마트폰의 잠금 해제 코드를 입력해 자격 증명 백업에 접근
• 이처럼 클라우드 동기화는 사용자가 복구 가능성을 기대하는 데 필수적이지만, 동시에 패스키의 실제 보안 수준을 클라우드 계정(및 백엔드 HSM 보안)에 종속시킴
• 운영체제의 패스키 인증 프로세스 외에도, FIDO2 표준은 사용자가 FIDO2 패스키로 인증을 완료한 이후에 도메인이 추가적인 인증 단계를 구현할 수 있도록 허용
  ex> 웹 서비스와 클라이언트는 선택적인 WebAuthn 확장 기능을 사용하여 추가적인 디바이스 바인딩 키(device-bound key)를 인증 과정에 포함시킬 수 있음 -> 이를 통해 웹 서비스는 예를 들어 사용자가 새로운 기기에서 로그인하는지 감지 가능
• 또한 FIDO2는 디바이스 간 인증(cross-device authentication)도 지원함.
  ex> 패스키를 지원하지 않는 노트북 같은 새로운 기기에서의 인증 시도는 유효한 패스키를 보유한 다른 디바이스로 블루투스를 통해 전달(tunneled)되며, 이때 Client to Authenticator Protocol(CTAP)이 사용

패스키 인증 흐름(Challenge Response with 서명)

1. 등록(Enrollment)

• 디바이스(스마트폰 등)의 SE/TEE에서 웹사이트별 공개·개인키 쌍 생성
• 개인키(패스키)는 디바이스 보안 저장소에만 보관, 공개키는 서버에 전송·등록

2. 로그인 요청 & 챌린지

• 클라이언트가 로그인 시도 → 서버가 논스(nonce) 챌린지를 생성해 전송

3. 사용자 인증 및 서명

• 디바이스 잠금 해제(PIN·생체 등) → 개인키로 챌린지 서명

4. 검증 & 로그인

• 서버가 등록된 공개키로 서명 검증 → 일치하면 로그인 성공

패스키 복구 흐름(E2EE)

1. 새 기기에서 복구 시작

• FIDO2/WebAuthn 지원 기기 준비 → iCloud/Google 계정 로그인(2FA 포함)

2. 클라우드 HSM 언랩(unwrap)

• 클라우드 HSM 안에 저장된 “백업용 대칭키”로 암호화된 개인키 데이터 언랩

3. 재래핑(Re-envelope) & 전송

• HSM이 복호화된 개인키를 선택된 기기의 퍼블릭 래핑 키로 즉시 재암호화(envelope)
• 래핑된 암호문만 TLS 채널로 새 기기 SE/TEE에 전달
• 퍼블릭 래핑키(HSM <-> 디바이스 TEE)간 E2EE 통신에 사용됨

4. 디바이스 언랩 & 저장

• 새 기기는 TEE/SE에 있는 프라이빗 래핑 키로만 암호문을 풀어 개인키를 안전 보관

5. 복구 완료

• 복원된 개인키로 웹사이트에 인증 시도 → 정상 작동 확인

패스키(passkey) 채택을 방해하는 잔존 문제

1. 자격 증명 공유(Credential Sharing)

   자격 증명 공유가 가장 빈번하게 발생하는 직장 환경에서는, 원격 근무의 확산으로 인해 사용자가 물리적으로 가까이 있지 않은 경우가 많아, 패스워드처럼 간단하게 문자나 메신저로 공유할 수 있는 방식이 여전히 유리하게 느껴짐

2. 자격 증명 철회(Credential Revocation)

   FIDO2 표준은 자격 증명의 전역 철회(global revocation) 문제를 적절히 다루지 못하고 있음
   현재 표준은 웹 서비스가 사용자에게 특정 인증기의 공개키를 서버에서 제거하는 방식으로 접근 권한을 철회하는 기능을 제공하도록 요구하고 있지만, 이는 사용자가 각 웹사이트마다 개별적으로 수행해야 하는 불편함이 있음

3. 자격 증명 접근성(Credential Availability)

   패스키(passkey)는 보통 기기의 보안 저장소(secure element)에 저장되고, 기기 자체를 통해 인증하기에 그 기기를 가진 사람은 인증된 사용자처럼 행동할 수 있음
   예를 들어 친구한테 사진 보여주려고 핸드폰을 넘겼는데, 그 친구가 다른 앱으로 들어가서 내 계정이나 메일을 본다거나, 로그인 상태인 웹사이트를 들어가서 뭘 본다거나 하는 일이 생길 수 있음

3) Social Authentication (사회적 인증)

• 사회적 인증 및 복구(social authentication and recovery)는 계정 소유자가 하나 이상의 복구 연락처(또는 ‘신뢰인(trustee)’)를 지정하여, 이들이 계정 접근 권한을 회복하는 데 도움을 주는 방식
• 이 방식은 모든 기기와 비밀번호를 분실하거나 기억하지 못하는 등의 현실적인 재난 상황을 확실하게 처리할 수 있는 유일한 복구 시나리오
• 이 개념은 2006년 RSA의 Brainard 등[53]이 처음 제안했으며, 현실의 신뢰 관계를 활용해 다른 사람이 사용자를 대신해 신원을 보증(vouch)하는 방식
• 당시 Brainard 등은 기업의 비밀번호 재설정 인력에 드는 재정적 비용을 줄이는 방법으로 이 개념을 제시했지만, 오늘날에는 수동 복구 과정에서 사용자의 신원을 확인하는 것이 어렵고, 또한 종단 간 암호화(E2EE) 서비스처럼 서비스 제공자가 사용자를 재인증할 수 없는 경우도 있기 때문에, 사회적 복구는 매우 중요한 대안으로 부각

단일복구연락처(Single Recovery Contact)

• 가장 단순한 형태의 사회적 복구 방식은 하나의 복구 연락처(보통은 가까운 지인)를 지정하는 것
• 예를 들어, Apple이 2022년에 도입한 iCloud 백업 복구 시스템은 이 아이디어를 반영
• Apple의 복구 방식에서는 복구 연락처가 되는 다른 iCloud 사용자가 짧은 코드를 생성해 원래 사용자(Alice)에게 전송함으로써 계정 복구를 가능하게 함