ليس كل خلل كارثة، ولا تحتاج كل حالة جديرة بالعرض إلى اكتشاف صاخب. هذه حكاية خطأ صغير ومحدّد في تطبيق مراسلة مفتوح المصدر؛ وهي، قبل ذلك، حكاية استجابة توضّح كيف ينبغي أن يجري الإفصاح المنسّق.
المفتاح نفسه على كل جهاز
يخزّن SKRED الإعدادات الحساسة مشفّرةً على الجهاز. في الوضع المعتاد، ينشئ مفتاحًا خاصًا بكل جهاز داخل مخزن المفاتيح الآمن في الهاتف (Android Keystore). وإذا تعذّر ذلك ــ وهي مشكلة معروفة في بعض الأجهزة القديمة ــ كان يلجأ إلى مفتاح احتياطي ثابت. هذا المفتاح كان واحدًا في كل عمليات التثبيت.
لماذا وُجد هذا المسار؟ كانت الغاية حماية البيانات حتى عند تعطل Keystore في الجهاز. لكن المفتاح الاحتياطي لم يكن خاصًا بكل جهاز؛ بل كان يُشتق على نحو حتمي من قيمتين ثابتتين في الشيفرة. لذا تطابق في كل مكان، وكان بالإمكان إعادة بنائه من الشيفرة المنشورة.
ماذا يعني ذلك، دون مبالغة؟ كان هذا مسارًا احتياطيًا لا طريقة التشفير المعتادة. وقد تعلّق بإعدادات محفوظة محليًا، لا بمحتوى رسائل جميع المستخدمين. استغلاله يتطلب الوصول إلى الجهاز نفسه، وليس هجومًا عن بُعد. تنحصر خطورة الخلل في حالة محلية مرتبطة بالجهاز: خلل حقيقي، لكن حدوده واضحة.
الآن: توقّف آمن عند الخطأ
المفتاح الاحتياطي لقراءة البيانات القديمة فقط
لم يعد المفتاح الاحتياطي يُستخدم للتشفير في الوضع الحالي. فإذا فشل إنشاء المفتاح في Keystore، يتوقف التطبيق بأمان بدل المتابعة بمفتاح معروف. ولا يبقى المفتاح القديم إلا لفك تشفير البيانات الموجودة مسبقًا أثناء نقلها.
ردّ شخصي، وإصلاح فعلي.
بعد أن أحال BSI البلاغ، ردّ المسؤول التقني في الشركة بنفسه. لم يكن ردًا جاهزًا؛ بل تناول النقاط واحدةً واحدة، مع شرح تقني مفصّل. شارك وثائق إضافية عن بنية التطبيق، وأحال إلى الشيفرة المفتوحة، وبدأ الإصلاحات فورًا. وإلى جانب معالجة المفتاح الاحتياطي، أُضيف تثبيت بصمات الشهادات أيضًا. ويمكن تتبّع هذه التغييرات كلها في مستودع الشيفرة المفتوح.
هكذا ينبغي أن تسير الأمور.
لا تُقاس قيمة الإفصاح المنسّق بحجم الثغرة وحده، بل بما يحدث بعد الإبلاغ عنها. قدّم SKRED مثالًا جيدًا: شيفرة مفتوحة، وشخص يردّ، وتعاون بدل التصلّب، وإصلاحات سريعة يمكن التحقق منها. وانفتاح شيفرة التطبيقات جزء من هذا النهج أيضًا.