خدمة Google Cloud Key Vault

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

المؤلف: شابسي فالفيش
تاريخ النسخة: 2018-03-06

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

نظرة عامة

يتطلب التشفير (الذي يُستخدَم لضمان خصوصية البيانات) عادةً استخدام أسرار ذات قصور عالٍ من منظور المهاجم. يجب توفير قصور عالٍ لأن نظام التشفير يجب أن يقاوم هجمات القوة الغاشمة التي تستكشف فضاء جميع الأسرار المحتملة إلى أن يتم العثور على المفتاح الصحيح. ونظرًا لتوفّر القدرة الحاسوبية في الوقت الحالي، قد يكون حدًّا أدنى معقولاً من متطلبات القصور لأسرار التشفير في محيط يتراوح بين 70 و80 بت. للأسف، يجد المستخدمون صعوبة كبيرة في تذكّر كلمات المرور أو الأسرار الأخرى التي تحتوي على هذا المقدار من القصور وتذكُّرها بشكل موثوق به¹، لا سيّما إذا نادرًا ما يتم استخدامها (ولكن يُعدّ الاستخدام المتكرر لكلمة مرور ذات نسبة عالية من الإنتروبيا أمرًا صعبًا ومملًا). يواجهنا هذا الأمر مشكلة صعبة، وهي كيف يمكننا حماية البيانات الخاصة باستخدام تقنية التشفير إذا أردنا أن يكون السر "عامل معرفة" من المرجح جدًا أن يتذكّره المستخدم؟ لأسباب متعددة، يكون من الصعب جدًا حلّ هذه المشكلة، وبالتالي يتم عادةً تشفير البيانات باستخدام الأسرار التي يديرها مقدّم خدمة Cloud Storage نفسه، بدلاً من الاعتماد على المستخدم لتذكّر بيانات سرّية.

إحدى الطرق السديمة بين متطلبات أسرار التشفير والأسرار البشرية التي لا تُنسى هي استخدام خدمة Cloud Key Vault (CKV) لتخزين "مفتاح استرداد" عالي الإنتروبيا، ومحميًا بواسطة سر قصور بشري منخفض لا يُنسى. لن تُصدر خدمة CKV مفتاح الاسترداد سوى إلى الطرف الذي يثبت معرفته بالسر الصحيح الذي لا يُنسى. يمكن لخدمة CKV إحباط هجمات القوة الغاشمة على سر الإنسان الذي لا يُنسى، ما سيفرض حدًا مطلقًا على عدد المحاولات غير الناجحة لإثبات معرفة السر. مفتاح الاسترداد نفسه هو مفتاح تشفير متماثل عادي، وهو مناسب للاستخدام مع نظام تشفير (مصدَّق عليه) يمكنه بسهولة تشفير كمية كبيرة من البيانات (مثل النسخة الاحتياطية على القرص) التي يمكن تخزينها بأمان في أي مكان، ولا تكون هذه البيانات المشفّرة مفيدة لأي مستخدم لا يمكنه الحصول على مفتاح الاسترداد.

