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 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 ve en güvenli deneyimi sunmak için Direct Boot API'lerini nasıl kullanabileceği açıklanmaktadır.

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

Doğrudan Önyükleme

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

Dosya tabanlı şifrelemenin (FBE) ve uygulamaları şifrelemeden haberdar eden yeni API'lerin kullanıma sunulmasıyla, bu uygulamaların sınırlı bir bağlamda çalışması mümkündür. Bu, kullanıcılar kimlik bilgilerini sağlamadan ve özel kullanıcı bilgilerini korumaya devam etmeden önce gerçekleşebilir.

FBE özellikli bir cihazda, cihazın her kullanıcısının uygulamalar için kullanabileceği iki depolama konumu vardır:

• 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 önyükleme zamanı parolasına dayalı olmadığından aynı anda birden fazla kullanıcının korunmasına olanak tanır.

Direct Boot API, şifrelemeye duyarlı uygulamaların bu alanların her birine erişmesine izin verir. Kilit ekranında kimlik bilgilerinin ilk girilmesine yanıt olarak bir kullanıcının CE deposunun 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. Bununla birlikte, FBE olmadan, DE ve CE depolaması her zaman kilitlenmemiş 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 özelliği optimize etmenin yollarını keşfetmek isteyebilir.

AOSP'deki tüm gerekli paketler, doğrudan önyüklemeye duyarlı 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 başlatmayı tanıyan paketlerin bulunduğundan emin olmak isteyeceklerdir:

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

Örnekler ve kaynak

Android, vold'un ( system/vold ) Android'de depolama cihazlarını ve birimleri yönetme işlevselliği sağladığı, dosya tabanlı şifrelemenin referans bir uygulamasını sağlar. FBE'nin eklenmesi, birden çok kullanıcının CE ve DE anahtarları için anahtar yönetimini desteklemek üzere çeşitli yeni komutlar sağlar. Çekirdekteki dosya tabanlı şifreleme yeteneklerini kullanmak için yapılan 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 bildirim özniteliğini kullanan sistem uygulamaları

AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutu çalıştırılarak şifrelemeye duyarlı uygulama ve hizmetlere ilişkin daha fazla örnek 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 üzeri Keymaster Desteği . Keymaster 0.3 için destek yoktur çünkü bu, gerekli yetenekleri sağlamaz veya şifreleme anahtarları için yeterli korumayı garanti etmez.
• Keymaster/ Keystore ve Gatekeeper, DE anahtarlarına koruma sağlamak için Güvenilir Yürütme Ortamında (TEE) uygulanmalıdır, böylece yetkisiz bir işletim sistemi (cihaza yüklenen özel işletim sistemi) DE anahtarlarını kolayca talep edemez.
• Donanım Güven Kökü ve Keymaster başlatmaya bağlı Doğrulanmış Önyükleme, DE anahtarlarına yetkisiz bir işletim sistemi tarafından erişilememesini sağlamak için gereklidir.

uygulama

Her şeyden önce, çalar saatler, telefon ve 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 sonraki sürümlerde 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 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ı destekleyecek veya dahili depolamada meta veri şifreleme kullanacaksa, meta veri şifreleme belgelerinde açıklandığı gibi meta veri şifreleme için gereken çekirdek yapılandırma seçeneklerini de etkinleştirin.

Ext4 veya F2FS şifreleme için işlevsel desteğe ek olarak, cihaz üreticileri 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, aşağıdaki çekirdek yapılandırma seçenekleri ayarlanarak ARMv8 CE (Kriptografi Uzantıları) hızlandırması 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, depolama cihazına giderken/cihazdan giderken verileri şifreleyen/şifresini çözen satır 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ü 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

Bir cihazda FBE'nin etkinleştirilmesi, dahili depolamada ( userdata ) etkinleştirilmesini gerektirir. Bu ayrıca FBE'yi uyarlanabilir depolamada otomatik olarak etkinleştirir; ancak, uyarlanabilir depolamadaki şifreleme formatı gerekirse 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ği eklenerek etkinleştirilir. Bu seçenek, dahili depolamadaki şifreleme formatını tanımlar. En fazla üç kolonla ayrılmış parametre içerir:

