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 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 Başlatma adlı yeni bir özelliği etkinleştirir. Doğrudan Başlatma, şifrelenmiş cihazların doğrudan kilit ekranına başlatılmasını sağlar. Önceden, tam disk şifreleme (FDE) kullanan şifrelenmiş cihazlarda kullanıcıların herhangi bir veriye erişilmeden önce kimlik bilgilerini sağlamaları gerekiyordu. Bu durum, telefonun en temel işlemler hariç tüm işlemleri yapmasını engelliyordu. Ö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.

Uygulamaların şifrelemeden haberdar olmasını sağlayan dosya tabanlı şifreleme (FBE) ve yeni API'lerin kullanıma sunulmasıyla bu uygulamalar sınırlı bir bağlam içinde çalışabilir. 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ı.
  • Cihaz Ş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.

Şifreleme artık yalnızca başlatma zamanı şifresine dayalı olmadığından, bu ayırma 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 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ına bakılmaksızın bu yeni API'leri ve yaşam döngülerini desteklemelidir. FBE olmadan da DE ve CE depolama alanı her zaman kilitli durumda kalır.

Ext4 ve F2FS dosya sistemlerinde dosya tabanlı şifrelemenin eksiksiz bir şekilde uygulanması Android Açık Kaynak Projesi (AOSP) içinde sağlanmıştı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şlatmaya duyarlı olacak şekilde güncellendi. Ancak cihaz üreticileri, bu uygulamaların özelleştirilmiş sürümlerini kullandıklarında en azından aşağıdaki hizmetleri sağlayan doğrudan başlatmaya duyarlı paketlerin bulunduğundan emin olmak isterler:

  • 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, birden fazla kullanıcının CE ve DE anahtarları için anahtar yönetimini desteklemek amacıyla vold'a birkaç yeni komut sağlar. Çekirdekteki dosya tabanlı şifreleme özelliklerini kullanacak 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 Çevirici (paketler/uygulamalar/Çevirici)
  • Masa Saati (paketler/uygulamalar/DeskClock)
  • LatinIME (packages/inputmethods/LatinIME)*
  • Ayarlar Uygulaması (paketler/uygulamalar/Ayarlar)*
  • SystemUI (çerçeveler/temel/paketler/SystemUI)*

* defaultToDeviceProtectedStorage manifest özelliğini kullanan sistem uygulamaları

Şifrelemeden haberdar uygulama ve hizmetlere ilişkin diğer örneklere, AOSP kaynak ağacının çerçeveler veya paketler dizininde mangrep directBootAware komutunu çalıştırarak ulaşabilirsiniz.

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 şifrelemesi için çekirdek desteği.
  • HAL 1.0 veya sonraki sürümlerde Keymaster desteği. Gerekli özellikleri sunmadığı veya şifreleme anahtarları için yeterli koruma sağlamadığı için Keymaster 0.3 için destek sunulmaz.
  • DE anahtarları için koruma sağlamak üzere Keymaster/Keystore ve Ağ Geçidi bir Güvenilir Yürütme Ortamı'nda (TEE) uygulanmalıdır. Böylece, yetkilendirilmemiş bir işletim sistemi (cihaza yüklenen özel işletim sistemi) sadece DE anahtarlarını isteyemez.
  • Keymaster başlatmaya bağlı Donanım Kökü ve Doğrulanmış Başlatma, yetkisiz bir işletim sisteminin DE anahtarlarına erişememesini sağlamak için gereklidir.

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.

Kernel desteği

Ext4 ve F2FS şifrelemesi için çekirdek desteği, Android ortak çekirdeklerinde 3.18 ve sonraki sürümlerde kullanılabilir. Bu API'yi 5.1 veya sonraki sürümlerdeki bir çekirdekte 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 kullanın. Cihazınızın 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 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 satır içi şifreleme donanımı uygulamayı da düşünebilir. Bu donanım, depolama cihazına giden veya depolama cihazından giden verileri şifreleyen/şifrelerini çözen bir donanımdır. Android'in ortak çekirdekleri (sürüm 4.14 ve sonraki sürümler), donanım ve satıcı sürücü desteği sunulduğ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 aşağıdakileri de 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'nin etkinleştirilmesi için dahili depolamada (userdata) etkinleştirilmesi gerekir. Bu işlem, benimsenebilir depolama alanında FBE'yi de otomatik olarak etkinleştirir. Ancak, gerekirse benimsenebilir depolama alanındaki şifreleme biçimi 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 ile 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 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üm şifreleme politikaları, daha güvenli ve esnek bir anahtar türetme işlevi kullanır. Cihaz, Android 11 veya sonraki bir sürümde (ro.product.first_api_level tarafından belirlenir.) başlatıldıysa v2, Android 10 veya önceki sürümlerde başlatıldıysa varsayılan değer v1 olur.
    • 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, CE veya DE anahtarı başına yalnızca 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ımına izin verir.
    • Donanımla sarmalanmış anahtarları destekleyen cihazlarda wrappedkey_v0 işareti, FBE için donanımla sarmalanmış anahtarların kullanımını etkinleştirir. 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 değeri ayarlanarak AES yerine Adiantum kullanılabilir.

Android 14'ten bu yana, hızlandırılmış kriptografi talimatlarına sahip cihazlar için tercih edilen dosya adı şifreleme modu AES-HCTR2'dir. Ancak yalnızca yeni Android çekirdekleri AES-HCTR2'yi destekler. Gelecekteki bir Android sürümünde, dosya adı şifrelemesi için varsayılan mod olması planlanmaktadır. Çekirdeğiniz AES-HCTR2 desteği içeriyorsa filenames_encryption_mode, aes-256-hctr2 olarak ayarlanarak dosya adı şifrelemesi için etkinleştirilebilir. En basit şekilde bu işlem fileencryption=aes-256-xts:aes-256-hctr2 ile yapılır.

Android 10 veya önceki bir sürümle kullanıma sunulan cihazlarda, fileencryption=ice dosya içeriği şifreleme modunun kullanımını belirtmek için de 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ümlerin yüklü olduğu cihazlarda bu moda artık izin verilmez ve bunun yerine standart ş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 ekleme seçeneğini de ekleyin. Örneğin, tam bir fstab satırı aşağıdaki gibi 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ğinin belirtilmesi, benimsenebilir depolama alanında hem FBE hem de meta veri şifreleme özelliğini otomatik olarak etkinleştirir. Ancak PRODUCT_PROPERTY_OVERRIDES içinde özellikleri ayarlayarak benimsenebilir depolama alanındaki FBE veya meta veri şifreleme biçimlerini geçersiz kılabilirsiniz.

Android 11 veya sonraki sürümlerin yüklü olduğu cihazlarda aşağıdaki özellikleri kullanın:

  • ro.crypto.volume.options (Android 11'deki yeni özellik), uyarlanabilir depolama alanında FBE şifreleme biçimini seçer. fileencryption fstab seçeneğindeki bağımsız değişkenle aynı söz dizimine sahiptir ve aynı varsayılanları kullanır. Burada ne kullanabileceğiniz için yukarıdaki fileencryption ile ilgili önerilere bakın.
  • ro.crypto.volume.metadata.encryption, kabul edilebilir depolama alanındaki meta veri şifreleme biçimini seçer. Meta veri şifreleme dokümanlarını inceleyin.

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 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 veya önceki sürümlerle kullanıma sunulan cihazlarda varsayılan değer aes-256-heh'dur. Ç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, benimsenebilir depolama alanındaki meta veri şifreleme biçimini seçer. 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 istekleri post-fs-data başlatma aşamasında (vold ilk anahtarları ayarlarken) işlemeye hazır olmasını gerektirmesidir.

Dizinleri hariç tutma

init, sistem DE anahtarını, sistem DE anahtarının kendisini içeren dizin 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 yönelik encryption=<action> bağımsız değişkeni ile kontrol edilebilir. Olası <action> değerleri, Android init dili için README (OKU) alanında belgelenmiştir.

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 şu şekildeydi: 

/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, güvenilmeyen tüm uygulamaları hariç tutmalıdır.

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

Sistem uygulamalarında doğrudan Başlatma desteği

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ğini herkesin kullanabilir. 

<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 alanını işaret etmek 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 depolamayı 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 Bağlamı açıkça yönetmek için aşağıdaki Sistem API'leri kullanılabilir. Bu, Cihaz Korumalı eşdeğerleriyle 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ı iki anahtara sahip olur: DE ve CE anahtarı. 0. Kullanıcı, özel bir kullanıcı olduğundan öncelikle cihaza giriş yapmalıdır. Bu durum, Cihaz Yönetimi kullanımlarına uygundur.

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 için CE şifreli dizinlere 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 işleme

Kurtarma bölümü, kullanıcı verileri bölümündeki DE korumalı depolama alanına erişemiyor. FBE'yi uygulayan cihazların, A/B sistem güncellemelerini kullanarak OSA'yı desteklemesi önemle tavsiye edilir. OTA normal çalışma sırasında uygulanabileceğinden şifrelenmiş sürücüdeki verilere erişmek için kurtarmaya 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 dizine ve içeriğine erişimi kontrol etmek için bir SELinux kuralı ve dosya bağlamları ekleyin. Yalnızca OTA güncellemeleri alan işlem veya uygulamalar bu dizinde okuma ve yazma yapabilir. Başka hiçbir uygulama veya işlem bu dizine erişemez.

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

Buna ek olarak, 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 dosyasının şifrelenmiş olduğundan emin olun
  • ro.crypto.type öğesinin mevcut olup olmadığını kontrol edin
    • ro.crypto.type değerinin file olarak ayarlandığından emin olun

Ayrıca test kullanıcıları, cihaz başlatıldıktan sonra ilk kez kilidi açılmadan CE depolama alanının kilitli olduğunu doğrulayabilir. Bunu yapmak için bir userdebug veya eng derlemesi kullanın, ana kullanıcıda bir 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 gözetimsiz sistem kullanıcı modunu (çoğu otomotiv cihazında) kullanıyorsa 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ğunda) 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ı şifrelenmemiş metin olarak listeleniyorsa bir sorun vardır.

Cihaz üreticilerinin, cihazlarında veya çekirdeklerinde fscrypt için yukarı akış Linux testlerini çalıştırmayı öğrenmeleri de önerilir. Bu testler, xfstests dosya sistemi test paketinin bir parçasıdır. Ancak, bu yukarı 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 Ö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. Sürüm 1 kullanımdan kaldırılmıştır. Android 11 ve sonraki sürümlerle kullanıma sunulan cihazlar için CDD gereksinimleri yalnızca sürüm 2 ile 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ı bir şekilde listelenmiştir:

Depolama sınıfı Açıklama Dizinler
Şifrelenmemiş FBE tarafından korunamayacak veya korunması gerekmeyen /data dizinleri. Meta veri şifrelemesi kullanan cihazlarda, bu dizinler gerçek anlamda şifresiz değildir, ancak System DE'ye eşdeğer meta veri şifreleme anahtarıyla korunur.
  • Sistem DE olan /data/apex/decompressed ve /data/apex/ota_reserved hariç /data/apex
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Alt dizinleri farklı FBE anahtarları kullanan tüm dizinler. Örneğin, her /data/user/${user_id} dizini kullanıcı başına bir anahtar kullandığından /data/user kendisi anahtar kullanmaz.
System DE Belirli bir kullanıcıya bağlı olmayan, cihazda şifrelenmiş veriler
  • /data/apex/decompressed
  • /data/apex/ota_reserved
  • /data/app
  • /data/misc
  • /data/system
  • /data/vendor
  • Bu tabloda farklı bir sınıfa sahip olduğundan bahsedilmeyen /data diğer tüm alt dizinleri
Başlatma başına Yeniden başlatmadan sonra kalması gerekmeyen geçici sistem dosyaları /data/per_boot
Kullanıcı CE (dahili) Dahili depolama alanında kullanıcı başına kimlik bilgisiyle şifrelenmiş veriler
  • /data/data (/data/user/0 için takma ad)
  • /data/media/${user_id}
  • /data/misc_ce/${user_id}
  • /data/system_ce/${user_id}
  • /data/user/${user_id}
  • /data/vendor_ce/${user_id}
Kullanıcı DE (dahili) Dahili depolama alanında kullanıcı başına cihazda şifrelenmiş veriler
  • /data/misc_de/${user_id}
  • /data/system_de/${user_id}
  • /data/user_de/${user_id}
  • /data/vendor_de/${user_id}
Kullanıcı CE (kabul edilebilir) Dahili hale getirilebilir depolama alanında kullanıcı başına kimlik bilgisiyle şifrelenmiş veriler
  • /mnt/expand/${volume_uuid}/media/${user_id}
  • /mnt/expand/${volume_uuid}/misc_ce/${user_id}
  • /mnt/expand/${volume_uuid}/user/${user_id}
Kullanıcı DE (kabul edilebilir) Kullanıcı başına, cihazda şifrelenmiş verileri benimsenebilir depolama alanında saklayabilirsiniz.
  • /mnt/expand/${volume_uuid}/misc_de/${user_id}
  • /mnt/expand/${volume_uuid}/user_de/${user_id}

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:

Anahtar türü Anahtar konumu Anahtar konumunun depolama sınıfı
Sistem DE anahtarı /data/unencrypted Şifrelenmemiş
Kullanıcı CE (dahili) anahtarları /data/misc/vold/user_keys/ce/${user_id} System DE
Kullanıcı DE (dahili) anahtarları /data/misc/vold/user_keys/de/${user_id} Sistem DE
Kullanıcı CE (uygulanabilir) anahtarları /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} Kullanıcı CE (dahili)
Kullanıcı DE (uygulanabilir) anahtarları /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} DE kullanıcısı (dahili)

Ö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 için CE anahtarlarının yanı sıra tüm anahtarlar, TEE dışına açık olmayan kendi Anahtar Deposu anahtarı kullanılarak AES-256-GCM ile şifrelenir. Bu, Doğrulanmış Başlatma tarafından zorunlu kılındığı şekilde güvenilir bir işletim sistemi başlatılmadıkça FBE anahtarlarının kilidinin açılmamasını sağlar. Anahtar deposu anahtarında geri alma direnci de istenir. Bu, Keymaster'ın geri alma direncini 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 uygulama kimliği etiketi olarak kullanılır. Bir FBE anahtarını kurtarmak için tüm bu baytların kurtarılması gerekir.

Dahili depolama için 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şlatma Devam Ettirme işlemi için hem istemci hem de sunucu tarafı anahtarları bilinmeden kilitlerin açılmaması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.

vold bunu sağlamak için kullanıcının sentetik şifresinden türetilen bir AES-256-GCM anahtarını kullanarak her bir CE anahtarını dahili depolama için şifreler. Yapay şifre, her kullanıcı için rastgele oluşturulan sabit, yüksek entropili kriptografik bir gizli 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 uzatır. 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 fazla güvenlik sağlamaz. Ana güvenlik katmanı, aşağıda açıklanan Güvenli Öğe (SE) veya TEE tarafından zorunlu kılınan hız sınırlamasıdır.

Cihazda Güvenli Öğe (SE) varsa LockSettingsService, Weaver HAL'i kullanarak gerilmiş 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, Gatekeeper şifresi olarak uzatılmış LSKF'yi kullanır. LockSettingsService daha sonra, yapay şifreyi iki kez şifreler: İlk olarak uzatılmış LSKF'den türetilen bir yazılım anahtarı ve gizli disk çıkarılabilir bir dosyanın karması, ikinci olarak ise Kapıyı Kalıcı kaydına bağlı olan bir Anahtar Deposu anahtarı kullanır. 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. Bu, Weaver veya geri almaya dirençli Anahtar Deposu anahtarlarını destekleyen cihazlarda eski bağlamanın güvenli bir şekilde silinmesini garanti eder. Bu nedenle, burada açıklanan korumalar kullanıcının LSKF'si olmasa bile uygulanır.