Dosya Tabanlı Şifreleme

Android 7.0 ve üstü, dosya tabanlı şifrelemeyi (FBE) destekler. Dosya tabanlı şifreleme, farklı dosyaların, bağımsız olarak açılabilen farklı anahtarlarla şifrelenmesine izin verir.

Bu makale, yeni cihazlarda dosya tabanlı şifrelemenin nasıl etkinleştirileceğini ve sistem uygulamalarının kullanıcılara mümkün olan en iyi, en güvenli deneyimi sunmak için Direct Boot API'lerini nasıl kullanabileceğini açıklar.

Doğrudan Önyükleme

Dosya tabanlı şifreleme, Android 7.0'da sunulan Direct Boot adlı yeni bir özelliği etkinleştirir. Doğrudan Önyükleme, şifrelenmiş aygıtların doğrudan kilit ekranına önyüklenmesini sağlar. Önceden, tam disk şifreleme (FDE) kullanan şifrelenmiş cihazlarda, kullanıcıların herhangi bir veriye erişilmeden önce kimlik bilgilerini sağlaması gerekiyordu ve telefonun en temel işlemler dışında her şeyi yapmasını engelliyordu. Örneğin, alarmlar çalışamıyordu, erişilebilirlik hizmetleri kullanılamıyordu ve telefonlar aramaları alamıyordu, ancak yalnızca temel acil durum çevirici işlemleriyle sınırlıydı.

Uygulamaları şifrelemeden haberdar etmek için dosya tabanlı şifrelemenin (FBE) ve yeni API'lerin tanıtılmasıyla, bu uygulamaların sınırlı bir bağlamda çalışması mümkündür. Bu, kullanıcılar kimlik bilgilerini sağlamaya devam ederken özel kullanıcı bilgilerini korumadan önce gerçekleşebilir.

FBE özellikli bir cihazda, cihazın her kullanıcısı, uygulamalar için kullanılabilen iki depolama konumuna sahiptir:

  • Varsayılan depolama konumu olan ve yalnızca kullanıcı cihazın kilidini açtıktan sonra kullanılabilen Kimlik Bilgileri Şifreli (CE) depolama.
  • Hem Doğrudan Önyükleme modunda hem de kullanıcı aygıtın kilidini açtıktan sonra kullanılabilen bir depolama konumu olan Aygıt Şifreli (DE) depolama.

Bu ayrım, iş profillerini daha güvenli hale getirir çünkü şifreleme artık yalnızca bir önyükleme zamanı parolasına dayalı olmadığından, aynı anda birden fazla kullanıcının korunmasına izin verir.

Direct Boot API, şifrelemeye duyarlı uygulamaların bu alanların her birine erişmesine izin verir. Kilit ekranına ilk kez kimlik bilgilerinin girilmesine yanıt olarak bir kullanıcının CE depolamasının kilidi açıldığında veya iş profilinin bir iş sorgulaması sağlaması durumunda, uygulamaları bilgilendirme ihtiyacını karşılamak için uygulama yaşam döngüsünde değişiklikler vardır. Android 7.0 çalıştıran cihazlar, FBE uygulayıp uygulamadıklarına bakılmaksızın bu yeni API'leri ve yaşam döngülerini desteklemelidir. FBE olmadan DE ve CE depolaması her zaman kilitsiz durumda olacaktır.

Ext4 ve F2FS dosya sistemlerinde dosya tabanlı şifrelemenin eksiksiz bir uygulaması, Android Açık Kaynak Projesi'nde (AOSP) sağlanır ve yalnızca gereksinimleri karşılayan cihazlarda etkinleştirilmesi gerekir. FBE'yi kullanmayı seçen üreticiler, kullanılan çip (SoC) üzerindeki sisteme dayalı olarak özelliği optimize etmenin yollarını keşfetmek isteyebilir.

AOSP'deki tüm gerekli paketler, doğrudan önyüklemeden haberdar olacak şekilde güncellendi. Bununla birlikte, cihaz üreticileri bu uygulamaların özelleştirilmiş sürümlerini kullandıklarında, en azından aşağıdaki hizmetleri sağlayan doğrudan önyükleme bilinçli paketlerin bulunduğundan emin olmak isteyeceklerdir:

  • Telefon Hizmetleri ve Çevirici
  • Kilit ekranına şifreleri girmek için giriş yöntemi

