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
veyaadiantum
olabilir. Android 11'den bu yanaaes-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
veyaaes-256-hctr2
olabilir. Belirtilmezse,contents_encryption_mode
aes-256-cts
ise varsayılan olarak aesaes-256-xts
cts'dir veyacontents_encryption_mode
adiantum
iseadiantum
. - 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 yerineinlinecrypt_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ızcainlinecrypt
bağlama seçeneği 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 ş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ıdakifileencryption
ö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ğeraes-256-heh
. Ç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
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:
-
userdata
bölümünde bir üst düzey dizin (örneğinmisc_ne
) oluşturun. - Bu üst düzey dizini şifrelenmemiş olacak şekilde yapılandırın (bkz . Dizinler hariç ).
- 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 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:
Depolama sınıfı | Tanım | dizinler |
---|---|---|
Sistem DE | Belirli bir kullanıcıya bağlı olmayan, cihaz tarafından şifrelenmiş veriler | /data/system , /data/app ve /data diğer çeşitli alt dizinleri |
önyükleme başına | Yeniden başlatmaya dayanması gerekmeyen geçici sistem dosyaları | /data/per_boot |
Kullanıcı CE (dahili) | Dahili depolamada kullanıcı başına kimlik bilgisi ile şifrelenmiş veriler |
|
Kullanıcı DE (dahili) | Dahili depolamada kullanıcı başına cihaz tarafından şifrelenmiş veriler |
|
Kullanıcı CE (evlat edinilebilir) | Kabul edilebilir depolamada kullanıcı başına kimlik bilgisi ile şifrelenmiş veriler |
|
Kullanıcı DE (benimsenebilir) | Kabul edilebilir depolamada kullanıcı başına cihaz tarafından şifrelenmiş veriler |
|
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:
Anahtar türü | Anahtar konum | Anahtar konumun depolama sınıfı |
---|---|---|
Sistem DE anahtarı | /data/unencrypted | şifrelenmemiş |
Kullanıcı CE (dahili) tuşları | /data/misc/vold/user_keys/ce/${user_id} | Sistem DE |
Kullanıcı DE (dahili) tuşları | /data/misc/vold/user_keys/de/${user_id} | Sistem DE |
Kullanıcı CE (benimsenebilir) anahtarları | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} | Kullanıcı CE (dahili) |
Kullanıcı DE (benimsenebilir) tuşları | /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 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.