• contents_encryption_mode parametresi, dosya içeriklerini şifrelemek için hangi kriptografik algoritmanı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 de boş bırakılabilir.
• filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi kriptografik algoritmanın kullanıldığını tanımlar. aes-256-cts , aes-256-heh , adiantum veya aes-256-hctr2 olabilir. Belirtilmezse, contents_encryption_mode aes-256-cts ise varsayılan olarak aes aes-256-xts cts'dir veya contents_encryption_mode adiantum ise adiantum .
• 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 ilkelerini seçer; v2 bayrağı, sürüm 2 şifreleme ilkelerini 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 daha yüksek bir sürümde başlatıldıysa ( ro.product.first_api_level tarafından belirlendiği şekilde) varsayılan v2 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 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 (başlatma vektörleri) üretimi buna göre ayarlanır.
  • emmc_optimized işareti, inlinecrypt_optimized ile benzerdir, ancak 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 belirtimi ile uyumlu ve bu nedenle 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 işaret, hiçbir zaman UFS tabanlı depolamada kullanılmamalıdır; UFS spesifikasyonu, 64 bit IV'lerin kullanımına izin verir.
  • Donanımla sarmalanmış anahtarları destekleyen cihazlarda, wrappedkey_v0 bayrağı, FBE için donanımla sarmalanmış 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 şeklindedir. Satır içi şifreleme donanımı kullanıyorsanız, çoğu cihaz için önerilen ayar şu şekildedir fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (veya eşdeğeri olarak fileencryption=::inlinecrypt_optimized ). Herhangi bir AES hızlandırması olmayan cihazlarda, fileencryption=adiantum ayarlanarak AES yerine Adiantum kullanılabilir.

Android 14'ten (AOSP deneysel) bu yana, AES-HCTR2, hızlandırılmış kriptografi 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 adı şifrelemesi için varsayılan mod olması planlanmaktadır. Çekirdeğinizin AES-HCTR2 desteği varsa, filenames_encryption_mode aes-256-hctr2 olarak ayarlayarak dosya adı şifrelemesi için etkinleştirilebilir. En basit durumda bu fileencryption=aes-256-xts:aes-256-hctr2 ile yapılır.

Android 10 veya önceki sürümleriyle 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 formatı satıcıya özeldi. Android 11 veya sonraki sürümleri çalıştıran 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 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 bu yana, FBE ve kabul edilebilir depolama birlikte kullanılabilir.

userdata için fileencryption fstab seçeneğinin belirtilmesi, benimsenebilir depolamada hem FBE hem de meta veri şifrelemeyi otomatik olarak etkinleştirir. Ancak, PRODUCT_PROPERTY_OVERRIDES içindeki özellikleri ayarlayarak, kabul edilebilir depolamada FBE ve/veya meta veri şifreleme biçimlerini geçersiz kılabilirsiniz.

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