Örnekler ve kaynak

Android, vold'un ( sistem / vold ) Android'deki depolama cihazlarını ve birimlerini yönetmek için işlevsellik sağladığı dosya tabanlı şifreleme için bir referans uygulaması sağlar. FBE'nin eklenmesi, birden çok kullanıcının CE ve DE anahtarları için anahtar yönetimini desteklemek için vold'a birkaç yeni komut sağlar. Çekirdekte dosya tabanlı şifreleme yeteneklerini kullanmak için temel değişikliklere ek olarak, kilit ekranı ve SystemUI dahil birçok sistem paketi FBE ve Direct Boot özelliklerini desteklemek için değiştirildi. Bunlar şunları içerir:

  • AOSP Çevirici (paketler / uygulamalar / Çevirici)
  • Masa Saati (paketler / uygulamalar / DeskClock)
  • LatinIME (paketler / girdi yöntemleri / LatinIME) *
  • Ayarlar Uygulaması (paketler / uygulamalar / Ayarlar) *
  • SystemUI (çerçeveler / temel / paketler / SystemUI) *

* defaultToDeviceProtectedStorage bildirim özelliğini kullanan sistem uygulamaları

AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutu çalıştırılarak şifrelemeye duyarlı daha fazla uygulama ve hizmet örneği bulunabilir.

Bağımlılıklar

FBE'nin AOSP uygulamasını güvenli bir şekilde kullanmak için, bir cihazın aşağıdaki bağımlılıkları karşılaması gerekir:

  • Ext4 şifrelemesi veya F2FS şifrelemesi için Çekirdek Desteği .
  • HAL sürüm 1.0 veya 2.0 ile Keymaster Desteği . Keymaster 0.3 desteği yoktur, çünkü bu gerekli yetenekleri sağlamaz veya şifreleme anahtarları için yeterli korumayı sağlamaz.
  • Keymaster / Keystore ve Gatekeeper , DE anahtarlarına koruma sağlamak için bir Trusted Execution Environment (TEE) içinde uygulanmalıdır, böylece yetkisiz bir işletim sistemi (aygıta yanıp sönen özel işletim sistemi) DE anahtarlarını basitçe talep edemez.
  • Cihaz Şifreleme kimlik bilgilerinin yetkisiz bir işletim sistemi tarafından erişilebilir olmadığından emin olmak için, anahtar yöneticisinin başlatılmasına bağlı Donanım Güveni ve Doğrulanmış Önyükleme gereklidir.

Not : Depolama ilkeleri bir klasöre ve tüm alt klasörlerine uygulanır. Üreticiler, şifrelenmemiş içeriği OTA klasörüne ve sistemin şifresini çözen anahtarı tutan klasöre sınırlamalıdır. Çoğu içerik, cihaz şifreli depolama yerine kimlik bilgileri ile şifrelenmiş depolamada bulunmalıdır.

Uygulama

Öncelikle ve en önemlisi, çalar saatler, telefon, erişilebilirlik özellikleri gibi uygulamalar, Direct Boot geliştirici belgelerine göre android: directBootAware yapılmalıdır.

Çekirdek Desteği

Ext4 ve F2FS şifrelemesi için çekirdek desteği, Android ortak çekirdeklerinde, sürüm 3.18 ve üzerinde mevcuttur. Sürüm 5.1 veya üzeri olan bir çekirdekte etkinleştirmek için şunu kullanın:

CONFIG_FS_ENCRYPTION=y

Daha eski çekirdekler için, cihazınızın kullanıcı userdata dosya sistemi Ext4 ise CONFIG_EXT4_ENCRYPTION=y veya cihazınızın userdata dosya sistemi F2FS ise CONFIG_F2FS_FS_ENCRYPTION=y kullanın.

Cihazınız benimsenebilir depolamayı destekleyecekse veya dahili depolamada meta veri şifrelemesini kullanacaksa, meta veri şifreleme belgelerinde açıklandığı gibi meta veri şifrelemesi için gereken çekirdek yapılandırma seçeneklerini de etkinleştirin.

