ECDSA (خوارزمية التوقيع الرقمي بالمنحنى الإهليلجي)

ما ECDSA؟

يرمز ECDSA إلى خوارزمية التوقيع الرقمي بالمنحنى الإهليلجي.

وهي خوارزمية تشفير بالمفتاح العام تُستخدم لإنشاء التوقيعات الرقمية والتحقق منها باستخدام رياضيات المنحنيات الإهليلجية.

تستخدم محافظ العملات المشفرة ECDSA لإثبات أن معاملة ما قد أذن بها حامل مفتاح خاص محدد.

ينشئ المفتاح الخاص التوقيع، بينما يتيح المفتاح العام المقابل لعُقد البلوكشين التحقق منه.

لا يلزم الكشف عن المفتاح الخاص أثناء التحقق.

ويُظهر توقيع ECDSA الصحيح أيضًا أن بيانات المعاملة الموقعة لم تتغير منذ إنشاء التوقيع.

يتضمن المعيار الرقمي للتوقيعات الصادر عن NIST ECDSA بوصفها تقنية توقيع رقمي معتمدة لتطبيقات تشفير اتحادية محددة ومدعومة.

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

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

لماذا تستخدم العملات المشفرة ECDSA؟

تحتاج شبكة العملات المشفرة اللامركزية إلى التحقق من أذونات الإنفاق من دون الاعتماد على قاعدة بيانات حسابات مركزية واحدة.

تتيح ECDSA لكل مستخدم التحكم في حساب أو مخرج قابل للإنفاق من خلال مفتاح خاص سري.

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

ويتحقق المشاركون الآخرون في الشبكة من التوقيع باستخدام المفتاح العام وقواعد التحقق الخاصة بالبروتوكول.

يصعب للغاية تزوير توقيع مُنشأ على نحو صحيح من دون المفتاح الخاص، وفق افتراضات الحوسبة التقليدية الحالية.

يتيح ذلك لعُقد البلوكشين رفض التحويلات غير المصرح بها مع السماح للمعاملات الصحيحة بالانتقال عبر شبكة عامة.

كما تنشئ ECDSA مفاتيح وتوقيعات صغيرة نسبيًا مقارنة ببعض أنظمة المفتاح العام الأقدم عند مستويات أمان تقليدية مماثلة.

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

ECDSA خوارزمية توقيع وليست تشفيرًا

تثبت ECDSA الإذن وسلامة الرسالة، لكنها لا تخفي البيانات الموقعة.

تظل معظم معاملات العملات المشفرة العامة مرئية لمشاركي البلوكشين رغم احتوائها على توقيعات ECDSA.

لا يشفر التوقيع عنوان الوجهة أو المبلغ المحوّل أو رسوم المعاملة أو تعليمات العقد الذكي.

يحوّل التشفير المعلومات المقروءة إلى نص مشفر يتطلب مفتاح فك تشفير.

أما ECDSA فتنشئ دليلًا رياضيًا على أن مفتاحًا خاصًا أذن برسالة محددة.

ويجب توفير الخصوصية باستخدام تقنيات تشفير منفصلة أو تصميمات بروتوكولات أو ضوابط تطبيقية.

الأساس القائم على المنحنى الإهليلجي

تعمل ECDSA ضمن مجموعة رياضية تتكون من نقاط على منحنى إهليلجي فوق حقل منتهٍ.

يُكتب أحد أشكال المنحنيات الشائعة على النحو التالي

، مع إجراء جميع حسابات الإحداثيات باستخدام الحساب المعياري.

تحدد معلمات مجال المنحنى الحقل ومعاملات المنحنى ونقطة المولد ورتبة المولد والمعامل المساعد.

يُشار عادةً إلى نقطة المولد بالرمز

.

ويُشار عادةً إلى رتبة المولد بالرمز

.

تستخدم التطبيقات الآمنة معلمات موحدة ومدروسة بعناية، بدلًا من ابتكار منحنى جديد لتطبيق واحد.

توثق توصية NIST بشأن معلمات نطاق المنحنيات الإهليلجية المنحنيات المعتمدة للتطبيقات التي يشملها ذلك المعيار.

المفاتيح الخاصة والمفاتيح العامة

مفتاح ECDSA الخاص عدد صحيح سري يُمثّل عادةً بالرمز

.

يجب اختيار القيمة ضمن النطاق الصحيح من 1 إلى

.

يُحسب المفتاح العام باستخدام الضرب القياسي على المنحنى الإهليلجي.

وتُكتب العلاقة عادةً بالشكل

.

يكون حساب

من و فعالًا.

ويُعتقد أن استعادة

من غير عملية حسابيًا عند استخدام منحنى آمن ومفتاح مولّد بطريقة صحيحة.

تعتمد هذه العلاقة أحادية الاتجاه على صعوبة مسألة اللوغاريتم المتقطع على المنحنى الإهليلجي.

يمكن لأي شخص يحصل على المفتاح الخاص إنشاء توقيعات صحيحة، والتحكم عادةً في الأصول المشفرة المرتبطة به.

ما secp256k1؟

secp256k1 هو المنحنى الإهليلجي الأكثر ارتباطًا بخوارزمية ECDSA في العملات المشفرة.

