WebAuthn의 증명(Attestation)이란 무엇인가요?

**증명(Attestation)**은 세 가지를 의미할 수 있습니다 (정확히는 다른 의미이지만, 구어체에서는 종종 혼용되어 사용됩니다):

1. 첫째, 더 일반적으로 암호화 분야에서 증명은 한 당사자가 다른 당사자에게 문장을 암호학적으로 "증명"하는 용어입니다.

2. 둘째, [WebAuthn]의 등록 단계에서 증명 객체가 [인증자]에 의해 생성되어 [신

당사자]에게 반환됩니다. 이것은 다음 정보를 담고 있는 컨테이너 객체입니다: - 증명서 형식(fmt) - 증명서(attStmt - 아래 참조) - [인증자] 데이터(authData)

Become part of our Passkeys Community for updates & support.

Join

3. 셋째, [WebAuthn]에서 증명서는 증명 객체의 선택적 요소입니다. 이 증명서는 포함될 경우, 증명 과정에 관련된 인증자(기기)의 특정 특성을 확인합니다. 그러나 일부 기기 제조업체(예: Apple)는 이 사양의 측면이 패스키 동기화를 위해 의도된 것이 아니며, 자격 증명이 여러 기기에서 동기화될 때(예: 패스키가 iPhone에서 생성되었지만 동일한 [iCloud 키체인]을 통해 MacBook에서도 사용될 때) 보안 속성을 효과적으로 확인하지 못하기 때문에 증명서를 제공하지 않습니다. 증명서가 제공될 때 부여될 수 있는 특성은 다음과 같습니다:
   • 인증 중에 신뢰할 수 있는 정품 기기가 사용되었음을 증명합니다.
   • 기기의 출처, 모델 및 기타 관련 정보에 대한 세부 정보를 제공합니다.
   • 특히 기기의 신뢰성이 중요한 시나리오(예: [의료]와 같은 특정 규제 산업)에서 보안 조치를 강화합니다.

다음 등록 프로세스 흐름은 WebAuthn에서 증명(객체)의 역할을 보여줍니다:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

위 스크린샷에서는 [AAGUID]와 증명서가 제공되지 않았습니다.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

가장 중요한 속성에 대한 기술적 분석을 계속 읽어보세요.

[WebAuthn]에서 증명은 사용자 인증이 안전하고 투명하도록 보장합니다. 증명서를 사용하면 특정 [인증자]/기기에서 자격 증명이 생성되었는지 확인할 수 있습니다.

이러한 증명 유형은 증명 객체가 아닌 증명서를 나타냅니다. 이는 [신뢰 당사자]의 선호 사항으로 간주됩니다(따라서 [인증자]는 단지 선호 사항이므로 다르게 동작할 수 있습니다).

• 증명 없음(none): 개인 정보 보호가 가장 중요하거나 동기화된 기기가 사용되는 경우, 이 유형은 기기에 대한 정보를 제공하지 않아 사용자의 개인 정보를 보호합니다. 이 값을 사용하는 또 다른 이유는 인증 기관(CA)으로의 왕복을 절약하기 위함일 수 있습니다. none은 또한 기본값입니다.
• 간접 증명(indirect): [신뢰 당사자]는 증명을 받는 것을 선호하지만, 클라이언트가 증명서를 얻는 방법을 결정하도록 허용합니다. 클라이언트는 사용자의 개인 정보를 보호하기 위해 인증자가 생성한 증명서를 익명의 증명서로 대체할 수 있습니다.
• 직접 증명(direct): 가장 투명한 형태입니다. 여기서 [신뢰 당사자]는 인증자에게 증명서를 원한다고 알려, [신뢰 당사자]가 기기의 브랜드, 모델 및 기타 세부 정보를 포함한 상세 정보를 얻을 수 있도록 합니다. 가장 높은 투명성을 제공하지만, 특정 시나리오에서는 개인 정보 보호 문제를 야기하거나 동기화된 자격 증명에는 실제로 사용하기 어려울 수 있습니다.
• 기업 증명(enterprise): [신뢰 당사자]는 고유 식별 정보를 포함할 수 있는 증명서를 받기를 원합니다. 이 유형의 증명은 일반적으로 특정 기기/[인증자]를 추적하려는 기업이나 조직에서 사용됩니다. 웹 브라우저(사용자 에이전트)는 요청하는 당사자에 대해 특별히 허용하는 설정이 없는 한 이 상세한 증명을 제공해서는 안 됩니다. 설정이 허용하는 경우, 브라우저는 프로세스 시작 시 이 특정 유형의 증명이 요청되고 있음을 기기에 알려야 합니다. 그런 다음 브라우저는 기기의 고유 ID와 증명 증거를 받은 그대로 신뢰 당사자에게 전달해야 합니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

