Dosya tabanlı şifreleme

Android 7.0 ve sonraki sürümler, dosya tabanlı şifrelemeyi (FBE) destekler. Dosya tabanlı şifreleme, farklı dosyaların birbirinden 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 Direct Boot API'lerini nasıl kullanabileceği açıklanmaktadır.

Android 10 ve sonraki sürümlerle kullanıma sunulan 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 Başlatma adlı yeni bir özelliği etkinleştirir. Doğrudan başlatma, şifrelenmiş cihazların doğrudan kilit ekranına başlatılmasına olanak tanır. Daha önce, tam disk şifreleme (FDE) kullanan şifrelenmiş cihazlarda, herhangi bir veriye erişilebilmesi için kullanıcıların kimlik bilgilerini sağlaması gerekiyordu. Bu da telefonun en temel işlemler dışında hiçbir işlemi gerçekleştirememesine neden oluyordu. Örneğin, alarmlar çalışmıyor, erişilebilirlik hizmetleri kullanılamıyor ve telefonlar arama alamıyor, yalnızca temel acil durum arama işlemlerini gerçekleştirebiliyordu.

Dosya tabanlı şifrelemenin (FBE) ve uygulamaların şifrelemeden haberdar olmasını sağlayan yeni API'lerin kullanıma sunulmasıyla bu uygulamaların sınırlı bir bağlamda çalışması mümkün hale geldi. Bu işlem, kullanıcılar kimlik bilgilerini sağlamadan önce yapılabilir ve özel kullanıcı bilgileri korunmaya devam eder.

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 Bilgileriyle Şifrelenmiş (CE) depolama alanı.
• Cihazda şifrelenmiş (DE) depolama alanı: Hem doğrudan başlatma modunda hem de kullanıcı cihazın kilidini açtıktan sonra kullanılabilen bir depolama konumudur.

Bu ayrım, şifreleme artık yalnızca başlatma zamanı şifresine dayalı olmadığından aynı anda birden fazla kullanıcının korunmasına olanak tanıyarak iş profillerini daha güvenli hale getirir.

Doğrudan Başlatma API'si, şifreleme uyumlu uygulamaların bu alanların her birine erişmesine olanak tanır. Kullanıcının CE depolama alanının kilidi, kilit ekranında ilk kez kimlik bilgileri girildiğinde veya iş profili söz konusu olduğunda iş sorgulaması sağlandığında açılır. Bu durumda uygulamaların bilgilendirilmesi gerektiğinden uygulama yaşam döngüsünde değişiklikler yapılmıştır. Android 7.0 çalıştıran cihazlar, FBE'yi uygulayıp uygulamadıklarına bakılmaksızın bu yeni API'leri ve yaşam döngülerini desteklemelidir. Ancak FBE olmadan DE ve CE depolama alanları her zaman kilitli olmayan durumdadı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 şartları karşılayan cihazlarda etkinleştirilmesi gerekir. FBE kullanmayı tercih eden üreticiler, kullanılan çip üzerinde sisteme (SoC) göre özelliği optimize etmenin yollarını araştırabilir.

AOSP'deki tüm gerekli paketler, doğrudan başlatma özelliğini destekleyecek şekilde güncellenmiştir. Ancak cihaz üreticileri bu uygulamaların özelleştirilmiş sürümlerini kullandığında, en azından aşağıdaki hizmetleri sağlayan doğrudan başlatma özellikli paketlerin bulunduğundan emin olmak isterler:

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

Örnekler ve kaynak

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

