شرح WebAuthn pubKeyCredParams و credentialPublicKey: دور CBOR و COSE

1. مقدمة: pubKeyCredParams و credentialPublicKey

2. ما هو التشفير بالمفتاح العام؟

   2.1 كيف يعمل التشفير بالمفتاح العام؟

   2.2 الأنواع الشائعة لخوارزميات التشفير بالمفتاح العام

   2.3 التبني المتزايد للتشفير العام القائم على ECC

3. WebAuthn: كيف يُستخدم التشفير بالمفتاح العام في مفاتيح المرور؟

4. كيفية اختيار إعدادات pubKeyCredParams الصحيحة؟

   4.1 ما هي خوارزميات COSE ذات الصلة بـ WebAuthn؟

   4.2 تحديد مصفوفة pubKeyCredParams في pubKeyCredParams

5. كيفية استخراج المفتاح العام من attestationObject؟

   5.1 نظرة عامة: ما هو attestationObject؟

   5.2 ما هو تمثيل الكائنات الثنائية المختصر (CBOR)؟

   5.3 ما هو تنسيق مفتاح COSE؟

   5.4 فك تشفير وتحليل attestationObject

6. توصية

7. الخاتمة

في عالم الأمن الرقمي، أصبحت مفاتيح المرور (Passkeys) هي المعيار الجديد للمصادقة بدون كلمة مرور. في صميم هذه المفاتيح يكمن التشفير بالمفتاح العام (public-key cryptography)، المستخدم ضمن بروتوكول WebAuthn الذي تعتمد عليه مفاتيح المرور. من المهم جدًا فهم كيفية استخدام التشفير بالمفتاح العام في WebAuthn، خاصة عند إنشاء مفاتيح المرور واستخراجها وإدارتها وتخزينها، وذلك عند تصميم أو استخدام مصادقة Passkey. يتم تخزين المفتاح العام على خادم الطرف المعتمد (RP)، وهو الواجهة الخلفية للموقع الإلكتروني الذي يرغب في مصادقة المستخدم عبر مفاتيح المرور، بينما يتم تخزين المفتاح الخاص بشكل آمن في وحدة أمان الأجهزة (Hardware Security Module) حسب نظام التشغيل، سواء كان 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

إليك نظرة عامة على بعض الأنواع الشائعة من الخوارزميات المستخدمة في التشفير بالمفتاح العام:

الأساس الرياضي لتشفير المنحنى الإهليلجي (ECC)، بما في ذلك ECDSA و EdDSA، يتضمن خصائص المنحنيات الإهليلجية التي لن نغطيها في هذا المقال. ولكن من الواضح من الجدول أعلاه أن هناك مزايا تدفع إلى تبنيها. سنتناول أهمها في القسم التالي.

Become part of our Passkeys Community for updates & support.

Join

لقد تم تبني تشفير المنحنى الإهليلجي على نطاق واسع في الأجهزة المحمولة لأنها تستفيد من أحجام المفاتيح الأصغر، مما يجلب المزايا التالية:

• تقليل متطلبات التخزين: تتطلب مفاتيح ECC الأصغر مساحة تخزين أقل مقارنة بأساليب التشفير التقليدية مثل RSA. هذا مفيد بشكل خاص للأجهزة ذات موارد الذاكرة المحدودة، مما يسمح باستخدام أكثر كفاءة للمساحة. يوضح الجدول التالي تقريبًا لمستويات الأمان المقارنة والأحجام الفعلية للمفاتيح المستخدمة. يُقاس مستوى الأمان بالبت وعادة ما يتوافق مع شفرة مفتاح متماثل من نفس الحجم:

يشير مصطلح مستوى الأمان في هذا السياق إلى قوة نظام التشفير، وتحديدًا مستوى الصعوبة التي يواجهها المهاجم للتغلب على الإجراءات الأمنية. يُقاس بشكل عام بالبت ويمثل مقدار العمل (عدد العمليات) الذي سيكون مطلوبًا لكسر التشفير أو تزوير توقيع. مع زيادة مستوى الأمان، تصبح مزايا الحجم واضحة حتى تصل إلى نسب حجم مفتاح تبلغ 1:30.

