WebAuthn pubKeyCredParams와 credentialPublicKey: CBOR 및 COSE

디지털 보안 분야에서 패스키는 새로운 비밀번호 없는 표준으로 자리 잡고 있습니다. 패스키의 핵심에는 공개 키 암호화가 있으며, 이는 패스키의 기반이 되는 WebAuthn 프로토콜 내에서 활용됩니다. 특히 패스키를 생성, 추출, 관리 및 저장할 때 WebAuthn에서 공개 키 암호화가 어떻게 사용되는지 이해하는 것은 패스키 인증을 설계하거나 사용할 때 매우 중요합니다. 공개 키는 신뢰 당사자(relying party)(RP)의 서버에 저장됩니다. RP는 패스키를 통해 사용자를 인증하려는 웹사이트의 백엔드를 의미합니다. 그리고 개인 키는 운영체제에 따라 하드웨어 보안 모듈에 안전하게 저장됩니다. 예를 들어 Secure Enclave(iOS), TEE(Android) 또는 TPM(Windows)이 있습니다.

이 블로그 게시물에서는 패스키에 사용되는 공개 키 암호화의 기본 사항을 빠르게 살펴보겠습니다. 이 글을 다 읽고 나면 다음 질문에 답할 수 있을 것입니다.

• WebAuthn에서 지원하는 암호화 알고리즘은 무엇인가
• 키 쌍 생성 시 pubKeyCredParams는 어떻게 작동하는가?
• 생성된 공개 키 추출 시 credentialPublicKey는 어떻게 작동하는가?

WebAuthn 내에서 공개 키 암호화가 어떻게 작동하는지 이해하기 위해, 먼저 일반적인 작동 방식과 일반적인 알고리즘 유형을 간단히 살펴보겠습니다.

비대칭 암호화라고도 하는 공개 키 암호화는 암호화와 복호화 모두에 동일한 키를 사용하는 대칭 암호화와 대조됩니다. 비대칭 암호화는 공개적으로 공유할 수 있는 공개 키와 소유자가 비밀로 유지하는 개인 키라는 두 개의 고유한 키를 사용합니다.

출처: https://en.wikipedia.org/wiki/Public-key_cryptography

이 방법은 데이터의 기밀성을 보호하기 위한 암호화뿐만 아니라 메시지에 서명하는 것도 가능하게 합니다. 서명은 발신자의 신원을 확인하고 메시지가 변조되지 않았음을 보장하여 메시지의 진위성과 무결성을 확인합니다.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

공개 키 암호화에 사용되는 몇 가지 일반적인 알고리즘 유형에 대한 개요는 다음과 같습니다.

ECDSA와 EdDSA를 포함한 타원 곡선 암호화(ECC)의 수학적 기반은 타원 곡선의 속성을 포함하지만, 이 글에서는 다루지 않겠습니다. 하지만 위 표에서 볼 수 있듯이, ECC 채택을 이끄는 명백한 장점들이 있습니다. 다음 섹션에서 가장 중요한 장점들을 살펴보겠습니다.

Become part of our Passkeys Community for updates & support.

Join

타원 곡선 암호화는 더 작은 키 크기의 이점을 활용할 수 있어 모바일 기기에 널리 채택되었으며, 다음과 같은 장점을 가집니다.

• 저장 공간 요구사항 감소: ECC의 더 작은 키는 RSA와 같은 전통적인 암호화 방법에 비해 더 적은 저장 공간을 필요로 합니다. 이는 제한된 메모리 리소스를 가진 기기에 특히 유용하며, 공간을 더 효율적으로 사용할 수 있게 합니다. 다음 표는 비교 가능한 보안 수준과 사용되는 실제 키 크기의 근사치를 보여줍니다. 보안 수준은 비트로 측정되며 일반적으로 해당 크기의 대칭 키 암호에 해당합니다.

