08 أغسطس 2025·7 دقيقة
ليونارد أدلمان وRSA: كيف تعلّم الإنترنت أن تثق
ساهم ليونارد أدلمان في إنشاء RSA، نظام المفتاح العام الذي أتاح HTTPS والخدمات المصرفية عبر الإنترنت والتحديثات الموقعة. تعرّف على كيف يعمل ولماذا يهم.
ساهم ليونارد أدلمان في إنشاء RSA، نظام المفتاح العام الذي أتاح HTTPS والخدمات المصرفية عبر الإنترنت والتحديثات الموقعة. تعرّف على كيف يعمل ولماذا يهم.
عندما يقول الناس إنهم “يثقون” بموقع أو خدمة عبر الإنترنت، فعادةً يقصدون ثلاثة أمور عملية:
أصبحت RSA مشهورة لأنها ساعدت على جعل هذه الوعود ممكنة على نطاق الإنترنت.
قد شعرت بتأثير RSA حتى لو لم تسمع الاسم من قبل. يرتبط RSA بشكل وثيق بكيفية:
الخيط المشترك هو الثقة بدون الحاجة لمقابلة شخصية أو ترتيب أسرار سريًا مع كل خادم أو بائع برمجيات تتعامل معه.
يحافظ هذا المقال على الشرح بسيطًا: لا رياضيات معقّدة، ولا حاجة لخلفية علوم الحاسوب. سنركز على وجهة نظر «لماذا تعمل» اليومية.
رَوَّجت RSA لمنهج قوي: بدلاً من سرّ واحد مشترك، تستخدم مفتاحًا عامًا تُشاركُه علنًا ومفتاحًا خاصًا تبقيه سريًا. هذا الانقسام يجعل من الممكن حماية السرية وَإثبات الهوية في مواقف لم يلتقِ فيها الأشخاص أو الأنظمة من قبل.
ليونارد أدلمان هو الحرف "A" في RSA، إلى جانب رون ريفست وآدي شامير. بينما يُنسب لبقية الفريق غالبًا بناء البنية الأساسية، كان لمساهمة أدلمان أهمية بالغة: ساعد في صياغة النظام بحيث لا يكون مجرد فكرة ذكية، بل نظامًا يمكن للناس تحليله، اختباره، والثقة به.
جزء كبير من دور أدلمان كان اختبار الفكرة بصرامة. في التشفير، لا تكون الخطة قيّمة لأنّها تبدو معقولة؛ تكون قيّمة لأنها تصمد أمام هجمات وفحص دقيق. عمل أدلمان على التحقق، صقل الافتراضات، وساهم في التأطير المبكر لسبب صعوبة كسر RSA.
وبقدر أهمية ذلك، ساعد أيضًا في تحويل «ربما تنجح» إلى «هذا نظام تشفير يمكن للآخرين تقييمه». كانت تلك الوضوحية—جعل التصميم قابلاً للفهم بما يكفي ليُفتَح أمام مجتمع البحث—أساسية لاعتماده.
قبل RSA، كانت الاتصالات الآمنة تعتمد عادةً على أن الطرفين يشاركان سرًا. هذا الأسلوب يصلح في مجموعات مغلقة، لكنه لا يتوسع عندما يحتاج الغرباء للتواصل بأمان (مثلاً، متسوق وموقع يلتقيان لأول مرة).
بدّلت RSA تلك القصة من خلال نشر نظام تشفير بالمفتاح العام عملي: يمكنك نشر مفتاح واحد ليستخدمه الآخرون، بينما تحتفظ بمفتاح خاص سري.
أثر RSA أكبر من خوارزمية واحدة. جعل أمرين أساسيين في الإنترنت يبدو عمليًا على نطاق واسع:
تقوم على هذه الأفكار كيف أصبح HTTPS والخدمات المصرفية الموثوقة والتحديثات الموقعة توقعات عادية بدلًا من استثناءات نادرة.
قبل RSA، كان الاتصال الآمن يعني عادةً تشفيرًا بسِرّ مشترك: كلا الطرفين يجب أن يمتلكا نفس المفتاح السري مسبقًا. يعمل هذا لجموع صغيرة، لكنه يفشل سريعًا عند بناء خدمة عامة يستخدمها الملايين.
لو احتاج كل زبون إلى مفتاح سري فريد للتحدث إلى بنك، لوجَب على البنك توليد، تسليم، تخزين، تدوير، وحماية عدد ضخم من الأسرار. الجزء الأصعب ليس الرياضيات—بل التنسيق.
كيف تُسلم المفتاح السري بأمان أصلاً؟ البريد بطيء ومحفوف بالمخاطر. الهاتف عرضة للاعتراض أو الهندسة الاجتماعية. إرساله عبر الإنترنت يهزم الغرض لأن القناة هي بالضبط ما تحاول تأمينه.
تخيّل شخصين لا يعرفان بعضهما—أنت ومتجر إلكتروني. تريد إرسال دفعة بأمان. مع التشفير بالسر المشترك، يلزم مفتاح خاص تعرفانه مسبقًا. لكنكما لا تعرفانه.
اختراق RSA كان تمكين الاتصال الآمن دون مشاركة سرّ مسبقًا. بدلًا من ذلك، يمكنك نشر مفتاح واحد (مفتاح عام) يمكن لأي شخص استخدامه لحماية رسالة موجهة إليك، بينما تحتفظ بمفتاح خاص فقط لك.
حتى لو شُفرت الرسائل، ما زلت بحاجة لمعرفة لمن تشفر. وإلا قد يخدعك مهاجم ويتظاهر بالبنك أو المتجر، ويُقنعك باستخدام مفتاحه، ليقرأ أو يغيّر كل شيء بهدوء.
لهذا يحتاج الاتصال الآمن عبر الإنترنت إلى خاصيتين:
ساعدت RSA في جعل كلا الخاصيتين ممكنتين، ومهّدت الطريق لكيفية عمل الثقة على الإنترنت على نطاق كبير.
فكرة التشفير بالمفتاح العام بسيطة ولكنها ذات نتائج كبيرة: يمكنك قفل شيء ما لشخص ما دون الاتفاق مسبقًا على سرّ مشترك. هذا هو التحول الأساسي الذي ساعدت RSA على جعله عمليًا.
فكّر في المفتاح العام على أنه قفل تُسعد بإعطائه لأي شخص. يمكن للناس استخدامه لحماية رسالة لك—أو (في أنظمة التوقيع) للتحقق من أن شيئًا ما جاء منك.
المفتاح الخاص هو الشيء الوحيد الذي يجب أن تحتفظ به لنفسك. هو المفتاح الذي يفتح ما قُفل بمفتاحك العام، وهو أيضًا ما يسمح لك بإنشاء توقيعات لا يستطيع سواك عملها.
معًا، يشكلان زوج مفتاح؛ مرتبطان رياضيًا لكن غير قابليْن للتبادل. مشاركة المفتاح العام آمنة لأن معرفته لا تمنح طريقة عملية لاشتقاق المفتاح الخاص.
التشفير يتعلق بالسرية. إذا شفر شخص رسالة بمفتاحك العام، فلن يستطيع فكها إلا مفتاحك الخاص.
التواقيع الرقمية تتعلق بالمصداقية والتكامل. إذا وقعت شيئًا بمفتاحك الخاص، يستطيع أيّ حامل لمفتاحك العام التحقق من:
الأمان ليس سحرًا—يعتمد على مشكلات رياضية صعبة يسهل عملها في اتجاه واحد ويصعب عكسها بالحواسيب الحالية. خاصية "اتجاه واحد" هذه هي ما يجعل مشاركة المفتاح العام آمنة بينما يبقى المفتاح الخاص قويًا.
تقوم RSA على عدم تماثل بسيط: من السهل إجراء الحساب "الأمامي" لقفل شيء، ومن الصعب للغاية عكس ذلك لفتح القفل—ما لم تمتلك سرًّا خاصًا.
تخيّل RSA كقفل رياضي؛ يمكن لأي شخص استخدام المفتاح العام لقفل رسالة. لكن الشخص الحامل للمفتاح الخاص فقط يمكنه فتحها.
ما يجعل ذلك ممكنًا هو علاقة مختارة بعناية بين المفتاحين. تُولَد المفاتيح معًا، ومع أنها مرتبطة، لا يمكنك عمليًا اشتقاق الخاص من العام.
بشكل عام، تعتمد RSA على أن ضرب أعداد أولية كبيرة سهل، لكن العودة—تحديد أي أوليات ضُربت—صعبة جدًا عندما تكون الأعداد ضخمة.
للأعداد الصغيرة، التفكيك سريع. لأحجام المفاتيح الحقيقية (آلاف البتات)، أفضل الطرق المعروفة ما زالت تتطلب وقتًا وموارد حوسبة غير عملية. خاصية "الصعوبة في العكس" هذه تحمي الخصوصية من المهاجمين.
غالبًا لا تُستخدم RSA لتشفير ملفات كبيرة مباشرة. بدلاً من ذلك، تحمي عادةً أسرارًا صغيرة—لا سيما مفتاح جلسة عشوائي. ثم يُستخدم مفتاح الجلسة هذا لتشفير البيانات الفعلية بخوارزميات متماثلة أسرع، وهي الأنسب لحركة البيانات الكبيرة.
اشتهرت RSA لأنها تستطيع أداء وظيفتين متعلقتين لكن مختلفتين: التشفير والتواقيع الرقمية. الخلط بينهما مصدر شائع للارتباك.
التشفير يستهدف أساسًا السرية، بينما التواقيع الرقمية تستهدف التكامل + المصداقية.
مع تشفير RSA، يستخدم شخص ما مفتاحك العام لقفل شيء بحيث لا يقدر على فتحه إلا مفتاحك الخاص.
عمليًا، تُستعمل RSA غالبًا لحماية سر صغير—مفتاح جلسة عشوائي—ثم يُستخدم مفتاح الجلسة لتشفير البيانات الكبيرة بكفاءة.
مع توقيعات RSA، تنقلب الاتجاهات: يَستخدم المُرسِل مفتاحه الخاص لصنع توقيع، وأي شخص يملك مفتاحه العام يستطيع التحقق من:
تظهر التواقيع الرقمية في لحظات "الموافقة" اليومية:
التشفير يحفظ الأسرار؛ التواقيع تحفظ الثقة.
القفل في متصفحك مُلخّص لفكرة واحدة: اتصالك بهذا الموقع مُشفّر وعادةً مُصادق عليه. يعني أن أشخاصًا آخرين على الشبكة—مثل شخص على Wi‑Fi عام—لا يستطيعون قراءة أو تغيير ما يرسله متصفحك والموقع لبعضهما.
لا يعني ذلك أن الموقع "آمن" بكلّية. القفل لا يخبرك إذا كان المتجر صادقًا، ولا إذا كان التنزيل يحتوي برمجيات خبيثة، ولا إذا كتبت اسم النطاق الصحيح. كما أنه لا يضمن أن الموقع سيحمي بياناتك بعد وصولها إلى خوادمه.
عندما تزور موقعًا عبر HTTPS، يجري متصفحك والخادم محادثة إعداد تُسمى مصافحة TLS:
تقليديًا، استُخدمت RSA كثيرًا لتبادل مفتاح الجلسة (المتصفح يشفر سرًا بالمفتاح العام للخادم). في إعدادات TLS الحديثة، تُستخدم RSA بشكل أساسي للمصادقة عبر التواقيع (إثبات تحكّم الخادم بالمفتاح الخاص)، بينما يتم الاتفاق على المفاتيح بطرق أخرى.
RSA ممتازة لتأسيس الثقة ولحماية قطع صغيرة من البيانات أثناء الإعداد، لكنها أبطأ مقارنةً بالتشفير المتماثل. بعد المصافحة، يتحول HTTPS إلى خوارزميات متماثلة سريعة لتحميل الصفحات وتسجيلات الدخول والمعاملات البنكية.
الوعد البسيط للخدمات المصرفية الإلكترونية: يجب أن تتمكن من تسجيل الدخول، مراجعة الأرصدة، وتحويل الأموال دون أن يتعلم شخص آخر بيانات اعتمادك—أو يغيّر ما ترسله بصمت.
يجب على جلسة بنكية حماية ثلاثة أشياء معًا:
بدون HTTPS، يمكن لأي شخص على نفس Wi‑Fi، أو راوتر مخترق، أو مشغل شبكة خبيث أن يصغي أو يُعدّل الحركة.
HTTPS (عبر TLS) يؤمن الاتصال بحيث تصبح البيانات المتحركة بين متصفحك والبنك مشفرة ومتحقَّق سلامتها. عمليًا يعني ذلك:
كان لدور RSA التاريخي أهمية لأنه حل مشكلة "الاتصال الأول"—تأسيس جلسة آمنة عبر شبكة غير آمنة.
التشفير وحده لا يكفي إن كنت تشفر إلى الطرف الخطأ. الخدمات المصرفية عبر الإنترنت تعمل فقط إذا أخبرك متصفحك أنك تتحدث مع البنك الحقيقي، وليس موقعًا مُقنّعًا أو وسيطًا في المنتصف.
تضيف البنوك دومًا التحقق متعدد العوامل (MFA)، وفحوص الأجهزة، ومراقبة الاحتيال. تقلل هذه الإجراءات الأضرار عند سرقة بيانات الاعتماد—لكنها لا تغني عن HTTPS. تعمل كشبكات أمان فوق اتصالٍ خاص ومقاوم للتلاعب بالفعل.
توزيع البرمجيات مشكلة ثقة بقدر ما هو مشكلة تقنية. حتى لو كُتبت تطبيقات بعناية، يمكن للمهاجمين استهداف مرحلة التوزيع—استبدال مثبت شرعي بآخر معدّل، أو إدخال تحديث مخترق في المسار بين الناشر والمستخدم. بدون طريقة موثوقة لمصادقة ما حمّلته، قد يصبح "تحديث متاح" نقطة دخول سهلة.
إذا كانت التحديثات محمية فقط برابط تحميل، يمكن لمهاجم يخترق مرآة، أو يخطف اتصال شبكة، أو يخدع المستخدم لزيارة صفحة شبيهة أن يقدم ملفًا مختلفًا بنفس الاسم. قد يثبّت المستخدم الملف بشكل طبيعي، ويكون الضرر "صامتًا": برمجيات خبيثة مضمَّنة في التحديث، أو أبواب خلفية، أو إضعاف إعدادات الأمان.
يستخدم توقيع الشفرات التشفير بالمفتاح العام (بما في ذلك RSA في أنظمة عديدة) لإرفاق توقيع رقمي إلى مثبت أو حزمة تحديث.
يوقّع الناشر البرمجية بمفتاحه الخاص. يتحقق جهازك (أو نظام التشغيل) من هذا التوقيع باستخدام مفتاح الناشر العام—غالبًا ما يُقدَّم عبر سلسلة شهادات. إذا تغيّر أي بايت، تفشل عملية التحقق. يحوّل هذا الثقة من "من أين حمّلته؟" إلى "هل أستطيع التحقق من من أنشأه وأنه سليم؟"
في خطوط تسليم التطبيقات الحديثة، تمتد هذه الأفكار لتشمل نُهجًا أبعد من المثبتات: نداءات API، نتائج البناء، وعمليات النشر. على سبيل المثال، منصات مثل Koder.ai (منصة برمجة تعمل من واجهة دردشة) ما تزال تعتمد على الأسس نفسها: HTTPS/TLS للنقل، وتعامل دقيق مع الشهادات للنطاقات المخصّصة، وإجراءات استرجاع (لقطات ونقاط استعادة) لتقليل المخاطر عند الدفع بالتغييرات.
تقلل التحديثات الموقعة من فرص العبث غير المرصود. يتلقى المستخدمون تحذيرات أوضح عند وجود مشكلة، ويمكن لأنظمة التحديث الأوتوماتيكي رفض الملفات المعدلة قبل تشغيلها. هذا ليس ضمانًا أن البرنامج خالٍ من الأخطاء، لكنه دفاع قوي ضد الانتحال والتلاعب بسلسلة التوريد.
للتعمق في كيفية ترابط التواقيع والشهادات وآليات التحقق، راجع /blog/code-signing-basics.
إذا كانت RSA تمنحك مفتاحًا عامًا، فالسؤال الطبيعي: لمَن ينتمي هذا المفتاح؟
الشهادة هي إجابة الإنترنت: ملف موقع صغير يربط مفتاحًا عامًا بهوية—مثل اسم موقع (example.com)، منظمة، أو ناشر برمجيات. اعتبرها بطاقة هوية للمفتاح: تقول "هذا المفتاح يعود لهذا الاسم"، وتحتوي على معلومات مثل صاحب الشهادة، المفتاح العام نفسه، وتواريخ الصلاحية.
تكتسب الشهادات أهميتها لأنها موقّعة من طرف آخر. يكون الطرف عادةً سلطة شهادات (CA).
الـ CA هي جهة خارجية تتحقّق من إثباتات معينة (قد تتراوح من تحقّق بسيط للسيطرة على النطاق إلى تحقق أعمق عن الكيان) ثم توقّع الشهادة. تحمل المتصفحات وأنظمة التشغيل قائمة CAs موثوقة مسبقًا. عندما تزور موقعًا عبر HTTPS، تستخدم جهازك تلك القائمة لتقرير قبول ادعاء الشهادة.
النظام ليس مثاليًا: قد ترتكب CAs أخطاء، ويمكن للمهاجمين محاولة خداعها أو اختراقها. لكنه يخلق سلسلة ثقة عملية تعمل على نطاق عالمي.
تنتهي صلاحية الشهادات عن عمد. تقلل مدد الصلاحية القصيرة الضرر إذا سُرق مفتاح وتشجع الصيانة المنتظمة.
يمكن أيضًا إبطال الشهادات قبل انتهائها. الإبطال وسيلة لقول "توقف عن الثقة بهذه الشهادة"—مثلاً إذا تسرب المفتاح الخاص أو أُصدرت الشهادة خطأ. يمكن للأجهزة التحقق من حالة الإبطال (بدرجات موثوقية وصرامة متفاوتة)، لذلك لا تزال صيانة المفاتيح أمرًا مهمًا.
احفظ المفتاح الخاص سريًا: خزّنه في مخزن مفاتيح آمن، قيد الوصول، وتجنّب نسخه بين أنظمة إلا عند الضرورة.
دوّر المفاتيح عند الحاجة—بعد حادث أمني، أثناء تحديثات مجدولة، أو حسب سياسة المؤسسة. وتابع تواريخ الانتهاء حتى لا تصبح التجديدات أزمة في اللحظة الأخيرة.
RSA فكرة أساس، لكنها ليست درعًا سحريًا. معظم الاختراقات الواقعية لا تحدث لأن أحدهم "حلّ RSA"—تحدث لأن الأنظمة المحيطة بـ RSA تفشل.
تتكرر بعض الأنماط:
تعتمد سلامة RSA على توليد مفاتيح كبيرة بما يكفي وعشوائية حقيقية. العشوائية الجيدة أساسية: إذا استُخدمت مصادر عشوائية ضعيفة في توليد المفاتيح، قد يمكن للمهاجمين إعادة إنشاء المفاتيح أو تضييق الاحتمالات. كذلك، طول المفتاح مهم لأن التقدّم في الحوسبة والطرق الرياضية يقلّص هامش الأمان للمفاتيح الصغيرة.
عمليات RSA أثقل من البدائل الحديثة، ولهذا تستخدم البروتوكولات RSA بشكل مقتصد—غالبًا للمصادقة أو لتبادل سرّ مؤقت—ثم تتحول إلى تشفير متماثل أسرع للبيانات الفعلية.
الأمن يعمل أفضل كـ دفاع متعدد الطبقات: احمِ المفاتيح الخاصة (ويُفضّل في أجهزة مخصصة)، راقب إصدار الشهادات، طوّر الأنظمة، استخدم مصادقة مقاومة للتصيد، وصمّم لدوَرَة آمنة للمفاتيح. RSA أداة في السلسلة—ليست السلسلة بأكملها.
RSA واحد من أكثر الأدوات التشفيرية دعمًا على الإنترنت. حتى إن لم يفضّل خدمة ما RSA الآن، غالبًا تحتفظ بتوافقية RSA لأنها منتشرة: أجهزة قديمة، أنظمة مؤسسية طويلة الأمد، وبنيات شهادات مبنية عبر سنوات.
يتطور التشفير لأسباب مشابهة لتطور تقنيات الأمان الأخرى:
سترى عادةً بدائل في TLS والتطبيقات الحديثة:
بصراحة: تستطيع RSA القيام بالتشفير والتواقيع، لكن الأنظمة الحديثة غالبًا ما تقسم العمل—تستخدم طريقة مُحسّنة للتواقيع وأخرى مُحسّنة لتأسيس مفاتيح الجلسة.
لا. ما زالت RSA مدعومة على نطاق واسع وتبقى خيارًا صالحًا في سياقات كثيرة، خاصةً حيث تلعب التوافقيّة دورًا أو حيث بنيت ممارسات إدارة المفاتيح وشهادات على RSA. الخيار "الأفضل" يعتمد على دعم الأجهزة، متطلبات الأداء، متطلبات الالتزام، وكيف تُخزن وتُدير المفاتيح.
إذا أردت رؤية كيفية ظهور هذه الخيارات في اتصالات HTTPS الحقيقية، الخطوة التالية: /blog/ssl-tls-explained.
ساعدت RSA في جعل الثقة على نطاق الإنترنت عمليّة من خلال تمكين التشفير بالمفتاح العام، والذي يدعم:
تُعَد هذه اللبنات الأساسية مركزية لـ HTTPS، والخدمات المصرفية عبر الإنترنت، والتحديثات الموقعة للبرمجيات.
ساهم ليونارد أدلمان في تحويل RSA من فكرة ذكية إلى نظام تشفير يمكن للآخرين تحليله والثقة به. عمليًا، شمل ذلك اختبار الافتراضات، وصقل العرض، وتقوية الحُجج حول سبب صعوبة كسر RSA في ظل نماذج هجوم واقعية.
المفتاح العام مُصمم ليُشارك: يستخدمه الآخرون لتشفير رسالة موجهة إليك أو للتحقق من توقيعاتك.
المفتاح الخاص يجب أن يظل سريًا: يُستخدم لفك تشفير ما أُرسل إليك (في سيناريوهات تشفير RSA) ولإنشاء توقيعات لا يستطيع إجراؤها سوى صاحب المفتاح.
إذا تسرب المفتاح الخاص، يمكن للمهاجمين انتحال هويتك أو فك تشفير أسرار محمية اعتمادًا على طريقة استخدام المفتاح.
تعتمد سلامة RSA (بمستوى عالٍ) على مشكلة رياضية أحادية الاتجاه: ضرب أعداد أولية كبيرة سهل، لكن تحليل هذه الأعداد إلى عواملهما الأولية (التفكيك) صعب للغاية عند أحجام المفاتيح الواقعية.
المفتاحان العام والخاص مرتبطان رياضيًا، لكن العلاقة مُصممة بحيث أن رؤية المفتاح العام لا تكشف عن الخاص بوسيلة عملية.
هما يخدمان أهدافًا ثقة مختلفة:
قاعدة عملية: التشفير يحفظ الأسرار؛ والتواقيع تثبت من أرسل شيئًا وما إذا تغيّر بعد توقيعه.
بتبسيط في تدفق HTTPS/TLS:
قد تُستخدم RSA للمصادقة (توقيعات)، وتاريخيًا استُخدمت أيضًا لحماية السرّ الأولي للجلسة في بعض الإعدادات.
لا. رمز القفل يدل أساسًا على أن الاتصال مشفّر وغالبًا مصادق عليه.
لا يضمن القفل أن:
اعتبر HTTPS طبقة أمان نقل ضرورية، لكن ليست حكمًا نهائيًا على الثقة.
الشهادة تربط مفتاحًا عامًا بهوية (مثل اسم نطاق). تتوثّق المتصفحات من هذا الربط لأن شهادةً ما مُوقَّعة من قِبل سلطة شهادات (CA)، وتحتوي الأجهزة والمتصفحات قائمة CAs موثوقة.
عند نشر خدماتك، خطط لـ:
تسمح التحديثات الموقعة لجهازك بالتحقق من أمرين:
هذا يحمي من هجمات «استبدال الحزمة» (مرايا مخترقة، شبكات مخترقة، صفحات تحميل مُشابهة). للمزيد من التفاصيل، راجع /blog/code-signing-basics.
أخطاء العالم الحقيقي عادةً تشغيلية أكثر منها كسرًا رياضيًا لـ RSA:
خطوات عملية: احمِ المفاتيح الخاصة (الأفضل في أجهزة مخصصة)، تابع تواريخ الصلاحية، أدر المفاتيح بصورة منهجية، وراقب إصدار الشهادات حيث أمكن.