• AOSP Çevirici (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 özellikli uygulama ve hizmetlerle ilgili daha fazla örneği, AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutunu çalıştırarak bulabilirsiniz.

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 şifreleme veya F2FS şifreleme için çekirdek desteği.
• KeyMint (veya Keymaster 1.0 ya da sonraki sürümler) Desteği. Keymaster 0.3, gerekli özellikleri sağlamadığı veya şifreleme anahtarları için yeterli koruma sağlamadığı için desteklenmez.
• KeyMint/Keymaster ve Gatekeeper, DE anahtarlarının korunması için güvenilir yürütme ortamı (TEE) içinde uygulanmalıdır. Böylece yetkisiz bir OS (cihaza yüklenen özel OS) DE anahtarlarını kolayca isteyemez.
• DE anahtarlarına yetkisiz bir işletim sistemi tarafından erişilemediğinden emin olmak için KeyMint başlatma işlemine bağlı Donanım Güven Kökü ve Doğrulanmış Başlatma gerekir.

Uygulama

Öncelikle, çalar saat, telefon ve erişilebilirlik özellikleri gibi uygulamalar, Doğrudan Başlatma geliştirici belgelerine göre android:directBootAware olarak ayarlanmalıdır.

Çekirdek desteği

Ext4 ve F2FS şifrelemesi için çekirdek desteği, Android ortak çekirdeklerinin 3.18 ve sonraki sürümlerinde mevcuttur. 5.1 veya daha yeni bir çekirdekte etkinleştirmek için şunu kullanın:

CONFIG_FS_ENCRYPTION=y

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

Cihazınız dahili hale getirilebilir depolama alanını destekliyorsa veya dahili depolama alanında meta veri şifreleme kullanıyorsa meta veri şifreleme belgelerinde açıklandığı şekilde meta veri şifreleme için gereken çekirdek yapılandırma seçeneklerini de etkinleştirin.

Cihaz üreticileri, Ext4 veya F2FS şifreleme için işlevsel desteğin 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 gönderilirken/depolama cihazından alınırken şifreleyen/şifresini çözen satır içi şifreleme donanımı kullanmayı da düşünebilir. Android ortak çekirdekleri (sürüm 4.14 ve sonraki sürümler), donanım ve tedarikçi sürücüsü desteği mevcut olduğunda satır içi şifrelemenin kullanılmasına olanak tanıyan bir çerçeve içerir. Satır içi şifreleme çerçevesi, aşağıdaki çekirdek yapılandırma seçenekleri ayarlanarak etkinleştirilebilir:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Cihazınızda UFS tabanlı depolama alanı kullanılıyorsa şunları da etkinleştirin:

CONFIG_SCSI_UFS_CRYPTO=y

Cihazınızda eMMC tabanlı depolama alanı kullanılı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ştirmeniz gerekir. Bu işlem, dahili hale getirilebilir depolama alanında da FBE'yi otomatik olarak etkinleştirir. Ancak dahili hale getirilebilir depolama alanındaki ş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 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 şifreleme algoritmasının kullanılacağını tanımlar. aes-256-xts veya adiantum olabilir. Android 11'den itibaren, varsayılan algoritmayı (aes-256-xts) belirtmek için boş da bırakılabilir.
• filenames_encryption_mode parametresi, dosya adlarını şifrelemek için hangi şifreleme algoritmasının kullanılacağını tanımlar. aes-256-cts, aes-256-heh, adiantum veya aes-256-hctr2 olabilir. 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 listesidir. Aşağıdaki işaretler desteklenir:
  • v1 işareti, 1. sürüm şifreleme politikalarını seçer; v2 işareti, 2. sürüm şifreleme politikalarını seçer. Sürüm 2 şifreleme politikaları, daha güvenli ve esnek bir anahtar türetme işlevi kullanır. Cihaz Android 11 veya sonraki bir sürümle (ro.product.first_api_level tarafından belirlendiği şekilde) kullanıma sunulduysa varsayılan sürüm v2, Android 10 ve önceki sürümlerle kullanıma sunulduysa v1'dir.
  • 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, 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) oluşturulması buna göre ayarlanır.
  • emmc_optimized işareti inlinecrypt_optimized işaretine benzer ancak IV'leri 32 bit ile 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 bit 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 kullanın. Bu işaret, UFS tabanlı depolama alanında hiçbir zaman kullanılmamalıdır. UFS spesifikasyonu, 64 bit IV'lerin kullanımına izin verir.
  • Donanım sarmalamalı satır içi şifreleme anahtarlarını destekleyen cihazlarda, wrappedkey veya wrappedkey_v0 işaretini ekleyerek FBE anahtarlarını donanım sarmalamalı hale getirebilirsiniz. wrappedkey modern sürümdür; wrappedkey_v0 yalnızca wrappedkey sürümünü desteklemeyen veya wrappedkey_v0 ile kullanıma sunulmuş cihazlarda kullanılmalıdır. Daha fazla bilgi için Sarmalanmış anahtarları etkinleştirme başlıklı makaleyi inceleyin.
  • dusize_4k işareti, dosya sistemi blok boyutu 4096 bayt olmasa bile şifreleme veri birimi boyutunu 4096 bayt olmaya zorlar. Şifreleme veri birimi boyutu, dosya içeriği şifrelemesinin ayrıntı düzeyidir. Bu işaret, Android 15'ten itibaren kullanılabilir. Bu işaret yalnızca 4.096 bayttan büyük veri birimlerini desteklemeyen satır içi şifreleme donanımının, 4.096 bayttan büyük sayfa boyutu ve f2fs dosya sistemi kullanan bir cihazda kullanılması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 şeklindedir. Satır içi şifreleme donanımı kullanıyorsanız çoğu cihaz için önerilen ayar fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (veya eşdeğeri fileencryption=::inlinecrypt_optimized) şeklindedir. Herhangi bir AES hızlandırma biçimi olmayan cihazlarda fileencryption=adiantum ayarlanarak AES yerine Adiantum kullanılabilir.

