سرویس Google Cloud Key Vault

ما یک سرویس ابری را توصیف می‌کنیم که از سخت‌افزار امن برای ذخیره کلیدهای رمزنگاری استفاده می‌کند، به طوری که دسترسی به آن‌ها توسط یک فاکتور دانش آنتروپی پایین (مثلاً یک پین قفل صفحه) محافظت می‌شود. سخت افزار ایمن برای جلوگیری از حملات brute force طراحی شده است، با ساختن کلیدهای رمزنگاری ذخیره شده برای همیشه غیرقابل بازیابی پس از تلاش های ناموفق بسیار برای تامین ضریب دانش صحیح.

نویسنده: شبسی والفیش
تاریخ نسخه: 2018-03-06

توجه: این سند هنوز در حال انجام است و جزئیات اجرایی هنوز در حال نهایی شدن است. همانطور که سیستم تثبیت می شود و اسناد بیشتری می تواند تولید شود، ما این کاغذ سفید را با اطلاعات دقیق تر به روز می کنیم (به ویژه در ارتباط با نسخه های منبع باز مربوطه).

نمای کلی

به طور سنتی، رمزگذاری (که برای اطمینان از حفظ حریم خصوصی داده ها استفاده می شود) مستلزم استفاده از اسرار است که از دیدگاه مهاجم دارای آنتروپی بالایی است. آنتروپی بالا مورد نیاز است زیرا طرح رمزگذاری باید در برابر حملات brute force مقاومت کند که فضای همه اسرار احتمالی را تا زمانی که اسرار صحیح پیدا شود کشف می کند. با توجه به در دسترس بودن توان محاسباتی امروزی، حداقل نیاز آنتروپی معقول برای اسرار رمزنگاری ممکن است در همسایگی 70 تا 80 بیت باشد. متأسفانه، به خاطر سپردن و یادآوری قابل اعتماد رمزهای عبور یا سایر اسرار با آنتروپی ¹ برای انسان بسیار دشوار است، به خصوص اگر به ندرت از آنها استفاده شود (اما استفاده مکرر از رمز عبور با آنتروپی بالا دشوار و خسته کننده است). این ما را با یک مشکل چالش برانگیز روبرو می کند: چگونه می توانیم از داده های خصوصی با فناوری رمزگذاری محافظت کنیم، اگر می خواهیم راز یک "عامل دانش" باشد که به احتمال زیاد توسط کاربر به خاطر سپرده می شود؟ به دلایل مختلف، حل این مشکل آنقدر سخت است که سرویس‌های ذخیره‌سازی ابری معمولاً فقط داده‌ها را با اسرار رمزگذاری می‌کنند که توسط خود ارائه‌دهنده فضای ذخیره‌سازی ابری مدیریت می‌شوند، نه اینکه به کاربر برای به خاطر سپردن راز خود متکی باشند.

یک رویکرد برای پر کردن شکاف بین الزامات اسرار رمزنگاری و اسرار به یاد ماندنی انسان، استفاده از سرویس Cloud Key Vault (CKV) برای ذخیره یک "کلید بازیابی" با آنتروپی بالا است که توسط یک راز به یاد ماندنی انسانی با آنتروپی پایین محافظت می شود. سرویس CKV کلید بازیابی را فقط در اختیار طرفی قرار می‌دهد که دانش صحیح راز به یاد ماندنی انسان را ثابت کند. حملات بی رحمانه علیه راز به یاد ماندنی انسان را می توان توسط سرویس CKV خنثی کرد، که محدودیت مطلقی را در تعداد تلاش های ناموفق برای اثبات آگاهی از راز اعمال می کند. کلید بازیابی به خودی خود یک کلید متقارن رمزنگاری استاندارد است، مناسب برای استفاده با یک طرح رمزگذاری (تایید شده) که به راحتی می تواند حجم زیادی از داده ها (مانند پشتیبان دیسک) را رمزگذاری کند که می تواند به طور ایمن در هر جایی ذخیره شود – چنین داده های رمزگذاری شده ای بی فایده است. هر کسی که نمی تواند کلید بازیابی را دریافت کند.