이 맥락에서 보안 수준이라는 용어는 암호화 시스템의 강도, 특히 공격자가 보안 조치를 무력화하는 데 필요한 난이도 수준을 의미합니다. 일반적으로 비트로 측정되며 암호화를 깨거나 서명을 위조하는 데 필요한 작업량(작업 수)을 나타냅니다. 보안 수준이 증가함에 따라 키 비율 크기가 1:30에 이를 때까지 크기 이점이 명확해집니다.

• 성능 향상: 더 작은 키는 더 빠른 암호화 작업을 가능하게 하며, 이는 처리 능력이 낮은 기기에 매우 중요합니다. 결과적으로 암호화 및 복호화 활동이 더 빨라져 모바일 애플리케이션의 전반적인 성능과 반응성이 향상됩니다. 벤치마크 유형에 따라 실행 속도는 10-40배 빨라집니다. 다음은 AWS가 2018년 Cloudfront에 ECDSA를 구현할 때 수행한 벤치마크 데이터의 예입니다.

• 배터리 효율성 향상: 더 작은 키로 인한 더 효율적인 처리로 ECC 작업은 더 적은 전력을 소비할 수 있습니다. 이러한 에너지 절약은 배터리 수명 보존이 끊임없는 과제인 모바일 기기에 매우 중요합니다.

이러한 요소들로 인해 ECC는 저장 공간, 처리 속도 및 전력 소비 최적화가 필수적인 모바일 환경에 특히 적합합니다. 결과적으로 ECC는 기기 성능을 저하시키지 않으면서 강력한 보안을 제공하는 능력 때문에 모바일 컴퓨팅에서 점점 더 선호되고 있습니다. 그럼에도 불구하고 오늘날까지 HTTPS, FTPS 또는 SMTPS에 사용되는 TLS, SSH 또는 IPsec과 같은 널리 퍼진 프로토콜의 많은 구버전은 여전히 RSA를 지원하지만, 이를 지원하는 클라이언트에게 ECC 기반 변형을 제공하기 시작했습니다.

WebAuthn 표준은 암호화 표준이 아니라, 웹 애플리케이션을 위한 강력한 공개 키 기반 인증을 제공하는 보안 프로토콜입니다. 이를 통해 사용자는 비밀번호 대신 생체 인식, 모바일 기기 또는 하드웨어 보안 키(예: YubiKeys)를 사용하여 로그인할 수 있습니다. 따라서 WebAuthn은 실제로 어떤 공개 키 기반 암호화가 사용되는지에 대해 의도적으로 불가지론적(agnostic)입니다. 이것이 어떻게 달성되는지 살펴보겠습니다.

WebAuthn 보안 프로토콜은 사용자와 신뢰 당사자 간의 암호학적으로 안전한 인증을 용이하게 합니다. 기술적인 용어로 이는 신뢰 당사자(사용자와 함께 패스키를 사용하려는 웹사이트)가 브라우저를 통해 사용자와 그의 인증자와 키를 교환해야 함을 의미하며, 인증자는 개인 키를 특정 하드웨어 보안 모듈(HSM)에 저장합니다.

패스키 가입/등록에는 세 가지 중요한 단계가 있습니다.

• (1) 신뢰 당사자가 지원하는 암호화 알고리즘을 알림: 신뢰 당사자는 다른 PublicKeyCredentialCreationOptions와 함께 PublicKeyCredentialCreationOptions.pubKeyCredParams를 통해 지원하는 암호화 알고리즘을 알립니다.
• (2) 사용자의 인증자가 키 쌍을 생성: 인증자는 pubKeyCredParams 목록에서 지원하는 암호화 알고리즘을 확인하고 고유한 Credential ID와 함께 키 쌍을 생성합니다. 개인 키를 HSM 내에 저장한 다음 공개 키와 사용된 암호화 알고리즘을 브라우저에 반환합니다. 그런 다음 브라우저는 "authData" 섹션에 attestationObject를 담아 신뢰 당사자 백엔드에 POST 요청을 보냅니다. 지원되는 암호화 알고리즘이 일치하지 않으면 생성 절차가 실패합니다.
• (3) 신뢰 당사자가 공개 키를 추출하고 저장: 신뢰 당사자는 브라우저로부터 attestationObject를 받습니다. authData.credentialPublicKey 섹션을 파싱하고 공개 키를 추출합니다. 공개 키와 함께 사용된 암호화 알고리즘 및 Credential ID에 대한 정보도 신뢰 당사자에게 다시 전송됩니다.

