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ı kavramı vardır. Bu süreç aşağıdaki bileşenleri içerir:

  • Şifreleme anahtarı depolama ve servis sağlayıcı. Android Keystore, uygulamalar için donanım tabanlı kriptografik hizmetler sunar. Çerçeve düzeyindeki Android Keystore sistemi, keystore2 sistem hizmeti tarafından desteklenir. Bu, anahtar materyaline yalnızca donanım tabanlı güvenli bir ortamda (ör. Güvenilir Yürütme Ortamı (TEE) veya StrongBox gibi bir Güvenlik Unsuru (SE)) erişilebilmesini sağlayan, tedarikçiye özel temel bir KeyMint (eski adıyla Keymaster) uygulamasına dayanır.
  • Kullanıcı kimlik doğrulayıcıları. Kullanıcının kimlik doğrulamasının başarılı olduğunu onaylama Android, aşağıdaki kimlik doğrulama bileşenlerini destekler:
    • TEE'de PIN, desen veya şifre kimlik doğrulaması için Gatekeeper.
    • (İsteğe bağlı) Güvenlik unsurunda PIN, desen veya şifre kimlik doğrulaması için Weaver.
    • Parmak iziyle kimlik doğrulama için parmak izi.
    • Diğer biyometrik kimlik doğrulama yöntemleri Android 9 veya sonraki sürümlerle gönderilen cihazlar, parmak izi ve ek biyometri için tek bir entegrasyon noktası olarak BiometricPrompt kullanabilir.
    Bu bileşenler, donanım destekli kimlik doğrulama jetonları (AuthTokens) kullanarak kimlik doğrulama durumlarını keystore2 hizmetine iletir.

Bu bileşenlerin her biri tedarikçiye özeldir ancak tedarikçi uygulamasının, donanım soyutlama katmanı (HAL) arayüz spesifikasyonunu karşılaması ve ilgili tedarikçi test paketi (VTS) testlerini geçmesi gerekir.

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

  • HAL hizmeti, Android sistem işlemi olarak çalışır ve Android sisteminden Binder istekleri 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ıdan kimlik bilgisi kayıtlarını almaya hazır hale getirilir. Kullanıcı başlangıçta Gatekeeper'a (veya varsa Weaver'a) bir PIN, desen veya şifre kaydetmelidir. Bu ilk kayıt, kullanıcı için tanımlayıcı ve kullanıcının kriptografik materyali için bağlayıcı jeton görevi 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ı, söz konusu şifre için kullanıcı SID'sini içeren AuthToken'lar oluşturur.

Mevcut bir kimlik bilgisini değiştirmek isteyen kullanıcı, bu 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 anahtarlara erişmeye devam edebilir.

Bazı durumlarda cihaz yöneticisi, mevcut bir kimlik bilgisini 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ın kimliğini doğrulamak için kullandıkları gizli bir HMAC anahtarını (önyükleme başına) paylaştığını unutmayın.

