Dosya tabanlı şifreleme

Android 7.0 ve sonraki sürümler dosya tabanlı şifrelemeyi (FBE) destekler. Dosya tabanlı şifreleme, farklı dosyaların bağımsız olarak kilidi açılabilen farklı anahtarlarla şifrelenmesine olanak tanır.

Bu makalede, yeni cihazlarda dosya tabanlı şifrelemenin nasıl etkinleştirileceği ve sistem uygulamalarının kullanıcılara mümkün olan en iyi ve en güvenli deneyimi sunmak için Doğrudan Önyükleme API'lerini nasıl kullanabileceği açıklanmaktadır.

Android 10 ve sonraki sürümlerin yüklü olduğu tüm cihazların dosya tabanlı şifreleme kullanması gerekir.

Doğrudan Başlatma

Dosya tabanlı şifreleme, Android 7.0'da kullanıma sunulan Doğrudan Önyükleme adlı yeni bir özelliği etkinleştirir. Doğrudan önyükleme, şifrelenmiş cihazların doğrudan kilit ekranına önyükleme yapmasını sağlar. Daha önce, tam disk şifrelemesi (FDE) kullanılan şifrelenmiş cihazlarda, verilere erişebilmek için kullanıcıların kimlik bilgilerini sağlaması gerekiyordu. Bu da telefonun en temel işlemler dışında hiçbir işlem yapamamasına neden oluyordu. Örneğin, alarmlar çalışamaz, erişilebilirlik hizmetleri kullanılamaz, telefonlar arama alamaz ve yalnızca temel acil durum araması işlevleriyle sınırlı olur.

Dosya tabanlı şifreleme (FBE) ve uygulamaların şifrelemeyi fark etmesini sağlayacak 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 kimlik bilgilerini sağlamadan önce gerçekleşebilir ve gizli kullanıcı bilgileri korunmaya devam eder.

FBE özellikli bir cihazda, cihazın her kullanıcısı için uygulamalar tarafından kullanılabilen iki depolama alanı bulunur:

• Varsayılan depolama konumu olan ve yalnızca kullanıcının cihazın kilidini açmasından sonra kullanılabilen kimlik bilgisi şifrelenmiş (CE) depolama alanı.
• Hem Doğrudan Önyükleme modunda hem de kullanıcı cihazın kilidini açtıktan sonra kullanılabilen bir depolama konumu olan Cihaz Şifrelenmiş (DE) depolama alanı.

Bu ayrım, şifreleme artık yalnızca önyükleme zamanı şifresine bağlı olmadığından aynı anda birden fazla kullanıcının korunmasına olanak tanıdığı için iş profillerini daha güvenli hale getirir.

Doğrudan Açılış API'si, şifrelemeye duyarlı uygulamaların bu alanların her birine erişmesine olanak tanır. Uygulama yaşam döngüsünde, kullanıcının CE depolama alanının kilidi ilk kez kilit ekranında kimlik bilgileri girildiğinde veya iş profilinde iş meydan okuması sağlandığında uygulamaların bilgilendirilmesi ihtiyacını karşılamak için değişiklikler yapılmıştı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. Ancak FBE olmadan DE ve CE depolama alanı her zaman kilidi açık durumdadır.

Ext4 ve F2FS dosya sistemlerinde dosya tabanlı şifrelemenin eksiksiz bir uygulaması Android Açık Kaynak Projesi'nde (AOSP) sağlanmıştır ve yalnızca koşulları karşılayan cihazlarda etkinleştirilmesi gerekir. FBE'yi kullanmayı tercih eden üreticiler, kullanılan çip üzerinde sisteme (SoC) göre özelliği optimize etme yollarını araştırabilir.

AOSP'deki gerekli tüm paketler, doğrudan önyükleme bilincine sahip olacak şekilde güncellendi. Ancak cihaz üreticileri bu uygulamaların özelleştirilmiş sürümlerini kullandığında, en azından aşağıdaki hizmetleri sağlayan doğrudan önyükleme bilincine sahip paketlerin bulunduğundan emin olmak ister:

• Telefon Hizmetleri ve Çevirici
• Kilit ekranına şifre girmek için giriş yöntemi

Örnekler ve kaynak