이후 패스키를 사용한 로그인/인증에는 다음 단계가 필요합니다(세부 정보는 단순화됨).

• (1) 신뢰 당사자가 챌린지를 제시: 신뢰 당사자는 임의의 챌린지를 생성하여 서명을 위해 인증자에 제공합니다.
• (2) 사용자의 인증자가 챌린지에 서명: 인증자는 인증 요청과 일치하는 키로 챌린지에 서명하고 Credential ID와 함께 신뢰 당사자에게 반환합니다.
• (3) 신뢰 당사자가 서명을 검증: 신뢰 당사자는 정보를 수신하고 사용된 Credential ID와 연관된 공개 키를 조회합니다. 그런 다음 패스키 등록 중에 합의된 암호화/서명 알고리즘을 사용하여 암호학적으로 서명을 검증합니다.

두 경우를 모두 살펴보면, 패스키 가입/등록 시에만 공개 키와 암호화 알고리즘 정보가 행위자들 간에 전송된다는 것을 알 수 있습니다.

이후 패스키를 사용한 로그인/인증 이벤트에서는 챌린지와 서명만이 전송되는 데이터의 일부입니다.

WebAuthn 표준은 사용된 암호화 알고리즘을 식별하기 위해 IANA COSE 알고리즘 ID를 사용합니다. COSE 알고리즘 ID는 pubKeyCredParams에서 지원되는 알고리즘을 알리는 것과 credentialPublicKey에서 실제로 생성된 키 쌍 유형을 전송하는 데 모두 사용됩니다. 다음 두 섹션에서는 이들의 구현에 초점을 맞출 것입니다.

IANA의 COSE 알고리즘 목록에는 이론적으로 WebAuthn 표준과 함께 사용할 수 있는 75개 이상의 알고리즘이 포함되어 있습니다. 음수 ID를 가진 대부분의 알고리즘은 비대칭 공개 키이고 양수 ID는 대부분 대칭이지만, 예외가 있으므로 이는 관례에 가깝습니다.

앞서 지적했듯이, 암호화 알고리즘은 WebAuthn 절차에서 사용되기 위해 인증자와 신뢰 당사자 백엔드에서 모두 지원되어야 합니다. 대부분의 신뢰 당사자는 다양한 암호화 알고리즘에 접근할 수 있는 기존 WebAuthn 라이브러리를 사용하므로, 어떤 알고리즘이 어떤 인증자에서 지원되는지 살펴보는 것이 더 중요합니다.

(*) = 일부 보안 키(예: Yubikeys 5+, Solokey 또는 Nitrokey) IANA 표에서 발췌: 전체 목록은 여기에서 확인하세요.

이 표에서 볼 수 있듯이, 모든 중요한 인증자를 지원하려면 RS256과 ES256으로 충분합니다. 커뮤니티의 일부에서는 보안을 더욱 강화하기 위해 EdDSA도 통합할 것을 권장합니다. 반면에, 함께 저장해야 하는 Credential ID는 EdDSA 키의 경우 훨씬 더 긴 것 같습니다. 현재 W3C 편집자 초안의 다가오는 레벨 3 WebAuthn 표준은 세 가지 알고리즘을 모두 제안합니다.

패스키 생성을 위해 지원되는 암호화 알고리즘 구성은 PublicKeyCredentialCreationOptions를 통해 수행됩니다.

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

이 예는 alg로 ID를, public-key를 알고리즘 유형으로 추가하여 pubKeyCredParams 내에서 알고리즘이 어떻게 지정되는지 보여줍니다. 29/30행에서 PublicKeyCredentialCreationOptions는 브라우저의 WebAuthn API를 통해 인증자로 전달됩니다. ES256 또는 RS256에 대한 지원을 제거하면 오류가 발생하며 절대 권장되지 않습니다.