Kullanıcı, kimlik bilgilerini ayarlayıp kullanıcı SID'si atandıktan sonra kimlik doğrulama işlemini başlatabilir. Bu işlem, kullanıcının PIN, desen, şifre, parmak izi veya başka bir güçlü biyometrik veri sağlamasıyla başlar. Kimlik doğrulama akışı

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

  1. Kullanıcı bir kimlik doğrulama yöntemi sağlar ve ilişkili hizmet, HAL hizmetine istek gönderir.
    • PIN, desen veya şifre için LockSettingsService, gatekeeperd uygulamasına 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ümleri çalıştıran cihazlarda FingerprintService, fingerprintd için istekte bulunur. Android 9 ve sonraki sürümleri çalıştıran cihazlarda BiometricPrompt, FingerprintManager veya FaceManager gibi uygun BiometricManager sınıfını kullanarak uygun biyometrik arka plan programı (ör. parmak izleri için fingerprintd veya yüz için faced) için istekte bulunur. Sürümden bağımsız olarak, biyometrik kimlik doğrulama, istek gönderildikten sonra eşzamansız olarak gerçekleşir.
  2. HAL hizmeti, verileri karşılık gelen TA'ya gönderir. TA, bir AuthToken oluşturur:
    • PIN/desen/şifre kimlik doğrulaması için gatekeeperd, PIN'i, deseni veya şifre karmasını Gatekeeper HAL hizmeti aracılığıyla 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'si aracılığıyla TEE'deki Parmak İzi TA'ya gönderir. TEE'de kimlik doğrulama başarılı olursa Fingerprint TA, bir AuthToken (AuthToken HMAC anahtarıyla imzalanmış) yayınlar.
    • Diğer biyometrik kimlik doğrulama yöntemlerinde, uygun biyometrik arka plan programı biyometrik etkinliği dinler ve uygun biyometrik HAL hizmetine ve TA'ya gönderir.
  3. İmzalanmış AuthToken, bir Binder arayüzü aracılığıyla keystore2 sistem hizmetine iletilir.
  4. keystore2 hizmeti, şifreleme işlemleri gerçekleştirmek için KeyMint'ten (eski adıyla Keymaster) AuthToken'ları eklemesini ister. KeyMint HAL hizmeti, bunları KeyMint TA'ya iletir. KeyMint TA, Gatekeeper ve desteklenen biyometrik TEE bileşenleriyle paylaşılan HMAC anahtarını kullanarak bunları doğrular. KeyMint, jetondaki zaman damgasını son kimlik doğrulama zamanı olarak kabul eder ve anahtarın kullanımına izin verilip verilmeyeceğine zaman damgasına göre karar 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 geçer ve bu hizmet de bunları KeyMint TA'ya iletir. Bu sayede keystore2 hizmeti, sistemdeki mevcut AuthToken'lar hakkında bilgi sahibi olduğundan başarısız olacağı kesin olan istekleri hızlı bir şekilde reddedebilir. Böylece, TEE'ye potansiyel olarak maliyetli bir IPC kaydedilir.

AuthToken biçimi

AuthToken'ın biçimi, HardwareAuthToken.aidl adresindeki AIDL spesifikasyonunda verilmiştir.

Cihaz başlatma akışı

Cihazın her başlatılışında AuthToken HMAC anahtarı oluşturulmalı ve tüm TEE bileşenleriyle (Gatekeeper, KeyMint ve desteklenen biyometri TA'ları) paylaşılmalıdır. Tekrar saldırılarını önlemek için HMAC anahtarı, cihaz her yeniden başlatıldığında rastgele oluşturulmalıdır.

TA'lar bu paylaşılan HMAC anahtarına iki yaygın yöntemle erişebilir:

  • Paylaşılan gizli anahtar sözleşmesi: keystore2 hizmeti, cihaz başlatılırken çok yönlü bir anahtar sözleşmesi protokolü gerçekleştirerek katılan TA'lar arasında HMAC anahtarının güvenli bir şekilde türetilmesini sağlar. Ancak katılımcı TA'ların ortak bir önceden paylaşılan gizli anahtara erişimi olmalıdır.
  • Doğrudan erişim: Aynı güvenli ortamda bulunan TA'lar, HMAC anahtarını paylaşmak için dahili bir işlemler arası iletişim mekanizması (platforma bağlıdır) kullanabilir.

Her iki durumda da HMAC anahtarı TEE dışında asla kullanılabilir olmamalıdır.

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

Bazı TEE'lerde IPC altyapısı olmadığından TEE'deki uygulamalar arasında iletişim kurulmaz. Bu sayede anahtar deposu hizmeti, sistemdeki kimlik doğrulama tablosu hakkında bilgi sahibi olduğu için başarısız olacağı kesin olan istekleri hızlı bir şekilde reddedebilir. Böylece, TEE'ye maliyetli olabilecek bir IPC'den tasarruf edilir.