Dosya Tabanlı Şifreleme

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

Bu makalede, yeni cihazlarda dosya tabanlı şifrelemenin nasıl etkinleştirileceği ve sistem uygulamalarının, kullanıcılara mümkün olan en iyi, en güvenli deneyimi sunmak için Doğrudan Önyükleme API'lerini nasıl kullanabileceği açıklanmaktadır.

Android 10 ve sonraki sürümlerle başlatılan tüm cihazların dosya tabanlı şifreleme kullanması gerekir.

Doğrudan Önyükleme

Dosya tabanlı şifreleme, Android 7.0'da sunulan Doğrudan Önyükleme adı verilen yeni bir özelliği etkinleştirir. Doğrudan Önyükleme, şifrelenmiş cihazların doğrudan kilit ekranına önyükleme yapmasına olanak tanır. Daha önce, tam disk şifreleme (FDE) kullanan şifrelenmiş cihazlarda, kullanıcıların herhangi bir veriye erişilmeden önce kimlik bilgileri sağlaması gerekiyordu, bu da telefonun en temel işlemler dışında tüm işlemleri gerçekleştirmesini engelliyordu. Örneğin, alarmlar çalışmıyordu, erişilebilirlik hizmetleri kullanılamıyordu ve telefonlar çağrı alamıyordu ancak yalnızca temel acil durum arama işlemleriyle sınırlıydı.

Dosya tabanlı şifrelemenin (FBE) ve uygulamaları şifreleme konusunda bilinçlendiren yeni API'lerin kullanıma sunulmasıyla, bu uygulamaların sınırlı bir bağlamda çalışması mümkün hale geldi. Bu durum, kullanıcıların özel kullanıcı bilgilerini korurken kimlik bilgilerini sağlamalarından ö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 Bilgisi Şifreli (CE) depolama.
• Hem Doğrudan Önyükleme modunda hem de kullanıcı cihazın kilidini açtıktan sonra kullanılabilen bir depolama konumu olan Cihaz Şifreli (DE) depolama.

Bu ayırma, şifrelemenin artık yalnızca önyükleme zamanı parolasına dayalı olmaması nedeniyle aynı anda birden fazla kullanıcının korunmasına olanak tanıdığı için iş profillerini daha güvenli hale getirir.

Direct Boot API, şifrelemeye duyarlı uygulamaların bu alanların her birine erişmesine olanak tanır. Kilit ekranına kimlik bilgilerinin ilk kez girilmesine yanıt olarak kullanıcının CE depolama alanının kilidi açıldığında veya iş profilinin bir iş sorunu sağlaması durumunda uygulamalara bildirimde bulunma 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'yi uygulayıp uygulamamaları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 üzerindeki sisteme (SoC) dayalı olarak bu özelliği optimize etmenin yollarını araştırmak isteyebilir.

AOSP'deki tüm gerekli paketler doğrudan önyükleme uyumlu olacak şekilde güncellendi. Ancak 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 uyumlu paketlerin bulunduğundan emin olmak isteyeceklerdir:

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

Örnekler ve kaynak

Android, dosya tabanlı şifrelemenin referans uygulamasını sağlar; burada vold ( system/vold ), Android'deki depolama aygıtlarını ve birimleri yönetme işlevselliğini sağlar. FBE'nin eklenmesi, vold'e birden fazla kullanıcının CE ve DE anahtarları için anahtar yönetimini desteklemek üzere birkaç yeni komut sağlar. Çekirdekteki dosya tabanlı şifreleme yeteneklerini kullanmaya yönelik temel değişikliklere ek olarak, kilit ekranı ve SystemUI dahil olmak üzere birçok sistem paketi, FBE ve Doğrudan Önyükleme özelliklerini destekleyecek şekilde değiştirildi. Bunlar şunları içerir:

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

* defaultToDeviceProtectedStorage manifest özelliğini kullanan sistem uygulamaları

Şifreleme uyumlu uygulama ve hizmetlere ilişkin daha fazla örnek, AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutunu çalıştırarak 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 şifreleme veya F2FS şifreleme için Çekirdek Desteği .
• HAL sürüm 1.0 veya üzeri ile Keymaster Desteği . Gerekli yetenekleri sağlamadığı veya şifreleme anahtarları için yeterli korumayı garanti etmediği için Keymaster 0.3 desteği yoktur.
• Yetkisiz bir işletim sisteminin (cihaza yüklenen özel işletim sistemi) DE anahtarlarını kolayca isteyememesi için, DE anahtarlarına koruma sağlamak üzere Keymaster/ Anahtar Deposu ve Ağ Geçidi Yöneticisinin Güvenilir Yürütme Ortamında (TEE) uygulanması gerekir.
• DE anahtarlarına yetkisiz bir işletim sistemi tarafından erişilememesini sağlamak için Keymaster başlatmaya bağlı Donanım Güven Kökü ve Doğrulanmış Önyükleme gereklidir.

