هذا السيناريو آمنة ؟

Question

أنا باستخدام RSA تشفير الاتصال بين الخادم والعميل.دعونا نقول لدينا 2 Asymetric مفاتيح, مفتاح 1 و key2.

الملقم key1 (خاص) من البداية العميل لديه key1(العامة)

حتى هنا هو السيناريو:

1. العميل يولد key2
2. العميل الاتصال إلى الملقم
3. إرسال key2(العامة) المشفرة مع key1(العامة)
4. من الآن فصاعدا سيقوم الملقم إرسال جميع البيانات مشفرة مع key2(العامة)
5. يرسل العميل عشوائي البيانات إلى الخادم
6. يرسل الملقم مرة أخرى نفس البيانات المجزأة
7. العميل التحقق من أن البيانات الصحيحة

بقدر ما أستطيع أن أرى هذا ينبغي أن يمنع رجل-في-الوسط والهجوم ، أو أنا في عداد المفقودين شيئا ؟ في نقطة 7 العميل يجب أن تعرف إذا كان شخص ما يحاول إعطاء الخادم الخطأ مفتاح تشفير ، كما أي شخص آخر ولكن الخادم يمكن فك تشفير key2(العامة).

إذا كان هناك أي شيء يمكن القيام به لتحسين الأمن من فضلك قل لي.

Answer 1

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

Answer 2

طالما key1 (خاص) لم يتم اعتراضها بطريقة أو بأخرى من قبل طرف ثالث, السيناريو الخاص بك تبدو آمنة.

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

على الرغم من صندوق القياس, هذا هو أساسا ما تفعله لذا أقول آمن به.

Answer 3

وأنا أتفق, مجرد استخدام TLS.

أيضا ، ما قيمة تفعل الخطوات من 5 إلى 7 ؟ MITM الرغبة في القيام بهجوم التي من شأنها العمل بعد الخطوات 1-4 (مثلا ، دوس من نوع ما عن طريق تمرير ن المعاملات من خلال ثم توقف إجبار إعادة المحاولة من البداية) يمكن أن تفعل ذلك فقط وكذلك بعد 5-7.ماذا تضيف ؟

-- MarkusQ

Answer 4

لا, هذا البروتوكول ليست آمنة.

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

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

---

@Petoj—المشكلة كنت تركز على هذا الخادم الثقة الرسائل التي تتلقاها;الاقتراح الخاص بك لا يوفر أي الأمن هناك.ومع ذلك ، إذا كنت قلقا بشأن السرية, لا يزال لديك مشكلة ، لأن MITM يمكن تمرير الرسائل ذهابا وإيابا دون تغيير حتى يرى ما يريد أن يجد لأنك لا تملك أي خصوصية على العميل الرسائل.

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

Answer 5

وسوف نتفق مع جريج أن كنت إعادة اختراع العجلة.ما أنت أساسا تصف بعض الشكل الأساسي تبادل مفتاح.بالمناسبة, من أجل ضمان أن يتم تأمين ضد الرجل في داخل المتوسطة الهجمات يجب أيضا أن تكون على يقين من خادم هوية أيضمان أن العميل يمكن أن نعرف على وجه اليقين أن ما كان يعتقد أن يكون العام(key1) حقا هو الخادم وليس رجل-في-الوسط (مثلا ، باستخدام CA أو وجود الخادم العام(key1) في تخزين آمن على جانب العميل.)

وعلاوة على ذلك ، هناك اعتبارات إضافية يجب أن تكون على علم من أنظمة نظر ، مثل:

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