Android, dosya tabanlı şifrelemenin referans bir uygulamasını sağlar. Bu uygulamada, Android'deki depolama cihazlarını ve birimleri yönetme işlevini vold (system/vold) sağlar. FBE'nin eklenmesi, vold'a birden fazla kullanıcının CE ve DE anahtarlarının anahtar yönetimini desteklemek için birkaç yeni komut sağlar. Çekirdekteki dosya tabanlı şifreleme özelliklerini kullanmaya yönelik temel değişikliklerin yanı sıra kilit ekranı ve SystemUI gibi birçok sistem paketi, FBE ve Doğrudan Önyükleme özelliklerini destekleyecek şekilde değiştirildi. Bunlardan bazıları:

• AOSP Dialer (packages/apps/Dialer)
• Masa Saati (packages/apps/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Ayarlar Uygulaması (packages/apps/Settings)*
• SystemUI (frameworks/base/packages/SystemUI)*

* defaultToDeviceProtectedStorage manifest özelliğini kullanan sistem uygulamaları

Şifreleme bilincine sahip uygulama ve hizmetlerle ilgili daha fazla örnek için AOSP kaynak ağacının frameworks veya packages dizininde mangrep directBootAware komutunu çalıştırabilirsiniz.

Bağımlılıklar

FBE'nin AOSP uygulamasını güvenli bir şekilde kullanmak için cihazın aşağıdaki bağımlılıkları karşılaması gerekir:

• Ext4 şifrelemesi veya F2FS şifrelemesi için çekirdek desteği.
• HAL 1.0 veya sonraki sürümlerde Keymaster desteği. Gerekli özellikleri sağlamadığı veya şifreleme anahtarları için yeterli korumayı sağlamadığı için Keymaster 0.3 desteklenmez.
• 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 (cihazın üzerine yüklenen özel işletim sistemi) DE anahtarlarını kolayca isteyemez.
• DE anahtarlarına yetkisiz bir işletim sisteminin erişememesi için Keymaster başlatma işlemine bağlı donanım güven kökü ve doğrulanmış başlatma gerekir.

Uygulama

Öncelikle alarm, telefon ve erişilebilirlik özellikleri gibi uygulamalar, Doğrudan Açılış geliştirici dokümanları uyarınca android:directBootAware olarak ayarlanmalıdır.

Çekirdek desteği

Ext4 ve F2FS şifrelemesi için çekirdek desteği, Android ortak çekirdeklerinde 3.18 ve sonraki sürümlerde kullanılabilir. Bu özelliği 5.1 veya daha yeni bir sürüme sahip bir çekirdekte etkinleştirmek için:

CONFIG_FS_ENCRYPTION=y

Eski çekirdekler için cihazınızın userdata dosya sistemi Ext4 ise CONFIG_EXT4_ENCRYPTION=y, userdata dosya sistemi F2FS ise CONFIG_F2FS_FS_ENCRYPTION=y kullanın.

Cihazınız uyarlanabilir depolama özelliğini destekliyorsa veya dahili depolama alanında meta veri şifrelemesi kullanıyorsa meta veri şifreleme dokümanlarında 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 destek sağlamanın yanı sıra dosya tabanlı şifrelemeyi hızlandırmak ve kullanıcı deneyimini iyileştirmek için kriptografik hızlandırmayı da etkinleştirmelidir. Örneğin, ARM64 tabanlı cihazlarda ARMv8 CE (Kriptografi 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

Cihaz üreticileri, performansı daha da artırmak ve güç kullanımını azaltmak için verileri depolama cihazına gidip gelirken şifreleyen/şifrelerini çözen satır içi şifreleme donanımı da kullanabilir. Android ortak çekirdekleri (4.14 ve sonraki sürümler), donanım ve tedarikçi sürücü 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 aşağıdakileri de etkinleştirin:

CONFIG_SCSI_UFS_CRYPTO=y

Cihazınız eMMC tabanlı depolama kullanıyorsa şunları da etkinleştirin:

CONFIG_MMC_CRYPTO=y

Dosya tabanlı şifrelemeyi etkinleştirme

Bir cihazda FBE'yi etkinleştirmek için dahili depolama alanında (userdata) etkinleştirilmesi gerekir. Bu işlem, FBE'yi uyarlanabilir depolama alanında da otomatik olarak etkinleştirir. Ancak gerekirse uyarlanabilir depolama alanındaki şifreleme biçimi geçersiz kılınabilir.

Dahili depolama

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 FBE etkinleştirilir. Bu seçenek, dahili depolama alanındaki şifreleme biçimini tanımlar. İki noktayla ayrılmış en fazla üç 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 veya adiantum olabilir. Android 11'den beri, varsayılan algoritmayı (aes-256-xts) belirtmek için boş bırakılabilir.
• filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi kriptografik algoritmanın kullanıldığını tanımlar. Bu değer şu değerlerden biri olabilir: aes-256-cts, aes-256-heh, adiantum veya aes-256-hctr2. Belirtilmezse contents_encryption_mode aes-256-xts ise varsayılan olarak aes-256-cts, contents_encryption_mode adiantum ise varsayılan olarak adiantum olur.
• Android 11'de yeni olan flags parametresi, + karakteriyle ayrılmış işaretlerin bir listesidir. Aşağıdaki işaretler desteklenir:
  • v1 işareti 1. sürüm şifreleme politikalarını, v2 işareti ise 2. sürüm 2 sürümlü şifreleme politikaları daha güvenli ve esnek bir anahtar türetme işlevi kullanır. Cihaz Android 11 veya sonraki bir sürümde kullanıma sunulmuşsa (ro.product.first_api_level tarafından belirlenir) varsayılan olarak v2, Android 10 ve önceki sürümlerde kullanıma sunulmuşsa v1 kullanılır.
  • inlinecrypt_optimized işareti, çok sayıda anahtarı verimli bir şekilde işlemeyen satır içi şifreleme donanımı için optimize edilmiş bir şifreleme biçimi seçer. Bunu, her dosya için bir tane yerine her CE veya DE anahtarı için tek bir dosya içeriği şifreleme anahtarı türeterek yapar. IV'lerin (ilk başlatma vektörleri) oluşturulması buna göre ayarlanır.
  • emmc_optimized işareti inlinecrypt_optimized'e benzer ancak IV'leri 32 bitle sınırlayan bir IV oluşturma yöntemi de seçer. Bu işaret yalnızca JEDEC eMMC v5.2 spesifikasyonuna uygun olan ve bu nedenle yalnızca 32 bitlik IV'leri destekleyen satır içi şifreleme donanımlarında kullanılmalıdır. Diğer satır içi şifreleme donanımlarında bunun yerine inlinecrypt_optimized simgesini kullanın. Bu işaret hiçbir zaman UFS tabanlı depolama alanında kullanılmamalıdır. UFS spesifikasyonu, 64 bit IV'lerin kullanılmasına izin verir.
  • Donanımla sarmalanmış anahtarları destekleyen cihazlarda wrappedkey_v0 işareti, FBE için donanımla sarmalanmış anahtarların kullanılmasını sağlar. Bu yalnızca inlinecrypt bağlama seçeneği ve inlinecrypt_optimized veya emmc_optimized işaretiyle birlikte kullanılabilir.
  • dusize_4k işareti, dosya sistemi blok boyutu 4096 bayt olmasa bile şifreleme veri birimi boyutunun 4096 bayt olmasını zorunlu kılar. Şifreleme veri birimi boyutu, dosya içeriği şifrelemesinin ayrıntı düzeyidir. Bu işaret, Android 15'ten beri kullanılabilir. Bu işaret yalnızca 4096 bayttan büyük sayfa boyutu ve f2fs dosya sistemi kullanan bir cihazda 4096 bayttan büyük veri birimlerini desteklemeyen satır içi şifreleme donanımının kullanımını etkinleştirmek için kullanılmalıdır.

Satır içi şifreleme donanımı kullanmıyorsanız çoğu cihaz için önerilen ayar fileencryption=aes-256-xts'tür. Satır içi şifreleme donanımı kullanıyorsanız çoğu cihaz için önerilen ayar fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (veya eşdeğeri fileencryption=::inlinecrypt_optimized) şeklindedir. Herhangi bir AES hızlandırması olmayan cihazlarda fileencryption=adiantum ayarlanarak AES yerine Adiantum kullanılabilir.

Android 14'ten beri, hızlandırılmış kriptografi talimatları olan cihazlarda dosya adı şifreleme için tercih edilen mod AES-HCTR2'dir. Ancak AES-HCTR2 yalnızca daha yeni Android çekirdeklerinde desteklenir. Bu modun, gelecekteki bir Android sürümünde dosya adı şifreleme için varsayılan mod olması planlanmaktadır. Çekirdeğiniz AES-HCTR2 desteğine sahipse filenames_encryption_mode değerini aes-256-hctr2 olarak ayarlayarak dosya adı şifrelemesi için etkinleştirebilirsiniz. En basit durumda bu işlem fileencryption=aes-256-xts:aes-256-hctr2 ile yapılır.

Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda, fileencryption=ice dosya içeriği şifreleme modunun kullanımını belirtmek için FSCRYPT_MODE_PRIVATE da kabul edilir. Bu mod, Android'in ortak çekirdekleri tarafından uygulanmaz ancak özel çekirdek yamaları kullanan tedarikçiler tarafından uygulanabilir. Bu mod tarafından oluşturulan disk üzerindeki biçim, tedarikçiye özeldi. Android 11 veya sonraki sürümlerle kullanıma sunulan cihazlarda artık bu moda izin verilmez ve bunun yerine standart bir şifreleme biçimi kullanılmalıdır.

Dosya içeriği şifreleme işlemi varsayılan olarak Linux çekirdeğinin kriptografi API'si kullanılarak yapılır. Bunun yerine satır içi şifreleme donanımı kullanmak istiyorsanız inlinecrypt bağlama seçeneğini de ekleyin. Örneğin, tam bir fstab satırı şu şekilde görünebilir:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Dahili hale getirilebilir depolama alanı

Android 9'dan beri FBE ve uyarlanabilir depolama alanı birlikte kullanılabilir.

userdata için fileencryption fstab seçeneğini belirtmek, benimsenebilir depolama alanında hem FBE'yi hem de meta veri şifrelemeyi otomatik olarak etkinleştirir. Ancak PRODUCT_PROPERTY_OVERRIDES'te mülkleri ayarlayarak, uyumlu depolama alanındaki FBE veya meta veri şifreleme biçimlerini geçersiz kılabilirsiniz.

Android 11 veya sonraki sürümlerle kullanıma sunulan cihazlarda aşağıdaki özellikleri kullanın:

• ro.crypto.volume.options (Android 11'de yeni) kabul edilebilir depolama alanında FBE şifreleme biçimini seçer. fileencryption fstab seçeneğini belirten bağımsız değişkenle aynı söz dizimine sahiptir ve aynı varsayılan değerleri kullanır. Burada ne kullanacağınız konusunda yukarıdaki fileencryption önerilerine göz atın.
• ro.crypto.volume.metadata.encryption, kabul edilebilir depolama alanındaki meta veri şifreleme biçimini seçer. Meta veri şifreleme belgelerini inceleyin.

Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda aşağıdaki özellikleri kullanın:

• ro.crypto.volume.contents_mode, içerik şifreleme modunu seçer. Bu, ro.crypto.volume.options değerinin iki nokta işaretiyle ayrılmış ilk alanına eşdeğerdir.
• ro.crypto.volume.filenames_mode dosya adlarının şifreleme modunu seçer. Bu, ro.crypto.volume.options değerinin iki nokta işaretiyle ayrılmış ikinci alanına eşdeğerdir. Bununla birlikte, Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda varsayılan değer aes-256-heh'dur. Çoğu cihazda bu değerin aes-256-cts olarak açıkça atlanması gerekir.
• ro.crypto.fde_algorithm ve ro.crypto.fde_sector_size kabul edilebilir depolama alanında meta veri şifreleme biçimini seçin. Meta veri şifreleme belgelerini inceleyin.

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ı oluşturduğu post-fs-data önyükleme aşamasında isteklere yanıt vermeye hazır olmasını gerektirmesidir.

Dizinleri hariç tutma

init, sistem DE anahtarını, sistem DE anahtarının kendisini içeren dizinler ve kullanıcı CE veya DE dizinlerini içeren dizinler gibi şifresinin çözülmesi gereken dizinler hariç olmak üzere /data'ın tüm üst düzey dizinlerine uygular. Şifreleme anahtarları yinelemeli olarak uygulanır ve alt dizinlerle geçersiz kılınamaz.

Android 11 ve sonraki sürümlerde, init dizinleri için geçerli olan anahtar, init komutlarındaki mkdir komutuna ait encryption=<action> bağımsız değişkeni ile kontrol edilebilir. <action> için olası değerler, Android init dili için README belgesinde açıklanmıştır.

Android 10'da init şifreleme işlemleri aşağıdaki konuma yerleştirildi:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 ve önceki sürümlerde konum:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Belirli dizinlerin hiç şifrelenmesini önlemek için istisnalar ekleyebilirsiniz. Bu tür değişiklikler yapılırsa cihaz üreticisi, yalnızca şifrelenmemiş dizini kullanması gereken uygulamalara erişim izni veren SELinux politikaları eklemelidir. Bu işlem, güvenilmeyen tüm uygulamaları hariç tutar.

Bunun için bilinen tek kabul edilebilir kullanım alanı, eski OTA özelliklerini desteklemektir.

Sistem uygulamalarında doğrudan başlatmayı destekleme

Uygulamaları Doğrudan Başlatma'ya uyumlu hale getirme

Sistem uygulamalarının hızlı bir şekilde taşınmasını kolaylaştırmak için uygulama düzeyinde ayarlanabilen iki yeni özellik vardır. defaultToDeviceProtectedStorage özelliği yalnızca sistem uygulamaları tarafından 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 bilincine sahip olarak işaretlemek için kullanılan kısaltmadır.

defaultToDeviceProtectedStorage özelliği, varsayılan uygulama depolama konumunu CE depolama yerine DE depolama alanına yönlendirir. Bu işareti kullanan sistem uygulamaları, varsayılan konumda depolanan tüm verileri dikkatlice denetlemeli ve hassas verilerin yollarını CE depolama alanını kullanacak şekilde değiştirmelidir. Bu seçeneği kullanan cihaz üreticileri, kişisel bilgi içermediğinden emin olmak için depoladıkları verileri dikkatlice incelemelidir.

Bu modda çalışırken, gerektiğinde CE depolama alanı tarafından desteklenen bir bağlamı açıkça yönetmek için aşağıdaki sistem API'leri kullanılabilir. Bu API'ler, cihaz korumalı muadillerine eşdeğerdir.

• 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ı. 0 numaralı kullanıcı özel bir kullanıcı olduğundan önce cihaza giriş yapmalıdır. Bu, Cihaz Yönetimi kullanımları için geçerlidir.

Kriptodan haberdar uygulamalar kullanıcılar arasında şu şekilde etkileşim kurar: INTERACT_ACROSS_USERS ve INTERACT_ACROSS_USERS_FULL uygulamaların cihazdaki tüm kullanıcılar arasında işlem yapmasına izin verir. Ancak bu uygulamalar, yalnızca kilidi açılmış kullanıcıların CE ile şifrelenmiş dizinlerine erişebilir.

Bir uygulama, DE alanlarında özgürce 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. İş meydan okuması karşılanırsa profil kullanıcısının kilidi açılır ve Anahtar Yöneticisi (TEE'de) profilin TEE anahtarını sağlayabilir.

Güncellemeleri yönetme

Kurtarma bölümü, userdata bölümündeki DE korumalı depolama alanına erişemiyor. FBE'yi uygulayan cihazların A/B sistem güncellemeleri 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 işlemi 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 şifrelenmeyecek şekilde yapılandırın (Dizinleri hariç tutma bölümüne bakın).
3. OTA paketlerini barındıracak bir üst düzey dizin oluşturun.
4. Bu dizin ve içeriğine erişimi kontrol etmek için bir SELinux kuralı ve dosya bağlamı ekleyin. Yalnızca OTA güncellemeleri alan işlem veya uygulamalar bu dizinde okuma ve yazma işlemi yapmalıdır. Başka hiçbir uygulama veya işlemin bu dizine erişimi olmamalıdır.

Doğrulama

Özelliğin uygulanmış 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ınızda Android 11 veya sonraki bir sürüm yüklüyse 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'nin mevcut olup olmadığını kontrol edin
  • ro.crypto.state dosyasının şifrelenmiş olduğundan emin olun
• ro.crypto.type'nin mevcut olup olmadığını kontrol edin
  • ro.crypto.type değerinin file olarak ayarlandığından emin olun

Ayrıca test kullanıcıları, cihazın önyüklemeden sonra ilk kez kilidinin açılmasından önce CE depolama alanının kilitli olduğunu doğrulayabilir. Bunu yapmak için userdebug veya eng derlemesini kullanın, ana kullanıcıda PIN, desen veya şifre ayarlayın ve cihazı yeniden başlatın. Cihazın kilidini açmadan önce, ana kullanıcının CE depolama alanını kontrol etmek için aşağıdaki komutu çalıştırın. Cihaz Başsız Sistem Kullanıcı Modu'nu kullanıyorsa (çoğu Otomotiv cihazı) ana kullanıcı 10. kullanıcıdır. Bu nedenle şu komutu çalıştırın:

adb root; adb shell ls /data/user/10

Diğer cihazlarda (Automotive dışındaki cihazların çoğu), ana kullanıcı 0 numaralı kullanıcıdır. Bu nedenle şunları çalıştırın:

adb root; adb shell ls /data/user/0

Listelenen dosya adlarının Base64 kodlu olduğunu doğrulayın. Bu, dosya adlarının şifrelenmiş olduğunu ve şifrelerini çözmek için gereken anahtarın henüz kullanılamadığını gösterir. Dosya adları düz metin olarak listeleniyorsa bir sorun var demektir.

Cihaz üreticilerinin, cihazlarında veya çekirdeklerinde fscrypt için yayın öncesi Linux testlerini çalıştırmayı da denemeleri önerilir. Bu testler, xfstests dosya sistemi test paketinin bir parçasıdır. Ancak bu yayın öncesi testler Android tarafından resmi olarak desteklenmemektedir.

AOSP uygulama ayrıntıları

Bu bölümde AOSP uygulamasıyla ilgili ayrıntılar ve dosya tabanlı şifrelemenin işleyiş şekli açıklanmaktadır. Cihaz üreticilerinin, cihazlarında FBE ve Doğrudan Önyükleme'yi kullanmak için burada herhangi bir değişiklik yapması gerekmez.

fscrypt şifrelemesi

AOSP uygulaması, çekirdekte "fscrypt" şifrelemeyi (ext4 ve f2fs tarafından desteklenir) kullanır ve genellikle aşağıdaki şekilde yapılandırılır:

• Dosya içeriklerini XTS modunda AES-256 ile şifreleme
• Dosya adlarını CBC-CTS modunda AES-256 ile şifreleme

Adiantum şifrelemesi de desteklenir. Adiantum şifrelemesi etkinleştirildiğinde hem dosya içerikleri hem de dosya adları Adiantum ile şifrelenir.

fscrypt, şifreleme politikalarının iki sürümünü destekler: 1. sürüm ve 2. sürüm. 1. sürümün desteği sonlandırılmıştır ve Android 11 ve sonraki sürümlerin yüklü olduğu cihazlar için CDD şartları yalnızca 2. sürümle uyumludur. 2. sürüm şifreleme politikaları, gerçek şifreleme anahtarlarını kullanıcı alanı tarafından sağlanan anahtarlardan türetmek için HKDF-SHA512'yi kullanır.

fscrypt hakkında daha fazla bilgi için yukarı yönlü çekirdek belgelerine bakın.

Depolama sınıfları

Aşağıdaki tabloda, FBE anahtarları ve korudukları dizinler daha ayrıntılı olarak listelenmiştir:

Anahtar depolama ve koruma

Tüm FBE anahtarları vold tarafından yönetilir ve hiç depolanmayan önyükleme anahtarı hariç olmak üzere diskte şifrelenmiş olarak depolanır. Aşağıdaki tabloda, çeşitli FBE anahtarlarının depolandığı konumlar listelenmiştir:

Önceki tabloda gösterildiği gibi, çoğu FBE anahtarı başka bir FBE anahtarı tarafından şifrelenmiş dizinlerde depolanır. Anahtarlar, bunları içeren depolama sınıfının kilidi açılana kadar açılamaz.

vold, tüm FBE anahtarlarına bir şifreleme katmanı da uygular. Dahili depolama alanı için CE anahtarlarının dışındaki her anahtar, TEE dışında gösterilmeyen kendi anahtar mağazası anahtarını kullanarak AES-256-GCM ile şifrelenir. Bu sayede, Doğrulanmış Başlatma tarafından zorunlu kılındığı gibi, güvenilir bir işletim sistemi başlatılmadığı sürece FBE anahtarlarının kilidi açılamaz. Anahtar mağazası anahtarında da geri alma koruması istenir. Bu, Keymaster'ın geri alma korumasını desteklediği cihazlarda FBE anahtarlarının güvenli bir şekilde silinmesine olanak tanır. Geri alma koruması kullanılamadığında en iyi çabayla geriye dönük yedek olarak, anahtarla birlikte depolanan secdiscardable dosyasında depolanan 16.384 rastgele baytın SHA-512 karması, Anahtar Deposu anahtarının Tag::APPLICATION_ID olarak kullanılır. FBE anahtarını kurtarmak için tüm bu baytların kurtarılması gerekir.

Dahili depolama alanı için CE anahtarları, kullanıcının Ekran Kilidi Bilgi Faktörü (LSKF) (PIN, desen veya şifre), güvenli şifre sıfırlama jetonu veya Yeniden Başlatıldığında Devam Et işlemi için hem istemci tarafı hem de sunucu tarafı anahtarları bilinmeden kilidinin açılamamasını sağlayan daha güçlü bir koruma düzeyine sahiptir. Şifre kodu sıfırlama jetonlarının yalnızca iş profilleri ve tümüyle yönetilen cihazlar için oluşturulmasına izin verilir.

Bunu yapmak için vold, kullanıcının sentetik şifresinden türetilen bir AES-256-GCM anahtarı kullanarak her bir CE anahtarını dahili depolama için şifreler. Sentetik şifre, her kullanıcı için rastgele oluşturulan, değiştirilemeyen, yüksek entropili bir kriptografik anahtardır. system_server içindeki LockSettingsService, sentetik şifreyi ve korunma yöntemlerini yönetir.

Sentetik şifreyi LSKF ile korumak için LockSettingsService, LSKF'yi önce scrypt üzerinden geçirerek yaklaşık 25 ms süre ve yaklaşık 2 MiB bellek kullanımı hedefleyerek uzatır. 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 Birim (SE) veya TEE tarafından uygulanan hız sınırlamasıdır.

Cihazda Güvenli Öğe (SE) varsa LockSettingsService, Weaver HAL'i kullanarak, uzatılmış LSKF'yi SE'de depolanan yüksek entropili rastgele bir gizliyle eşler. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: önce uzatılmış LSKF ve Weaver gizlisinden türetilen bir yazılım anahtarıyla, ardından kimlik doğrulamasına bağlı olmayan bir Keystore anahtarıyla. Bu sayede LSKF tahminleri SE tarafından zorunlu olarak sınırlandırılır.

Cihazda SE yoksa LockSettingsService, Güvenlik Bekçisi şifresi olarak uzatılmış LSKF'yi kullanır. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: önce, uzatılmış LSKF'den ve gizlilik için atılabilir bir dosyanın karmasından türetilen bir yazılım anahtarıyla, ardından Gatekeeper kaydına kimlik doğrulaması bağlı bir anahtar deposu anahtarıyla. Bu sayede, LSKF tahminleri TEE tarafından zorunlu kılınan bir hız sınırlamasına tabi tutulur.

LSKF değiştirildiğinde LockSettingsService, sentetik şifrenin eski LSKF'ye bağlanmasıyla ilişkili tüm bilgileri siler. Weaver'ı veya geri çekmeye dayanıklı Keystore anahtarlarını destekleyen cihazlarda bu işlem, eski bağlamanın güvenli bir şekilde silinmesini sağlar. Bu nedenle, burada açıklanan korumalar kullanıcının LSKF'si olmasa bile uygulanır.