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
veyaadiantum
olabilir. Android 11'den bu yanaaes-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
veyaaes-256-hctr2
olabilir. Belirtilmemişse,contents_encryption_mode
aes-256-cts
iseaes-256-xts
veyacontents_encryption_mode
adiantum
iseadiantum
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 yerineinlinecrypt_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ızcainlinecrypt
bağlama seçeneğiyle veinlinecrypt_optimized
veyaemmc_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ıdakifileencryption
ö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ınaes-256-heh
olması dışındaro.crypto.volume.options
iki nokta üst üste ile ayrılmış ikinci alanına eşdeğerdir. Çoğu cihazda bunun açıkçaaes-256-cts
olarak geçersiz kılınması gerekir. -
ro.crypto.fde_algorithm
vero.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:
-
userdata
bölümünde üst düzey bir dizin (örneğinmisc_ne
) oluşturun. - Bu üst düzey dizini şifrelenmemiş olacak şekilde yapılandırın (bkz . Dizinleri hariç tutma ).
- OTA paketlerini tutmak 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ü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ınfile
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:
Depolama sınıfı | Tanım | Dizinler |
---|---|---|
Sistem DE | Belirli bir kullanıcıya bağlı olmayan, cihazla şifrelenmiş veriler | /data/system , /data/app ve /data diğer çeşitli alt dizinleri |
Önyükleme başına | Yeniden başlatma sonrasında hayatta kalması gerekmeyen geçici sistem dosyaları | /data/per_boot |
Kullanıcı CE (dahili) | Dahili depolamada kullanıcı başına kimlik bilgileri ile şifrelenmiş veriler |
|
Kullanıcı DE (dahili) | Dahili depolamada kullanıcı başına cihaz tarafından şifrelenen veriler |
|
Kullanıcı CE (kabul edilebilir) | Kabul edilebilir depolama alanında kullanıcı başına kimlik bilgileri ile şifrelenmiş veriler |
|
Kullanıcı DE (kabul edilebilir) | Uyarlanabilir depolama alanında kullanıcı başına cihazla şifrelenen veriler |
|
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:
Anahtar türü | Anahtar konumu | Anahtar konumun depolama sınıfı |
---|---|---|
Sistem DE anahtarı | /data/unencrypted | Şifrelenmemiş |
Kullanıcı CE (dahili) anahtarları | /data/misc/vold/user_keys/ce/${user_id} | Sistem DE |
Kullanıcı DE (dahili) anahtarları | /data/misc/vold/user_keys/de/${user_id} | Sistem DE |
Kullanıcı CE (kabul edilebilir) anahtarları | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} | Kullanıcı CE (dahili) |
Kullanıcı DE (kabul edilebilir) anahtarları | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} | Kullanıcı DE (dahili) |
Ö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.