Uygulama

Öncelikle ve en önemlisi, alarm saatleri, telefon ve erişilebilirlik özellikleri gibi uygulamaların Direct Boot geliştirici belgelerine göre android:directBootAware haline getirilmesi gerekir.

Çekirdek desteği

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

CONFIG_FS_ENCRYPTION=y

Daha eski çekirdekler için, cihazınızın userdata dosya sistemi Ext4 ise CONFIG_EXT4_ENCRYPTION=y kullanın 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 şifrelemesi için gereken çekirdek yapılandırma seçeneklerini de meta veri şifreleme belgelerinde açıklandığı şekilde etkinleştirin.

Ext4 veya F2FS şifrelemeye yönelik işlevsel desteğin yanı sıra, cihaz üreticilerinin dosya tabanlı şifrelemeyi hızlandırmak ve kullanıcı deneyimini geliştirmek için şifreleme hızlandırmayı da etkinleştirmesi gerekir. Örneğin, ARM64 tabanlı cihazlarda ARMv8 CE (Şifreleme Uzantıları) hızlandırması, 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 artırmak ve güç kullanımını azaltmak için cihaz üreticileri, verileri depolama cihazına giderken/aygıttan ayrılırken şifreleyen/şifresini çözen hat içi şifreleme donanımını da uygulamayı 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 olanak tanıyan 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

Bir cihazda FBE'nin etkinleştirilmesi, cihazın dahili depolama biriminde ( userdata ) etkinleştirilmesini gerektirir. Bu aynı zamanda benimsenebilir depolamada FBE'yi otomatik olarak etkinleştirir; ancak gerektiğinde uyarlanabilir depolama birimindeki şifreleme formatı geçersiz kılınabilir.

Dahili depolama

FBE, userdata için fstab satırının fs_mgr_flags sütununa fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] seçeneğinin eklenmesiyle etkinleştirilir. Bu seçenek dahili depolama birimindeki şifreleme biçimini tanımlar. İki nokta üst üste ile ayrılmış en fazla üç parametre içerir:

• contents_encryption_mode parametresi, dosya içeriklerini şifrelemek için hangi şifreleme algoritmasının kullanıldığını tanımlar. aes-256-xts veya adiantum olabilir. Android 11'den bu yana aes-256-xts olan varsayılan algoritmayı belirtmek için boş da bırakılabilir.
• filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi şifreleme algoritmasının kullanıldığını tanımlar. aes-256-cts , aes-256-heh , adiantum veya aes-256-hctr2 olabilir. Belirtilmemişse, contents_encryption_mode aes-256-cts ise aes-256-xts veya contents_encryption_mode adiantum ise adiantum varsayılandır.
• Android 11'de yeni olan flags parametresi, + karakteriyle ayrılmış bayrakların bir listesidir. Aşağıdaki bayraklar desteklenir:
  • 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 ilkeleri daha güvenli ve esnek bir anahtar türetme işlevi kullanır. Cihaz Android 11 veya üzeri bir sürümde başlatıldıysa ( ro.product.first_api_level tarafından belirlendiği üzere) varsayılan v2'dir veya cihaz Android 10 veya daha düşük bir sürümde başlatıldıysa v1'dir.
  • 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 biçimini 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 (başlatma vektörleri) üretimi buna göre ayarlanır.
  • emmc_optimized bayrağı inlinecrypt_optimized bayrağına benzer, ancak aynı zamanda IV'leri 32 bit ile sınırlayan bir IV oluşturma yöntemini de seçer. Bu işaret yalnızca JEDEC eMMC v5.2 spesifikasyonuyla uyumlu olan ve dolayısıyla yalnızca 32 bit IV'leri destekleyen satır içi şifreleme donanımında kullanılmalıdır. Diğer satır içi şifreleme donanımlarında bunun yerine inlinecrypt_optimized kullanın. Bu bayrak hiçbir zaman 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ına olanak tanır. Bu yalnızca inlinecrypt bağlama seçeneğiyle 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 şeklindedir. 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ırma biçimi olmayan cihazlarda, fileencryption=adiantum ayarlanarak AES yerine Adiantum kullanılabilir.