Cihaz üreticileri, Ext4 veya F2FS şifrelemesine yönelik işlevsel desteğe ek olarak, dosya tabanlı şifrelemeyi hızlandırmak ve kullanıcı deneyimini iyileştirmek için kriptografik hızlandırmayı da etkinleştirmelidir. Örneğin, ARM64 tabanlı cihazlarda, ARMv8 CE (Şifreleme Uzantıları) hızlandırma, aşağıdaki çekirdek yapılandırma seçenekleri ayarlanarak etkinleştirilebilir:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Performansı daha da iyileştirmek ve güç kullanımını azaltmak için, cihaz üreticileri, depolama cihazına giderken / cihazdan gelirken verileri şifreleyen / şifresini çözen hat içi şifreleme donanımını uygulamayı da düşünebilir. Android ortak çekirdekleri (sürüm 4.14 ve üstü), donanım ve satıcı sürücüsü desteği mevcut olduğunda satır içi şifrelemenin kullanılmasına izin veren bir çerçeve içerir. Satır içi şifreleme çerçevesi, aşağıdaki çekirdek yapılandırma seçenekleri ayarlanarak etkinleştirilebilir:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Cihazınız UFS tabanlı depolama kullanıyorsa, şunları da etkinleştirin:

CONFIG_SCSI_UFS_CRYPTO=y

Cihazınız eMMC tabanlı depolama kullanıyorsa şunları da etkinleştirin:

CONFIG_MMC_CRYPTO=y

Dosya tabanlı şifrelemeyi etkinleştirme

FBE'nin bir cihazda etkinleştirilmesi, dahili depolamada ( userdata ) etkinleştirilmesini gerektirir. Bu aynı zamanda FBE'yi otomatik olarak kabul edilebilir depolamada etkinleştirir; ancak, kabul edilebilir depolamadaki şifreleme formatı gerekirse geçersiz kılınabilir.

Dahili depolama

FBE seçeneği ekleyerek etkindir fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] arasında fs_mgr_flags sütuna fstab için hat userdata . Bu seçenek, dahili depolamadaki şifreleme biçimini tanımlar. En fazla üç tane iki nokta üst üste ile ayrılmış parametre içerir:

  • contents_encryption_mode parametresi, dosya içeriklerini şifrelemek için hangi şifreleme algoritmasının kullanıldığını tanımlar. adiantum aes-256-xts adiantum veya adiantum . Android 11'den beri, aes-256-xts olan varsayılan algoritmayı belirtmek için boş bırakılabilir.
  • filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi şifreleme algoritmasının kullanıldığını tanımlar. Bu, aes-256-cts , aes-256-heh veya adiantum . , Varsayılan belirtilmemiş ise aes-256-cts eğer contents_encryption_mode olduğunu aes-256-xts , veya adiantum eğer contents_encryption_mode olduğunu adiantum .
  • Android 11'de yeni olan flags parametresi, + karakteriyle ayrılmış bayrakların bir listesidir. Aşağıdaki bayraklar desteklenmektedir:
    • v1 bayrağı, sürüm 1 şifreleme politikalarını seçer; v2 bayrağı, sürüm 2 şifreleme politikalarını seçer. Sürüm 2 şifreleme politikaları, daha güvenli ve esnek bir anahtar türetme işlevi kullanır . Varsayılan, cihaz Android 11 veya daha yüksek bir ro.product.first_api_level başlatılıyorsa ( ro.product.first_api_level tarafından belirlendiği ro.product.first_api_level ) v2 veya cihaz Android 10 veya daha düşük bir ro.product.first_api_level başlatılmışsa ro.product.first_api_level .
    • inlinecrypt_optimized bayrağı, çok sayıda anahtarı verimli bir şekilde işlemeyen satır içi şifreleme donanımı için optimize edilmiş bir şifreleme formatı seçer. Bunu, dosya başına bir tane yerine, CE veya DE anahtarı başına yalnızca bir dosya içeriği şifreleme anahtarı türeterek yapar. IV'lerin üretimi (başlatma vektörleri) buna göre ayarlanır.
    • emmc_optimized bayrağı emmc_optimized benzer, ancak inlinecrypt_optimized 32 bit ile sınırlayan bir IV oluşturma yöntemi de seçer. Bu bayrak yalnızca JEDEC eMMC v5.2 spesifikasyonuyla uyumlu olan ve bu nedenle yalnızca 32 bit IV'leri destekleyen hat içi şifreleme donanımında kullanılmalıdır. Diğer satır içi şifreleme donanımında bunun yerine inlinecrypt_optimized kullanın. Bu bayrak asla UFS tabanlı depolamada kullanılmamalıdır; UFS spesifikasyonu 64-bit IV'lerin kullanımına izin verir.
    • Donanımla sarılmış anahtarları destekleyen cihazlarda, wrappedkey_v0 bayrağı, FBE için donanımla sarılmış anahtarların kullanılmasını sağlar. Bu yalnızca inlinecrypt bağlama seçeneği ve inlinecrypt_optimized veya emmc_optimized bayrağıyla birlikte kullanılabilir.

