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 Doğrudan Önyükleme API'lerini nasıl kullanabileceği açıklanmaktadır.
Doğrudan Önyükleme
Dosya tabanlı şifreleme, Android 7.0'da sunulan Direct Boot adlı yeni bir özelliği etkinleştirir. Doğrudan Önyükleme, şifrelenmiş aygıtların doğrudan kilit ekranına önyüklenmesini sağlar. Ö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ışındaki tüm işlemleri gerçekleştirmesini engelliyordu. Örneğin, alarmlar çalışamıyordu, erişilebilirlik hizmetleri kullanılamıyor ve telefonlar arama alamıyor, ancak yalnızca temel acil durum çevirici işlemleriyle sınırlıydı.
Dosya tabanlı şifrelemenin (FBE) ve uygulamaları şifrelemeden haberdar etmek için yeni API'lerin tanıtılması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ı, 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 Bilgileri Şifreli (CE) depolama.
- Hem Doğrudan Önyükleme modu sırasında hem de kullanıcı cihazın kilidini açtıktan sonra kullanılabilen bir depolama konumu olan Cihaz Şifreli (DE) depolama.
Bu ayrım, şifreleme artık yalnızca bir önyükleme zamanı parolasına dayalı olmadığından, aynı anda birden fazla kullanıcının korunmasına izin verdiği için iş profillerini daha güvenli hale getirir.
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 depolamasının kilidi açıldığında veya iş profilinin bir iş zorluğu 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. 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 özelliği optimize etmenin yollarını araştırmak isteyebilirler.
AOSP'deki tüm gerekli paketler, doğrudan önyüklemenin farkında olacak şekilde güncellendi. Ancak, cihaz üreticilerinin bu uygulamaların özelleştirilmiş sürümlerini kullandığı durumlarda, asgari olarak aşağıdaki hizmetleri sağlayan doğrudan önyüklemeye duyarlı paketlerin olmasını sağlamak isteyeceklerdir:
- Telefon Hizmetleri ve Çevirici
- Kilit ekranına şifre girmek için giriş yöntemi
Örnekler ve kaynak
Android, vold'un ( system/vold ) Android'de depolama aygıtlarını ve birimleri yönetmeye yönelik işlevsellik sağladığı dosya tabanlı şifrelemenin bir referans uygulamasını sağlar. FBE'nin eklenmesi, birden çok kullanıcının CE ve DE anahtarları için anahtar yönetimini desteklemek için vold'a birkaç yeni komut sağlar. Çekirdekte dosya tabanlı şifreleme yeteneklerini kullanmak için yapılan temel değişikliklere ek olarak, kilit ekranı ve SystemUI dahil 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/taban/paketler/SystemUI)*
* defaultToDeviceProtectedStorage
bildirim özniteliğini kullanan sistem uygulamaları
AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware
komutunu çalıştırarak, şifreleme farkında olan daha fazla uygulama ve hizmet örneği 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 2.0 ile Keymaster Desteği . Gerekli yetenekleri sağlamadığı veya şifreleme anahtarları için yeterli koruma sağlamadığı için Keymaster 0.3 desteği yoktur.
- Keymaster/ Keystore ve Gatekeeper , DE anahtarlarına koruma sağlamak için bir 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.
- Aygıt Şifreleme kimlik bilgilerine yetkisiz bir işletim sistemi tarafından erişilemediğinden emin olmak için, anahtar yöneticisi başlatmasına bağlı Donanım Güven Kökü ve Doğrulanmış Önyükleme gereklidir.
Not : Depolama ilkeleri, bir klasöre ve tüm alt klasörlerine uygulanır. Üreticiler, şifrelenmemiş içeriği OTA klasörüyle ve sistemin şifresini çözen anahtarın bulunduğu klasörle sınırlandırmalıdır. Çoğu içerik, cihazla şifrelenmiş depolama yerine kimlik bilgileriyle şifrelenmiş depolamada bulunmalıdır.
uygulama
Her şeyden önce çalar saat, telefon, 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 üzeri 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 kullanıcı userdata
dosya sistemi Ext4 ise CONFIG_EXT4_ENCRYPTION=y
kullanın veya cihazınızın kullanıcı verileri dosya sistemi userdata
ise CONFIG_F2FS_FS_ENCRYPTION=y
kullanın.
Cihazınız uyarlanabilir depolamayı destekleyecekse veya dahili depolamada meta veri şifrelemesi kullanacaksa, meta veri şifreleme belgelerinde açıklandığı gibi meta veri şifrelemesi için gereken çekirdek yapılandırma seçeneklerini de etkinleştirin.
Cihaz üreticileri, Ext4 veya F2FS şifrelemesi için işlevsel desteğe ek olarak, dosya tabanlı şifrelemeyi hızlandırmak ve kullanıcı deneyimini geliş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 iyileştirmek ve güç kullanımını azaltmak için, cihaz üreticileri ayrıca, depolama cihazına giderken/gelirken verileri şifreleyen/şifresini çözen satır içi şifreleme donanımını 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 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'yi etkinleştirmek, dahili depolamada ( userdata
) etkinleştirmeyi gerektirir. Bu, aynı zamanda, kabul edilebilir depolamada FBE'yi otomatik olarak etkinleştirir; ancak, uyarlanabilir depolamadaki şifreleme biçimi 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 biçimini tanımlar. Üç adede kadar iki nokta üst üste ayrılmış parametre içerir:
- content_encryption_mode parametresi, dosya
contents_encryption_mode
şifrelemek için hangi şifreleme algoritmasının kullanıldığını tanımlar. Aesaes-256-xts
xts veyaadiantum
. Android 11'den beri,aes-256-xts
olan varsayılan algoritmayı belirtmek için boş 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
. Belirtilmezse, content_encryption_modeaes-256-xts
contents_encryption_mode
iseaes-256-cts
veyaadiantum
isecontents_encryption_mode
adiantum
olur. - Android 11'de yeni olan
flags
parametresi,+
karakteriyle ayrılmış bir bayrak 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 sonraki sürümlerde (ro.product.first_api_level
tarafından belirlenir) başlatılırsa varsayılan değer v2'dir veya cihaz Android 10 veya daha düşük sürümlerde başlatılırsa 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ç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 üretimi (başlatma vektörleri) buna göre ayarlanır. -
emmc_optimized
bayrağı, inlinecrypt_optimized işlevine benzer, ancakinlinecrypt_optimized
32 bit ile sınırlayan bir IV oluşturma yöntemi de seçer. Bu bayrak yalnızca JEDEC eMMC v5.2 spesifikasyonuyla 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 bayrak asla UFS tabanlı depolamada kullanılmamalıdır; UFS spesifikasyonu 64-bit IV'lerin kullanımına izin verir. - Donanım sarılı anahtarları destekleyen cihazlarda,
wrappedkey_v0
bayrağı, FBE için donanım sarılı 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
. 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ğeri fileencryption=::inlinecrypt_optimized
) şeklindedir. Herhangi bir AES hızlandırması olmayan cihazlarda, fileencryption fileencryption=adiantum
ayarlanarak AES yerine Adiantum kullanılabilir.
Android 14'ten (AOSP deneysel), 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ı şifrelemesi için varsayılan mod olması planlanmaktadır. Çekirdeğiniz AES-HCTR2 desteğine sahipse, filenames_encryption_mode aes-256-hctr2
olarak ayarlayarak filenames_encryption_mode
adları şifrelemesi için etkinleştirilebilir. En basit durumda bu, fileencryption=aes-256-xts:aes-256-hctr2
.
Android 10 veya daha düşük sürümle başlatılan cihazlarda, FSCRYPT_MODE_PRIVATE
dosya içeriği şifreleme modunun kullanımını belirtmek için fileencryption=ice
da 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ümlerle başlatılan cihazlarda bu moda artık izin verilmez 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ını kullanmak istiyorsanız, satır içi 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 beri FBE ve uyarlanabilir depolama birlikte kullanılabilir.
Kullanıcı verileri için dosya şifreleme fstab seçeneğinin belirtilmesi, fileencryption
depolamada hem userdata
hem de meta veri şifrelemesini otomatik olarak etkinleştirir. Ancak, PRODUCT_PROPERTY_OVERRIDES
içinde özellikleri ayarlayarak, uyarlanabilir depolamadaki FBE ve/veya meta veri şifreleme biçimlerini geçersiz kılabilirsiniz.
Android 11 veya sonraki sürümlerle başlatılan cihazlarda aşağıdaki özellikleri kullanın:
-
ro.crypto.volume.options
(Android 11'de yeni), uyarlanabilir 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ğı konusunda 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
iki nokta üst üste ayrılmış ilk alanına eşdeğerdir. -
ro.crypto.volume.filenames_mode
, dosya adları şifreleme modunu seçer. Bu,ro.crypto.volume.options
iki nokta üst üste ayrılmış alanına eşdeğerdir, ancak Android 10 veya daha eski sürümlerle başlatılan cihazlarda varsayılanınaes-256-heh
olmasıdır. Çoğu cihazda, bununaes-256-cts
olarak açıkça geçersiz kılınması gerekir. -
ro.crypto.fde_algorithm
vero.crypto.fde_sector_size
, uyarlanabilir depolamada meta veri şifreleme biçimini seçer. Meta veri şifreleme belgelerine bakın.
Keymaster ile entegrasyon
Anahtarların oluşturulması ve çekirdek anahtarlığının yönetimi vold
tarafından gerçekleştirilir. FBE'nin AOSP uygulaması, cihazın Keymaster HAL 1.0 veya sonraki sürümünü desteklemesini gerektirir. Keymaster HAL'ın önceki sürümleri için destek yoktur.
İlk önyüklemede, kullanıcı 0'ın anahtarları, önyükleme işleminin başlarında oluşturulur ve kurulur. on-post-fs
aşaması tamamlandığında, init
istekleri işlemeye hazır olması gerekir. Pixel cihazlarda bu, /data
monte edilmeden önce Keymaster'ın başlatıldığından emin olan bir komut dosyası bloğuna sahip olarak gerçekleştirilir.
Şifreleme politikası
Dosya tabanlı şifreleme, şifreleme ilkesini dizin düzeyinde uygular. Bir aygıtın kullanıcı userdata
bölümü ilk kez oluşturulduğunda, temel yapılar ve ilkeler, init
komut dosyaları tarafından uygulanır. Bu komut dosyaları, ilk kullanıcının (kullanıcı 0'ların) CE ve DE anahtarlarının oluşturulmasını tetikleyecek ve ayrıca bu anahtarlarla hangi dizinlerin şifreleneceğini tanımlayacaktır. Ek kullanıcılar ve profiller oluşturulduğunda, gerekli ek anahtarlar oluşturulur ve anahtar deposunda saklanır; kimlik bilgileri ve cihaz depolama konumları oluşturulur ve şifreleme ilkesi bu anahtarları bu dizinlere bağlar.
Android 11 ve sonraki sürümlerde, şifreleme ilkesi artık merkezi bir konuma sabit kodlanmış değildir, bunun yerine init komut dosyalarındaki mkdir
komutlarına yönelik bağımsız değişkenler tarafından tanımlanır. DE anahtarı sistemiyle şifrelenmiş dizinler encryption=Require
, şifrelenmemiş dizinler (veya alt dizinleri kullanıcı başına anahtarlarla şifrelenmiş dizinler) encryption=None
kullanır.
Android 10'da şifreleme ilkesi şu konuma sabit 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 hiç ş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, tüm güvenilmeyen 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ın Direct Boot'u bilinçli 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üzeyinde directBootAware
özniteliği, uygulamadaki tüm bileşenleri şifrelemeye duyarlı olarak işaretlemek için bir kısayoldur.
defaultToDeviceProtectedStorage
özniteliği, varsayılan uygulama depolama konumunu CE depolama yerine DE depolamasını işaret edecek şekilde yeniden yönlendirir. Bu bayrağı kullanan sistem uygulamaları, varsayılan konumda depolanan tüm verileri dikkatli bir şekilde denetlemeli ve CE depolamasını kullanmak için hassas verilerin yollarını değiştirmelidir. Bu seçeneği kullanan cihaz üreticileri, hiçbir kişisel bilgi içermediğinden emin olmak için sakladıkları verileri dikkatlice incelemelidir.
Bu modda çalışırken, gerektiğinde CE depolaması tarafından desteklenen bir İçeriği açıkça yönetmek için aşağıdaki Sistem API'leri kullanılabilir ve bunlar Cihaz Korumalı muadillerine eşdeğerdir.
-
Context.createCredentialProtectedStorageContext()
-
Context.isCredentialProtectedStorage()
Birden fazla kullanıcıyı destekleme
Çok kullanıcılı bir ortamda her kullanıcı ayrı bir şifreleme anahtarı alır. Her kullanıcı iki anahtar alır: 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.
Kriptoya 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 arasında hareket etmesine izin verir. Bununla birlikte, bu uygulamalar, zaten kilidi açılmış olan kullanıcılar için yalnızca CE ile şifrelenmiş dizinlere erişebilecektir.
Bir uygulama, DE alanları arasında serbestçe etkileşime girebilir, ancak bir kullanıcının kilidinin açılması, cihazdaki tüm kullanıcıların kilidinin açık olduğu 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 uygulanabileceğinden, şifrelenmiş sürücüdeki verilere erişmek için kurtarma işlemine gerek yoktur.
Kullanıcı verileri bölümündeki userdata
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 şifreleme ilkesi istisnasına ekleyin (yukarıdaki Şifreleme ilkesine bakın).
- OTA paketlerini tutmak için üst düzey dizin içinde bir dizin oluşturun.
- Bu klasöre 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 klasörü okuyabilmeli ve bu klasöre yazabilmelidir. Başka hiçbir uygulama veya işlemin bu klasöre 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 önce 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 dosyasını 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
olup olmadığını kontrol edin-
ro.crypto.state
şifrelendiğinden emin olun
-
-
ro.crypto.type
olup olmadığını kontrol edin-
ro.crypto.type
öğesininfile
olarak ayarlandığından emin olun
-
Ek olarak, test kullanıcıları, birincil kullanıcıda ayarlanmış bir kilit ekranı ile bir kullanıcı userdebug
örneğini başlatabilir. Ardından cihaza kabuk adb
ve kök olmak için su
kullanın. /data/data
data'nın şifrelenmiş dosya adları içerdiğinden emin olun; 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 takımının 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 yapmalarına gerek kalmamalıdır.
fscrypt şifreleme
AOSP uygulaması, çekirdekte "fscrypt" şifrelemesi (ext4 ve f2fs tarafından desteklenir) kullanır ve normalde şu şekilde yapılandırılı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çeriği hem de dosya adları Adiantum ile şifrelenir.
fscrypt hakkında daha fazla bilgi için yukarı akış çekirdek belgelerine bakın.
Anahtar türetme
512 bitlik anahtarlar olan dosya tabanlı şifreleme anahtarları, TEE'de tutulan başka bir anahtar (256 bit AES-GCM anahtarı) tarafından şifrelenmiş olarak depolanır. Bu TEE anahtarını kullanmak için üç gereksinimin karşılanması gerekir:
- Yetkilendirme belirteci
- uzatılmış kimlik
- "Secdiscardable hash"
Yetkilendirme belirteci , bir kullanıcı başarıyla oturum açtığında Gatekeeper tarafından oluşturulan, kriptografik olarak kimliği doğrulanmış bir belirteçtir. TEE, doğru yetkilendirme belirteci sağlanmadıkça anahtarı kullanmayı reddedecektir. Kullanıcının kimlik bilgisi yoksa, kimlik doğrulama belirteci kullanılmaz veya gerekli değildir.
Uzatılmış kimlik bilgisi , scrypt
algoritması ile tuzlama ve esnetmeden sonra kullanıcı kimlik bilgisidir. Kimlik bilgisi, scrypt'e geçirilmek üzere vold
geçirilmeden önce, kilit ayarları hizmetinde bir kez scrypt
. Bu, KM_TAG_APPLICATION_ID için geçerli tüm garantilerle birlikte KM_TAG_APPLICATION_ID
anahtara kriptografik olarak bağlıdır. Kullanıcının kimlik bilgisi yoksa, uzatılmış kimlik bilgisi kullanılmaz veya gerekli değildir.
secdiscardable hash
, anahtarı yeniden oluşturmak için kullanılan tohum gibi diğer bilgilerle birlikte depolanan rastgele 16 KB'lik bir dosyanın 512 bitlik bir karmasıdır. Bu dosya, anahtar silindiğinde güvenli bir şekilde silinir veya yeni bir şekilde şifrelenir; bu ek koruma, bir saldırganın anahtarı kurtarmak için bu güvenli bir şekilde silinen dosyanın her bir parçasını kurtarmasını sağlar. Bu, KM_TAG_APPLICATION_ID için geçerli tüm garantilerle birlikte KM_TAG_APPLICATION_ID
anahtara kriptografik olarak bağlıdır.
Çoğu durumda, FBE anahtarları, örneğin dosya başına veya mod başına anahtarlar gibi, şifrelemeyi yapmak için fiilen kullanılan alt anahtarları oluşturmak için çekirdekte ek bir anahtar türetme adımından da geçer. Sürüm 2 şifreleme ilkeleri için bunun için HKDF-SHA512 kullanılır.