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 kullanıcıların herhangi bir veriye erişebilmesi için 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 yapabiliyordu.

Dosya tabanlı şifrelemenin (FBE) ve uygulamaların şifrelemeyi algılamasını sağlayan yeni API'lerin kullanıma sunulmasıyla birlikte, 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:

• Kimlik Bilgisi Şifreli (CE) depolama alanı, varsayılan depolama konumudur ve yalnızca kullanıcı cihazın kilidini açtıktan sonra kullanılabilir.
• 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. Uygulama yaşam döngüsünde, kullanıcının kilit ekranında ilk kez kimlik bilgilerini girmesi üzerine CE depolama alanı kilidinin açılması durumunda uygulamalara bildirim gönderme veya iş profili durumunda işe özel bir güvenlik sorusu sağlama ihtiyacını karşılamak için değişiklikler yapıldı. 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.

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

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 ister:

• Telefon Hizmetleri ve Çevirici
• Kilit ekranına şifre girme için 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ının anahtar yönetimini desteklemek için çeşitli yeni komutlar 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 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 ö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şilememesini sağlamak için KeyMint 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, Direct Boot geliştirici belgelerine göre android:directBootAware olarak ayarlanmalıdır.

Çekirdek desteği

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

CONFIG_FS_ENCRYPTION=y

Daha eski çekirdeklerde, cihazınızın userdata dosya sistemi Ext4 ise CONFIG_EXT4_ENCRYPTION=y, userdata F2FS ise CONFIG_F2FS_FS_ENCRYPTION=y kullanın.

Cihazınız uyarlanabilir depolamayı destekliyorsa veya dahili depolama alanında meta veri şifreleme kullanıyorsa meta veri şifreleme belgelerinde açıklandığı gibi 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 depolama cihazına giden/gelen verileri şifreleyen/şifresini çözen satır içi şifreleme donanımı kullanmayı da düşünebilir. Android ortak çekirdekleri (4.14 ve sonraki sürümler), donanım ve satıcı sürücüsü desteği 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ız eMMC tabanlı depolama alanı 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ş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 nokta üst üste ile ayrılmış en fazla üç parametre içerir:

• contents_encryption_mode parametresi, dosya içeriklerini şifrelemek için hangi şifreleme algoritmasının kullanıldığı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ıldığı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) piyasaya sürüldüyse varsayılan sürüm v2, Android 10 ve önceki bir sürümle piyasaya sürüldüyse 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ımı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ılması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'ı 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 boyutunun 4096 bayt olmasını zorlar. Şifreleme veri birimi boyutu, dosya içeriklerinin şifrelenmesinin 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 kullanan ve f2fs dosya sistemini kullanan bir cihazda kullanılmasını sağlamak 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'dır (veya buna eşdeğer olarak fileencryption=::inlinecrypt_optimized). AES hızlandırması 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ğinizde AES-HCTR2 desteği varsa filenames_encryption_mode değerini aes-256-hctr2 olarak ayarlayarak dosya adlarının şifrelenmesi 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 da kabul edilir. Bu mod, Android'in ortak çekirdeklerinde uygulanmamıştır ancak özel çekirdek yamaları kullanan satıcılar 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çeriği şifreleme işlemi 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 uyarlanabilir depolama alanı birlikte kullanılabilir.

userdata için fileencryption fstab seçeneğinin belirtilmesi, 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ı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 dosyasının iki nokta üst üste ile ayrılmış ilk alanına eşdeğerdir.
• ro.crypto.volume.filenames_mode dosya adlarını seçer şifreleme modu. 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, /data'nin tüm üst düzey dizinlerine sistem DE anahtarını uygular. Ancak sistem DE anahtarının kendisini içeren dizin ve kullanıcı CE veya DE dizinlerini içeren dizinler gibi şifrelenmemiş olması gereken dizinler bu kapsamın dışındadır. Şifreleme anahtarları özyinelemeli olarak uygulanır ve alt dizinler tarafından geçersiz kılınamaz.