این کاغذ سفید رویکرد ما را برای ساخت یک سرویس Cloud Key Vault با استفاده از ماژول‌های سخت‌افزار مورد اعتماد (THM) توضیح می‌دهد. اولین اجرای ما از سرویس CKV برای محافظت از کلیدهای بازیابی با ضریب دانش صفحه قفل کاربر (LSKF) طراحی شده است - پین مخفی، رمز عبور، یا الگوی کش رفتن مورد استفاده برای باز کردن قفل گوشی های هوشمند. انسان ها می توانند به طور قابل اعتماد LSKF خود را به خاطر بسپارند. در عین حال، چنین اسرار LSKF معمولاً دارای آنتروپی کافی برای مقاومت در برابر مهاجمی است که تعداد تلاش های بسیار محدودی دارد و آنها را برای سرویس CKV مناسب می کند.

اولین کاربرد سرویس Cloud Key Vault ما فعال کردن پشتیبان‌گیری رمزگذاری‌شده اندروید در سمت مشتری خواهد بود. پیش از این، فایل‌هایی که به صورت محلی روی دستگاه اندرویدی رمزگذاری شده بودند، از کلید محافظت شده با LSKF کاربر استفاده می‌کردند، اما نسخه‌های پشتیبان آن فایل‌های ذخیره شده (و رمزگذاری‌شده) در Cloud توسط LSKF محافظت نمی‌شدند. برای اولین بار، Cloud Key Vault محافظت از صفحه قفل را برای نسخه های پشتیبان اندروید ذخیره شده در Cloud نیز فعال می کند. این بدان معناست که سرورهای Google توانایی دسترسی یا بازیابی محتوای پشتیبان‌های رمزگذاری شده را ندارند - فقط دستگاهی با LSKF کاربر می‌تواند پشتیبان‌ها را رمزگشایی کند.

مفاهیم اصلی

در ابتدا، تنها پلتفرم مشتری پشتیبانی شده برای سرویس Cloud Key Vault، سیستم عامل Android 9 Pie است، و وقتی در سراسر این کاغذ سفید به مشتری اشاره می کنیم، به دستگاهی اشاره می کنیم که سیستم عامل Android 9 Pie را با خدمات Google Play اجرا می کند. پیاده‌سازی سمت سرور ما روی سرورهای Google ویژه تعیین‌شده اجرا می‌شود که یک تراشه Titan ² اضافی در آنها نصب شده است. تراشه Titan طراحی‌شده توسط Google به‌عنوان جزء سخت‌افزاری ماژول سخت‌افزار مورد اعتماد ما عمل می‌کند، و ما به‌ویژه آن را با یک بوت‌لودر و سفت‌افزار سفارشی ارائه می‌کنیم که پروتکل‌ها و مکانیسم‌های اجرایی امنیتی ما را پیاده‌سازی می‌کند (همانطور که در اینجا توضیح داده شد). ما از تکنیک های گواهی سخت افزاری استفاده می کنیم تا اطمینان حاصل کنیم که پروتکل ما واقعاً روی سخت افزار Titan اجرا می شود.

سرویس CKV باید به گونه‌ای باشد که ترافیک ^{میلیاردها} دستگاه Android را مدیریت کند، بدون از دست دادن مقدار قابل توجهی از داده‌های کاربر به دلیل نقص سخت‌افزاری (مثلاً تراشه‌های سوخته) یا هرگونه قطعی طولانی‌مدت به دلیل تعمیر و نگهداری مرکز داده. به همین دلیل، سرورهایی که تراشه‌های تایتان روی آن‌ها قرار دارند، به گروه‌هایی سازمان‌دهی می‌شوند، که در آن هر گروه از چندین THM مستقل تشکیل شده است که هر کدام یک کپی از یک ماده کلیدی دارند. برای اطمینان از اینکه سیستم می‌تواند اهداف در دسترس بودن و قابلیت اطمینان خود را برآورده کند، یک گروه معین در مراکز داده متفاوت از نظر فیزیکی در مناطق نگهداری مختلف توزیع می‌شود. برای مقیاس‌پذیری، مشتریان به تعدادی گروه‌های مختلف تقسیم می‌شوند، به طوری که می‌توانیم ظرفیت سرویس را فقط با افزودن سرورهای بیشتر برای افزایش تعداد گروه‌های موجود تنظیم کنیم.