증명 객체는 많은 속성을 포함하고 있으며, 여기 몇 가지 선택된 속성에 대한 간략한 설명이 있습니다:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

attestationObject는 새로 생성된 자격 증명, 공개 키 및 기타 관련 데이터에 대한 정보를 포함하는 [CBOR] 인코딩 객체입니다:

• fmt는 증명 형식을 나타냅니다. [인증자]는 다양한 방식으로 증명 데이터를 제공할 수 있기 때문입니다. 서버가 증명 데이터를 어떻게 검증해야 하는지 알려줍니다. 허용되는 값은 "packed", "tpm", "android-key", "android-safetynet", "[fido]-u2f", "apple" 또는 "none"입니다. 자세한 내용은 여기를 참조하세요.
• attStmt는 증명서입니다. [iOS] 또는 [Android] 기기의 패스키의 경우, [iOS] 또는 [Android]의 패스키는 동기화될 수 있으므로 비워두고, Windows 또는 [하드웨어 보안 키]와 같은 다른 기기에서는 채워집니다.
• authData는 다음 데이터를 포함하는 값의 버퍼입니다:
  
  증명된 자격 증명 데이터는 여기서 중요한 역할을 합니다. 여기에는 다음이 포함됩니다:
  • [AAGUID],
  • [자격 증명 ID] 길이,
  • [자격 증명 ID] 및
  • 자격 증명 공개 키.

가독성을 위해 attStmt가 비어 있던 위의 증명 객체와는 달리, 채워진 증명서는 다음과 같습니다.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: alg 속성은 인증자가 증명서에 서명하는 데 사용한 암호화 알고리즘 식별자를 나타냅니다.
• sig: sig 속성은 인증자가 생성한 디지털 서명을 포함합니다. 이 서명은 증명서의 진위 여부를 확인하는 데 사용됩니다.
• ver: ver 속성은 증명서 형식의 버전을 지정합니다.
• x5c: x5c 배열은 증명 검증에 도움이 되는 인증 경로를 형성하는 하나 이상의 X.509 인증서를 포함합니다.
• pubArea: pubArea 속성은 공개 키와 [인증자]의 특성에 대한 자세한 정보를 포함합니다.
• certInfo: certInfo 속성은 일반적으로 신뢰할 수 있는 당사자에 의한 인증자 인증에 대한 정보를 포함합니다.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

clientDataJSON에 대한 자세한 내용은 해당 용어집 문서에서 읽어보세요.

"transports": [
        "hybrid",
        "internal"
      ]

transports 속성은 인증자가 클라이언트와 통신할 수 있는 메커니즘을 나타냅니다. 몇 가지 일반적인 샘플 값 조합은 다음과 같습니다:

• "transports": ["internal","hybrid"]: [플랫폼 인증자](예: Face ID, Touch ID, [Windows Hello]) 또는 교차 기기 인증([QR 코드] 및 블루투스 사용)을 통해 패스키를 사용할 수 있습니다.
• "transports": ["internal"]: [플랫폼 인증자](예: Face ID, Touch ID, [Windows Hello])에서 패스키를 사용할 수 있습니다.
• transports 속성이 설정되지 않음: 아무런 표시도 없는 기본 동작입니다.

