WebAuthn pubKeyCredParams & credentialPublicKey: Tìm hiểu về CBOR & COSE

1. Giới thiệu: pubKeyCredParams & credentialPublicKey

2. Mật mã khóa công khai là gì?

   2.1 Mật mã khóa công khai hoạt động như thế nào?

   2.2 Các loại thuật toán mật mã khóa công khai phổ biến

   2.3 Sự gia tăng áp dụng mật mã công khai dựa trên ECC

3. WebAuthn: Mật mã khóa công khai được sử dụng trong Passkey như thế nào?

4. Làm thế nào để chọn cài đặt pubKeyCredParams chính xác?

   4.1 Những thuật toán COSE nào liên quan đến WebAuthn?

   4.2 Định nghĩa mảng pubKeyCredParams trong pubKeyCredParams

5. Làm thế nào để trích xuất khóa công khai từ attestationObject?

   5.1 Tổng quan: attestationObject là gì?

   5.2 Concise Binary Object Representation (CBOR) là gì?

   5.3 Định dạng khóa COSE là gì?

   5.4 Giải mã và phân tích attestationObject

6. Khuyến nghị

7. Kết luận

Trong lĩnh vực bảo mật kỹ thuật số, passkey là tiêu chuẩn không mật khẩu mới. Cốt lõi của passkey là mật mã khóa công khai, được sử dụng trong giao thức WebAuthn mà passkey dựa trên. Việc hiểu rõ cách mật mã khóa công khai được sử dụng trong WebAuthn, đặc biệt là trong việc tạo, trích xuất, quản lý và lưu trữ passkey, là rất quan trọng khi thiết kế hoặc sử dụng xác thực bằng passkey. Khóa công khai được lưu trữ trên máy chủ của relying party (RP), tức là backend của trang web muốn xác thực người dùng qua passkey, còn khóa riêng tư được lưu trữ an toàn trong một Module Bảo mật Phần cứng tùy thuộc vào hệ điều hành, có thể là Secure Enclave (iOS), TEE (Android) hoặc TPM (Windows).

Trong bài viết này, chúng ta sẽ cùng tìm hiểu nhanh về những kiến thức cơ bản của mật mã khóa công khai được sử dụng trong passkey. Những câu hỏi sau đây sẽ được trả lời vào cuối bài viết:

• Những thuật toán mã hóa nào được hỗ trợ trong WebAuthn
• pubKeyCredParams hoạt động như thế nào khi tạo một cặp khóa?
• credentialPublicKey hoạt động như thế nào khi trích xuất các khóa công khai đã tạo?

Để hiểu cách mật mã khóa công khai hoạt động trong WebAuthn, chúng ta sẽ xem xét nhanh cách nó hoạt động nói chung và các loại thuật toán phổ biến là gì.

Mật mã khóa công khai, còn được gọi là mật mã bất đối xứng, trái ngược với mật mã đối xứng, nơi cùng một khóa được sử dụng cho cả việc mã hóa và giải mã. Mật mã bất đối xứng sử dụng hai khóa riêng biệt – một khóa công khai, có thể được chia sẻ rộng rãi, và một khóa riêng tư, được chủ sở hữu giữ bí mật.

Nguồn: https://en.wikipedia.org/wiki/Public-key_cryptography

Phương pháp này không chỉ cho phép mã hóa dữ liệu để bảo mật thông tin mà còn cho phép ký các thông điệp. Việc ký xác minh danh tính của người gửi và đảm bảo rằng thông điệp không bị giả mạo, từ đó xác nhận tính xác thực và toàn vẹn của nó.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Dưới đây là tổng quan về một số loại thuật toán phổ biến được sử dụng trong mật mã khóa công khai:

