نوضّح خدمة السحابة الإلكترونية التي تستخدم أجهزة آمنة لتخزين مفاتيح التشفير، بحيث يتم حماية الوصول إليها من خلال عامل معرفة منخفضة الانتروبي (مثل رقم التعريف الشخصي لشاشة القفل). تم تصميم الجهاز الآمن لمنع هجمات القوة الغاشمة، وذلك من خلال جعل مفاتيح التشفير المُخزَّنة غير قابلة للاسترداد نهائيًا بعد إجراء عدد كبير جدًا من المحاولات غير الناجحة لتقديم عامل المعرفة الصحيح.
المؤلف: شابسي والفيشم
تاريخ الإصدار: 06-03-2018
ملاحظة: لا يزال هذا المستند قيد التطوير، ولا تزال تفاصيل التنفيذ قيد المراجعة. مع استقرار النظام وإمكانية إنشاء المزيد من المستندات، سنعدّل هذا المستند الفني لتقديم معلومات أكثر تفصيلاً (خاصةً مع الإصدارات ذات الصلة للبرامج المفتوحة المصدر).
نظرة عامة
يتطلّب التشفير (الذي يُستخدَم لضمان خصوصية البيانات) بشكلٍ عام استخدام أسرار تتسم بدرجة عالية من الالتباس من وجهة نظر المهاجم. يجب أن تكون درجة التشويش عالية لأنّه يجب أن يقاوم أسلوب التشفير هجمات القوة الغاشمة التي تستكشف مساحة جميع الأسرار المحتملة إلى أن يتم العثور على السر الصحيح. نظرًا لتوفّر الطاقة الحسابية اليوم، قد يكون الحد الأدنى المعقول لمتطلبات التشويش في الأسرار التشفيرية في حدود 70 إلى 80 بت. يجد البشر صعوبة كبيرة في حفظ كلمات المرور أو الأسرار الأخرى التي تتضمّن هذا القدر من العشوائية1 وتذكُّرها بشكل موثوق، خاصةً إذا كانت هذه الكلمات نادرًا ما يتم استخدامها (ولكن استخدام كلمة مرور تتضمّن قدرًا عالٍ من العشوائية بشكل متكرّر هو أمر صعب وممل). يتركنا ذلك أمام مشكلة صعبة: كيف يمكننا حماية البيانات الخاصة باستخدام تكنولوجيا التشفير، إذا أردنا أن يكون السر هو "عامل معرفة" من المرجّح أن يتذكره المستخدم؟ لأسباب متنوعة، من الصعب حلّ هذه المشكلة، لذا لا تُشفِّر خدمات التخزين في السحابة الإلكترونية البيانات عادةً إلا باستخدام الأسرار التي يديرها مقدّم خدمة التخزين في السحابة الإلكترونية نفسه، بدلاً من الاعتماد على المستخدم لتذكر سرّه الخاص.
من بين الطرق التي يمكن من خلالها سد الفجوة بين متطلبات الأسرار التشفيرية والأسرار السهلة التذكر للمستخدمين هي استخدام خدمة Cloud Key Vault (CKV) لتخزين "مفتاح استرداد" ذو كثافة معلومات عالية، محمي بسِر سهل التذكر للمستخدمين ذو كثافة معلومات منخفضة. لن تُطلق خدمة CKV مفتاح الاسترداد إلا لجهة تثبت معرفتها بسرية التذكرة الصحيحة. يمكن أن تتصدّى خدمة CKV للهجمات القائمة على التخمين الوحشي ضد السر السهل التذكر الذي يُستخدم مفتاح الاسترداد نفسه هو مفتاح تشفير متماثل قياسي ومناسب للاستخدام مع مخطّط تشفير (موثَّق) يمكنه بسهولة تشفير كمية كبيرة من البيانات (مثل نسخة احتياطية على القرص) التي يمكن تخزينها بأمان في أي مكان. إنّ هذه البيانات المشفَّرة غير مفيدة لأي شخص لا يمكنه الحصول على مفتاح الاسترداد.
يصف هذا المستند التعريفي منهجنا لإنشاء خدمة Cloud Key Vault باستخدام وحدات الأجهزة الموثوق بها (THM). تم تصميم عملية التنفيذ الأولى لخدمة CKV لحماية مفاتيح الاسترداد باستخدام عامل معرفة قفل الشاشة (LSKF) الخاص بالمستخدم، وهو رقم التعريف الشخصي السري أو كلمة المرور أو النقش المستخدَم لفتح قفل الهواتف الذكية. يمكن للبشر تذكُّر مفتاح LSKF بشكلٍ موثوق. وفي الوقت نفسه، تحتوي أسرار مفتاح التشفير العمودي (LSKF) هذه عادةً على قدر كافٍ من التشويش لمقاومة مهاجمٍ لديه عدد محدود جدًا من المحاولات، ما يجعلها مناسبة لخدمة CKV.
سيكون أول تطبيق لخدمة Cloud Key Vault هو تفعيل ميزة "التشفير من جهة العميل" في ملفاتك الاحتياطية على Android. في السابق، كانت الملفات المشفَّرة على جهاز Android تستخدم مفتاحًا محميًا بمفتاح LSKF الخاص بالمستخدم، ولكن لم تكن النُسخ الاحتياطية من هذه الملفات المخزَّنة (والمشفَّرة) في السحابة الإلكترونية محمية بمفتاح LSKF. وللمرة الأولى، تتيح خدمة Cloud Key Vault حماية شاشة القفل للنُسخ الاحتياطية من بيانات Android المخزّنة في السحابة الإلكترونية أيضًا. وهذا يعني أنّ خوادم Google ليس لديها إمكانية الوصول إلى محتوى النُسخ الاحتياطية المشفَّرة أو استعادتها، ولا يمكن لأحد فك ترميز النُسخ الاحتياطية إلّا من خلال جهاز لديه مفتاح LSKF الخاص بالمستخدم.
المفاهيم الأساسية
في البداية، كانت منصة العميل الوحيدة المتوافقة مع خدمة Cloud Key Vault هي نظام التشغيل Android 9 Pie . وعندما نشير إلى العميل في هذه الورقة البيضاء، نشير إلى جهاز يعمل بنظام التشغيل Android 9 Pie مع "خدمات Google Play". يتم تنفيذ 2 على خوادم Google المخصّصة التي تم تركيب شريحة Titan2 إضافية فيها. تشكل شريحة Titan المصمّمة من Google مكوّنًا للأجهزة في "وحدة الأجهزة الموثوق بها"، ونحن ننظّمها خصيصًا باستخدام أداة تحميل مخصّصة وبرامج ثابتة تنفّذ بروتوكولاتنا وآليات فرض الأمان (كما هو موضّح هنا). نستخدم تقنيات إثبات ملكية الأجهزة في order to gain assurances that our protocol is really running on the Titan hardware.
يجب أن تكون خدمة CKV قابلة للتوسّع لتلبية الزيارات من مليارات3 أجهزة Android، بدون فقدان أيّ قدر كبير من بيانات المستخدمين بسبب أعطال الأجهزة (مثل الرقائق المحترقة) أو حدوث أيّ انقطاعات طويلة بسبب صيانة مركز البيانات. لهذا السبب، يتم تنظيم الخوادم التي تتضمّن شرائح Titan في مجموعات نموذجية تتألف كل مجموعة منها من عدة مجموعات نموذجية مستقلة تتضمّن كل مجموعة منها نسخة من مادة المفتاح نفسها. سيتم توزيع مجموعة نموذجية معيّنة على مراكز بيانات مختلفة جغرافيًا في مناطق صيانة مختلفة، وذلك لضمان أن يتمكن النظام من تحقيق أهداف مدى التوفّر والموثوقية. ولزيادة إمكانية التوسّع، سيتم تقسيم العملاء إلى عدد من المجموعات النموذجية المختلفة، حتى نتمكّن من تعديل سعة الخدمة من خلال إضافة المزيد من الخوادم لزيادة عدد المجموعات النموذجية المتاحة.
نحن الآن جاهزون لتعداد المكونات الرئيسية لبنية خدمة Cloud Key Vault.
المكونات المعمارية / المسرد
عامل معلومات قفل الشاشة (LSKF): سر يمكن للمستخدم تذكره، مثل رقم تعريف شخصي قصير أو نقش تمرير سريع على شبكة من النقاط 3 × 3 أو كلمة مرور. يُستخدَم هذا السر لحماية إمكانية فتح قفل الجهاز على الجهاز، ويعتبر عامل مصادقة أساسيًا (أو "قويًا") لقفل شاشة الجهاز على الجهاز.
العميل: جهاز مستخدم نهائي يعمل بنظام التشغيل Android 9 Pie و "خدمات Google Play" أو برنامج متوافق مكافئ
-
إطار عمل Android: نستخدم هذا المصطلح العام (أو الإطار فقط) للإشارة إلى واجهات برمجة التطبيقات في الإصدار 9 من نظام التشغيل Android أو الإصدارات الأحدث، وليس المقصود به الإشارة إلى أي إصدارات سابقة.
خدمات Google Play: هي مجموعة من الخدمات والتطبيقات التي تعمل على جهاز المستخدم النهائي، ما يتيح له العمل مع نظام حسابات Google وواجهات برمجة التطبيقات الخاصة بالخادم المخصّص.
Recovery Agent: تطبيق نظام يعمل كجزء من خدمات Google Play في مساحة المستخدم على جهاز Android 9 Pie (أو ما شابه). يتحمّل "مسؤول الاسترداد" مسؤولية تنفيذ بروتوكولات مختلفة من جهة العميل والتفاعل مع نظام التشغيل Android حسب الحاجة لإنشاء أي رسائل بروتوكول تتضمن "مفتاح استرداد الجهاز".
طلب استرداد المفتاح: عندما يريد المستخدم استرداد مفتاح الاسترداد، عليه إنشاء طلب استرداد يحتوي على نسخة مشفّرة من مفتاح LSKF الذي يدّعي المستخدم معرفته. سيُطلب عادةً من المستخدم إدخال مفتاح LSKF الخاص بجهازه القديم على جهاز جديد يحاول الوصول إلى مفتاح الاسترداد الخاص بالجهاز القديم.
مفتاح الاسترداد: مفتاح سري مشفّر محمي من خلال خدمة Key Vault في السحابة الإلكترونية، ويُستخدَم لتشفير البيانات (ومصادقتها) على جهاز العميل. بعد وضع "مفتاح الاسترداد" في "مخزن آمن" (راجِع المعلومات أدناه)، يمكن حذف النسخة المحلية بعد انتهاء "العميل" من استخدامه لتشفير البيانات.
خدمة Cloud Key Vault (CKV): خدمة على الإنترنت تتيح لأجهزة العميل تخزين مفاتيح التشفير المحمية بمفتاح تشفير مفتاح الجلسة (LSKF) سهل التذكر.
-
مجموعة نموذجية: هي مجموعة من خوادم Vault أو وحدات تخزين THM التي يمكنها أن تعمل كنسخ احتياطية بعضها من بعض.
مفتاح المجموعة النموذجية العام: المفتاح العام من زوج مفاتيح تم إنشاؤه من مجموعة نموذجية محدّدة من THM. لا يتوفّر المفتاح الخاص المقابل إلا داخل نماذج THM التي كانت في المجموعة النموذجية في وقت إنشاء المفتاح.
وحدة الأجهزة الموثوق بها (THM): هي وحدة أمان مخصّصة (وحدة تحكّم دقيقة) مصمّمة لتوفير بيئة حوسبة بسيطة وموثوقة. على الأقل، يجب أن يكون العنصر الآمن قادرًا على إنشاء و/أو تخزين المفاتيح السرية، والحفاظ على بعض الحالات المتغيّرة غير القابلة للفقدان (كي يتمكّن من منع الهجمات التي تنطوي على إعادة الضبط إلى حالة سابقة).
Vault: إدخال معيّن في قاعدة بيانات خدمة CKV، يحتوي على مفتاح استرداد محمي بتنسيق LSKF لجهاز واحد. قد يكون لدى المستخدم النهائي عدة خزائن ملفات، يرتبط كل منها بجهاز أو مفتاح تشفير مفتاح أساسي مختلف. لا يمكن إلا لـ THM في خادم Vault فحص محتويات Vault أو استخراجها.
خادم Vault: جهاز مخصّص للأغراض العامة يعمل في أحد ملفّات Google البيانات التي تم إعادة تجهيزها خصيصًا لإضافة وحدة الأجهزة الموثوق بها (THM).
تصميم البروتوكول
يتألّف بروتوكول CKV من عدة مراحل، على النحو التالي:
الإعداد
لبدء تشغيل النظام، ستوفّر Google مفتاحًا عامًا لـ "جذر الثقة" الذي سيستخدمه إطار العمل للتحقّق من بيانات اعتماد أجهزة Google. يتم تخزين مفتاح التوقيع الخاص بجذر الثقة هذا بلا إنترنت وتأمينه بعناية بحيث يتطلّب مشاركة عدة موظفين من أجل التوقيع به. إنّ المفتاح العام لجذر الثقة هذا مضمّن في نظام التشغيل Android، ولا يمكن تغييره إلا من خلال تحديث نظام التشغيل.
تنشر Google أيضًا بشكل دوري قائمة بالمفاتيح العامة لكل مجموعة نموذجية من نماذج THM، بالإضافة إلى شهادة اعتماد في القائمة. تستخدم شهادة الاعتماد المدرَجة في القائمة توقيعًا يعود إلى قاعدة الاعتماد. يحتوي كل تعديل على القائمة المنشورة أيضًا على رقم تسلسلي، ما يتيح منع عمليات التراجع. سيسترجع "مسؤول الاسترداد" أحدث قائمة منشورة للمفاتيح العامة للمجموعات النموذجية ويقدّمها إلى "الإطار العام". بعد ذلك، يتحقّق إطار العمل من شهادة الاعتماد ويختار بشكل عشوائي مفتاحًا عامًا لمجموعة نموذجية من القائمة لاستخدامه في مرحلة إنشاء الخزينة.
إنشاء Vault
بعد مساعدة Framework على إكمال عملية الإعداد من خلال جلب قائمة مفاتيح Cohort Public، سيطلب Recovery Agent من Framework إنشاء Vault جديد. عندما يُدخل المستخدم مفتاح LSKF في المرة التالية، سينشئ "الإطار العام" مفتاح استرداد جديدًا ويشفّره أولاً باستخدام مفتاح مشتق من تجزئة مفتاح LSKF، ثم باستخدام مفتاح المجموعة النموذجية العام الذي يختاره "الإطار العام" أثناء الإعداد. الكتلة المشفّرة الناتجة هي Vault التي يتم تمريرها مرة أخرى من خلال Framework إلى "مسؤول الاسترداد"، الذي يحمّلها بعد ذلك إلى خدمة CKV من Google.
فتح الخزانة
عندما يحتاج مسؤول الاسترداد على الجهاز الجديد إلى الوصول إلى مفتاح الاسترداد المخزَّن في وحدة تخزين آمنة معيّنة، سيُطلَب منه أولاً إدخال مفتاح LSKF للجهاز الأصلي الذي أنشأ وحدة التخزين الآمنة. سيطلب موظّف الاسترداد بعد ذلك من "الإطار" إنشاء مطالبة باسترداد باستخدام مفتاح LSKF هذا. سينشئ "إطار العمل" مفتاحًا جديدًا للمطالب، ويشفّر هذا المفتاح بالإضافة إلى تجزئة مفتاح LSKF الذي تمّت المطالبة به، باستخدام مفتاح المجموعة النموذجية العام نفسه الذي تمّ تشفير المخزن به في الأصل. يُطلق على ملف البيانات المشفّر الذي تم إنشاؤه اسم طلب الاسترداد، ويُرسِله إطار العمل إلى وكيل الاسترداد الذي يعرضه بعد ذلك لخدمة CKV.
يوجّه CKV Recovery Claim (وVault المرتبط به) إلى خوادم Vault التي تشكّل جزءًا من المجموعة النموذجية الصحيحة. بعد ذلك، يفكّ THM في خوادم Vault تشفير طلب الاسترداد ويحاول استخراج مفتاح الاسترداد من الحاويات الأصلية باستخدام تجزئة LSKF التي تمّت المطالبة بها (لاستخراج مفتاح التشفير الداخلي). إذا كانت التجزئة الأصلية لمفتاح LSKF تتطابق مع التجزئة المُدّعاة لمفتاح LSKF، ستستخرج أداة THM مفتاح الاسترداد من "الخزينة" وستعيد تشفيره باستخدام مفتاح المدّعي الذي كان مضمّنًا في طلب استرداد. وإذا لم يكن الأمر كذلك، سيزيد THM من عدد المحاولات غير الناجحة. بعد أن يصل عدد المحاولات غير الناجحة إلى الحد الأقصى، سيرفض فريق إدارة الطلبات (THM) معالجة أي مطالبات لاسترداد المستودع التالية.
أخيرًا، إذا سارت الأمور على ما يرام، يتم إعادة إرسال مفتاح الاسترداد المشفَّر (الذي تم تشفيره الآن باستخدام مفتاح المدّعي) من خادم Vault إلى Framework. يستخدم "الإطار العام" نسخته من مفتاح المدّعي لفك تشفير مفتاح الاسترداد، ويكمل البروتوكول الآن.
إجراءات الأمان
يهدف نظام Cloud Key Vault إلى توفير "دفاع في العمق" من خلال تضمين وسائل حماية أمان على مستويات متعدّدة من حِزمنا. لإعطائك فكرة عن آلية عمل هذه التدابير الوقائية، سنبدأ بوصف العميل وننتقل تدريجيًا إلى أعلى الحزمة إلى خدمة Cloud Key Vault.
أمان العميل
استنادًا إلى المصنّع الأصلي للجهاز والجهاز المحدّد، يتم عادةً تخزين عامل معلومات شاشة القفل (LSKF) وحمايته على الجهاز باستخدام مجموعة متنوعة من الطرق التي تختلف حسب المصنّع الأصلي للجهاز. على سبيل المثال، تستخدم أجهزة Pixel 2 من Google وحدة أمان أجهزة مقاومة للتلاعب بهدف تخزين مفتاح LSKF في وضع السكون، وفرض حدود معدّل استنادًا إلى الأجهزة على عملية التحقّق من مفتاح LSKF. تم تصميم واجهات برمجة التطبيقات الجديدة في إطار العمل التي يتم طرحها لتفعيل استخدام "مفتاح الصندوق السحابي" بهدف الحفاظ على ضمانات الأمان الحالية إلى أقصى حد ممكن، حتى عندما يستخدم الجهاز وحدة أمان أجهزة مماثلة لحماية تخزين مفتاح LSKF.
سنركّز في هذا القسم على المشاكل الأمنية والإجراءات الوقائية ذات الصلة التي تؤثر في ميزة Cloud Key Vault الجديدة، بدلاً من محاولة تقديم صورة كاملة عن جميع آليات الأمان المرتبطة بـ LSKF.
تأمين واجهات برمجة تطبيقات Framework
تم وضع علامة على واجهات برمجة التطبيقات الجديدة لإطار العمل التي تمت إضافتها لتتوافق مع خدمة CKV على أنّها @SystemApi وتطلب حصولها على أذونات خاصة، ما يضمن عدم توفّرها إلا لتطبيقات النظام التي يوافق عليها المصنّع الأصلي للجهاز، مثل "خدمات Google Play". ويؤدي ذلك إلى إزالة أي سطح هجوم مباشر قد يكون متوفّرًا للتطبيقات التي يثبّتها المستخدم على الجهاز.
تضمن واجهات برمجة التطبيقات في Framework أيضًا عدم إنشاء خزائن إلا للمفاتيح العامة للمجموعات النموذجية التي تم إثبات صحتها من خلال مرجع ثقة. يُدمج المُصنّع الأصلي للجهاز جذر الثقة في إطار العمل عند شحنه، ولا يمكن تغييره بدون تحديث نظام التشغيل. يضمن ذلك أنّه لا يتم استخدام مفتاح LSKF إلا لإنشاء خزائن ستفرض بشكل صحيح وسائل الحماية المستندة إلى الأجهزة من هجمات القوة الغاشمة. من خلال الاعتماد على نموذج THM في خدمة Cloud Key Vault لحماية LSKF من هجمات القوة الغاشمة، يمكننا تحقيق مستوى أمان مماثل لاستخدام الأجهزة الآمنة على الجهاز للقيام بالشيء نفسه (كما تفعل أجهزة Google Pixel 2).
بما أنّنا لا نفترض أنّه سيتم تخزين مفتاح LSKF في أي مكان على الجهاز خارج الأجهزة الآمنة، لا يمكن إنشاء ملف Vault جديد إلا بعد فتح قفل الجهاز مباشرةً. في الوقت الذي يُدخِل فيه المستخدِم مفتاح LSKF لفتح قفل الجهاز، يتم إتاحة مفتاح LSKF لفترة وجيزة للإطار العمل في ذاكرة الوصول العشوائي. وهذه هي اللحظة التي تستخدم فيها واجهة برمجة التطبيقات الجديدة لإنشاء Vault هذا المفتاح. لا يمكن إنشاء "ملف آمن" جديد محمي بـ "مفتاح تشفير الجهاز" عندما يكون الجهاز مقفلاً، لأنّ "مفتاح تشفير الجهاز" ليس متاحًا.
تأمين وكيل الاسترداد
إنّ الحماية الأمنية الأساسية التي نقدّمها لمسؤول الاسترداد هي أنّه تم تصميم البروتوكول لمنع مسؤول الاسترداد من الاطّلاع على مفتاح LSKF للجهاز الحالي أو أي مفاتيح استرداد. من المفترض أن يعرِض إطار العمل هذه العناصر فقط من جهة العميل، ما يجعل من الصعب جدًا استغلال أي أخطاء محتملة أو ثغرات أمنية في "وكيل الاسترداد". يُستخدَم "وكيل الاسترداد" في الغالب لإدارة أحداث دورة الحياة ونقل البيانات ذهابًا وإيابًا بين السحابة الإلكترونية والإطار. ويحدث الاستثناء الوحيد لهذا أثناء عملية الاسترداد قبل بدء ملف تعريف الارتباط لفتح ملف البيانات، عندما يجب على المستخدم إدخال مفتاح LSKF للجهاز القديم. ويتم تنفيذ واجهة المستخدم التي تجمع مفتاح LSKF الذي تمّت المطالبة به للجهاز القديم في "وكيل الاسترداد"4. ومع ذلك، فإنّ عملية تنفيذ "وكيل الاسترداد" "تُنسى" ملف LSKF الذي تمّت المطالبة به فور تولي "الإطار العام" إنشاء "مطالبة الاسترداد".
ميزات الأمان في البروتوكول
على الرغم من أنّ التحليل الكامل للبروتوكول لا يندرج ضمن نطاق هذا المستند، نريد تسليط الضوء على بعض وسائل الحماية المضمّنة في البروتوكول. وعلى وجه التحديد، لا يستخدم البروتوكول سوى التجزئة لمفتاح LSKF طوال الوقت. وهذا يعني أنّه إذا كان مفتاح LSKF يتضمّن محتوى عشوائيًا بدرجة عالية (مثلاً، إذا كانت كلمة مرور جيدة تتضمّن محتوى عشوائيًا بدرجة عالية)، يكون تخزين "الخزينة" أفضل بكثير من تخزين تجزئة كلمة المرور، وفي هذه الحالة، يمكن أن يوفّر تجزئة كلمة المرور مقياسًا للأمان مستقلاً عن أمان THM. لهذا السبب، نتيح استخدام دالة التجزئة "الذاكرة الصعبة" المصحوبة بملح لتشفير مفتاح LSKF كجزء من بروتوكول. ونربط أيضًا "الخزينة" تشفيريًا بمعرّف للجهاز الذي أنشأه وربط "طلب الاسترداد" بمعرّف عشوائي يُستخدَم كتحدّي أثناء بروتوكول "فتح الخزينة" لضمان أن يكون "طلب الاسترداد" جديدًا.
بما أنّه يتم إنشاء مفتاح الاسترداد حديثًا عند إنشاء كلّ "خزينة"، فإنّنا نفّذنا عملية تدوير المفاتيح من خلال استبدال إدخال "خزينة" حالي بـ "خزينة" تم إنشاؤها حديثًا. يتم اختيار عنوان عداد المحاولة التي تعذّر إكمالها الذي يستخدمه Vault أثناء إنشاء Vault، ويضمن "الإطار العام" عدم تغيُّر عنوان عداد المحاولة الذي يستخدمه أيّ Vault لاحق ما لم يتم تغيير مفتاح LSKF أو توفُّر قائمة جديدة موثَّقة للمفاتيح العامة للمجموعات النموذجية. وبالتالي، يمكن إجراء عملية تدوير مفتاح الاسترداد بدون التأثير في الحماية من هجمات القوة الغاشمة لمفتاح LSKF.
أمان الخادم لخدمة Cloud Key Vault
يتم تنفيذ الخادم باستخدام مجموعة من البرامج التي تعمل على أجهزة الخادم العادية، والبرامج الثابتة التي تعمل على أجهزة مخصّصة (شريحة Titan). سنوضّح وسائل الحماية التي نقدّمها في كل طبقة.
وسائل حماية الأجهزة
إنّ الحماية الأمنية الأساسية التي يتم تنفيذها من جهة الخادم في خدمة CKV هي وحدات الأجهزة الموثوق بها (THM) التي تم إنشاؤها باستخدام شرائح Titan المصمّمة خصيصًا من Google. تعمل الشرائح على البرامج الثابتة التي توفّر واجهات برمجة التطبيقات اللازمة لتنفيذ بروتوكولات CKV. على سبيل المثال، يمكنهم إنشاء مفتاحَي تشفير ومشاركتهما بأمان مع أعضاء آخرين في المجموعة النموذجية، بحيث يحمي منطق البرامج الثابتة المفتاح الخاص من التسرب خارج شرائح Titan في المجموعة النموذجية. يمكنهم أيضًا تنفيذ عملية فتح Vault، والحفاظ على عداد تصاعدي بدقة لكل Vault للمحاولات غير الناجحة (حيث يتم الاحتفاظ بالعداد من خلال الحالة المخزّنة داخل شريحة Titan). سيتم تقديم وصف أكثر تفصيلاً للبروتوكول الذي تنفّذه البرامج الثابتة لشريحة CKV Titan في إصدار مستقبلي من هذا المستند.
بما أنّ أمان الخادم يعتمد على منطق البرامج الثابتة في شرائح Titan، يجب أن نضمن عدم تغيُّر المنطق بطريقة تسمح للشرائح بتسرُّب الأسرار أو تجاهلحدود العداد. لتحقيق هذا الهدف، نغيّر أيضًا أداة تحميل نظام التشغيل Titan لضمان محو البيانات المخزّنة في chip بالكامل (مثل المفتاح الخاص لمجموعة Cohort) قبل تطبيق أي تحديث. الجانب السلبي لهذه الحماية هو أنّه لا يمكننا تصحيح الأخطاء في البرامج الثابتة بدون فقدان بعض البيانات، لأنّ تحديث البرامج الثابتة يعادل من الناحية الوظيفية تدمير الجهاز الحالي واستبداله بشرائح جديدة. في حال كان ضروريًا تحديث برمجي مهم للبرامج الثابتة، ستحتاج Google إلى إنشاء قائمة جديدة تمامًا من مفاتيح مجموعات النموذج العلنية المعتمَدة ونشرها، ونقل جميع المستخدمين تدريجيًا إلى القائمة الجديدة. للحدّ من هذا الخطر، نحاول إبقاء قاعدة بيانات البرامج الثابتة صغيرة إلى حدٍ ما، ونراجعها بعناية بحثًا عن أي مشاكل أمنية محتملة.
وسائل حماية البرامج
بالإضافة إلى الحدود القصوى الصارمة لعدد حالات الفشل لكلّ "خزينة" التي تفرضها مجموعات THM، تنفِّذ خدمة CKV أيضًا الحدّ من معدّل الإرسال المستنِد إلى البرامج. تم تصميم ميزة الحد من معدّل تكرار الطلبات لمنع المخترقين من الوصول إلى حساب المستخدم واستنفاذ الحد الأقصى لعدد محاولات استرداد غير الناجحة بسرعة، ما يؤدي إلى منع المستخدم الحقيقي من الوصول إلى مفاتيح الاسترداد. على غرار التأخيرات الزمنية التي يفرضها جهاز المستخدم بعد إجراء عدد كبير جدًا من المحاولات غير الناجحة لفتح الشاشة، ستفرض خدمة CKV تأخيرًا زمنيًا متزايدًا بعد كل طلب لاحق غير ناجح لفتح ملف Vault.
نحن نطبّق أيضًا إجراءات أمان عادية لخدمات السحابة الإلكترونية التي تستضيف بيانات المستخدمين، بما في ذلك عناصر التحكّم في الوصول والمراقبة والتدقيق الصارمة.
مواصفات البروتوكول التفصيلية
لا تزال مواصفات البروتوكول التفصيلية قيد التطوير، وسيتم تعديل هذا المستند لتشمل تلك التفاصيل إلى جانب نشر رمز العميل في "مشروع Android المفتوح المصدر" في وقت لاحق من هذا العام.
ملاحظات
- "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX". 1 آب (أغسطس) 2014، https://www.usenix.org/node/184458. ↩
- "مدوّنة Google Cloud Platform: شرح مفصّل عن Titan: الأمان في النص العادي". 24 آب (أغسطس) 2017، https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html. ↩
- "تعلن Google عن أكثر من ملياري جهاز نشِط شهريًا على Android"، 17 أيار (مايو) 2017، https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users. ↩
- يتيح لنا ذلك توفير واجهات مستخدم مرنة لإدخال مفتاح LSKF لجهاز آخر، لأنّ إطار عمل الجهاز الحالي قد لا يتضمّن واجهة مستخدم مناسبة لإدخال مفتاح LSKF للجهاز القديم. ↩