نتحدث عن PAKE

الآن دعنا نتحدث عن أمن المعلومات. هذا المنشور مخصص لإطلاق الدورة التدريبية "أمن معلومات التشفير" ، والتي تبدأ في 30 مايو. دعنا نذهب.

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




لفهم لماذا نتحدث عن هذا الهراء ، دعونا ننظر إلى مشكلة حقيقية.

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

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

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

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

ما هو PAKE؟

يعد بروتوكول PAKE ، الذي اقترحه Bellovin و Merritt لأول مرة ، نوعًا معينًا من بروتوكول التبادل الرئيسي . صُممت بروتوكولات تبادل المفاتيح (أو "الاتفاقيات الرئيسية") لمساعدة الطرفين (دعنا نطلق عليهما اسم العميل والخادم) على الاتفاق على مفتاح مشترك باستخدام تشفير المفتاح العام. أقرب بروتوكولات التبادل الرئيسية (مثل Diffie-Hellman الكلاسيكية) كانت غير مصرح بها ، مما يجعلها عرضة لهجمات مثل الرجل في الوسط . الميزة المميزة لبروتوكولات PAKE هي أن العميل يصادق على الخادم بكلمة مرور. لأسباب واضحة ، يُفترض أن كلمة المرور أو علامة التجزئة الخاصة بها معروفة بالفعل للخادم ، مما يسمح بالتحقق.

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

تمثيل مثالي لبروتوكول PAKE. تتضمن المدخلات من كلا الجانبين بعض العشوائية ، والتي لا تظهر هنا. لا يحتاج التنصت إلى معرفة المفتاح السري المشترك K ، والذي يعتبر عشوائيًا ولا يمثل وظيفة كلمة المرور.

بطبيعة الحال ، فإن المشكلة الواضحة في PAKE هي أن العديد من المطورين لا يرغبون في تشغيل بروتوكول "تبادل المفاتيح" في المقام الأول! إنهم يريدون فقط التأكد من أن المستخدم يعرف كلمة المرور.

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

SRP: PAKE ، في أي وقت نسي نفسه

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

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

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

على الرغم من حقيقة أنني قلت أن PAKE لا يستخدم الآن ، لا تزال هناك استثناءات للقواعد.

هناك بروتوكول واحد كبير تم تطويره في عام 1998 بواسطة Tom Wu (يجب عدم الخلط بينه وبين Tim Wu) ، والذي يسمى "SRP" (اختصار لـ "Secure Remote Password"). في الواقع ، إنها مجرد لعبة PAKE ثلاثية المراحل مع بعض الوظائف الإضافية التي لم يتم تنفيذها في الأعمال الأولى. بقدر ما أعرف ، يختلف SRP في أنه بروتوكول PAKE الأكثر شيوعًا في العالم. سأقدم إثباتين لهذا البيان:

1. تم توحيد SRP كـ ciphersuite وتطبيقه في المكتبات مثل ، على سبيل المثال ، OpenSSL ، على الرغم من أنه لا يبدو أن هناك أحد يستخدمه بشكل خاص.
2. تستخدم Apple على نطاق واسع SRP في iCloud Key Vault

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

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

بدلاً من هذه التفاصيل غير الضرورية ، اسمحوا لي أن أكتب ملخصًا موجزًا ​​لأفكاري حول SRP:

