في المسار الشائع BIP39، تتحول البيانات العشوائية إلى كلمات للنسخة الاحتياطية، أو Seed Phrase. ومن هذه الكلمات وpassphrase اختيارية، أي كلمة مرور إضافية، تُحسب البذرة: بيانات سرية يستطيع BIP32 أن يشتق منها شجرة مفاتيح المحفظة. البيانات العشوائية والكلمات والبذرة والمفاتيح مراحل مختلفة في المسار نفسه، وقد تعمل صيغ النسخ الاحتياطي الأخرى بطريقة مختلفة.
تخيل أنك تريد حفظ نسختك الاحتياطية بسهولة، فتختار كلمات من كتاب تحبه. قد تبدو لك غير مألوفة، لكن المهاجم يستطيع تجربة الاقتباسات والأنماط التي يختارها البشر عادة. لذلك يبدأ BIP39 بعشوائية يولدها الحاسوب ثم يمثلها بكلمات. وتصف الإنتروبيا مدى صعوبة التنبؤ بهذه البيانات. الكلمات سجل مقروء لبيانات سرية، وليست دعوة إلى تأليف جملة من عندك. [1]
يجب أن تحصل المحفظة فعلًا على بيانات عشوائية، لا أن تستدعي فقط دالة ذات اسم مناسب. يوفر Linux مثلًا الدالة getrandom() التي تنتظر افتراضيًا حتى يصبح مصدر النظام جاهزًا. ومع الخيار GRND_NONBLOCK قد تبلغ بدل الانتظار عن EAGAIN، أي أن البيانات غير متاحة بعد. على البرنامج فحص النتيجة وعدد البايتات التي حصل عليها؛ والبايت وحدة بيانات. الاستمرار بعد الفشل وكأن المدخل السري قد أُنشئ بنجاح قد ينتج محفظة تبدو عاملة لكنها غير آمنة. [2]
توفر المتصفحات أيضًا واجهة للحصول على بيانات عشوائية آمنة. تملأ Web Crypto getRandomValues() مصفوفة أعداد صحيحة ببايتات آمنة تشفيريًا، وتفشل الطلبات التي تتجاوز 65536 بايت بالخطأ QuotaExceededError. لكن هذا وصف لدالة واحدة، وليس شهادة أمان للموقع كله. فقد تحصل الصفحة على عشوائية جيدة ثم تسرب كلمات النسخة الاحتياطية. لذلك يجب فحص الكود المحمل وما يفعله بالنتيجة أيضًا. [3]
إذا نقلت كلمة بصورة خاطئة، فقد تكتشف المحفظة الخطأ بواسطة مجموع اختباري: تحقق قصير يُحسب من البيانات الأصلية. يضيف BIP39 عدد 4 بتات للتحقق إلى 128 بت من المدخل لتكوين 12 كلمة؛ وتنتج 256 بت مع 8 بتات للتحقق 24 كلمة. البت وحدة أساسية للمعلومات. تأتي بتات التحقق من بصمة للبيانات تحسبها SHA256، لا من إنتروبيا مستقلة إضافية. لذلك لا يثبت المجموع الصحيح أن الكلمات سرية أو أنها وُلدت بأمان. [1]
تسهل الكلمات الاحتفاظ بالنسخة الاحتياطية، بينما يحتاج البرنامج إلى تحويلها إلى بيانات محددة بدقة. يستخدم BIP39 دالة الاشتقاق PBKDF2-HMAC-SHA512 مع 2048 تكرارًا لإنتاج بذرة بطول 512 بت. وإلى جانب العبارة يستخدم معاملًا اسمه salt: وهو هنا النص الحرفي mnemonic متبوعًا بـpassphrase، أو بسلسلة فارغة إن لم تستخدمها. تُعالج العبارة وهذا المعامل وفق UTF-8 NFKD لتوحيد تمثيل المحارف. لا يصنع الناتج الأطول عشوائية مفقودة؛ فطوله لا يثبت وجود 512 بت من إنتروبيا المدخل. [1]
يصف BIP32 الخطوة التالية: اشتقاق مفتاح خاص رئيسي وchain code، أي بيانات مساعدة لاشتقاق مفاتيح أخرى. وهكذا تستطيع المحفظة إنشاء عناوين جديدة من أصل مشترك. تقنيًا، تطبق HMAC-SHA512 مع النص الثابت Bitcoin seed بوصفه مفتاح هذه الدالة، ثم تقسم النتيجة. هذا النص العام ليس سرك. وإذا كانت قيمة المفتاح الخاص المشتق صفرًا أو خارج النطاق المسموح، فهو غير صالح. إذن ليست العملية مجرد تغيير اسم البذرة إلى مفتاح خاص. [4]
يحتاج المطور إلى معرفة ما إذا كان برنامجه يجري الحسابات بصورة صحيحة. توفر متجهات الاختبار مدخلات معروفة ونتائج متوقعة لهذا الغرض. ينشر BIP39 مجموعات تضم الإنتروبيا والكلمات والبذرة، ومنها passphrase الاختبارية TREZOR. يؤكد تطابق النتيجة تحويل ذلك المدخل، لكنه لا يثبت أن المولد الفعلي ينتج أسرارًا غير قابلة للتنبؤ. ولأن بيانات الاختبار علنية، فلا يجوز استخدامها نسخة احتياطية سرية لأموال حقيقية. [1]
تربط عدة مراحل مصدر العشوائية بالكلمات ثم بحفظ النسخة الاحتياطية. يوضح NIST SP 800-90C كيفية الجمع بين مصادر الإنتروبيا وآليات توليد البيانات العشوائية. وعند تقييم محفظة، يجب أيضًا فحص إصدار البرنامج المحدد ومعالجة الأخطاء وانتقال البيانات بين المراحل. لا يضمن مكون خضع لفحص جيد أن مكونًا آخر لن يفقد السر أو يكشفه. الهدف هو تتبع العملية كاملة، لا البحث عن اسم واحد يوحي بالثقة. [5]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Random Number Generator, BIP 39, HD Wallet, Seed Phrase. تشير إلى هذا المدخل أيضًا Random Number Generator, CSPRNG, Deterministic RNG, Entropy Mixing.