Authentication

Android'de, cihazın kilidini açmak ve şifreleme anahtarlarına erişimi kontrol etmek için kullanılan kullanıcı kimlik doğrulayıcıları vardır. Bu işlem aşağıdaki bileşenleri içerir:

  • Şifreleme anahtarı depolama ve hizmet sağlayıcı. Şifreleme anahtarlarını depolar ve bu anahtarların üzerinde standart şifreleme rutinleri sağlar. Android, anahtar depolama için donanım destekli şifreleme de dahil olmak üzere kriptografik hizmetler için donanım destekli bir anahtar deposu ve KeyMint'i (eski adıyla Keymaster) destekler. Bu hizmetler, StrongBox gibi bir Güvenilir Yürütme Ortamı (TEE) veya Güvenli Öğeyi (SE) içerebilir.
  • Kullanıcı kimlik doğrulayıcıları. Kullanıcının varlığını ve/veya başarılı kimlik doğrulamasını onaylayın. Android, PIN/desen/şifre kimlik doğrulaması için Gatekeeper'ı ve parmak izi kimlik doğrulaması için parmak izi'ni destekler. Android 9 ve sonraki sürümlerle birlikte gelen cihazlar, parmak izi ve ek biyometrik veriler için tek bir entegrasyon noktası olarak BiometricPrompt'ı kullanabilir. Bu bileşenler, kimlik doğrulama durumlarını kimliği doğrulanmış bir kanal üzerinden anahtar deposu hizmetiyle paylaşır. (Çerçeve düzeyindeki Android anahtar deposu sistemi de anahtar deposu hizmeti tarafından desteklenir.)

Bu bileşenlerin her biri satıcıya özeldir ancak satıcı uygulaması, Donanım Soyutlama Katmanı (HAL) arayüzü spesifikasyonunu karşılamak ve ilgili satıcı test paketi (VTS) testlerini geçmek için gereklidir.

Tedarikçi uygulamaları da genellikle tedarikçiye özel bir iletişim mekanizmasıyla birbirine bağlanan iki bölüme ayrılır :

  • HAL hizmeti, Android sisteminden Binder istekleri alarak Android sistem süreci olarak çalışır.
  • Güvenilir uygulama (TA), güvenli ortamda çalışarak gerçek güvenli işlemleri gerçekleştirir.

Kayıt

Fabrika ayarlarına sıfırlama işleminden sonra cihaz ilk kez başlatıldığında, tüm kimlik doğrulayıcılar kullanıcının kimlik bilgisi kayıtlarını almaya hazırlanır. Kullanıcı, başlangıçta Gatekeeper (veya varsa Weaver) ile bir PIN, desen ya da şifre kaydetmelidir. Bu ilk kayıt işlemi, kullanıcı için tanımlayıcı ve kullanıcının kriptografik materyali için bağlama jetonu olarak işlev gören, rastgele oluşturulmuş 64 bitlik bir kullanıcı güvenli tanımlayıcısı (SID) oluşturur. Bu kullanıcı SID'si, kullanıcının şifresine kriptografik olarak bağlıdır. Gatekeeper'da başarılı kimlik doğrulamalar, bu şifrenin kullanıcı SID'sini içeren AuthToken'lar ile sonuçlanır.

Mevcut bir kimlik bilgisini değiştirmek isteyen kullanıcı, söz konusu kimlik bilgisini sunmalıdır. Mevcut bir kimlik bilgisi başarıyla doğrulanırsa mevcut kimlik bilgisiyle ilişkili kullanıcı SID'si yeni kimlik bilgisine aktarılır. Böylece kullanıcı, kimlik bilgisini değiştirdikten sonra da anahtarlara erişmeye devam edebilir.

Bazı durumlarda, cihaz yöneticisi mevcut bir kimlik bilgisi sunmadan yeni bir kimlik bilgisi kaydetmek için güvenilmeyen kayıt işlemi gerçekleştirebilir. Bu işlem, kullanıcının cihaza erişmesine olanak tanır ancak eski kullanıcı SID'si altında oluşturulan anahtarlar kalıcı olarak kaybolur.

Kimlik doğrulama

Bu bölümde, hem Android'deki hem de güvenli ortamdaki birden fazla bileşen arasındaki etkileşimleri içeren tipik bir kimlik doğrulama akışı açıklanmaktadır. Tüm güvenli bileşenlerin, birbirlerinin mesajlarını doğrulamak için kullandıkları (her yeniden başlatma için) gizli bir HMAC anahtarı paylaştığını unutmayın.

Kullanıcı bir kimlik bilgisi oluşturup kullanıcı SID'si atandıktan sonra kimlik doğrulama işlemine başlayabilir. Bu işlem, kullanıcının PIN, desen, şifre, parmak izi veya başka bir güçlü biyometrik bilgi sağlamasıyla başlar. Kimlik doğrulama akışı

