Dosya Tabanlı Şifreleme

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, 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. Daha önce, tam disk şifreleme (FDE) kullanan şifreli cihazlarda, kullanıcıların herhangi bir veriye erişilebilmesi için kimlik bilgilerini sağlamaları 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 bir iş zorluğu sağlayan iş profili 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 uygulamadıklarından bağımsız olarak 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önetme işlevselliği 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 özelliklerini 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 komutu çalıştırılarak, ş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 , yetkisiz bir işletim sisteminin (cihaza yüklenen özel işletim sistemi) DE anahtarlarını isteyememesi için DE anahtarlarına koruma sağlamak için bir Güvenilir Yürütme Ortamında (TEE) uygulanmalıdır.
• 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ü 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 FBE'yi kabul edilebilir depolamada 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ğinin eklenmesiyle etkinleştirilir. Bu seçenek, dahili depolamadaki şifreleme biçimini tanımlar. En fazla üç kolonla 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. Aes aes-256-xts xts veya adiantum . 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 veya adiantum . Belirtilmezse, content_encryption_mode aes-256-xts contents_encryption_mode ise aes-256-cts veya adiantum ise contents_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 başlatıldıysa ( ro.product.first_api_level tarafından belirlendiği gibi) v2 veya cihaz Android 10 veya daha düşük sürümlerde başlatıldıysa v1 varsayılandır.
  • 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, ancak inlinecrypt_optimized 32 bit ile sınırlayan bir IV oluşturma yöntemi de seçer. Bu işaret yalnızca JEDEC eMMC v5.2 spesifikasyonu ile uyumlu olan ve bu nedenle yalnızca 32 bit IV'leri destekleyen satır içi şifreleme donanımında kullanılmalıdır. Diğer satır içi şifreleme donanımlarında bunun yerine inlinecrypt_optimized kullanın. Bu 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ızca inlinecrypt bağlama seçeneği ve inlinecrypt_optimized veya emmc_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 10 veya önceki sürümlerle 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ğını öğrenmek için yukarıdaki fileencryption ö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 düşük sürümlerle başlatılan cihazlarda varsayılanın aes-256-heh olmasıdır. Çoğu cihazda, bunun aes-256-cts olarak açıkça geçersiz kılınması gerekir.
• ro.crypto.fde_algorithm ve ro.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 yüklenir. 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) 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üzeyindeki 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 depolamayı işaret edecek şekilde yeniden yönlendirir. Bu bayrağı kullanan sistem uygulamaları, varsayılan konumda depolanan tüm verileri dikkatle 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şim kurabilir, 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:

1. userdata bölümünde bir üst düzey dizin (örneğin misc_ne ) oluşturun.
2. Bu üst düzey dizini şifreleme ilkesi istisnasına ekleyin (yukarıdaki Şifreleme ilkesine bakın).
3. OTA paketlerini tutmak için üst düzey dizin içinde bir dizin oluşturun.
4. 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ü ç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 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 öğesinin file 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" şifrelemesini (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 esnetme işleminden 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 olan 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. Anahtar silindiğinde bu dosya 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 olan 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.