과열된 Passkeys가 보안 키를 쓸모없게 만드는 방식

 (fy.blackhats.net.au)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Passkeys를 resident key로 정의해 요구하는 흐름이 퍼지면, Yubikey·Feitian·Nitrokey 같은 보안 키는 제한된 저장 공간 때문에 빠르게 한계에 부딪힘
  • non-resident credential은 Relying Party가 제공한 credential ID를 보안 키가 복호화해 RP별 개인키를 얻는 구조라, 기기 내부에는 master key만 저장됨
  • 반대로 resident/discoverable credential은 개인키 자체를 보안 키에 저장하므로 계정마다 슬롯을 쓰며, Nitrokey는 8개, Yubikey는 보통 20~32개 수준만 지원함
  • CTAP2.0 보안 키는 resident key를 개별 삭제할 수 없어 전체 초기화가 필요하고, 이때 master key도 바뀌어 기존 non-resident key까지 작동하지 않게 됨
  • 서비스와 라이브러리가 resident key를 기본 요구하면 150개 이상 계정을 쓰는 사용자는 여러 보안 키와 백업 키를 관리해야 해, 원하는 인증기를 자유롭게 선택하기 어려워짐

resident key가 문제의 중심인 이유

  • Passkeys에 대한 과열된 기대가 보안 키를 구식 장치처럼 만들 수 있다는 우려의 핵심은 resident key에 있음
  • 보안 키가 계정 수를 “무제한”처럼 지원한다는 인식은 많은 경우 non-resident credential 방식에 기대고 있음
  • resident key는 보안 키 내부 저장 공간을 실제로 소비하므로, 계정 수가 늘어날수록 기기 한계가 곧바로 드러남

non-resident credential의 동작 방식

  • non-resident credential에서는 Relying Party가 인증 시 credential ID를 브라우저를 통해 보안 키에 전달함
  • credential ID는 보안 키만 복호화할 수 있는 암호화된 blob이며, 복호화 결과는 해당 Relying Party 전용 개인키임
  • 보안 키는 복호화한 개인키로 challenge에 서명하고, 서명을 브라우저와 Relying Party에 반환함
  • 이 구조에서는 개인키가 보안 enclave 안에 상주하지 않고, 보안 키 내부에는 master key만 있음
  • credential ID는 AES-128로 암호화되고 HMAC이 적용되어 외부에서 변조하거나 복호화하기 어렵다고 평가됨
    • AES-128이 깨져 보안 키 없이 개인키를 복호화할 수 있다면 TLS 암호화나 SSH도 공격 가능한 수준이라는 비교가 나옴

resident/discoverable credential의 차이

  • resident key 또는 discoverable credential은 개인키가 보안 키 내부에 저장되는 방식임
  • Relying Party가 빈 credential ID 목록을 보내면, 보안 키가 해당 RP에 사용할 수 있는 키를 찾고 선택한 뒤 서명함
  • 이 구조는 외부에서 credential ID를 받아 master key로 복호화하는 방식에 의존하지 않음
  • 대신 각 credential이 보안 키 내부 공간을 차지하므로, resident key 슬롯 수가 실질적인 계정 수 제한이 됨

userVerification은 resident key와 별개

  • credential이 userVerification을 강제하려면 반드시 resident여야 한다는 혼동이 있지만, 두 개념은 분리되어 있음
  • 보안 키는 터치로 presence를 확인할 뿐 아니라, 내부에서 PIN이나 생체 인식을 검증해 실제 사용자인지 확인할 수 있음
  • 이 동작은 userVerification flag로 제어되며, key residency와 별개로 동작함
  • 따라서 resident key가 아니어도 기기는 자체적으로 다중 인증기처럼 쓸 수 있음

보안 키의 저장 공간과 CTAP 제약

  • resident key는 기기 내부에 저장되므로 보안 키의 슬롯 수가 중요함
    • Nitrokey는 resident key 8개를 지원함
    • Yubikey는 일반적으로 20~32개를 지원함
    • 일부 키는 resident key를 전혀 지원하지 않음
  • 보안 키가 구현한 CTAP 표준도 관리 가능성을 크게 좌우함
    • CTAP2.1과 CTAP2.1PRE는 resident key를 개별 관리, 업데이트, 삭제할 수 있음
    • CTAP2.0은 resident key를 삭제하려면 전체 기기 초기화가 필요함
  • CTAP2.0 기기 초기화는 master key도 함께 초기화하므로, 기존 non-resident key까지 더 이상 작동하지 않음
  • 많은 보안 키가 CTAP2.0일 가능성이 높으며, Yubico의 경우 CTAP 버전은 펌웨어 버전에 따라 달라짐

passkeys라는 이름과 resident key 정의의 확산

  • Apple은 2022년 macOS/iOS에서 Touch ID와 Face ID를 WebAuthn authenticator처럼 사용하는 passkeys 기능을 발표함
  • passkeys라는 이름은 “webauthn authenticator”나 “security key”보다 사용자에게 친숙한 명칭으로 평가됨
  • 이후 passkeys의 의미가 명확히 고정되지 않은 상태에서 여러 해석이 등장함
    • Rust WebAuthn 라이브러리와 Relying Party 구현자는 passkeys를 사용자가 선택할 수 있는 모든 authenticator의 이름으로 정의함
    • 일부 커뮤니티 구성원은 passkeys를 여러 기기 사이에 동기화되는 credential로 불렀음
    • FIDO Authenticate 콘퍼런스에서 “passkey는 resident key”라는 정의가 등장했고, 이후 FIDO도 FAQ에서 이 정의를 사용함
  • resident key 정의가 주목받는 이유 중 하나는 브라우저의 예정 기능인 conditional UI와 연결되어 있기 때문임
    • credential이 resident key이면 사용자 이름과 WebAuthn credential을 자동완성할 수 있음
    • 사용자가 사용자 이름을 직접 입력하지 않아도 되는 경험을 제공함

