Ş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 korunmasını sağlayan bir bulut hizmeti açıklanmaktadır. Güvenli donanım, doğru bilgi faktörünü sağlamak için çok fazla sayıda başarısız deneme yapıldığında depolanan ş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 belge ile 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 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 tüm olası 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 makul bir minimum entropi gereksinimi 70 ila 80 bit civarında olabilir. Ne yazık ki kullanıcılar, bu miktarda entropi1 içeren şifreleri veya diğer sırları ezberleyip güvenilir bir şekilde hatırlamakta, özellikle de nadiren kullanılıyorlarsa çok zorlanırlar (ancak yüksek entropili şifrelerin sık kullanımı zor ve yorucudur). Bu durum bizi zor bir sorun teşkil ediyor: Bu sırrın kullanıcı tarafından muhtemelen hatırlanacak bir "bilgi faktörü" olmasını istiyorsak, gizli verileri şifreleme teknolojisiyle nasıl koruyabiliriz? Çeşitli nedenlerle, bu sorunun çözülmesi o kadar zordur ki Cloud depolama hizmetleri genellikle verileri yalnızca Bulut depolama alanı sağlayıcısının yönettiği gizli anahtarlarla şifreler. Bunun yerine, kullanıcının kendi sırrını hatırlaması gerekmez.
Kriptografik gizli anahtarlar 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ırrı ile korunan yüksek entropili bir "kurtarma anahtarı"nı depolamak için Cloud Key Vault (CKV) hizmeti kullanmaktır. CKV hizmeti, kurtarma anahtarını yalnızca insanların unutabileceği doğru sırrı bildiğini kanıtlayan bir tarafa verir. Unutulmaz sırlara karşı yapılan kaba kuvvet saldırıları, CKV hizmeti tarafından engellenebilir. Bu da sırların farkında olduğunu kanıtlamak için başarısız girişimlerin sayısına mutlak bir sınırlama getirir. 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ıma 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) kullanarak Cloud Key Vault hizmeti derleme yaklaşımımız açıklanmaktadır. CKV hizmeti için ilk uygulamamız, kurtarma anahtarlarını kullanıcının akıllı telefon kilidini açmak için kullanılan gizli PIN, şifre veya kaydırma kalıbı olan Kilit Ekranı Bilgi Faktörü (LSKF) ile koruyacak şekilde tasarlanmıştır. İnsanlar LSKF'lerini güvenle hatırlayabilir. Aynı zamanda, bu tür LSKF gizli anahtarları, genellikle çok sınırlı sayıda deneme hakkı olan bir saldırgana karşı yeterli entropiye sahiptir ve bu nedenle CKV hizmeti için uygundur.
Cloud Key Vault hizmetimizin ilk uygulaması, istemci tarafında şifrelenmiş Android yedeklemelerini etkinleştirmek olacak. Önceden, Android cihazda yerel olarak şifrelenen dosyalar kullanıcının LSKF ile korunan bir anahtarı kullanıyordu. Ancak Cloud'da depolanan (ve şifrelenen) bu dosyaların yedekleri LSKF ile korunmuyordu. İlk kez Cloud Key Vault, Cloud'da depolanan Android yedekleri için kilit ekranı korumasını da etkinleştiriyor. Bu, Google sunucularının şifrelenmiş yedeklerin içeriğine erişemeyeceği veya bu yedeklerin içeriğine geri yüklenemeyeceği anlamına gelir. Yedeklerin şifresini yalnızca kullanıcının LSKF'sine sahip 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 belgenin tamamında istemciden söz ettiğimizde Google Play hizmetlerine sahip Android 9 Pie işletim sistemini çalıştıran bir cihazdan bahsediyoruz. Sunucu tarafı uygulamamız, ekstra 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 ve 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ırız.
CKV hizmeti, donanım arızaları (ör. eskimiş ç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çeklenmelidir. Bu nedenle, üzerinde Titan çipleri bulunan sunucular kohortlar halinde düzenlenir. Her kohortta, her biri aynı anahtar materyalinin bir kopyasını içeren birkaç bağımsız THM bulunur. Belirli bir kohort, sistemin kullanılabilirlik ve güvenilirlik hedeflerini karşılayabilmesini sağlamak için farklı bakım alt bölgelerindeki fiziksel olarak farklı veri merkezlerine dağıtılır. Ölçeklenebilirlik için istemciler bir dizi farklı kohorta ayrılır. Böylece mevcut kohort 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 numaralandırmaya hazırız.
Mimari Bileşenler / Sözlük
Kilit Ekranı Bilgi Faktörü (LSKF): Kısa bir PIN, 3 x 3 noktalı ı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 bir şekilde 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'lere atıfta bulunmak 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 cihazında (veya benzeri cihazlarda) kullanıcı alanında Google Play hizmetlerinin bir parçası olarak çalışan bir sistem uygulaması. 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 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 Talebi oluşturmalıdır. Genellikle kullanıcıdan eski cihazının Kurtarma Anahtarı'na erişmeye çalışan yeni bir cihaza eski cihazının LSKF kodunu girmesi istenir.
Kurtarma Anahtarı: Cloud Key Vault hizmeti tarafından korunan ve İstemci cihazındaki verileri şifrelemek (ve kimliklerini doğrulamak) için kullanılan bir şifreleme gizli anahtarı. Kurtarma Anahtarı, Apps Kasası'na yerleştirildikten sonra (aşağıya bakın) İstemci, verileri şifrelemek için bu anahtarı kullanarak işini bitirir bitirmez yerel kopya silinebilir.
Cloud Key Vault (CKV) Hizmeti: İstemci cihazlarının, kullanıcıların akılda kalıcı LSKF ile korunan şifreleme anahtarlarını depolamasını sağlayan 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 bir anahtar çiftinin ortak anahtarı. İlgili özel anahtar, yalnızca anahtar oluşturma sırasında Kohortta 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). Güvenlik unsuru en azından gizli anahtarlar oluşturup/veya depolayabilmeli ve değişken olmayan bir değişim durumunu sürdürebilmelidir (böylece önceki bir duruma sıfırlama içeren saldırıları önleyebilir).
Apps Kasası: CKV Hizmeti veritabanında, tek bir cihazın LSKF korumalı Kurtarma Anahtarı'nı içeren belirli bir giriş. Bir son kullanıcının dosyada her biri farklı bir cihaza veya LSKF'ye karşılık gelen birden fazla Apps Kasası olabilir. Yalnızca Apps Kasası Sunucusundaki THM, Apps Kasası içeriğini 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
Sistemi ilk kullanıma hazırlamak için Google, Çerçeve'nin Google'ın donanım onaylarını doğrulamak amacıyla kullanacağı "güven kökü" için bir ortak anahtar sağlar. Bu güven kökünün imzalama anahtarı çevrimdışı olarak saklanır ve oturum açmak için birden fazla çalışanın katılımını gerektirecek şekilde dikkatli bir şekilde güvenceye alınır. Bu güven kökünün ortak anahtarı Android işletim sisteminde bulunur ve yalnızca işletim sistemi güncellemesi yoluyla değiştirilebilir.
Google ayrıca listedeki bir onayla birlikte her THM Grubu için düzenli aralıklarla genel anahtarlar listesi yayınlar. Listedeki onay, tekrar güven köküne bağlanan bir imza kullanır. Yayınlanan listenin her güncellemesi bir sıra numarası da içerir. Böylece geri almaları önlemek 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ılacak listeden rastgele bir Kohort Ortak Anahtarı seçer.
Apps Kasası Oluşturma
Kohort Genel Anahtarları listesini getirerek Çerçevenin Başlatmayı tamamlamasına yardımcı olduktan sonra, Kurtarma Aracısı, Çerçeveden yeni bir Apps Kasası oluşturmasını ister. LSKF'nin kullanıcı tarafından bir sonraki girişinde Çerçeve yeni bir Kurtarma Anahtarı oluşturur. Bunu, önce LSKF'nin karmasından elde edilen bir anahtarla ve 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 daha sonra Google'ın CKV hizmetine yükleyen Apps Kasası'dır.
Apps Kasası Açma
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. Daha sonra Kurtarma Aracısı, Çerçeveden bu LSKF'yi kullanarak bir Kurtarma Talebi oluşturmasını ister. Çerçeve yeni bir Talep Sahibi Anahtarı oluşturur ve hem bu Talep Sahibi Anahtarı'nı hem de hak talebinde bulunulan LSKF'nin karmasını, 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. Ardından Apps Kasası Sunucularındaki THM, Kurtarma 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 (Talep Sahibi Anahtarı) ile yeniden şifreler. Aksi takdirde THM, başarısız deneme sayacını dokundurur. Başarısız deneme sayacı sınırına ulaştığında THM, bu Apps Kasası için sonraki Kurtarma Taleplerini işlemeyi reddeder.
Son olarak, her şey yolunda giderse yeniden şifrelenen Kurtarma Anahtarı (artık Talep Sahibi Anahtarı altında şifrelenmektedir) Apps Kasası Sunucusu'ndan Çerçeve'ye kadar geri gönderilir. Çerçeve, Kurtarma Anahtarı'nın şifresini çözmek için Hak Talebi Sahibi Anahtarı'nın kopyasını kullanır ve protokol tamamlandı.
Güvenlik Önlemleri
Cloud Key Vault sistemi, yığınımızın birden çok düzeyine güvenlik korumaları ekleyerek "derinlemesine savunma" sağlamayı amaçlar. Bu korumaların işleyişi hakkında fikir vermek için İstemci'yi açıklayarak başlayacağız ve yığını Cloud Key Vault Service'e yükselteceğiz.
İstemci Güvenliği
Belirli bir OEM ve cihaza bağlı olarak Kilit Ekranı Bilgi Faktörü (LSKF) normalde OEM'ye göre değişiklik gösteren çeşitli yöntemler kullanılarak cihazda depolanır ve korunur. Örneğin, Google'ın Pixel 2 cihazları, kullanımda olmayan LSKF'yi depolamak ve LSKF doğrulamasında donanım tabanlı hız sınırlamaları uygulamak için değişikliklere karşı korumalı bir donanım güvenlik modülü kullanır. Cloud Key Vault kullanımını mümkün kılmak amacıyla kullanıma sunulan yeni Framework API'leri, cihaz LSKF depolama alanını korumak için bu tür 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.
LSKF ile ilişkili tüm güvenlik mekanizmalarını eksiksiz şekilde göstermeye çalışmak yerine, bu bölümde özellikle 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 Framework API'leri @SystemApi olarak işaretlenmiştir ve bu API'lerin yalnızca Google Play Hizmetleri gibi OEM onaylı sistem uygulamalarında kullanılabilmesini sağlayan özel izinler gerektirir. Bu, kullanıcının cihaza yüklediği uygulamaların maruz kalabileceği doğrudan saldırı yüzeylerini büyük ölçüde ortadan kaldırır.
Çerçeve API'leri, Apps Kasası'nın yalnızca bir güven kökü tarafından onaylanan Kohort Genel Anahtarları için oluşturulmasını da sağlar. Güven kökü, gönderildikten sonra OEM tarafından Çerçeveye eklenir ve OS güncellemesi olmadan değiştirilemez. Böylece LSKF'nin yalnızca donanım tabanlı kaba kuvvete karşı korumaları düzgün bir ş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 (Google Pixel 2 cihazlarda olduğu gibi) güvenlik sağlayabiliriz.
LSKF'nin güvenli donanımlar dışında cihazda herhangi bir yerde saklanacağını varsaymadığımız için yeni bir Apps Kasası yalnızca cihaz kilitlendikten hemen sonra oluşturulabilir. Kullanıcı cihazın kilidini açmak için LSKF'ye girdiğinde, LSKF kısa bir süre için RAM'de Çerçeve'ye sunulur. Apps Kasası'nı oluşturmak için kullanılan yeni API, bu noktada söz konusu API'yi kullanır. LSKF kullanılamadığından, cihaz kilitliyken yeni 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 mevcut cihazın LSKF'sini veya herhangi bir Kurtarma Anahtarını görmesini önleyecek şekilde tasarlanmasıdır. İstemci tarafında bu öğeleri yalnızca Çerçeve görmelidir. Bu nedenle, Kurtarma Aracısı'ndaki olası hatalardan veya güvenlik açıklarından yararlanmanız çok daha zor hale gelir. Kurtarma Aracısı çoğunlukla yaşam döngüsü olaylarını yönetmek ve verilerin Cloud ile Çerçeve arasında iki yönlü aktarımını yönetmek için kullanılır. Bunun tek istisnası, Apps Kasası Açma protokolünden hemen önceki kurtarma işlemleri sırasında yaşanır. Bu aşamada 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 uygulanır. Ancak Çerçeve, Kurtarma Talebi oluşturma işlemini 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. Yani, LSKF yüksek entropiye sahipse (ö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çümü sağlayabilir. Bu nedenle, protokolün bir parçası olarak LSKF'nin tuzlu "belleğe sert" karma oluşturma işlemi yapılmasını destekliyoruz. Ayrıca, Apps Kasası'nı onu oluşturan cihazın tanımlayıcısına kriptografik olarak bağlarız ve Kurtarma Hak Talebi'nin güncel olduğundan emin olmak için Apps Kasası Açılış protokolü sırasında sorgulama olarak kullanılan tek seferlik bir tek seferlik kurtarma talebine bağlarız.
Kurtarma Anahtarı, her Apps Kasası oluşturma işleminde yeni oluşturulduğundan, yeni oluşturulan bir Apps Kasası ile mevcut bir Apps Kasası girişinin üzerine yazarak anahtar rotasyonu 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ış yeni bir Kohort Ortak Anahtarları listesi olmadığı sürece sonraki Apps Kasası'lar 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 ile ö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 tasarım Titan çipleri kullanılarak oluşturulmuş Güvenilir Donanım Modülleri'dir (THM'ler). Çipler, CKV protokollerini uygulamak için gerekli API'leri açığa çıkaran 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ı önlemek için bir anahtar çifti oluşturabilir ve bu çifti grubun diğer üyeleriyle güvenli bir şekilde paylaşabilir. Ayrıca, Apps Kasası Açma işlemini gerçekleştirebilir ve başarısız denemeler için Apps Kasası başına kesinlikle artan bir sayacı koruyabilirler (Sayaç, Titan çipinde depolanan durumla 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 çiplerinin 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 depolanan verilerinin (Kohort için özel anahtar gibi) tamamen silinmesini sağlamak için Titan önyükleme yükleyicisini de değiştiririz. Bu korumanın olumsuz tarafı, veri kaybı yaşamadan donanım yazılımındaki hataları düzeltemememizdir. 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 Genel 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 minimum 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 sabit kasa başına hata sınırlarına ek olarak yazılım tabanlı hız sınırlaması uygular. Hız sınırlaması, saldırganların bir kullanıcının hesabına girmesini ve başarısız kurtarma denemelerinin sınırını hızla tüketmesini, böylece gerçek kullanıcının Kurtarma Anahtarlarına erişimini etkin bir şekilde kilitlemesini önlemek için tasarlanmıştır. CKV hizmeti, ekranın 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, sonraki her başarısız Apps Kasası Açma isteğinin ardından artan bir gecikme süresi uygular.
Kullanıcı verilerini barındıran Cloud hizmetleri için sıkı erişim denetimleri, izleme ve denetleme gibi standart güvenlik önlemleri de uygularız.
Ayrıntılı Protokol Spesifikasyonu
Ayrıntılı protokol spesifikasyonu halen devam etmektedir. Bu belge, önümüzdeki aylarda istemci kodunun Android Açık Kaynak Projesi'nde yayınlanmasıyla birlikte bu ayrıntıları da içerecek şekilde güncellenecektir.
Notlar
- "İnsan Belleğinde 56 Bit Sırların Güvenilir Olarak Depolanması | USENIX." 1 Ağustos 2014, https://www.usenix.org/node/184458. ↩
- "Google Cloud Platform Blog: Derinlemesine Titan: Şifrelenmemiş metinde güvenlik." 24 Ağustos 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in- deep-security-in-plaintext.html. ↩
- "Google, Android cihazlarda aylık 2 milyardan fazla etkin cihazı olduğunu ......" 17 Mayıs. 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users. ↩
- Bu sayede, başka bir cihazın LSKF'sini girmek için esnek kullanıcı arayüzleri sağlayabiliriz. Mevcut cihazın çerçevesinde, eski cihazın LSKF'sini girmek için uygun bir kullanıcı arayüzü olmayabilir.↩