عند كلمة "التشفير" ، يتذكر بعض الأشخاص كلمة مرور WiFi ، والقفل الأخضر بجوار عنوان موقعهم المفضل ، ومدى صعوبة الوصول إلى بريد شخص آخر. يتذكر آخرون سلسلة من نقاط الضعف في السنوات الأخيرة مع اختصارات التحدث (DROWN ، FREAK ، POODLE ...) ، والشعارات الأنيقة ، وتحذير لتحديث المتصفح بشكل عاجل.

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

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

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

• الاستراتيجيات الأساسية: القوة الغاشمة ، تحليل التردد ، الاستيفاء ، تخفيض التصنيف والبروتوكولات المتقاطعة.
• نقاط الضعف "ذات العلامات التجارية": نزوة ، جريمة ، بركة ، DROWN ، Logjam.
• الاستراتيجيات المتقدمة: هجمات أوراكل (هجوم Waudenay ، هجوم Kelsey) ؛ طريقة الاجتماع في الوسط ، هجوم عيد الميلاد ، التحيز الإحصائي (تحليل الشفرات التفاضلي ، تحليل الشفرات المتكامل ، إلخ).
• هجمات القناة الجانبية وأقاربهم المقربين ، طرق تحليل الفشل.
• الهجمات على تشفير المفتاح العام: جذر مكعب ، بث ، رسالة مرتبطة ، هجوم Coppersmith ، خوارزمية Polig-Hellman ، غربال رقمي ، هجوم Wiener ، هجوم Bleichenbacher.

تتناول هذه المقالة تحديدًا المواد المذكورة أعلاه حتى هجوم كيلسي.

الاستراتيجيات الأساسية

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

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

القوة الغاشمة البسيطة

يتكون نظام التشفير من جزأين: 1) وظيفة تشفير تأخذ رسالة (نص عادي) في تركيبة مع مفتاح ، ثم تنشئ رسالة مشفرة - نص مشفر ؛ 2) وظيفة فك تشفير تأخذ نصًا مشفرًا ومفتاحًا وتنتج نصًا عاديًا. يجب أن يكون كل من التشفير وفك التشفير سهل الحساب باستخدام المفتاح - وصعب بدونه.

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

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

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

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

لسوء الحظ بالنسبة لمحللي الشفرات ، فإن زيادة حجم المفتاح هو دفاع جيد ضد القوة الغاشمة. مع نمو حجم المفتاح ، يزداد عدد المفاتيح الممكنة أضعافًا مضاعفة. مع أحجام المفاتيح الحالية ، فإن القوة الغاشمة البسيطة غير عملية تمامًا. لمعرفة ما نعنيه ، دعنا نأخذ أسرع كمبيوتر عملاق معروف اعتبارًا من منتصف عام 2019: قمة من شركة IBM ، بأداء يبلغ حوالي 1017 عملية في الثانية. اليوم ، يبلغ طول المفتاح النموذجي 128 بت ، مما يعني 2128 مجموعة ممكنة. سوف يستغرق الكمبيوتر العملاق ساميت حوالي 7800 مرة من عمر الكون لفرز جميع المفاتيح.

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

تحليل التردد

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

المثال الأساسي للشفرات المعرضة لهذا الهجوم هو تشفير بديل بسيط. في هذا التشفير ، يكون المفتاح هو جدول مع استبدال جميع الأحرف. على سبيل المثال ، تتحول "g" إلى "h" ، وتتحول "o" إلى j ، لذا فإن كلمة "go" تصبح "hj". هذا التشفير يصعب فرضه لأن هناك العديد من جداول الاستبدال الممكنة. إذا كنت مهتمًا بالرياضيات ، فإن طول المفتاح الفعال يبلغ حوالي 88 بت: إنه
. لكن تحليل التردد عادة ما ينجز المهمة بسرعة.

ضع في اعتبارك النص المشفر التالي الذي تمت معالجته باستخدام تشفير بديل بسيط:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

منذ Y بشكل متكرر ، بما في ذلك في نهاية العديد من الكلمات ، يمكننا أن نفترض مبدئيًا أن هذا حرف e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