يُستخدم لتوقيعات معاملات Bitcoin التقليدية وتوقيعات الحسابات المملوكة خارجيًا في Ethereum.

معادلة المنحنى هي

فوق حقل أولي كبير.

يقترب حجم الحقل ورتبة المجموعة من 256 بت.

يُوصف مستوى الأمان التقليدي المقدّر له عادةً بأنه نحو 128 بت أمام هجمات اللوغاريتم المتقطع العامة.

يختلف secp256k1 عن NIST P-256، رغم وصف كليهما عادةً بأنهما منحنيان إهليلجيان بحجم 256 بت.

ولا يمكن ببساطة التحقق من المفاتيح والتوقيعات المنشأة لمنحنى ما باستخدام المنحنى الآخر.

يوفر مشروع libsecp256k1 المُصان وظائف محسنة للتوقيع والتحقق وإنشاء المفاتيح وتحليلها واسترداد المفاتيح العامة باستخدام ECDSA على secp256k1.

كيفية إنشاء توقيع ECDSA

تبدأ عملية التوقيع بمفتاح خاص ورسالة ودالة تجزئة تشفيرية ومعلمات المنحنى المحدد.

تُعالج الرسالة وفق قواعد التسلسل الدقيقة الخاصة ببروتوكول العملة المشفرة.

تُجزّأ الرسالة المتسلسلة لإنتاج ملخص يُشار إليه عادةً بالرمز

.

يختار الموقّع قيمة سرية خاصة بالتوقيع، تُسمى عادةً nonce ويُشار إليها بالرمز

.

يجب أن يكون nonce عددًا صحيحًا غير صفري وصحيحًا وأقل من رتبة المنحنى.

يحسب الموقّع نقطة المنحنى

.

تُشتق القيمة الأولى للتوقيع،

، من الإحداثي x للنقطة وتُختزل بترديد .

إذا كانت

مساوية للصفر، فعلى الموقّع اختيار nonce آخر.

وتُحسب القيمة الثانية للتوقيع وفق المعادلة

.

إذا كانت

مساوية للصفر، فعلى الموقّع أيضًا اختيار nonce آخر.

يتكون توقيع ECDSA الناتج من الزوج

، مع احتمال إضافة العملة المشفرة معلومات ترميز أو استرداد.

كيفية التحقق من توقيع ECDSA

يبدأ التحقق بالرسالة والتوقيع والمفتاح العام ومعلمات المنحنى وقواعد التجزئة المطلوبة.

يرفض المدقق التوقيع إذا كانت

أو خارج النطاق الصحيح.

ثم يحسب المدقق

.

بعد ذلك يحسب

و.

ويحسب نقطة المنحنى

.

يُرفض التوقيع إذا كانت

نقطة اللانهاية.

يكون التوقيع صحيحًا عندما يساوي الإحداثي x للنقطة

، بعد اختزاله بترديد ، القيمة .

تصح هذه العلاقة لأن معادلة التوقيع تربط ملخص الرسالة وnonce والمفتاح الخاص والمفتاح العام.

لا يكشف التحقق عن المفتاح الخاص أو nonce المستخدم للتوقيع.

ما الذي يثبته توقيع ECDSA؟

يثبت توقيع ECDSA الصحيح أن شخصًا يتحكم بالمفتاح الخاص المقابل وقّع البيانات المحددة.

ويتيح أيضًا للمدقق اكتشاف أي تغيير في الرسالة الموقعة.

لا يثبت التوقيع وحده الهوية القانونية للموقّع.

ولا يرتبط المفتاح العام بشخص أو مؤسسة إلا عبر أدلة أو تسجيل أو مراسلات أو سجل معاملات إضافي.

ينشئ المفتاح الخاص المسروق توقيعات لا يمكن تمييزها رياضيًا عن التوقيعات التي أنشأها مالكه الأصلي.

تتحقق عُقد البلوكشين من التشفير، ولا تقرر ما إذا كان الموقّع يتصرف طوعًا.

إذا وقّع مستخدم معاملة ضارة، فسيظل قد أنشأ توقيعًا صحيحًا.

الدور الحاسم لـ nonce في ECDSA

يُعد nonce التوقيع

من أكثر أجزاء ECDSA حساسية من ناحية الأمان.

يجب عدم إعادة استخدامه مطلقًا لتوقيع رسائل مختلفة بالمفتاح الخاص نفسه.

إذا استخدم توقيعان nonce نفسه، فستتضمن معادلاتهما معلومات مترابطة تكفي لحساب nonce واستعادة المفتاح الخاص.

ولا يحتاج المهاجم حينها إلى حل مسألة اللوغاريتم المتقطع على المنحنى الإهليلجي.

وقد تكشف nonces المتوقعة جزئيًا أو المنحازة أو المسربة المفتاح أيضًا بعد رصد عدد كافٍ من التوقيعات.

تسببت إخفاقات nonce في اختراق مفاتيح تشفيرية فعلية، حتى عندما ظل المنحنى الإهليلجي المختار آمنًا رياضيًا.

تعني كلمة nonce قيمة تُستخدم مرة واحدة، لكن ECDSA تتطلب أن تظل سرية وفريدة أيضًا.