Android 14'ten itibaren, hızlandırılmış kriptografi talimatları içeren cihazlarda dosya adı şifreleme için tercih edilen mod AES-HCTR2'dir. Ancak AES-HCTR2 yalnızca daha yeni Android çekirdekleri tarafından desteklenir. Gelecekteki bir Android sürümünde, dosya adı şifreleme için varsayılan mod olması planlanmaktadır. Çekirdeğiniz AES-HCTR2'yi destekliyorsa filenames_encryption_mode değerini 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 ve önceki sürümlerle kullanıma sunulan 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 tedarikçiler tarafından uygulanabilir. Bu modun ürettiği disk üzerindeki biçim, satıcıya özgüydü. Android 11 veya sonraki sürümlerle kullanıma sunulan cihazlarda bu moda artık izin verilmez ve bunun yerine standart bir şifreleme biçimi kullanılmalıdır.

Varsayılan olarak, dosya içeriklerinin şifrelemesi 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 itibaren FBE ve dahili hale getirilebilir depolama alanı birlikte kullanılabilir.

userdata için fileencryption fstab seçeneğini belirtmek, dahili hale getirilebilir depolama alanında hem FBE'yi hem de meta veri şifrelemeyi otomatik olarak etkinleştirir. Ancak PRODUCT_PROPERTY_OVERRIDES içinde özellikleri ayarlayarak dahili hale getirilebilir 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), dahili hale getirilebilir depolama alanında FBE şifreleme biçimini seçer. fileencryption fstab seçeneğinin bağımsız değişkeniyle aynı söz dizimine sahiptir ve aynı varsayılanları kullanır. Burada ne kullanacağınızı öğrenmek için yukarıdaki fileencryption ile ilgili önerilere bakın.
• ro.crypto.volume.metadata.encryption, dahili hale getirilebilir depolama alanında 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 öğesinin iki nokta üst üste ile ayrılmış ilk alanına eşdeğerdir.
• ro.crypto.volume.filenames_mode, dosya adları şifreleme modunu seçer. Bu, ro.crypto.volume.options öğesinin iki nokta üst üste ile ayrılmış ikinci alanına eşdeğerdir. Ancak Android 10 ve önceki sürümlerle kullanıma sunulan cihazlarda varsayılan değer aes-256-heh şeklindedir. Çoğu cihazda bu değerin açıkça aes-256-cts olarak geçersiz kılınması gerekir.
• ro.crypto.fde_algorithm ve ro.crypto.fde_sector_size, dahili hale getirilebilir depolama alanında meta veri şifreleme biçimini seçin. Meta veri şifreleme belgelerini inceleyin.

KeyMint ile entegrasyon

KeyMint HAL, early_hal sınıfının bir parçası olarak başlatılmalıdır. Bunun nedeni, FBE'nin KeyMint'in post-fs-data başlatma aşamasında istekleri işlemeye hazır olmasını gerektirmesidir. Bu aşamada vold ilk anahtarları ayarlar.

Dizinleri hariç tutma

init, sistem DE anahtarını /data dizininin tüm üst düzey dizinlerine uygular. Sistem DE anahtarını içeren dizin ve kullanıcı CE veya DE dizinlerini içeren dizinler gibi şifrelenmemiş olması gereken dizinler buna dahil değildir. Şifreleme anahtarları yinelemeli olarak uygulanır ve alt dizinler tarafından geçersiz kılınamaz.