زوجان XD تتكرر في بداية عدة كلمات. على وجه الخصوص ، فإن الجمع XDeLe يعني بوضوح الكلمة these أو thereفلنتابع:

قال آل أوجل إنه هيجن ANF eALth DGLAtWG من ALe FLeAUt GR WN OGQL ZDWBGEGZDO

بعد ذلك ، افترض ذلك L مباراة r, A - a وما إلى ذلك وهلم جرا. من المحتمل أن يستغرق الأمر عدة محاولات ، ولكن بالمقارنة مع هجوم القوة الغاشمة الكامل ، فإن هذا الهجوم يعيد النص الأصلي في أقصر وقت ممكن:

هناك أشياء في السماء والأرض أكثر مما تحلم به فلسفتك

بالنسبة للبعض ، فإن حل مثل هذه "التشفير" هواية مثيرة.

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

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

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

الحسابات المسبقة

خذ على سبيل المثال المدينة الافتراضية بريكوم هايتس ، التي يبلغ عدد سكانها 200 نسمة. يحتفظ كل منزل في المدينة بأشياء ثمينة تبلغ قيمتها في المتوسط ​​000 ألف دولار ، ولكن ليس أكثر من 30 دولار. احتكرت شركة أكمي للصناعات سوق الأمان في بريكوم ، مما يجعل أقفال الأبواب من فئة كويوت ™ الأسطورية. وفقًا لتحليل الخبراء ، يمكن فقط لآلة افتراضية معقدة للغاية ، والتي تتطلب حوالي خمس سنوات واستثمار 000 دولار ، كسر قفل من فئة Coyote. هل المدينة آمنة؟

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

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

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

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

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

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

استيفاء

ها هو المحقق الشهير شيرلوك هولمز ، وهو يقوم بهجوم استيفاء على الدكتور واتسون التعساء:

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

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

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

لنفترض أننا لاحظنا في 28 ديسمبر أن بوب يكتب شيئًا ما في يومياته. عندما ينتهي ، نأخذه بتكتم وننظر إلى الإدخال الأخير:

تاريخ: 235/520

مذكراتي العزيزة،

كان اليوم يوم جيد. خلال 64 اليوم لدي موعد مع أليس ، التي تعيش في شقة 843. أنا حقا أعتقد أنها قد تكون كذلك 26!

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

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

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

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

عبر البروتوكول / الرجوع إلى إصدار سابق

في The Illusion of Deception (2013) ، حاولت مجموعة من المخادعين خداع ثروة قطب التأمين الفاسد آرثر تريسلر. من أجل الوصول إلى حساب آرثر المصرفي ، يجب على المخادعين إما تقديم اسم المستخدم وكلمة المرور الخاصة به ، أو جعله يظهر شخصيًا في البنك والمشاركة في المخطط.

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

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

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

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

تكسير: مرحبًا؟ هذا هو آرثر تريسلر. أود استعادة كلمة المرور الخاصة بي.

أمين الصندوق: عظيم. يرجى إلقاء نظرة على دفتر الرموز السرية الشخصي الخاص بك ، الصفحة 28 ، كلمة 3. سيتم تشفير جميع الرسائل التالية باستخدام هذه الكلمة المعينة كمفتاح. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV ...

تكسير: مرحبًا ، انتظر ، انتظر. هل هو حقا ضروري؟ ألا يمكننا التحدث مثل الناس العاديين؟

أمين الصندوق: لا أوصي بفعل هذا.

تكسير: أنا فقط ... لقد مررت بيوم رديء ، حسنًا؟ أنا عميل VIP ولست في حالة مزاجية للبحث في تلك الدفاتر الغبية.

أمين الصندوق: بخير. إذا كنت تصر ، سيد تريسلر. ماذا تريد؟

تكسير: من فضلكم ، أود التبرع بكل أموالي لصندوق أرثر تريسلر الوطني للضحايا.

(يوقف).

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

تكسير: ماذا بي؟

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

