Donanımla Sarılmış Anahtarlar

Çoğu disk ve dosya şifreleme yazılımı gibi, Android'in depolama şifrelemesi geleneksel olarak, şifrelemenin gerçekleştirilebilmesi için sistem belleğinde bulunan ham şifreleme anahtarlarına dayanır. Şifreleme, yazılım yerine özel donanım tarafından gerçekleştirildiğinde 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 cihazdan tamamen ödün vermeden 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 sundu. Donanımla sarılmış anahtarlar, adanmış donanım tarafından yalnızca ham biçimde bilinen depolama anahtarlarıdır; yazılım, bu anahtarları yalnızca sarmalanmış (şifrelenmiş) biçimde görür ve bunlarla çalışır. Bu donanım, depolama anahtarları oluşturma ve içe aktarma, depolama anahtarlarını geçici ve uzun vadeli biçimlerde sarma, alt anahtarları türetme, bir alt anahtarı doğrudan bir satır içi kripto motoruna programlama ve ayrı bir alt anahtarı yazılıma geri döndürme becerisine sahip olmalıdır.

Not : Bir satır içi şifreleme motoru (veya satır içi şifreleme donanımı ), depolama cihazına giderken / cihazdan giderken verileri şifreleyen / şifresini çözen donanımı ifade eder. Genellikle bu, ilgili JEDEC belirtimiyle tanımlanan şifreleme uzantılarını uygulayan bir UFS veya eMMC ana bilgisayar denetleyicisidir.

Tasarım (değiştir | kaynağı değiştir)

Bu bölüm, donanımla sarılmış anahtarlar özelliğinin tasarımını ve bunun için hangi donanım desteğinin gerekli olduğunu gösterir. Bu tartışma dosya tabanlı şifrelemeye (FBE) odaklanır, ancak çözüm meta veri şifrelemesi için de geçerlidir.

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

  • Şifreleme anahtarlarının sayısı, anahtar yuvalarının 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 durumunda, yazılımın dosya adı ş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 gerekecektir.

Bu sorunlardan kaçınmak için, depolama anahtarları bunun yerine donanımla sarılmış anahtarlara dönüştürülür , bu anahtarlar yalnızca özel donanım tarafından açılabilir ve 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 da bir alt anahtarın bir satır içi kripto motoru kullanamayan görevler için yazılıma döndürülmesine izin verir.

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 ile sonuçlanır.

Donanım sarılmış anahtarlar kullanılmamaktadır aşağıdaki diyagram FBE için tipik bir anahtar hiyerarşi göstermektedir:

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

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

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

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

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

Önceki durumla karşılaştırıldığında, anahtar hiyerarşisine ek bir seviye eklenmiş ve dosya içeriği şifreleme anahtarı yeniden konumlandırılmıştır. Kök düğüm hala Android'in bir dizi şifreli dizinin kilidini açmak için Linux'a aktardığı anahtarı temsil ediyor. Ancak, artık bu anahtar geçici olarak sarılmış formdadır 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:

  • Bir türetmek için arayüz inline_encryption_key ve doğrudan sıralı kripto motorun bir keyslot içine programlamak. Bu, yazılımın ham anahtara erişimi olmadan dosya içeriklerinin şifrelenmesine / şifresinin çözülmesine izin verir. Android ortak çekirdeklerinde bu arabirim, depolama sürücüsü tarafından uygulanması gereken blk_ksm_ll_ops::keyslot_program işlemine karşılık gelir.
  • Linux'un dosya içeriği şifreleme dışındaki her şey için alt anahtarları türetmek için kullandığı anahtar olan sw_secret türetmek ve döndürmek için bir sw_secret ("yazılım sırrı" - bazı yerlerde "ham sır" olarak da adlandırılır). Android ortak çekirdeklerinde bu arayüz, depolama sürücüsü tarafından uygulanması gereken blk_ksm_ll_ops::derive_raw_secret işlemine karşılık gelir.

Türetmek için inline_encryption_key ve sw_secret ham depolama anahtarından, donanım şifreleme açısından güçlü KDF kullanmalıdır. Bu KDF, en iyi kriptografi uygulamalarını takip etmelidir; en az 256 bitlik, yani daha sonra kullanılacak herhangi bir algoritma için yeterli bir güvenlik gücüne sahip olmalıdır. Ayrıca, sonuçta ortaya çıkan alt anahtarların kriptografik olarak izole edildiğini, yani bunlardan birinin bilgisi diğerini açığa çıkarmadığından emin olmak için her bir alt anahtar türünü türetirken ayrı bir etiket, bağlam ve / veya uygulamaya özgü bilgi dizesi kullanmalıdır. Ham depolama anahtarı zaten tek tip rasgele bir anahtar olduğundan anahtar genişletme gerekli değildir.

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