Android 11 ve sonraki sürümlerde, dizinler için geçerli olan init anahtar, init komut dosyalarındaki mkdir komutunun encryption=<action> bağımsız değişkeniyle kontrol edilebilir. <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 eklemek mümkündür. 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 özelliğin bilinen tek kabul edilebilir kullanım alanı, eski OTA özelliklerini desteklemektir.

Sistem uygulamalarında doğrudan başlatma özelliğini destekleme

Uygulamaları doğrudan başlatmaya 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ısaltmasıdır.

defaultToDeviceProtectedStorage özelliği, varsayılan uygulama depolama konumunu CE depolama alanı yerine DE depolama alanına 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ı verilerin kişisel bilgi içermediğinden emin olmak için 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ı benzerleriyle aynı işlevi görür.

• 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ı iki anahtar alır: bir DE ve bir CE anahtarı. Özel bir kullanıcı olduğundan User 0 önce cihazda oturum açmalıdır. 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. İş sorgulaması 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 yönetme

Kurtarma bölümü, userdata bölümündeki DE ile korunan depolama alanına erişemiyor. FBE'yi 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 (örneğin, 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şlem bu dizine erişmemelidir.

Doğrulama

Özelliğin uygulanan sürümünün beklendiği 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 çalışıyorsa 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 gerçekleştirebilir. FBE'nin etkin olduğu bir cihazda:

• ro.crypto.state öğesinin mevcut olup olmadığını kontrol edin
  • ro.crypto.state cihazının şifrelendiğinden emin olun
• ro.crypto.type dosyasının 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 otomotiv cihazı) kullanılıyorsa ana kullanıcı 10 numaralı kullanıcıdır. Bu nedenle, aşağıdaki 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 üst akış 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 doğrudan başlatma özelliğini kullanmak için burada herhangi bir değişiklik yapması gerekmez.

fscrypt şifreleme

AOSP uygulaması, çekirdekte "fscrypt" şifrelemesini (ext4 ve f2fs tarafından desteklenir) kullanır ve normalde şu şekilde yapılandırılır:

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

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

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

Önceki tabloda gösterildiği gibi, çoğu FBE anahtarı başka bir FBE anahtarıyla şifrelenmiş dizinlerde saklanı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 alanı 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 bu baytların tümünün kurtarılması gerekir.

Dahili depolama alanındaki CE anahtarları, kullanıcının kilit ekranı bilgi faktörü (LSKF) (PIN, desen veya şifre), güvenli geçiş kodu sıfırlama jetonu ya da yeniden başlatmada devam etme 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ı yalnızca iş profilleri ve tümüyle 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. Sentezlenmiş şifre, her kullanıcı için rastgele oluşturulan, değiştirilemez ve yüksek entropili bir kriptografik sırdır. LockSettingsServicesystem_server, sentezlenmiş şifreyi ve korunma şekillerini yönetir.

LSKF ile yapay şifreyi korumak için, LockSettingsService öncelikle LSKF'yi scrypt'den geçirerek uzatır. Bu işlem yaklaşık 25 ms sürer ve yaklaşık 2 MiB bellek kullanılır. LSKF'ler genellikle kısa olduğundan bu adım genellikle fazla güvenlik sağlamaz. Temel güvenlik katmanı, aşağıda açıklanan güvenli öğe (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: ilk olarak, uzatılmış LSKF ve Weaver sırrından türetilen bir yazılım anahtarıyla, ikinci olarak da kimlik doğrulama ile sınırlı olmayan bir anahtar deposu 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 bunun yerine LockSettingsService uzatılmış LSKF, Gatekeeper şifresi olarak kullanılır. LockSettingsService daha sonra sentetik şifreyi iki kez şifreler: İlk olarak, uzatılmış LSKF'den ve silinebilir bir dosyanın karma oluşturma işleminden türetilen bir yazılım anahtarıyla, ikinci olarak da Gatekeeper kaydına kimlik doğrulama ile bağlı bir anahtar deposu anahtarıyla. Bu, LSKF tahminlerinin TEE ile zorunlu kılınan hız 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 alma işlemine dirençli Keystore anahtarlarını destekleyen cihazlarda bu, 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.