تكسير:… لقد فقدته. هل هو حقا ضروري؟ ألا يمكنك الموافقة على الصفقة فقط؟

أمين الصندوق: لا. أنا آسف ، سيد تريسلر. مرة أخرى ، هذا هو الإجراء الأمني ​​الذي طلبته. إذا كنت ترغب في ذلك ، يمكننا إرسال رمز PIN جديد إلى صندوق البريد.

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

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

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

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

أمين الصندوق: - # @ $ # @ $ # * @ $$ @ # * سيتم تشفيرها بهذه الكلمة كمفتاح. AAAYRR PLRQRZ MMNJK LOJBAN ...

تريسلر: آسف ، لم أفهم تمامًا. مرة أخرى؟ في أي صفحة؟ اي كلمة؟

أمين الصندوق: هذه الصفحة @ # $ @ # * $) # * # @ () # @ $ (# @ * $ (# @ *.

تريسلر: ماذا؟

أمين الصندوق: رقم الكلمة عشرين @ $ # @ $ #٪ # $.

تريسلر: بجد! يكفي بالفعل! أنت مع بروتوكول الأمان الخاص بك نوع من السيرك. أعلم أنه يمكنك التحدث معي بشكل طبيعي.

أمين الصندوق: لا أوصي ...

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

أمين الصندوق:… نعم. بخير. ماذا تريد؟

تريسلر: أرغب في تحويل 20 دولار إلى Lord Business Investments ، رقم الحساب ...

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

تريسلر: ماذا؟ اه صحيح. 1234.

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

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

هذا بالضبط ما حدث مع بروتوكول SSLv2 في عام 1995. لطالما بدأت حكومة الولايات المتحدة في النظر إلى التشفير باعتباره سلاحًا يُحفظ بعيدًا عن الأعداء الخارجيين والداخليين. تمت الموافقة على مقتطفات التعليمات البرمجية بشكل فردي للتصدير من الولايات المتحدة ، غالبًا مع التخفيف المتعمد للخوارزمية. تم منح Netscape ، مطور متصفح Netscape Navigator الأكثر شهرة ، إذنًا لـ SSLv2 فقط مع مفتاح RSA ضعيف بطبيعته يبلغ 512 بت (و 40 بت لـ RC4).

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

وجدت هذه النظرية طريقها إلى هجومين رفيعي المستوى هزما أمان بروتوكول SSL واحدًا تلو الآخر في عام 2015 ، وكلاهما اكتشفهما باحثو Microsoft و INRIA. أولاً ، في فبراير ، تم الكشف عن تفاصيل هجوم FREAK ، وبعد ثلاثة أشهر ، حدث هجوم مماثل آخر يسمى Logjam ، والذي سنناقشه بمزيد من التفصيل عندما ننتقل إلى الهجمات على تشفير المفتاح العام.

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

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

وقبل المضي قدمًا ، يجب ذكر هجوم متقدم ...

هجوم أوراكل

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

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

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

لذلك ، يتواصل بوب وأليس باستخدام تشفير بديل بسيط باستخدام مفتاح معروف لهما فقط. إنها صارمة للغاية بشأن طول الرسائل: فهي بطول 20 حرفًا بالضبط. لذلك اتفقوا على أنه إذا أراد شخص ما إرسال رسالة أقصر ، فيجب عليهم إضافة بعض النص الوهمي إلى نهاية الرسالة لجعلها بطول 20 حرفًا بالضبط. بعد بعض المناقشة ، قرروا أنهم سيقبلون فقط النصوص الوهمية التالية: a, bb, ccc, dddd وهكذا ، يُعرف النص الوهمي بأي طول مطلوب.

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

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

تكسير: PREWF ZHJKL MMMN. LA

أليس: نص وهمي غير صالح.

تكسير: PREWF ZHJKL MMMN. LB

أليس: نص وهمي غير صالح.

تكسير: PREWF ZHJKL MMMN. LC

أليس: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

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

تكسير: REWF ZHJKL MMMN. LAA

أليس: نص وهمي غير صالح.

تكسير: REWF ZHJKL MMMN. LBB