Nền tảng toán học của mật mã đường cong elliptic (ECC), bao gồm ECDSA và EdDSA, liên quan đến các thuộc tính của đường cong elliptic mà chúng ta sẽ không đề cập trong bài viết này. Nhưng từ bảng trên, rõ ràng có những ưu điểm thúc đẩy việc áp dụng chúng. Chúng ta sẽ đi qua những điểm quan trọng nhất trong phần tiếp theo.

Become part of our Passkeys Community for updates & support.

Join

Mật mã đường cong elliptic đã được áp dụng rộng rãi cho các thiết bị di động vì chúng được hưởng lợi từ kích thước khóa nhỏ hơn, mang lại những ưu điểm sau:

• Giảm yêu cầu lưu trữ: Khóa nhỏ hơn của ECC yêu cầu ít không gian lưu trữ hơn so với các phương pháp mật mã truyền thống như RSA. Điều này đặc biệt có lợi cho các thiết bị có tài nguyên bộ nhớ hạn chế, cho phép sử dụng không gian hiệu quả hơn. Bảng sau đây cho thấy sự so sánh gần đúng về các cấp độ bảo mật và kích thước thực tế của các khóa được sử dụng. Cấp độ bảo mật được đo bằng bit và thường tương ứng với một mật mã khóa đối xứng có kích thước đó:

Thuật ngữ cấp độ bảo mật trong bối cảnh này đề cập đến sức mạnh của hệ thống mật mã, cụ thể là mức độ khó khăn để kẻ tấn công vượt qua các biện pháp bảo mật. Nó thường được đo bằng bit và đại diện cho khối lượng công việc (số lượng thao tác) cần thiết để phá vỡ mã hóa hoặc giả mạo chữ ký. Với cấp độ bảo mật ngày càng tăng, lợi thế về kích thước trở nên rõ ràng với tỷ lệ kích thước khóa lên tới 1:30.

• Nâng cao hiệu suất: Các khóa nhỏ hơn cho phép các hoạt động mật mã nhanh hơn, điều này rất quan trọng đối với các thiết bị có sức mạnh xử lý thấp hơn. Điều này dẫn đến các hoạt động mã hóa và giải mã nhanh hơn, tăng hiệu suất tổng thể và khả năng phản hồi của các ứng dụng di động. Tùy thuộc vào loại benchmark, tốc độ thực thi tăng từ 10-40 lần. Dưới đây là một ví dụ về dữ liệu benchmark mà AWS đã thực hiện khi triển khai ECDSA cho Cloudfront vào năm 2018:

• Cải thiện hiệu quả sử dụng pin: Với việc xử lý hiệu quả hơn từ các khóa nhỏ hơn, các hoạt động ECC có thể tiêu thụ ít năng lượng hơn. Việc tiết kiệm năng lượng này rất quan trọng đối với các thiết bị di động, nơi việc duy trì tuổi thọ pin là một thách thức không ngừng.

Những yếu tố này làm cho ECC đặc biệt phù hợp với môi trường di động, nơi việc tối ưu hóa lưu trữ, tốc độ xử lý và tiêu thụ điện năng là điều cần thiết. Do đó, ECC ngày càng được ưa chuộng trong điện toán di động vì khả năng cung cấp bảo mật mạnh mẽ mà không ảnh hưởng đến hiệu suất của thiết bị. Tuy nhiên, cho đến ngày nay, rất nhiều phiên bản cũ của các giao thức phổ biến như TLS (được sử dụng cho HTTPS, FTPS hoặc SMTPS), SSH hoặc IPsec vẫn còn tồn tại và hỗ trợ RSA nhưng đã bắt đầu cung cấp các biến thể dựa trên ECC cho các client hỗ trợ chúng.

Tiêu chuẩn WebAuthn không phải là một tiêu chuẩn mã hóa, mà là một giao thức bảo mật cung cấp xác thực mạnh mẽ dựa trên khóa công khai cho các ứng dụng web, cho phép người dùng đăng nhập bằng sinh trắc học, thiết bị di động hoặc khóa bảo mật phần cứng (ví dụ: YubiKeys) thay vì mật khẩu. Do đó, WebAuthn cố ý không phụ thuộc vào loại mật mã khóa công khai nào thực sự được sử dụng, hãy cùng xem điều này được thực hiện như thế nào.