Satır içi şifreleme donanımı kullanmıyorsanız, çoğu cihaz için önerilen ayar fileencryption=aes-256-xts . Satır içi şifreleme donanımı kullanıyorsanız, çoğu cihaz için önerilen ayar fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (veya eşdeğer olarak fileencryption=::inlinecrypt_optimized ) şeklindedir. Herhangi bir AES hızlandırması olmayan cihazlarda, dosya fileencryption=adiantum ayarlanarak AES yerine fileencryption=adiantum .

Android 10 veya daha düşük fileencryption=ice başlatılan cihazlarda, FSCRYPT_MODE_PRIVATE dosya içeriği şifreleme modunun kullanımını belirtmek için fileencryption=ice da kabul edilir. Bu mod, Android ortak çekirdeklerinde uygulanmaz, ancak özel çekirdek yamaları kullanan satıcılar tarafından uygulanabilir. Bu mod tarafından üretilen disk üstü format, satıcıya özeldi. Android 11 veya üzeri ile başlatılan cihazlarda bu moda artık izin verilmemektedir ve bunun yerine standart bir şifreleme biçimi kullanılmalıdır.

Varsayılan olarak, dosya içeriği şifrelemesi Linux çekirdeğinin şifreleme API'si kullanılarak yapılır. Bunun yerine satır içi şifreleme donanımı kullanmak istiyorsanız, ayrıca inlinecrypt bağlama seçeneğini de ekleyin. Örneğin, tam bir fstab satırı şöyle görünebilir:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Kabul edilebilir depolama

Android 9'dan beri FBE ve benimsenebilir depolama birlikte kullanılabilir.

Belirtme fileencryption için fstab seçeneği userdata da otomatik FBE ve her iki sağlayan meta şifreleme uyarlanamıyor depolama. Ancak, PRODUCT_PROPERTY_OVERRIDES içindeki özellikleri ayarlayarak, kabul edilebilir depolamada FBE ve / veya meta veri şifreleme formatlarını geçersiz kılabilirsiniz.