أليس: نص وهمي غير صالح.

بعد عدة محاولات ...

تكسير: REWF ZHJKL MMMN. LGG

أليس: نص وهمي غير صالح.

تكسير: REWF ZHJKL MMMN. LHH

أليس: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

مرة أخرى ، ليس لدى جهاز التكسير أي فكرة عما قالته أليس للتو ، لكنه يشير إلى أن H يجب أن يتطابق مع b لأن أليس افترضت نصًا وهميًا.

وهكذا ، حتى يعرف المهاجم معنى كل شخصية.

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

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

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

في عام 1998 ، أجاب عالم التشفير السويسري Daniel Bleichenbacher بالإيجاب. أظهر هجومًا أوراكل على نظام تشفير المفتاح العام RSA المستخدم على نطاق واسع باستخدام مخطط رسائل محدد. في بعض تطبيقات RSA ، يستجيب الخادم برسائل خطأ مختلفة ، اعتمادًا على ما إذا كان النص العادي يطابق المخطط أم لا ؛ كان هذا كافيا لتنفيذ الهجوم.

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

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

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

هجوم فوديني

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

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

يستهدف هجوم Vaudeney أسلوب التشغيل الشهير لـ CBC (Cipher Block Chaining). يتعامل الهجوم مع تشفير الكتلة الأساسي باعتباره صندوقًا أسود سحريًا لا يمكن اختراقه ويتجاوز الأمان تمامًا.

فيما يلي رسم تخطيطي يوضح كيفية عمل وضع CBC:

تشير علامة الجمع المحاطة بدائرة إلى عملية XOR (عملية OR حصرية). على سبيل المثال ، تم استلام كتلة النص المشفر الثانية:

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

نظرًا لأن CBC تستخدم عملية XOR الثنائية بكثافة ، فلنأخذ لحظة لاستدعاء بعض خصائصها:

• العجز:
• التبادلية:
• الترابط:
• الانعكاس الذاتي:
• البايت: بايت ن من = (بايت ن من ) (بايت n من )

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

هناك اختلافان طفيفان وفرق رئيسي واحد بين سيناريو أليس وهجوم فوديني. اثنان صغيران:

• في النص ، توقعت أليس أن تنتهي النصوص العادية بالأحرف a, bb, ccc وما إلى ذلك وهلم جرا. في هجوم Vaudeney ، يتوقع الضحية بدلاً من ذلك أن تنتهي النصوص العادية N مرة بالبايت N (أي النظام الست عشري 01 أو 02 02 أو 03 03 03 وهكذا). هذا اختلاف تجميلي بحت.
• في نص أليس ، كان من السهل معرفة ما إذا كانت أليس قد قبلت الرسالة من خلال الرد "نص وهمي غير صحيح". في هجوم فوديني ، يتطلب الأمر مزيدًا من التحليل والتنفيذ الدقيق من جانب الضحية ؛ ولكن من أجل الإيجاز ، دعونا نعتبر أن هذا التحليل لا يزال ممكناً.

الفرق الرئيسي:

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

هذا الاختلاف الرئيسي هو الجزء الأخير من اللغز لفهم هجوم فوديني ، لذلك دعونا نفكر للحظة في سبب وكيفية هجوم أوراكل على CBC.

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

ضع في اعتبارك أنه في سيناريو أليس ، كانت لدينا العلاقات التالية:

$$ display $$ text {SIMPLE_SUBSTITUTION} (نص {ciphertext} ، نص {مفتاح}) = نص {plaintext} $$ عرض $$

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

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

دعنا نسمي هذا "معادلة CBC".

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

لنفترض أننا استعدنا ماذا بعد؟ حسنًا ، يمكننا بعد ذلك إخراج الكتلة الأخيرة بأكملها من النص العادي مرة واحدة () بمجرد الدخول (التي لدينا) و
حصلت في معادلة CBC.