resident key 요구가 만드는 사용자 문제

  • WebAuthn 라이브러리가 모든 등록에 resident key를 요구하도록 유도하면, 제한된 저장 공간을 가진 보안 키가 빠르게 가득 찰 수 있음
  • 예를 들어 비밀번호 관리자에 150개 넘는 저장 비밀번호가 있는 경우, 이를 모두 resident key로 바꾸려면 최소 5개의 Yubikey가 필요함
  • 백업까지 고려하면 10~15개의 Yubikey를 관리해야 할 수 있음
  • 이는 보안 키를 선택한 사용자에게 나쁜 사용자 경험이 되며, passkeys의 resident key 요구 때문에 보안 키 사용 자체가 어려워질 수 있음
  • FIDO 인증 키 마케팅에서 “무한 key pair storage”나 “등록 계정 수 제한 없음” 같은 문구가 쓰이지만, 이는 non-resident key에서는 맞아도 resident key 요구와는 충돌함
  • WebAuthn Work Group의 목표 중 하나는 사용자가 원하는 authenticator를 불이익 없이 자유롭게 선택할 수 있게 하는 것이지만, resident key 강제는 이 목표와 맞지 않음
  • passkey 환경에서 제대로 동작할 인증기 유형으로는 Apple passkeys, Android passkeys, WebAuthn을 지원하는 비밀번호 관리자, TPM 2.0을 사용하는 Windows, Touch ID를 TPM처럼 사용하는 macOS의 Chromium 기반 브라우저가 제시됨

가능한 대응 방향

  • rk=preferred 동작을 바꿔 보안 키에는 resident key를 만들지 않게 하는 방안이 있음
    • 현재 Relying Party는 resident key 요청 수준을 discouraged, preferred, required 중 하나로 지정할 수 있음
    • 현재 rk=preferred는 roaming authenticator인 Yubikey에서도 resident key를 만들며, 결과적으로 rk=required와 비슷하게 동작함
    • preferred를 “저장 공간이 무제한일 때만 resident key 생성”으로 완화하면 Android/iOS는 resident key를 만들고, 보안 키 저장 공간은 소비하지 않을 수 있음
    • WebAuthn WG는 아직 이 변경에 저항적이며, 브라우저가 별도로 구현하려면 현실적으로 Chrome 팀 결정에 달려 있음
  • passkey 라이브러리가 rk=discouraged를 사용하도록 요구하는 방법도 있음
    • rk=required는 보안 키를 배제할 수 있음
    • rk=discouraged는 Android 사용자가 conditional UI를 얻지 못하게 만들 수 있음
    • 사용자 이름은 이미 자동완성 수단이 있으므로, 보안 키를 배제하는 것보다 낫다는 판단임
  • FIDO에 resident key 저장 공간을 인증 기능으로 요구하라고 요청하는 방안도 있음
    • 현재 FIDO는 인증 기기에 대해 저장 공간 요구량을 의무화하지 않음
    • FIDO가 resident key를 원한다면 인증 기기가 수천 개 resident key를 저장할 수 있게 해야 한다는 요구임