Giao thức bảo mật WebAuthn tạo điều kiện cho việc xác thực an toàn bằng mật mã giữa Người dùng và Relying Party. Về mặt kỹ thuật, điều này có nghĩa là Relying Party (một trang web muốn sử dụng passkey với người dùng của mình) cần trao đổi khóa qua trình duyệt với người dùng và authenticator của họ, sau đó authenticator sẽ lưu trữ khóa riêng tư trong module bảo mật phần cứng (HSM) cụ thể.

Đối với việc đăng ký passkey, có ba bước quan trọng:

• (1) Relying Party thông báo các thuật toán mã hóa được hỗ trợ: Relying party thông báo các thuật toán mã hóa được hỗ trợ thông qua PublicKeyCredentialCreationOptions.pubKeyCredParams cùng với các PublicKeyCredentialCreationOptions khác.
• (2) Authenticator của người dùng tạo cặp khóa: Authenticator kiểm tra danh sách pubKeyCredParams để tìm các thuật toán mã hóa mà nó hỗ trợ và tạo một cặp khóa cùng với một Credential ID duy nhất. Nó lưu trữ khóa riêng tư trong HSM và sau đó trả về khóa công khai và thuật toán mã hóa đã sử dụng cho trình duyệt. Sau đó, trình duyệt gửi một yêu cầu POST đến backend của Relying Party với attestationObject trong phần “authData”. Trong trường hợp không có thuật toán mã hóa nào được hỗ trợ khớp, quá trình tạo sẽ thất bại.
• (3) Relying Party trích xuất khóa công khai và lưu trữ nó: Relying party nhận attestationObject từ trình duyệt. Nó phân tích phần authData.credentialPublicKey và trích xuất khóa công khai. Cùng với khóa công khai, thông tin về thuật toán mã hóa đã sử dụng và Credential ID cũng được gửi lại cho relying party.

Đối với các lần đăng nhập/xác thực tiếp theo bằng passkey, các bước sau là cần thiết (chi tiết được đơn giản hóa):

• (1) Relying Party đưa ra một thử thách (challenge): Relying party tạo ra một thử thách ngẫu nhiên và cung cấp nó cho authenticator để ký.
• (2) Authenticator của người dùng ký thử thách: Authenticator ký thử thách bằng khóa khớp với yêu cầu xác thực và trả lại nó cùng với Credential ID cho Relying Party.
• (3) Relying Party xác thực chữ ký: Relying Party nhận thông tin và tra cứu khóa công khai được liên kết với Credential ID đã sử dụng. Sau đó, nó xác thực chữ ký bằng mật mã học sử dụng thuật toán mã hóa/ký đã được thống nhất trong quá trình đăng ký passkey.

Bằng cách xem xét cả hai trường hợp, chúng ta có thể thấy rằng chỉ khi đăng ký passkey, thông tin về khóa công khai và thuật toán mã hóa mới được truyền giữa các bên.

Đối với các sự kiện đăng nhập/xác thực tiếp theo bằng passkey, chỉ có thử thách và chữ ký là một phần của dữ liệu được truyền đi.

Tiêu chuẩn WebAuthn sử dụng IANA COSE Algorithm IDs để xác định các thuật toán mã hóa được sử dụng. Các ID Thuật toán COSE được sử dụng cả để thông báo các thuật toán được hỗ trợ trong pubKeyCredParams và để truyền loại cặp khóa thực sự được tạo trong credentialPublicKey. Chúng ta sẽ tập trung vào việc triển khai chúng trong hai phần tiếp theo.