1. SRP يفعل بعض الأشياء في نصابها الصحيح. أولاً ، على عكس الإصدارات السابقة من PAKE ، لا تحتاج إلى تخزين كلمة المرور الخام على الخادم (أو ، معادلًا ، تجزئة يمكن استخدامها من قبل مهاجم بدلاً من كلمة مرور). بدلاً من ذلك ، يقوم الخادم بتخزين "المدقق" ، وهو عبارة عن وظيفة أحادية الاتجاه لتجزئة كلمة المرور. هذا يعني أن تسرب قاعدة بيانات كلمة المرور لا يسمح للمهاجم باستبدال المستخدم فورًا إلا إذا لم ينفذ المزيد من هجمات القاموس المكلفة. (الاسم التقني لهذا هو "غير المتماثلة" PAKE.)
2. هناك أخبار أفضل ، لم يتم اختراق الإصدار الحالي من SRP (v4 v6a) حتى الآن!
3. ومع ذلك (لا تهين من قبل المطورين) ، فإن بنية بروتوكول SRP مجنونة تمامًا ، وتم اختراق إصداراتها السابقة عدة مرات - وهذا هو السبب في أننا لدينا الآن الإصدار 6a. بالإضافة إلى ذلك ، "إثبات السلامة" في المقال البحثي الأصلي لا يثبت في الواقع أي شيء .
4. يعتمد SRP حاليًا على حساب عدد صحيح (نهائي) ، ولأسباب مختلفة (انظر الفقرة 3 أعلاه) لا يمكن نقل بنيانها بوضوح إلى منحنى إهليلجي. يتطلب ذلك مزيدًا من النطاق الترددي والحساب ، لذلك لا يمكن لـ SRP الاستفادة من العديد من تحسينات الأداء التي طورناها في الوظائف الإضافية مثل Curve25519 .
5. SRP عرضة لهجمات ما قبل الحوسبة لأنه ينقل ملح المستخدم إلى أي مهاجم يمكنه بدء جلسة SRP. هذا يعني أنه يمكنني أن أطلب من الخادم ملحك وأنشئ قاموسًا لتجزئة كلمات المرور المحتملة قبل اختراق الخادم.
6. على الرغم من كل هذه العيوب ، فإن SRP بسيط للغاية ، كما أنه مزود برمز العمل. بالإضافة إلى ذلك ، يشتمل OpenSSL على رمز عمل يتكامل حتى مع TLS ، مما يسهل تنفيذه نسبيًا.

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

معتوه: نلقي جيل جديد

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

ثم ، في بداية العام الماضي ، كشف Jarecki و Kravczyk و Xu للعالم عن بروتوكول جديد يسمى OPAQUE . لديها عدد من المزايا المهمة:

1. يمكن تنفيذه حتى لو كانت هناك مشاكل في Diffie-Hellman ولوغاريتمات منفصلة. هذا يعني أنه ، على عكس SRP ، يمكن إنشاء مثيل له بسهولة باستخدام منحنيات إهليلجية فعالة.
2. أفضل من ذلك: لا تكشف OPAQUE عن الملح للمهاجمين. إنه يحل هذه المشكلة عن طريق استخدام "PRF" النسيان "لضم الملح مع كلمة المرور بحيث لا يتلقى العميل الملح ولا يتلقى الخادم كلمة المرور.
3. OPAQUE يعمل مع أي وظيفة التجزئة كلمة المرور. نظرًا لأن جميع أعمال التجزئة تتم على العميل ، فيمكن أن تقوم OPAQUE بالفعل بإيقاف التحميل من الخادم ، وتحرير الخدمة عبر الإنترنت ، على سبيل المثال ، لاستخدام إعدادات الأمان الضخمة للغاية ، على سبيل المثال ، تكوين scrypt مع الكثير من ذاكرة الوصول العشوائي .
4. من حيث عدد الرسائل والأس ، OPAQUE لا يختلف كثيرا عن SRP. ولكن نظرًا لأنه يمكن تنفيذه بمعلمات أكثر كفاءة ، فمن المحتمل أن يعمل بكفاءة أكبر.
5. بخلاف SRP ، فإن OPAQUE لديها أدلة أمان معقولة (في نموذج قوي للغاية).

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

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

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

من الناحية النظرية ، يمكنك حل هذه المشكلة عن طريق حساب دالة تجزئة كلمة المرور باستخدام بروتوكول حساب آمن للطرفين (2PC) . في الممارسة العملية ، من شبه المؤكد أن تكون هذه الحلول غير فعالة ، في المقام الأول لأن وظائف تجزئة كلمة المرور معقدة وتستغرق وقتًا طويلاً. هذا سيزيد بشكل لا يصدق من تعقيد أي نظام 2PC.

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

يعمل شيء مثل هذا:

يخزن الخادم "ملح" ، ويكون للعميل password.salt2 = PRF (ملح ، كلمة مرور) ، ويتم حساب ذلك بين العميل والخادم باستخدام بروتوكول لن يتعرف فيه العميل أبدًا على الملح وسيعرف الخادم كلمة المرور. يتلقى العميل salt2K = PasswordHash (salt2 ، كلمة المرور) - وكل هذا يعتبر على العميل.

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

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

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

C = تشفير (K ، المفتاح السري للعميل | المفتاح العمومي للخادم)


نسخة كاملة من بروتوكول OPAQUE ، مقتطفات من المقال .

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

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

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

استنتاج

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

وفقًا للتقاليد المعمول بها ، نحن في انتظار تعليقاتكم وندعوكم لزيارة يوم الباب المفتوح ، والذي سيقام في 27 مايو من قبل معلمتنا ، الكابتناليست إيلينا كيرشانوفا .