결론

  • passkeys를 resident key로 보는 과열된 흐름은 보안 키 사용자가 온라인에서 원하는 authenticator를 선택하는 일을 막거나 심하게 어렵게 만들 수 있음
  • 문제는 passkeys 자체보다, 제한된 저장 공간과 관리 기능을 가진 보안 키에 resident key 요구를 일괄 적용하는 데 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 암호화 자체와는 조금 다른 얘기지만, 어머니가 Gmail에 못 들어간다고 패닉 상태로 전화했음. 알고 보니 Google이 새 Android 폰을 패스키로 자동 등록하고, 그걸 기본 로그인 방식으로 바꿔놨는데 인터페이스가 너무 헷갈렸음
    비밀번호로 로그인하려면 두 번째 옵션을 눌러야 한다거나 패스키가 뭔지 이해해야 한다고 기대하는 건 과하다고 봄. “Android로 패스키를 보냈다”고 했지만 폰에는 알림이 오지 않았고, 30분을 봐도 해결 못 했음. 자동 등록된 패스키를 삭제할 수도 없고 기본 인증 흐름을 끌 수도 없었음. Google의 UX가 끔찍하며, 저가형 Samsung 폰의 변형된 Android를 대규모 인증 시스템의 기반으로 신뢰한 게 멍청한 결정처럼 보임

    • Google 2단계 인증에서도 같은 문제가 있음. “S21로 알림을 보냈습니다”라고 하지만, 실제로는 잠금 해제된 S21을 손에 들고 있어도 3번 중 1번은 알림이 안 오거나 5분 뒤에야 도착함
      최근 Google에서 겪은 여러 문제 중 하나일 뿐임. 예전엔 개인정보 때문에 대충 피하려고 했다면, 이제는 Google 사용을 최대한 줄이려고 전력을 다하고 있음. Google Maps에서 아무 이유 없이 비즈니스가 내려가서 다시 등록하는 데 2주가 걸렸고, 사람과 통화하는 건 불가능했음. 지원 이메일마다 전화번호를 주지만 그건 광고 지원 번호라 정지된 비즈니스 계정에는 아무것도 못 하고, Google Business 팀이 그 번호를 지원용으로 준다는 사실조차 믿지 않으려 했음. Google Ads 지원 직원에게 Google Business 관련 사람과 통화할 방법이 없다는 걸 인정받기까지 30분 동안 질문을 반복해야 했음. 이제는 그냥 반Google 전도사가 됐음
    • 원치 않는 “휴대폰으로 알림을 보냈습니다” 확인 요구 때문에 진지하게 내 비즈니스를 Google 생태계에서 빼는 걸 고민 중임. 지구 반대편에서 갑자기 로그인한다거나, 항상 Linux를 쓰다가 브라우저가 Windows로 식별되는 상황이라면 이해하겠지만, 개인정보 보호 중심 브라우저인 ungoogled chromium을 쓰면 같은 IP에서도 인증할 때마다 이 일이 발생함
      폰 배터리가 없으면? 폰을 잃어버려서 위치 서비스 자격 증명을 복구하려고 이메일로 비밀번호 재설정을 보내야 하는데 이메일에 로그인할 수 없으면? 그때부터 “질문에 답하기” 절차가 시작됨. 숨겨진 책임 없는 알고리즘이 Linux의 ungoogled chromium을 수상하다고 판단하고, “현재 사용 가능한 저장공간의 몇 퍼센트를 쓰고 있나?” 같은 질문 답을 잘못 기억하면 접근 복구는 행운에 맡겨야 함. 참고로 유료 Google 사용자임
    • 사소한 정정: 패스키가 Android로 “전송”되는 건 아님. Gmail 로그인은 브라우저에 표시된 QR 코드를 스캔해서 Android에 있는 패스키를 보유하고 있음을 증명하게 하는 방식임
      그래도 요지는 완전히 이해됨. UX도 용어도 헷갈림. 각 단계가 설명을 제공하더라도, 사람들은 특히 급할 때 작은 설명문을 건너뛰고 가장 크고 화려한 버튼을 누르도록 학습돼 있어서 별 도움이 안 됨. UX 설계상 정말 어려운 문제임
    • 이 일을 겪고 선을 넘었음. Google은 사용자 기준으로 의사결정하지 않는다는 사실을 깨닫게 됐음. 광고주에게서 돈을 벌고, 사용자가 떠나지 않을 정도로만 서비스를 제공하며, 경쟁자를 막을 정도로만 유지함
      사용자가 떠나지 않는 한 Google은 신경 쓰지 않고, 신경 쓸 필요도 없음. 다른 걸 원한다면 광고주가 비용을 대지 않는 서비스가 필요함. Google이 사용자를 한 방식으로 착취한다면 Apple은 다른 방식으로 착취할 뿐이고, 독을 고르는 건 선택지가 아님
    • 공정하게 보면 이건 패스키 자체 문제가 아니라 Google의 제품 UX가 멍청한 것에 가깝다. Google이 로그인 UX를 사용자가 익숙하지 않은 방식으로 갑자기 바꾸면 대부분 혼란스러울 수밖에 없음

  • Apple이 실제로 정의하지 않은 탓에, “패스키가 대체 뭔가?”를 알고 싶어 하는 사용자를 위해 사상가들이 빈자리를 채우게 됐음
    Apple은 패스키를 iCloud Keychain으로 동기화되는 키 쌍으로 정의했다고 이해해 왔음. WWDC 2021 발표에서도 패스키는 “항상 가지고 있음”, 즉 기기 동기화와 “복구 가능함” 때문에 보안 키와 다르다고 구분했음. 이후 정의가 다른 클라우드 동기화 방식으로 확장된 것 같음. 이 글은 잘못된 절충을 한다고 봄. 보안 키는 중요하지 않음[1]. 아주 적은 기술 사용자와 보안을 정말 중시하는 소수 회사만 쓰기 때문임. 웹 안전을 높이려면 사람들을 비밀번호에서 벗어나게 해야 하고, 인구의 99%는 강제되지 않는 한 보안 키를 쓰지 않을 것임. 패스키는 특히 운영체제 깊은 통합 덕분에 비밀번호를 대체할 가능성이 큼. 1% 이하 사용자가 상주 키 슬롯이 부족하다고 해서 인증을 그쪽에 맞춰 최적화해서는 안 됨. [1] Yubikey 3개, Yubico 보안 키 3개, SoloKey 1개를 보유 중임

    • 목표는 Apple Passkey 제품이 아니라 업계 차원의 이니셔티브였음. 2022년에 출시될 때쯤에는 정의가 느슨해져서, 예를 들어 발견 가능하고 사용자 검증 선택지를 제공하는 “경험”에 가까워졌음
      사용자는 백업·복구 가능한 패스키 제공자를 쓸지 선택할 수 있고, 신뢰 당사자는 그 신호를 받음. 이 신호를 보고 비밀번호 로그인 옵션 제거를 제안할지 판단할 수도 있음
    • 패스키는 사실 FIDO Alliance가 정의함
      FIDO 표준에 따르면 패스키는 비밀번호를 대체하며, 사용자의 여러 기기에서 웹사이트와 앱에 더 빠르고 쉽고 안전하게 로그인하게 해 줌. 비밀번호와 달리 패스키는 항상 강력하고 피싱에 강함. https://fidoalliance.org/passkeys/

  • rk=required가 왜 존재하는지 모르겠음. 애초에 옵션으로 있어서는 안 됨
    이런 것 때문에 패스키와 그 관련자들을 계속 걱정하고 회의적으로 봐 왔음. 이들은 Microsoft 같은 대기업이 보안과 호환성을 심각하게 망치고 경쟁을 죽이는 온갖 악의적 시장 관행에 쓰기 좋은 도구가 되지 않도록 프로토콜을 설계할 책임이 있음. 그런데 글과 게시물에서 반복적으로 보여 주는 태도는 “엿 먹어라, 남용을 더 쉽게 만들어 주겠다”에 가까움. 상주 키만의 문제가 아니라, 예를 들어 증명(attestation) 처리 방식도 회사들을 죽이는 데 쉽게 악용될 수 있음

    • 여기 목표는 휴대폰을 패스키로 만들고, 그 외에는 아무것도 쓰지 않게 하는 것 같음. 그 관점에서 보면 글에 나온 모든 내용이 말이 됨
    • 이건 증명 남용보다는 덜 나쁘다고 봄
      어떤 서비스가 rk=required를 설정했는데 플랫폼이 이를 켜거나 지원하고 싶지 않거나 불가능하면, 절차가 항상 실패해서 등록조차 못 할 것 같음. 사용자를 온보딩하고 사업을 키우려는 목표라면 스스로 발등을 찍는 선택처럼 보임
    • “증명 처리 방식이 회사들을 쉽게 죽이는 데 악용될 수 있다”는 게 어떤 문제인지 궁금함

  • 보안이나 암호화 쪽 사람은 전혀 아니라서 이 글이 따라가기 매우 어려웠고, 다른 사람들도 그럴 것 같음
    배경지식이 충분한 사람에게는 이상한 질문처럼 보일 수 있지만, 한두 문장마다 막힘. “결국 하나, 상주 키로 귀결된다”는 게 어떻게, 왜 그런지 모르겠고 패스키나 HSM과의 연결도 모르겠음. “발견 가능한/상주 키가 무엇인지 이해해야 한다”는 말은 모든 상주 키가 발견 가능한 키라는 뜻인지, 모든 발견 가능한 키가 상주 키라는 뜻인지, 둘 다인지 애매함. “대부분의 키가 ‘무제한’ 계정을 지원한다는 걸 봤을 것”이라는데, 여기서 키가 패스키인지 HSM에 저장된 키인지 둘 다인지 모르겠음. “키로 감싼 키를 보안 키에 보낸다”는 건 HSM이 무제한 계정에 적용될 수 있는 이유가 어떤 키를 또 다른 키로 감싸 저장할 수 있어서라는 뜻인지도 헷갈림

    • 핵심은 WebAuthn이 각 사이트가 저장공간을 소비하는 자격 증명을 만드는 패스키 모델로 밀리고 있다는 점으로 보임. 표시 가능한 사이트명과 사용자 계정명, 사용자 레코드 핸들, 개인 키, 기타 항목들이 모두 저장공간을 차지함
      휴대폰은 패스키 1만 개도 문제없이 저장할 수 있지만, 최신 하드웨어 키는 사용 가능한 플래시에 총 25개만 저장할 수도 있음. 이 저장공간이 필요한 이유는 발견 가능성임. 예를 들어 GitHub.com 로그인 페이지에서 새 패스키 지원을 누르면 계정명조차 입력하지 않고 로그인할 수 있음. 브라우저가 비밀번호 관리자 같은 경험을 제공하고, 비밀번호 관리자 안의 비밀번호처럼 패스키도 로컬에서 사이트 계정의 레코드가 됨. 하지만 WebAuthn에는 패스키가 아닌 여러 모드도 있음. 발견 불가능한 자격 증명은 특정 사용자 계정에 대해 핸들 목록을 제공해야 하고, 이 핸들은 등록 시 키가 제공했던 것임. 인증 시 핸들과 일치하는 자격 증명만 선택지로 제시됨. 하드웨어 보안 키는 이 점을 활용해 향후 암호 연산에 필요한 레코드를 핸들 자체에 저장하며, 이 모드는 플래시 저장공간을 쓰지 않음. 사용자가 사용자명을 입력하면 어떤 API가 핸들 목록을 반환하고, 이를 보안 키에 적용해 저장공간 제한 없이 인증할 수 있음. 다만 많은 사이트는 계정 존재 여부를 노출하지 않는 정책을 취함. “이 계정이 존재한다면 곧 이메일을 받을 것” 같은 복구 절차를 봐 왔음. 로그인 절차가 사용자명이나 이메일에 연결된 계정이 있는지, 몇 개의 자격 증명이 기록됐는지 감지하는 API를 제공하는 건 사이트 입장에서는 받아들이기 어려울 수 있음. 결국 사이트들이 이 절차를 널리 채택해 현재 하드웨어 한계에 영향을 주기보다는, 저장공간이 10배 많은 보안 키가 나올 가능성이 더 커 보임
    • 글의 논증이 좋지 않다는 데 동의함. 핵심은 WebAuthN 프로토콜에서 신뢰 당사자가 rk=required를 지정할 수 있는 기능이 해롭다는 주장임. 이 때문에 많은 TPM 하드웨어가 패스키 지갑·데이터베이스로 작동하지 못하기 때문임
      댓글의 대부분은 이 점에 동의할 것 같음. 그렇다고 글쓴이가 글 절반을 패스키 정의 논쟁에 쓰며 만든 혼란이 정당화되지는 않음
    • 글은 FIDO2에 대한 지식을 꽤 많이 전제로 하고 있어서 혼란스러운 게 당연함
      패스키는 FIDO2 위에서 구현되며, 특히 FIDO2 사양의 상주 키 기능을 활용함. FIDO2 하드웨어 인증 장치는 정확히 HSM은 아니지만 비슷하고, Yubikey처럼 HSM이면서 FIDO2 인증 장치인 기기도 있음. FIDO2에서 “상주 키”와 “발견 가능한 키”는 동의어임. 사양에서는 “상주 키”를 쓰지만 “발견 가능한 키”도 흔히 쓰이며, FIDO가 만든 혼란스러운 용어 중 하나임. “키”는 패스키나 HSM에 저장된 키가 아니라 Yubikey 같은 FIDO2 하드웨어 인증 장치를 가리키며, 흔히 “보안 키”라고 부름. FIDO2 하드웨어 인증 장치는 상주 키를 쓰지 않는 한 사실상 상태가 없어 아무것도 저장하지 않기 때문에 무제한 계정에 등록될 수 있음. 계정에 등록될 때 장치에서 EdDSA 같은 키 쌍을 생성하지만 저장하지 않고, 개인 키를 내장 마스터 키, 예를 들어 AES256 키로 암호화함. 그런 다음 평문 공개 키와 암호화된 개인 키를 google.com 같은 신뢰 당사자에게 보내 저장하게 함. 인증 시 암호화된 개인 키, 즉 “감싼” 키가 인증 장치로 전송되고, 장치 안에서 복호화된 뒤 디지털 서명을 만드는 데 쓰임. 단, FIDO2는 비상주 키 구현 방식을 실제로 지정하지 않으며 감싼 키는 한 방법일 뿐임. FIDO2는 개인 키가 자격 증명 ID에서 안전하게 도출 가능해야 한다고만 요구하며, 자격 증명 ID는 감싼 키일 수도 있고 아닐 수도 있는 임의 데이터임

  • 상황을 너무 박하게 보는 것 같음. 약한 비밀번호와 비밀번호 재사용을 없애서 일상적인 계정 침해 99%를 막는 새 인증 표준의 이점을 누리고 싶다면, 2013년부터 버티던 구형 Yubikey에서 벗어나 30달러를 들여 업그레이드해야 한다고 볼 수도 있음

    • 왜 업그레이드를 강제당해야 하는지 모르겠음. 비상주 키도 약한 비밀번호와 비밀번호 재사용을 없앰. 상주 키는 키를 꽂으면 서비스가 어느 계정의 것인지 안다는 정도의 작은 개선만 추가할 뿐이고, 현재 사용 중인 기존 인증 장치를 모두 폐기할 정당한 이유로 보이지 않음
    • 5 시리즈 기술 매뉴얼을 보니 25개만 지원함. 지금은 2개뿐이지만 TOTP는 25개보다 훨씬 많음
      Bio FIDO 모델은 어떤지 모르겠지만 비슷하다면 YubiCo에는 많은 수의 상주 키에 잘 맞는 제품이 없을 수 있음. 수정: Bio도 같은 25개 제한임
    • 오히려 너무 호의적인 해석이라고 보임
      공유되는 상주 키는 단기 임시 사용을 제외하면 존재해서는 안 됨. 이는 책임 부담이고 보안 위험이며 나쁜 보안 관행을 장려함. 가장 좋은 예가 보안 관점에서 결함이 많은 TOTP임. 공유 비밀을 여러 기기에 공유하거나 백업하고 싶어서는 안 되지만, 가능하다는 점과 허술한 2단계 인증 구현이 예외가 아니라 표준이 되면서 사실상 강요받음. 지금 흐름을 보면 패스키도 같은 결함 많고 사용자에게 적대적인 방향으로 갈 것 같음
    • 그래도 크게 달라지는 건 없음. 내 키는 상주 키를 25개만 담을 수 있는데, 비밀번호 관리자에 저장된 비밀번호는 25개보다 많음
    • 앞으로는 이 “이점”을 택하는 것 외에 선택지가 없어질까 걱정됨. 사이트가 새 인증 표준을 구현하면 현재의 사용자명/비밀번호/2단계 인증도 대안으로 계속 유지할까?

  • “가지고 있지만 잃어버릴 수도 있는 것”에 기반한 인증은 근본적으로 망가져 있음. 장치를 잃으면 접근 권한을 잃거나, 아니면 최약점이 다른 곳에 있어야 하므로 그 뛰어난 보안성이 의미 없어짐

    • 백업 코드를 출력해 두거나 두 번째 서랍용 키를 추가하면 됨. 아이디어 자체는 훌륭하지만 마케팅이 매우 나쁘고, 일반 사용자에게 설정 흐름이 이상하며, AirDrop 가능하거나 클라우드 동기화되는 키를 밀어붙이는 것도 나쁜 생각임. 가장 중요한 문제는 키 비용임
    • 비밀번호도 여기에 포함되지 않나? 사람들은 비밀번호도 자주 잃어버림
      결과로 증명되겠지만, 패스키가 널리 채택되면 대다수에게는 계정 잠금이 더 흔해지기보다 덜 흔해질 것 같음

  • 하드웨어 키의 저장공간은 왜 이렇게 제한적인지 궁금함. 키 안에 보안 프로세서가 접근할 수 있는 대용량 저장장치를 함께 넣으려면 비용이 얼마나 더 들까
    이 대용량 저장장치는 당연히 보안 프로세서가 강하게 암호화하고, 모든 것이 삭제될 때 그 키도 함께 지워지게 하면 됨

    • 안전한 변조 방지 저장공간은 비싸기 때문임
      보안 관점에서는 저장공간이 0인 보안 키가 최고의 보안 키라고까지 말할 수 있음. 보안 토큰을 공유 비밀 등에서 도출하지 않고 보안 키나 보안 영역 등에 주입해 저장하는 프로토콜은 대체로 심각한 결함이 있었음. 때로는 TOTP처럼 근본적인 보안 결함이고, 때로는 복잡성 결함임. 마찬가지로 HSK/2단계 인증용 보안 키를 여러 기기에 공유하고 싶어서는 절대 안 됨. 한 기기에서 유출되면 모두 망가진다는 뜻임. 대신 각 기기에 별도의 키를 둬야 하며, 로그인 제공자나 서버 쪽에서 이 오버헤드는 큰 그림에서는 무시할 만함
    • 이런 장치를 최대한 “멍청하게” 유지하려는 의식적인 설계 선택으로 보임. 저장공간을 추가하는 순간 다른 저장장치와 같은 취약점 표면이 열리고, 다음에는 연산 기능이 붙고, 결국 멍청한 Yubikey가 아니라 완전한 컴퓨터가 됨
    • 저장공간을 늘릴 수는 있겠지만, 더 많이 넣을수록 고장 가능성도 커짐. 지금의 키들은 작동하지 않게 되기 전까지 상당히 거친 사용을 견딤
      작은 저장공간은 감사하기가 조금 더 쉽다는 장점도 있음. 물론 요즘 기준으로는 그 작은 크기조차 현실적으로 감사 가능한 범위를 밀어붙이고 있을 수 있음
    • 메모리가 제한적이라기보다는, 애초에 메모리 한계가 없도록 설계된 것에 가까움
      TPM을 보면 무언가에 서명할 때마다 입력은 서명할 데이터와 봉인된 개인 키임. 봉인된 키는 TPM이 생성한 개인 키를 TPM에 내장된 키로 대칭 암호화한 것임. 이 봉인된 키를 대용량 저장장치에 저장해 두고, 매 서명 작업마다 TPM에 제공함. 이 설계 덕분에 대용량 저장장치가 허용하는 만큼 많은 키를 가질 수 있음
    • 모듈식으로 만들 수도 있을 것 같음. USB 메모리처럼 생겼지만 뒤쪽에 YubiKey Nano 같은 작은 폼팩터의 보안 키를 꽂을 슬롯이 있는 제품을 파는 식임
      보안 키를 슬롯에 꽂으면 USB 메모리가 보안 키에 저장공간을 제공하고, 컴퓨터에는 보안 키처럼 보임. 보안 키를 꽂지 않았을 때는 일반 USB 메모리로 동작함. 평소에는 보안 키를 꽂아 두다가 저장공간이 더 필요해지면 더 큰 저장 모듈을 사서, 기존 모듈에서 보안 키를 빼고 컴퓨터에 꽂아 암호화된 파일을 복사한 뒤 새 모듈에 옮기고 보안 키를 다시 꽂으면 됨

  • 애초에 물리 보안 키를 패스키로 쓰는 게 좋은 생각인지 모르겠음. 패스키는 비밀번호 대체재로 의도됐고, 그러려면 보통 “가지고 있는 것”에 더해 잠금 해제에 “아는 것”이나 “자기 자신”을 요구하는 휴대폰이나 데스크톱이 제공하는 2요소 속성이 필요해 보임
    물리 보안 키는 특정 고보안 맥락에서 패스키에 더해 쓰는 2단계 인증으로 남겨두는 편이 낫다고 봄. 특히 복제 저항성이 핵심 기능일 때 그렇음. 그 용도라면 두 번째 단계에 도달했을 때 이미 로그인하려는 계정을 알고 있으므로 상주 키는 필요 없음. 또 상주 키가 제공하는 자동완성 기능은 패스키 UX에 중요하다고 생각함. 보안 덕후만 쓰는 소수 키와의 하위 호환성을 유지하려고 그걸 희생하는 건 말이 안 됨. 물론 상주 키 없이도 그 UX를 유지할 방법이 있다면 괜찮음

    • 대체로 같은 생각임. 현재 모두가 수렴한 아이디어는 신뢰할 수 있는 로컬 암호화 보안 금고를 갖고, 그 시스템에 신원을 확인해야 한다는 것임. 비밀번호일 수도 있고 키일 수도 있음
      계정을 만드는 세상의 모든 서비스가 안전하거나 피싱 불가능하다고 가정하는 것보다, 선택한 비밀번호 관리자가 더 안전하다고 믿는 편이 쉽다. 그래서 패스키를 사용할 때쯤에는 이미 운영체제나 패스키를 소유한 비밀번호 관리자 등에 신원을 확립한 더 안전한 맥락에 있는 경우가 많음. 또한 지금이나 최근까지 하드웨어 키를 지원하지 않았던 곳들은 가까운 미래에도 지원하지 않았을 가능성이 큼. 반면 패스키 솔루션은 도입 비용이 소프트웨어 지원 정도라 훨씬 쉬워 투자 대비 효과가 높을 가능성이 큼. 물론 주로 웹사이트에 해당하는 얘기이며, 패스키는 웹사이트용 “표준화된 SSH 키”에 가깝다. 하드웨어 키는 패스키가 들어 있는 금고를 실제로 여는 2단계 요소로 더 유용해 보이고, 이때 비밀번호도 함께 필요할 수 있음. 하드웨어 키의 수명은 아직 좀 남아 있을 것 같음. GitHub, Gmail 등에서 기본 방법으로 써 보니 패스키 로그인 흐름은 정말 매우 좋음
    • 비밀번호 관리자가 이미 비밀번호를 쓸모없게 만들었음. 마스터 비밀번호 하나 빼고는 내 비밀번호를 하나도 모름. 패스키는 우리가 꼭 필요로 하지 않는 지나치게 복잡한 해법임
      브라우저에는 비밀번호 관리자가 연결할 수 있는 단순한 HATEOAS API가 있으면 되고, 웹 앱은 브라우저를 트리거하는 HTML을 노출하면 됨. 그러면 비밀번호 관리자가 사용자를 어떻게 인증할지, 즉 사용자가 원하는 방식을 결정하고, 해당 웹사이트의 비밀값을 자동 주입해 사용자는 자동 로그인됨. 문제가 생기면 이메일 재설정을 쓰면 됨. “아주 화려한 보안”을 원하는 웹사이트 입장에서는 더 복잡한 무언가를 원하는 걸 이해함. 하지만 사용자가 선택적으로 더 높은 보안 수준을 켤 수 있어야 함. 예를 들어 대부분의 웹사이트는 비밀번호 관리자가 무작위 비밀번호를 쓴다는 전제라면 단순 비밀번호 해시로 충분함. 어떤 웹사이트나 구현할 수 있고, 모든 비밀번호 관리자가 구현할 수 있으며, 일반 사용자 99%의 현재 비밀번호 사용보다 낫다. 이걸 기본 인증 방식으로 두면 됨. 이후 TOTP, OIDC, 공개 키 암호화 등을 원하면 서버가 광고하고 클라이언트가 선택적으로 참여해 인증을 이어가면 됨. 모든 사이트와 모든 사용자가 가장 안전한 방법을 쓸 필요는 없음. 우선 보안의 기준선을 올리기 쉽게 만들고, 더 강한 보안은 천천히 선택하게 하면 됨
    • Yubikey로 비밀번호 없는 인증(FIDO2)을 할 때는 장치를 터치하라고 하기 전에 PIN을 요구함. PIN을 너무 많이 틀리면 Yubikey가 잠기고 장치 재설정이 필요해지며, 그 키를 인증에 쓰던 기존 등록이 모두 무효화됨
      누가 내 하드웨어 토큰을 훔쳐도 큰 문제처럼 보이지 않음. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
    • 생각해 보면 핵심 문제는 “생물학적 존재를 전자 시스템에 인증하는 것”이라고 표현할 수 있음
      비밀번호를 쓰면 인증 인터페이스는 키보드이고, 비밀번호를 입력하는 사람이 주장하는 그 사람이라는 실제 보장은 없음. 비밀번호는 쉽게 전달 가능한 지식에 의존하므로 여러 방식으로 추출될 수 있음. 인증 인터페이스를 기기 대 기기로 옮기는 편이 훨씬 낫다. 쉽게 전달 가능한 지식이 전달되지 않았다고 가정하는 대신, 생물학적 존재가 인증 장치를 관리할 수 있다고 가정하는데 사람들은 원래 그런 일에 꽤 능함. 인증 채널 수를 늘려 더 단단하게 만들 수도 있고, 원격 시스템 인증에 사용할 기기와 생물학적 존재 간 인증을 FaceID처럼 제한할 수도 있음. 핵심적으로는 휴대폰이나 키 같은 기기가 곧 그 사람이라고 가정하는 게 자연스럽게 느껴짐. 집에서는 Netflix 비밀번호뿐 아니라 신용카드 하나도 공유함. 실용적 이유로 신용카드 하나는 여분 열쇠와 함께 두고, 집에 필요한 물건을 살 일이 있으면 누구나 집어 쓸 수 있음. 서로 카드를 제대로 쓸 거라고 믿고, 모두 PIN을 알지만 비접촉 결제가 일반적이라 거의 필요 없음. 비용을 추적하고 나중에 서로 정산하는 것보다 훨씬 자연스럽다. 아마 불법일 것이고 은행이 알면 카드를 취소하겠지만 말임. IT 시스템은 현실 세계와 유사한 방식으로 작동하면서 인간 행동에 다가갈 필요가 절실함. IT 시스템에 관여하고 있어서 대부분은 버티지만, 기술에 익숙하지 않은 사람들은 iPhone 비밀번호는 무엇이고 iCloud 비밀번호는 무엇이며 Gmail 비밀번호는 무엇인지, 왜 WhatsApp에 코드를 입력해야 하는지 같은 일상적인 문제도 힘들어함. 사실 나도 Mastadon은 이해하지 못했음. Mastadon 피싱에는 무방비일 것 같고, 화면이 입력하라는 건 뭐든 입력할 것 같음
    • 패스키가 비밀번호 대체재라는 말은 맞지 않음
      패스키는 이름 그대로 두 번째 요소로 개발된 FIDO2 U2F 표준에 기생함. 상주 키는 PIN을 곁들인 기기 내 2단계 인증용이며, 스마트카드의 기능적 대체물임. 누군가, 아마 Apple이 WebAuthn만으로 유일한 인증 요소가 되기에 충분하다고 생각한 듯함. 상주 키도 없고 하드웨어 결속도 없으며 키는 iCloud를 통해 이동하지만, 기기에서는 TouchID/FaceID로 보호된다는 식임. 그리고 이를 패스키라고 브랜드화했음. 2단계 인증 자체가 목표는 아님. 목표는 피싱, 무차별 대입, 자격 증명 대입 공격에 안전하고 스마트카드만큼 구현이 어렵지 않은 사용자 인증임. FIDO2는 그걸 해냄. Apple, Google, Microsoft 구현의 문제는 인증 사이트와 사용자 기기 사이의 프로토콜 수준 보안이 낮다는 게 아님. 그 프로토콜은 동일함. 문제는 사이트가 이제 사용자 개인 플랫폼 계정을 신뢰해야 하고, 사용자가 올바르게 설정했으며, 플랫폼이 앞으로도 늘 올바르게 행동해 사용자 개인 계정 공격을 제대로 처리할 것이라고 믿어야 한다는 점임

  • 맥락을 덧붙이면, YC 지원을 받은 비밀번호 없는 인증 회사를 운영하고 있고 대형 조직에 이를 배포해 왔음. 패스키가 소비자용 비밀번호 없는 인증의 답이 될 것은 분명해 보이지만, 기업 환경에는 아직 그렇게 반영되지 않은 것 같음
    패스키는 소비자에게 훌륭함. iCloud 기본 백업이나 AirDrop 같은 방식으로 자격 증명을 다른 기기에 백업해, 스스로 비상 접근을 가능하게 하려는 목적이 있기 때문임. 기술적으로 이 자격 증명을 공유받은 기기들은 증명을 제공할 수 없음. 증명이란 키 쌍이 Yubikey나 Apple 기기 같은 특정 장치에서 생성됐다는 “증거”임. Yubico 같은 제조사는 추출할 수 없는 키 쌍·인증서를 키에 내장해 출하하고, 이 키 쌍에 접근하는 외부 인터페이스가 없으므로 관리자는 이것이 진짜 Yubikey라고 높은 확신을 가질 수 있음. 증명이 없고 키를 공유할 수 있으면 문제가 어디서 시작되는지 보임. 기업은 AirDrop 가능한 자격 증명이 특권 직원 계정 접근을 노출할 위험을 떠안으려 하지 않음. Yubikey에는 디지털 절도 위험이 사실상 없음. 결국 패스키는 기기나 서버 잠금 해제에도 쓸 수 없음. FIDO2, 더 중요하게는 운영체제 개발자들이 비밀번호를 완전히 끝내려면 갈 길이 멂. 현재 기업 시장 대부분에서는 Yubikey가 이 공백을 메우고 있고, 일부는 하드웨어에 수백만 달러를 썼음. 현재 상태의 패스키는 팔기 어려울 것임

    • 패스키는 기술 용어가 아니라 경험 용어임. 그래서 기술적 논증에 쓰면 어느 정도 무너짐
      Apple도 패스키를 지원하고, Android와 Chrome도, Microsoft도, Yubikey도 패스키를 지원함. 하지만 사용자 검증을 위한 인증 절차와 복제 가능성 같은 기능·제약은 크게 다를 수 있음. 정부 기관은 패스키를 지원하되, AAL2 요구사항을 충족하는 FIPS 인증 인증 장치에서 제공될 때만 허용할 수 있음. 적어도 현재 Apple이나 Google에서 나올 것은 아님. 기업은 MDM 관리 제품이 제공하는 소프트웨어·구성으로 생성된 패스키를 지원하기로 선택할 수 있고, Apple은 이에 대한 베타 지원을 발표했음. 다만 정부 대 시민 서비스에서 특정 하드웨어 인증 장치를 강제하려 하면 많은 고통을 겪을 수 있음. 시민에게 80달러 이상짜리 하드웨어를 사라고 설득하기도 어렵고, 웹 기술이 사용자 선택을 중심으로 만들어져 있어서 WebAuthn API와 사용자 경험이 사용자 선택 제한을 돕는 방향으로 최적화될 가능성도 낮기 때문임
    • Google이나 Apple이 봇 방지, 사기 탐지 같은 말도 안 되는 이유로 실수로 계정을 차단하면 어떻게 됨?
    • yubikeys 5는 패스키로 쓸 수 있음

  • 보안 관점에서 이건 정말 형편없는 해법이라고 봄
    정부와 Apple, Google 같은 회사가 디지털 삶을 통제하기 좋은 꿈 같은 구조임. 비밀번호를 쓰면 일종의 무상태에 가까워서, 개인 이메일 계정이나 어떤 계정을 가진 채 국경을 넘더라도 아무도 계정 보유 사실을 알 수 없고, 접근 권한을 내놓으라고 강요하거나 하드웨어에서 접근 요소를 추출하거나 기기 접근을 잃었다고 잠그는 일이 어려움. 마스터 키 등이 TPM이나 보안 요소에 저장되더라도, 어떤 정부는 접근할 수 있으니 몇 년과 연산 능력의 문제일 뿐임. 대부분의 경우 그 자체가 특정 계정의 자격 증명을 가지고 있다는 증거가 되기도 함. 기기나 운영체제 제조사는 당국에 의해 보안 영역 접근을 제공하도록 쉽게 강제될 수 있고, 자발적이든 아니든 그렇게 될 수 있음

답변달기