ايفون:هل هناك أي طريقة آمنة لإنشاء طبقة مقابس آمنة ثنائية الاتجاه (SSL) من أحد التطبيقات

Question

أحتاج إلى إنشاء اتصال HTTPS ثنائي الاتجاه SSL من تطبيق iPhone الخاص بي إلى خادم العميل.ومع ذلك، لا أرى أي طريقة آمنة لتسليم الشهادات من جانب العميل إلى التطبيق (إنه تطبيق مصرفي إلكتروني، لذا يمثل الأمان مشكلة حقيقية).مما وجدته حتى الآن، فإن الطريقة الوحيدة التي يمكن للتطبيق من خلالها الوصول إلى الشهادة هي توفيرها مجمعة مسبقًا مع التطبيق نفسه، أو الكشف عن عنوان URL الذي يمكن جلبه منه (تطبيق IPhone مع شهادات عميل SSL).

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

يجب أن يبدو بروتوكول الأمان بالكامل كما يلي:
- HTTPS 2-way SSL لمصادقة التطبيق
- تسجيل المستخدم المستند إلى OTP (الرمز المميز) (تم إنشاء زوج المفاتيح من جانب العميل في هذه الخطوة)
- SOAP / WSS XML-Signature (الطلبات الموقعة بواسطة المفاتيح التي تم إنشاؤها مسبقًا)

هل لديك أي فكرة عن كيفية إنشاء الطبقة الأولى من الأمان (HTTPS)؟

Answer 1

حسنًا ، للإجابة على سؤالي الخاص ...

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

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

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

سنفكر أيضًا في كيفية حماية بيانات المستخدمين على مستوى أعلى (على سبيل المثال.باستخدام تشفير WSS)، ولكن في البداية أعتقد أننا جيدون في الحل الحالي.

أي رأي؟

يعتبر

Answer 2

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

إذا كنت تستخدم فئات Apples (iPhone) لهذا الغرض ، فسوف يقبلون فقط شهادات "جيدة". من الخير ، أعني ما تعتبره أبل مقبولًا. إذا لم تستخدمها (هناك بدائل في SDK) ، فلن تتمكن 100 ٪ اليقين لأنني لم أنظر بما يكفي في هذا الترخيص للتأكد)

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

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

تعديل

يفحص هذه Post - قد يكون لديك المزيد من المعلومات حول ما تطلبه

/تعديل

EDIT2

يرجى ملاحظة أن الطلب هو iPhone ، وليس OSX - موافقة متجر التطبيقات مشكلة

/edit2