Donanımla sarmalanmış anahtarlar

Ç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ı gereken blk_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üz blk_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çin vold tarafından kullanılır. "İçe aktarma" özelliği ise vts_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 hem vold hem de vts_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şaretini fileencryption 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şaretini metadata_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.