작동 예시로, Mac의 Passkeys Debugger에서 다음 PublicKeyCredentialCreationOptions를 실행해 보겠습니다.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

인증자가 생성한 응답은 신뢰 당사자에게 (증명(attestation)으로) 전송되며 다음과 같습니다.

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

다음 세션에서는 응답에서 공개 키와 사용된 암호화 알고리즘을 어떻게 추출할 수 있는지 살펴보겠습니다.

먼저, 실제 attestationObject가 어떻게 구성되는지 살펴봐야 합니다. 위에서 보았듯이 JSON 형식으로 신뢰 당사자에게 전송되지 않기 때문입니다.

attestationObject는 WebAuthn 등록 과정에서 중요한 역할을 하며, 인증자가 제공하는 증명서(attestation statement)를 담는 컨테이너 역할을 합니다. 이 객체는 신뢰 당사자(RP)가 새로 생성된 공개 키 자격 증명의 출처와 무결성을 확인하는 데 필요한 많은 정보를 제공합니다.

핵심적으로 attestationObject는 복잡한 구조입니다. 대부분 CBOR(Concise Binary Object Representation) 형식으로 인코딩된 후, 마지막에 Base64URL 인코딩으로 인코딩됩니다. 이는 정보의 진위성을 확인하는 증명(attestation)서와 함께 인증자 데이터를 캡슐화합니다. 패스키는 증명(attestation) "none"으로 생성되어 증명(attestation)서를 포함하지 않으므로, 이 글에서는 다루지 않겠습니다. 참고로, 선택적 확장에 필요한 가변 길이 때문에 비표준 CBOR 접두사도 관련되어 있어 대부분 CBOR이라고 썼습니다. 이에 대해서는 더 깊이 다루지 않겠지만, 복잡성에 대한 논의는 여기에서 찾을 수 있습니다.

WebAuthn 사양에서 발췌

인증자 데이터(authData) 내에는 새로 생성된 공개 키가 사용자의 자격 증명 ID와 함께 안전하게 저장되어 신뢰 당사자가 검색할 수 있습니다. 개발자는 모든 WebAuthn 기반 시스템에서 attestationObject로부터 공개 키를 추출하는 작업을 수행해야 하므로, 그 아키텍처를 이해하는 것이 중요합니다.

CBOR(Concise Binary Object Representation)은 데이터를 작고 효율적이며 확장 가능한 방식으로 인코딩하도록 설계된 데이터 형식입니다. 이진 형식이므로 텍스트 기반의 롤모델인 JSON보다 작고 파싱이 빠릅니다. 다음 예는 JSON과 CBOR이 어떻게 다른지(텍스트 대 이진) 보여줍니다.

