تعمية المفتاح المعلن

[[Image:Public key shared secret.svg|thumb|250px|يسار|في نظام تبادل مفاتيح ديفي–هلمان، يقوم كل طرف بإنشاء زوج مفاتيح معلن / خاص وتوزيع المفتاح المعلن. بعد الحصول على نسخة أصلية من المفاتيح المعلنة لبعضهما البعض، يمكن لـ أليس وبوب حساب السر المشترك دون اتصال بالإنترنت. يمكن استخدام السر المشترك، على سبيل المثال، كمفتاح لـ تشفير متناظر.

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

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 كيفية عملها

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

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

نظراً لأن خوارزميات المفاتيح المتناظرة دائماً ما تكون أقل كثافة من الناحية الحسابية، فمن الشائع تبادل مفتاح باستخدام خوارزمية تبادل المفاتيح ونقل البيانات باستخدام هذا المفتاح و خوارزمية المفتاح المتناظر. PGP ، و تقوم مجموعة مجموعة أنظمة SSL /TLS بهذا، على سبيل المثال، وبالتالي تسمى نظام التعمية الهجين.

 الوصف

الفرعين الرئيسية لتعمية المفتاح المعلن هما:

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

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

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

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

 الأمان

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

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

التوقيع الإلكتروني باستخدام المفتاح المعلن يمكن استخدامه للتأكد من شخصية المرسل. في الواقع, يتم حساب قيمة معينة (hash value) للرسالة ويتم تشفيرها باستخدام المفتاح السري مع القيمة المحسوبة (Cryptographic Hash Value).

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

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

 الاعتبارات العلمية

 مماثلة بريدية

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

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

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

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

في نوع آخر من نظام المفاتيح غير المتناظرة ، يمتلك بوب وأليس أقفال منفصلة. أولاً، تضع أليس الرسالة السرية في صندوق، وتغلق الصندوق باستخدام قفل ليس لديها سوى مفتاح. ثم ترسل الصندوق إلى بوب عبر البريد العادي. عندما يتلقى بوب الصندوق، يضيف قفله الخاص إلى الصندوق، ويرسله مرة أخرى إلى أليس. عندما تتلقى أليس الصندوق الذي يحتوي على القفلين، تزيل قفلها وترسله إلى بوب. عندما يتلقى بوب الصندوق بقفله فقط، يمكن لبوب فتح الصندوق بمفتاحه وقراءة الرسالة من أليس. لاحظ أنه في هذا المخطط يكون ترتيب فك التشفير هو نفسه ترتيب التشفير؛ هذا ممكن فقط إذا تم استخدام الشيفرة التبادلية. التشفير التبادلي هو الذي يكون فيه ترتيب فك التعمية والتشفير قابلاً للتبادل، تمامًا كما يكون ترتيب الضرب قابلاً للتبادل؛ على سبيل المثال، A*B*C = A*C*B = C*B*A. يعد استخدام XOR البسيط مع المفاتيح الفردية بمثابة تشفير تبادلي. على سبيل المثال، لنفترض أن E1() and E2() هما تابعي تشفير ولنفترض لـ "M" أن تكون الرسالة، لذلك إذا قامت أليس بتشفيرها باستخدام E1() وأرسلت E1(M) إلى بوب. يقوم بوب بعد ذلك بتشفير الرسالة مرة أخرى كـ E2(E1(M)) وإرسالها إلى أليس. الآن تقوم أليس بفك تشفير E2(E1(M)) باستخدام E1(). ستحصل الآن على E2(M)، مما يعني أنه عندما ترسل هذا مرة أخرى إلى بوب، سيكون قادراً على فك تشفير الرسالة باستخدام E2() ونحصل على "M". على الرغم من عدم تبادل أي من المفاتيح مطلقاً، فقد تكون الرسالة "M" مفتاحاً جيداً، على سبيل المثال، مفتاح أليس المعلن.

يُستخدم هذا پروتوكول ثلاث مرورات عادةً أثناء تبادل المفاتيح.

 الخوارزميات الفعلية - مفتاحان مرتبطان

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

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

 نقاط الضعف

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

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

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

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

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

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 التكلفة الحسابية

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

 اقترات المفتاح المعلن بالهويات

يجب أن يكون الربط بين المفتاح المعلن و "مالكه" صحيحاً، خشية أن تعمل الخوارزمية بشكل مثالي ومع ذلك تكون غير آمنة تماماً في الممارسة العملية. كما هو الحال مع معظم عمليات التعمية، فإن پروتوكول المستخدم لتأسيس هذا الربط والتحقق منه له أهمية بالغة. يتم عادةً ربط مفتاح معلن بمالكه عن طريق پروتوكولات تنفذ البنية الأساسية للمفتاح العام؛ وتسمح هذه بالتحقق من صحة الارتباط رسمياً بالرجوع إلى طرف ثالث موثوق، إما في شكل تسلسل مصدر الشهادات الهرمي (على سبيل المثال، X.509)، نموذج ثقة (على سبيل المثال، SPKI)، أو مخطط شبكة ثقة (على سبيل المثال، تم تضمينه في الأصل في PGP و GPG ولا تزال قابلة للاستخدام معهم إلى حد ما). مهما كان ضمان التعمية للپروتوكولات نفسها، فإن الارتباط بين المفتاح المعلن ومالكه هو في النهاية مسألة حكم ذاتي من جانب الطرف الثالث الموثوق به، لأن المفتاح هو كيان رياضي بينما المالك، والاتصال بين المالك والمفتاح، ليست كذلك. لهذا السبب، يجب أن توفر شكليات البنية التحتية للمفتاح المعلن بيانات صريحة عن السياسات المتبعة عند إصدار هذا الحكم. على سبيل المثال، يسمح معيار X.509 العقدي وغير المطبق بالكامل لمصدر الشهادات بتحديد سياستها عن طريق مطابقة الكائن الذي يعمل كفهرس في كتالوگ للسياسات المسجلة. قد توجد سياسات للعديد من الأغراض المختلفة، بدءاً من إخفاء الهوية إلى التصنيف العسكري.

 علاقاتها بالأحداث العالمية الواقعية

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

 امتياز إلغاء المفتاح

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

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

 توزيع المفتاح الجديد

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

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

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

 نشر الإلغاء

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

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

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

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

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

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

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

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

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

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

 أمثلة

تشمل الأمثلة على تقنيات المفاتيح غير المتناظرة المعروفة جيدًا لأغراض متنوعة:

• پروتوكول تبادل مفاتيح ديفي-هلمان
• DSS (معيار التوقيع الرقمي) ، والذي يتضمن خوارزمية التوقيع الرقمي
• ElGamal
• تقنيات المنحنى الناقصي المختلفة
• تقنيات موافقة مفاتيح مصادقة بكلمة مرور
• نظام تعمية پاييه
• خوارزمية التشفير RSA (PKCS#1)
• نظام تعمية كرامر-شوپ

تتضمن أمثلة الخوارزميات الرئيسية غير المتناظرة غير المعتمدة على نطاق واسع

• نظام تعمية NTRUEncrypt
• نظام تعميةماك‌إليس

تتضمن أمثلة خوارزميات المفاتيح غير المتناظرة الظاهرة وغير الآمنة:

• نظام تعمية مجموعة مركل-هلمان

تتضمن أمثلة الپروتوكولات التي تستخدم خوارزميات المفاتيح غير المتناظرة:

• GPG، تنفيذ OpenPGP
• تبادل مفاتيح الإنترنت
• PGP
• پروتوكول ZRTP، VoIP الآمن
• طبقة المنافذ الآمنة، تم تنفيذه الآن كمعيار IETF TLS
• SILC
• SSH

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

 انظر أيضاً

• كتب عن التعمية
• GNU Privacy Guard
• Identity based encryption (IBE)
• Key-agreement protocol
• خزانة المفاتيح
• PGP word list
• Pretty Good Privacy
• Pseudonymity
• Public key fingerprint
• Public key infrastructure (PKI)
• Quantum cryptography
• Secure Shell
• Secure Sockets Layer
• Threshold cryptosystem

 المصادر

• N. Ferguson (2003). Practical Cryptography. Wiley. ISBN 0-471-22357-3. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
• J. Katz (2007). Introduction to Modern Cryptography. CRC Press. ISBN 1-58488-551-3. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
• A. J. Menezes (1997). Handbook of Applied Cryptography. ISBN 0-8493-8523-7. {{cite book}}: Unknown parameter |coauthors= ignored (|author= suggested) (help)
• IEEE 1363: Standard Specifications for Public-Key Cryptography

 وصلات خارجية

• Oral history interview with Martin Hellman, Charles Babbage Institute, University of Minnesota. Leading cryptography scholar Martin Hellman discusses the circumstances and fundamental insights of his invention of public key cryptography with collaborators Whitfield Diffie and Ralph Merkle at Stanford University in the mid-1970s.
• An account of how GCHQ kept their invention of PKE secret until 1997 (Content can be found at the Internet Archive.)