لذلك ، نحن متفائلون بشأن الخطة الشاملة للهجوم ، وقد حان الوقت للعمل على التفاصيل. انتبه إلى كيفية تسريب المعلومات حول النص العادي على الخادم بالضبط. في سيناريو أليس ، كان التسرب بسبب استجابة أليس بالرسالة الصحيحة فقط إذا انتهى $ inline $ text {SIMPLE_SUBSTITUTION} (text {ciphertext} ، text {key}) $ inline $ مع السطر a (أو bb، وما إلى ذلك ، ولكن فرص حدوث هذه الظروف بشكل عشوائي كانت ضئيلة للغاية). على غرار CBC ، يقبل الخادم الحشو إذا وفقط إذا ينتهي بالنظام الست عشري 01. لذلك دعونا نجرب نفس الحيلة: إرسال نصوص مشفرة مزيفة بقيمنا المزيفة حتى يقبل الخادم المساحة المتروكة.

عندما يقبل الخادم الحشو لإحدى رسائلنا المزيفة ، فهذا يعني أن:

نستخدم الآن خاصية XOR بايت:

نحن نعرف الحد الأول والثالث. وقد رأينا بالفعل أن هذا يسمح لك باستعادة العضو المتبقي - آخر بايت من :

يمنحنا هذا أيضًا البايت الأخير من كتلة النص العادي النهائي عبر معادلة CBC وخاصية البايت.

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

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

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

في السابق ، لم نتمكن من القيام بذلك لأنه لم يكن لدينا البايت الأخير حتى الآن. .

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

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

ماذا عن باقي النص؟ لاحظ أن القيمة هو في الواقع $ inline $ text {BLOCK_DECRYPT} (text {key}، C_ {247}) $ inline $. يمكننا وضع أي كتلة أخرى بدلاً من ذلك ، وسيظل الهجوم ناجحًا. في الواقع ، يمكننا أن نطلب من الخادم عمل $ inline $ text {BLOCK_DECRYPT} $ inline $ لأي بيانات. في هذه المرحلة ، انتهت اللعبة - يمكننا فك تشفير أي نص مشفر (انظر مرة أخرى إلى مخطط فك تشفير CBC لترى ذلك ؛ ولاحظ أن المتجه الرابع متاح للجمهور).

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

هجوم كيلسي

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

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

لرؤية المبدأ قيد التنفيذ ، ضع في اعتبارك نصين عاديين:

نص عادي 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

نص عادي 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

افترض أنه تم ضغط كلا النصين العاديين ثم تشفيرهما. تحصل على نصين مشفرين ناتجين وعليك تخمين النص المشفر الذي يتوافق مع أي نص عادي:

نص مجفر 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

نص مجفر 2: DWKJZXYU

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

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

مرة أخرى ، كما هو الحال في هجمات oracle الأخرى ، لدينا نسبة:

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

لتوضيح كيفية عمل مثل هذا الهجوم ، دعنا نستخدم مخطط ضغط وهمي توصلنا إليه للتو: TOYZIP. يبحث عن سطور النص التي ظهرت بالفعل في النص ويستبدلها بثلاثة مواضع بايت للبايت التي تشير إلى مكان العثور على المثيل السابق للسطر وعدد مرات حدوثه هناك. على سبيل المثال ، الخط helloworldhello يمكن ضغطها في helloworld[00][00][05] 13 بايت مقارنةً بالبايت الأصلي البالغ 15 بايت.

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

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

الخادم: طول النتيجة هو 14.

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=a.

الخادم: طول النتيجة هو 18.

تلاحظ الكسارة: [الأصل 14] + [ثلاثة بايت التي حلت محلها password=] + a

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=b.

الخادم: طول النتيجة هو 18.

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=с.

الخادم: طول النتيجة هو 17.

تلاحظ الكسارة: [الأصل 14] + [ثلاثة بايت التي حلت محلها password=c]. يفترض هذا أن النص العادي الأصلي يحتوي على السلسلة password=c. أي أن كلمة المرور تبدأ بحرف c

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=сa.

الخادم: طول النتيجة هو 18.

تلاحظ الكسارة: [الأصل 14] + [ثلاثة بايت التي حلت محلها password=с] + a

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=сb.