اکنون آماده برشمردن اجزای اصلی معماری سرویس Cloud Key Vault هستیم.

مولفه های معماری / واژه نامه

عامل دانش قفل صفحه (LSKF): یک راز به یاد ماندنی برای انسان، مانند یک پین کوتاه، یک الگوی تند کشیدن روی یک شبکه 3×3 نقطه، یا یک رمز عبور. این راز برای محافظت از توانایی باز کردن قفل دستگاه به صورت محلی استفاده می‌شود و به عنوان یک عامل تأیید هویت اولیه (یا "قوی") برای قفل صفحه نمایش دستگاه محلی کاربر در نظر گرفته می‌شود.

کلاینت: دستگاه کاربر نهایی که سیستم عامل Android 9 Pie و سرویس های Google Play یا نرم افزاری معادل آن را پشتیبانی می کند.

Android Framework: ما از این اصطلاح عمومی (یا فقط Framework ) برای اشاره به APIهای موجود در Android 9 Pie یا جدیدتر استفاده می‌کنیم، و به معنای اشاره به نسخه‌های قبلی نیست.

سرویس‌های Google Play: مجموعه‌ای از سرویس‌ها و برنامه‌هایی که روی دستگاه کاربر نهایی اجرا می‌شوند و آن را قادر می‌سازند با سیستم حساب Google و APIهای سرور سفارشی کار کند.

Recovery Agent: یک برنامه سیستمی که به عنوان بخشی از خدمات Google Play در فضای کاربر در دستگاه Android 9 Pie (یا مشابه) اجرا می شود. Recovery Agent مسئول اجرای سمت کلاینت پروتکل‌های مختلف است و در صورت لزوم با سیستم عامل Android ارتباط برقرار می‌کند تا پیام‌های پروتکلی که LSKF را در بر می‌گیرد ایجاد کند.

ادعای بازیابی: هنگامی که کاربر می خواهد کلید بازیابی را بازیابی کند، باید یک ادعای بازیابی ایجاد کند که دارای یک نسخه رمزگذاری شده از LSKF است که کاربر ادعا می کند می داند. معمولاً از کاربر خواسته می شود تا LSKF دستگاه قدیمی خود را در دستگاه جدیدی وارد کند که در تلاش است به کلید بازیابی دستگاه قدیمی دسترسی پیدا کند.

کلید بازیابی: یک کلید مخفی رمزنگاری که توسط سرویس Cloud Key Vault محافظت می شود و برای رمزگذاری (و احراز هویت) داده ها در دستگاه مشتری استفاده می شود. هنگامی که کلید بازیابی در یک Vault قرار داده شد (به زیر مراجعه کنید)، به محض اینکه کلاینت با استفاده از آن برای رمزگذاری داده ها کار خود را انجام داد، نسخه محلی را می توان حذف کرد.

سرویس Cloud Key Vault (CKV): یک سرویس اینترنتی که دستگاه های Client را قادر می سازد کلیدهای رمزنگاری را که توسط یک LSKF به یاد ماندنی برای انسان محافظت می شوند، ذخیره کنند.

همگروهی: مجموعه‌ای از سرورها/THM‌های Vault که می‌توانند به‌عنوان کپی اضافی از یکدیگر استفاده کنند.

کلید عمومی کوهورت : کلید عمومی از یک جفت کلید تولید شده توسط یک گروه خاص از THMها. کلید خصوصی مربوطه فقط در داخل THMهایی موجود است که در زمان تولید کلید در گروه بودند.

ماژول سخت افزار قابل اعتماد (THM): یک ماژول امنیتی اختصاصی (میکروکنترلر) که برای ارائه یک محیط محاسباتی حداقل و قابل اعتماد طراحی شده است. حداقل، عنصر امن باید بتواند کلیدهای مخفی را تولید و/یا ذخیره کند، و برخی از وضعیت های در حال تکامل غیرفرار را حفظ کند (به طوری که بتواند از حملاتی که شامل بازنشانی به حالت قبلی است، جلوگیری کند).