Android 11 veya üzeri ile başlatılan cihazlarda aşağıdaki özellikleri kullanın:

  • ro.crypto.volume.options (Android 11'de yeni), kabul edilebilir depolamada FBE şifreleme formatını seçer. fileencryption fstab seçeneğinin bağımsız değişkeniyle aynı sözdizimine sahiptir ve aynı varsayılanları kullanır. Burada neyin kullanılacağını fileencryption yukarıdaki fileencryption önerilerine bakın.
  • ro.crypto.volume.metadata.encryption , kabul edilebilir depolamada meta veri şifreleme biçimini seçer. Meta veri şifreleme belgelerine bakın.

Android 10 veya daha eski sürümlerle başlatılan cihazlarda aşağıdaki özellikleri kullanın:

  • ro.crypto.volume.contents_mode , içerik şifreleme modunu seçer. Bu, iki nokta üst üste ile ayrılmış ilk ro.crypto.volume.options alanına ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode dosya adları şifreleme modunu seçer. Bu, iki nokta üst üste ile ayrılmış ro.crypto.volume.options alanına ro.crypto.volume.options , tek fark, Android 10 veya daha düşük ro.crypto.volume.options başlatılan cihazlarda varsayılanın aes-256-heh . Çoğu cihazda, bunun aes-256-cts olarak açıkça geçersiz kılınması gerekir.
  • ro.crypto.fde_algorithm ve ro.crypto.fde_sector_size , kabul edilebilir depolamada meta veri şifreleme formatını seçer. Meta veri şifreleme belgelerine bakın.

Keymaster ile entegrasyon

Anahtarların üretimi ve çekirdek anahtarlığının yönetimi vold tarafından vold . FBE'nin AOSP uygulaması, cihazın Keymaster HAL sürüm 1.0 veya üstünü desteklemesini gerektirir. Keymaster HAL'ın önceki sürümleri için destek yoktur.

İlk önyüklemede, kullanıcı 0'ın anahtarları önyükleme işleminin başlarında oluşturulur ve yüklenir. Zamanla on-post-fs faz init tamamlanıncaya, Keymaster isteklerini işlemek için hazır olmalıdır. Pixel cihazlarda bu, Keymaster'ın /data eklenmeden önce başlatılmasını sağlayan bir komut dosyası bloğuna sahip olarak ele alınır.

Şifreleme politikası

Dosya tabanlı şifreleme, şifreleme ilkesini dizin düzeyinde uygular. Bir aygıtın kullanıcı userdata bölümü ilk oluşturulduğunda, temel yapılar ve ilkeler init komut dosyaları tarafından uygulanır. Bu komut dosyaları, ilk kullanıcının (kullanıcı 0'lar) CE ve DE anahtarlarının oluşturulmasını tetikleyecek ve bu anahtarlarla hangi dizinlerin şifreleneceğini tanımlayacaktır. Ek kullanıcılar ve profiller oluşturulduğunda, gerekli ek anahtarlar oluşturulur ve anahtar deposunda saklanır; kimlik bilgileri ve cihazların depolama konumları oluşturulur ve şifreleme politikası bu anahtarları bu dizinlere bağlar.

Android 11 ve sonraki sürümlerde, şifreleme politikası artık merkezi bir konuma gömülmez, bunun yerine init komut dosyalarındaki mkdir komutlarına yapılan argümanlar tarafından tanımlanır. Sistem DE anahtarıyla şifrelenen dizinler, encryption=Require , şifrelenmemiş dizinler (veya alt dizinleri kullanıcı başına anahtarlarla şifrelenmiş dizinler) encryption=None .

Android 10'da, şifreleme politikası şu konuma kodlanmıştır:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 ve önceki sürümlerde konum şöyleydi:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Belirli dizinlerin şifrelenmesini önlemek için istisnalar eklemek mümkündür. Bu tür değişiklikler yapılırsa, cihaz üreticisi, yalnızca şifrelenmemiş dizini kullanması gereken uygulamalara erişim sağlayan SELinux politikalarını dahil etmelidir. Bu, güvenilmeyen tüm uygulamaları dışlamalıdır.

Bunun için bilinen tek kabul edilebilir kullanım durumu, eski OTA yeteneklerini desteklemektir.

Sistem uygulamalarında Direct Boot'u destekleme

Uygulamaları Doğrudan Önyükleme konusunda bilinçlendirme

Sistem uygulamalarının hızlı geçişini kolaylaştırmak için, uygulama düzeyinde ayarlanabilen iki yeni özellik vardır. defaultToDeviceProtectedStorage özniteliği yalnızca sistem uygulamalarında kullanılabilir. directBootAware özniteliği directBootAware tarafından kullanılabilir.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Uygulama düzeyindeki directBootAware özniteliği, uygulamadaki tüm bileşenleri şifrelemeye duyarlı olarak işaretlemenin kısaltmasıdır.

defaultToDeviceProtectedStorage özniteliği, varsayılan uygulama depolama konumunu CE depolamaya işaret etmek yerine DE depolamaya işaret edecek şekilde yeniden yönlendirir. Bu bayrağı kullanan sistem uygulamaları, varsayılan konumda depolanan tüm verileri dikkatli bir şekilde denetlemeli ve CE depolamasını kullanmak için hassas verilerin yollarını değiştirmelidir. Bu seçeneği kullanan cihaz üreticileri, hiçbir kişisel bilgi içermediğinden emin olmak için sakladıkları verileri dikkatlice incelemelidir.

Bu modda çalışırken, CE depolama tarafından desteklenen bir Bağlamı açık bir şekilde yönetmek için aşağıdaki Sistem API'leri kullanılabilir ve bunlar Cihaz Korumalı muadilleriyle eşdeğerdir.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Birden çok kullanıcıyı desteklemek

Çok kullanıcılı bir ortamdaki her kullanıcı ayrı bir şifreleme anahtarı alır. Her kullanıcı iki anahtar alır: bir DE ve bir CE anahtarı. Kullanıcı 0, özel bir kullanıcı olduğu için önce cihazda oturum açmalıdır. Bu, Aygıt Yönetimi kullanımları için geçerlidir.

Şifreli uygulamalar, kullanıcılar arasında şu şekilde etkileşim INTERACT_ACROSS_USERS : INTERACT_ACROSS_USERS ve INTERACT_ACROSS_USERS_FULL , bir uygulamanın cihazdaki tüm kullanıcılar arasında hareket etmesine izin verir. Ancak, bu uygulamalar yalnızca kilidi açılmış kullanıcılar için CE ile şifrelenmiş dizinlere erişebilecektir.

Bir uygulama, DE alanlarında serbestçe etkileşime girebilir, ancak bir kullanıcının kilidinin açılması, cihazdaki tüm kullanıcıların kilidinin açıldığı anlamına gelmez. Uygulama, bu alanlara erişmeye çalışmadan önce bu durumu kontrol etmelidir.

Her iş profili kullanıcı kimliği ayrıca iki anahtar alır: DE ve CE. İş zorluğu karşılandığında, profil kullanıcısının kilidi açılır ve Keymaster (TEE'de) profilin TEE anahtarını sağlayabilir.

Güncellemeleri işleme

Kurtarma bölümü, kullanıcı verileri bölümündeki DE korumalı depolamaya erişemiyor. FBE'yi uygulayan cihazların A / B sistem güncellemelerini kullanarak OTA'yı desteklemesi şiddetle tavsiye edilir. OTA normal çalışma sırasında uygulanabildiğinden, şifrelenmiş sürücüdeki verilere erişmek için kurtarmaya gerek yoktur.

Erişmek için üzerine OTA dosyasını kurtarma gerektiren eski OTA çözüm kullanırken userdata bölümü:

  1. (Örnek için bir üst düzey dizin oluşturun misc_ne olarak) userdata bölümü.
  2. Bu en üst düzey dizini şifreleme politikası istisnasına ekleyin (yukarıdaki Şifreleme politikasına bakın).
  3. OTA paketlerini tutmak için üst düzey dizinde bir dizin oluşturun.
  4. Bu klasöre ve içeriğine erişimi kontrol etmek için bir SELinux kuralı ve dosya bağlamları ekleyin. Yalnızca OTA güncellemelerini alan işlem veya uygulamalar bu klasörü okuyup yazabilmelidir. Başka hiçbir uygulama veya işlemin bu klasöre erişimi olmamalıdır.

Doğrulama

Özelliğin uygulanan sürümünün amaçlandığı gibi çalıştığından emin olmak için, önce DirectBootHostTest ve EncryptionTest gibi birçok CTS şifreleme testini çalıştırın.

Cihaz Android 11 veya sonraki bir sürümü çalıştırıyorsa vts_kernel_encryption_test'i de çalıştırın:

atest vts_kernel_encryption_test

veya:

vts-tradefed run vts -m vts_kernel_encryption_test

Ek olarak, cihaz üreticileri aşağıdaki manuel testleri gerçekleştirebilir. FBE'nin etkin olduğu bir cihazda:

  • ro.crypto.state var ro.crypto.state olmadığını kontrol edin
    • ro.crypto.state şifrelenmiş olduğundan emin olun
  • ro.crypto.type var ro.crypto.type olmadığını kontrol edin
    • ro.crypto.type file olarak ayarlandığından emin olun

Ek olarak, test uzmanları, birincil kullanıcı üzerinde bir kilit ekranı ayarlı bir userdebug örneğini önyükleyebilir. Ardından cihaza adb kabuğu ve root olmak için su kullanın. /data/data data'nın şifrelenmiş dosya adları içerdiğinden emin olun; değilse, bir sorun var.

Cihaz üreticilerinin ayrıca kendi cihazlarında veya çekirdeklerinde fscrypt için yukarı akış Linux testlerini çalıştırmayı keşfetmeleri önerilir. Bu testler, xfstests dosya sistemi test paketinin bir parçasıdır. Ancak, bu yukarı akış testleri resmi olarak Android tarafından desteklenmemektedir.

AOSP uygulama ayrıntıları

Bu bölüm, AOSP uygulamasıyla ilgili ayrıntıları sağlar ve dosya tabanlı şifrelemenin nasıl çalıştığını açıklar. Cihaz üreticilerinin cihazlarında FBE ve Direct Boot kullanmak için burada herhangi bir değişiklik yapmasına gerek olmamalıdır.

fscrypt şifreleme

AOSP uygulaması, çekirdekte "fscrypt" şifrelemesini (ext4 ve f2fs tarafından desteklenir) kullanır ve normalde şu şekilde yapılandırılır:

  • Dosya içeriklerini XTS modunda AES-256 ile şifreleyin
  • CBC-CTS modunda dosya adlarını AES-256 ile şifreleyin

Adiantum şifreleme de desteklenmektedir. Adiantum şifreleme etkinleştirildiğinde, hem dosya içerikleri hem de dosya adları Adiantum ile şifrelenir.

Fscrypt hakkında daha fazla bilgi için yukarı akış çekirdek belgelerine bakın .

Anahtar türetme

512 bit anahtarlar olan dosya tabanlı şifreleme anahtarları, TEE'de tutulan başka bir anahtarla (256 bit AES-GCM anahtarı) şifrelenmiş olarak saklanır. Bu TEE anahtarını kullanmak için üç gereksinim karşılanmalıdır:

  • Yetkilendirme belirteci
  • Uzatılmış kimlik bilgisi
  • "İkinci elden çıkarılabilir hash"

Yetkilendirme belirteci , bir kullanıcı başarıyla oturum açtığında Gatekeeper tarafından üretilen kriptografik olarak doğrulanmış bir simgedir. TEE, doğru kimlik doğrulama belirteci sağlanmadıkça anahtarı kullanmayı reddedecektir. Kullanıcının kimlik bilgisi yoksa, kimlik doğrulama belirteci kullanılmaz veya gerekli değildir.

Uzatılmış kimlik bilgisi , scrypt algoritmasıyla tuzlama ve esnetme işleminden sonra kullanıcı kimlik scrypt . Kimlik aslında geçirilmeden önce Kilidin ayarları hizmetinde kez, sağlaması için vold için geçme scrypt . Bu, KM_TAG_APPLICATION_ID için geçerli olan tüm garantilerle birlikte KM_TAG_APPLICATION_ID anahtara kriptografik olarak bağlıdır. Kullanıcının kimlik bilgisi yoksa, uzatılmış kimlik bilgisi kullanılmaz veya gerekli değildir.

İkinci secdiscardable hash , çekirdek gibi anahtarı yeniden yapılandırmak için kullanılan diğer bilgilerle birlikte depolanan rastgele 16 KB'lik bir dosyanın 512 bitlik bir secdiscardable hash . Bu dosya, anahtar silindiğinde veya yeni bir şekilde şifrelendiğinde güvenli bir şekilde silinir; Bu ek koruma, bir saldırganın anahtarı kurtarmak için bu güvenli bir şekilde silinen dosyanın her bir parçasını kurtarmasını sağlar. Bu, KM_TAG_APPLICATION_ID için geçerli olan tüm garantilerle birlikte KM_TAG_APPLICATION_ID anahtara kriptografik olarak bağlıdır.

Çoğu durumda, FBE anahtarları, örneğin dosya başına veya mod başına anahtarlar gibi şifrelemeyi yapmak için fiilen kullanılan alt anahtarları oluşturmak için çekirdekte ek bir anahtar türetme adımına da tabi tutulur. Sürüm 2 şifreleme politikalarında bunun için HKDF-SHA512 kullanılır.