굵은 글씨는 Name입니다. 이탤릭체는 Corbado입니다. (더 많은 정보는 https://cbor.io/에서 찾을 수 있습니다.)

WebAuthn의 맥락에서 CBOR은 여러 가지 이유로 사용됩니다.

• FIDO2 / CTAP와의 연결: CBOR이 기본 표준에서 사용되므로 WebAuthn과 CTAP 모두 동일한 간결한 인코딩 체계를 활용하여 데이터의 파싱 및 처리를 간소화합니다.
• 간결성: CBOR의 효율적인 인코딩은 데이터 크기를 최소화하는 것이 성능에 큰 영향을 미칠 수 있는 웹 트래픽, 특히 모바일 네트워크나 대역폭이 제한된 환경에서 탁월한 선택입니다.
• 유연성: CBOR은 배열, 맵, 텍스트 문자열, 바이트 문자열 및 확장성을 위한 태그를 포함한 다양한 데이터 유형과 구조를 지원합니다. 이로 인해 WebAuthn의 작업에 필요한 다양한 데이터 유형과 복잡한 구조를 처리할 수 있을 만큼 다재다능합니다.
• 확장성: 이 형식은 확장 가능하도록 설계되었으므로 기존 구현과의 호환성을 깨지 않고도 WebAuthn에 새로운 기능을 추가할 수 있습니다.

CBOR의 사용은 위에서 논의한 다양한 형식과 길이를 처리해야 하기 때문에 공개 키와 attestationObject를 인코딩하는 데 특히 적합합니다. 예를 들어, RSA 키는 ECDSA 키와 다른 속성과 크기를 가집니다. attestationObject 내에서 공개 키는 CBOR 기반의 COSE 키 형식으로 저장됩니다.

COSE 키 구조는 CBOR 맵 객체를 기반으로 합니다. 이는 RSA 모듈러스 및 지수, 또는 타원 곡선 공개 키 좌표와 같은 다양한 키 유형과 해당 매개변수를 포함하는 구조화된 키 표현 방법을 정의합니다. 이 표준화된 형식을 사용하면 위에서 논의한 암호화 알고리즘 ID 외에도 기본 암호화 알고리즘에 관계없이 키를 일관된 방식으로 직렬화 및 역직렬화할 수 있습니다.

CBOR과 COSE 키 형식을 활용함으로써 WebAuthn은 페이로드를 가능한 한 작게 유지하면서 광범위한 암호화 작업을 용이하게 하고, 암호화 기술의 미래 업데이트에 적응할 수 있습니다. 이 선택은 웹 인증을 위한 안전하고 효율적이며 미래 지향적인 프로토콜을 제공하려는 WebAuthn의 목표와 일치합니다.

WebAuthn 내에서 attestationObject를 디코딩할 때 개발자는 중요한 결정에 직면합니다. 맞춤형 솔루션을 개발할 것인가, 아니면 기존 라이브러리를 활용할 것인가. 이 과정의 복잡성과 중요성은 아무리 강조해도 지나치지 않습니다. Base64URL 및 CBOR 디코딩을 수동으로 구현하는 것은 기술적으로 가능하지만, 인증 프로세스의 무결성을 손상시킬 수 있는 미묘한 오류의 위험을 초래합니다.

서명의 암호화 검증과 다른 모든 유효성 검사 단계의 정확성을 보장하기 위해, 잘 테스트되고 널리 채택된 WebAuthn 라이브러리를 활용하는 것이 강력히 권장됩니다. 이러한 라이브러리는 attestationObject의 디코딩 및 유효성 검사의 세부 사항을 처리하기 위한 암호화 전문 지식으로 구축되었습니다. 여기에는 다음이 포함됩니다.

• 증명(attestation)서와 인증자 데이터를 추출하기 위해 CBOR 형식을 올바르게 파싱합니다.
• 공개 키를 검색하기 위해 COSE 키 형식을 해석합니다.
• WebAuthn 표준에 따라 서명을 검증하기 위해 암호화 검사를 수행합니다.

평판 좋은 라이브러리에 의존함으로써 개발자는 시간과 자원을 절약할 뿐만 아니라 마음의 평화를 얻을 수 있습니다. 이러한 신뢰할 수 있는 도구를 통해 추출되고 검증된 공개 키는 데이터베이스에 안전하게 저장되어 안전한 인증 세션에 사용될 준비가 됩니다. 이 접근 방식은 프로토콜 사양 준수를 보장하고 WebAuthn 구현에서 기대되는 보안 태세를 유지합니다. 간단하게 하기 위해, CBOR 필드가 확장된 JSON으로 변환된 완전히 디코딩된 버전을 반환하는 SimpleWebauthn Debugger를 사용하겠습니다.

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

SimpleWebAuthn 라이브러리는 전체 attestationObject를 디코딩하는 데 사용됩니다. 보시다시피, 이제 모든 정보를 읽을 수 있습니다. 모든 암호화 정보는 authData 부분의 일부인 credentialPublicKey에 포함되어 있으며, 라이브러리는 이를 parsedCredentialPublicKey 문으로 확장했습니다. 사양에는 COSE 키 형식이 어떻게 생겼는지에 대한 여러 예가 있습니다.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

이 출력은 credentialPublicKey의 모든 암호화 요소를 사람이 읽을 수 있는 형태로 깔끔하게 파싱하여 보여줍니다. 이 특정 인스턴스는 알고리즘 매개변수와 x 및 y 좌표의 존재로 알 수 있듯이 ES256 알고리즘에 대한 EC2 키를 보여줍니다.

반면 Windows 10 시스템의 출력은 다음과 같습니다.

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

여기서 알고리즘 ID는 -257로 RS256에 해당하며, 이 공개 키를 특징짓는 속성이 ECDSA 키의 속성과 크게 다르다는 것을 알 수 있습니다. COSE 키 형식을 사용하면 유형별로 고유한 속성을 지정할 수 있습니다.

또한 RSA 모듈러스는 ES256 키에 사용된 타원 곡선 좌표보다 훨씬 길며, 이는 키 크기의 차이와 다른 암호화 알고리즘의 고유한 요구 사항에 대한 이전 논의를 강조합니다.

공개 키 암호화의 기본 사항을 살펴보고 WebAuthn / FIDO2 표준에 어떻게 통합되는지 이해한 후, 신뢰 당사자를 위한 두 가지 주요 권장 사항이 있습니다.

• 올바른 암호화 알고리즘 선택: WebAuthn 구현에서는 최대 호환성을 위해 올바른 알고리즘을 사용하는 것이 중요합니다. 현재 권장 사항에 따라 RS256, ES256 및 EdDSA의 조합이 바람직합니다. RS256과 ES256은 광범위한 지원으로 인해 두드러지며, EdDSA를 포함하면 가능한 경우 보안을 강화할 수 있습니다.
• 공개 키 추출을 위해 잘 테스트된 WebAuthn 라이브러리 사용: 알고리즘을 결정했다면 다음 단계는 잘 테스트된 WebAuthn 라이브러리를 통합하는 것입니다. 이러한 라이브러리는 attestationObject 파싱의 복잡성을 능숙하게 처리할 수 있습니다. 라이브러리가 공개 키와 관련 데이터를 추출한 후에는 데이터베이스에 안전하게 저장할 수 있습니다. 라이브러리에서 사용하는 형식은 일반적으로 키가 향후 인증 목적을 위해 정확하게 읽고 활용될 수 있는 방식으로 저장되도록 보장합니다.

바퀴를 다시 발명하지 않는 것이 중요합니다. 기존에 검증된 라이브러리에 내장된 집단 지성을 활용하세요. 직접 구현하면 인증의 효율성과 시스템의 전반적인 보안을 저해할 수 있는 오류와 보안 결함을 초래할 위험이 있습니다.

이 블로그 게시물에서는 공개 키 암호화의 기본 사항을 조사하여 초기 세 가지 핵심 질문에 답했습니다.

1. WebAuthn에서 지원되는 암호화 알고리즘: WebAuthn은 유연하게 설계되었으며 RSA(RS256), ECDSA(ES256) 및 EdDSA를 포함한 광범위한 암호화 알고리즘을 지원합니다. 이러한 적응성을 통해 다양한 인증자 및 플랫폼과 원활하게 통합되어 광범위한 호환성을 보장합니다.
2. 키 쌍 생성에서 pubKeyCredParams의 기능: pubKeyCredParams는 신뢰 당사자가 지원하는 암호화 알고리즘을 지정하여 WebAuthn 프로세스의 등록 단계에서 중요한 역할을 합니다. 이를 통해 생성된 키 쌍이 사용자의 인증자와 신뢰 당사자의 요구 사항 모두와 호환되도록 보장합니다.
3. credentialPublicKey의 기능 및 공개 키 추출: credentialPublicKey는 인증자가 제공하는 attestationObject에서 공개 키를 추출하는 데 사용됩니다.

또한, WebAuthn 프로토콜이 특정 암호화 알고리즘에 독립적이라는 점을 강조했으며, 이는 유연성을 크게 향상시키고 새로운 암호화 방법에 대한 미래 대비를 가능하게 합니다. 이 글이 다른 개발자들이 WebAuthn에서 공개 키 암호화와 관련된 개념/문제를 디버깅하고 이해하는 데 도움이 되기를 바랍니다.