تشفير الطرف إلى الطرف، شرح حقيقي

ما يعنيه التشفير، حقاً

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

تضيف صفة من الطرف إلى الطرف —بالإنجليزية end-to-end، واختصاراً E2EE— دقة إضافية. لا يتم التشفير لكي يتمكن خادم وسيط من قراءته وتسليمه، بل لكي يمتلك الطرفان فقط —جهاز المرسل وجهاز المستلم— المفتاح. أي خادم تمر عبره الرسالة يرى الضجيج، لا الرسالة. هذا هو الفرق التقني مع التشفير أثناء النقل، حيث ينتقل المحتوى مشفراً من خادم إلى آخر، ولكن كل خادم يمر عبره يقوم بفك تشفيره لإعادة إرساله، مما يستعيد النص الأصلي مؤقتاً.

مفارقة السر المشترك

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

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

أناقة Diffie-Hellman

في عام ١٩٧٦، أثبت عالمان في الرياضيات هما Whitfield Diffie و Martin Hellman شيئاً يبدو مستحيلاً: أن شخصين، يتحدثان فقط عبر قناة عامة —قناة حيث يمكن لأي شخص سماع كل ما يقولانه— يمكنهما الاتفاق على كلمة سر دون أن يتمكن أي مستمع من اكتشافها. يبدو الأمر كالسحر، لكنه ليس كذلك: إنه الرياضيات. تبادل مفاتيح Diffie-Hellman، كما عُرف منذ ذلك الحين، هو الأساس لجميع اتصالات الإنترنت المشفرة تقريباً، ونصف قرن من الاستخدام المكثف والتمحيص الأكاديمي العالمي يؤكد متانته. من يريد رؤية الحدس البصري أو الرياضيات يمكنه مواصلة القراءة. ومن يفضل الثقة في أنه يعمل يمكنه أيضاً المتابعة دون أن يفقد خيط المقال.

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

من Diffie-Hellman إلى بروتوكول Signal

تشفير الطرف إلى الطرف الذي تستخدمه تطبيقات المراسلة المهنية اليوم يعتمد، بلا استثناء تقريباً، على نسخة أنيقة ومعززة من تبادل Diffie-Hellman. بروتوكول Signal، الذي صممه Trevor Perrin و Moxie Marlinspike بين عامي ٢٠١٣ و ٢٠١٦، هو المرجع. يجمع بين فكرتين رئيسيتين. الأولى، تبادل المفاتيح في المنحنيات الإهليلجية (X25519)، التي تنتج السر المشترك الأولي بين جهازين. الثانية، ما يسمى Double Ratchet —الترس المزدوج— الذي يجدد المفاتيح تلقائياً مع كل رسالة، بحيث أن اختراق الجهاز اليوم لا يسمح بفك تشفير الرسائل الماضية، ولا الرسائل المستقبلية بمجرد تدوير الترس.

في Zig، تبادل X25519 الذي ينتج السر المشترك بين جهازين يتسع في ستة أسطر، باستخدام المكتبة القياسية:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

وماذا يوجد بالضبط داخل std.crypto.dh.X25519؟ لا يوجد سحر خفي. هما دالتان قصيرتان يمكن قراءتهما بالكامل في المكتبة القياسية الخاصة بـ Zig. الأولى تشتق المفتاح العام من المفتاح الخاص — الـ «gᵃ» في التبادل:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

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

الدالة الثانية تدمج مفتاحك الخاص مع المفتاح العام الذي يرسله لك الطرف الآخر. إنها الـ «(gᵇ)ᵃ» في التبادل، والتي تنتج السر المشترك المكون من اثنين وثلاثين بايتاً والذي لم ينقله أي منكما:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

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

ما الذي يحميه تشفير الطرف إلى الطرف

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

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

ما لا يحميه تشفير الطرف إلى الطرف

يجدر معرفة ذلك جيداً أيضاً. E2EE لا يحمي الميتاداتا (البيانات الوصفية): لا يزال الخادم يعرف أن المستخدم أ يرسل بيانات للمستخدم ب، في أي ساعة، وبأي تكرار ومن أين، حتى لو كان لا يعرف ماذا يقول. هذه الميتاداتا، كما جادلنا بالفعل في التشفير لا يعني الخصوصية، غالباً ما تكون كاشفة أكثر من المحتوى. معرفة أن شخصاً ما اتصل بمكتب محاماة متخصص في الطلاق يوم الجمعة الساعة ٢٢:٠٠ لمدة ثلاثين دقيقة تحكي قصة لم يحكِها محتوى المكالمة أبداً. إنه نفس الموقف عند رؤية شخص يدخل ويخرج عدة مرات من عيادة أورام: لا حاجة لسماع أي شيء مما يقال في الداخل لتخيل ما يحدث. ميتاداتا واحدة معزولة قد لا تعني شيئاً؛ لكن عدة بيانات متقاطعة فيما بينها ترسم شيئاً قريباً جداً من الحقيقة. E2EE لا يحمي الأطراف: إذا كان جهاز المستلم مخترقاً ببرنامج ضار، فسيتم فك تشفير الرسالة بشكل طبيعي لذلك المستلم ويقوم البرنامج الضار بقراءتها. E2EE لا يحمي من هوية المحاور في حد ذاتها: إذا اعتقدت أليس أنها تتحدث مع برونو لكن مهاجماً تدخل في البداية (هجوم man in the middle) ولم يتضمن البروتوكول تحققاً مستقلاً، سينتهي الأمر بالطرفين بالتحدث مع الدخيل معتقدين أنهما يتحدثان مع بعضهما البعض.

