Çoğu disk ve dosya şifreleme yazılımı gibi Android'in depolama şifrelemesi de geleneksel olarak şifrelemenin yapılabilmesi için sistem belleğinde bulunan ham şifreleme anahtarlarını kullanır. Şifreleme yapıldığında bile tarafından kullanılabilmesini sağlayan özel bir donanımla, yazılımların şifreleme anahtarlarını yönetmenizi sağlar.
Geleneksel olarak bu durum bir sorun olarak görülmez çünkü anahtarlar hazır olmaz. Bu, saldırıya uğrayan çevrimdışı saldırı türüdür. Bu saldırı türü, korumayı amaçlar. Bununla birlikte, soğuk başlatma saldırıları gibi diğer saldırı türlerine ve saldırganın cihazın güvenliğini tamamen ihlal etmeden sistem belleğini sızdırabileceği online saldırılara karşı daha fazla koruma sağlamak istiyoruz.
Android 11, bu sorunu çözmek için donanım desteğinin bulunduğu donanımla kaplanmış anahtarlar için destek sunmuştur. Donanımla sarmalanmış anahtarlar, yalnızca özel donanım tarafından ham biçimde bilinen depolama anahtarlardır. Yazılım, bu anahtarları yalnızca sarmalanmış (şifrelenmiş) biçimde görür ve onlarla çalışır. Bu donanım, depolama anahtarları oluşturma ve içe aktarma, depolama anahtarlarını geçici ve uzun süreli biçimlere sarmalama, alt anahtarlar türetme, bir alt anahtarı doğrudan satır içi şifreleme motoruna programlama ve yazılıma ayrı bir alt anahtar döndürme işlemlerini yapabilmelidir.
Not: Satır içi kripto motoru (veya satır içi şifreleme donanımı), verileri şifreleyen/şifrelerini çözen depolama cihazına iletildi. Genellikle bu bir UFS veya eMMC ana makinesidir tarafından tanımlanan şifreleme uzantılarını uygulayan denetleyici JEDEC spesifikasyonu.
Tasarım
Bu bölümde, donanımla sarmalanmış anahtarlar özelliğinin tasarımı (örneğin, ve hangi donanım desteğinin gerektiğini belirtiyor. Bu tartışma dosya tabanlı şifrelemeye (FBE) odaklansa da Google Analytics 4'te, meta veriler şifrelemeyi de unutmayın.
Sistem belleğinde ham şifreleme anahtarlarına ihtiyaç duyulmasını önlemenin bir yolu, bunları yalnızca satır içi şifreleme motorunun anahtar yuvalarında tutmaktır. Ancak bu yaklaşımın bazı sorunları vardır:
- Şifreleme anahtarlarının sayısı, anahtar yuvalarının sayısını aşabilir.
- Satır içi şifreleme motorları yalnızca diskteki veri bloklarının tamamını şifrelemek/şifrelerini çözmek için kullanılabilir. Ancak FBE durumunda, yazılımın dosya adı şifreleme ve anahtar tanımlayıcısı türetme gibi diğer kriptografik işlemleri yapabilmesi gerekir. Yazılımın bu diğer işlemleri yapabilmesi için ham FBE anahtarlarına erişmesi gerekir.
Bu sorunları önlemek için depolama alanı anahtarları, yalnızca özel donanım tarafından açılıp kullanılabilen donanımla sarmalanmış anahtarlar haline getirilir. Bu sayede sınırsız sayıda anahtar desteklenir. İçinde ek olarak, anahtar hiyerarşisi değiştirilmiş ve kısmen bu donanıma taşınmıştır. Bu alt anahtarın, satır içi kripto motoru.
Anahtar hiyerarşisi
Anahtarlar, HKDF gibi bir KDF (anahtar türetme işlevi) kullanılarak diğer anahtarlardan türetilebilir. Bu işlem sonucunda anahtar hiyerarşisi oluşturulur.
Aşağıdaki şemada, FBE için tipik bir anahtar hiyerarşisi gösterilmektedir. donanımla sarmalanmış anahtarlar kullanılmaz:
FBE sınıf anahtarı, Android'in Linux'a ilettiği ham şifreleme anahtarıdır. örneğin, kimlik bilgisi ile şifrelenmiş depolama alanı. (Çekirdekteki bu anahtarına, fscrypt ana anahtarı denir.) Bu anahtardan çekirdek, şu alt anahtarlar:
- Anahtar tanımlayıcı. Bu değer, şifreleme için değil, belirli bir dosya veya dizinin korunduğu anahtarı tanımlamak için kullanılır.
- Dosya içeriği şifreleme anahtarı
- Dosya adı şifreleme anahtarı
Buna karşılık aşağıdaki şemada FBE'nin anahtar hiyerarşisi gösterilmektedir. donanımla sarmalanmış anahtarlar kullanılır:
Önceki duruma kıyasla anahtar hiyerarşisine ek bir düzey eklendi ve dosya içeriği şifreleme anahtarı taşındı. Kök düğüm, şifrelenmiş bir dizi dizinin kilidini açmak için Android'in Linux'a ilettiği anahtarı temsil etmeye devam eder. Ancak bu anahtar artık geçici olarak sarmalanmış biçimdedir ve kullanılabilmesi için özel donanıma aktarılması gerekir. Bu donanım, kısa ömürlü olarak sarmalanmış anahtar alan iki arayüz uygulayın:
inline_encryption_key
ve doğrudan elde etmek için tek bir arayüz bunu satır içi şifreleme motorunun bir anahtar üzerinde programlaması. Bu sayede, yazılımın ham anahtara erişmesi gerekmeden dosya içeriklerinin şifrelenmesine/şifresinin çözülmesine olanak tanınabilir. Android ortak çekirdeklerinde bu arayüz, depolama sürücüsü tarafından uygulanması gerekenblk_crypto_ll_ops::keyslot_program
işlemine karşılık gelir.sw_secret
değerini türetmek ve döndürmek için tek bir arayüz ("yazılım sır" "işlenmemiş sır" olarak da bilinir. yer alır). Bu, bir anketin Linux, dosya içerikleri dışındaki her şey için alt anahtar türetmek için kullanılır bahsedeceğim. Android'in ortak çekirdeklerinde bu arayüzblk_crypto_ll_ops::derive_sw_secret
işlemi, şu olmalıdır: depolama sürücüsü tarafından uygulanır.
Şundan inline_encryption_key
ve sw_secret
türetmek için:
şifreleme anahtarı ise donanımın kriptografik olarak güçlü bir KDF kullanması gerekir. Bu KDF, kriptografiyle ilgili en iyi uygulamaları izlemelidir. En az 256 bit güvenlik gücüne sahip olmalıdır. Yani daha sonra kullanılacak herhangi bir algoritma için yeterli olmalıdır. Ayrıca, elde edilen alt anahtarların kriptografik olarak izole edilmesini (yani, bunlardan birinin bilinmesi diğerinin bilinmesini sağlamamasını) garanti etmek için her alt anahtar türünü türetirken farklı bir etiket, bağlam ve uygulamaya özgü bilgi dizesi kullanmalıdır. Ham depolama anahtarı zaten bir
olması gerekir.
Teknik olarak, güvenlik şartlarını karşılayan herhangi bir KDF kullanılabilir.
Ancak test amacıyla aynı KDF'nin
test kodu. Şu anda bir KDF incelendi ve uygulandı. Bu KDF'yi vts_kernel_encryption_test
için kaynak kodunda bulabilirsiniz.
Donanımın, PRF olarak AES-256-CMAC ile NIST SP 800-108 "Karşı Modda KDF" kullanan bu KDF'yi kullanması önerilir. Uyumlu olmak amacıyla,
KDF bağlamlarının seçimi de dahil olmak üzere algoritmanın bölümleri özdeş olmalıdır.
ve etiketleri kullanabilirsiniz.
Anahtar sarmalama
Donanımla sarmalanmış anahtarların güvenlik hedeflerini karşılamak için iki tür anahtar sarmalama tanımlanmıştır:
- Geçici sarmalama: Donanım, her önyüklemede rastgele oluşturulan ve donanımın dışında doğrudan gösterilmeyen bir anahtar kullanarak ham anahtarı şifreler.
- Uzun süreli sarmalama: Donanım, ham anahtarı donanıma yerleştirilmiş ve doğrudan donanımın dışında gösterilmeyen benzersiz, kalıcı bir anahtar kullanarak şifreler.
Depolama alanının kilidini açmak için Linux çekirdeğine iletilen tüm anahtarlar kısa süreli olarak sarmalanmış. Bu sayede, saldırgan bir dosyanın içeriğini sistem belleğinde bulunan kullanımdaki bir anahtarla cihaz dışında, yeniden başlatma sonrasında da cihazda.
Aynı zamanda, Android'in şifrelenmiş sürümleri de depolayabilmesi gerekir. öncelikle kilitlerini açmaları için diskteki tuşlara basın. Ham anahtarlar bu amaçla kullanılabilir. Ancak, ham anahtarların sistem belleğinde hiç bulunmaması arzu edilir. Böylece, önyükleme sırasında ayıklanmış olsalar bile cihaz dışında kullanılmak üzere hiçbir zaman ayıklanamazlar. Bu nedenle, uzun süreli sarmalama kavramı tanımlanmıştır.
Anahtarları bu iki farklı şekilde sarmalamak için donanımın aşağıdaki arayüzleri uygulaması gerekir:
- Depolama alanı anahtarları oluşturmak ve içe aktarmak için uzun süreli sarmalanmış biçimde döndüren arayüzler. Bu arayüzlere, uygulamadaki
KeyMint'tır ve
TAG_STORAGE_KEY
KeyMint etiketine karşılık gelir. "Oluşturma" özelliği, Android'in kullanacağı yeni depolama alanı anahtarları oluşturmak içinvold
tarafından kullanılır. "İçe aktarma" özelliği isevts_kernel_encryption_test
tarafından test anahtarlarını içe aktarmak için kullanılır. - Uzun süreli sarmalanmış bir depolama anahtarını geçici olarak sarmalanmış bir depolama anahtarına dönüştüren bir arayüz. Bu,
convertStorageKeyToEphemeral
KeyMint yöntemi. Bu yöntem, depolama alanının kilidini açmak için hemvold
hem devts_kernel_encryption_test
tarafından kullanılır.
Anahtar sarmalama algoritması bir uygulama ayrıntısı olsa da güçlü AEAD (örneğin, rastgele IV'lerle AES-256-GCM).
Yazılım değişiklikleri gerekiyor
AOSP, donanımla sarmalanmış anahtarları desteklemek için halihazırda temel bir çerçeveye sahiptir. Bu
vold
gibi kullanıcı alanı bileşenlerinde de destek içerir.
Linux çekirdeğinin blk-crypto, fscrypto ve
dm-default-key olarak ayarlayın.
Ancak uygulamaya özel bazı değişiklikler yapılması gerekiyor.
KeyMint değişiklikleri
Cihazın KeyMint uygulaması, TAG_STORAGE_KEY
yöntemini desteklemek ve uygulamak için değiştirilmelidir.
Keymaster'da convertStorageKeyToEphemeral
yerine exportKey
kullanılıyordu.
Linux çekirdek değişiklikleri
Cihazın satır içi şifreleme motoru için Linux çekirdek sürücüsü, donanımla sarmalanmış anahtarları desteklemek üzere değiştirilmelidir.
android14
ve sonraki sürüm çekirdekler için BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
'ü blk_crypto_profile::key_types_supported
'de ayarlayın, blk_crypto_ll_ops::keyslot_program
ve blk_crypto_ll_ops::keyslot_evict
'i oluşturun, donanımla sarmalanmış anahtarların programlanmasını/kaldırılmasını destekleyin ve blk_crypto_ll_ops::derive_sw_secret
'i uygulayın.
android12
ve android13
çekirdekleri için blk_keyslot_manager::features
'te BLK_CRYPTO_FEATURE_WRAPPED_KEYS
'yi ayarlayın, blk_ksm_ll_ops::keyslot_program
ve blk_ksm_ll_ops::keyslot_evict
'i oluşturun, donanımla sarmalanmış anahtarların programlanmasını/çıkarılmasını destekleyin ve blk_ksm_ll_ops::derive_raw_secret
'yi uygulayın.
android11
çekirdek için
BLK_CRYPTO_FEATURE_WRAPPED_KEYS
ayarla
keyslot_manager::features
içinde,
keyslot_mgmt_ll_ops::keyslot_program
yapın
ve keyslot_mgmt_ll_ops::keyslot_evict
donanımla sarmalanmış anahtarları programlamayı/çıkarmayı destekler,
ve keyslot_mgmt_ll_ops::derive_raw_secret
uygulayın.
Test
Donanımla sarmalanmış anahtarlarla şifrelemeyi test etmek standart anahtarlarla şifrelemeyi test etmekten daha zor olsa da bir test anahtarı içe aktarıp donanımın yaptığı anahtar türetme işlemini yeniden uygulayarak test etmek mümkündür. Uygulandı
vts_kernel_encryption_test
içinde. Bu testi çalıştırmak için
çalıştır:
atest -v vts_kernel_encryption_test
Test günlüğünü okuyun ve donanım destekli anahtar test durumlarının (ör. FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy
ve DmDefaultKeyTest.TestHwWrappedKey
) donanım destekli anahtar desteğinin algılanmaması nedeniyle atlanmadığından emin olun. Bu durumda test sonuçları yine de "geçti" olarak görünür.
Anahtarları etkinleştirme
Cihazın donanımla sarmalanmış anahtar desteği düzgün şekilde çalışmaya başladıktan sonra, Android'in FBE ve meta veri şifrelemesi için kullanması amacıyla cihazın fstab
dosyasında aşağıdaki değişiklikleri yapabilirsiniz:
- FBE:
wrappedkey_v0
işaretinifileencryption
parametresinden yararlanın. Örneğin,fileencryption=::inlinecrypt_optimized+wrappedkey_v0
Örneğin, Daha fazla bilgi için FBE'ye göz atın dokümanlarına göz atın. - Meta veri şifreleme:
wrappedkey_v0
işaretinimetadata_encryption
parametresinden yararlanın. Örneğin, şunu kullanın:metadata_encryption=:wrappedkey_v0
Daha fazla bilgi için meta veri şifreleme dokümanlarını inceleyin.