ECDSA الحتمية

تُنشئ ECDSA الحتمية nonce التوقيع من المفتاح الخاص وملخص الرسالة بدلًا من طلب قيمة عشوائية جديدة لكل توقيع.

تحدد إجراءات RFC 6979 للتوقيع الحتمي طريقة شائعة الاستخدام تستند إلى بنية تجزئة بمفتاح.

عادةً ما ينتج المفتاح الخاص والرسالة نفسيهما nonce والتوقيع نفسيهما عند استخدام الإجراء الحتمي نفسه.

يقلل ذلك الاعتماد على جودة مولّد أرقام عشوائية منفصل في كل عملية توقيع.

لكن التوقيع الحتمي لا يجعل إنشاء المفاتيح الخاصة الضعيفة آمنًا.

فالمفتاح الخاص الأصلي لا يزال يتطلب مصدر إنتروبيا قويًا.

كما يجب أن تقاوم التطبيقات الحتمية هجمات التوقيت والأعطال وتسرب الذاكرة والمعالجة غير الصحيحة للرسائل.

تضيف بعض التطبيقات عشوائية إضافية إلى إنشاء nonce الحتمي لمواجهة ظروف محددة من الأعطال أو الهجمات بالقنوات الجانبية.

أهمية التجزئة

توقّع ECDSA عادةً ملخصًا تشفيريًا بدلًا من معالجة رسالة كبيرة بلا حد مباشرةً.

يحدد بروتوكول البلوكشين بدقة حقول المعاملة التي تُضمّن وكيفية تسلسلها قبل التجزئة.

ينبغي أن يؤدي تغيير أي حقل موقع إلى ملخص مختلف وإبطال التوقيع القديم.

قد تستخدم العملات المشفرة المختلفة دوال تجزئة وقواعد التزام بالمعاملات مختلفة، مع استخدام منحنى ECDSA نفسه.

لذلك قد تنتج الرسالة المقروءة نفسها توقيعات مختلفة في تطبيقات مختلفة.

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

كما تستخدم البروتوكولات الآمنة فصل النطاقات لمنع توقيع أُنشئ لغرض معين من تفويض غرض آخر.

ترميز توقيع ECDSA

يتكون توقيع ECDSA رياضيًا من عددين صحيحين هما

و.

يجب أن ترمّز البرامج هذين العددين إلى بايتات قبل نقل التوقيع أو تخزينه.

إحدى الطرق الشائعة هي قواعد الترميز المميزة، المعروفة اختصارًا باسم DER.

تمثل DER القيم على هيئة أعداد صحيحة مرمزة ضمن تسلسل منظم.

قد يختلف طول التوقيع الناتج لأن الأعداد الصحيحة الموجبة تحتاج أحيانًا إلى بايت صفري في بدايتها.

تستخدم أنظمة أخرى للعملات المشفرة ترميزًا مدمجًا ثابت العرض يتضمن 32 بايتًا لـ

و32 بايتًا لـ.

قد يُرفض توقيع صحيح رياضيًا إذا خالف ترميز بايتاته التنسيق المعياري للبروتوكول.

Bitcoin وECDSA

تستخدم Bitcoin تقليديًا ECDSA على secp256k1 للسماح بإنفاق كثير من مخرجات المعاملات.

توقّع المحفظة ملخصًا خاصًا بالمعاملة تحدده قواعد النص البرمجي وقواعد تجزئة التوقيع المعمول بها.

تتحقق عُقد Bitcoin من المفتاح العام والتوقيع وشروط النص البرمجي وجميع متطلبات الإجماع الأخرى.

لا يثبت التوقيع وحده أن قيمة المدخل كافية أو أن المعاملة تستوفي جميع قواعد البروتوكول.

أدخلت مواصفة BIP 66 في Bitcoin الترميز الصارم DER شرطًا للإجماع على توقيعات ECDSA التي تقيّمها عمليات النص البرمجي المشمولة.

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

يستخدم إنفاق Taproot في Bitcoin توقيعات Schnorr المحددة في BIP 340 بدلًا من ECDSA لمسار التوقيع الجديد.

ولا تزال أنواع المخرجات التقليدية المعتمدة على ECDSA موجودة ويمكن إنفاقها.

أهمية التحليل الصارم للتوقيعات

يجب أن تتفق برمجيات الإجماع ليس فقط على معادلة التوقيع، بل أيضًا على سلاسل البايتات التي تمثل توقيعًا صحيحًا.

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

وقد يؤدي هذا الاختلاف إلى انقسام رؤية الشبكة للبلوكشين.

يزيل التحليل الصارم الترميزات البديلة التي تمثل القيم الرياضية نفسها.

ينبغي أن يحدد تطبيق العملة المشفرة بدقة إشارات الأعداد الصحيحة والأصفار البادئة والأطوال والنطاقات والبيانات اللاحقة.

يتطلب التشفير الحساس للإجماع تطابقًا على مستوى البايتات بين إصدارات البرامج ولغات البرمجة.

Ethereum وECDSA

تستخدم الحسابات المملوكة خارجيًا في Ethereum خوارزمية ECDSA على secp256k1 للتصريح بالمعاملات.

