Donanım Sarılmış Anahtarlar

Çoğu disk ve dosya şifreleme yazılımı gibi, Android'in depolama şifrelemesi de geleneksel olarak, şifrelemenin gerçekleştirilebilmesi için sistem belleğinde bulunan ham şifreleme anahtarlarına dayanır. Şifreleme, yazılım yerine tahsis edilmiş donanım tarafından yapıldığında bile, yazılımın genellikle ham şifreleme anahtarlarını yönetmesi gerekir.

Bu, geleneksel olarak bir sorun olarak görülmez çünkü anahtarlar, depolama şifrelemesinin korumayı amaçladığı ana saldırı türü olan çevrimdışı bir saldırı sırasında mevcut olmayacaktır. Ancak, soğuk başlatma saldırıları ve bir saldırganın aygıtı tamamen tehlikeye atmadan sistem belleğini sızdırabileceği çevrimiçi saldırılar gibi diğer saldırı türlerine karşı artırılmış koruma sağlama isteği vardır.

Bu sorunu çözmek için Android 11, donanım desteğinin mevcut olduğu donanımla sarılmış anahtarlar için destek sunmuştur. Donanıma sarılmış anahtarlar, özel donanım tarafından yalnızca ham biçimde bilinen depolama anahtarlarıdır; yazılım bu anahtarları yalnızca sarılmış (şifrelenmiş) biçimde görür ve bunlarla çalışır. Bu donanım, depolama anahtarlarını oluşturabilme ve içe aktarabilme, depolama anahtarlarını kısa ömürlü ve uzun vadeli biçimlerde sarmalayabilme, alt anahtarları türetebilme, bir alt anahtarı doğrudan bir hat içi kripto motoruna programlayabilme ve ayrı bir alt anahtarı yazılıma döndürebilme yeteneğine sahip olmalıdır.

Not : Satır içi şifreleme motoru (veya satır içi şifreleme donanımı ), veriler depolama aygıtına giderken/cihazdan çıkarken şifreleyen/şifresini çözen donanımı ifade eder. Genellikle bu, karşılık gelen JEDEC spesifikasyonu tarafından tanımlanan kripto uzantılarını uygulayan bir UFS veya eMMC ana bilgisayar denetleyicisidir.

Tasarım

Bu bölüm, hangi donanım desteğinin gerekli olduğu da dahil olmak üzere, donanımla sarılmış anahtar özelliğinin tasarımını sunar. Bu tartışma, dosya tabanlı şifrelemeye (FBE) odaklanmaktadır, ancak çözüm, meta veri şifreleme için de geçerlidir.

Sistem belleğindeki ham şifreleme anahtarlarına ihtiyaç duymamanın bir yolu, onları yalnızca bir satır içi kripto motorunun anahtar yuvalarında tutmaktır. Ancak, bu yaklaşım bazı sorunlarla karşılaşır:

• Şifreleme anahtarı sayısı, anahtar yuvası sayısını aşabilir.
• Satır içi kripto motorları, yalnızca disk üzerindeki tüm veri bloklarını şifrelemek/şifresini çözmek için kullanılabilir. Bununla birlikte, FBE söz konusu olduğunda, yazılımın dosya adlarını şifreleme ve anahtar tanımlayıcıları türetme gibi diğer kriptografik işleri yapabilmesi gerekir. Bu diğer işi yapmak için yazılımın yine de ham FBE anahtarlarına erişmesi gerekir.

Bu sorunlardan kaçınmak için, depolama anahtarları bunun yerine donanıma sarılmış anahtarlar haline getirilir ve bunlar yalnızca özel donanım tarafından açılıp kullanılabilir. Bu, sınırsız sayıda anahtarın desteklenmesine izin verir. Ek olarak, anahtar hiyerarşisi değiştirilir ve kısmen bu donanıma taşınır; bu, bir satır içi kripto motoru kullanamayan görevler için yazılıma bir alt anahtarın döndürülmesine olanak tanır.

Not : Özel donanım kullanmak yerine aynı işlemci üzerinde çalışan bir TEE (Güvenilir Yürütme Ortamı) kullanan bir yazılımda "donanımla sarmalanmış anahtarlar" uygulamak teknik olarak mümkündür. Ancak, özelliği haklı çıkarmak için bunun yeterli güvenlik avantajı sağlayıp sağlayamayacağı net olmadığından, bunu yapmak şu anda önerilmemektedir. Özellikle bu, soğuk önyükleme saldırılarına karşı koruma sağlamayabilir.

