Sertifikaları harici bellekte tutmak kötü bir uygulama mı?

AWS-IoT üzerinde bir STM32 mikrodenetleyici kullanarak çalışıyoruz.

Bugüne kadar sertifikaları flaşa yazıyorduk ve flaşı harici okumadan kilitliyorduk. Uygulama kodu arttıkça, flaşta daha az yer kaplıyoruz, bu nedenle sertifikayı harici olarak bir SD kart / EEPROM'a taşımayı ve AWS-IoT'ye bağlanmadan önce ne zaman ihtiyaç duyulduğunu okumayı planladık.

Notlar:

• Bu şey için yazılan ilke, yalnızca belirli adlara sahip aygıtların söz konusu sertifikaya bağlanmasına izin verir.

• Bu şeyin, gelen herhangi bir haydut paketini yok sayacak olan bir veri işlemcisine bağlı olan sadece 2 kanala (adı ve bir veri besleme kanalı) yayınlanmasına izin verilir.

• Bir şey başka bir konuyu yayınlıyor / abone oluyorsa, AWS hemen bağlantıyı kesecektir.

Bir cihazın çalındığını / hileli olduğunu tespit edersem anahtarı sunucudan devre dışı bırakırız.

Bir istismarcı sertifikalarla ne yapabilir (RootCA, sunucu anahtarı, istemci anahtarı)?

Bu tür bir kullanım için sertifikaların bir istismarcı tarafından erişilebilen harici bir depolama biriminde tutulması kötü bir uygulama mı?

“Sertifikalar” dan bahsediyorsunuz, ancak bağlamda, bence iki farklı şeyden bahsediyorsunuz.

• Cihazınızın, bu cihaza özgü ve cihazın dışında bilinmeyen özel bir anahtarı vardır . Bu anahtar cihazınızı tanımlar. Bu anahtara erişebilen herkes cihazı taklit edebilir. Bu, özellikle şunları yapabildikleri anlamına gelir:

  • Cihazınızın yasal olarak yayınlanmasına izin verildiği kanallarda geçerli, ancak yanlış veriler yayınlayın.
  • Meşru cihazın yasaklanmasını sağlayacak geçersiz veriler yayınlayın.
  • Muhtemelen, kullanım durumuna bağlı olarak, cihaz sahibinin bazı özel bilgilerini açığa çıkarın.

  Bu özel anahtarın gizli kalması daha iyi olur.

• Cihazınızda muhtemelen konuştuğu sunucuları tanımasına izin veren en az bir ortak anahtar bulunur. Bu anahtarı okuyabilen biri varsa sorun değil: herkese açık. Ancak bir saldırgan anahtarı değiştiremez. Aksi takdirde, aygıtla iletişim kurabilir ve sunucuyu taklit edebilirler. Bu, aşağıdaki gibi şeyler yapmalarına izin verebilir:

  • Cihaza bir ürün yazılımı güncellemesi gönderin.
  • Bir yapılandırma güncellemesini cihaza aktarın.
  • Cihazın verilerini farklı bir konuma yüklemesini sağlayın.

İyi haber şu ki, bu tehdit analizi aslında çok ilgili değil. Herhangi bir güvenlikten ödün vermenize gerek yok ! (En azından gizlilik ve özgünlük özellikleri değil - bir şeyi harici olarak depolarsanız kullanılabilirlik bir isabet alır, çünkü bu sistemin kaybolabilecek bir parçasıdır.)

En az bir kez yazabileceğiniz en az 128 bit depolama alanınız olduğu sürece, sahip olduğunuz ve daha fazlası, güvenli bir uzak depolama çözümü uygulayabilirsiniz. Gizli bir anahtarı saklamak için sınırlı alandaki cihazda depolamayı kullanın. Bu gizli anahtar aygıt başına benzersiz olmalıdır; STM32'nin donanım RNG'si vardır, böylece ilk önyükleme sırasında cihazda oluşturabilirsiniz. Cihazınızda bir donanım RNG'si yoksa, anahtarı cihaz dışında güvenli bir yerde oluşturabilir ve cihaza enjekte edebilirsiniz.

Bu anahtarla, cihazda sakladığınız şeyler için kimlik doğrulamalı şifreleme kullanın . Harici depolama biriminden bazı verileri okumak istediğinizde, yükleyin, şifresini çözün ve doğrulayın. Harici depoya bazı veriler yazmak istediğinizde, şifreleyin ve imzalayın. Bu, verilerin dahili depolama alanındaki veriler kadar gizli ve özgün olduğunu garanti eder.

