خدمة Google Cloud Key Vault

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

المؤلف: شابسي والفيش
تاريخ الإصدار: 2018-03-06

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

نظرة عامة

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

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

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

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

المفاهيم الأساسية

في البداية، كان نظام التشغيل Android 9 Pie هو النظام الأساسي الوحيد المتوافق مع خدمة Cloud Key Vault، وعندما نشير إلى العميل في هذا التقرير الموجز، نشير إلى جهاز يعمل بنظام التشغيل Android 9 Pie مع "خدمات Google Play". يتم تنفيذ عملية التنفيذ من جهة الخادم على خوادم Google المحدّدة خصيصًا والتي تم تثبيت شريحة Titan إضافية 2 فيها. تعمل شريحة Titan من تصميم Google كمكوّن خارجي في وحدة الأجهزة الموثوق بها، ونزوّدها بشكل خاص ببرنامج إقلاع وبرامج ثابتة مخصّصة لتنفيذ البروتوكولات وآليات تنفيذ الأمان (كما هو موضّح هنا). ونستخدم تقنيات المصادقة على الأجهزة من أجل الحصول على ضمانات بأنّ البروتوكول الذي نستخدمه يعمل فعلاً على أجهزة Titan.

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

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

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

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

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

Android Framework: نستخدم هذا المصطلح العام (أو إطار العمل فقط) للإشارة إلى واجهات برمجة التطبيقات في الإصدار 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 بشكل دوري قائمة بالمفاتيح العامة لكل مجموعة من "تقنية المعلومات والاتصالات"، بالإضافة إلى مصادقة على القائمة. تستخدم المصادقة المدرَجة في القائمة توقيعًا يؤدي إلى جذور الثقة. يحتوي كل تعديل للقائمة المنشورة أيضًا على رقم تسلسل، لذلك من الممكن منع العودة إلى الحالة السابقة. سيجلب وكيل الاسترداد أحدث قائمة منشورة للمفاتيح العامة الخاصة بالمجموعة النموذجية ويضيفها إلى إطار العمل. يتحقق إطار العمل بعد ذلك من المصادقة ويختار عشوائيًا مفتاحًا عامًا للمجموعة النموذجية من القائمة لاستخدامه في مرحلة إنشاء أداة Vault.

إنشاء Vault

بعد المساعدة في إكمال إعداد إطار العمل من خلال استرجاع قائمة المفاتيح العامة للمجموعة، سيطلب وكيل الاسترداد إطار العمل لإنشاء أداة Vault جديدة. عند إدخال المستخدم لإطار العمل في المرة التالية، سينشئ إطار العمل مفتاح استرداد جديدًا وسيتم تشفيره أولاً باستخدام مفتاح مشتق من تجزئة 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 إلى توفير "الدفاع المعمّق" من خلال تضمين وسائل حماية أمنية على مستويات متعدّدة من حزمة SDK. وللتعرّف على طريقة عمل إجراءات الحماية هذه، سنبدأ بوصف العميل وننتقل إلى حزمة الخدمات في خدمة 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 لفترة وجيزة في إطار العمل في ذاكرة الوصول العشوائي. وهذه هي اللحظة التي تستخدمها واجهة برمجة التطبيقات الجديدة لإنشاء Vault. لا يمكن إنشاء Vault جديد محمي من LSKF عندما يكون الجهاز مقفلاً، وذلك لأنّ LSKF غير متوفرة.

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

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

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

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

  1. "نحو تخزين موثوق لأسرار 56 بت في الذاكرة البشرية | USENIX." 1 آب (أغسطس) 2014، https://www.usenix.org/node/184458.
  2. "مدونة Google Cloud Platform: Titan in depth: الأمان في النص العادي". 24 آب (أغسطس) 2017، https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html.
  3. "أعلنت Google عن أكثر من ملياري جهاز نشط شهريًا على Android ...." 17 أيار (مايو) 2017، https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-month-active-users.
  4. ويتيح لنا ذلك توفير واجهات مستخدم مرنة لإدخال LSKF في جهاز آخر، وقد لا يتضمّن إطار عمل الجهاز الحالي واجهة مستخدم مناسبة لإدخال LSKF في الجهاز القديم.