Sabit yazılımın üzerinde çalıştığı donanımın ana işlemciden yeterince ayrı olması koşuluyla, sabit yazılımdaki bir uygulama kabul edilebilir.

Anahtar hiyerarşi

Anahtarlar, HKDF gibi bir KDF (anahtar türetme işlevi) kullanılarak diğer anahtarlardan türetilebilir ve bu da bir anahtar hiyerarşisi oluşturur.

Aşağıdaki diyagram, donanımla sarılmış anahtarlar kullanılmadığında FBE için tipik bir anahtar hiyerarşisini gösterir:

Şekil 1. FBE anahtar hiyerarşisi (standart)

FBE sınıf anahtarı, belirli bir Android kullanıcısı için kimlik bilgileriyle şifrelenmiş depolama gibi belirli bir şifrelenmiş dizin kümesinin kilidini açmak için Android'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üretir:

• Anahtar tanımlayıcı. Bu, şifreleme için kullanılmaz, bunun yerine belirli bir dosyanın veya dizinin korunduğu anahtarı tanımlamak için kullanılan bir değerdir.
• Dosya içeriği şifreleme anahtarı
• Dosya adları şifreleme anahtarı

Not : Yukarıdakiler, bir satır içi şifreleme motoruyla ( inlinecrypt_optimized veya emmc_optimized ) kullanım için optimize edilmiş şifreleme ayarlarından birinin kullanıldığını varsayar. Bu ayarlardan biri kullanılmazsa, FBE sınıf anahtarından (dosya veya dizin başına bir tane) türetilen birçok dosya içeriği ve dosya adı şifreleme anahtarı olacaktır.

Buna karşılık, aşağıdaki diyagram, donanımla sarmalanmış anahtarlar kullanıldığında FBE için anahtar hiyerarşisini gösterir:

Şekil 2. FBE anahtar hiyerarşisi (donanımla sarmalanmış anahtarla)

Önceki durumla karşılaştırıldığında, anahtar hiyerarşisine ek bir düzey eklendi ve dosya içeriği şifreleme anahtarının yeri değiştirildi. Kök düğüm, Android'in bir dizi şifrelenmiş dizinin kilidini açmak için Linux'a ilettiği anahtarı temsil eder. Ancak, artık bu anahtar geçici olarak sarılmış biçimdedir ve kullanılabilmesi için özel donanıma geçirilmesi gerekir. Bu donanım, geçici olarak sarılmış bir anahtar alan iki arabirim uygulamalıdır:

• inline_encryption_key türetmek ve doğrudan satır içi kripto motorunun bir anahtar yuvasına programlamak için bir arayüz. Bu, yazılımın ham anahtara erişimi olmadan dosya içeriğinin şifrelenmesine/şifresinin çözülmesine olanak tanır. Android ortak çekirdeklerinde bu arabirim, depolama sürücüsü tarafından uygulanması gereken blk_crypto_ll_ops::keyslot_program işlemine karşılık gelir.
• sw_secret ("yazılım sırrı" -- bazı yerlerde "ham sır" olarak da adlandırılır) türetmek ve döndürmek için bir arayüz; bu, Linux'un dosya içeriği şifreleme dışındaki her şey için alt anahtarları türetmek için kullandığı anahtardır. Android ortak çekirdeklerinde bu arabirim, depolama sürücüsü tarafından uygulanması gereken blk_crypto_ll_ops::derive_sw_secret işlemine karşılık gelir.

Ham depolama anahtarından inline_encryption_key ve sw_secret türetmek için donanımın kriptografik olarak güçlü bir KDF kullanması gerekir. Bu KDF, kriptografinin en iyi uygulamalarını takip etmelidir; en az 256 bitlik, yani daha sonra kullanılacak herhangi bir algoritma için yeterli güvenlik gücüne sahip olmalıdır. Ayrıca, elde edilen alt anahtarların kriptografik olarak izole edildiğini garanti etmek için her bir alt anahtar türünü türetirken ayrı bir etiket, bağlam ve/veya uygulamaya özel bilgi dizisi kullanmalıdır, yani bunlardan birinin bilgisi diğerini ortaya çıkarmaz. Ham depolama anahtarı zaten tek biçimli rastgele bir anahtar olduğundan, anahtar genişletme gerekli değildir.

Teknik olarak, güvenlik gereksinimlerini karşılayan herhangi bir KDF kullanılabilir. Ancak, test amacıyla, aynı KDF'yi test kodunda yeniden uygulamak gerekir. Şu anda bir KDF gözden geçirilmiş ve uygulanmıştır; vts_kernel_encryption_test için kaynak kodunda bulunabilir . Donanımın, PRF olarak AES-256-CMAC ile NIST SP 800-108 "KDF in Sayaç Modunda" kullanan bu KDF'yi kullanması önerilir. Uyumlu olması için, her bir alt anahtar için KDF içerikleri ve etiketleri seçimi dahil olmak üzere, algoritmanın tüm bölümlerinin aynı olması gerektiğini unutmayın.

Anahtar sarma

Donanım sarmalı anahtarların güvenlik hedeflerini karşılamak için iki tür anahtar sarma tanımlanmıştır:

• Kısa ömürlü sarma : donanım, ham anahtarı her önyüklemede rastgele oluşturulan ve doğrudan donanımın dışında açığa çıkmayan bir anahtar kullanarak şifreler.
• Uzun süreli sarma : donanım, donanımın dışında doğrudan açığa çıkmayan, donanıma yerleşik benzersiz, kalıcı bir anahtar kullanarak ham anahtarı şifreler.

Depolamanın kilidini açmak için Linux çekirdeğine iletilen tüm anahtarlar geçici olarak sarılır. Bu, bir saldırgan sistem belleğinden kullanımdaki bir anahtarı çıkarabilirse, bu anahtarın yalnızca aygıt dışında değil, yeniden başlatmanın ardından aygıtta da kullanılamaz olmasını sağlar.

Aynı zamanda, Android'in yine de anahtarların şifrelenmiş bir sürümünü diskte depolayabilmesi gerekir, böylece ilk etapta kilitleri açılabilir. Ham anahtarlar bu amaç için çalışırdı. Bununla birlikte, ham anahtarların sistem belleğinde hiçbir zaman bulunmaması arzu edilir, böylece önyükleme sırasında çıkarılsalar bile cihaz dışında kullanılmak üzere asla çıkarılamazlar. Bu nedenle uzun süreli sarma kavramı tanımlanmaktadır.

Not : Android'in diskte depoladığı tüm depolama şifreleme anahtarları, anahtarın kilidini açma yeteneğini cihazın Doğrulanmış Önyükleme durumuna ve ayrıca kullanıcının Kilit Ekranı Bilgi Faktörüne (örn. PIN) bağlayan ayrı bir anahtar sarma katmanıyla korunur. uygulanabilir olduğunda. Bu anahtar sarma katmanı, yukarıda tartışılan uzun vadeli anahtar sarmadan bağımsızdır. Bu nedenle, donanıma sarılmış anahtarlar kullanımdayken, Android'in diskte depoladığı anahtarlar iki kez sarılır: bir kez donanımın uzun vadeli anahtar sarmalaması ve yine Android'in standart anahtar sarmalaması.

Anahtarların bu iki farklı şekilde yönetilmesini desteklemek için donanımın aşağıdaki arabirimleri uygulaması gerekir:

• Depolama anahtarlarını oluşturmak ve içe aktarmak için arayüzler, bunları uzun vadeli sarılmış formda döndürür. Bu arayüzlere dolaylı olarak KeyMint aracılığıyla erişilir ve TAG_STORAGE_KEY KeyMint etiketine karşılık gelir. "Oluştur" yeteneği, vold tarafından Android tarafından kullanılmak üzere yeni depolama anahtarları oluşturmak için kullanılırken, "içe aktarma" yeteneği vts_kernel_encryption_test tarafından test anahtarlarını içe aktarmak için kullanılır.
• Uzun süreli sarılmış bir depolama anahtarını geçici olarak sarılmış bir depolama anahtarına dönüştürmek için bir arabirim. Bu, convertStorageKeyToEphemeral KeyMint yöntemine karşılık gelir. Bu yöntem, depolamanın kilidini açmak için hem vold hem de vts_kernel_encryption_test tarafından kullanılır.

Anahtar kaydırma algoritması bir uygulama ayrıntısıdır, ancak rastgele IV'lere sahip AES-256-GCM gibi güçlü bir AEAD kullanmalıdır.

Yazılım değişiklikleri gerekli

AOSP, donanımla sarılmış anahtarları desteklemek için zaten temel bir çerçeveye sahiptir. Bu, vold gibi kullanıcı alanı bileşenlerindeki desteğin yanı sıra blk- crypto , fscrypt ve dm-default- key'deki Linux çekirdeği desteğini içerir.

Ancak, uygulamaya özel bazı değişiklikler gereklidir.

KeyMint değişiklikleri

Cihazın KeyMint uygulaması, TAG_STORAGE_KEY desteklemek ve convertStorageKeyToEphemeral yöntemini uygulamak için değiştirilmelidir.

Keymaster'da, exportKey yerine convertStorageKeyToEphemeral kullanıldı.

Linux çekirdek değişiklikleri

Aygıtın satır içi kripto motoru için Linux çekirdeği sürücüsü, donanımla sarılmış anahtarları desteklemek için değiştirilmelidir.

android14 ve daha yüksek çekirdekler için, blk_crypto_profile::key_types_supported BLK_CRYPTO_KEY_TYPE_HW_WRAPPED blk_crypto_ll_ops::keyslot_program ve blk_crypto_ll_ops::keyslot_evict donanımla sarılmış anahtarların programlanmasını/tahliye edilmesini destekleyin ve blk_crypto_ll_ops blk_crypto_ll_ops::derive_sw_secret .

android12 ve android13 çekirdekleri için, blk_keyslot_manager::features içinde BLK_CRYPTO_FEATURE_WRAPPED_KEYS öğesini ayarlayın, blk_ksm_ll_ops::keyslot_program ve blk_ksm_ll_ops::keyslot_evict donanımla sarılmış anahtarların programlanmasını/tahliye edilmesini destekleyin ve blk_ksm_ll_ops:: blk_ksm_ll_ops::derive_raw_secret .

android11 ​​çekirdekleri için, keyslot_manager::features içinde BLK_CRYPTO_FEATURE_WRAPPED_KEYS öğesini ayarlayın, keyslot_mgmt_ll_ops::keyslot_program ve keyslot_mgmt_ll_ops::keyslot_evict donanım sarılı anahtarların programlanmasını/çıkartılmasını destekler ve keyslot_mgmt_ll_ops:: keyslot_mgmt_ll_ops::derive_raw_secret .

Test yapmak

Donanıma sarılmış anahtarlarla şifrelemeyi test etmek, standart anahtarlarla şifrelemeye göre daha zor olsa da, bir test anahtarı içe aktararak ve donanımın yaptığı anahtar türetmeyi yeniden uygulayarak test etmek yine de mümkündür. Bu, vts_kernel_encryption_test içinde uygulanmaktadır. Bu testi çalıştırmak için şunu çalıştırın:

atest -v vts_kernel_encryption_test

Test günlüğünü okuyun ve donanımla sarmalanmış anahtar test senaryolarının (örn FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy ve DmDefaultKeyTest.TestHwWrappedKey ), donanımla sarmalanmış anahtar desteği algılanmadığı için atlanmadığını doğrulayın, çünkü test sonuçları yine de "geçildi" O vaka.

Not : Bu test durumlarının geçmesi için, donanım tarafından gerçekleştirilen anahtar türetmenin testin beklediğiyle tam olarak eşleşmesi gerekir. Ayrıca, satır içi kripto motorunun AES-256-XTS kullanımı doğru olmalıdır; yani, diskteki her şifrelenmiş veri bloğu, hem anahtar hem de IV için doğru endianness ve bir bloktan diğerine doğru IV artış miktarının kullanılması da dahil olmak üzere, beklenen anahtar ve IV (başlatma vektörü) kullanılarak şifrelenmelidir.

Donanım farklı bir KDF kullanıyorsa (önerilmez), testi o KDF'yi destekleyecek şekilde değiştirmek gerekecektir.

etkinleştirme

Cihazın donanımla sarmalanmış anahtar desteği doğru şekilde çalıştığında, Android'in onu FBE ve meta veri şifreleme için kullanmasını sağlamak üzere cihazın fstab dosyasında aşağıdaki değişiklikleri yapabilirsiniz:

• FBE: wrappedkey_v0 bayrağını fileencryption parametresine ekleyin. Örneğin, fileencryption=::inlinecrypt_optimized+wrappedkey_v0 . Daha fazla ayrıntı için FBE belgelerine bakın.
• Meta veri şifreleme: wrappedkey_v0 bayrağını metadata_encryption parametresine ekleyin. Örneğin, metadata_encryption=:wrappedkey_v0 kullanın. Daha fazla ayrıntı için meta veri şifreleme belgelerine bakın.

Not : Donanımla sarmalanmış anahtarlar yalnızca dahili depolamada kullanılabilir, kabul edilebilir depolamada kullanılamaz.