Vault: یک ورودی خاص در پایگاه داده سرویس CKV، که حاوی کلید بازیابی محافظت شده LSKF یک دستگاه است. یک کاربر نهایی ممکن است چندین Vault در پرونده داشته باشد که هر کدام مربوط به یک دستگاه یا LSKF متفاوت است. فقط THM در سرور Vault می تواند محتویات Vault را بررسی یا استخراج کند.

Vault Server: ماشینی با هدف عمومی که در مرکز داده Google کار می کند و به طور ویژه برای افزودن یک ماژول سخت افزار قابل اعتماد (THM) مجهز شده است.

طراحی پروتکل

پروتکل CKV از چند مرحله تشکیل شده است که به شرح زیر است:

مقداردهی اولیه

برای راه‌اندازی اولیه سیستم، Google یک کلید عمومی برای «ریشه اعتماد» ارائه می‌کند که چارچوب از آن برای تأیید گواهی‌های سخت‌افزاری Google استفاده می‌کند. کلید امضای این ریشه اعتماد به صورت آفلاین ذخیره می شود و به دقت ایمن می شود به طوری که برای امضای آن نیاز به مشارکت چند کارمند دارد. کلید عمومی برای این ریشه اعتماد در سیستم عامل اندروید قرار می گیرد و فقط از طریق به روز رسانی سیستم عامل قابل تغییر است.

Google همچنین به صورت دوره‌ای فهرستی از کلیدهای عمومی را برای هر گروه از THMها همراه با یک گواهی در فهرست منتشر می‌کند. گواهی موجود در لیست از امضایی استفاده می کند که به ریشه اعتماد متصل می شود. هر به روز رسانی لیست منتشر شده حاوی یک شماره توالی نیز می باشد، به طوری که امکان جلوگیری از بازگشت مجدد وجود دارد. Recovery Agent جدیدترین فهرست منتشر شده از کلیدهای عمومی Cohort را دریافت کرده و آن را در اختیار Framework قرار می دهد. سپس Framework تأییدیه را تأیید می کند و به طور تصادفی یک کلید عمومی کوهورت را از لیست انتخاب می کند تا در مرحله ایجاد Vault استفاده شود.

ایجاد خرک

پس از کمک به Framework برای تکمیل Initialization با واکشی فهرست کلیدهای عمومی همگروهی ، Recovery Agent از Framework درخواست می‌کند تا یک Vault جدید ایجاد کند. هر زمان که LSKF بعدی توسط کاربر وارد شود، Framework یک کلید بازیابی جدید ایجاد می کند و آن را ابتدا با یک کلید مشتق شده از هش LSKF، و سپس با کلید عمومی کوهورت انتخاب شده توسط Framework در حین شروع، رمزگذاری می کند. حباب رمزگذاری شده، Vault است که توسط Framework به Recovery Agent ارسال می‌شود و سپس آن را در سرویس CKV Google آپلود می‌کند.

باز شدن طاق

هنگامی که Recovery Agent در دستگاه جدید نیاز به دسترسی به Recovery Key ذخیره شده در یک Vault خاص داشته باشد، ابتدا از کاربر می خواهد که LSKF دستگاه اصلی را که Vault را ایجاد کرده است، وارد کند. سپس Recovery Agent از Framework می خواهد که با استفاده از آن LSKF یک ادعای بازیابی ایجاد کند. Framework یک Claimant Key جدید ایجاد می‌کند و آن کلید مدعی و همچنین هش LSKF ادعا شده را با همان کلید عمومی گروهی که Vault در ابتدا با آن رمزگذاری شده بود، رمزگذاری می‌کند. لکه رمزگذاری شده به دست آمده Recovery Claim نامیده می شود و Framework آن را به Recovery Agent ارسال می کند و سپس آن را به سرویس CKV ارائه می دهد.