• أداء محسن: تتيح المفاتيح الأصغر عمليات تشفير أسرع، وهو أمر حاسم للأجهزة ذات قدرة المعالجة المنخفضة. ينتج عن هذا أنشطة تشفير وفك تشفير أسرع، مما يعزز الأداء العام واستجابة تطبيقات الهاتف المحمول. اعتمادًا على نوع المعايير، تتراوح زيادة السرعة من 10 إلى 40 ضعفًا في التنفيذ. إليك مثال على بيانات قياس الأداء التي أجرتها AWS عند تنفيذ ECDSA لـ Cloudfront في عام 2018:

• كفاءة بطارية محسنة: مع معالجة أكثر كفاءة من المفاتيح الأصغر، يمكن لعمليات ECC أن تستهلك طاقة أقل. يعد هذا الحفاظ على الطاقة أمرًا حيويًا للأجهزة المحمولة، حيث يمثل الحفاظ على عمر البطارية تحديًا مستمرًا.

هذه العوامل تجعل ECC مناسبًا بشكل خاص لبيئات الأجهزة المحمولة، حيث يكون تحسين التخزين وسرعة المعالجة واستهلاك الطاقة أمرًا ضروريًا. نتيجة لذلك، يُفضل ECC بشكل متزايد في الحوسبة المتنقلة لقدرته على توفير أمان قوي دون المساس بأداء الجهاز. ومع ذلك، حتى اليوم، لا تزال هناك الكثير من الإصدارات القديمة من البروتوكولات واسعة الانتشار مثل TLS (المستخدم لـ HTTPS أو FTPS أو SMTPS) و SSH و IPsec التي لا تزال تدعم RSA ولكنها بدأت في تقديم متغيرات قائمة على ECC للعملاء الذين يدعمونها.

معيار WebAuthn ليس معيار تشفير، بل هو بروتوكول أمني يوفر مصادقة قوية قائمة على المفتاح العام لتطبيقات الويب، مما يمكّن المستخدمين من تسجيل الدخول باستخدام القياسات الحيوية أو الأجهزة المحمولة أو مفاتيح الأمان المادية (مثل YubiKeys) بدلاً من كلمات المرور. لذلك، فإن WebAuthn محايد عن قصد بشأن التشفير القائم على المفتاح العام المستخدم بالفعل، دعنا نلقي نظرة على كيفية تحقيق ذلك.

يسهل بروتوكول أمان WebAuthn المصادقة الآمنة بالتشفير بين المستخدم و الطرف المعتمد. من الناحية الفنية، هذا يعني أن الطرف المعتمد (موقع ويب يريد استخدام مفاتيح المرور مع مستخدميه) يحتاج إلى تبادل المفاتيح عبر المتصفح مع المستخدم وأداة المصادقة الخاصة به والتي تقوم بعد ذلك بتخزين المفتاح الخاص في وحدة أمان الأجهزة المحددة (HSM).

للتسجيل / إنشاء مفاتيح المرور، هناك ثلاث خطوات مهمة:

• (1) يشير الطرف المعتمد إلى خوارزميات التشفير المدعومة: يشير الطرف المعتمد إلى خوارزميات التشفير المدعومة عبر PublicKeyCredentialCreationOptions.pubKeyCredParams مع خيارات PublicKeyCredentialCreationOptions الأخرى.
• (2) تقوم أداة المصادقة الخاصة بالمستخدم بإنشاء زوج المفاتيح: تتحقق أداة المصادقة من قائمة pubKeyCredParams بحثًا عن خوارزميات التشفير التي تدعمها وتنشئ زوجًا من المفاتيح إلى جانب معرف اعتماد فريد. تقوم بتخزين المفتاح الخاص داخل HSM ثم تعيد المفتاح العام وخوارزمية التشفير المستخدمة إلى المتصفح. بعد ذلك، يرسل المتصفح طلب POST إلى الواجهة الخلفية للطرف المعتمد مع attestationObject في قسم 'authData'. في حالة عدم وجود تطابق في خوارزميات التشفير المدعومة، ستفشل عملية الإنشاء.
• (3) يستخرج الطرف المعتمد المفتاح العام ويخزنه: يتلقى الطرف المعتمد attestationObject من المتصفح. يقوم بتحليل قسم authData.credentialPublicKey ويستخرج المفتاح العام. إلى جانب المفتاح العام، يتم أيضًا إرسال معلومات حول خوارزمية التشفير المستخدمة ومعرف الاعتماد إلى الطرف المعتمد.