يوقّع المُرسِل ملخص معاملة يلتزم بحقول مثل nonce والوجهة والقيمة والبيانات ومعلمات الرسوم ونوع المعاملة.

تتضمن توقيعات Ethereum قيمتي

و، إضافة إلى معلومات استرداد المفتاح العام.

تُسمى قيمة الاسترداد في الأوصاف القديمة غالبًا

، بينما تُمثل في المعاملات الجديدة ذات الأنواع عادةً بقيمة تكافؤ y.

تتيح معلومات الاسترداد للبرامج اشتقاق المفتاح العام المحتمل من التوقيع وملخص الرسالة.

ثم يمكن اشتقاق عنوان الحساب ومقارنته بعنوان المُرسِل المعلن.

يرفض تغيير البروتوكول EIP-2 توقيعات المعاملات العادية التي تزيد فيها قيمة

على نصف رتبة منحنى secp256k1.

الحماية من إعادة تشغيل المعاملات في Ethereum

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

يضمّن تصميم الحماية من إعادة التشغيل في EIP-155 معرّف السلسلة في عملية توقيع المعاملة.

وهذا يربط التفويض بسياق سلسلة محدد.

كما تلتزم معاملات Ethereum الحديثة ذات الأنواع بحقول نوع المعاملة والحقول الخاصة بالسلسلة.

ولا تزال التطبيقات التي تطلب توقيعات خارج السلسلة بحاجة إلى فصل نطاقاتها وnonces وقواعد انتهاء الصلاحية ومعرّفات العقود الخاصة بها.

ينبغي ألا يُعتبر توقيع ECDSA صحيح آمنًا من دون فهم الرسالة والنطاق اللذين يغطيهما.

استرداد المفتاح العام

يفترض التحقق القياسي من ECDSA أن المفتاح العام معروف مسبقًا للمدقق.

تضيف ECDSA القابلة للاسترداد قدرًا صغيرًا من المعلومات للمساعدة على تحديد المفتاح العام المرتبط بتوقيع ورسالة.

قد تستوفي عدة نقاط مرشحة على المنحنى جزءًا من معادلة التوقيع، لذا يحدد معرّف الاسترداد المرشح المقصود.

قد تقلل هذه الميزة الحاجة إلى إرسال المفتاح العام كاملًا في بعض تنسيقات المعاملات.

ولا يكشف استرداد المفتاح العام عن المفتاح الخاص.

تدعم وحدة الاسترداد الاختيارية في libsecp256k1 توقيعات secp256k1 القابلة للاسترداد للتطبيقات المناسبة.

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

قابلية التلاعب بتوقيع ECDSA

تنطوي ECDSA على شكل رياضي أصيل من قابلية التلاعب بالتوقيع.

إذا كان

صحيحًا لرسالة ومفتاح عام، فإن يكون صحيحًا أيضًا وفق معادلة التحقق الأساسية.

يمكن لطرف ثالث إنشاء التوقيع البديل من دون معرفة المفتاح الخاص.

ولا يتيح ذلك للمهاجم توقيع رسالة مختلفة أو إنفاق أصول إضافية.

لكنه قد يغير معرّف المعاملة عندما يشمل المعرّف بايتات التوقيع.

تحد البروتوكولات من هذه المشكلة بقبول صيغة معيارية واحدة فقط، وغالبًا ما تكون التوقيع ذي قيمة

الأقل.

كما يجعل توحيد الصيغة مقارنة التوقيعات وتخزينها باتساق أسهل.

التوقيعات منخفضة s

تشترط قاعدة القيمة المنخفضة لـ

ألا تتجاوز نصف رتبة المنحنى.

إذا حسب الموقّع قيمة أعلى، فيمكنه استبدالها بـ

.

وتظل القيمة المعدلة صحيحة رياضيًا وتقع ضمن النطاق الأدنى المقبول.

تفرض Ethereum هذه القاعدة على توقيعات المعاملات العادية من خلال EIP-2.

غالبًا ما تنشئ برمجيات Bitcoin توقيعات ECDSA مطبّعة ذات قيمة منخفضة لـ

، بينما يعتمد التعامل الدقيق معها وفق الإجماع والسياسات على سياق الإنفاق.

ينبغي للمطورين اتباع القواعد الدقيقة للبروتوكول المستهدف بدلًا من افتراض أن جميع أنظمة ECDSA تقبل الصيغة نفسها.

ECDSA مقابل توقيعات Schnorr

ECDSA وSchnorr خوارزميتان مختلفتان للتوقيع، ويمكن استخدامهما على منحنى secp256k1 نفسه.

تمتلك توقيعات Schnorr بنية خطية أبسط تدعم إنشاء حلول فعالة للتوقيعات المتعددة وتجميع التوقيعات.

ولا توفر ECDSA الأساسية خصائص التجميع الخطي المباشرة نفسها.

تحدد مواصفة BIP 340 في Bitcoin توقيعات Schnorr ثابتة الطول من 64 بايتًا على secp256k1.

كما تشرح BIP 340 قابلية التلاعب الأصيلة في ECDSA وافتراضات الأمان الأكثر تعقيدًا المستخدمة في التحليل الرسمي لها.