هناك أمر رابع يجدر صياغته دون غموض. E2EE لا يمنع المزود الذي يدعي تقديمه من الاحتفاظ أيضاً بنسخة من الرسالة غير مشفرة في أنظمته الخاصة. الادعاء بأن «رسائلي مشفرة من الطرف إلى الطرف» والادعاء بأن «المزود لا يحتفظ بمحتواي» ليسا نفس الشيء. يمكن لتطبيق أن يلتزم بالأول بينما ينتهك الثاني؛ لقد رأينا هذا في عناوين الصحف بشكل متكرر منذ عام ٢٠١٨. لا يملك المستخدم، ما لم يكن كود العميل قابلاً للتحقق، طريقة تقنية لتمييز حالة عن الأخرى دون تحقيق خبير. الحالة الأكثر شهرة لدى الجمهور العام: يقوم WhatsApp بتشفير الرسائل من الطرف إلى الطرف أثناء النقل، ولكن إذا قام المستخدم بتفعيل النسخ الاحتياطي في iCloud أو Google Drive بدون تشفير إضافي، فسيتم تخزين تلك النسخة قابلة للقراءة في بنية تحتية لطرف ثالث، وينكسر التشفير في طرف المستخدم نفسه.

السؤال الذي لا يريد المشغل سماعه

يمكن للتطبيق الذي يدعي التشفير من الطرف إلى الطرف، من الناحية التقنية، القيام بواحد من ثلاثة أشياء فيما يتعلق بالمفاتيح:

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

لذلك، فإن السؤال العملي ليس ما إذا كان الشيء مشفراً، بل من يملك السيطرة على الجهاز وعلى البرمجيات التي تدير المفاتيح. في Solo2، تقيم المفاتيح فقط في «بوابتك» (IndexedDB مشفرة بكلمة سرك) والبرمجيات هي كود مفتوح المصدر قابل للتحقق.

للقارئ المهني

تشفير الطرف إلى الطرف هو أداة للسيادة الرقمية. ولكن ككل أداة، تعتمد فعاليتها على اليد التي تمسك بها والأرض التي تستند إليها.

1. أين يتم توليد المفاتيح التشفيرية وأين تقيم فيزيائياً؟ إذا كان بإمكان المشغل الوصول إليها (حتى ولو مؤقتاً، أو تحت مسمى الاسترداد)، فإن E2EE هو مجرد اسم.
2. هل يوجد تحقق مستقل من هوية المحاور (أرقام أمان، رموز استجابة سريعة QR، مقارنة خارج القناة) يمنع هجوم رجل في المنتصف أثناء تأسيس المحادثة؟
3. هل كود العميل قابل للتدقيق —مفتوح، منشور، قابل لإعادة الإنتاج— أم يتطلب الثقة في كلمة المزود حول ما يفعله العميل في الواقع؟
4. ما هي الميتاداتا التي يولدها ويحتفظ بها الخدمة، ولكم من الوقت؟ حتى لو كان المحتوى معتماً، يمكن للميتاداتا إعادة بناء جزء كبير من المعلومات الحساسة.

هذه الأسئلة الأربعة لا تطلب معلومات تقنية متقدمة؛ بل تطلب معلومات يمكن لأي مشغل نزيه الإجابة عليها في توثيقه العام. جودة ودقة الإجابة تعبر عن المنتج بقدر الإجابة نفسها.

---

تشفير الطرف إلى الطرف، إذا نُفذ بشكل جيد، يعد واحداً من أروع البناءات التي قدمها علم التشفير المعاصر للممارسة اليومية. الفكرة الأصلية —إمكانية اتفاق شخصين على سر عبر قناة عامة— تعود إلى Whitfield Diffie و Martin Hellman، ١٩٧٦؛ وبعد نصف قرن ما زلنا نعيش في تبعات ذلك. ولكن، كما هو الحال مع أي وعد تقني، فإن قيمته تعتمد على الالتزام الحقيقي، وليس على التسمية. سؤال المهني النزيه ليس «هل هو مشفر؟»، بل «من يملك المفاتيح؟». للإجابات عواقب مختلفة. يجدر بك معرفتها.