Android 14'ten beri AES-HCTR2, hızlandırılmış şifreleme talimatlarına sahip cihazlar için tercih edilen dosya adı şifreleme modudur. Ancak yalnızca daha yeni Android çekirdekleri AES-HCTR2'yi destekler. Gelecekteki bir Android sürümünde dosya adlarının şifrelenmesi için varsayılan mod olması planlanıyor. Çekirdeğinizde AES-HCTR2 desteği varsa, filenames_encryption_mode aes-256-hctr2 olarak ayarlayarak dosya adları şifrelemesi için etkinleştirilebilir. En basit durumda bu fileencryption=aes-256-xts:aes-256-hctr2 ile yapılabilir.

Android 10 veya daha düşük bir sürümle başlatılan cihazlarda, FSCRYPT_MODE_PRIVATE dosya içeriği şifreleme modunun kullanımını belirtmek için fileencryption=ice de kabul edilir. Bu mod, Android ortak çekirdekleri tarafından 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 sonraki sürümlerle başlatılan cihazlarda bu moda artık izin verilmiyor ve bunun yerine standart bir şifreleme biçiminin kullanılması gerekiyor.

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ını kullanmak istiyorsanız 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 itibaren FBE ve uyarlanabilir depolama birlikte kullanılabilir.

userdata için fileencryption fstab seçeneğinin belirlenmesi, benimsenebilir depolama alanında hem FBE'nin hem de meta veri şifrelemesinin otomatik olarak etkinleştirilmesini sağlar. Ancak, PRODUCT_PROPERTY_OVERRIDES içindeki özellikleri ayarlayarak benimsenebilir depolamadaki FBE ve/veya meta veri şifreleme formatlarını geçersiz kılabilirsiniz.

Android 11 veya sonraki bir sürümle başlatılan cihazlarda aşağıdaki özellikleri kullanın:

• ro.crypto.volume.options (Android 11'de yeni), benimsenebilir depolamada FBE şifreleme formatını seçer. fileencryption fstab seçeneğinin argümanıyla aynı sözdizimine sahiptir ve aynı varsayılanları kullanır. Burada ne kullanılacağını öğrenmek için yukarıdaki fileencryption önerilerine bakın.
• ro.crypto.volume.metadata.encryption benimsenebilir depolamadaki meta veri şifreleme formatını seçer. Meta veri şifreleme belgelerine bakın.

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

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

Keymaster ile entegrasyon

Keymaster HAL, early_hal sınıfının bir parçası olarak başlatılmalıdır. Bunun nedeni, FBE'nin Keymaster'ın, vold başlangıç ​​anahtarlarını ayarladığı post-fs-data önyükleme aşamasında istekleri işlemeye hazır olmasını gerektirmesidir.

Dizinler hariç

init , sistem DE anahtarını, şifrelenmemiş olması gereken dizinler hariç, /data dosyasının tüm üst düzey dizinlerine uygular: sistem DE anahtarının kendisini içeren dizin ve kullanıcı CE veya DE dizinlerini içeren dizinler. Şifreleme anahtarları yinelemeli olarak uygulanır ve alt dizinler tarafından geçersiz kılınamaz.

Android 11 ve sonraki sürümlerde, init dizinlere uyguladığı anahtar, init komut dosyalarındaki mkdir komutunun encryption=<action> bağımsız değişkeni tarafından kontrol edilebilir. <action> 'ın olası değerleri Android başlangıç ​​dili için README dosyasında belgelenmiştir.

Android 10'da, init ​​şifreleme eylemleri aşağıdaki konuma kodlanmıştır:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

/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 üreticisinin yalnızca şifrelenmemiş dizini kullanması gereken uygulamalara erişim sağlayan SELinux ilkelerini içermesi gerekir. Bu, güvenilmeyen tüm uygulamaları hariç tutmalıdır.

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

Sistem uygulamalarında Doğrudan Önyüklemeyi destekleme

Uygulamaları Doğrudan Önyükleme konusunda duyarlı hale getirme

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

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

Uygulama düzeyindeki directBootAware özelliği, uygulamadaki tüm bileşenleri şifreleme uyumlu olarak işaretlemenin kısaltmasıdır.

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

Bu modda çalışırken, gerektiğinde CE depolaması tarafından desteklenen bir Bağlamı açıkça yönetmek için Cihaz Korumalı benzerlerine eşdeğer olan aşağıdaki Sistem API'leri kullanılabilir.

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

Birden fazla kullanıcıyı destekleme

Çok kullanıcılı bir ortamdaki her kullanıcı ayrı bir şifreleme anahtarı alır. Her kullanıcıya iki anahtar verilir: DE ve CE anahtarı. Özel bir kullanıcı olduğu için öncelikle 0 kullanıcısının cihazda oturum açması gerekir. Bu, Cihaz Yönetimi kullanımları için geçerlidir.

Kripto duyarlı uygulamalar kullanıcılar arasında şu şekilde etkileşime girer: INTERACT_ACROSS_USERS ve INTERACT_ACROSS_USERS_FULL , bir uygulamanın cihazdaki tüm kullanıcılar üzerinde işlem yapmasına olanak tanır. Ancak bu uygulamalar, halihazırda kilidi açılmış olan kullanıcılar için yalnızca CE şifreli dizinlere erişebilecek.

Bir uygulama DE alanları arasında serbestçe etkileşimde bulunabilir, 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ğine ayrıca iki anahtar verilir: 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üncelleştirmeleri yönetme

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

userdata bölümündeki OTA dosyasına erişmek için kurtarma gerektiren eski bir OTA çözümü kullanırken:

1. userdata bölümünde üst düzey bir dizin (örneğin misc_ne ) oluşturun.
2. Bu üst düzey dizini şifrelenmemiş olacak şekilde yapılandırın (bkz . Dizinleri hariç tutma ).
3. OTA paketlerini tutmak için üst düzey dizin içinde bir dizin oluşturun.
4. Bu dizine 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 dizini okuyabilmeli ve yazabilmelidir. Başka hiçbir uygulamanın veya işlemin bu dizine 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 öncelikle DirectBootHostTest ve EncryptionTest gibi birçok CTS şifreleme testini çalıştırın.

Cihaz Android 11 veya sonraki bir sürümünü çalıştırıyorsa vts_kernel_encryption_test komutunu da çalıştırın:

atest vts_kernel_encryption_test

veya:

vts-tradefed run vts -m vts_kernel_encryption_test

Ayrıca cihaz üreticileri aşağıdaki manuel testleri de yapabilirler. FBE'nin etkin olduğu bir cihazda:

• ro.crypto.state var olup olmadığını kontrol edin
  • ro.crypto.state şifrelendiğinden emin olun
• ro.crypto.type mevcut olup olmadığını kontrol edin
  • ro.crypto.type dosyasının file olarak ayarlandığından emin olun

Ek olarak, test uzmanları birincil kullanıcı üzerinde ayarlanmış bir kilit ekranıyla bir userdebug örneğini başlatabilir. Daha sonra cihaza adb kabuğu ekleyin ve root olmak için su kullanın. /data/data şifrelenmiş dosya adları içerdiğinden emin olun; eğer değilse, bir şeyler yanlış demektir.

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

AOSP uygulama ayrıntıları

Bu bölümde AOSP uygulamasına ilişkin ayrıntılar sağlanır ve dosya tabanlı şifrelemenin nasıl çalıştığı açıklanır. Cihaz üreticilerinin cihazlarında FBE ve Direct Boot kullanabilmesi için burada herhangi bir değişiklik yapmasına gerek kalmaması gerekiyor.

fscrypt şifreleme

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

• XTS modunda dosya içeriğini AES-256 ile şifreleyin
• CBC-CTS modunda dosya adlarını AES-256 ile şifreleyin

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

fscrypt, şifreleme politikalarının iki sürümünü destekler: sürüm 1 ve sürüm 2. Sürüm 1 kullanımdan kaldırılmıştır ve Android 11 ve sonraki sürümleriyle başlatılan cihazlar için CDD gereksinimleri yalnızca sürüm 2 ile uyumludur. Sürüm 2 şifreleme politikaları, gerçek verileri elde etmek için HKDF-SHA512'yi kullanır. Kullanıcı alanı tarafından sağlanan anahtarlardan şifreleme anahtarları.

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

Depolama sınıfları

Aşağıdaki tabloda FBE anahtarları ve korudukları dizinler daha ayrıntılı olarak listelenmektedir:

Anahtar saklama ve koruma

Tüm FBE anahtarları vold tarafından yönetilir ve hiç depolanmayan önyükleme başına anahtar hariç, diskte şifrelenmiş olarak saklanır. Aşağıdaki tabloda çeşitli FBE anahtarlarının saklandığı konumlar listelenmektedir:

Önceki tabloda gösterildiği gibi çoğu FBE anahtarı, başka bir FBE anahtarı tarafından şifrelenen dizinlerde saklanır. Anahtarları içeren depolama sınıfının kilidi açılana kadar anahtarların kilidi açılamaz.

vold ayrıca tüm FBE anahtarlarına bir şifreleme katmanı uygular. Dahili depolamaya yönelik CE anahtarları dışındaki her anahtar, TEE dışında gösterilmeyen kendi Anahtar Deposu anahtarı kullanılarak AES-256-GCM ile şifrelenir. Bu, Doğrulanmış Önyükleme tarafından zorunlu kılındığı gibi güvenilir bir işletim sistemi başlatılmadığı sürece FBE anahtarlarının kilidinin açılamamasını sağlar. Keystore anahtarında geri alma direnci de talep edilir; bu, Keymaster'ın geri alma direncini desteklediği cihazlarda FBE anahtarlarının güvenli bir şekilde silinmesine olanak tanır. Geri alma direncinin mevcut olmadığı durumlarda en iyi geri dönüş çabası olarak, anahtarın yanında saklanan secdiscardable dosyada saklanan 16384 rastgele baytlık SHA-512 karması, Anahtar Deposu anahtarının uygulama kimlik etiketi olarak kullanılır. Bir FBE anahtarını kurtarmak için tüm bu baytların kurtarılması gerekir.

Dahili depolamaya yönelik CE anahtarları, kullanıcının Kilit Ekranı Bilgi Faktörünü (LSKF) (PIN, desen veya parola), güvenli bir parola sıfırlama belirtecini veya istemci tarafının her ikisini de bilmeden kilitlerinin açılamamasını sağlayan daha güçlü bir koruma düzeyi alır. ve Yeniden Başlatmada Devam Etme işlemi için sunucu tarafı anahtarları. Parola sıfırlama belirteçlerinin yalnızca iş profilleri ve tam olarak yönetilen cihazlar için oluşturulmasına izin verilir.

Bunu başarmak için vold , kullanıcının sentetik parolasından türetilen bir AES-256-GCM anahtarını kullanarak dahili depolama için her CE anahtarını şifreler. Sentetik şifre, her kullanıcı için rastgele oluşturulan, değişmez, yüksek entropili bir kriptografik sırdır. system_server LockSettingsService sentetik şifreyi ve korunma yollarını yönetir.

Sentetik şifreyi LSKF ile korumak için LockSettingsService ilk olarak LSKF'yi scrypt üzerinden geçirerek genişletir ve yaklaşık 25 ms'lik bir süre ve yaklaşık 2 MiB'lik bir bellek kullanımını hedefler. LSKF'ler genellikle kısa olduğundan bu adım genellikle fazla güvenlik sağlamaz. Güvenliğin ana katmanı, aşağıda açıklanan Güvenli Öğe (SE) veya TEE tarafından uygulanan hız sınırlamasıdır.

Cihazda bir Güvenli Öğe (SE) varsa LockSettingsService , Weaver HAL'ı kullanarak uzatılmış LSKF'yi SE'de depolanan yüksek entropili rastgele bir gizli diziyle eşler. LockSettingsService daha sonra sentetik parolayı iki kez şifreler: ilki, uzatılmış LSKF ve Weaver sırrından türetilen bir yazılım anahtarıyla ve ikincisi, kimlik doğrulamaya bağlı olmayan bir Anahtar Deposu anahtarıyla. Bu, LSKF tahminlerinin SE tarafından zorlanan hız sınırlamasını sağlar.

Cihazın bir SE'si yoksa LockSettingsService bunun yerine uzatılmış LSKF'yi Gatekeeper şifresi olarak kullanır. LockSettingsService daha sonra sentetik parolayı iki kez şifreler: ilki, uzatılmış LSKF'den ve ikinci olarak atılabilir bir dosyanın karmasından türetilen bir yazılım anahtarıyla ve ikincisi, Gatekeeper kaydına kimlik doğrulaması yapılan bir Anahtar Deposu anahtarıyla. Bu, LSKF tahminlerinin TEE tarafından uygulanan oran sınırlamasını sağlar.

LSKF değiştirildiğinde LockSettingsService , sentetik parolanın eski LSKF'ye bağlanmasıyla ilişkili tüm bilgileri siler. Weaver'ı veya geri almaya dirençli Anahtar Deposu anahtarlarını destekleyen cihazlarda bu, eski bağlamanın güvenli bir şekilde silinmesini garanti eder. Bu nedenle burada anlatılan korumalar kullanıcının LSKF'si olmadığı durumlarda dahi uygulanır.