Anahtar sarma

Donanımla sarılmış anahtarların güvenlik hedeflerini karşılamak için iki tür anahtar sarmalama tanımlanmıştır:

  • Geçici sarma : Donanım, her önyüklemede rastgele oluşturulan ve donanımın dışında doğrudan açığa çıkmayan bir anahtar kullanarak ham anahtarı şifreler.
  • Uzun vadeli sarma : Donanım, donanımda yerleşik olarak bulunan ve donanımın dışında doğrudan açığa çıkmayan benzersiz, kalıcı bir anahtar kullanarak ham anahtarı şifreler.

Depolamanın kilidini açmak için Linux çekirdeğine aktarılan tüm anahtarlar geçici olarak paketlenir. Bu, bir saldırganın sistem belleğinden kullanımda olan bir anahtarı çıkarması durumunda, bu anahtarın yalnızca cihaz dışında değil, yeniden başlatmanın ardından cihazda da kullanılamaz olmasını sağlar.

Aynı zamanda, Android'in yine de anahtarların şifrelenmiş bir sürümünü diskte saklayabilmesi gerekiyor, böylece ilk etapta kilidi açılabiliyor. Ham anahtarlar bu amaç için çalışacaktır. Bununla birlikte, önyükleme sırasında çıkarılsalar bile aygıt dışında kullanılmak üzere çıkarılmamaları için ham anahtarların hiçbir zaman sistem belleğinde bulunmaması arzu edilir. Bu nedenle uzun vadeli sarma kavramı tanımlanmıştır.

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

  • Depolama anahtarlarını oluşturmak ve içe aktarmak için arabirimler, bunları uzun vadeli sarmalanmış biçimde döndürür. Bu arayüzlere dolaylı olarak KeyMint aracılığıyla erişilir ve TAG_STORAGE_KEY KeyMint etiketine karşılık gelirler. " vold " yeteneği, Android tarafından kullanılmak üzere yeni depolama anahtarları oluşturmak için vold tarafından kullanılırken, "içe aktarma" yeteneği, test anahtarlarını içe aktarmak için vts_kernel_encryption_test tarafından kullanılır.
  • Uzun vadeli 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, her iki tarafından kullanılan vold ve vts_kernel_encryption_test depolama açmak üzere.

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

Yazılım değişiklikleri gerekli

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

Bununla birlikte, uygulamaya özgü bazı değişiklikler gereklidir.

KeyMint değişiklikleri

Cihazın KeyMint uygulama desteği şekilde değiştirilmesi gerekir TAG_STORAGE_KEY ve uygulamak convertStorageKeyToEphemeral yöntemi.

exportKey , exportKey yerine convertStorageKeyToEphemeral kullanıldı.

Linux çekirdek değişiklikleri

Aygıtın satır içi şifreleme motoru için Linux çekirdek sürücüsü, BLK_CRYPTO_FEATURE_WRAPPED_KEYS ayarlamak, keyslot_program() ve keyslot_evict() işlemlerinin donanımla sarılmış anahtarların programlanmasını / çıkarılmasını desteklemek ve keyslot_evict() işlemini uygulamak için derive_raw_secret() .

Test yapmak

Donanımla sarılmış anahtarlarla şifrelemeyi test etmek, standart anahtarlarla şifrelemeden daha zor olsa da, bir test anahtarını içe aktararak ve donanımın yaptığı anahtar türetimini yeniden uygulayarak test etmek yine de mümkündür. Bu, vts_kernel_encryption_test . 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 sarılmış anahtar test durumlarının (ör. FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy ve DmDefaultKeyTest.TestHwWrappedKey ), donanımla sarmalanmış anahtarlar için destek nedeniyle DmDefaultKeyTest.TestHwWrappedKey , çünkü test sonuçları yine "geçer O vaka.

Etkinleştirme

Cihazın donanımla sarılmış anahtar desteği doğru şekilde çalıştıktan sonra, Android'in FBE ve meta veri şifrelemesi için kullanmasını sağlamak için 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 .