CKV ادعای بازیابی (و Vault مربوط به آن) را به سرورهای Vault که بخشی از کوهورت صحیح هستند هدایت می کند. سپس THM در سرورهای Vault، ادعای بازیابی را رمزگشایی می کند و با استفاده از هش LSKF ادعا شده (برای استخراج کلید رمزگذاری داخلی) سعی می کند کلید بازیابی را از Vault اصلی استخراج کند. اگر هش LSKF اصلی و هش LSKF ادعا شده مطابقت داشته باشند، THM کلید بازیابی را از Vault استخراج می‌کند و آن را با کلید ادعایی که در ادعای بازیابی بود، دوباره رمزگذاری می‌کند. در غیر این صورت، THM با یک شمارنده تلاش ناموفق برخورد می کند. هنگامی که شمارنده تلاش ناموفق به حد مجاز خود رسید، THM از پردازش هرگونه ادعای بازیابی بعدی برای این Vault خودداری می کند.

در نهایت، اگر همه چیز خوب پیش برود، کلید بازیابی مجدد رمزگذاری شده (که اکنون در زیر کلید مدعی رمزگذاری شده است) از سرور Vault تا فریم ورک بازگردانده می شود. Framework از کپی خود از Claimant Key برای رمزگشایی Recovery Key استفاده می کند و پروتکل اکنون کامل شده است.

اقدامات امنیتی

هدف سیستم Cloud Key Vault ارائه "دفاع در عمق" با گنجاندن محافظت های امنیتی در سطوح مختلف پشته ما است. برای اینکه بفهمیم این حفاظت‌ها چگونه کار می‌کنند، با توصیف Client شروع می‌کنیم و به سمت سرویس Cloud Key Vault می‌رویم.

امنیت مشتری

بسته به OEM و دستگاه خاص، ضریب دانش صفحه قفل (LSKF) معمولاً با استفاده از روش‌های مختلفی که بسته به OEM متفاوت است، روی دستگاه ذخیره و محافظت می‌شود. به عنوان مثال، دستگاه‌های پیکسل 2 گوگل از یک ماژول امنیتی سخت‌افزاری مقاوم در برابر دستکاری برای ذخیره LSKF در حالت استراحت و اعمال محدودیت‌های نرخ مبتنی بر سخت‌افزار در اعتبارسنجی LSKF استفاده می‌کنند. APIهای Framework جدیدی که برای فعال کردن استفاده از Cloud Key Vault معرفی شده‌اند، طراحی شده‌اند تا تضمین‌های امنیتی موجود را تا حد امکان حفظ کنند، حتی زمانی که دستگاه از چنین ماژول امنیتی سخت‌افزاری برای محافظت از فضای ذخیره‌سازی LSKF استفاده می‌کند.

ما به‌جای تلاش برای ارائه تصویری کامل از تمام مکانیسم‌های امنیتی مرتبط با LSKF، این بخش را به‌طور خاص بر روی مسائل امنیتی مرتبط و محافظت‌هایی که بر ویژگی جدید Cloud Key Vault تأثیر می‌گذارند، متمرکز خواهیم کرد.

ایمن سازی API های چارچوب

APIهای Framework جدیدی که برای پشتیبانی از سرویس CKV اضافه شده‌اند، به‌عنوان @SystemApi علامت‌گذاری شده‌اند و به مجوزهای خاصی نیاز دارند، که تضمین می‌کند فقط برای برنامه‌های سیستمی مورد تأیید OEM مانند سرویس‌های Google Play در دسترس هستند. این تا حد زیادی هر سطح حمله مستقیمی را که ممکن است در معرض برنامه هایی باشد که کاربر روی دستگاه نصب می کند، حذف می کند.

APIهای Framework همچنین تضمین می‌کنند که Vault‌ها فقط برای کلیدهای عمومی همگروهی ایجاد می‌شوند که توسط ریشه اعتماد تأیید شده‌اند. ریشه اعتماد هنگام ارسال توسط OEM در Framework قرار می گیرد و بدون به روز رسانی سیستم عامل قابل تغییر نیست. این اطمینان را ایجاد می کند که LSKF فقط برای ایجاد Vault هایی استفاده می شود که به درستی محافظت های بروت فورس مبتنی بر سخت افزار را اعمال می کند. با تکیه بر THM ها در سرویس Cloud Key Vault برای محافظت از نیروی brute force برای LSKF، می‌توانیم به امنیت قابل مقایسه با استفاده از سخت‌افزار ایمن در دستگاه برای همان کار (مانند دستگاه‌های Google Pixel 2) دست یابیم.

