Dosya tabanlı şifreleme

Android 7.0 ve sonraki sürümlerde dosya tabanlı şifreleme (FBE) desteklenir. Dosya tabanlı şifreleme, farklı dosyaların bağımsız olarak kilidi 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 doğrudan başlatma API'lerini nasıl kullanabileceği açıklanmaktadır.

Android 10 ve sonraki sürümlerle kullanıma sunulan tüm cihazlarda dosya tabanlı şifreleme kullanılması zorunludur.

Doğrudan Başlatma

Dosya tabanlı şifreleme, Android 7.0'da kullanıma sunulan Direct Boot adlı yeni bir özelliği etkinleştirir. Doğrudan başlatma, şifrelenmiş cihazların doğrudan kilit ekranına başlatılmasına olanak tanır. Daha önce, tam disk şifreleme (FDE) kullanan şifrelenmiş cihazlarda, herhangi bir veriye erişilebilmesi için kullanıcıların kimlik bilgilerini sağlaması gerekiyordu. Bu durum, telefonun en temel işlemler dışında herhangi bir işlem yapmasını engelliyordu. Örneğin, alarmlar çalışmıyor, erişilebilirlik hizmetleri kullanılamıyor ve telefonlar arama alamıyor ancak yalnızca temel acil durum arama işlemleriyle sınırlı kalıyordu.

Dosya tabanlı şifrelemenin (FBE) ve uygulamaların şifrelemeyi algılamasını sağlayan yeni API'lerin kullanıma sunulmasıyla birlikte, bu uygulamaların sınırlı bir bağlamda çalışması mümkün hale geldi. Bu, kullanıcılar kimlik bilgilerini sağlamadan önce gerçekleşebilir ve özel kullanıcı bilgileri korunmaya devam eder.

FBE'nin etkin olduğu bir cihazda, cihazın her kullanıcısı için uygulamaların kullanabileceği iki depolama alanı bulunur:

• Varsayılan depolama konumu olan ve yalnızca kullanıcı cihazın kilidini açtıktan sonra kullanılabilen Kimlik Bilgisi Şifreli (CE) depolama alanı.
• Cihaz şifreli (DE) depolama alanı: Hem doğrudan başlatma modunda hem de kullanıcı cihazın kilidini açtıktan sonra kullanılabilen bir depolama alanıdır.

Bu ayrım, şifreleme artık yalnızca başlatma zamanı şifresine dayanmadığı için birden fazla kullanıcının aynı anda korunmasına olanak tanıyarak iş profillerini daha güvenli hale getirir.

Direct Boot API, şifreleme konusunda bilgili uygulamaların bu alanların her birine erişmesine olanak tanır. Kullanıcı, kilit ekranında ilk kez kimlik bilgilerini girdiğinde CE depolama alanı kilidinin açılması durumunda veya iş profili için iş sorgusu sağlandığında uygulamaları bilgilendirme ihtiyacını karşılamak için uygulama yaşam döngüsünde değişiklikler yapıldı. Android 7.0 çalıştıran cihazlar, FBE'yi uygulayıp uygulamadıklarına bakılmaksızın bu yeni API'leri ve yaşam döngülerini desteklemelidir. Ancak FBE olmadan DE ve CE depolama alanları her zaman kilidi açılmış durumda olur.

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ı tercih eden üreticiler, kullanılan çip üzerinde sisteme (SoC) göre özelliği optimize etmenin yollarını araştırabilir.

AOSP'deki tüm gerekli paketler doğrudan başlatma özelliğini destekleyecek şekilde güncellendi. Ancak cihaz üreticileri bu uygulamaların özelleştirilmiş sürümlerini kullandığında en azından aşağıdaki hizmetleri sağlayan doğrudan başlatmaya uygun paketlerin olmasını ister:

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

Örnekler ve kaynak

Android, dosya tabanlı şifrelemenin referans uygulamasını sağlar. Bu uygulamada vold (system/vold), Android'de depolama cihazlarını ve birimlerini yönetme işlevini sağlar. FBE'nin eklenmesi, vold'a birden fazla kullanıcının CE ve DE anahtarlarının anahtar yönetimini desteklemek için çeşitli yeni komutlar sağlar. Çekirdekte dosya tabanlı şifreleme özelliklerini kullanmaya yönelik temel değişikliklerin yanı sıra kilit ekranı ve SystemUI gibi birçok sistem paketi, FBE ve doğrudan başlatma özelliklerini destekleyecek şekilde değiştirildi. Bunlardan bazıları:

• AOSP Çevirici (packages/apps/Dialer)
• Masa Saati (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Ayarlar uygulaması (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* defaultToDeviceProtectedStorage manifest özelliğini kullanan sistem uygulamaları

Şifreleme konusunda bilgi sahibi olan uygulama ve hizmetlerin diğer örneklerini, AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutunu çalıştırarak bulabilirsiniz.

Bağımlılıklar

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

• Ext4 şifreleme veya F2FS şifreleme için çekirdek desteği.
• KeyMint (veya Keymaster 1.0 ya da sonraki bir sürüm) Desteği. Keymaster 0.3, gerekli özellikleri sağlamadığı veya şifreleme anahtarları için yeterli koruma sağlamadığı için desteklenmez.
• KeyMint/Keymaster ve Gatekeeper, DE anahtarlarının korunması 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ı basitçe isteyemez.
• DE anahtarlarına yetkisiz bir işletim sistemi tarafından erişilememesini sağlamak için KeyMint başlatma işlemine bağlı Donanım Güven Kökü ve Doğrulanmış Başlatma gereklidir.

Uygulama

Öncelikle, alarm, telefon ve erişilebilirlik özellikleri gibi uygulamalar, Direct Boot geliştirici belgelerine göre android:directBootAware olarak ayarlanmalıdır.

Çekirdek desteği

Ext4 ve F2FS şifreleme için çekirdek desteği, Android ortak çekirdeklerinin 3.18 ve sonraki sürümlerinde mevcuttur. 5.1 veya sonraki bir sürümdeki çekirdekte etkinleştirmek için şunu kullanın:

CONFIG_FS_ENCRYPTION=y

Daha eski çekirdeklerde, cihazınızın CONFIG_EXT4_ENCRYPTION=y dosya sistemi Ext4 ise userdata, cihazınızın userdata dosya sistemi F2FS ise CONFIG_F2FS_FS_ENCRYPTION=y kullanın.

Cihazınız adoptable storage'ı destekliyorsa veya dahili depolama alanında metadata encryption kullanıyorsa metadata encryption documentation'da açıklandığı gibi meta veri şifreleme için gereken çekirdek yapılandırma seçeneklerini de etkinleştirin.

Cihaz üreticileri, Ext4 veya F2FS şifrelemesi için işlevsel desteğin yanı sıra 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 (Cryptography Extensions) 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, veriler depolama cihazına giderken/gelirken şifreleyen/şifresini çözen satır içi şifreleme donanımı uygulamayı da düşünebilir. Android ortak çekirdekleri (4.14 ve sonraki sürümler), donanım ve satıcı sürücüsü desteği 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ızda UFS tabanlı depolama kullanılı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'yi etkinleştirmek için dahili depolama alanında (userdata) etkinleştirmeniz gerekir. Bu işlem, FBE'yi kabul edilebilir depolama alanında da otomatik olarak etkinleştirir. Ancak gerekirse kabul edilebilir depolama alanındaki şifreleme biçimi geçersiz kılınabilir.

Dahili depolama

FBE, fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] seçeneği fstab satırının fs_mgr_flags sütununa eklenerek etkinleştirilir.userdata Bu seçenek, dahili depolama alanındaki şifreleme biçimini tanımlar. İki nokta işaretiyle 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 itibaren, varsayılan algoritmayı (aes-256-xts) belirtmek için boş da bırakılabilir.
• filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi şifreleme algoritmasının kullanılacağını tanımlar. Şunlardan biri olabilir: aes-256-cts, aes-256-heh, adiantum veya aes-256-hctr2. Belirtilmezse contents_encryption_mode değeri aes-256-xts ise varsayılan olarak aes-256-cts, contents_encryption_mode değeri adiantum ise varsayılan olarak adiantum olur.
• Android 11'de yeni olan flags parametresi, + karakteriyle ayrılmış bir işaret listesidir. Aşağıdaki işaretler desteklenir:
  • v1 işareti, sürüm 1 şifreleme politikalarını; v2 işareti ise sürüm 2 şifreleme politikalarını seçer. Sürüm 2 şifreleme politikalarında daha güvenli ve esnek bir anahtar türetme işlevi kullanılır. Cihaz, Android 11 veya sonraki bir sürümde kullanıma sunulduysa (ro.product.first_api_level tarafından belirlendiği şekilde) varsayılan olarak v2, Android 10 veya önceki bir sürümde kullanıma sunulduysa v1 kullanılır.
  • inlinecrypt_optimized işareti, çok sayıda anahtarı verimli bir şekilde işlemeyen satır içi şifreleme donanımı için optimize edilmiş bir şifreleme biçimi 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) oluşturulması buna göre ayarlanır.
  • emmc_optimized işareti, inlinecrypt_optimized işaretine benzer ancak IV'leri 32 bit ile sınırlayan bir IV oluşturma yöntemi de seçer. Bu işaret yalnızca JEDEC eMMC v5.2 spesifikasyonuna uygun olan 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ı depolama alanında kullanılmamalıdır. UFS spesifikasyonu, 64 bit IV'lerin kullanılmasına izin verir.
  • Donanım destekli anahtarları destekleyen cihazlarda wrappedkey_v0 işareti, FBE için donanım destekli anahtarların kullanılmasını sağlar. Bu seçenek yalnızca inlinecrypt bağlama seçeneği ve inlinecrypt_optimized veya emmc_optimized işaretiyle birlikte kullanılabilir.
  • dusize_4k işareti, dosya sistemi blok boyutu 4096 bayt olmasa bile şifreleme veri birimi boyutunun 4096 bayt olmasını zorlar. Şifreleme veri birimi boyutu, dosya içeriklerinin şifrelemesinin ayrıntı düzeyidir. Bu işaret, Android 15'ten itibaren kullanılabilir. Bu işaret yalnızca 4096 bayttan büyük veri birimlerini desteklemeyen satır içi şifreleme donanımının, 4096 bayttan büyük sayfa boyutu kullanan ve f2fs dosya sistemini kullanan bir cihazda kullanılmasını sağlamak için kullanılmalıdır.

