fingerprint أداة التحقق من بصمة الملف (Checksum) star

لماذا تنشر جهات توزيع البرمجيات بصمات التحقق (Checksums)

عندما تُنزّل نسخة ISO من لينكس، أو ملفًا تنفيذيًا مفتوح المصدر، أو مثبّتًا موقّعًا، عادةً ما تعرض صفحة التنزيل بصمة تحقق (checksum) بجانب الملف — نصًا قصيرًا مثل a94a8fe5ccb19ba61c4c0873d391e987982fbbd. هذا النص هو ناتج تشغيل دالة تجزئة (hash) تشفيرية على كل بايت من الملف. تغيير بت واحد فقط في أي مكان من الملف يجعل التجزئة مختلفة تمامًا. تنشر الجهات هذه القيمة حتى تتمكن، بعد تنزيل الملف، من تشغيل دالة التجزئة نفسها بنفسك ومقارنة نتيجتك بما نشروه. إذا تطابق النصان تمامًا، يمكنك أن تثق بأن النسخة الموجودة على قرصك تحتوي بالضبط على نفس البايتات التي بناها المُوزِّع ورفعها — لا شيء أُضيف، ولا شيء نقص، ولا شيء تغيّر.

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

بصمات التحقق ليست تشفيرًا

يستحق الأمر التوضيح بدقة لما تتحقق منه بصمة التحقق فعليًا، لأن المصطلحات كثيرًا ما تُخلط. التجزئة (hashing) عملية أحادية الاتجاه لا يمكن عكسها: يحوّل SHA-256 ملفًا إلى نص سداسي عشري ثابت الطول من 64 حرفًا، لكن لا توجد عملية تعيد ذلك النص إلى الملف. هذا وحده يُظهر أن الأمر ليس تشفيرًا — فالتشفير مصمَّم ليكون قابلًا للعكس بالمفتاح الصحيح، بينما التجزئة مصمَّمة لتكون غير قابلة للعكس على الإطلاق. تتحقق بصمة التحقق من السلامة، لا من السرّية: فهي تؤكد أن البايتات التي لديك هي نفسها البايتات التي جُزّئت. أي شخص يملك حق الوصول إلى الملف لا يزال بإمكانه قراءة كل بايت منه بوضوح تام؛ فالتجزئة لا تُخفي المحتوى إطلاقًا. ما تضمنه هو أنه إذا تغيّر بايت واحد فقط — عمدًا أو عرضًا — فإن التجزئة التي تحسبها لن تعود مطابقة للتجزئة المنشورة، وستعرف فورًا أن هناك شيئًا مختلفًا.

هذا التمييز مهم أيضًا في اختيار الخوارزمية. اعتُبر SHA-1 مكسورًا رسميًا من الناحية التشفيرية الأمنية عام 2017، عندما نشر باحثون من Google وCWI أمستردام هجوم "SHAttered": ملفا PDF مختلفان صُمِّما لإنتاج نفس بصمة SHA-1، مما أثبت أن مهاجمًا مصمَّمًا بما يكفي يمكنه بناء ملف خبيث يشارك بصمة تحقق مع ملف شرعي. أدت هذه النتيجة إلى إحالة SHA-1 إلى التقاعد في كل ما هو حرج أمنيًا — شهادات TLS، التوقيعات الرقمية، الدفاع ضد جهة معادية تصمّم تصادمًا (collision) عمدًا. لكن بالنسبة للحالة الأكثر شيوعًا بكثير التي تعالجها هذه الأداة — التأكد من أن تنزيلًا لم يتلف بسبب اتصال غير مستقر — لا يزال SHA-1 يعمل جيدًا عمليًا، لأن لا أحد يصمّم تنزيلك التالف تحديدًا ليطابق تجزئة مستهدفة؛ فالتلف العرضي هو انقلاب عشوائي للبتات، لا بناء تصادم مقصود. مع ذلك، عندما يتيح الناشر الخيار، لا يكلّف SHA-256 شيئًا إضافيًا للحساب ويغلق الفجوة تمامًا، لذا فهو الخيار الافتراضي الأكثر أمانًا.