الخادم: طول النتيجة هو 18.

(… في وقت اخر…)

تكسير: يرجى ضغط وتشفير النص العادي المضاف إليه password=со.

الخادم: طول النتيجة هو 17.

تلاحظ الكسارة: [الأصل 14] + [ثلاثة بايت التي حلت محلها password=co]. بنفس المنطق ، يستنتج المهاجم أن كلمة المرور تبدأ بالأحرف co

وهكذا حتى يتم استرداد كلمة المرور بالكامل.

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

نقاط ضعف العلامة التجارية: الجريمة ، البركة ، السقوط

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

الجريمة

إذا استهدف الهجوم متصفح الضحية وشبكتها ، فسيكون بعضها أسهل والبعض الآخر أكثر صعوبة. على سبيل المثال ، من السهل رؤية حركة المرور للضحية: يكفي الجلوس معها في نفس المقهى باستخدام شبكة WiFi. لهذا السبب ، يُنصح الضحايا المحتملون (أي الجميع) عمومًا باستخدام اتصال مشفر. سيكون الأمر أكثر صعوبة ، ولكن لا يزال من الممكن ، تقديم طلبات HTTP نيابة عن الضحية إلى بعض مواقع الطرف الثالث (على سبيل المثال ، Google). يحتاج المهاجم إلى جذب الضحية إلى صفحة ويب ضارة باستخدام برنامج نصي يقوم بالطلب. سيوفر متصفح الويب تلقائيًا ملف تعريف ارتباط الجلسة المناسب.

يبدو مذهلاً. إذا ذهب بوب إلى evil.com، فهل يمكن للبرنامج النصي الموجود على هذا الموقع أن تطلب من Google إرسال كلمة مرور بوب بالبريد الإلكتروني إلى [email protected]؟ حسنًا ، من الناحية النظرية نعم ، لكن في الواقع لا. يسمى هذا السيناريو هجوم تزييف طلب عبر المواقع (طلب تزوير عبر الموقع، CSRF) ، وكان شائعًا في منتصف التسعينيات. اليوم إذا evil.com عند محاولة مثل هذه الحيلة ، عادةً ما يستجيب Google (أو أي موقع يحترم نفسه) بـ "رائع ، ولكن رمز CSRF الخاص بك لهذه المعاملة سيكون ... mmm ... три триллиона и семь. من فضلك كرر هذا الرقم ". تفرض المتصفحات الحديثة شيئًا يسمى "سياسة نفس الأصل" حيث لا تتمتع البرامج النصية الموجودة على الموقع أ بإمكانية الوصول إلى المعلومات المرسلة بواسطة الموقع ب. لذلك ، فإن البرنامج النصي الموجود على evil.com يمكن إرسال الطلبات إلى google.com، ولكن لا يمكن قراءة الردود أو إكمال المعاملة بالفعل.

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

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

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

من خلال فهم النظرية ، ابتكر مؤلفو CRIME استغلالًا يمكنه سرقة ملفات تعريف الارتباط الخاصة بالجلسة لمجموعة واسعة من المواقع ، بما في ذلك Gmail و Twitter و Dropbox و Github. أثرت الثغرة الأمنية على معظم متصفحات الويب الحديثة ، مما أدى إلى إصدار التصحيحات التي دفنت بصمت ميزة الضغط في SSL بحيث لا يتم استخدامها على الإطلاق. الوحيد المحمي من الثغرة الأمنية هو Internet Explorer الموقر ، والذي لم يستخدم ضغط SSL على الإطلاق.

بودل

في أكتوبر 2014 ، تسبب فريق أمان Google في إثارة ضجة في مجتمع الأمان. كانوا قادرين على استغلال ثغرة أمنية في بروتوكول SSL الذي تم تصحيحه منذ أكثر من عقد.