Satır içi şifreleme donanımı kullanmıyorsanız çoğu cihaz için önerilen ayar fileencryption=aes-256-xts'dır. 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'dır (veya eşdeğeri olan fileencryption=::inlinecrypt_optimized). Herhangi bir AES hızlandırması olmayan cihazlarda fileencryption=adiantum ayarlanarak AES yerine Adiantum kullanılabilir.

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

Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda, FSCRYPT_MODE_PRIVATE dosya içeriği şifreleme modunun kullanımını belirtmek için fileencryption=ice da kabul edilir. Bu mod, Android'in ortak çekirdekleri tarafından uygulanmaz ancak özel çekirdek yamaları kullanan satıcılar tarafından uygulanabilir. Bu modda üretilen disk üzerindeki biçim, satıcıya özgüydü. Android 11 veya sonraki sürümlerle kullanıma sunulan cihazlarda bu moda artık izin verilmiyor ve bunun yerine standart bir şifreleme biçimi kullanılması gerekiyor.

Varsayılan olarak, dosya içeriği şifreleme işlemi Linux çekirdeğinin kriptografi 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 şu şekilde 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

Dahili hale getirilebilir depolama alanı

Android 9'dan itibaren FBE ve adaptable storage birlikte kullanılabilir.

fileencryption için userdata fstab seçeneğinin belirtilmesi, uyarlanabilir depolama alanında hem FBE hem de meta veri şifrelemeyi otomatik olarak etkinleştirir. Ancak PRODUCT_PROPERTY_OVERRIDES içinde özellikleri ayarlayarak FBE veya meta veri şifreleme biçimlerini, kullanılabilir depolama alanında geçersiz kılabilirsiniz.

Android 11 veya sonraki sürümlerle kullanıma sunulan cihazlarda aşağıdaki özellikleri kullanın:

• ro.crypto.volume.options (Android 11'de yeni) kabul edilebilir depolama alanında FBE şifreleme biçimini seçer. fileencryption fstab seçeneğinin bağımsız değişkeniyle aynı söz dizimine sahiptir ve aynı varsayılanları kullanır. Burada ne kullanacağınızla ilgili olarak yukarıdaki fileencryption için önerilere bakın.
• ro.crypto.volume.metadata.encryption, kabul edilebilir depolama biriminde meta veri şifreleme biçimini seçer. Meta veri şifreleme belgelerini inceleyin.

Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda aşağıdaki özellikleri kullanın:

• ro.crypto.volume.contents_mode, içeriklerin şifreleme modunu seçer. Bu, ro.crypto.volume.options öğesinin iki nokta üst üste ile ayrılmış ilk alanına eşdeğerdir.
• ro.crypto.volume.filenames_mode dosya adlarının şifreleme modunu seçer. Bu, ro.crypto.volume.options öğesinin iki nokta üst üste ile ayrılmış ikinci alanına eş değerdir. Ancak Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda varsayılan değer aes-256-heh'dir. Çoğu cihazda bu değerin 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 depolama alanında meta veri şifreleme biçimini seçin. Meta veri şifreleme belgelerini inceleyin.

KeyMint ile entegrasyon

KeyMint HAL, early_hal sınıfının bir parçası olarak başlatılmalıdır. Bunun nedeni, FBE'nin, post-fs-data önyükleme aşamasında istekleri işlemek için KeyMint'in hazır olmasını gerektirmesidir. Bu aşamada vold ilk anahtarları ayarlar.

Dizinleri hariç tutma

init, /data'nin tüm üst düzey dizinlerine sistem DE anahtarını uygular. Ancak sistem DE anahtarının kendisini içeren dizin ve kullanıcı CE veya DE dizinlerini içeren dizinler gibi şifrelenmemiş olması gereken dizinler bu kapsam dışındadır. Şifreleme anahtarları özyinelemeli olarak uygulanır ve alt dizinler tarafından geçersiz kılınamaz.

Android 11 ve sonraki sürümlerde, dizinler için geçerli olan anahtar, init komut dosyalarındaki mkdir komutunun encryption=<action> bağımsız değişkeniyle kontrol edilebilir.init <action> için olası değerler, Android başlatma dili için README dosyasında açıklanmıştır.

Android 10'da init şifreleme işlemleri aşağıdaki konuma sabit kodlanmıştır:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Belirli dizinlerin hiç şifrelenmemesi için istisnalar ekleyebilirsiniz. Bu tür değişiklikler yapılırsa cihaz üreticisi, yalnızca şifrelenmemiş dizini kullanması gereken uygulamalara erişim izni veren SELinux politikaları eklemelidir. Bu işlem, güvenilmeyen tüm uygulamaları hariç tutar.

Bu işlev için bilinen tek kabul edilebilir kullanım alanı, eski OTA özelliklerini desteklemektir.

Sistem uygulamalarında doğrudan başlatmayı destekleme

Uygulamaları doğrudan başlatmaya uygun hale getirme

Sistem uygulamalarının hızlı taşınmasını kolaylaştırmak için uygulama düzeyinde ayarlanabilen 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 konusunda bilgili olarak işaretlemenin kısaltmasıdır.

defaultToDeviceProtectedStorage özelliği, varsayılan uygulama depolama konumunu CE depolama alanı yerine DE depolama alanına yönlendirir. Bu işareti 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, depoladıkları verilerin kişisel bilgi içermediğinden emin olmak için bu verileri dikkatlice incelemelidir.

Bu modda çalışırken, gerektiğinde CE depolama alanı tarafından desteklenen bir bağlamı açıkça yönetmek için aşağıdaki sistem API'leri kullanılabilir. Bu API'ler, cihaz tarafından korunan benzerleriyle aynı işlevi görür.

• 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ı iki anahtar alır: bir DE anahtarı ve bir CE anahtarı. Özel bir kullanıcı olduğundan User 0 önce cihazda oturum açmalıdır. Bu, Cihaz Yönetimi kullanımları için geçerlidir.

Kripto para birimiyle ilgili uygulamalar, kullanıcılar arasında şu şekilde etkileşim kurar: INTERACT_ACROSS_USERS ve INTERACT_ACROSS_USERS_FULL uygulamanın cihazdaki tüm kullanıcılar adına işlem yapmasına izin verir. Ancak bu uygulamalar, yalnızca kilidi açılmış kullanıcıların CE ile şifrelenmiş dizinlerine erişebilir.

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 de iki anahtar alır: DE ve CE. İşle ilgili zorluk karşılandığında profil kullanıcısının kilidi açılır ve KeyMint (TEE'de) profilin TEE anahtarını sağlayabilir.

Güncellemeleri yönetme

Kurtarma bölümü, userdata bölümündeki DE ile korunan depolama alanına erişemiyor. FBE'yi 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ş olarak yapılandırın (bkz. Dizinleri hariç tutma).
3. OTA paketlerini barındırmak 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üncellemeleri alan işlemler veya uygulamalar bu dizini okuyup yazabilir. Başka hiçbir uygulama veya işlem bu dizine erişmemelidir.

Doğrulama

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

Cihazda Android 11 veya sonraki bir sürüm çalışı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

Ayrıca, cihaz üreticileri aşağıdaki manuel testleri de yapabilir. FBE'nin etkinleştirildiği bir cihazda:

• ro.crypto.state öğesinin mevcut olduğunu kontrol edin
  • ro.crypto.state adlı dosyanın şifrelendiğinden emin olun
• ro.crypto.type öğesinin mevcut olduğunu kontrol edin
  • ro.crypto.type değerinin file olarak ayarlandığından emin olun.

Ayrıca, test kullanıcıları, cihaz ilk kez başlatıldıktan sonra kilidi açılmadan önce CE depolama alanının kilitli olduğunu doğrulayabilir. Bunu yapmak için userdebug veya eng derlemesini kullanın, ana kullanıcıda PIN, desen veya şifre belirleyin ve cihazı yeniden başlatın. Cihazın kilidini açmadan önce, ana kullanıcının CE depolama alanını kontrol etmek için aşağıdaki komutu çalıştırın. Cihazda gözetimsiz sistem kullanıcı modu kullanılıyorsa (çoğu otomotiv cihazı) ana kullanıcı 10 numaralı kullanıcıdır. Bu nedenle şu komutu çalıştırın:

adb root; adb shell ls /data/user/10

Diğer cihazlarda (otomotiv dışı çoğu cihaz) ana kullanıcı, kullanıcı 0'dır. Bu nedenle şu komutu çalıştırın:

adb root; adb shell ls /data/user/0

Listelenen dosya adlarının Base64 kodlu olduğunu doğrulayın. Bu, dosya adlarının şifrelendiğini ve şifrelerini çözmek için gereken anahtarın henüz kullanılamadığını gösterir. Dosya adları düz metin olarak listeleniyorsa bir sorun var demektir.

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

AOSP uygulama ayrıntıları

Bu bölümde, AOSP uygulamasıyla ilgili ayrıntılar ve dosya tabanlı şifrelemenin işleyiş şekli açıklanmaktadır. Cihaz üreticilerinin, cihazlarında FBE ve doğrudan başlatma özelliğini kullanmak için burada herhangi bir değişiklik yapması gerekmez.

fscrypt şifrelemesi

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 şifreleme
• Dosya adlarını CBC-CTS modunda AES-256 ile şifreleme

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

fscrypt, şifreleme politikalarının 1. ve 2. sürümlerini destekler. 1. sürüm kullanımdan kaldırıldı. Android 11 ve sonraki sürümlerle kullanıma sunulan cihazlar için CDD şartları yalnızca 2. sürümle uyumludur. 2. sürüm şifreleme politikaları, kullanıcı alanında sağlanan anahtarlardan gerçek şifreleme anahtarlarını türetmek için HKDF-SHA512'yi kullanır.

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 listelenmiştir:

Anahtar depolama ve koruma

Tüm FBE anahtarları vold tarafından yönetilir ve hiç depolanmayan her yeniden başlatma anahtarı hariç olmak üzere diskte şifrelenmiş olarak saklanır. Aşağıdaki tabloda, çeşitli FBE anahtarlarının depolandığı konumlar listelenmiştir:

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

vold ayrıca tüm FBE anahtarlarına bir şifreleme katmanı uygular. Dahili depolama için kullanılan CE anahtarları dışındaki tüm anahtarlar, TEE dışında kullanıma sunulmayan kendi anahtar deposu anahtarı kullanılarak AES-256-GCM ile şifrelenir. Bu sayede, Doğrulanmış Başlatma tarafından zorunlu kılınan şekilde, güvenilir bir işletim sistemi başlatılmadığı sürece FBE anahtarlarının kilidinin açılamaması sağlanır. Ayrıca, KeyMint'in geri alma direncini desteklediği cihazlarda FBE anahtarlarının güvenli bir şekilde silinmesine olanak tanıyan Keystore anahtarında geri alma direnci de istenir. Geri alma direncinin kullanılamadığı durumlarda en iyi çaba geri dönüşü olarak, anahtarla birlikte depolanan secdiscardable dosyasında depolanan 16384 rastgele baytın SHA-512 karması, Keystore anahtarının Tag::APPLICATION_ID olarak kullanılır. Bir FBE anahtarını kurtarmak için bu baytların tümünün kurtarılması gerekir.

Dahili depolama alanındaki CE anahtarları, kullanıcının kilit ekranı bilgi faktörü (LSKF) (PIN, desen veya şifre), güvenli geçiş kodu sıfırlama jetonu ya da yeniden başlatma işleminde devam ettirme için hem istemci tarafı hem de sunucu tarafı anahtarları bilinmeden kilidinin açılamamasını sağlayan daha güçlü bir koruma düzeyine sahiptir. Şifre kodu sıfırlama jetonları yalnızca iş profilleri ve tümüyle yönetilen cihazlar için oluşturulabilir.

Bunu yapmak için vold, kullanıcının sentezlenmiş şifresinden türetilen bir AES-256-GCM anahtarı kullanarak dahili depolama için her CE anahtarını şifreler. Sentezlenmiş şifre, her kullanıcı için rastgele oluşturulan, değişmez ve yüksek entropili bir kriptografik sırdır. LockSettingsService, system_server içinde yapay şifreyi ve korunma şekillerini yönetir.

LSKF ile sentetik şifreyi korumak için, LockSettingsService öncelikle LSKF'yi yaklaşık 25 ms'lik bir süre ve yaklaşık 2 MiB'lik bir bellek kullanımı hedefleyerek scrypt'den geçirerek uzatır. LSKF'ler genellikle kısa olduğundan bu adım genellikle fazla güvenlik sağlamaz. Temel güvenlik katmanı, aşağıda açıklanan güvenli öğe (SE) veya TEE tarafından zorunlu kılınan sıklık sınırlamasıdır.

Cihazda Güvenli Element (SE) varsa LockSettingsService uzatılmış LSKF'yi Weaver HAL kullanarak SE'de depolanan yüksek entropili rastgele bir gizli değere eşler. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: önce uzatılmış LSKF ve Weaver gizli kodundan türetilen bir yazılım anahtarıyla, ardından da kimlik doğrulama ile sınırlı olmayan bir Keystore anahtarıyla. Bu, LSKF tahminlerinin SE tarafından zorunlu kılınan sıklık sınırını sağlar.

Cihazda SE yoksa LockSettingsService bunun yerine Gatekeeper şifresi olarak uzatılmış LSKF'yi kullanır. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: İlk olarak, uzatılmış LSKF'den ve silinebilir bir dosyanın karma değerinden türetilen bir yazılım anahtarıyla, ikinci olarak da Gatekeeper kaydına kimlik doğrulama ile bağlı bir anahtar deposu anahtarıyla. Bu, LSKF tahminlerinin TEE ile zorunlu kılınan sıklık sınırını sağlar.

LSKF değiştirildiğinde LockSettingsService, yapay şifrenin eski LSKF'ye bağlanmasıyla ilişkili tüm bilgileri siler. Weaver'ı veya geri çekmeye dirençli Keystore anahtarlarını destekleyen cihazlarda bu işlem, eski bağlamanın güvenli bir şekilde silinmesini sağlar. Bu nedenle, kullanıcıda LSKF olmasa bile burada açıklanan korumalar uygulanır.