از آنجایی که فرض نمی‌کنیم LSKF در هر نقطه‌ای از دستگاه خارج از سخت‌افزار امن ذخیره می‌شود، یک Vault جدید فقط بلافاصله پس از باز کردن قفل دستگاه ایجاد می‌شود. در زمانی که کاربر برای باز کردن قفل دستگاه وارد LSKF می شود، LSKF به طور خلاصه در RAM در اختیار Framework قرار می گیرد. آن لحظه ای است که API جدید برای ایجاد Vault از آن استفاده می کند. زمانی که دستگاه قفل است، امکان ایجاد یک Vault جدید محافظت شده از LSKF وجود ندارد، زیرا LSKF در دسترس نیست.

ایمن سازی عامل بازیابی

حفاظت امنیتی اولیه ای که ما در Recovery Agent ارائه می کنیم این است که پروتکل برای جلوگیری از دیدن LSKF دستگاه فعلی یا هر کلید بازیابی توسط Recovery Agent طراحی شده است. فقط Framework باید آن چیزها را در سمت کلاینت ببیند، و بهره برداری از هر گونه اشکال بالقوه یا آسیب پذیری امنیتی در Recovery Agent را بسیار سخت تر می کند. Recovery Agent بیشتر برای مدیریت رویدادهای چرخه حیات و ارسال داده ها بین Cloud و Framework استفاده می شود. تنها استثنا در این مورد در طول بازیابی درست قبل از پروتکل باز کردن Vault اتفاق می‌افتد، زمانی که کاربر باید LSKF دستگاه قدیمی را وارد کند - رابط کاربری که LSKF ادعا شده را برای دستگاه قدیمی جمع‌آوری می‌کند در Recovery Agent ⁴ پیاده‌سازی می‌شود. با این حال، پیاده سازی Recovery Agent LSKF ادعا شده را به محض اینکه Framework ساخت Recovery Claim را بر عهده گرفت، "فراموش" می کند.

ویژگی های امنیتی پروتکل

در حالی که تجزیه و تحلیل کامل پروتکل خارج از محدوده این سند است، ما می خواهیم چند مورد از محافظت های داخلی پروتکل را برجسته کنیم. به طور خاص، پروتکل فقط از هش LSKF در سراسر استفاده می کند. این به این معنی است که اگر LSKF آنتروپی بالایی داشته باشد (مثلاً اگر یک رمز عبور خوب با آنتروپی بالا باشد)، ذخیره Vault کاملاً بهتر از ذخیره سازی هش رمز عبور است و در این مورد هش رمز عبور می تواند معیاری از امنیت را مستقل از امنیت THM ها به همین دلیل، ما از هش "حافظه سخت" LSKF به عنوان بخشی از پروتکل پشتیبانی می کنیم. ما همچنین به صورت رمزنگاری Vault را به یک شناسه برای دستگاهی که آن را ایجاد کرده است وصل می کنیم و ادعای بازیابی را به nonce متصل می کنیم که به عنوان چالش در پروتکل باز کردن Vault استفاده می شود تا اطمینان حاصل شود که ادعای بازیابی تازه است.

از آنجایی که Recovery Key به تازگی در هر ایجاد Vault ایجاد می شود، ما چرخش کلید را با بازنویسی یک ورودی Vault موجود با یک Vault جدید ایجاد می کنیم. آدرس شمارنده تلاش ناموفق مورد استفاده توسط Vault در حین ایجاد Vault انتخاب می‌شود، و چارچوب تضمین می‌کند که آدرس شمارنده استفاده‌شده برای هر خرک بعدی تغییر نخواهد کرد، مگر اینکه LSKF تغییر کرده باشد یا لیست تأیید شده جدیدی از Cohort Public وجود داشته باشد. کلیدها بنابراین، چرخش کلید بازیابی را می توان بدون آسیب رساندن به محافظ نیروی brute force برای LSKF انجام داد.

امنیت سرور برای سرویس Cloud Key Vault

سرور با استفاده از ترکیبی از نرم افزارهای اجرا شده بر روی سخت افزار سرور معمولی و سیستم عامل اجرا شده بر روی سخت افزار تخصصی (تراشه Titan) پیاده سازی می شود. ما حفاظت های ارائه شده در هر لایه را شرح خواهیم داد.