[WebAuthn]의 증명(증명서)은 [인증자]의 진위 여부를 증명하기 때문에 중요합니다. 이를 통해 인증 프로세스가 신뢰할 수 있는 기기에서 수행되도록 보장하여 잠재적인 보안 위협으로부터 보호합니다.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

3,000명 이상의 개발자가 Corbado를 신뢰하고 패스키로 더 안전한 인터넷을 만듭니다. 질문이 있으신가요? 저희는 패스키에 대해 150개 이상의 블로그 게시물을 작성했습니다.

패스키 커뮤니티 참여하기

네, 패스키는 기기 간에 동기화될 수 있으므로(예: iPhone에서 MacBook으로 [키체인]을 통해), 신뢰 당사자는 더 이상 어떤 증명된 기기가 앱이나 웹사이트에 실제로 로그인하는지 정확히 판단할 수 없습니다. 따라서 Apple과 Google은 동기화된 패스키에 대해서는 더 이상 증명서를 제공하지 않기로 결정했습니다. 그러나 신뢰 당사자의 UX를 개선하고 Apple 및 Google 생태계([iCloud 키체인] 및 [Google 비밀번호 관리자])의 패스키를 인식하고 표시할 기회를 제공하기 위해, WebAuthn 서버 설정에서 PublicKeyCredentialCreationOptions에 대한 증명이 direct 또는 indirect로 설정되어 있는 한 [AAGUID]는 계속 제공됩니다. 자세한 내용은 이 GitHub 이슈를 참조하세요.

웹사이트와 앱에 [패스키 인증]을 통합하고 사용자에게 훌륭한 패스키 UX를 제공하려면 다음을 고려해야 합니다. 대부분의 사용자가 Windows, [iOS], macOS 또는 [Android] 운영 체제를 사용하는 시나리오를 주로 구축한다고 가정합니다. 또한 대부분의 패스키(Windows 제외)가 동기화된 패스키라고 가정합니다. iOS, macOS, [Android] 모두 더 이상 증명서를 보내지 않으므로 인증자의 실제 검증은 더 이상 사용되지 않습니다(Windows의 경우 아직 작동하며, 아마도 Windows가 아직 [Windows Hello]를 통해 동기화된 패스키를 제공하지 않기 때문일 것입니다). 그러나 계정 설정에서 더 나은 패스키 관리를 위해 [AAGUID]를 얻으려면 증명 선호도를 indirect로 설정하는 것이 좋습니다. 이렇게 하면 증명서가 전송되거나(Windows) 전송되지 않는(iOS, macOS, Android) 동안에도 [AAGUID]를 얻을 수 있습니다.

[FIDO] 메타데이터 서비스는 다양한 [인증자]에 대한 메타데이터 저장소를 제공합니다. 증명 중에 이 서비스를 쿼리하여 [인증자]에 대한 세부 정보를 가져오고 검증하여 정확성을 보장하고 프로세스의 신뢰성을 높일 수 있습니다. [FIDO] 메타데이터 서비스는 증명 객체가 아닌 증명서를 확인합니다.

네, 직접 증명(증명서에서)은 기기에 대한 상세 정보를 제공하여 가장 높은 투명성을 제공하지만 특정 시나리오에서는 개인 정보 보호 문제를 야기할 수 있습니다. 증명 유형을 선택할 때 투명성의 필요성과 개인 정보 보호의 필요성을 평가하는 것이 중요합니다.

[WebAuthn]은 없음, 간접, 직접, 기업 등 다양한 유형의 증명 선호도를 제공합니다. [사용자 개인 정보]가 중요한 시나리오에서는 attestation=none을 사용하여 기기에 대한 세부 정보를 제공하지 않음으로써 사용자의 개인 정보가 보호되도록 할 수 있습니다.