لتسجيل الدخول / المصادقة اللاحقة باستخدام مفاتيح المرور، تكون الخطوات التالية ضرورية (التفاصيل مبسطة):

• (1) يقدم الطرف المعتمد تحديًا: يقوم الطرف المعتمد بإنشاء تحدٍ عشوائي ويقدمه إلى أداة المصادقة للتوقيع.
• (2) تقوم أداة المصادقة الخاصة بالمستخدم بتوقيع التحدي: تقوم أداة المصادقة بتوقيع التحدي بالمفتاح الذي يطابق طلب المصادقة وتعيده مع معرف الاعتماد إلى الطرف المعتمد.
• (3) يتحقق الطرف المعتمد من صحة التوقيع: يتلقى الطرف المعتمد المعلومات ويبحث عن المفتاح العام المرتبط بمعرف الاعتماد المستخدم. ثم يتحقق من صحة التوقيع بالتشفير باستخدام خوارزمية التشفير/التوقيع المتفق عليها أثناء تسجيل مفاتيح المرور.

بالنظر إلى كلتا الحالتين، يمكننا أن نرى أنه فقط عند التسجيل / إنشاء مفاتيح المرور يتم نقل معلومات المفتاح العام وخوارزمية التشفير بين الأطراف الفاعلة.

بالنسبة لأحداث تسجيل الدخول / المصادقة اللاحقة باستخدام مفاتيح المرور، يكون التحدي والتوقيع فقط جزءًا من البيانات المنقولة.

يستخدم معيار WebAuthn معرفات خوارزمية COSE من IANA لتحديد خوارزميات التشفير المستخدمة. تُستخدم معرفات خوارزمية COSE لكل من الإشارة إلى الخوارزميات المدعومة في pubKeyCredParams ولنقل نوع زوج المفاتيح الذي تم إنشاؤه بالفعل في credentialPublicKey. سنركز على تنفيذها في القسمين التاليين.

تتضمن قائمة خوارزميات COSE من IANA أكثر من 75 خوارزمية يمكن استخدامها نظريًا مع معيار WebAuthn. معظم الخوارزميات ذات المعرف السالب هي مفتاح عام غير متماثل ومعظم الموجبة متماثلة، ولكن هذا مجرد عرف حيث توجد استثناءات لذلك.

كما أشرنا من قبل، يجب أن تكون خوارزمية التشفير مدعومة من قبل أداة المصادقة والواجهة الخلفية للطرف المعتمد لكي يتم استخدامها في عملية WebAuthn. نظرًا لأن معظم الأطراف المعتمدة تستخدم مكتبات WebAuthn الحالية التي لديها إمكانية الوصول إلى مجموعة واسعة من خوارزميات التشفير، فمن الأهم النظر إلى الخوارزميات التي تدعمها أدوات المصادقة المختلفة:

(*) = جزء صغير من مفاتيح الأمان (مثل Yubikeys 5+ أو Solokey أو Nitrokey) مقتطف من جدول IANA: انظر القائمة الكاملة هنا

كما ترى من هذا الجدول، لدعم جميع أدوات المصادقة المهمة، فإن RS256 و ES256 كافيان. هناك بعض الأجزاء من المجتمع توصي بدمج EdDSA أيضًا لزيادة تحسين الأمان. من ناحية أخرى، يبدو أن معرفات الاعتماد التي تحتاج أيضًا إلى تخزين أطول بكثير لمفاتيح EdDSA. حتى اليوم، تقترح مسودة المحررين من W3C حول معيار WebAuthn من المستوى 3 القادم جميع الخوارزميات الثلاث.

يتم تكوين خوارزميات التشفير المدعومة لإنشاء مفتاح المرور عبر 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,
});

يوضح المثال كيفية تحديد الخوارزميات داخل: pubKeyCredParams بواسطة alg للمعرف وإضافة public-key كنوع للخوارزمية. في السطر 29/30، يتم تمرير PublicKeyCredentialCreationOptions إلى أداة المصادقة عبر واجهة برمجة تطبيقات WebAuthn الخاصة بالمتصفح. سيؤدي إزالة الدعم لـ ES256 أو RS256 إلى حدوث أخطاء ولا يوصى به بشدة.