لا يعني إدخال Schnorr أن توقيعات ECDSA القائمة أصبحت غير صالحة أو قابلة للتزوير عمليًا.

بل يوفر تصميمًا آخر للتوقيع بخصائص مفيدة لميزات البروتوكول الأحدث.

ECDSA مقابل EdDSA

EdDSA عائلة منفصلة من التوقيعات تستند إلى رياضيات المنحنيات Edwards.

Ed25519 إحدى تطبيقات EdDSA الشائعة.

صُممت EdDSA مع إعطاء أولوية للتوقيع الحتمي وتبسيط سلوك التنفيذ.

لا يمكن استخدام مفتاح Ed25519 كمفتاح ECDSA على secp256k1 من دون تصميم تحويل منفصل، كما أن التحويل العشوائي غير آمن.

تختلف أحجام التوقيعات وتنسيقات المفاتيح العامة وحسابات المنحنيات وإجراءات التجزئة وقواعد التحقق.

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

ECDSA مقابل توقيعات BLS

تستخدم توقيعات BLS منحنيات إهليلجية ملائمة للاقتران، وتختلف خصائصها الرياضية عن ECDSA.

يمكنها دعم التجميع المدمج لعدد كبير من التوقيعات وفق قواعد أمان محددة.

يستخدم مدققو Ethereum توقيعات BLS لمهام إجماع إثبات الحصة، بينما تستخدم الحسابات العادية المملوكة خارجيًا في Ethereum توقيعات ECDSA على secp256k1.

لذلك لا يمكن استخدام مفتاح المدقق بدلًا من مفتاح حساب التنفيذ.

قد يقلل تجميع BLS حجم البيانات عندما يوقّع العديد من المشاركين رسائل مترابطة، لكنه يتطلب عمليات اقتران وقواعد تحقق مختلفة.

ECDSA ومحافظ التوقيعات المتعددة

قد يشترط نص برمجي على البلوكشين عدة توقيعات ECDSA مستقلة قبل إنفاق الأصول.

وهذا تصميم تقليدي للتوقيعات المتعددة لأن كل موقّع مطلوب ينشئ توقيعًا منفصلًا.

تستخدم ECDSA العتبية بروتوكولًا تفاعليًا أكثر تعقيدًا ينشئ فيه عدة مشاركين معًا توقيع ECDSA عاديًا واحدًا.

ولا يحتاج أي مشارك إلى إعادة تكوين المفتاح الخاص كاملًا أثناء التنفيذ الصحيح.

يصعب تصميم ECDSA العتبية لأن المشاركين يجب أن ينسقوا إنشاء nonce ويقاوموا السلوك الضار.

وقد يكشف بروتوكول عتبي معيب المفتاح الخاص المشترك حتى لو كانت خوارزمية ECDSA الأساسية آمنة.

ينبغي لأنظمة الإنتاج استخدام بروتوكولات مدروسة ومراجعة جيدًا بدلًا من ابتكار معادلات توقيع متعددة الأطراف خاصة بها.

محافظ الأجهزة وECDSA

يمكن لمحفظة الأجهزة إنشاء مفتاح ECDSA خاص وتخزينه داخل جهاز مخصص.

يتلقى الجهاز بيانات المعاملة ويعرض التفاصيل المتاحة وينشئ التوقيع داخليًا بعد موافقة المستخدم.

ويُفترض أن يبقى المفتاح الخاص داخل البيئة المحمية.

يقلل هذا العزل التعرض المباشر للبرمجيات الخبيثة على الهاتف أو الحاسوب المتصل.

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

يظل عرض تفاصيل المعاملة بأمان وسلامة البرامج الثابتة وحماية عبارة الاسترداد وأمن سلسلة التوريد أمورًا أساسية.

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

هجمات القنوات الجانبية

تستخرج هجمات القنوات الجانبية معلومات من السلوك المادي لتنفيذ ECDSA.

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

قد تكشف الفروع أو عمليات البحث في الجداول التي تعتمد على القيم السرية معلومات عن المفتاح الخاص أو nonce.

تحاول التطبيقات ذات زمن التنفيذ الثابت جعل أنماط العمليات الملحوظة مستقلة عن القيم السرية.

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

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

هجمات الأعطال

تتعمد هجمة الأعطال إحداث خطأ أثناء إنشاء الجهاز لتوقيع ECDSA.

قد يتلاعب المهاجم بالجهد الكهربائي أو توقيت الساعة أو الحرارة أو الذاكرة أو تدفق الحسابات.

وقد يكشف التوقيع المعيب معلومات رياضية كافية لاستعادة المفتاح الخاص في بعض التطبيقات.

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

وقد تستخدم أيضًا حسابات احتياطية ومستشعرات للأعطال وشرائح معززة ورسائل خطأ محدودة.

ينبغي دائمًا اعتبار الحيازة المادية لجهاز التوقيع حدثًا أمنيًا مهمًا.

المفاتيح العامة ونقاط المنحنى غير الصالحة

ينبغي ألا يقبل مدقق ECDSA أي سلسلة بايتات على أنها مفتاح عام من دون تحقق.