حفاظت های سخت افزاری

حفاظت امنیتی اولیه که در سمت سرور سرویس CKV اجرا می‌شود، ماژول‌های سخت‌افزار مورد اعتماد (THM) هستند که با استفاده از تراشه‌های Titan طراحی‌شده سفارشی خود گوگل ساخته می‌شوند. تراشه‌ها سیستم‌افزاری را اجرا می‌کنند که APIهای لازم برای اجرای پروتکل‌های CKV را در معرض دید قرار می‌دهد. به طور خاص، آنها می توانند یک جفت کلید را با سایر اعضای همگروه خود ایجاد کرده و به طور ایمن به اشتراک بگذارند به طوری که منطق سیستم عامل از کلید خصوصی در برابر نشت در خارج از تراشه های Titan در گروه محافظت می کند. آن‌ها همچنین می‌توانند عملیات باز کردن خرک را انجام دهند، و شمارشگر تلاش‌های ناموفق را به شدت افزایش دهند (جایی که شمارنده توسط حالت ذخیره شده در تراشه Titan پشتیبانی می‌شود). شرح مفصل تری از پروتکل اجرا شده توسط سیستم عامل تراشه CKV Titan در نسخه آینده این سند ارائه خواهد شد.

با توجه به اینکه امنیت سرور از منطق سیستم عامل موجود در تراشه‌های Titan ناشی می‌شود، باید اطمینان حاصل کنیم که منطق به گونه‌ای تغییر نمی‌کند که به تراشه‌ها اجازه افشای اسرار یا نادیده گرفتن محدودیت‌های شمارنده را بدهد. برای دستیابی به این هدف، ما بوت لودر Titan را نیز تغییر می دهیم تا اطمینان حاصل شود که داده های ذخیره شده تراشه (مانند کلید خصوصی برای Cohort) قبل از اعمال هر به روز رسانی به طور کامل پاک می شوند. نقطه ضعف این محافظت این است که نمی‌توانیم باگ‌ها را بدون از دست دادن داده‌ها در میان‌افزار برطرف کنیم – به‌روزرسانی سیستم‌افزار از نظر عملکردی معادل از بین بردن سخت‌افزار موجود و جایگزینی آن با تراشه‌های جدید است. در صورتی که به یک وصله سیستم عامل حیاتی نیاز باشد، گوگل باید یک لیست کاملاً جدید از کلیدهای عمومی همگروه تایید شده تولید و منتشر کند و به تدریج همه کاربران را به لیست جدید منتقل کند. برای کاهش این خطر، ما سعی می‌کنیم پایگاه کد میان‌افزار را نسبتاً به حداقل برسانیم و آن را برای هر گونه مشکل امنیتی احتمالی بررسی کنیم.

حفاظت های نرم افزاری

علاوه بر محدودیت‌های سخت در هر خرک که توسط THMها اعمال می‌شود، سرویس CKV محدودیت نرخ مبتنی بر نرم‌افزار را نیز پیاده‌سازی می‌کند. محدودیت نرخ برای جلوگیری از ورود یک هکر به حساب کاربر و رفع سریع محدودیت تلاش‌های بازیابی ناموفق طراحی شده است، و به طور موثر دسترسی کاربر واقعی به کلیدهای بازیابی را قفل می‌کند. مشابه تأخیرهای زمانی اعمال شده توسط دستگاه کاربر پس از تلاش‌های ناموفق بیش از حد برای باز کردن قفل صفحه، سرویس CKV پس از هر درخواست ناموفق بعدی برای باز کردن قفل صفحه، تأخیر زمانی فزاینده‌ای را اعمال می‌کند.

ما همچنین اقدامات امنیتی استانداردی را برای سرویس‌های Cloud که میزبان داده‌های کاربر هستند، از جمله کنترل‌های دسترسی دقیق، نظارت و ممیزی اجرا می‌کنیم.

مشخصات پروتکل تفصیلی

مشخصات پروتکل دقیق هنوز در حال انجام است، و این سند به‌روزرسانی می‌شود تا این جزئیات را همراه با انتشار کد مشتری در پروژه منبع باز Android در اواخر سال جاری شامل شود.

یادداشت ها