كمثال عملي، سنقوم بتشغيل PublicKeyCredentialCreationOptions التالية على جهاز Mac في 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"
    }
}

الاستجابة التي تنتجها أداة المصادقة يتم إرسالها إلى الطرف المعتمد (كـ 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، حيث يعمل كحاوية لـ بيان المصادقة الذي تقدمه أداة المصادقة. يوفر هذا الكائن الكثير من المعلومات اللازمة للطرف المعتمد (RP) للتحقق من أصل وسلامة بيانات اعتماد المفتاح العام التي تم إنشاؤها حديثًا.

في جوهره، يعد attestationObject بنية معقدة. يتم ترميزه في الغالب بتنسيق CBOR (تمثيل الكائنات الثنائية المختصر)، والذي يتم بعد ذلك ترميزه بترميز Base64URL. وهو يغلف بيانات أداة المصادقة جنبًا إلى جنب مع بيان attestation الذي يتحقق من صحة المعلومات. نظرًا لأن مفاتيح المرور يتم إنشاؤها باستخدام attestation 'none' وبالتالي لا تحمل بيان attestation، فلن نغطي هذا في هذا المقال. كملاحظة جانبية: كتبنا في الغالب CBOR لأنه توجد أيضًا بادئات CBOR غير قياسية بسبب الأطوال المتغيرة اللازمة للملحقات الاختيارية. لن نتعمق في ذلك، يمكن العثور على مناقشة حول التعقيدات هنا.

مأخوذ من مواصفات WebAuthn

ضمن بيانات أداة المصادقة (authData)، يتم تخزين المفتاح العام الذي تم إنشاؤه حديثًا، إلى جانب معرف اعتماد المستخدم، بشكل آمن ويمكن استرداده من قبل الطرف المعتمد. نظرًا لأنه يجب على المطورين التعامل مع مهمة استخراج المفتاح العام من attestationObject في أي نظام قائم على WebAuthn، فإن فهم بنيته أمر مهم.

CBOR (تمثيل الكائنات الثنائية المختصر) هو تنسيق بيانات مصمم لترميز البيانات بطريقة مدمجة وفعالة وقابلة للتوسيع. إنه ثنائي، مما يجعله أصغر وأسرع في التحليل من نظيره النصي JSON. يوضح المثال التالي كيف يختلف JSON و CBOR (نصي مقابل ثنائي):

العريض هو Name. المائل هو Corbado. (يمكن العثور على مزيد من المعلومات على https://cbor.io/)

في سياق WebAuthn، يتم استخدام CBOR لعدة أسباب:

• الارتباط بـ FIDO2 / CTAP: نظرًا لاستخدام CBOR في المعايير الأساسية، يتم تبسيط تحليل ومعالجة البيانات، حيث يستخدم كل من WebAuthn و CTAP نفس نظام الترميز المدمج.
• الاكتناز: يجعل ترميز CBOR الفعال خيارًا ممتازًا لحركة مرور الويب حيث يمكن أن يؤثر تقليل حجم البيانات بشكل كبير على الأداء، خاصة عبر شبكات الهاتف المحمول أو في البيئات التي يكون فيها عرض النطاق الترددي مقيدًا.
• المرونة: يدعم CBOR مجموعة متنوعة من أنواع البيانات والهياكل، بما في ذلك المصفوفات والخرائط والسلاسل النصية والسلاسل البايتية والعلامات للتوسيع. هذا يجعله متعدد الاستخدامات بما يكفي للتعامل مع أنواع البيانات المختلفة والهياكل المعقدة اللازمة لعمليات WebAuthn.
• قابلية التوسيع: تم تصميم التنسيق ليكون قابلاً للتوسيع، مما يعني أنه يمكن إضافة ميزات جديدة إلى WebAuthn دون كسر التوافق مع التطبيقات الحالية.

يعد استخدام CBOR مناسبًا بشكل خاص لترميز المفاتيح العامة و attestationObject لأنه يحتاج إلى التعامل مع التنسيقات والأطوال المختلفة التي ناقشناها أعلاه. على سبيل المثال، سيكون لمفتاح RSA سمات وأحجام مختلفة مقارنة بمفتاح ECDSA. ضمن attestationObject، يتم تخزين المفاتيح العامة بتنسيق مفتاح COSE، والذي يعتمد على CBOR.

تُبنى بنية مفتاح COSE على كائن خريطة CBOR. وهي تحدد طريقة منظمة لتمثيل المفاتيح، تشمل أنواعًا مختلفة من المفاتيح والمعلمات المقابلة لها، مثل معامل RSA والأس، أو إحداثيات المفتاح العام للمنحنى الإهليلجي. يسمح هذا التنسيق الموحد بتحويل المفاتيح إلى تسلسل وفك تسلسلها بطريقة متسقة، بغض النظر عن خوارزمية التشفير الأساسية الخاصة بها، بالإضافة إلى معرف خوارزمية التشفير الذي ناقشناه أعلاه.

من خلال الاستفادة من CBOR وتنسيق مفتاح COSE، يمكن لـ WebAuthn تسهيل مجموعة واسعة من عمليات التشفير مع ضمان بقاء الحمولة صغيرة قدر الإمكان، والبقاء قابلاً للتكيف مع التحديثات المستقبلية في تكنولوجيا التشفير. يتماشى هذا الاختيار مع أهداف WebAuthn لتوفير بروتوكول آمن وفعال ومتوافق مع المستقبل لمصادقة الويب.

عندما يتعلق الأمر بفك تشفير attestationObject داخل WebAuthn، يواجه المطورون قرارًا مهمًا: تطوير حل مخصص أو الاستفادة من مكتبة راسخة. لا يمكن المبالغة في تعقيد وأهمية هذه العملية. التنفيذ اليدوي لفك تشفير Base64URL و CBOR، على الرغم من أنه ممكن تقنيًا، فإنه يقدم خطر الأخطاء الدقيقة التي يمكن أن تعرض سلامة عملية المصادقة للخطر.

لضمان التحقق التشفيري من التوقيع، وكذلك دقة جميع خطوات التحقق الأخرى، ننصح بشدة باستخدام مكتبة WebAuthn مجربة ومعتمدة على نطاق واسع. تم بناء هذه المكتبات بخبرة في التشفير للتعامل مع تفاصيل فك تشفير والتحقق من attestationObject، بما في ذلك:

• تحليل تنسيق CBOR بشكل صحيح لاستخراج بيان attestation وبيانات أداة المصادقة.
• تفسير تنسيق مفتاح COSE لاسترداد المفتاح العام.
• إجراء فحوصات تشفيرية للتحقق من صحة التوقيع وفقًا لمعيار WebAuthn.

بالاعتماد على مكتبة حسنة السمعة، لا يوفر المطورون الوقت والموارد فحسب، بل يكتسبون أيضًا راحة البال. يمكن بعد ذلك تخزين المفتاح العام بأمان في قاعدة البيانات، بعد استخراجه والتحقق منه من خلال هذه الأدوات الموثوقة، ليكون جاهزًا للاستخدام في جلسات المصادقة الآمنة. يضمن هذا النهج الالتزام بمواصفات البروتوكول ويحافظ على الوضع الأمني المتوقع في تطبيقات WebAuthn. للتبسيط، سنستخدم SimpleWebauthn Debugger الذي يعيد إصدارًا مفككًا بالكامل مع تحويل حقول CBOR إلى JSON موسع:

{
    "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 بالكامل. كما نرى، جميع المعلومات الآن قابلة للقراءة. جميع المعلومات التشفيرية هي جزء من credentialPublicKey وهو جزء من authData، والذي قامت المكتبة بتوسيعه إلى بيان parsedCredentialPublicKey. في المواصفات، هناك عدة أمثلة على شكل تنسيق مفتاح COSE.

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

يعرض هذا الإخراج جميع العناصر التشفيرية لـ credentialPublicKey محللة بدقة في شكل يمكن قراءته من قبل الإنسان. يكشف هذا المثال المحدد عن مفتاح EC2 لخوارزمية ES256، كما هو موضح بواسطة معلمة الخوارزمية ووجود إحداثيات x و y.

في المقابل، يبدو إخراج نظام 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
    }
}

هنا، معرف الخوارزمية هو -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.