Passkeys are a secure and user-friendly approach to authentication that can also be used to create and securely store crypto wallets, thanks to their use of elliptic curve cryptography.
في هذا المنشور، سنغطي كيفية عمل مفاتيح المرور، ونستكشف مخاطر استخدام مفاتيح المرور لمحافظ العملات المشفرة، ونستكشف كيفية تمكين التجريد عن الحساب لاستخدام مفاتيح المرور عندما يتم دمجها مع العقود الذكية.
هذا يتيح للمستخدمين تسجيل الدخول بسهولة والتفاعل مع التطبيقات بطريقة معتمدة دون الحاجة إلى تخزين بيانات الاعتماد الحساسة؛ مما يوفر تجربة سلسة وأمان إضافي ضد اختراقات البيانات ونقاط الهجوم الشائعة مثل الصيد الاحتيالي.
على معظم الأجهزة، مثل iPhone، يتم تخزين مفاتيح المرور داخل الأجهزة المتخصصة المسماة الحصن الآمن؛ بيئة معزولة مخصصة لحماية البيانات الحساسة حتى لو تم اختراق المعالج الرئيسي.
لتوقيع المعاملة بمفتاح مرور خاص، يتم إرسال المعاملة إلى الأجهزة الأمنية، حيث يتم توقيعها، ومن ثم يتم إخراج التوقيع الناتج. طوال هذه العملية، لا يحصل صاحب المفتاح الخاص أو مطور التطبيق على إمكانية الوصول إلى المفتاح الخاص؛ بل يتلقون فقط التواقيع المولدة.
يوفر ذلك أمانًا محسنًا للمستخدم، حيث أن المفتاح الخاص عادةً لا يتم تحميله في ذاكرة التطبيق، مما يقلل من مخاطر التعرض للهجمات المحتملة. على سبيل المثال، على الايفون، لا يمكن للمستخدم حتى الوصول إلى قيمة المفتاح السري ضمن إعداداته، حيث يتم إنشاء المفتاح وتخزينه في أجهزة مخصصة غير قابلة للوصول عن طريق الواجهة.
ومع ذلك، هناك اختلاف هام يدخل في تعقيد استخدام مفاتيح المرور لحسابات سلسلة الكتل؛ تستخدم مفاتيح المرور منحنى بيضوي مختلف عن حسابات سلسلة الكتل.
بينما تستخدم كل من Apple و Android و WebAuthn منحنى secp256r1 (AKA P-256) لمفاتيح المرور ، تستخدم حسابات blockchain المنحنى الإهليلجي secp256k1.
هذا يعني أن المعاملات الموقعة بواسطة المفتاح الخاص لتذييل الصفحة لا يتم فهمها (وبالتالي رفضها) من قبل سلاسل الكتل مثل إثيريوم أو أبستراكت. التوقع الافتراضي لسلاسل الكتل هو أن تكون المعاملة موقعة بواسطة زوج مفاتيح تم إنشاؤه على منحنى secp256k1.
نظرا لأن المحافظ العادية (EOA) يتم إنشاؤها على منحنى k1 ، فإن محافظ العقود الذكية مطلوبة ، حيث يمكن أن تتضمن منطقا مخصصا يتحقق من المعاملات الموقعة بواسطة المفاتيح الخاصة التي تم إنشاؤها بواسطة مفاتيح المرور قبل الإذن بتنفيذ المعاملة.
تفتقر النسخة k1 من المنحنى أيضًا إلى بعض الميزات مثل المعاملات الإضافية التي تجعل secp256r1 أكثر تعقيدًا قليلاً، مما يعني أن secp256k1 أكثر كفاءة حسابياً لإنشاء المفاتيح وإنشاء وتحقق التوقيع.
على الرغم من عدم وجود ثغرات مباشرة تم العثور عليها ، إلا أنه هناك أيضًا نظريات المؤامرة التي تفترض أن بيتكوين اختارت استخدام منحنى k1 على منحنى r1 المعتمد بشكل أكبر لتجنب أي إمكانية لوجود فتحة خلفية قد تكون تم إدخالها سراً من قبل وكالات حكومية مثل NSA ، نظرًا لتورطهم في تطوير المعايير التشفيرية المعتمدة من قبل NIST.
المكتبات مفتوحة المصدر مثل مدقق P256 مفتوح المصدر لدايموتم بناء بوابات للتحقق من التوقيعات على منحنى secp256r1 داخل العقود الذكية المكتوبة بلغة Solidity.
على الإيثيريوم، يعني هذا أنه يمكنك استخدام العقود الذكية المبنية باستخدام Gate.comمعيار جمع حساب ERC-4337للتحقق من توقيع r1 لعملية المستخدم في الداخلvalidateUserOpوظيفة محفظة العقد الذكي.

على النحو التجريدي، التجريبية الأصلية للحسابيتيح لمحافظ العقود الذكية تقديم المعاملات مع حقل التوقيع مضبوطًا كالرسالة الموقعة بواسطة المفتاح الخاص للمفتاح المروري. إذا كان الحساب الذي أرسل المعاملة عقدًا ذكيًا يتضمن منطقًا للتحقق من توقيعات r1 (في تحقق من المعاملةعندما يتم تأكيد الوظيفة، يتم قبول المعاملة.

محافظ العقد الذكية تقدم مزيدًا من المرونة من المحافظ EOA (Externally Owned Accounts) التقليدية ونظرًا لأنها يمكن أن تتضمن رمز EVM التعسفي، لديها القدرة على التحقق من التواقيع (أي التفويض للمعاملات) من أزواج المفاتيح التي تم إنشاؤها على منحنى الرقم البياني r1.
RIP-7212 (Rollup Improvement Proposal) proposes the addition of a precompiled smart contract to Ethereum L2s for more gas-efficient signature verification on the r1 curve. While this is not yet included on Ethereum, EVM-compatible scaling solutions such as Abstract have already implemented this and provide a 100x gas reduction for r1 signature verifications.
هذا خيار تصميم مقصود لتجنب الهجمات الاحتيالية ، ومع ذلك ، يشكل عيبًا كبيرًا للمستخدمين الذين يقدرون الاحتفاظ بالأمان بأنفسهم ، حيث يرتبط محفظتك مباشرة بتطبيق واحد فقط ؛ وهذا يعني:





