تم تصميم أجهزة توقيع الأجهزة لحماية المستخدم من مختلف نواقل الهجوم الشائعة ، مثل:

• الوصول غير المصرح به واستخراج البذور
• تصيب البرامج الضارة محفظة البرامج المرتبطة
• نقاط ضعف البرامج على الجهاز نفسه

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

ومع ذلك ، قد لا يزال لدى بعض المستخدمين مخاوف. ما الذي يمنع الشركة نفسها من إخفاء أ الباب الخلفي في الأجهزة؟

في الحجز الذاتي ، نحن لا تثق, نتحقق.
ولكن يمكن للمستخدم في الحقيقة تحقق من أن الجهاز لا يحتوي على باب خلفي؟

هذا هو السؤال الرئيسي الذي يتناوله هذا المقال. بتعبير أدق ، تتناول هذه المقالة الموضوعات التالية:

• ما هو الباب الخلفي ، ولماذا من الصعب ، إن لم يكن من المستحيل ، إثبات عدم وجوده ؛
• لماذا يمكن للمستخدمين فقط حماية أنفسهم من هذا الخطر ؛
• كيف يتيح برنامج miniscript حلولًا عملية لهذا التحدي لمحافظ البيتكوين.

من خلال كونها أول محفظة أجهزة تدعمها نص صغير، نأمل أن نلهم المطورين لبناء حلول آمنة وترقية صناعتنا بأكملها ، والقضاء على فرصة حدوث مثل هذه المخاطر الشاملة.

كيفية بناء ملف غير مستتر جهاز التوقيع

دعونا نوضح الأمر بوضوح: لا يمكنك ذلك.

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

الحل الذي يتم الترويج له كثيرًا لهذه المشكلة هو المصدر المفتوح: بعد كل شيء ، إذا كان بإمكانك فحص الكود ، فما الخطأ الذي يمكن أن يحدث؟

ومع ذلك ، فإن الحقيقة أكثر تعقيدًا. نظرًا لأن البائع يقوم بتجميع الأجهزة ، يمكن احتواء باب خلفي بالكامل بداخله. يمكن تصميم الجهاز بحيث يتجاهل البرنامج في نقاط معينة وتنفيذ تعليمات برمجية ضارة بدلاً من ذلك.

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

كيفية الباب الخلفي لمحفظة الأجهزة

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

توليد البذور

توفر لك العديد من الأجهزة القدرة على إنشاء بذرة (تسمى أيضًا ملف عبارة الاسترداد السرية) مباشرة على الجهاز باستخدام ملف مولد رقم عشوائي حقيقي.

😈 يمكن للجهاز الشرير أن يولد بذورًا تبدو عشوائية ولكن يمكن للمهاجم توقعها.

🛡️ يمكن للمستخدمين المتمرسين التحايل على هذه المشكلة عن طريق إنشاء ذاكرة بدون اتصال بالإنترنت. بالإضافة إلى ذلك ، يتم دمج ملف عبارة المرور يمكن أيضًا إنشاء بذرة مستقلة تمامًا لا يستطيع بائع الأجهزة التنبؤ بها. وتتمثل المقايضة في أنه يجب على المستخدمين التأكد من قيامهم بعمل نسخة احتياطية من عبارة المرور بشكل صحيح بالإضافة إلى كلمات ذاكري.

اشتقاق المفتاح العام

تعمل محافظ الأجهزة على اشتقاق وتصدير ملف المفاتيح العامة (أيضا يسمى com.xpubs، باختصار ل موسع المفتاح العمومي على النحو المحدد في بيب-32. com.xpubs تُستخدم لتوليد العناوين الممكنة لتلقي العملات المعدنية.

😈 يمكن للجهاز الشرير إرجاع المفاتيح العامة التي يتحكم فيها المهاجم بدلاً من المفاتيح الصحيحة المشتقة من الأصل.

🛡️ يمكن للمستخدمين التحقق من صحة المشتق xpub على جهاز آخر غير متصل بالإنترنت. ومع ذلك ، فإن إدخال البذور على الأجهزة الأخرى يحمل مخاطره الخاصة. قد يعتبر المستخدمون المهتمون بالأمان أي جهاز وصل إلى البذور على أنه خطير ، ومن المحتمل أن يؤدي إلى تدميرها. قد يكافح المستخدم العادي لتنفيذ هذا الإجراء بشكل صحيح أثناء إدارة المخاطر الإضافية.

تسريب المعلومات

An فجوة الهواء كثيرًا ما يُقترح كحل لمنع الأجهزة الخبيثة أو المخترقة من اختراق المفاتيح الخاصة. بعد كل شيء ، إذا كان الجهاز لا يمكنه الاتصال بالعالم الخارجي ، فلا يمكنه فعل أي شيء ضار ، أليس كذلك؟

ليس تماما!

يمكن للجهاز دائمًا الاتصال عندما يكون قيد الاستخدام: فهو ينتج تواقيع. تنتهي هذه التوقيعات داخل المعاملات التي يتم بثها وتخزينها إلى الأبد على blockchain.

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

😈 قد ينتج عن الجهاز المحتال توقيعات غير عشوائية تكشف ، عبر العديد من المعاملات ، عن البذرة للمهاجم!

سيتعين على المهاجم الناجح في تثبيت مثل هذا الباب الخلفي فقط انتظار ظهور التوقيعات الضارة على blockchain حتى يكون لديه معلومات كافية لإعادة بناء البذور بأكملها.

🛡️ بالنسبة لتوقيعات ECDSA ، باستخدام طريقة موحدة لاشتقاق nonce بشكل حتمي (مثل RFC6979) يحبط هذا الهجوم ، بشرط أن يتحقق المرء من أن التوقيع الناتج يطابق التوقيع المتوقع. ومع ذلك ، فإن ضمان هذه الحالة يتطلب تحميل جهاز ثان بنفس البذرة ، مما يؤدي إلى نفس المشكلات العملية المذكورة في القسم السابق.

🛡️ نهج مثير للاهتمام هو استخدام طريقة ذكية القوة الجهاز لاختيار رقم عشوائي فعليًا. بروتوكول لهذا الغرض ، والمعروف باسم مكافحة exfil or مكافحة klepto، يتم تنفيذه حاليًا في محافظ أجهزة Blockstream Jade و ShiftCrypto BitBox02. اقرأ المزيد مدونة ShiftCrypto، والذي يتضمن أيضًا وصفًا تقنيًا لكيفية تنفيذ مثل هذا الهجوم.

طيب اذن الا يوجد امل؟

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

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

في منشور المدونة هذا ، نحن مهتمون بشكل أساسي بهذه الأنواع من الإجراءات: في حين أن الاستراتيجيات التي تؤدي إلى تفاقم تجربة المستخدم بشكل كبير قد تكون جذابة للمستخدمين المتمرسين ، فمن المحتمل أن يصنعوا الأشياء أسوأ من الناحية العملية للمستخدمين الأقل مهارة تقنيًا - وهي الغالبية العظمى.

نموذج الأمان

النموذج القياسي لأجهزة التوقيع

تهدف الشركات المصنّعة للموقّعين على الأجهزة إلى حماية المستخدمين من مجموعة متنوعة من التهديدات المحتملة (لمزيد من التفاصيل ، راجع نموذج التهديد). في هذه المقالة ، نركز على خاصية واحدة مهمة للغاية ، يمكن تلخيصها على النحو التالي:

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

الموافقة مطلوبة لأي إجراء حساس ، خاصة التوقيعات. ستكون حماية البذور غير مجدية إذا تمكنت البرامج الضارة من إنتاج توقيعات على رسائل عشوائية ، مثل معاملة تستنزف جميع الأموال!

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

لذلك ، فإن البرامج الثابتة والتطبيقات التي تعمل على جهاز توقيع الأجهزة تأخذ في الاعتبار محفظة البرنامج بطبيعتها غير موثوق بها وغير جدير بالثقة.

نموذج أمان مضاد للباب الخلفي لمحافظ البرامج

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

ومن ثم ، لا يمكن أن يكون هذا من ممتلكات جهاز: بدلاً من ذلك ، إنها ملكية خاصة بـ محفظة البرمجيات يثبت. يمكننا تلخيصها على النحو التالي:

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

قد يبدو هذا غير منطقي ، لأنه يتعارض بشكل مباشر مع نموذج الأمان القياسي المفصل أعلاه. ومع ذلك ، فإن "عدم وجود باب خلفي" يعني "القيام بالضبط بما يفترض بهم القيام به". نظرًا لأن محفظة البرنامج هي ملف شمس واجهة بين جهاز التوقيع والعالم الخارجي ، إنه المكان الوحيد الذي يمكن فيه فرض الحماية ضد سوء السلوك - سواء كان ذلك بسبب خطأ أو اختراق صريح للجهاز.

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

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

دور المخطوطة المصغرة

يزود برنامج Miniscript مطوري المحفظة بالقدرة على الاستفادة الكاملة من الميزات المتقدمة لسيناريو البيتكوين. للحصول على نظرة عامة على الاحتمالات المذهلة لإلغاء قفل البرنامج المصغر ، يرجى الرجوع إلى منشورنا السابق في المدونة. قد ترغب أيضًا في الاستماع إلى الحلقة 452 من ستيفان ليفيرا بودكاست لمناقشة ما يجلبه المصغر إلى مشهد البيتكوين.

يدعم تطبيق Ledger Bitcoin البرنامج المصغر منذ إصداره 2.1.0 ، والذي تم نشره في فبراير 2023. في مؤتمر Bitcoin 2023 في ميامي ، أعلنت Wizardsardine عن الإصدار 1.0 من محفظة ليانا، أول محفظة تم نشرها استنادًا إلى miniscript.

الفكرة الأساسية لهذا المنشور هي أنه يمكن حماية حساب محفظة البيتكوين ليس فقط بحساب واحد ، ولكن أيضًا متعدد مفاتيح. هذا يسمح لأطر أمان مرنة حيث حتى الفشل التام أو اختراق مفتاح لا يكون كارثيًا.

تأملات Multisig

تعد Multisig ترقية مهمة في قوة حل الحجز الذاتي. من خلال الاستفادة من قابلية برمجة Bitcoin Script ، فإنه يتيح إنشاء محافظ تتطلب مفاتيح متعددة بدلاً من مفتاح واحد فقط. أ k-من-n تتطلب محفظة multisig مزيجًا من k التوقيعات الصالحة ، من إجمالي n ممكن منها.

ومع ذلك ، يضع multisig أيضًا عبئًا على المستخدم UX ، ويقدم فرصًا جديدة للأخطاء. يوفر إعداد 3 من 3 multisig ، الذي يتضمن ثلاثة مفاتيح مختلفة تم نسخها احتياطيًا بشكل آمن في مواقع منفصلة ، أمانًا قويًا ... ولكنه يعني أيضًا أنه إذا كان عزباء المفتاح مفقود ، تصبح العملات المعدنية غير قابلة للوصول بشكل دائم!

لذلك ، تميل الإعدادات التي تقدم المزيد من التكرار (مثل 2 من 3 أو 3 من 5) إلى أن تكون أكثر شيوعًا: في حالة فقد مفتاح واحد ، لا يزال بإمكان المفاتيح الأخرى تسهيل الاسترداد. لكن هذا يقدم مقايضة: إذا تم اختراق مفتاح واحد دون علمك ، فسيتم تقليل الأمان العام بشكل كبير!

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

مسارات استرداد صغيرة ومحددة زمنياً

تستخدم Liana نصًا صغيرًا لإنشاء محافظ لها طرق متعددة للإنفاق:

• شرط أساسي للإنفاق ، وهو متاح على الفور ؛
• واحد أو أكثر من شروط الإنفاق الإضافية التي تصبح متاحة بعد فترة معينة (ما يسمى ب وقت الإغلاق).

يتيح ذلك العديد من حالات الاستخدام المثيرة للاهتمام:

• التعافى: محفظة قياسية إما بتوقيع فردي أو multisig كمسار إنفاق أساسي ؛ لكن آلية استرداد منفصلة (مفتاح ببذرة مختلفة ، أو multisig ، أو صديق خبير في التكنولوجيا ، أو وصي) تصبح متاحة بعد 6 أشهر.
• الحكم: يمكن للشركة التي لديها مديرين إنشاء 2 من 2 لخزينة الشركة ؛ في حالة الخلاف ، يمكن لمحامي موثوق الوصول إلى الأموال بعد 6 أشهر.
• multisig المتحللة: تبدأ المحفظة على شكل 3 من 3 ، وتتحول إلى 2 من 3 بعد 6 أشهر ، وتصبح 1 من 3 بعد 9 أشهر.
• الميراث التلقائي: مسار الشفاء بعد 6 أشهر يشمل 2 من 3 من أطفالك الثلاثة ؛ ربما يتضمن مسار التعافي الثاني بعد عام واحد كاتب عدل ، في حالة عدم تمكن الورثة من التوصل إلى توافق في الآراء.

تعليق: جميع الأمثلة أعلاه تستخدم أ timelock النسبي، والتي تشير إلى عمر العملات المعدنية (أي آخر مرة تم فيها نقل الأموال). المفاضلة هي أن المستخدم يجب أن يتذكر إنفاق العملات المعدنية (عن طريق إرسالها إلى نفسه) إذا كان القفل الزمني على وشك الانتهاء.

هذه مجرد أمثلة قليلة ، ولكن يجب أن تكون كافية لإقناع القارئ بأن النص الصغير يمثل خطوة مهمة للأمام نحو إدراك إمكانات Bitcoin مثل أموال قابلة للبرمجة.

تسجيل سياسة المحفظة

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

التحقق من صحة السياسة و com.xpubs من أداة cosigner مقابل نسخة احتياطية موثوقة أمر ضروري ، ولكنه يستغرق وقتًا طويلاً نسبيًا.
والخبر السار هو أنه يجب القيام به مرة واحدة فقط:

بمجرد تسجيل السياسة باسم (في المثال "Decaying 3of3") ، سيكون جهازك قادرًا على التعرف عليها كلما تم استخدام مثل هذه السياسة.

يمكن للمهتمين بالتفاصيل الفنية العثور على مزيد من المعلومات في اقتراح BIP.

النسخ الاحتياطي للسياسة

أحد الجوانب المهمة التي يجب ملاحظتها هو أنه بينما تسمح السياسات متعددة المفاتيح بمجموعة فرعية من مفاتيح خاصة لتفويض المعاملات ، معرفة من جميع المفاتيح العامة (و دقيق السياسة) مطلوبة.

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

المحفظة ذات التوقيع الفردي غير القابلة للفتح الباب

لنعد خطوة للوراء. لقد ناقشنا المحافظ متعددة التوقيع ، لكننا الآن نعود إلى الأساسيات لإنشاء محفظة ذات توقيع واحد. بتعبير أدق ، نريد محفظة يشعر و يبدو مثل محفظة التوقيع الفردي ، بعد مرحلة الإعداد الأولي. ومع ذلك ، فإننا نهدف إلى إنشاء محفظة لا يمكن للشركة المصنعة أن تسرق منها أموالك حتى لو كانت ضارة 😈 ، ويتصرف جهاز توقيع الأجهزة بطرق غير متوقعة.

يمكن بسهولة تعميم هذا النهج للمحافظ متعددة التوقيعات.

ستتم كتابة الأمثلة أدناه بلغة تسمى سياسة، بدلاً من النص الصغير. السياسة أسهل على البشر لقراءتها والتفكير فيها ، ويمكن تجميعها إلى نص صغير باستخدام أدوات آلية. اقرأ المزيد عن النص الصغير والسياسة.

يمكن لمحفظة الأجهزة أن تحميك في نموذج الأمان القياسي. يمكن أن يحميك برنامج Miniscript في نموذج الأمان المضاد للباب الخلفي (وأكثر من ذلك بكثير!).

الخطوة صفر: الوضع الراهن

هذه هي السياسة التي يستخدمها معظم المستخدمين اليوم: مفتاح واحد مشتق من بذرة تم إنتاجها في محفظة الأجهزة.

pk(key_ledger)

بالطبع ، لا توجد طريقة لإثبات عدم وجود باب خلفي.

الخطوة الأولى: ضاعف هذه المفاتيح

الخطوة الأولى بسيطة:

and(pk(key_ledger), pk(key_client))

هنا، key_client يتم إنشاؤه على جهاز المستخدم ، ومن ثم أ مفتاح ساخن. في الأساس ، إنه إعداد متعدد الرموز 2 من 2. الجانب الرئيسي هو أن المستخدم لا يتفاعل كثيرًا معه key_client: تُنشئ محفظة البرنامج هذا المفتاح ، وتُدرجه في النسخة الاحتياطية للمحفظة ، وتُشير إليه كلما دعت الحاجة (على سبيل المثال ، عندما يكون المستخدم مشغولاً بالتوقيع باستخدام مُوقِّع الأجهزة).

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

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

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

الخطوة الثانية: استرجاع مؤقت

نقدم مفتاح استرداد منفصل ، لا يمكن الوصول إليه إلا بعد قفل زمني محدد: and(older(25920), pk(key_recovery))، حيث 25920 هو العدد التقريبي للكتل في 6 أشهر. تصبح السياسة الكاملة:

or(
  and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)

هذا مشابه للسيناريو السابق ، ولكن مع تطور: if key_ledger or key_client يصبح غير متاح لأي سبب من الأسباب (الأكثر شيوعًا ، فقدان النسخة الاحتياطية الأولية!) ، أ مسار الانتعاش يصبح متاحًا بعد 6 أشهر.

هناك عدة خيارات key_recovery، لكل منها مفاضلاتها الخاصة:

a. استخدم آخر مفتاح ساخن. هذا حل عملي طالما المستخدم يتذكر إعادة ضبط timelock. ومع ذلك ، إذا تم اختراق مفاتيح التشغيل السريع (وهو سيناريو يجب اعتباره محتمل بشكل عام!) ، فقد يحاول المهاجم الوصول إلى الأموال بمجرد انتهاء صلاحية قفل الوقت ، مما يؤدي إلى بدء سباق مع المالك الشرعي.

b. استخدم جهاز توقيع منفصل للجهاز. هذا حل قوي ويمكن استخدامه مع بائع مختلف إذا رغبت في ذلك ؛ ومع ذلك ، فإنه يزيد من تعقيد الإعداد وتكلفة المستخدم من حيث تجربة المستخدم.

c. استخدم خدمة خارجية موثوقة. يمكن لمحفظة البرنامج استيراد xpub من خدمة خارجية ، واستخدامها كملف key_recovery. لا يتم الوثوق بهذا الطرف الثالث إلا في حالة انتهاء صلاحية timelock ، مما قد يكون مقايضة جذابة لبعض المستخدمين.

كما ذكرنا ، مثل أي سياسة مع timelocks ، من المهم أن يتذكر المستخدم تحديث العملات قبل انتهاء صلاحية timelock.

الخطوة الثالثة: الطرف الثالث غير الموثوق به

دعنا نمزج كلا الفكرتين (أ) و (ج): بالنسبة لمسار الاسترداد ، نحتاج إلى مفتاح تشغيل سريع محلي key_recovery_local، و key_recovery_remote التي يتم استضافتها مع خدمة شبه موثوقة ؛ نحتفظ أيضًا بـ timelock.

or(
and(pk(key_ledger), pk(key_client)),
  and(older(25920),
    and(pk(key_recovery_local), pk(key_recovery_remote))
)
)

هذا يقلل من مستوى الثقة المطلوب من خدمة الاسترداد. ومع ذلك ، يجب أن نتوخى الحذر: يمكن للخدمة نفسها أن تراقب blockchain وتكتشف UTXOs الخاصة بنا - بعد كل شيء ، لقد زودتنا بـ key_recovery_remote xpub ، حتى يتمكنوا من البحث عن UTXOs التي تحتوي على مفاتيح عامة مشتقة من key_recovery_remote. سيكونون قادرين على التعرف على تاريخنا المالي ، حتى قبل انتهاء صلاحية timelock ، وحتى إذا لم نستخدم خدمتهم مطلقًا.

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

الخطوة الرابعة: أعمى الطرف الثالث 🙈

من أجل منع خدمة الاسترداد من التعرف على تاريخنا المالي ، بدلاً من استخدام مفتاح النشر الذي يرسلونه إلينا ، يمكننا استخدام xpub أعمى تقنية أوضحه mflaxman بالتفصيل هنا. باختصار ، بدلاً من استخدام key_recovery_remote في سياستنا ، نختار أربعة أرقام عشوائية كل منها 31 بت a, b, c, d (لل العوامل المسببة للعمى) ، ونستخدم ما يلي بيب-32 مفتاح عام مشتق:

key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d

من المهم أن نضيف أيضًا key_recovery_remote، والعوامل المسببة للعمى a, b, c و d إلى نسختنا الاحتياطية ، للرجوع إليها في المستقبل.

إذا احتجنا في أي وقت إلى استخدام خدمة الاسترداد ، فسنكشف a, b, c, d لهم. حتى ذلك الحين ، ليس لديهم طريقة لاكتشاف تلك المفاتيح المشتقة من ملفات key_recovery_remote يتم نشرها على blockchain: عدد التركيبات الممكنة للعوامل الأربعة المسببة للعمى هو 2^(31*4) = 2^124، مما يجعل من المستحيل إجبارهم جميعًا بوحشية.

الخطوة الخامسة: الكثير من مفاتيح التشغيل السريع يمكن أن تحرقك 🔥

لقد نجحنا في جعل محفظة البرامج الخاصة بنا غير قابلة للارجاع. ومع ذلك ، فقد أدخلنا مشكلة مختلفة: يستخدم كل من شروط الإنفاق عنصرًا محليًا ، حار المفتاح الذي لم يتم التحقق منه بواسطة محفظة الأجهزة. لذلك ، إذا تم اختراق الجهاز المضيف ، فقد يخدعك ذلك لتسجيل السياسة باستخدام مفاتيح النشر key_client و key_recovery_local، ولكن ضع مفاتيح خاصة عشوائية وغير مرتبطة في نسختنا الاحتياطية (تذكر ، ملف حار المفاتيح هي جزء من النسخ الاحتياطي لدينا!).

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

هناك بعض الحلول لحل هذه المشكلة:

• أثناء الإعداد ، بعد طباعة نسختنا الاحتياطية على الورق ، يمكننا استخدام جهاز منفصل للتحقق من تطابق مفاتيح التشغيل السريع الخاصة والعامة على النسخة الاحتياطية بالفعل. هذا النهج سيقضي على المشكلة ، لأننا على يقين من أن لدينا جميع المفاتيح المطلوبة لإعادة الإعمار والتوقيع.
• يمكننا إضافة شرط إنفاق آخر مع قفل زمني أطول (9 أشهر ، 38880 كتلة) يتطلب فقط key_ledger_failsafe من الجهاز. بهذه الطريقة ، في أسوأ سيناريو مطلقًا حيث يفشل كل شيء آخر ، نعود إلى أمان جهاز توقيع واحد. في العمليات العادية ، لن نسمح أبدًا بانتهاء صلاحية قفل الوقت الأول ، وبالتالي ، لن تنتهي صلاحية قفل الوقت الثاني أيضًا!

مع النهج الثاني ، ستبدو السياسة النهائية على هذا النحو

or(
  and(pk(key_ledger), pk(key_client)),
  or(
    and(older(25920),
        and(pk(key_recovery_local), pk(key_recovery_remote_blind))
    ),
    and(older(38880), pk(key_ledger_failsafe))
  ),
)

يفي تكوين محفظة البرنامج هذا بجميع خصائص الأمان التي ذكرناها في البداية. علاوة على ذلك ، فإنه يوفر مسار استرداد في حالة مفاتيح الإنفاق الرئيسية key_ledger ضاع. ميزة لطيفة لديك!

Onboarding إلى محفظة البرامج غير القابلة للفتح

كيف ستبدو تجربة المستخدم للمحفظة التي تستخدم مثل هذه السياسة المعقدة؟ فيما يلي نظرة عامة موجزة:

• يفتح المستخدم محفظة البرنامج ويبدأ في إنشاء حساب جديد.
• تطالب محفظة البرنامج المستخدم بتوصيل جهاز التوقيع الخاص به واسترداد xpubs لـ key_ledger و key_ledger_failsafe.
• تُنشئ محفظة البرنامج بشكل مستقل مفتاح التشغيل السريع key_client.
• تحصل محفظة البرنامج key_recovery_remote من خدمة التوقيع المشترك أو تسمح للمستخدم بتحديد مفتاح بطريقة أخرى. اختياريا ، فإنه يحسب key_recovery_remote_blind باستخدام تقنية التعمية المذكورة سابقاً.
• تُنشئ محفظة البرنامج نسخة احتياطية للسياسة تحتوي على سياسة miniscript الدقيقة ، وجميع أجهزة xpubs ، والمفتاح الخاص الموسع لـ key_client مفتاح التشغيل السريع. يتم تخزين هذه النسخة الاحتياطية بشكل آمن (على سبيل المثال ، طباعتها على ورق أو حفظها على جهاز منفصل).
• أخيرًا ، توجه محفظة البرنامج المستخدم إلى تسجيل السياسة على الجهاز. يتحقق المستخدم من النسخة الاحتياطية (على الورق أو أي وسيط آخر غير الشاشة التي تتحكم فيها محفظة البرنامج).

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

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

تحسينات Taproot

يدعم Ledger النص المصغر منذ الإصدار 2.1.0 من تطبيق Bitcoin ، الذي تم إصداره في مارس. بينما تم تمكين دعم الاستلام إلى العناوين الرئيسية والإنفاق منها منذ شوكة الجذر في تشرين الثاني (نوفمبر) 2021 ، نضع اللمسات الأخيرة على الخطوة التالية من خريطة الطريق: دعم النص الصغير للجذر الرئيسي.

سيكون لـ Taproot تأثير كبير على قابلية استخدام الأساليب المقدمة في هذه المقالة. إذا كان مسار الإنفاق الأساسي عبارة عن شرط إنفاق بمفتاح واحد ، فلن يكون من الممكن اكتشاف مسارات الإنفاق على الاسترداد على blockchain ما لم يتم استخدامها. سيؤدي ذلك إلى تحسين الخصوصية بشكل كبير من خلال التخلص تمامًا من أي بصمات لمسار الإنفاق القياسي. علاوة على ذلك ، فإنه يحسن قابلية التوسع ، حيث يصبح مسار الإنفاق القياسي فعالاً من حيث التكلفة للإنفاق قدر الإمكان. هذا يعني أنه لن يتم تكبد أي تكلفة إضافية بسبب وجود مسارات الاسترداد ، ما لم يتم استخدامها. هذه ترقية مهمة من معاملات SegWit ، والتي تتطلب نشر النص بالكامل ، بما في ذلك جميع شروط الإنفاق ، أثناء أي إنفاق.

أخيرًا ، البروتوكولات الأكثر تقدمًا مثل MuSig2 (تم توحيده مؤخرًا) و الصقيع سيشحن مسار مفتاح الجذر الرئيسي. بناءً على توقيعات شنور ، تسمح هذه البروتوكولات بإنشاء ملف مجموع pubkey التي يمكن استخدامها لتمثيل n-من-n متعدد التوقيعات أو أ k-من-n مخطط العتبة. سيسمح هذا باستخدام مسار مفتاح الجذر الرئيسي حتى في الحالات التي يتم تمثيلها اليوم بشكل أكثر شيوعًا باستخدام نصوص برمجية multisig محددة.

استنتاجات

تستكشف هذه المقالة مكانًا صغيرًا (لكن مهمًا) من مساحة التصميم الشاسعة التي يطلقها المحرر الصغير لمحافظ البرامج.

أظهرنا كيف يمكن استخدام البرنامج المصغر لإنشاء محفظة برامج "غير قابلة للفتح" ، مع إضافة مسار استرداد إضافي يسمح بمنع فقدان المفاتيح بشكل كارثي. على الرغم من أن أجهزة توقيع الأجهزة لا يمكنها فرض نموذج الأمان المضاد للباب الخلفي ، إلا أنها من خلال دعمها للبرامج الصغيرة تمكن محافظ البرامج التي تفعل ذلك بالضبط!

من خلال الاستفادة بذكاء من مجموعة من المخططات متعددة التوقيعات ، والأقفال الزمنية ، و xpubs العمياء ، والمفاتيح السريعة ، أظهرنا تكوينًا آمنًا للمحفظة يوازن بين الأمان والخصوصية والقوة.

علاوة على ذلك ، جادلنا بأن هذا ممكن دون التأثير سلبًا على تجربة المستخدم ، نظرًا لأن تعقيد الإعداد لا يترجم إلى عبء إضافي كبير لتجربة المستخدم.

نحن متحمسون للإمكانيات التي سيفتحها البرنامج المصغر للجيل القادم من خدمة البيتكوين الذاتية.

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
• أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
• أفلاطون السيارات / المركبات الكهربائية ، كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
• BlockOffsets. تحديث ملكية الأوفست البيئية. الوصول هنا.
• المصدر https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript