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ımla sarmalanmış anahtarlar içindir. Donanımla sarmalanmış anahtarlar, yalnızca özel donanım tarafından ham biçimde bilinen depolama anahtarlardır. Yazılımlar bu anahtarları yalnızca sarmalanmış (şifrelenmiş) biçimde görür ve bu biçimde işler. Bu donanım, oluşturma ve içe aktarma kapasitesine sahip olmalıdır depolama anahtarları, depolama anahtarlarını geçici ve uzun süreli formlarda sarmalama, türetme bir alt anahtarı doğrudan satır içi kripto motoruna programlayarak ve ayrı bir alt anahtar döndürerek başlayın.

Not: Satır içi şifreleme motoru (veya satır içi şifreleme donanımı), verileri depolama cihazına giderken/gelirken şifreleyen/şifrelerini çözen donanımı ifade eder. 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ı ve bu özellik için gereken donanım desteği açıklanmaktadır. Bu tartışmada dosya tabanlı şifreleme (FBE) ele alınsa da çözüm meta veri şifrelemesi için de geçerlidir.

Sistem belleğinde ham şifreleme anahtarlarına ihtiyaç duymamak için bunları yalnızca satır içi şifreleme motorunun anahtar yuvalarında tutmak da bir yöntemdir. 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 söz konusu olduğunda, yazılımın yine de şunları yapabilmesi gerekir: dosya adı şifreleme ve anahtar türetme gibi başka kriptografik işler tanımlayıcılar. 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 anahtarları donanım sarmalanmış anahtarlar bir donanımla sınırlıdır. Bu şekilde sınırsız sayıda anahtar desteklenir. Ayrıca, anahtar hiyerarşisi değiştirilir ve kısmen bu donanıma taşınır. Bu sayede, satır içi şifreleme motoru kullanılamayan görevler için bir alt anahtarın yazılıma döndürülmesi sağlanır.

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, donanımla sarmalanmış anahtarlar kullanılmadığında FBE için tipik bir anahtar hiyerarşisi gösterilmektedir:

FBE sınıf anahtarı, Android'in belirli bir Android kullanıcısının kimlik bilgisiyle şifrelenmiş depolama alanı gibi belirli bir şifrelenmiş dizin grubunun kilidini açmak için Linux çekirdeğine ilettiği ham şifreleme anahtarıdır. (Çekirdekte bu anahtara fscrypt ana anahtarı denir.) Çekirdek bu anahtardan aşağıdaki alt anahtarları türetmektedir:

• Anahtar tanımlayıcısı. Bu, şifreleme için kullanılmaz ancak bir değerdir belli bir dosyanın veya dizinin bulunduğu anahtarı tanımlamak için kullanılır. korunuyor.
• 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, bir dizi anahtarın kilidini açmak için Android'in Linux'a geçtiği anahtarı temsil eder. şifrelenmiş dizinler. Ancak şimdi bu anahtar kısa süreli olarak sarmalanmış biçimdedir kullanılması için özel donanıma iletilmesi gerekir. Bu donanım, geçici olarak sarmalanmış bir anahtar alan iki arayüz uygulamalıdır:

• inline_encryption_key değerini türetmek ve doğrudan satır içi kripto motorunun bir anahtar yuvasına programlamak için tek bir arayüz. Bu, ham verilere erişimi olmayan yazılım olmadan şifrelenecek/şifresi çözülecek içerikler tuşuna basın. 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.
• Linux'un dosya içeriği şifrelemeden başka her şey için alt anahtarları türetmek amacıyla kullandığı sw_secret ("yazılım gizlisi", bazı yerlerde "ham gizli" olarak da adlandırılır) anahtarını türetmek ve döndürmek için kullanılan bir arayüz. Android ortak çekirdeklerinde bu arayüz, depolama sürücüsü tarafından uygulanması gereken blk_crypto_ll_ops::derive_sw_secret işlemine karşılık gelir.

Donanımın, ham depolama anahtarından inline_encryption_key ve sw_secret'yi türetmesi için kriptografik olarak güçlü bir KDF kullanması gerekir. Bu KDF Kriptografiyle ilgili en iyi uygulamalara uygun olmalıdır; güvenlik gücü şu kadar olmalıdır: yani daha sonra kullanılacak algoritma için yeterlidir. Ayrıca, elde edilen alt anahtarların kriptografik olarak izole edilmesini (yani, bunlardan birinin bilinmesi diğerinin açığa çıkmasını) sağlamak 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 gereksinimlerini karşılayan tüm KDF'ler kullanılabilir. Ancak test amacıyla, test kodunda aynı KDF'nin yeniden uygulanması gerekir. Şu anda bir KDF incelendi ve uygulandı. Bu KDF'yi vts_kernel_encryption_test için kaynak kodunda bulabilirsiniz. Donanımın, PRF olarak NIST SP 800-108 "KDF'yi Sayaç Modunda" ve AES-256-CMAC kullanan bu KDF'yi kullanması önerilir. Uyumlu olması için her alt anahtar için KDF bağlamları ve etiketler de dahil olmak üzere algoritmanın tüm bölümlerinin aynı olması gerektiğini unutmayın.

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, ham anahtarı bir anahtar kullanarak şifreler her başlatma sırasında rastgele oluşturulur ve doğrudan kullanıma sunulmaz. dış mekana uyum sağlar.
• Uzun süreli sarmalama: Donanım, ham anahtarı bir yerleşik olarak bulunan benzersiz, kalıcı bir anahtar, tespit edebilirsiniz.

Depolama alanının kilidini açmak için Linux çekirdeğine iletilen tüm anahtarlar kısa süreli olarak sarmalanmış. Bu sayede, bir saldırgan sistem belleğinden kullanılan bir anahtarı çıkarsa bu anahtar yalnızca cihaz kapalıyken değil, yeniden başlatıldıktan sonra da kullanılamaz.

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ı istenmelidir. 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.

Bu iki farklı şekilde sarmalanmış anahtarların yönetilmesini desteklemek için donanım, aşağıdaki arayüzleri uygulayın:

• 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 vold tarafından yeni depolama alanı oluşturmak için kullanılır anahtarlarının dışında "içe aktarma" ile özelliği kullanan Test anahtarlarını içe aktarmak için vts_kernel_encryption_test tuşlarına basın.
• Uzun süreli sarmalanmış depolama anahtarını bir depolama anahtarı olabilir. Bu, convertStorageKeyToEphemeral KeyMint yöntemine karşılık gelir. 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ıdır ancak rastgele IV'ler içeren AES-256-GCM gibi güçlü bir AEAD kullanılmalıdır.

Yazılım değişiklikleri gerekiyor

AOSP, donanımla sarmalanmış anahtarları desteklemek için halihazırda temel bir çerçeveye sahiptir. Buna vold gibi kullanıcı alanı bileşenlerindeki destek ve blk-crypto, fscrypt ve dm-default-key'deki Linux çekirdeği desteği dahildir.

Ancak uygulamaya özgü bazı değişiklikler yapılması gerekir.

KeyMint değişiklikleri

Cihazın KeyMint uygulaması, TAG_STORAGE_KEY ve convertStorageKeyToEphemeral yöntemini çağırın.

Keymaster'da şunun yerine exportKey kullanıldı: convertStorageKeyToEphemeral.

Linux çekirdek değişiklikleri

Cihazın satır içi şifreleme motoru için Linux çekirdek sürücüsü değiştirilmelidir ve donanımla sarmalanmış anahtarları destekler.

android14 ve daha yüksek çekirdekler için BLK_CRYPTO_KEY_TYPE_HW_WRAPPED ayarla blk_crypto_profile::key_types_supported içinde, blk_crypto_ll_ops::keyslot_program yapın ve blk_crypto_ll_ops::keyslot_evict donanımla sarmalanmış anahtarları programlamayı/çıkarmayı destekler, ve blk_crypto_ll_ops::derive_sw_secret uygulayın.

android12 ve android13 çekirdekleri için BLK_CRYPTO_FEATURE_WRAPPED_KEYS ayarla blk_keyslot_manager::features içinde yap: blk_ksm_ll_ops::keyslot_program ve blk_ksm_ll_ops::keyslot_evict donanımla sarmalanmış anahtarları programlamayı/çıkarmayı destekler, ve blk_ksm_ll_ops::derive_raw_secret uygulayın.

android11 çekirdeklerinde, keyslot_manager::features içinde BLK_CRYPTO_FEATURE_WRAPPED_KEYS'ü ayarlayın, keyslot_mgmt_ll_ops::keyslot_program ve keyslot_mgmt_ll_ops::keyslot_evict'i oluşturun, donanımla sarmalanmış anahtarların programlanmasını/çıkarılmasını destekleyin ve keyslot_mgmt_ll_ops::derive_raw_secret'i 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:

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.

Tuşları etkinleştir

Cihazın donanımla sarmalanmış anahtar desteği düzgün çalışmaya başladıktan sonra şunları yapabilirsiniz: cihazın fstab dosyasında aşağıdaki değişiklikleri yapın: Android, bunu FBE ve meta veri şifreleme için kullanır:

• FBE: wrappedkey_v0 işaretini fileencryption parametresinden yararlanın. Örneğin, fileencryption=::inlinecrypt_optimized+wrappedkey_v0 değerini kullanın. Örneğin, Daha fazla bilgi için FBE'ye göz atın dokümanlarına göz atın.
• Meta veri şifrelemesi: metadata_encryption parametresine wrappedkey_v0 işaretini ekleyin. Örneğin, şunu kullanın: metadata_encryption=:wrappedkey_v0 Daha fazla bilgi için meta veri şifreleme dokümanlarını inceleyin.