Danh sách Thuật toán COSE của IANA bao gồm hơn 75 thuật toán có thể được sử dụng trên lý thuyết với Tiêu chuẩn WebAuthn. Hầu hết các thuật toán có ID âm là khóa công khai bất đối xứng và hầu hết các thuật toán có ID dương là đối xứng, nhưng đây chỉ là một quy ước vì có những ngoại lệ.

Như chúng ta đã chỉ ra trước đó, thuật toán mã hóa cần được hỗ trợ bởi Authenticator và backend của Relying Party để có thể được sử dụng trong quy trình WebAuthn. Vì hầu hết các relying party sử dụng các thư viện WebAuthn hiện có có quyền truy cập vào một loạt các thuật toán mã hóa, điều quan trọng hơn là xem xét những thuật toán nào được hỗ trợ bởi những authenticator nào:

(*) = Một phần nhỏ các khóa bảo mật (ví dụ: Yubikeys 5+, Solokey hoặc Nitrokey)\ Trích từ Bảng IANA: Xem danh sách đầy đủ tại đây

Như bạn có thể thấy từ bảng này, để hỗ trợ tất cả các authenticator quan trọng, RS256 và ES256 là đủ. Có một số bộ phận trong cộng đồng khuyến nghị tích hợp cả EdDSA để tăng cường bảo mật hơn nữa. Mặt khác, các Credential ID cũng cần được lưu trữ dường như dài hơn đáng kể đối với các khóa EdDSA. Cho đến hôm nay, bản dự thảo của W3C về Tiêu chuẩn WebAuthn Cấp 3 sắp tới đề xuất cả ba thuật toán.

Việc cấu hình các thuật toán mã hóa được hỗ trợ cho việc tạo passkey được thực hiện thông qua 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,
});

Ví dụ cho thấy cách các thuật toán được chỉ định trong: pubKeyCredParams bằng alg cho ID và thêm public-key làm loại của thuật toán. Ở dòng 29/30, PublicKeyCredentialCreationOptions được truyền đến authenticator thông qua API WebAuthn của trình duyệt. Việc loại bỏ hỗ trợ cho ES256 hoặc RS256 sẽ gây ra lỗi và tuyệt đối không được khuyến khích.

Là một ví dụ hoạt động, chúng ta sẽ chạy PublicKeyCredentialCreationOptions sau trên máy Mac trong Passkeys Debugger.

{
    "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"
    }
}

Phản hồi do authenticator tạo ra được gửi đến relying party (dưới dạng attestation) và trông như sau:

{
    "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": {}
}

Trong phần tiếp theo, chúng ta sẽ xem cách các khóa công khai và thuật toán mã hóa đã sử dụng có thể được trích xuất từ phản hồi.

Trước hết, chúng ta cần xem xét cách attestationObject thực sự được cấu trúc, bởi vì như chúng ta thấy ở trên, nó không được truyền đến Relying Party ở định dạng JSON.

attestationObject đóng một vai trò quan trọng trong quá trình đăng ký WebAuthn, đóng vai trò là một vùng chứa cho attestation statement do authenticator cung cấp. Đối tượng này cung cấp rất nhiều thông tin cần thiết để Relying Party (RP) xác minh nguồn gốc và tính toàn vẹn của thông tin xác thực khóa công khai mới được tạo.

Về cốt lõi, attestationObject là một cấu trúc phức tạp. Nó chủ yếu được mã hóa ở định dạng CBOR (Concise Binary Object Representation), sau đó được mã hóa bằng Base64URL. Nó đóng gói dữ liệu authenticator cùng với một attestation statement xác minh tính xác thực của thông tin. Bởi vì passkey được tạo với attestation “none” và do đó không mang theo attestation statement, chúng ta sẽ không đề cập đến điều này trong bài viết này. Lưu ý thêm: Chúng ta đã viết chủ yếu là CBOR vì cũng có các tiền tố CBOR không chuẩn liên quan do độ dài thay đổi cần thiết cho các phần mở rộng tùy chọn. Chúng ta sẽ không đi sâu vào vấn đề đó, một cuộc thảo luận về sự phức tạp có thể được tìm thấy tại đây.