قد يحتاج التنفيذ إلى التأكد من صحة الترميز ومن وقوع النقطة على المنحنى المتوقع.

وينبغي له رفض نقطة اللانهاية وإجراء أي فحوصات مطلوبة للمجموعة الجزئية.

قد يؤدي استخدام نقطة غير صالحة يتحكم بها المهاجم في عمليات المفتاح السري إلى هجمات المنحنيات غير الصالحة أو المجموعات الفرعية الصغيرة.

تعتمد متطلبات التحقق الدقيقة على المنحنى والبروتوكول والعملية.

تتعامل مكتبات التشفير التي خضعت للمراجعة مع هذه التفاصيل بأمان أكبر من التطبيقات المخصصة غير الرسمية.

إنشاء المفتاح الخاص

يجب إنشاء مفتاح ECDSA الخاص من مصدر إنتروبيا آمن تشفيريًا.

تُعد العبارات التي يختارها الأشخاص وأعياد الميلاد والاقتباسات والأرقام المكررة ودوال الأرقام العشوائية العادية وسائل غير آمنة.

كما يجب أن يقع المفتاح ضمن نطاق القيم القياسية الصحيح للمنحنى المحدد.

ولا يعني أن القيمة تبدو بطول 256 بت أنها مفتاح خاص أُنشئ بأمان.

تشتق المحافظ عادةً مفاتيح ECDSA عديدة من بذرة رئيسية عبر عملية اشتقاق حتمية هرمية.

قد يتمكن أي شخص يحصل على تلك البذرة الرئيسية من إعادة إنشاء جميع الحسابات المشتقة.

لا تستطيع ECDSA التعويض عن كشف عبارة استرداد أو سهولة توقعها.

ECDSA وعناوين المحافظ

لا يكون المفتاح العام دائمًا مطابقًا لعنوان العملة المشفرة.

غالبًا ما ترمز عناوين Bitcoin تجزئةً أو شرطًا نصيًا مرتبطًا بمعلومات المفتاح العام.

تُشتق عناوين Ethereum من جزء من تجزئة مفتاح عام غير مضغوط على secp256k1.

قد يضيف تنسيق العنوان معرّفات الشبكة ومعلومات لاكتشاف الأخطاء.

قد تعرض المحفظة عدة عناوين مشتقة من بذرة رئيسية واحدة عبر مسارات اشتقاق مختلفة.

ينبغي ألا يفترض المستخدمون أن معرفة العنوان تكشف المفتاح العام كاملًا في كل حالة من حالات البروتوكول.

ومعرفة المفتاح العام لا تجعل استعادة المفتاح الخاص باستخدام الحوسبة التقليدية عملية عندما يكون المفتاح والمنحنى آمنين.

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

يفوض توقيع المعاملة عملية على البلوكشين وفق قواعد يحددها البروتوكول.

وقد يثبت توقيع الرسالة التحكم بالمفتاح من دون إرسال معاملة على البلوكشين مباشرةً.

قد تستخدم ECDSA توقيعات تسجيل الدخول إلى المحافظ وموافقات التوكنات والطلبات وتصويتات الحوكمة ورسائل التفويض.

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

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

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

ينبغي للمستخدمين رفض التوقيعات التي تتضمن بيانات غير مفسرة أو صلاحيات غير متوقعة.

هجمات إعادة الاستخدام

تستغل هجمة إعادة الاستخدام توقيعًا صحيحًا في سياق آخر لم يقصد الموقّع أن ينطبق عليه.

لا يزوّر المهاجم التوقيع.

بل يستغل نقص الربط بين التوقيع وسياقه.

تتضمن الرسائل الموقعة الآمنة قيمًا مثل معرّف السلسلة وnonce الحساب وعنوان العقد ونطاق التطبيق ونوع العملية ووقت انتهاء الصلاحية.

يمنع nonce أحادي الاستخدام إعادة استخدام التفويض نفسه مرارًا داخل التطبيق نفسه.

ينبغي للمطورين التحقق من استهلاك nonce بعد نجاح الإجراء المصرح به فقط.

أخطاء التنفيذ

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

تشمل الإخفاقات الشائعة إعادة استخدام nonce والأرقام العشوائية المنحازة وقبول المفاتيح غير الصالحة والتجزئة غير الصحيحة والتسلسل الملتبس وغياب فحوصات النطاق والتحليل غير الآمن للتوقيعات.

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

ينبغي للمطورين استخدام مكتبات مُصانة ومختبرة على نطاق واسع ولها نموذج أمني واضح.

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

لماذا يُعد تطوير شيفرة ECDSA مخصصة أمرًا خطيرًا؟

قد تبدو معادلات ECDSA بسيطة بما يكفي لتنفيذها في برنامج قصير.

لكن الأمان في بيئة الإنتاج يتطلب أكثر بكثير من تكرار معادلات التوقيع والتحقق.

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

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

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

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

قوة أمان ECDSA

يعتمد أمان ECDSA على قوة المنحنى ودالة التجزئة وإنتروبيا المفتاح الخاص وإنشاء nonce والتنفيذ.

يرتبط المنحنى الإهليلجي الآمن ذي 256 بتًا عادةً بمستوى أمان تقليدي يبلغ نحو 128 بتًا.

