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
veyaadiantum
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
veyaaes-256-hctr2
. Belirtilmezsecontents_encryption_mode
değeriaes-256-xts
ise varsayılan olarakaes-256-cts
,contents_encryption_mode
değeriadiantum
ise varsayılan olarakadiantum
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 yerineinlinecrypt_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ızcainlinecrypt
bağlama seçeneği veinlinecrypt_optimized
veyaemmc_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ıdakifileencryption
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ğeraes-256-heh
'dir. Çoğu cihazda bu değerin açıkçaaes-256-cts
olarak geçersiz kılınması gerekir.ro.crypto.fde_algorithm
vero.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:
userdata
bölümünde üst düzey bir dizin (örneğin,misc_ne
) oluşturun.- Bu üst düzey dizini şifrelenmemiş olarak yapılandırın (bkz. Dizinleri hariç tutma).
- OTA paketlerini barındırmak için üst düzey dizin içinde bir dizin oluşturun.
- 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 edinro.crypto.state
adlı dosyanın şifrelendiğinden emin olun
ro.crypto.type
öğesinin mevcut olduğunu kontrol edinro.crypto.type
değerininfile
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:
Depolama sınıfı | Açıklama | Dizinler |
---|---|---|
Şifrelenmemiş | /data içindeki, FBE ile korunması mümkün olmayan veya korunması gerekmeyen dizinler. Meta veri şifrelemesi kullanılan cihazlarda bu dizinler gerçekten şifrelenmemiş değildir. Bunun yerine, Sistem DE'ye eşdeğer olan meta veri şifreleme anahtarıyla korunur. |
|
System DE | Belirli bir kullanıcıya bağlı olmayan, cihazda şifrelenmiş veriler |
|
Başlatma başına | Yeniden başlatma işleminden sonra kalması gerekmeyen geçici sistem dosyaları | /data/per_boot |
Kullanıcı CE (dahili) | Dahili depolama biriminde kullanıcı başına kimlik bilgisiyle şifrelenmiş veriler |
|
User DE (internal) | Dahili depolama biriminde kullanıcı başına cihaz şifreli veriler |
|
Kullanıcı CE'si (benimsenebilir) | Dahili hale getirilebilir depolama alanında kullanıcı başına kimlik bilgisiyle şifrelenmiş veriler |
|
User DE (adoptable) | Kullanıcı başına cihazda şifrelenmiş veriler (taşınabilir depolama alanında) |
|
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:
Anahtar türü | Anahtar konumu | Anahtar konumunun depolama sınıfı |
---|---|---|
Sistem DE anahtarı | /data/unencrypted |
Şifrelenmemiş |
Kullanıcı CE (dahili) anahtarları | /data/misc/vold/user_keys/ce/${user_id} |
System DE |
Kullanıcı DE (dahili) anahtarları | /data/misc/vold/user_keys/de/${user_id} |
System DE |
Kullanıcı CE (benimsenen) anahtarları | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} |
Kullanıcı CE (dahili) |
Kullanıcı DE (benimsenen) anahtarları | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} |
User DE (internal) |
Ö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.