Android 11 ve sonraki sürümlerde, dizinlere uygulanan anahtar, init komut dosyalarındaki mkdir komutunun encryption=<action> bağımsız değişkeni tarafından kontrol edilebilir.init <action> için olası değerler, Android init dili için README dosyasında belgelenmiştir.

Android 10'da init şifreleme işlemleri aşağıdaki konuma sabit kodlanmıştır:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Android 9 ve önceki sürümlerde konum şu şekildeydi:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Belirli dizinlerin şifrelenmesini tamamen ö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ını eklemelidir. Bu işlem, güvenilmeyen tüm uygulamaları hariç tutar.

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

Sistem uygulamalarında Doğrudan Başlatma'yı destekleme

Uygulamaları doğrudan başlatma 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ında kullanılabilir. directBootAware özelliği herkes tarafından kullanılabilir.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Uygulama düzeyindeki directBootAware özelliği, uygulamadaki tüm bileşenleri şifreleme uyumlu olarak işaretlemenin kısa yoludur.

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

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ı muadilleriyle 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ı. Özel bir kullanıcı olduğu için cihazda ilk olarak 0 numaralı kullanıcının oturum açması gerekir. Bu, Cihaz Yönetimi kullanımları için geçerlidir.

Kripto uyumlu 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 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 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 de iki anahtar alır: DE ve CE. İş sınaması karşılandığında profil kullanıcısının kilidi açılır ve KeyMint (TEE'de), profilin TEE anahtarını sağlayabilir.

Güncellemeleri işleme

Kurtarma bölümü, userdata bölümündeki DE korumalı depolama alanına erişemiyor. FBE uygulayan cihazların, A/B sistem güncellemelerini kullanarak OTA'yı desteklemesi önemle tavsiye edilir. OTA, normal çalışma sırasında uygulanabildiğinden şifrelenmiş sürücüdeki verilere erişmek için kurtarma işlemine gerek yoktur.

userdata bölümündeki OTA dosyasına erişmek için kurtarma gerektiren eski bir OTA çözümü kullanırken:

1. userdata bölümünde üst düzey bir dizin (ör. misc_ne) oluşturun.
2. Bu üst düzey dizini şifrelenmemiş olacak şekilde yapılandırın (Dizinleri hariç tutma bölümüne bakın).
3. OTA paketlerini barındırmak için üst düzey dizinde bir dizin oluşturun.
4. 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 amaçlandığı gibi çalıştığından emin olmak için önce DirectBootHostTest ve EncryptionTest gibi birçok CTS şifreleme testini çalıştırın.

Cihazda Android 11 veya sonraki bir sürüm yüklüyse vts_kernel_encryption_test'i de ç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 yapabilir. FBE'nin etkin olduğu bir cihazda:

• ro.crypto.state öğesinin mevcut olup olmadığını kontrol edin
  • ro.crypto.state şifrelenmiş olmalıdır
• ro.crypto.type öğesinin mevcut olup olmadığını kontrol edin
  • ro.crypto.type özelliğinin file olarak ayarlandığından emin olun.

Ayrıca test kullanıcıları, cihaz başlatıldıktan sonra ilk kez kilidi açılmadan önce CE depolama alanının kilitli olduğunu doğrulayabilir. Bunun için userdebug veya eng derlemesi 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. Cihazda Headless System User Mode (çoğu Automotive cihazı) kullanılıyorsa ana kullanıcı, kullanıcı 10'dur. Bu nedenle şu komutu çalıştırın:

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

Diğer cihazlarda (Automotive olmayan çoğu cihaz) ana kullanıcı, kullanıcı 0'dır. Bu nedenle şu komutu ç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 şifrelendiğini ve şifrelerini çözecek anahtarın henüz mevcut olmadığını gösterir. Dosya adları düz metin olarak listeleniyorsa bir sorun var demektir.

Cihaz üreticilerinin, cihazlarında veya çekirdeklerinde fscrypt için yukarı akış Linux testlerini çalıştırmayı denemeleri de önerilir. Bu testler, xfstests dosya sistemi test paketinin bir parçasıdır. Ancak bu upstream testleri Android tarafından resmi olarak desteklenmez.

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 Direct Boot'u kullanmak için burada herhangi bir değişiklik yapması gerekmez.

fscrypt şifrelemesi

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 şifreleme
• Dosya adlarını CBC-CTS modunda AES-256 ile şifreleme

Adiantum şifreleme 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: sürüm 1 ve sürüm 2. 1. sürüm kullanımdan kaldırılmıştır ve Android 11 ve sonraki sürümlerle piyasaya sürülen cihazlar için CDD şartları yalnızca 2. sürümle uyumludur. Sürüm 2 şifreleme politikaları, kullanıcı alanı tarafından sağlanan anahtarlardan gerçek şifreleme anahtarlarını türetmek için HKDF-SHA512 kullanır.

fscrypt hakkında daha fazla bilgi için upstream ç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 diskte şifrelenmiş olarak saklanır. Hiçbir şekilde saklanmayan önyükleme anahtarı bu kapsamda değildir. Aşağıdaki tabloda, çeşitli FBE anahtarlarının depolandığı konumlar listelenmiştir:

Yukarıdaki tabloda gösterildiği gibi çoğu FBE anahtarı, başka bir FBE anahtarı tarafından şifrelenen dizinlerde depolanır. Anahtarlar, bulundukları 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 için CE anahtarları dışındaki her anahtar, TEE dışında gösterilmeyen kendi Keystore anahtarı kullanılarak AES-256-GCM ile şifrelenir. Bu sayede, Doğrulanmış Başlatma tarafından zorunlu kılındığı şekilde, güvenilir bir işletim sistemi başlatılmadığı sürece FBE anahtarlarının kilidi açılamaz. Keystore anahtarında geri alma direnci de istenir. Bu sayede, KeyMint'in geri alma direncini desteklediği cihazlarda FBE anahtarları güvenli bir şekilde silinebilir. Geri alma direnci kullanılamadığında en iyi çaba yedek olarak, anahtarla birlikte depolanan secdiscardable dosyasında depolanan 16.384 rastgele baytın SHA-512 karması, Keystore 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ına ait CE anahtarları, kullanıcının Kilit Ekranı Bilgi Faktörü (LSKF) (PIN, desen veya şifre), güvenli şifre kodu sıfırlama jetonu ya da Yeniden Başlatmada Devam Et işlemi için hem istemci tarafı hem de sunucu tarafı anahtarları bilinmeden kilitlerinin açılmamasını sağlayan daha güçlü bir koruma düzeyine sahiptir. Şifre kodu sıfırlama jetonları yalnızca iş profilleri ve tam olarak yönetilen cihazlar için oluşturulabilir.

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

Sentetik şifreyi LSKF ile korumak için LockSettingsService, önce LSKF'yi scrypt üzerinden geçirerek genişletir. Bu işlem yaklaşık 25 ms sürer ve yaklaşık 2 MiB bellek kullanır. LSKF'ler genellikle kısa olduğundan bu adım genellikle çok fazla güvenlik sağlamaz. Ana güvenlik katmanı, aşağıda açıklanan güvenlik unsuru (SE) veya TEE tarafından uygulanan sıklık sınırlamasıdır.

Cihazda Weaver HAL uygulanıyorsa LockSettingsService, Weaver'ı kullanarak genişletilmiş LSKF'yi SE veya TEE'de depolanan yüksek entropili rastgele bir gizli anahtarla eşler. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: İlk olarak, uzatılmış LSKF ve Weaver gizli anahtarından türetilen bir yazılım anahtarıyla, ikinci olarak ise kimlik doğrulama ile bağlı olmayan bir Keystore anahtarıyla. Bu sayede, LSKF tahminleri için SE veya TEE tarafından uygulanan sıklık sınırlaması sağlanır.

Cihazda Weaver uygulanmıyorsa LockSettingsService, bunun yerine uzatılmış LSKF'yi Gatekeeper şifresi olarak kullanır. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: İlk olarak, uzatılmış LSKF'den türetilen bir yazılım anahtarı ve secdiscardable dosyasının karması ile, ikinci olarak ise Gatekeeper kaydına Auth ile bağlı bir Keystore anahtarı ile. Bu, LSKF tahminlerinin TEE tarafından zorunlu kılınan sıklık sınırlamasını sağlar.

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