Kimliği doğrulanmış şifreleme, verilerin gizliliğini ve gerçekliğini garanti etmek için yeterlidir , ancak bütünlüğünü tam olarak garanti etmez .

• Birden fazla veri yığını varsa, cihaz bir veri parçasını okuduğunda, bunun doğru yığın olduğundan emin olamaz. Çözüm: (örn biriyle her öbek her başlattığınızda yığın içeriğinde benzersiz bir tanımlayıcı içeriyor "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Verileri bir noktada güncellerseniz, tekrar okuduğunuzda, bu verilerin en son sürümünü aldığınızdan emin olamazsınız. Birisi harici depolama birimini değiştirebilirse, kimlik doğrulama denetiminde başarısız olacağı için sahte veri koyamaz, ancak eski verileri geri yükleyebilir, çünkü eskiden orijinal olanı hala orijinaldir. Çözüm: Harici olarak depolanan her veri yığınına, o parçanın her yeni sürümünü yazdığınızda arttıracağınız bir sayaç ekleyin. Bir öbeği okuduğunuzda, beklenen sürüm olduğunu doğrulayın.

Harici depolama biriminin hasar görmesi veya başka bir şekilde kaybolması durumunda bir cihazı kirletmekten kaçınmak için, dahili depolama alanında yeterli alana sahip olduğunuzda, cihazı “iyi” duruma sıfırlamak için gereken her şeye öncelik vermelisiniz, örneğin fabrika ayarlarına sıfırlama . İkinci öncelik performans değerlendirmeleri olacaktır.

Biraz bağlam

AWS IoT ile MQTT kullandığınızdan , kimlik doğrulama ve güvenlik için X.509 sertifikaları kullanmanız beklenir . Amazon , sertifikalarınızı nasıl güvence altına almanız gerektiği konusunda biraz rehberliğe sahiptir , bu yüzden burada şunları söyleyeceğim:

Sertifikalar, cihazlarla asimetrik anahtarların kullanılmasını sağlar. Bu, özel anahtarları, hassas kriptografik malzemenin cihazdan çıkmasına izin vermeden bir cihazda güvenli bir depolama alanına yakabileceğiniz anlamına gelir.

Şu anda STM32'nin Okuma Korumasını (RDP) kullandığınızdan, en kararlı saldırganlar hariç tümü mevcut programınızdaki sertifikalarınıza erişmekte sorun yaşayacaktır:

Global Read Out Koruması, yerleşik bellenim kodunun (Flash belleğe önceden yüklenmiş) tersine mühendislik, hata ayıklama araçları kullanarak boşaltma veya diğer müdahaleci saldırı yöntemlerine karşı koruma sağlar.

• Seviye 0 - Koruma yok (varsayılan)
• Seviye 1 - Flash bellek, RAM yüklü kod tarafından hata ayıklama veya kod dökümü ile okumaya karşı korunur
• Seviye 2 - Tüm hata ayıklama özellikleri devre dışı

Harici depolama güvenli olacak mı?

Muhtemelen o kadar güvenli değil . İstemcinizin özel anahtarı çalınırsa, bir saldırgan gerçekte olmadığında cihazınızdan gelmiş gibi görünen veriler gönderebilir. Hangi verileri gönderdiğiniz belli olmasa da, güvenilir olmayan veriler güvenlik riski oluşturabilir.

Özel tutmak için hangi bitlere ihtiyacım var?

AWS IoT'de bir cihaz sertifikası oluşturduğunuzda, aşağıdaki gibi bir resim görmelisiniz:

^{Image Bir Aygıtı oluşturun ve etkinleştirme Belgesi AWS Iot belgelerin sayfa.}

Özel anahtar, gerçekten ... özel tutmanız gereken şeydir ve mümkünse kesinlikle okunan bellekte saklanmalıdır. Ortak anahtar ve sertifika paylaşılmak üzere tasarlanmıştır, bu nedenle alanınız biterse bunları güvenle harici depolama alanına taşıyabilirsiniz. Sayfada biraz daha bağlam elde edebilirsiniz SSL / TLS nasıl çalışır? Wikipedia'da Bilgi Güvenliği Yığın Değişimi ve Açık Anahtarlı Şifreleme . Özel anahtarın neden gizli olması gerektiğini açıklamak için bu görüntüyü eklemeseydim sana bir kötülük yapacağımı düşünüyorum :

.

^{Wikipedia'dan kamu malı olarak yayınlanan resim .}

Cihazınızın genel anahtarı , AWS IoT'nin cihazınıza göndermek için mesajları imzalamak için kullandığı şeydir (ancak mesajı kimin gönderdiğini kanıtlamaz ). Yani, eğer birileri ortak anahtarı çalarsa, bu büyük bir felaket değildir, çünkü bu bir sır değildir.

Özel anahtar bir saldırganın bu çalarsa o biraz daha büyük bir problem böylece cihaz kullanımları mesajları deşifre şeydir.

Ayrıca, saldırganın RootCA sertifikasını çalması durumunda ne olacağını sordunuz. Birisi AWS IoT'nin özel anahtarını çaldıysa , felaket olur, ancak cihazınızdaki RootCA sertifikası bu değildir . RootCA.crtBu Amazon sensin vermek tamamen kamu ve amaç size (büyük olasılıkla bir man-in-the-middle AWS Iot sunucuları gibi davranarak) herhangi bir şekilde saldırıya uğraması olmadığını doğrulamak böylece olduğunu.

Saldırıya uğramış bir cihaz hangi hasarı yapabilir?

Çalınan cihazınız yalnızca politikada listelenen işlemleri yapabilir . En az ayrıcalık ilkesini izlemeye çalışın ; cihazınıza yalnızca kesinlikle ihtiyaç duyduğu ayrıcalıkları verin , bu yüzden en kötüsü gerçekleşirse, çok fazla tahribat yaratamaz. Özel durumunuz için:

Bir şeyin, kendisine gelen herhangi bir haydut paketini yok sayacak olan bir veri işlemcisine bağlı olan yalnızca 2 kanala (adı ve bir veri besleme kanalı) yayınlanmasına izin verilir.

Bu iyi. Herhangi bir saldırı, cihazın yayınlayabileceği yalnızca iki MQTT konusuna tecrit edilmelidir, bu nedenle büyük çaplı zarara neden olmaz.

İdeal olarak, genel sisteminizin, tek bir ünitenin kesilmesi genel olarak sistemi değil, sadece o üniteyi kıracak bir tasarıma sahip olmasını istersiniz.

Özellikle anahtarları, çipler arasında standart bir elektrik arayüzünü geçecek şekilde ayrı bir bellekte saklıyorsanız, yalnızca yayınlanması zaten güvenli olan veya cihazın belirli fiziksel örneğine özgü anahtarlar olmalıdır.

Tek bir anahtar tek bir aygıttan ayıklanırsa ve birden fazla yetkisiz klondan olması gereken bir trafik hacminde kötüye kullanılmaya veya görünmeye başlarsa, sunucu tarafında bu anahtarı yasaklayabilirsiniz.

Anahtarlarınız elbette yetkisiz bir tarafın birkaç çıkarılan örnekten tahmin edebileceği veya kendi orijinal uyumlu örneklerini oluşturabileceği bir şey olmamalıdır - yani, geçerli olanların oluşturduğu anahtarların bir kaydına ihtiyacınız vardır. büyük bir olasılık alanının sadece küçük ve öngörülemeyen bir kısmı ya da oluşturduğunuz anahtarları imzalamanız ve sisteminizin sadece bir anahtarı imza kanıtı ile birlikte kabul etmesini sağlamanız gerekir.

İstemci anahtarını gizli tutmaya çalışmalısınız (ancak diğer cevaplarda açıklandığı gibi kaybetmenin (1) anlamını anlamalısınız). Sunucu ortak anahtarı ve AWS ortak sertifikası, aygıtın sonunda gizli tutmak istediğiniz için değil, AWS sertifikasını (güvenliği ihlal edilmiş bir cihazda) değiştirerek bir saldırganın Saldırganın ev sahibi ile veya AWS ile iletişiminizi ortadaki adamla değiştirin.

Bunu yaparak (2), bir saldırgan TLS güvenliğini ortadan kaldırabilir ve bu da güvenliğin sağlanmasında istemci anahtarını tersine çevirebilecek yeterli azalmaya neden olabilir.

Bu nedenle, harici bellek aygıtında açığa çıkarmanın güvenli olduğu tek anahtar sunucu ortak anahtarıdır. Bunu (3) değiştirmek, cihazınızın yalnızca mühendis tarafından erişilmesi zor olan sahte bir AWS hizmetine bağlanmaya zorlanmasına izin verir. Sadece bu anahtarın sızdırılması bile birisinin bazı yayınları gizlemesine veya taklit etmesine izin verebilir (örneğin TLS katmanı bir şekilde düşürülebilirse).

Özet olarak, risk sadece bilgi sızıntısı değildir, (sözde güvenilir) ürün yazılımının güvenilir olmayan güvenli bilgilerle sağlanabilmesi riski vardır.