لا يعني ذلك أن احتمال تخمين المهاجم للمفتاح هو واحد من 128.

بل يصف عامل جهد حاسوبيًا تقريبيًا ضمن نماذج الهجوم المعنية.

ويجب أن توفر دالة التجزئة أيضًا مقاومة مناسبة للتصادمات وإيجاد النص الأصلي وفق أهداف أمان البروتوكول.

قد تخفض الضوابط التشغيلية الضعيفة مستوى الأمان العملي إلى ما دون المستوى الرياضي بكثير.

ECDSA والحوسبة الكمية

لا تُعد ECDSA آمنة أمام حاسوب كمي قوي بما يكفي ومتحمل للأعطال.

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

ولا يوجد حاليًا حاسوب كمي معروف علنًا قادر على كسر ECDSA الكاملة على secp256k1 على نطاق عملي للعملات المشفرة.

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

قد تصبح المفاتيح العامة المكشوفة بالفعل على السلسلة أهدافًا ذات أولوية أعلى إذا طُورت أجهزة كمومية ذات صلة بالتشفير.

ينبغي التعامل بحذر مع الادعاءات غير المدعومة التي تزعم أن ECDSA الحالية قد كُسرت بالفعل.

بدائل التوقيع لما بعد الحوسبة الكمية

تعتمد التوقيعات الرقمية لما بعد الحوسبة الكمية على مسائل رياضية يُعتقد أنها تقاوم الحواسيب التقليدية والكمية الكبيرة.

اعتمدت NIST النسختين النهائيتين FIPS 204 لـML-DSA وFIPS 205 لـSLH-DSA في أغسطس 2024.

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

ولا يقتصر استبدال ECDSA على تغيير مكتبة محفظة واحدة في البلوكشين.

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

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

كيفية استخدام ECDSA بأمان للمطورين

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

يجب أن تأتي المفاتيح الخاصة من عملية إنشاء أو اشتقاق آمنة تشفيريًا.

ينبغي استخدام طريقة حتمية مدروسة لإنشاء nonces التوقيع، أو تصميم آمن للعشوائية يوفر حماية مكافئة.

يجب أن تجري المكتبات تحليلًا صارمًا للتوقيعات وفحوصات لنطاق القيم العددية والتحقق من المفاتيح العامة وتوحيد الصيغ المطلوبة وفق البروتوكول.

ينبغي أن تستخدم عمليات المفتاح السري تطبيقات ذات زمن تنفيذ ثابت.

يجب أن تتضمن التطبيقات فصل النطاقات والحماية من إعادة التشغيل وعرضًا واضحًا لتفاصيل المعاملة وإدارة مناسبة لـnonce.

ينبغي أن تشمل مجموعات الاختبار توقيعات غير صالحة وصيغًا ذات قيمة

مرتفعة وترميزات مشوهة وقيمًا صفرية ورسائل معدلة وشبكات خاطئة ومحاولات إعادة استخدام التفويض.

وينبغي أن تخضع الأنظمة ذات القيمة العالية لتدقيق مستقل في التشفير والتنفيذ.

كيفية حماية مستخدمي العملات المشفرة لمفاتيح ECDSA

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

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

ينبغي التحقق من تفاصيل المعاملة على شاشة موثوقة قبل التوقيع.

كما ينبغي التحقق من عنوان الوجهة والشبكة والمبلغ والرسوم والعقد ونطاق الصلاحيات.

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

ينبغي عدم استيراد عبارة استرداد واحدة إلى تطبيقات لا حاجة إليها.

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

أخطاء شائعة في ECDSA

من الأخطاء الشائعة افتراض أن ECDSA تشفر معاملات العملات المشفرة.

ومنها اعتبار المفتاح العام مطابقًا دائمًا لعنوان المحفظة.

والثالث إعادة استخدام nonce التوقيع نفسه لرسالتين.

والرابع إنشاء المفاتيح الخاصة أو nonces باستخدام دالة عادية لتوليد الأرقام العشوائية.

والخامس قبول التوقيعات غير المعيارية أو المشوهة من دون تحليل صارم.

والسادس نسيان أن كلًا من

و قد يفي بمعادلة ECDSA الأساسية.

والسابع توقيع بيانات من دون التحقق من الشبكة والنطاق وnonce وتاريخ انتهاء الصلاحية.

والثامن استخدام مفتاح خاص واحد عبر تطبيقات وشبكات بلوكشين غير مرتبطة.

والتاسع كتابة شيفرة مخصصة للمنحنيات الإهليلجية لمحافظ الإنتاج من دون مراجعة خبراء.

والعاشر افتراض أن التوقيع الصحيح يثبت أن المعاملة آمنة أو عادلة أو مقصودة من المالك الأصلي للمفتاح.

الأسئلة الشائعة

إلام يشير اختصار ECDSA؟

يشير ECDSA إلى خوارزمية التوقيع الرقمي بالمنحنى الإهليلجي.

ما استخدام ECDSA في العملات المشفرة؟

تُستخدم لإنشاء التوقيعات التي تفوض معاملات البلوكشين وإجراءات المحافظ الأخرى والتحقق منها.

