استخدام التشفير ضمن البروتوكولات (2) Using Encryption In Protocols

[color:c85c=red]المفتاح التقليدي للتوقيعات الرقمية :
Conventional key Digital Signatures[/color]

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

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


ليكن (S) هو المرسل و (A) هو الحكم و(R ) هو المستقبل [ البنك ٍ] المرسل يملك المفتاح (KS) بالاشتراك مع الحكم والبنك يملك مفتاح (KS) بالاشتراك مع الحكم ، لنفترض بأن S و R اتفقا مسبقاً على صيغة للتوقيع الرقمي . S يريد أن يبعث رسالة (M) إلى (R ) مع المتطلبات الإضافية التي تجعل الرسالة غير قابلة للتزوير وقابلة للتحقق من وثوقيتها .
في البداية يرسل (S) E(M, KS) إلى الحكم (A) يقوم الحكم بفك تشفير الرسالة (M) مستخدماً (KS) بعد التحقق أن الرسالة مرسلة من قبل (S) فإن الحكم يرسل
E((M, S, E(M, KS)), KR) إلى R و R يستقبل الرسالة (M) المشفرة بالمفتاح (KR) لذلك فإن R يستطيع فك تشفير الرسالة واستخدامها ويستقبل (R ) كذلك E(M, KS) والتي لا يستطيع R فك تشفيرها بما أنها مشفرة بواسطة المفتاح (KS ) ، إن (R ) يحفظ في إضبارة نسخة من الرسالة (M) و E(M,KS) في حال حدوث خلاف مستقبلي .
لقد تم شرط التوثيق حالما وثق المستقبل بأن الحكم الذي قال أن الرسالة قد وصلت من المرسل .
إن الملكية التابعة لـ (R ) غير المزورة أصبحت مؤكدة ، لأنه إذا ادعى (S) لاحقاً وجود تزوير فإن (R ) يبرز كلاً من (M) و E(M,KS) .
يستطيع الحكم إعادة تشفير الرسالة (M) مستخدماً المفتاح (KS) وأن يؤكد أن (S) فقط هو الذي يستطيع إنتاج E(M, KS) لذلك فإن الحكم يستطيع أن يشهد بأن (S) هو من أوصل الرسالة (M) .
[color:c85c=red]التوقيعات الرقمية دون استخدام التشفير :
Digital Signatures Without Encryption[/color]

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

لنفرض أن كل من (S) و (R) قد سجل تابع ضمان شخصي مع الحكم يرمز لهما على الترتيب FS) و (FR ثم يرسل (S) رسالة (M) و FS(M) من نسخة (M) المرسلة من (S) إن تطابقت قيمتا FS(M)المحسوبة والمرسلة فإن الرسالة يفترض بأنها موثقة من قبل (S) ثم (A) يرسل (M) و (S) و FS(M) لكن يبقى (R) هذا كدليل بأن (S) أرسل الرسالة الأصلية ، يتحقق (R) من صحة FR(M) لكي يعلم بوثوقية الرسالة .
[color:c85c=red]منع إعادة الاستعمال أو التعديل: Preventing Reuse or Altering[/color]

كلا الحلين السابقين يحققان متطلبات الوثوقية وعدم التزوير لذلك فهما بروتوكولات توقيع رقمي مقبولة .
بالإضافة إلى أننا نريد أن نمنع إعادة الاستعمال أو تعديل رسالة قديمة بالرغم من أن (R ) لا يستطيع خلق رسائل جديدة بواسطة المفتاح (KS) أو التابع (FS) ولكنه المستقبل يستطيع إعادة استعمال رسالة قديمة فمثلاً المستقبل يستطيع أن يحفظ طلب دفع قديم لشخص ويفعله كل شهر وأكثر من ذلك بمعرفة تقنية التشفير دون مفتاح التشفير سيكون المستقبل قادراً على اقتطاع أجزاء من رسائل قديمة ولصقها مع بعضها البعض لتشكيل رسالة جديدة .
إن الشيك الورقي يحل هذه المشكلة حيث يلغي البنك الشيك ويعيده إلى المرسل لذلك فإن المرسل يعلم بأنه لا يمكن إعادة استخدامه مرة أخرى. لذلك نحتاج إلى طريقة لخلق توقيع كمبيوتر مشابه ذو تدمير ذاتي لا يمكن إعادة استخدامه .
نصنع جزء من التوقيع على شكل طابع زمني Time Stamp ، فمثلاً إذا كان رسالة المرسل تظهر وقت وتاريخ الإرسال عندها البنك لا يستطيع إعادة استخدام الرسالة نفسها بعد أسبوع دون أن يكشف المرسل التزوير .
يجب ألا يكون في الطابع الزمني الوقت والتاريخ بشكل حرفي أي ترميزي أي أن سلسلة أرقام متزايدة سوف تفي بالغرض ، هذه الطريقة تحل مشكلة إعادة الاستعمال .
لمنع تقسيم الرسالة إلى أجزاء وإعادة استخدام جزء منها يستطيع المرسل جعل كل جزء منها يعتمد على الطابع الزمني فمثلاً في خوارزمية (DES) التي تشفر مجموعات دخل ذات (64) بت بمجموعات ذات (64) بت فإن المرسل يستطيع تشفير التاريخ والوقت في أول (8) بت من كل مجموعة تاركاً الـ (56) بت من كل مجموعة للرسالة .
بما أن (64) بت من مجموعة خرج الـ DES تعتمد على الـ (64) بت من مجموعة الدخل فإن البنك لايستطيع دمج الـ (56) بت من المجموعة مع (8) بت لطابع زمني مختلف .
إن طريقة سلسلة المجموعة المشفرة من (DES) هي طريقة أخرى لمنع إعادة استخدام مجموعة من رسالة واحدة برسالة أخرى .

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


مع تحياتي
Dr.Houssam

يتبع