Google Cloud Key Vault Hizmeti

Şifreleme anahtarlarını depolamak için güvenli donanım kullanan ve bu anahtarlara erişimin düşük entropi bilgi faktörü (ör. kilit ekranı PIN'i) ile korunduğu bir bulut hizmeti tanımladık. Güvenli donanım, doğru bilgi faktörünü sağlamak için çok sayıda başarısız denemeden sonra saklanan şifreleme anahtarlarını kalıcı olarak geri alınamaz hale getirerek kaba kuvvet saldırılarını önlemek üzere tasarlanmıştır.

Yazar: Shabsi Walfish
Sürüm Tarihi: 06.03.2018

Not: Bu belgeyle ilgili çalışmalar devam etmektedir ve uygulama ile ilgili ayrıntılar henüz kesinleşmemiştir. Sistem dengeli hale geldikçe ve daha fazla belge üretildikçe bu teknik belgeyi daha ayrıntılı bilgilerle (özellikle de ilgili açık kaynak sürümleriyle birlikte) güncelleyeceğiz.

Genel bakış

Geleneksel olarak, şifrelemede (veri gizliliğini sağlamak için kullanılır) saldırganın bakış açısından yüksek entropiye sahip gizli anahtarların kullanılması gerekir. Şifreleme şemasının, doğru gizli anahtar bulunana kadar olası tüm gizli anahtarların alanını araştıran kaba kuvvet saldırılarına direnmesi gerektiğinden yüksek entropi gereklidir. Günümüzde bilgi işlem gücünün mevcut olduğu göz önünde bulundurulduğunda, kriptografik gizli anahtarlar için minimum entropi gereksinimi 70 ila 80 bit civarında olabilir. Ne yazık ki kullanıcılar, bu miktarda entropi içeren şifreleri veya diğer sırları, özellikle de nadiren kullanılıyorlarsa ezberlemek ve güvenilir bir şekilde hatırlamak çok zor olur1 (ancak yüksek entropili şifrelerin sık kullanımı zor ve yorucudur). Bu durum bizi bekleyen bir sorun oluşturuyor: Gizli verilerin kullanıcıların hatırlayabileceği bir "bilgi faktörü" olmasını istiyorsak bu verileri şifreleme teknolojisiyle nasıl koruyabiliriz? Çeşitli nedenlerle bu sorunun çözülmesi çok zordur. Bu nedenle Cloud depolama hizmetleri, kullanıcının sırrını hatırlamasına güvenmek yerine verileri genelde yalnızca Cloud depolama sağlayıcısı tarafından yönetilen gizli anahtarlarla şifreler.

Şifreleme sırları ile kullanıcıların akılda kalıcı sırları arasındaki boşluğu kapatmaya yönelik yaklaşımlardan biri, düşük entropili kullanıcıların akılda kalıcı sırlarıyla korunan yüksek entropili bir "kurtarma anahtarı"nı depolamak için bir Cloud Key Vault (CKV) hizmeti kullanmaktır. CKV hizmeti, kurtarma anahtarını yalnızca insanın akılda kalıcı doğru sırrını bildiğini kanıtlayan bir tarafa verir. İnsanların unutulmaz sırrına karşı yapılan kaba kuvvet saldırıları CKV hizmeti tarafından engellenebilir. CKV hizmeti, sırrı bildiğini kanıtlamak için yapılan başarısız girişimlerin sayısını kesin bir şekilde sınırlandırır. Kurtarma anahtarının kendisi, her yerde güvenli bir şekilde saklanabilen büyük hacimli verileri (disk yedeği gibi) kolayca şifreleyebilen (kimliği doğrulanmış) bir şifreleme şemasıyla kullanılmaya uygun standart bir şifreleme simetrik anahtarıdır. Bu tür şifrelenmiş veriler, kurtarma anahtarını alamayan kişilere fayda sağlamaz.

Bu teknik belgede, Güvenilir Donanım Modülleri (THM'ler) kullanarak Cloud Key Vault hizmeti oluşturma yaklaşımımız açıklanmaktadır. CKV hizmetine ilişkin ilk uygulamamız, kurtarma anahtarlarını kullanıcının Kilit Ekranı Bilgi Faktörü (LSKF) ile korumak için tasarlanmıştır. Bu bilgi, akıllı telefonların kilidini açmak için kullanılan gizli PIN, şifre veya kaydırma kalıbıdır. İnsanlar LSKF'lerini güvenilir bir şekilde hatırlayabilir. Aynı zamanda, bu tür LSKF gizli anahtarları genellikle çok sınırlı sayıda girişimi olan bir saldırgana direnmeye yetecek kadar entropiye sahiptir; bu da CKV hizmetine uygundur.

Cloud Key Vault hizmetimizin ilk uygulaması, istemci tarafında şifrelenmiş Android yedeklemelerini etkinleştirmek olacak. Daha önce, Android cihazda yerel olarak şifrelenen dosyalar kullanıcının LSKF ile korunan bir anahtarını kullanıyordu. Ancak bu dosyaların bulutta depolanan (ve şifrelenen) yedekleri LSKF ile korunmuyordu. Cloud Key Vault ilk kez Cloud'da depolanan Android yedekleri için de kilit ekranı koruması özelliğini etkinleştirmektedir. Yani Google sunucuları, şifrelenmiş yedeklerin içeriğine erişemez veya bu içerikleri geri yükleyemez. Yedeklerin şifresini yalnızca kullanıcının LSKF'si olan bir cihaz çözebilir.

Temel Kavramlar

Başlangıçta Cloud Key Vault hizmeti için desteklenen tek istemci platformu Android 9 Pie işletim sistemidir. Bu teknik belgede istemciden bahsettiğimizde Google Play hizmetlerine sahip Android 9 Pie işletim sistemini çalıştıran bir cihazdan bahsediyoruz. Sunucu tarafı uygulamamız, ek bir Titan çipi2 yüklü olan, özel olarak tanımlanmış Google sunucularında çalışır. Google tarafından tasarlanan Titan çipi, Güvenilir Donanım Modülümüzde donanım bileşeni görevi görür. Titan çipi, protokollerimizi ve güvenlik uygulama mekanizmalarımızı (burada açıklandığı gibi) uygulayan özel bir bootloader ve donanım yazılımı sağlar. Protokolümüzün gerçekten Titan donanımı üzerinde çalıştığından emin olmak için donanım onayı teknikleri kullanıyoruz.

CKV hizmeti, donanım arızaları (ör. bitmiş çipler) nedeniyle önemli miktarda kullanıcı verisi kaybetmeden veya veri merkezi bakımı nedeniyle uzun süreli kesinti yaşanmadan milyarlarca3 Android cihazdan gelen trafiği yönetecek şekilde ölçeklendirilmelidir. Bu nedenle, Titan çiplerinin bulunduğu sunucular kohortlar halinde düzenlenmiştir. Her kohort, aynı anahtar materyalinin bir kopyasını içeren birkaç bağımsız THM'den oluşur. Belirli bir kohort, sistemin kullanılabilirlik ve güvenilirlik hedeflerini karşılayabilmesini sağlamak için farklı bakım bölgelerindeki fiziksel olarak farklı veri merkezlerine dağıtılır. Ölçeklenebilirlik için istemciler, birkaç farklı kohorta dahil edilir. Böylece kullanılabilir kohortların sayısını artırmak için yalnızca daha fazla sunucu ekleyerek hizmetin kapasitesini ayarlayabiliriz.

Artık Cloud Key Vault hizmet mimarisinin ana bileşenlerini sıralamaya hazırız.

Mimari Bileşenler / Sözlük

Kilit Ekranı Bilgi Faktörü (LSKF): Kısa bir PIN, 3 x 3 noktalı bir ızgara üzerinde kaydırma deseni veya şifre gibi akılda kalıcı bir sır. Bu gizli anahtar, cihazın kilidini yerel olarak açma yeteneğini korumak için kullanılır ve kullanıcının yerel cihaz ekran kilidi için birincil (veya "güçlü") kimlik doğrulama faktörü olarak kabul edilir.

İstemci: Android 9 Pie işletim sistemini ve Google Play Hizmetleri'ni veya eşdeğer desteklenen yazılımları çalıştıran bir son kullanıcı cihazı.

Android Framework: Bu genel terimi (veya sadece Çerçeveyi) Android 9 Pie veya sonraki sürümlerdeki API'leri belirtmek için kullanırız. Bu terimin, daha önceki sürümleri belirtmesi amaçlanmamıştır.

Google Play hizmetleri: Son kullanıcı cihazında çalışan, Google'ın hesap sistemi ve özel sunucu API'leriyle çalışmasını sağlayan hizmetler ve uygulamalar koleksiyonu.

Kurtarma Aracısı: Android 9 Pie cihazlarda (veya benzeri cihazlarda) kullanıcı alanında Google Play Hizmetleri kapsamında çalışan bir sistem uygulamasıdır. Kurtarma Aracısı, çeşitli protokollerin İstemci tarafını yürütmekten ve LSKF'yi içeren protokol mesajlarını oluşturmak için gerektiğinde Android İşletim Sistemi ile arayüz oluşturmaktan sorumludur.

Kurtarma Hak Talebi: Kullanıcı, Kurtarma Anahtarı'nı almak istediğinde, kullanıcının bildiğini iddia ettiği LSKF'nin şifrelenmiş bir kopyasını içeren bir Kurtarma Hak Talebi oluşturmalıdır. Genellikle kullanıcıdan, eski cihazın Kurtarma Anahtarı'na erişmeye çalışan yeni bir cihazda eski cihazının LSKF kodunu girmesi istenir.

Kurtarma Anahtarı: Cloud Key Vault hizmeti tarafından korunan ve istemci cihazındaki verileri şifrelemek (ve kimliklerini doğrulamak) için kullanılan şifreleme gizli anahtarı. Kurtarma Anahtarı bir Apps Kasası'na yerleştirildikten (aşağıya bakın) sonra, istemci bu anahtarı kullanarak verileri şifreleme işlemini tamamladığı anda yerel kopya silinebilir.

Cloud Key Vault (CKV) Hizmeti: İstemci cihazlarının, akılda kalıcı bir LSKF ile korunan şifreleme anahtarlarını depolamasına olanak tanıyan bir internet hizmetidir.

Grup: Birbirinin yedek kopyaları olarak hizmet verebilen Apps Kasası Sunucuları/THM'lerden oluşan bir koleksiyon.

Kohort Ortak Anahtarı: Belirli bir THM Grubu tarafından oluşturulan anahtar çiftindeki ortak anahtardır. İlgili özel anahtar, yalnızca anahtar oluşturma sırasında Kohort'ta bulunan THM'ler içinde kullanılabilir.

Güvenilir Donanım Modülü (THM): Minimum ve güvenilir bir bilgi işlem ortamı sağlamak için tasarlanmış özel bir güvenlik modülü (mikrodenetleyici). En azından, güvenli öğenin gizli anahtarlar oluşturabilmesi ve/veya depolayabilmesi ve değişken olmayan bazı değişim durumlarını koruyabilmesi gerekir (böylece, daha önceki bir duruma sıfırlama içeren saldırıları önleyebilmelidir).

Apps Kasası: CKV Hizmeti veritabanında, tek bir cihazın LSKF ile korunan Kurtarma Anahtarı'nı içeren belirli bir giriştir. Bir son kullanıcının, her biri farklı bir cihaza veya LSKF'ye karşılık gelen birden fazla Apps Kasası kayıtlı olabilir. Apps Kasası içeriğini yalnızca Apps Kasası Sunucusundaki THM inceleyebilir veya çıkarabilir.

Apps Kasası Sunucusu: Güvenilir Donanım Modülü (THM) eklemek için özel olarak donatılmış, bir Google veri merkezinde çalışan genel amaçlı bir makine.

Protokol Tasarımı

CKV protokolü aşağıdaki gibi birkaç aşamadan oluşur:

Başlatma

Google, sistemi başlatmak amacıyla Çerçeve'nin Google'ın donanım onaylarını doğrulamak için kullanacağı bir "güven kökü" için ortak anahtar sağlar. Bu güven kaynağının imzalama anahtarı çevrimdışı depolanır ve imzalamak için birden fazla çalışanın katılımını gerektirecek şekilde dikkatli bir şekilde saklanır. Bu güven kökünün ortak anahtarı Android OS'te yerleşik olarak bulunur ve yalnızca işletim sistemi güncellemesiyle değiştirilebilir.

Google ayrıca listedeki bir onayla birlikte her THM Grubu için genel anahtarların listesini düzenli aralıklarla yayınlar. Listedeki onay, güven köküne geri dönen bir imza kullanır. Yayınlanan listenin her güncellemesi bir sıra numarası da içerir. Böylece geri almaların önlenmesi mümkün olur. Kurtarma Aracısı, Kohort ortak anahtarlarının yayınlanan en son listesini getirir ve Çerçeve'ye sağlar. Çerçeve daha sonra onayı doğrular ve Apps Kasası Oluşturma aşamasında kullanılmak üzere listeden rastgele bir Kohort Ortak Anahtarı seçer.

Apps Kasası Oluşturma

Kohort Ortak Anahtarları listesini getirip Çerçevenin Başlatmayı tamamlamasına yardımcı olduktan sonra, Kurtarma Aracısı, Çerçeveden yeni bir Apps Kasası oluşturmasını ister. Kullanıcı tarafından LSKF'ye bir sonraki giriş yapıldığında Çerçeve yeni bir Kurtarma Anahtarı oluşturur. Bunu, önce LSKF'nin karmasından elde edilen bir anahtarla, ardından Başlatma sırasında Çerçeve tarafından seçilen Kohort Ortak Anahtarı ile şifreler. Ortaya çıkan şifrelenmiş blob, Çerçeve tarafından Kurtarma Aracısına geri aktarılan ve ardından Google'ın CKV hizmetine yükleyen Apps Kasası'dır.

Apps Kasası Açılışı

Yeni cihazdaki Kurtarma Aracısı'nın belirli bir Apps Kasası'nda depolanan Kurtarma Anahtarı'na erişmesi gerektiğinde, ilk olarak kullanıcıdan Apps Kasası'nı oluşturan orijinal cihazın LSKF'sini girmesi istenir. Kurtarma Aracısı, daha sonra Çerçeveden bu LSKF'yi kullanarak bir Kurtarma Hak Talebi oluşturmasını ister. Çerçeve yeni bir Talep Sahibi Anahtarı oluşturur ve bu Talep Sahibi Anahtarı'nın yanı sıra hak talebinde bulunulan LSKF'nin karma değerini, Apps Kasası'nın ilk olarak şifrelendiği Kohort Ortak Anahtarı ile şifreler. Ortaya çıkan şifrelenmiş blob Kurtarma Talebi olarak adlandırılır. Çerçeve, bunu Kurtarma Aracısı'na iletir ve daha sonra CKV hizmetine sunar.

CKV, Kurtarma Hak Talebi'ni (ve karşılık gelen Apps Kasası) doğru Kohortun parçası olan Apps Kasası Sunucularına yönlendirir. Apps Kasası Sunucularındaki THM, daha sonra Kurtarma Hak Talebi'nin şifresini çözer ve talep edilen LSKF karmasını kullanarak (iç şifreleme anahtarını elde etmek için) orijinal Apps Kasası'ndan Kurtarma Anahtarı'nı çıkarmaya çalışır. Orijinal LSKF karması ile talep edilen LSKF karması eşleşirse THM, Kurtarma Anahtarı'nı Apps Kasası'ndan çıkarır ve bunu Kurtarma Talebi'ndeki Claimant Key ile yeniden şifreler. Aksi takdirde THM, başarısız deneme sayacı iletir. Başarısız deneme sayacı sınırına ulaştığında THM, bu Apps Kasası için sonraki Kurtarma Hak Taleplerini işlemeyi reddeder.

Son olarak, her şey yolunda giderse yeniden şifrelenen Kurtarma Anahtarı (artık Hak Talebinde Bulunan Anahtarı altında şifrelenmiştir) Apps Kasası Sunucusu'ndan Çerçeve'ye kadar geri gönderilir. Çerçeve, Kurtarma Anahtarı'nın şifresini çözmek için Hak Talebinde Bulunan Anahtarı kopyasını kullanır ve protokol tamamlanmıştır.

Güvenlik Önlemleri

Cloud Key Vault sistemi, yığınımızın çeşitli seviyelerinde güvenlik korumaları dahil ederek "derinlemesine savunma" sağlamayı amaçlar. Bu korumaların işleyiş şekli hakkında bir fikir vermek için İstemci'yi açıklayarak başlayacağız ve grubu Cloud Key Vault Hizmeti'ne taşıyacağız.

İstemci Güvenliği

Kilit Ekranı Bilgi Faktörü (LSKF) normalde OEM'ye ve cihaza bağlı olarak saklanır ve OEM'ye göre değişiklik gösteren çeşitli yöntemler kullanılarak cihazda korunur. Örneğin, Google'ın Pixel 2 cihazları, aktif olmayan LSKF'yi depolamak ve LSKF doğrulamasında donanım tabanlı hız sınırları uygulamak için değişikliğe karşı korumalı bir donanım güvenlik modülü kullanır. Cloud Key Vault kullanımına olanak sağlamak için kullanıma sunulan yeni Çerçeve API'ler, cihaz LSKF'nin depolanmasını korumak için böyle bir donanım güvenlik modülü kullandığında bile mevcut güvenlik garantilerini mümkün olan en iyi şekilde koruyacak şekilde tasarlanmıştır.

Bu bölümde, LSKF ile ilişkili tüm güvenlik mekanizmalarını kapsamlı bir şekilde göstermeye çalışmak yerine, yeni Cloud Key Vault özelliğini etkileyen ilgili güvenlik sorunlarına ve korumalara odaklanacağız.

Çerçeve API'lerinin Güvenliğini Sağlama

CKV hizmetini desteklemek için eklenen yeni Çerçeve API'leri @SystemApi olarak işaretlenmiştir ve yalnızca Google Play Hizmetleri gibi OEM onaylı sistem uygulamalarında kullanılabilmesini sağlayan özel izinler gerektirir. Bu sayede, kullanıcının cihaza yüklediği uygulamaların maruz kalabileceği doğrudan saldırı yüzeyleri büyük ölçüde ortadan kalkar.

Çerçeve API'leri, Apps Kasası'nın yalnızca bir güven kökü tarafından onaylanmış Kohort Ortak Anahtarları için oluşturulmasını da sağlar. Güven kökü, gönderildikten sonra OEM tarafından Çerçeveye alınır ve OS güncellemesi olmadan değiştirilemez. Bu sayede LSKF'nin yalnızca donanıma dayalı kaba kuvvete karşı korumaları düzgün şekilde uygulayacak Apps Kasası'nı oluşturmak için kullanıldığından emin olabilirsiniz. LSKF'ye yönelik kaba kuvvet koruması için Cloud Key Vault hizmetindeki THM'lerden yararlanarak, aynı şey için cihazda güvenli donanım kullanmaya benzer bir güvenlik sağlayabiliriz (Google Pixel 2 cihazlarda olduğu gibi).

LSKF'nin güvenli donanım dışında cihazda herhangi bir yerde saklanacağını varsaymadığımızdan yeni bir Apps Kasası yalnızca cihazın kilidi açıldıktan hemen sonra oluşturulabilir. Kullanıcı, cihazın kilidini açmak için LSKF'ye girdiğinde, LSKF kısa bir süre RAM'de Çerçeve'ye sunulur. Apps Kasası'nı oluşturmak için kullanılacak yeni API bu noktada ondan yararlanır. LSKF kullanılamadığından cihaz kilitliyken yeni bir LSKF korumalı Apps Kasası oluşturulamaz.

Kurtarma Aracısının Güvenliğini Sağlama

Kurtarma Aracısı'nda sunduğumuz birincil güvenlik koruması, protokolün Kurtarma Aracısı'nın geçerli cihazın LSKF'sini veya Kurtarma Anahtarlarını görmesini önleyecek şekilde tasarlanmasıdır. İstemci tarafında bunları yalnızca Çerçeve görmelidir. Bu nedenle, Kurtarma Aracısı'ndaki olası hataları veya güvenlik açıklarını suistimal etmeyi çok daha zor hale getirir. Kurtarma Aracısı çoğunlukla yaşam döngüsü olaylarını ve verilerin Cloud ile Çerçeve arasında geçişini yönetmek için kullanılır. Bu durumun tek istisnası, Apps Kasası Açılış protokolünden hemen önceki kurtarma işlemi sırasında gerçekleşir. Bu protokol, kullanıcının eski cihazın LSKF'sini (eski cihaz için hak talebinde bulunulan LSKF'yi toplayan kullanıcı arayüzü), Kurtarma Aracısı'nda4 girmesi gerekir. Ancak Çerçeve Kurtarma Hak Talebi'nin oluşturulmasını devraldığı anda Kurtarma Aracısı uygulaması, hak talebinde bulunulan LSKF'yi "unutur".

Protokolün Güvenlik Özellikleri

Protokolün tam analizi bu belgenin kapsamı dışında olsa da protokolde yerleşik olan korumalardan birkaçını vurgulamak istiyoruz. Özellikle, protokol proje boyunca yalnızca LSKF'nin karmasını kullanır. Bu, LSKF'nin entropisi yüksekse (ör.yüksek entropili iyi bir şifreyse) Apps Kasası'nı saklamak, şifre karması depolamaktan kesinlikle daha iyidir. Bu durumda, şifre karması THM'lerin güvenliğinden bağımsız olarak bir güvenlik ölçüsü sağlayabilir. Bu nedenle, protokolün bir parçası olarak LSKF'nin tuzlu "belleğe sert" karma oluşturma işlemini destekleriz. Ayrıca, Apps Kasası'nı oluşturan cihazın tanımlayıcısına kriptografik olarak ve Kurtarma Hak Talebi'nin güncel olduğundan emin olmak için Apps Kasası Açma protokolü sırasında sorgulama olarak kullanılan bir tek seferlik rastgele sayıya bağlarız.

Kurtarma Anahtarı, her Apps Kasası oluşturma işleminde yeni oluşturulduğundan, mevcut bir Apps Kasası girişinin üzerine yeni oluşturulan bir Apps Kasası ile anahtar rotasyonu uygulayarak anahtar rotasyonunu uygularız. Apps Kasası tarafından kullanılan başarısız deneme sayacının adresi, Apps Kasası oluşturma işlemi sırasında seçilir ve Çerçeve, LSKF değiştirilmediği veya onaylanmış Kohort Ortak Anahtarları listesi mevcut olmadığı sürece sonraki Apps Kasası işlemleri için kullanılan sayaç adresinin değişmemesini sağlar. Böylece, Kurtarma Anahtarı'nın rotasyonu, LSKF'nin kaba kuvvet korumasına zarar vermeden yapılabilir.

Cloud Key Vault Hizmeti için Sunucu Güvenliği

Sunucu, normal sunucu donanımında çalışan yazılım ve özel donanım (Titan çipi) üzerinde çalışan donanım yazılımı kombinasyonu kullanılarak uygulanır. Her bir katmanda sunulan korumaları açıklayacağız.

Donanım korumaları

CKV hizmetinin sunucu tarafında uygulanan birincil güvenlik koruması, Google'ın kendi özel tasarlanmış Titan çipleri kullanılarak oluşturulan Güvenilir Donanım Modülleri'dir (THM'ler). Çipler, CKV protokollerini uygulamak için gerekli API'leri sunan bir donanım yazılımı çalıştırmaktadır. Özellikle, donanım yazılımı mantığı, özel anahtarın Kohort'taki Titan çiplerinin dışına sızdırılmasını önleyecek bir anahtar çifti üretip bunları Cohort'un diğer üyeleriyle güvenli bir şekilde paylaşabilir. Ayrıca, Apps Kasası Açma işlemini gerçekleştirebilir ve her bir Apps Kasası için başarısız deneme sayacını sıkı bir şekilde artırabilir (sayaç Titan çipinde kayıtlı duruma göre desteklenir). CKV Titan çipi donanım yazılımı tarafından yürütülen protokolün daha ayrıntılı bir açıklaması, bu belgenin gelecekteki bir sürümünde sunulacaktır.

Sunucu güvenliği Titan çiplerindeki donanım yazılımı mantığından kaynaklandığı için mantığın, çiplerin gizli anahtarları sızdırmasına veya sayaç sınırlarını göz ardı etmesine izin verecek şekilde değişmemesini sağlamalıyız. Bu hedefe ulaşmak amacıyla, herhangi bir güncelleme uygulanmadan önce çipin depolanmış verilerinin (Kohort için özel anahtar gibi) tamamen silindiğinden emin olmak için Titan önyükleme yükleyicisini de değiştiririz. Bu korumanın olumsuz tarafı, bir miktar veri kaybı yaşamadan donanım yazılımındaki hataları düzeltmeye çalışmamızdır. Donanım yazılımını güncellemek, işlevsel olarak mevcut donanımı yok etmek ve yeni çiplerle değiştirmekle eşdeğerdir. Kritik bir donanım yazılımı yaması gerektiğinde, Google'ın onaylanmış Kohort Ortak Anahtarları'ndan oluşan yepyeni bir liste oluşturup yayınlaması ve tüm kullanıcıları kademeli olarak yeni listeye taşıması gerekir. Bu riski azaltmak amacıyla donanım yazılımı kod tabanını olabildiğince asgari düzeyde tutmaya ve olası güvenlik sorunlarına karşı dikkatli bir şekilde denetlemeye çalışırız.

Yazılım korumaları

CKV hizmeti, THM'ler tarafından uygulanan katı Apps Kasası başına hata sınırlarına ek olarak, yazılım tabanlı hız sınırlaması da uygular. Hız sınırlaması, saldırganların bir kullanıcının hesabına girmesini ve başarısız kurtarma girişimi sınırını hızla tüketerek gerçek kullanıcının Kurtarma Anahtarlarına erişimini etkin bir şekilde kilitleyebilmesini sağlamak üzere tasarlanmıştır. Ekran kilidini açmak için çok fazla sayıda başarısız denemeden sonra kullanıcının cihazının uyguladığı süre gecikmelerine benzer şekilde, CKV hizmeti, sonraki başarısız Apps Kasası Açma isteklerinin her birinden sonra artan bir gecikme süresi uygular.

Ayrıca kullanıcı verilerini barındıran Cloud hizmetleri için katı erişim kontrolleri, izleme ve denetleme gibi standart güvenlik önlemlerini uygularız.

Ayrıntılı Protokol Spesifikasyonu

Ayrıntılı protokol spesifikasyonu halen devam etmektedir. Bu belge, bu yılın ilerleyen dönemlerinde istemci kodunun Android Açık Kaynak Projesi'nde yayınlanmasıyla birlikte, söz konusu ayrıntıları da içerecek şekilde güncellenecektir.

Notlar

  1. "Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX." 1 Ağustos 2014, https://www.usenix.org/node/184458.
  2. "Google Cloud Platform Blog: Derinlemesine Titan: Şifrelenmemiş metinde güvenlik." 24 Ağustos 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-deeplink-security-in-plaintext.html.
  3. "Google, her ay 2 milyardan fazla etkin cihazın Android'de ......" 17 Mayıs. 2017, https://www.theverge.com/2017/5/17/15654454/android-accesses-2-billion-month-active-users.
  4. Bu sayede, başka bir cihazın LSKF'sini girmek için esnek kullanıcı arayüzleri sağlayabiliriz. Mevcut cihazın çerçevesi, eski cihazın LSKF'sini girmek için uygun bir kullanıcı arayüzüne sahip olmayabilir.