هل تشفر ECDSA المعاملات؟

لا، فهي تثبت التفويض وسلامة البيانات، لكنها لا تخفي بيانات البلوكشين العامة المعتادة.

ما مفتاح ECDSA الخاص؟

هو عدد صحيح سري يُستخدم لإنشاء التوقيعات واشتقاق المفتاح العام المقابل.

ما مفتاح ECDSA العام؟

هو نقطة على منحنى إهليلجي مشتقة من المفتاح الخاص وتُستخدم للتحقق من التوقيعات.

ما المنحنى الذي تستخدمه Bitcoin مع ECDSA؟

تستخدم Bitcoin منحنى secp256k1 الإهليلجي لتوقيعات معاملات ECDSA التقليدية.

ما المنحنى الذي تستخدمه Ethereum لتوقيعات الحسابات؟

تستخدم الحسابات المملوكة خارجيًا في Ethereum خوارزمية ECDSA على secp256k1.

ما r وs في ECDSA؟

هما المكونان العدديان لتوقيع ECDSA.

ما nonce في ECDSA؟

هو قيمة عددية قياسية سرية خاصة بكل توقيع وتُستخدم أثناء إنشائه.

لماذا يجب عدم إعادة استخدام nonce في ECDSA؟

قد تتيح إعادة استخدام nonce لرسائل مختلفة لمراقبٍ حساب المفتاح الخاص.

ما ECDSA الحتمية؟

هي طريقة توقيع تشتق nonce من المفتاح الخاص وملخص الرسالة عبر إجراء محدد مثل RFC 6979.

هل تلغي ECDSA الحتمية الحاجة إلى العشوائية؟

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

ما قابلية التلاعب بتوقيع ECDSA؟

هي خاصية تتيح أن يكون كل من

و صحيحًا للرسالة والمفتاح العام نفسيهما.

ما التوقيع منخفض s؟

هو توقيع ECDSA معياري لا تتجاوز فيه قيمة

نصف رتبة المنحنى.

ما ترميز DER؟

DER ترميز ثنائي منظم يُستخدم عادةً لتمثيل العددين الصحيحين

و في توقيع ECDSA.

هل يمكن أن يكشف توقيع ECDSA المفتاح الخاص؟

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

هل تستطيع ECDSA استعادة مفتاح خاص مفقود؟

لا، فلا توفر التوقيعات والمفاتيح العامة طريقة عملية لاستعادة مفتاح خاص مفقود أُنشئ بأمان.

هل يمكن تزوير توقيع ECDSA؟

يُعد التزوير غير عملي حسابيًا عند استخدام معلمات ومفاتيح وnonces ودوال تجزئة وتطبيقات آمنة.

هل ECDSA هي نفسها ECC؟

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

هل ECDSA هي نفسها Schnorr؟

لا، إنهما خوارزميتان مختلفتان للتوقيع، حتى عند عملهما على secp256k1.

هل تستخدم Taproot خوارزمية ECDSA؟

يستخدم مسار التوقيع الجديد في Taproot توقيعات Schnorr وفق BIP 340 بدلًا من ECDSA.

هل تستطيع العقود الذكية التحقق من توقيعات ECDSA؟

نعم، توفر بيئات بلوكشين كثيرة عمليات أصلية أو مكتبات للتحقق من توقيعات ECDSA على secp256k1.

هل يثبت توقيع ECDSA الصحيح الهوية القانونية؟

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

هل يضمن التوقيع الصحيح سلامة المعاملة؟

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

هل يستطيع الحاسوب الكمي كسر ECDSA؟

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

هل لا تزال ECDSA آمنة اليوم؟

تظل ECDSA المنفذة على نحو صحيح، مع مفاتيح وnonces آمنة، مقاومة للهجمات التقليدية العملية المعروفة.

الخلاصة

ECDSA خوارزمية أساسية للتوقيع الرقمي تُستخدم للتصريح بمعاملات العملات المشفرة من دون كشف المفاتيح الخاصة.

وتجمع بين عدد قياسي خاص ومفتاح عام على منحنى إهليلجي وملخص رسالة وnonce توقيع سري لإنشاء قيمتي التوقيع

و.

تتحقق عُقد البلوكشين من هذه القيم رياضيًا قبل قبول الإجراء الموقع.

تستخدم Bitcoin تقليديًا ECDSA على secp256k1، بينما تستخدم الحسابات المملوكة خارجيًا في Ethereum المنحنى نفسه مع معلومات توقيع قابلة للاسترداد.

يساعد الترميز الصارم وقواعد القيمة المنخفضة لـ

ومعرّفات السلاسل ونطاقات الرسائل والحماية من إعادة التشغيل على جعل ECDSA أكثر أمانًا في بروتوكولات العملات المشفرة.

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

قد تؤدي إعادة استخدام nonce والعشوائية الضعيفة وكشف عبارات الاسترداد وهجمات القنوات الجانبية والتعامل مع النقاط غير الصالحة وطلبات التوقيع غير الواضحة إلى تقويض الرياضيات القوية.

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

وينبغي للمستخدمين حماية مواد الاسترداد والتحقق من كل معاملة أو رسالة عبر شاشة توقيع موثوقة.

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