يصف هذا التقرير الموجز طريقتنا في إنشاء خدمة تخزين المفاتيح في السحابة الإلكترونية باستخدام وحدات الأجهزة الموثوق بها (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. يتم تنفيذ عملية التنفيذ من جهة الخادم على خوادم Google المخصّصة والمثبّتة فيها شريحة Titan إضافية². تُعدّ شريحة Titan من Google التي صممتها Google مكوِّنًا للأجهزة في "وحدة الأجهزة الموثوق بها"، ونزوّدها بشكل خاص ببرنامج إقلاع وبرامج ثابتة مخصَّصة تنفّذ بروتوكولاتنا وآليات تنفيذ الأمان (كما هو موضّح هنا). ونحن نستخدم تقنيات المصادقة على الأجهزة من أجل الحصول على ضمانات بأنّ البروتوكول يعمل في الواقع على أجهزة Titan.

يجب توسيع نطاق خدمة CKV لمعالجة زيارات المليارات³ من أجهزة Android، بدون فقدان أي قدر كبير من بيانات المستخدمين بسبب تعطُّل الأجهزة (على سبيل المثال، تعطُّل الشرائح) أو مواجهة أي انقطاعات طويلة في الخدمة بسبب صيانة مركز البيانات. لهذا السبب، يتم تنظيم الخوادم التي تحتوي على شرائح Titan على مجموعات نموذجية، حيث تتكوّن كل مجموعة نموذجية من عدة وحدات THM مستقلة تحتوي على نسخة من المادة الأساسية نفسها. سيتم توزيع مجموعة نموذجية معيّنة على مراكز بيانات متباينة فعليًا في مناطق صيانة مختلفة، لضمان أن يتمكن النظام من تحقيق أهداف التوفّر والموثوقية. ولقابلية التوسّع، سيتم تقسيم العملاء إلى عدد من المجموعات النموذجية المختلفة، حتى نتمكن من تعديل سعة الخدمة عن طريق إضافة المزيد من الخوادم لزيادة عدد المجموعات النموذجية المتاحة.

نحن الآن جاهزون لتعداد المكونات الرئيسية لبنية خدمة Cloud Key Vault.

المكونات المعمارية / مسرد المصطلحات

عامل المعرفة لشاشة القفل (LSKF): هو مفتاح سرّي يسهُل تذكّره، مثل رقم تعريف شخصي قصير أو نمط تمرير سريع فوق شبكة مكوّنة من 3 نقاط × 3 نقاط أو كلمة مرور. يُستخدم هذا المفتاح السرّي لحماية إمكانية فتح قفل الجهاز على الجهاز، ويُعتبر عامل مصادقة أساسي (أو "قوي") لقفل شاشة الجهاز المحلي للمستخدم.

العميل: جهاز مستخدم نهائي يعمل بنظام التشغيل Android 9 Pie و"خدمات Google Play" أو برنامج متوافق

إطار عمل Android: نستخدم هذا المصطلح العام (أو إطار العمل فقط) للإشارة إلى واجهات برمجة التطبيقات في الإصدار Android 9 Pie أو الإصدارات الأحدث، وليس من المفترض أن يشير إلى أي إصدارات سابقة.

خدمات Google Play: هي مجموعة من الخدمات والتطبيقات التي تعمل على جهاز المستخدم النهائي، ما يتيح له العمل مع نظام حسابات Google وواجهات برمجة التطبيقات للخوادم المخصّصة.

عميل استرداد الحساب: هو تطبيق نظام يتم تشغيله كجزء من "خدمات Google Play" في مساحة المستخدم على جهاز Android 9 Pie (أو ما شابه ذلك). ويكون وكيل الاسترداد مسؤولاً عن تنفيذ جانب "العميل" للبروتوكولات المختلفة، والتفاعل مع نظام التشغيل Android عند الضرورة لصياغة أي رسائل بروتوكول تتضمّن LSKF.

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

مفتاح الاسترداد: مفتاح تشفير سرّي تحميه خدمة Cloud Key Vault، ويُستخدم لتشفير البيانات (ومصادقتها) على جهاز العميل. بعد وضع مفتاح الاسترداد في Vault (انظر أدناه)، يمكن حذف النسخة المتوفّرة على الجهاز فور انتهاء العميل من استخدامها لتشفير البيانات.

خدمة Cloud Key Vault (CKV): هي خدمة إنترنت تتيح لأجهزة العميل تخزين مفاتيح التشفير المحمية بتشفير LSKF لا يُنسى.

مجموعة نموذجية: هي مجموعة من خوادم Vault/خدمات THM التي يمكنها العمل كنُسخ طبق الأصل عن بعضها البعض.

المفتاح العام لمجموعة: المفتاح العام من زوج مفاتيح يتم إنشاؤه من خلال مجموعة محددة من مجموعات THM. لا يتوفر المفتاح الخاص المقابل إلا داخل مجموعات THM التي كانت في المجموعة النموذجية في وقت إنشاء المفتاح.

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

Vault: إدخال معيّن في قاعدة بيانات "خدمة CKV" يحتوي على مفتاح استرداد LSKF المحمي لجهاز واحد. قد يكون لدى المستخدم النهائي عدة مجموعات Vault محفوظة في الملف، كل منها يتوافق مع جهاز مختلف أو LSKF. ويمكن فقط لوحدة THM في خادم Vault فحص محتوى Vault أو استخراجه.

خادم Vault: هو جهاز يُستخدم للأغراض العامة في مركز بيانات Google تم تعديله خصيصًا لإضافة وحدة أجهزة موثوق بها (THM).

تصميم البروتوكول

يتألف بروتوكول CKV من عدة مراحل، كما يلي:

الإعداد

لإعداد النظام، ستوفر Google مفتاحًا عامًا لـ "جذر ثقة" سيستخدمه إطار العمل للتحقّق من تصديقات أجهزة Google. يتم تخزين مفتاح التوقيع لجذر الثقة هذا بلا اتصال بالإنترنت وتأمينه بعناية بحيث يتطلّب مشاركة عدة موظفين من أجل التوقيع باستخدامه. يتم إدخال المفتاح العام لجذر الثقة هذا في نظام التشغيل Android، ولا يمكن تغييره إلا من خلال تحديث نظام التشغيل.

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

إنشاء Vault

بعد مساعدة إطار العمل في إكمال الإعداد عن طريق استرجاع قائمة المفاتيح العامة للمجموعة، سيطلب وكيل الاسترداد إطار العمل لإنشاء أداة Vault جديدة. وعند إدخال المستخدم لمعيار LSKF في المرة التالية، سينشئ إطار العمل مفتاح استرداد جديدًا وسيتم تشفيره أولاً باستخدام مفتاح مشتق من تجزئة LSKF، ثم باستخدام المفتاح العام للمجموعة النموذجية الذي يختاره إطار العمل أثناء الإعداد. ويكون الكائن الثنائي المشفّر الناتج هو Vault الذي تمت إعادته من خلال إطار العمل إلى وكيل الاسترداد، والذي يحمِّله بعد ذلك إلى خدمة "CKV" من Google.

فتح Vault

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

توجّه أداة CKV المطالبة بالاسترداد (وVault المقابلة لها) إلى خوادم Vault التي تشكل جزءًا من المجموعة النموذجية الصحيحة. بعد ذلك يفكّ THM في خوادم Vault فك تشفير المطالبة بالاسترداد ويحاول استخراج مفتاح الاسترداد من Vault الأصلي باستخدام تجزئة LSKF التي تمت المطالبة بها (لاستخلاص مفتاح التشفير الداخلي). في حال تطابقت تجزئة LSKF الأصلية وتجزئة LSKF المُطالب بها، ستستخرج THM مفتاح الاسترداد من Vault ويعيد تشفيره باستخدام مفتاح المطالبة الذي كان في المطالبة بالاسترداد. إذا لم يكن الأمر كذلك، سيصدر THM عدّاد محاولة فاشلة. عندما يصل عدد المحاولات الفاشلة إلى الحدّ الأقصى المسموح به، سيرفض فريق THM معالجة أي مطالبات لاحقة بشأن استرداد الحساب في Vault.

أخيرًا، إذا سارت الأمور على ما يرام، سيتم إرسال مفتاح الاسترداد المُعاد تشفيره (الذي تم تشفيره الآن ضمن مفتاح المدّعي) من خادم Vault بالكامل إلى إطار العمل. يستخدم إطار العمل نسخته من مفتاح المدّعي لفك تشفير مفتاح الاسترداد، ويصبح البروتوكول جاهزًا الآن.

إجراءات الأمان

يهدف نظام Cloud Key Vault إلى توفير "الدفاع المتعمق" من خلال تضمين وسائل الحماية الأمنية على مستويات متعددة من الحزمة. لتوضيح آلية عمل وسائل الحماية هذه، سنبدأ بوصف العميل، وننتقل إلى حزمة المحتوى إلى "خدمة Cloud Key Vault".

أمان العملاء

استنادًا إلى المصنِّع الأصلي للجهاز والجهاز المُحدَّدَين، يتم عادةً تخزين عامل معرفة شاشة القفل (LSKF) وحمايته على الجهاز باستخدام مجموعة من الطرق التي تختلف حسب المصنّع الأصلي للجهاز. على سبيل المثال، تستفيد أجهزة Pixel 2 من Google من وحدة أمان مقاومة للتلاعب، لتخزين LSKF في حال عدم النشاط، وفرض حدود على المعدلات المستندة إلى الأجهزة على التحقق من LSKF. تم تصميم واجهات برمجة التطبيقات الخاصة بإطار العمل الجديدة التي يتم تقديمها لإتاحة استخدام Cloud Key Vault للحفاظ على ضمانات الأمان الحالية لأقصى درجة ممكنة، حتى عندما يستخدم الجهاز وحدة أمان الأجهزة هذه لحماية تخزين LSKF.

سنركّز في هذا القسم تحديدًا على مشاكل الأمان وإجراءات الحماية ذات الصلة التي تؤثر في ميزة Cloud Key Vault الجديدة، بدلاً من محاولة تقديم صورة كاملة عن جميع آليات الأمان المرتبطة بـ LSKF.

تأمين واجهات برمجة تطبيقات إطار العمل

يتم وضع علامة @SystemApi على واجهات برمجة التطبيقات الخاصة بإطار العمل الجديدة التي تمت إضافتها لإتاحة خدمة CKV، كما أنّها تتطلّب أذونات خاصة تضمن عدم توفّرها إلا لتطبيقات النظام المعتمَدة من المصنّعين الأصليين، مثل "خدمات Google Play". ويؤدي هذا إلى حد كبير إلى إزالة أي الأجزاء المعرضة للهجوم المباشر قد تكون مكشوفة للتطبيقات التي يثبّتها المستخدم على الجهاز.

تضمن واجهات برمجة التطبيقات الخاصة بإطار العمل أيضًا إنشاء Vault للمفاتيح العامة الخاصة بالمجموعة النموذجية التي تم التأكّد من صحتها فقط. يتم دمج جذر الثقة في إطار العمل من قِبل المصنّع الأصلي للجهاز عند شحنه، ولا يمكن تغييره بدون تحديث نظام التشغيل. وهذا يضمن عدم استخدام LSKF سوى لإنشاء Vault والتي ستفرض بشكل صحيح إجراءات حماية القوة الغاشمة المستندة إلى الأجهزة. من خلال الاعتماد على أجهزة THM في خدمة Cloud Key Vault لحماية القوة الغاشمة على LSKF، يمكننا توفير مستوى أمان مشابه لاستخدام أجهزة آمنة على الأجهزة (مثل أجهزة Google Pixel 2).

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

تأمين وكيل الاسترداد

تتمثل الحماية الأمنية الأساسية التي نقدمها في وكيل الاسترداد في أن البروتوكول مصمم لمنع وكيل الاسترداد من رؤية LSKF للجهاز الحالي أو أي مفاتيح استرداد. ويجب أن تظهر هذه الأخطاء من جانب "إطار العمل" فقط، ما يجعل من الصعب استغلال أي أخطاء محتملة أو ثغرات أمنية في وكيل الاسترداد. يتم استخدام وكيل الاسترداد في الغالب لإدارة أحداث مراحل النشاط وتمرير البيانات ذهابًا وإيابًا بين السحابة الإلكترونية وإطار العمل. ويحدث الاستثناء الوحيد لذلك أثناء عملية الاسترداد قبل بروتوكول فتح Vault مباشرةً، عندما يكون على المستخدم الدخول إلى واجهة المستخدم القديمة (LSKF) للجهاز القديم، حيث يتم تنفيذ واجهة المستخدم التي تجمع بيانات LSKF التي تمت المطالبة بها للجهاز القديم في وكيل الاسترداد⁴. مع ذلك، إنّ تنفيذ وكيل الاسترداد "ينسى" طلب استرداد الحساب الذي تمت المطالبة بملكيته بعد أن يبدأ إطار العمل في إنشاء مطالبة استرداد الحساب.

الميزات الأمنية للبروتوكول

علمًا أنّ التحليل الكامل للبروتوكول خارج نطاق هذا المستند، نريد تسليط الضوء على بعض إجراءات الحماية المضمَّنة في البروتوكول. وعلى وجه الخصوص، يستخدم البروتوكول بشكل خاص تجزئة LSKF طوال الوقت. وهذا يعني أنّه إذا كانت قيمة القصور في LSKF كبيرة (على سبيل المثال، إذا كانت كلمة مرور جيدة ذات إنتروبيا عالية)، يكون تخزين Vault أفضل تمامًا من تخزين تجزئة كلمة المرور، وفي هذه الحالة، يمكن أن توفّر تجزئة كلمة المرور مقياس أمان مستقلاً عن أمان أجهزة THM. لهذا السبب، نتيح استخدام التجزئة المملّحة لحقل "صعب الذاكرة" لمقياس LSKF كجزء من البروتوكول. كما نربط Vault أيضًا بمعرّف الجهاز الذي أنشأه Vault بطريقة مشفَّرة، ونربط مطالبة الاسترداد برقم هاتف يتم استخدامه كتحدي أثناء بروتوكول فتح Vault وذلك لضمان أن تكون المطالبة بالاسترداد حديثة.

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

أمان الخادم في "خدمة Cloud Key Vault"

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

وسائل حماية الأجهزة

إنّ الحماية الأمنية الأساسية التي يتم تنفيذها على الخادم في خدمة CKV هي وحدات الأجهزة الموثوق بها (THM) التي تم تصميمها باستخدام شرائح Titan ذات التصميم المخصّص من Google. تعمل الشرائح على برامج ثابتة تعرض واجهات برمجة التطبيقات اللازمة لتنفيذ بروتوكولات CKV. وعلى وجه التحديد، يمكنهم إنشاء مفتاحَي تشفير ومشاركتهما بأمان مع أعضاء المجموعة النموذجية الآخرين كي يحمي منطق البرامج الثابتة المفتاح الخاص من تسرُّب المفتاح الخاص من خارج شرائح Titan في المجموعة النموذجية. ويمكنهم أيضًا تنفيذ عملية "فتح أداة Vault" والاحتفاظ بعدّاد المحاولات الفاشلة لكل أداة Vault الذي تتم زيادته بشكل صارم (حيث يكون العدّاد مدعومًا بالحالة مخزّنة داخل شريحة Titan). سيتم تقديم وصف أكثر تفصيلاً للبروتوكول المنفَّذ من خلال البرامج الثابتة الخاصة بشريحة CKV Titan في إصدار مستقبلي من هذا المستند.

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

إجراءات حماية البرامج

بالإضافة إلى الحدود الصعبة للفشل لكل Vault التي تفرضها أنظمة THM، فإن خدمة CKV تطبّق أيضًا حدًا للمعدل المستند إلى البرامج. وتم تصميم الحدّ الأقصى لمعدّل الزحف لمنع المخترِق من الدخول إلى حساب المستخدم واستنفاد حدّه من محاولات الاسترداد غير الناجحة بسرعة، ما يؤدي إلى حظر إمكانية وصول المستخدم الحقيقي إلى مفاتيح الاسترداد بشكلٍ فعّال. وعلى غرار حالات التأخير الزمنية التي يفرضها جهاز المستخدم بعد تعذُّر إجراء عدد كبير جدًا من المحاولات غير الناجحة لفتح قفل الشاشة، ستفرض خدمة CKV تأخيرًا زمنيًا متزايدًا بعد كل طلب لاحق لتعذُّر فتح Vault.

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

مواصفات البروتوكول التفصيلية

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

Notes