اتضح أنه أثناء تشغيل الخوادم TLSv1.2 الجديد الرائع ، ترك الكثيرون الدعم لـ SSLv3 القديم للتوافق مع الإصدارات السابقة مع Internet Explorer 6. لقد تحدثنا بالفعل عن هجمات الرجوع إلى إصدار أقدم ، لذا يمكنك تخيل ما يحدث. يعد التخريب المنظم جيدًا لبروتوكول المصافحة والخوادم جاهزة للعودة إلى SSLv3 القديم الجيد ، مما يعكس بشكل أساسي آخر 15 عامًا من البحث الأمني.

للسياق التاريخي ، فيما يلي ملخص قصير لتاريخ SSL حتى الإصدار 2 بواسطة Matthew Green:

يُعد بروتوكول أمان طبقة النقل (TLS) أهم بروتوكول أمان على الإنترنت. [..] تعتمد كل معاملة تجريها على الإنترنت تقريبًا على TLS. [..] لكن TLS لم تكن دائمًا TLS. بدأ البروتوكول حياته في نتسكيب للاتصالات تسمى "طبقة مآخذ التوصيل الآمنة" أو SSL. تقول الشائعات أن الإصدار الأول من SSL كان فظيعًا للغاية لدرجة أن المطورين جمعوا جميع نسخ الكود ودفنوها في مكب نفايات سري في نيو مكسيكو. نتيجة لذلك ، فإن أول إصدار عام من SSL هو في الواقع إصدار SSL 2. إنه قبيح جدًا ، و [..] كان منتجًا من منتصف التسعينيات ، والذي يعتبره المشفرون المعاصرون "العصور المظلمة للتشفير". العديد من أبشع هجمات التشفير التي نعرفها اليوم لم يتم اكتشافها بعد. نتيجة لذلك ، كان على مطوري بروتوكول SSLv2 أن يتلمسوا طريقهم في الظلام ، وواجهوا العديد من الوحوش الرهيبة - مما يثير استياءهم ولصالحنا ، حيث تركت الهجمات على SSLv2 دروسًا لا تقدر بثمن للجيل القادم من البروتوكولات.

بعد هذه الأحداث ، في عام 1996 ، أعادت شركة Netscape المحبطة تصميم بروتوكول SSL من البداية. كانت النتيجة SSL الإصدار 3 ، والذي تم إصلاح العديد من مشكلات الأمان المعروفة لسابقتها.

لحسن الحظ بالنسبة للمفرقعات ، "القليل" لا يعني "الكل". بشكل عام ، قدم SSLv3 جميع اللبنات الأساسية اللازمة لشن هجوم Wodenay. استخدم البروتوكول تشفير كتلة في وضع CBC ونظام حشو غير آمن (تم إصلاح ذلك في TLS ؛ ومن هنا جاءت الحاجة إلى هجوم الرجوع إلى إصدار أقدم). إذا كنت تتذكر مخطط الحشو في وصفنا الأصلي لهجوم Vaudeney ، فإن مخطط SSLv3 مشابه جدًا.

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

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

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

غارقة

كما ذكرنا سابقًا ، كانت SSLv3 بها عيوب ، لكنها كانت مختلفة اختلافًا جوهريًا عن سابقتها ، نظرًا لأن SSLv2 المتسرب كان نتاج عصر آخر. هناك كان من الممكن مقاطعة الرسالة في المنتصف: соглашусь на это только через мой труп تحولت إلى соглашусь на это؛ يمكن للعميل والخادم الاجتماع على الإنترنت ، وبناء الثقة ، وتبادل الأسرار أمام المهاجم ، الذي يمكنه بعد ذلك انتحال صفتهما بسهولة. هناك أيضًا مشكلة تشفير التصدير ، والتي ذكرناها عند مراجعة FREAK. كانت هذه هي التشفير Sodom و Gomorrah.

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

تسأل ، ما الذي يهمنا ما يفعلونه هناك؟ لديهم جلسة ضعيفة ، لكن لا ينبغي أن يؤثر ذلك على الجلسات الأخرى أو أمان الخادم - أليس كذلك؟ كذلك ليس تماما. نعم ، هذا ما ينبغي أن يكون عليه الأمر من الناحية النظرية. لكن لا - لأن إنشاء شهادات SSL يفرض عبئًا معينًا ، ونتيجة لذلك تستخدم العديد من الخوادم نفس الشهادات ، ونتيجة لذلك ، تستخدم نفس مفاتيح RSA لاتصالات TLS و SSLv2. لجعل الأمور أسوأ ، نظرًا لوجود خطأ في OpenSSL ، لم يكن خيار "تعطيل SSLv2" يعمل في الواقع في تطبيق SSL الشهير هذا.