1.şekil Kimlik doğrulama akışı

  1. Kullanıcı bir kimlik doğrulama yöntemi sağlar ve ilişkili hizmet, HAL hizmetine istekte bulunur.
    • PIN, desen veya şifre için LockSettingsService, gatekeeperd'ye istek gönderir.
    • Biyometri tabanlı kimlik doğrulama akışları Android sürümüne bağlıdır. Android 8.x ve önceki sürümlerin yüklü olduğu cihazlarda FingerprintService, fingerprintd için istekte bulunur. Android 9 ve sonraki sürümlerin yüklü olduğu cihazlarda BiometricPrompt, uygun BiometricManager sınıfını (ör. FingerprintManager veya FaceManager) kullanarak uygun biyometrik daemon'a (ör. parmak izi için fingerprintd veya yüz için faced) istekte bulunur. Sürümden bağımsız olarak, istek gönderildikten sonra biyometrik kimlik doğrulama işlemi eşzamansız olarak gerçekleşir.
  2. HAL hizmeti, verileri kendi karşılığı olan TA'ya gönderir. TA, AuthToken oluşturur:
    • PIN/desen/şifre kimlik doğrulaması için gatekeeperd, Gatekeeper HAL hizmeti aracılığıyla PIN, desen veya şifre karmasını TEE'deki Gatekeeper TA'ya gönderir. TEE'de kimlik doğrulama başarılı olursa Gatekeeper TA, ilgili kullanıcı SID'sini içeren bir AuthToken (paylaşılan HMAC anahtarıyla imzalanmış) yayınlar.
    • Parmak iziyle kimlik doğrulama için fingerprintd, parmak izi etkinliklerini dinler ve verileri Parmak İzi HAL'ı aracılığıyla TEE'deki Parmak İzi TA'sına gönderir. TEE'deki kimlik doğrulama başarılı olursa parmak izi TA'sı bir AuthToken (AuthToken HMAC anahtarıyla imzalanmış) yayınlar.
    • Diğer biyometrik kimlik doğrulama için uygun biyometrik daemon, biyometrik etkinliği dinler ve uygun biyometrik HAL hizmetine ve TA'ya gönderir.
  3. Daemon, imzalı bir AuthToken alır ve bunu anahtar deposu hizmetinin Binder arayüzüne yönelik bir uzantı aracılığıyla anahtar deposu hizmetine iletir. (gatekeeperd ayrıca cihaz yeniden kilitlendiğinde ve cihaz şifresi değiştiğinde de anahtar deposu hizmetini bilgilendirir.)
  4. Anahtar deposu hizmeti, AuthToken'ları KeyMint'e iletir ve bunları Gatekeeper ile paylaşılan anahtar ve desteklenen biyometrik TEE bileşeni kullanılarak doğrular. KeyMint, jetondaki zaman damgasını son kimlik doğrulama zamanı olarak kabul eder ve anahtar yayınlama kararını (bir uygulamanın anahtarı kullanmasına izin vermek için) zaman damgasına göre verir.

Kimlik doğrulama akışı, güvenli ortamdaki TA'lar arasında doğrudan iletişim gerektirmez: AuthToken'lar, kimlik doğrulayıcı TA'dan Android'deki keystore2 hizmetine akar ve bu hizmet de bunları KeyMint TA'ya iletir. Bu, sistemdeki mevcut AuthToken'lar hakkında bilgi sahibi olduğu için keystore2 hizmetinin başarısız olacak istekleri hızlıca reddetmesine de olanak tanır ve bu sayede TEE'ye potansiyel olarak maliyetli bir IPC kaydedilir.

AuthToken biçimi

AuthToken'ın biçimi, HardwareAuthToken.aidl adresindeki AIDL spesifikasyonuyla belirlenir.

Cihaz başlatma akışı

Bir cihaz her yeniden başlatıldığında AuthToken HMAC anahtarı oluşturulmalı ve tüm TEE bileşenleriyle (Gatekeeper, KeyMint ve desteklenen biyometrik trustlet'ler) paylaşılmalıdır. Bu nedenle, yeniden oynatma saldırılarına karşı ek koruma için HMAC anahtarının cihaz her yeniden başlatıldığında rastgele oluşturulması gerekir.

TA'lar bu paylaşılan HMAC anahtarına erişimi genellikle iki şekilde elde eder:

  • Paylaşılan gizli anlaşma: keystore2 hizmeti, cihaz başlatılırken çok yönlü bir anahtar anlaşma protokolü gerçekleştirir. Bu sayede, katılan TA'lar arasında HMAC anahtarının güvenli bir şekilde türetilmesine olanak tanır. Ancak katılan TAs'ın, önceden paylaşılmış ortak bir gizli anahtara erişimi olmalıdır.
  • Doğrudan erişim: Aynı güvenli ortamda bulunan GA'lar, HMAC anahtarını paylaşmak için dahili bir süreçler arası iletişim mekanizması (platforma bağlıdır) kullanabilir.

Her iki durumda da HMAC anahtarı hiçbir zaman TEE dışında kullanıma sunulmamalıdır.

Android'in yanında çalışan Trusty işletim sistemi, TEE'ye örnek olarak verilebilir ancak bunun yerine başka TEE'ler de kullanılabilir. Trusty, KeyMint ile Gatekeeper veya uygun biyometrik trustlet arasında doğrudan iletişim kurmak için dahili bir IPC sistemi kullanır. HMAC anahtarı yalnızca KeyMint'te saklanır. Fingerprint ve Gatekeeper, her kullanım için KeyMint'ten anahtar ister ve değeri kalıcı olarak saklamaz veya önbelleğe almaz.

Bazı TEE'lerde IPC altyapısı olmadığından TEE'deki küçük uygulamalar arasında iletişim gerçekleşmez. Bu, aynı zamanda anahtar deposu hizmetinin sistemdeki kimlik doğrulama tablosu hakkında bilgi sahibi olduğu için başarısız olması kesin olan istekleri hızlı bir şekilde reddetmesine olanak tanır. Böylece, TEE'ye gönderilen potansiyel olarak maliyetli bir IPC kaydedilir.