• ro.crypto.volume.options (Android 11'de yeni), kabul edilebilir depolamada FBE şifreleme biçimini 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 uyarlanabilir depolamada meta veri şifreleme biçimini seçer. Meta veri şifreleme belgelerine bakın.

Android 10 veya önceki 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, ro.crypto.volume.options öğesinin iki nokta üst üste ayrılmış alanına eşdeğerdir.
• 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 eşdeğerdir, ancak Android 10 veya önceki sürümleriyle başlatılan cihazlarda varsayılan değer aes-256-heh . Ç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 kabul edilebilir 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 ilk anahtarları 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 dışında tüm üst düzey /data 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 üzeri sürümlerde, init dizinlere uyguladığı anahtar, init betiklerindeki mkdir komutuna yönelik encryption=<action> argümanı tarafından kontrol edilebilir. <action> öğesinin olası değerleri , Android başlangıç ​​dili için README'de belgelenmiştir.

Android 10'da, init şifreleme işlemleri aşağıdaki konuma sabit olarak 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 tamamen önlemek için istisnalar eklemek mümkündür. Bu türden değişiklikler yapılırsa, cihaz üreticisi, yalnızca şifrelenmemiş dizini kullanması gereken uygulamalara erişim sağlayan SELinux ilkelerini içermelidir. 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üklemeye duyarlı hale getirme

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 herkes tarafından kullanılabilir.

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

Uygulama düzeyindeki directBootAware özniteliği, uygulamadaki tüm bileşenleri şifreleme farkında olarak işaretlemek için kısa yoldur.

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

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

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

Birden çok kullanıcıyı destekleme

Çok kullanıcılı bir ortamda her kullanıcı ayrı bir şifreleme anahtarı alır. Her kullanıcıya iki anahtar verilir: DE ve CE anahtarı. Kullanıcı 0, özel bir kullanıcı olduğu için önce cihaza giriş yapmalıdır. Bu, Cihaz Yönetimi kullanımları için geçerlidir.

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

Bir uygulama, DE alanlarında serbestçe etkileşim kurabilir, 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 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.

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 bir üst düzey dizin (örneğin misc_ne ) oluşturun.
2. Bu üst düzey dizini şifrelenmemiş olacak şekilde yapılandırın (bkz . Dizinler hariç ).
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 okuyup yazabilmelidir. Başka hiçbir uygulama veya işlemin bu dizine erişimi olmamalıdır.

Doğrulama

Özelliğin uygulanan sürümünün istendiği gibi çalışmasını sağlamak 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 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 gerçekleştirebilir. FBE'nin etkin olduğu bir cihazda:

• ro.crypto.state var olduğunu kontrol edin
  • ro.crypto.state şifrelendiğinden emin olun
• ro.crypto.type var olduğunu kontrol edin
  • ro.crypto.type file olarak ayarlandığından emin olun

Ek olarak, test kullanıcıları, birincil kullanıcı üzerinde ayarlanmış bir kilit ekranı ile bir userdebug örneğini önyükleyebilir. Ardından cihaza kabuk adb ve kök olmak için su kullanın. /data/data şifrelenmiş dosya adları içerdiğinden emin olun; eğer değilse, bir şeyler yanlıştır.

Cihaz üreticileri ayrıca cihazlarında veya çekirdeklerinde fscrypt için yukarı akış Linux testlerini çalıştırmayı keşfetmeye teşvik edilir. 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üm, AOSP uygulaması hakkında ayrıntılar sağlar ve dosya tabanlı şifrelemenin nasıl çalıştığını açıklar. Cihaz üreticilerinin cihazlarında FBE ve Direct Boot kullanabilmeleri için burada herhangi bir değişiklik yapmasına gerek kalmamalı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 şifrelemesi de desteklenmektedir. Adiantum şifreleme 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 üstü ile başlayan cihazlar için CDD gereksinimleri yalnızca sürüm 2 ile uyumludur. Sürüm 2 şifreleme ilkeleri, gerçek değeri 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 tablo, FBE anahtarlarını ve korudukları dizinleri daha ayrıntılı olarak listeler:

Anahtar saklama ve koruma

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

Önceki tabloda gösterildiği gibi, çoğu FBE anahtarı, başka bir FBE anahtarı tarafından şifrelenen dizinlerde depolanı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 depolama için CE anahtarlarının yanı sıra her anahtar, TEE dışında açığa çıkmayan 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 önyüklenmedikçe FBE anahtarlarının kilidinin açılamamasını sağlar. Keymaster'ın geri alma direncini desteklediği cihazlarda FBE anahtarlarının güvenli bir şekilde silinmesine izin veren Keystore anahtarında geri alma direnci de talep edilir. Geri alma direncinin mevcut olmadığı durumlarda en iyi çaba geri dönüşü olarak, anahtarın yanında saklanan secdiscardable dosyada saklanan 16384 rasgele baytlık SHA-512 karması, Anahtar Deposu anahtarının uygulama kimliği etiketi olarak kullanılır. Bir FBE anahtarını kurtarmak için tüm bu baytların kurtarılması gerekir.

Dahili depolama için CE anahtarları, kullanıcının Kilit Ekranı Bilgi Faktörü (LSKF) (PIN, model veya parola), güvenli parola sıfırlama belirteci veya her ikisi de istemci tarafı bilinmeden 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 parola, her kullanıcı için rasgele oluşturulan değişmez, yüksek entropili bir kriptografik sırdır. system_server içindeki LockSettingsService sentetik parolayı ve korunma yollarını yönetir.

Sentetik parolayı LSKF ile korumak için, LockSettingsService önce LSKF'yi scrypt içinden geçirerek genişletir, yaklaşık 25 ms'lik bir süreyi 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. Ana güvenlik katmanı, aşağıda açıklanan Güvenli Öğe (SE) veya TEE tarafından uygulanan hız sınırlamasıdır.

Aygıtta bir Güvenli Öğe (SE) varsa, LockSettingsService uzatılmış LSKF'yi Weaver HAL kullanarak SE'de saklanan yüksek entropili rastgele bir sır ile eşler. LockSettingsService daha sonra yapay parolayı iki kez şifreler: ilk olarak, 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 uygulanan oran sınırlamasını sağlar.

Aygıtın bir SE'si yoksa LockSettingsService bunun yerine genişletilmiş LSKF'yi Gatekeeper parolası olarak kullanır. LockSettingsService daha sonra yapay parolayı iki kez şifreler: birincisi, uzatılmış LSKF'den türetilen bir yazılım anahtarı ve bir silinebilir dosyanın karması ile ve ikincisi, Gatekeeper kaydına kimlik doğrulaması ile bağlanan 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 açıklanan korumalar, kullanıcının bir LSKF'si olmadığında bile uygulanır.