Nguồn từ đặc tả WebAuthn

Trong dữ liệu authenticator (authData), khóa công khai mới được tạo, cùng với ID thông tin xác thực của người dùng, được lưu trữ an toàn và có thể được relying party truy xuất. Vì các nhà phát triển phải tiếp cận nhiệm vụ trích xuất khóa công khai từ attestationObject trong bất kỳ hệ thống dựa trên WebAuthn nào, việc hiểu kiến trúc của nó là rất quan trọng.

CBOR (Concise Binary Object Representation) là một định dạng dữ liệu được thiết kế để mã hóa dữ liệu một cách nhỏ gọn, hiệu quả và có thể mở rộng. Nó là dạng nhị phân, giúp nó nhỏ hơn và nhanh hơn để phân tích cú pháp so với mô hình dựa trên văn bản của nó là JSON. Ví dụ sau minh họa sự khác biệt giữa JSON và CBOR (Văn bản so với Nhị phân):

In đậm là Tên. In nghiêng là Corbado. (thông tin thêm có thể được tìm thấy trên https://cbor.io/)

Trong bối cảnh của WebAuthn, CBOR được sử dụng vì nhiều lý do:

• Liên kết với FIDO2 / CTAP: Vì CBOR được sử dụng trong các tiêu chuẩn cơ bản, việc hợp lý hóa việc phân tích và xử lý dữ liệu được thực hiện, vì cả WebAuthn và CTAP đều sử dụng cùng một lược đồ mã hóa nhỏ gọn.
• Tính nhỏ gọn: Mã hóa hiệu quả của CBOR làm cho nó trở thành một lựa chọn tuyệt vời cho lưu lượng truy cập web, nơi việc giảm thiểu kích thước dữ liệu có thể ảnh hưởng đáng kể đến hiệu suất, đặc biệt là qua mạng di động hoặc trong môi trường có băng thông hạn chế.
• Tính linh hoạt: CBOR hỗ trợ nhiều loại dữ liệu và cấu trúc, bao gồm mảng, map, chuỗi văn bản, chuỗi byte và các thẻ để mở rộng. Điều này làm cho nó đủ linh hoạt để xử lý các loại dữ liệu khác nhau và các cấu trúc phức tạp cần thiết cho các hoạt động của WebAuthn.
• Khả năng mở rộng: Định dạng được thiết kế để có thể mở rộng, có nghĩa là các tính năng mới có thể được thêm vào WebAuthn mà không phá vỡ khả năng tương thích với các triển khai hiện có.

Việc sử dụng CBOR đặc biệt phù hợp để mã hóa các khóa công khai và attestationObject vì nó cần xử lý các định dạng và độ dài khác nhau mà chúng ta đã thảo luận ở trên. Ví dụ, một khóa RSA sẽ có các thuộc tính và kích thước khác so với một khóa ECDSA. Trong attestationObject, các khóa công khai được lưu trữ ở định dạng Khóa COSE, dựa trên CBOR.

Một cấu trúc Khóa COSE được xây dựng trên một đối tượng map CBOR. Nó định nghĩa một cách có cấu trúc để biểu diễn khóa, bao gồm các loại khóa khác nhau và các tham số tương ứng của chúng, chẳng hạn như modulus và số mũ của RSA, hoặc tọa độ khóa công khai của đường cong elliptic. Định dạng tiêu chuẩn hóa này cho phép các khóa được tuần tự hóa và giải tuần tự hóa một cách nhất quán, bất kể thuật toán mật mã cơ bản của chúng, ngoài ID thuật toán mã hóa mà chúng ta đã thảo luận ở trên.

Bằng cách tận dụng CBOR và định dạng Khóa COSE, WebAuthn có thể tạo điều kiện cho một loạt các hoạt động mật mã trong khi đảm bảo payload vẫn nhỏ nhất có thể, và vẫn có thể thích ứng với các bản cập nhật trong tương lai của công nghệ mật mã. Lựa chọn này phù hợp với các mục tiêu của WebAuthn là cung cấp một giao thức an toàn, hiệu quả và tương thích với tương lai cho xác thực web.

Khi nói đến việc giải mã attestationObject trong WebAuthn, các nhà phát triển phải đối mặt với một quyết định quan trọng: phát triển một giải pháp tùy chỉnh hay tận dụng một thư viện đã có uy tín. Sự phức tạp và tính chất quan trọng của quá trình này không thể bị xem nhẹ. Việc triển khai thủ công giải mã Base64URL và CBOR, mặc dù khả thi về mặt kỹ thuật, nhưng lại có nguy cơ gây ra các lỗi nhỏ có thể làm tổn hại đến tính toàn vẹn của quá trình xác thực.

Để đảm bảo việc xác minh mật mã của chữ ký, cũng như tính chính xác của tất cả các bước xác thực khác, chúng tôi khuyến nghị mạnh mẽ nên sử dụng một thư viện WebAuthn đã được kiểm thử kỹ lưỡng và áp dụng rộng rãi. Các thư viện như vậy được xây dựng với chuyên môn về mã hóa để xử lý các chi tiết của việc giải mã và xác thực attestationObject, bao gồm:

• Phân tích định dạng CBOR một cách chính xác để trích xuất attestation statement và dữ liệu authenticator.
• Diễn giải định dạng Khóa COSE để lấy khóa công khai.
• Thực hiện các kiểm tra mật mã để xác thực chữ ký theo tiêu chuẩn WebAuthn.

Bằng cách dựa vào một thư viện uy tín, các nhà phát triển không chỉ tiết kiệm thời gian và tài nguyên mà còn có được sự yên tâm. Khóa công khai, sau khi được trích xuất và xác minh thông qua các công cụ đáng tin cậy này, sau đó có thể được lưu trữ an toàn trong cơ sở dữ liệu, sẵn sàng để sử dụng cho các phiên xác thực an toàn. Cách tiếp cận này đảm bảo tuân thủ các thông số kỹ thuật của giao thức và duy trì tình trạng bảo mật mong đợi trong các triển khai WebAuthn. Để đơn giản, chúng ta sẽ sử dụng SimpleWebauthn Debugger trả về một phiên bản được giải mã hoàn toàn với các trường CBOR được chuyển đổi thành JSON mở rộng:

{
    "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": {}
}

Thư viện SimpleWebAuthn được sử dụng để giải mã toàn bộ attestationObject. Như chúng ta có thể thấy, tất cả thông tin bây giờ đều có thể đọc được. Tất cả thông tin mật mã là một phần của credentialPublicKey, là một phần của authData, mà thư viện đã mở rộng thành câu lệnh parsedCredentialPublicKey. Trong đặc tả, có một số ví dụ về định dạng Khóa COSE trông như thế nào.

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

Đầu ra này thể hiện tất cả các yếu tố mật mã của credentialPublicKey được phân tích cú pháp gọn gàng thành dạng con người có thể đọc được. Trường hợp cụ thể này cho thấy một khóa EC2 cho thuật toán ES256, như được chỉ ra bởi tham số thuật toán và sự hiện diện của tọa độ x và y.

Ngược lại, đầu ra của một hệ thống Windows 10 trông như sau:

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

Ở đây, ID thuật toán là -257, tương ứng với RS256, và chúng ta có thể nhận thấy rằng các thuộc tính đặc trưng cho khóa công khai này khác biệt đáng kể so với các thuộc tính của một khóa ECDSA. Định dạng Khóa COSE cho phép chỉ định các thuộc tính duy nhất cho mỗi loại:

Ngoài ra, modulus của RSA dài hơn đáng kể so với các tọa độ đường cong elliptic được sử dụng trong khóa ES256, nhấn mạnh cuộc thảo luận trước đây của chúng ta về sự khác biệt về kích thước khóa và các yêu cầu cố hữu của các thuật toán mật mã khác nhau.

Sau khi đi qua những kiến thức cơ bản về mật mã khóa công khai và hiểu cách nó được tích hợp vào tiêu chuẩn WebAuthn / FIDO2, chúng tôi có hai khuyến nghị chính cho các relying party:

• Chọn đúng thuật toán mã hóa: Trong việc triển khai WebAuthn, điều quan trọng là sử dụng các thuật toán chính xác để có khả năng tương thích tối đa. Dựa trên các khuyến nghị hiện tại, sự kết hợp của RS256, ES256 và EdDSA là nên làm. RS256 và ES256 nổi bật do được hỗ trợ rộng rãi, và việc bao gồm EdDSA có thể tăng cường bảo mật ở những nơi có thể.
• Sử dụng các thư viện WebAuthn đã được kiểm thử kỹ lưỡng để trích xuất khóa công khai: Một khi bạn đã quyết định về các thuật toán, bước tiếp theo là tích hợp một thư viện WebAuthn đã được kiểm thử kỹ lưỡng. Một thư viện như vậy có thể xử lý thành thạo sự phức tạp của việc phân tích * attestationObject*. Sau khi thư viện đã trích xuất các khóa công khai và dữ liệu liên quan của nó, nó có thể được lưu trữ an toàn trong cơ sở dữ liệu. Định dạng được sử dụng bởi thư viện thường đảm bảo rằng khóa được lưu trữ theo cách có thể được đọc và sử dụng chính xác cho các mục đích xác thực trong tương lai.

Điều quan trọng là không 'phát minh lại bánh xe': hãy tận dụng kiến thức tập thể được tích hợp trong các thư viện đã được thiết lập. Việc triển khai tùy chỉnh có nguy cơ gây ra lỗi và lỗ hổng bảo mật có thể làm suy yếu hiệu quả của việc xác thực và bảo mật tổng thể của hệ thống.

Trong bài viết này, chúng ta đã tìm hiểu những kiến thức cơ bản về mật mã khóa công khai để trả lời ba câu hỏi cốt lõi ban đầu:

1. Các thuật toán mã hóa được hỗ trợ trong WebAuthn: WebAuthn được thiết kế để linh hoạt và hỗ trợ một loạt các thuật toán mã hóa, nổi bật bao gồm RSA (RS256), ECDSA (ES256) và EdDSA. Khả năng thích ứng này cho phép nó tích hợp liền mạch với các authenticator và nền tảng khác nhau, đảm bảo khả năng tương thích rộng rãi.
2. Chức năng của pubKeyCredParams trong việc tạo cặp khóa: pubKeyCredParams đóng một vai trò quan trọng trong giai đoạn đăng ký của quy trình WebAuthn bằng cách chỉ định những thuật toán mật mã nào mà relying party hỗ trợ. Điều này đảm bảo rằng các cặp khóa được tạo ra tương thích với cả authenticator của người dùng và các yêu cầu của relying party.
3. Chức năng của credentialPublicKey và việc trích xuất khóa công khai: credentialPublicKey được sử dụng để trích xuất các khóa công khai từ attestationObject do các authenticator cung cấp.

Bên cạnh đó, chúng ta đã nhấn mạnh sự độc lập của giao thức WebAuthn đối với các thuật toán mã hóa cụ thể, điều này giúp tăng cường đáng kể tính linh hoạt và khả năng tương thích với tương lai trước các phương pháp mật mã mới nổi. Chúng tôi hy vọng bài viết này cũng giúp các nhà phát triển khác khi gỡ lỗi và hiểu các khái niệm / vấn đề liên quan đến mật mã khóa công khai trong WebAuthn.