جعل هذا من الممكن شن هجوم عبر البروتوكولات على TLS ، والذي تم استدعاؤه غارقة (فك تشفير RSA مع التشفير الإلكتروني القديم والضعيف). تذكر أن هذا ليس هو نفسه هجوم قصير ؛ لا يحتاج الكراك إلى التصرف مثل "رجل في المنتصف" ولا يحتاج إلى إشراك العميل من أجل المشاركة في جلسة غير آمنة. يبدأ المهاجمون ببساطة جلسة SSLv2 غير آمنة مع الخادم أنفسهم ، ويهاجمون البروتوكول الضعيف ، ويستعيدون مفتاح RSA الخاص بالخادم. هذا المفتاح صالح أيضًا لاتصالات TLS ، ومن الآن فصاعدًا ، لن ينقذه أي قدر من أمان TLS من التعرض للاختراق.

ولكن للتغلب على المشكلة ، فأنت بحاجة إلى هجوم عملي ضد SSLv2 ، والذي يسمح لك باستعادة ليس فقط حركة مرور معينة ، ولكن أيضًا مفتاح خادم RSA السري. على الرغم من أن هذا الإعداد صعب ، كان بإمكان الباحثين اختيار أي ثغرة تم إغلاقها تمامًا بعد SSLv2. في النهاية ، وجدوا خيارًا مناسبًا: هجوم Bleichenbacher ، الذي ذكرناه سابقًا والذي سنشرحه بالتفصيل في المقالة التالية. SSL و TLS محصنون ضد هذا الهجوم ، لكن بعض ميزات SSL العشوائية ، جنبًا إلى جنب مع المفاتيح القصيرة في تشفير فئة التصدير ، جعلت ذلك ممكنًا تنفيذ محدد لـ DROWN.

في وقت النشر ، أثرت ثغرات DROWN على 25٪ من أفضل مواقع الإنترنت ، ويمكن تنفيذ الهجوم بموارد متواضعة متاحة حتى للمتسللين المنفردين المؤذيين. استغرق الأمر ثماني ساعات من الحوسبة و 440 دولارًا لاستخراج مفتاح RSA للخادم ، وغيّر SSLv2 حالته من "عفا عليه الزمن" إلى "إشعاعي".

انتظر ، ماذا عن Heartbleed؟

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

لنأخذ استراحة

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

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

ثم نظرنا إلى ثلاثة أمثلة أخرى لتطبيق هذه المبادئ. أولاً ، CRIME و POODLE: هجومان يعتمدان على قدرة المهاجم على إدخال نص عادي تعسفي إلى جانب النص العادي المستهدف ، ثم فحص استجابات الخادم و ثمباستخدام منهجية هجوم أوراكل ، استخدم هذه المعلومات الهزيلة لاستعادة النص العادي جزئيًا. ذهبت CRIME في طريق مهاجمة Kelsey على ضغط SSL ، بينما استخدم POODLE بدلاً من ذلك نوعًا مختلفًا من هجوم Vaudeney على CBC بنفس التأثير.

ثم وجهنا انتباهنا إلى هجوم DROWN عبر البروتوكولات ، والذي ينشئ اتصالًا بالخادم باستخدام بروتوكول SSLv2 القديم ، ثم يستعيد المفاتيح السرية للخادم باستخدام هجوم Bleichenbacher. في الوقت الحالي ، تخطينا التفاصيل الفنية لهذا الهجوم ؛ مثل Logjam ، سيتعين عليها الانتظار حتى نحصل على فهم جيد لأنظمة تشفير المفتاح العام ونقاط ضعفها.

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

المصدر: www.habr.com