Sınırlı yerleşik sistemler arasındaki iletişimi güvenli hale getirme
Şu anda gömülü bir sistemde sınırlı bir fiziksel iletişim kanalı üzerinden iletişimi güçlendirmeye çalışıyorum.
Senaryo
Sistemin küçük gömülü uygulamalar için oldukça tipik olduğunu düşünüyorum:
Dahil edilen gömülü sistemler, herhangi bir işletim sistemi olmayan küçük mikro denetleyicilerdir ve güvenli bir fiziksel ortamda olduğu varsayılabilir. Bağlantı kanalı saldırganlar tarafından fiziksel olarak erişilebilir durumdadır, mesajlara istedikleri gibi müdahale edebilirler.
Farklı iletişim kanalları mümkündür: örn. RS485 veya RS232. Üzerine inşa edebileceğimiz adresleme ve kaba bütünlük (örneğin bitflips için CRC16) gibi şeyleri işleyen kaba bir protokol var. Bunu yavaş bir TCP olarak düşünün.
Her iletişim ortağı, CA olarak hareket edebilen ve kendisi tarafından imzalanmış kendi benzersiz sertifikasına (+ anahtarı) sahip olan bir kök sertifika bilir. Sertifikalar kendinden imzalı, eliptik eğri prime256v1'dir
MbedTLS kitaplığı bu sistemler için mevcuttur (DH, AES, .. ile).
Çoğu zaman internet mevcut değildir.
Sistemler zamanı koruyabilir ve yeterli sayıda rastgele sayı oluşturabilir
Mahremiyet, özgünlük ve bütünlüğe ulaşmak istiyorum.
Nasıl çözülebilir
Kriptografik protokollerdeki bir kural, bunları asla kendi başınıza uygulamamaktır. Maalesef bu kullanım durumuyla eşleşen hiçbir şey bulamadım.
Mevcut sorulara da göz attım, ancak hiçbir şey aradığım tam çözümü sağlamadı.
Son olarak bu cevapta kendi protokolünü uygulamak son seçenek olarak verilmiştir.
Bu yüzden aşağıda açıklanan çözümü buldum - ancak bundan tam olarak emin değilim. Ben odaklı bir Diffie-Hellmann Anahtar Değişimi kimliğini doğrulamak için nasıl bu cevap , bütünlüğünü nasıl kontrol edileceği bu cevabı ve bana böyle bir protokol nasıl uygulanacağına ilişkin bazı fikirler vererek bu konuyu .
İletişimi güvenli hale getirmek için protokol
İlk yapılacak şey, rastgele bir K anahtarını oluşturmaktır. İlk gönderilen şey bir el sıkışma mesajıdır. Aşağıdaki alanlara sahiptir:
| Alan | Açıklama |
|---|---|
| DH | Diffie-Hellmann anahtar değişimi msg K |
| Sertifika | Gönderen cihazın sertifikası (-zinciri) |
| MsgIdNonce | Rastgele bir 64 bit değer |
| İmza | Cert'in özel anahtarını kullanan tam mesajın imzası |
Her iki cihaz da böyle bir mesaj gönderir (ve alır).
Bir mesaj alındığında aşağıdakiler yapılır:
- Sertifikanın beklenen CA tarafından imzalanıp imzalanmadığını kontrol edin (zincir halinde olması gerekir)
- Msg'nin sertifika ve anahtarı ile doğru şekilde imzalanıp imzalanmadığını kontrol edin
Bu kontroller başarılı olduğunda, gönderilen ve alınan DH g K mesajları bir simetrik anahtarı hesaplamak için kullanılır.
Bu noktadan itibaren, uygulamalar AES-CBC ile şifrelenmiş mesajlar gönderebilir. Mesajlar nispeten sık kaybolabileceğinden, IV her zaman mesajın içindedir.
Bu mesaj formatıdır:
| Alan | Açıklama | Şifreli |
|---|---|---|
| IV | AES için Başlangıçta Rastgele IV | Hayır |
| MsgIdNonce | El Sıkışma / Son Mesaj Kimliği Bir kez + 1 veya + 2 | Evet |
| Uygulama Verileri | Korunacak veriler / komutlar | Evet |
| CMAC, 64 Bit'e kesildi | Bütünlüğü kontrol etmek için MAC | Evet |
Bir mesajın kabul edilmesi için
- Beklenen MsgIdNonce (sondan 1 veya 2'si alınan) - tekrar saldırılarını önleyerek 1 mesajın kaybolmasına izin verin
- Geçerli bir CMAC'a sahip olun - bütünlüğe yönelik saldırıları önleyin
- Max alınacak. Son mesajdan T saniye sonra - gecikme saldırılarını önleme
Herhangi bir şey beklendiği gibi değilse, Tokalaşma tekrar gönderilir, ardından yeni değiştirilen parametrelerle mesaj tekrar gönderilir.
Sorular
Doğru yolda mıyım yoksa tamamen farklı bir şey denemeli miyim?
Bu, güvenlik hedeflerimi sağlıyor mu yoksa buradaki bariz güvenlik açıklarını kaçırıyor muyum?
Bu çalışabilir mi?
Umarım bana ve benzer sorunlarla karşılaşan diğer gömülü mühendislere yardım edebilirsiniz!
Yanıtlar
Kriptografik protokollerdeki bir kural, bunları asla kendi başınıza uygulamamaktır. Maalesef bu kullanım durumuyla eşleşen hiçbir şey bulamadım.
DTLS'yi düşündünüz mü ? Bu, aynı sorunu çözmeye çalışır (zaman damgaları hariç; bu, datagrama zaman damgası eklenerek eklenebilir) ve zaten üzerinde düşünülmüş şeyler vardır. Diğer bir olasılık IPsec olabilir; ancak DTLS, sahip olduğunuz sorunu çözmeye daha yakından bakar (koruduğunuz veri trafiği IP trafiği değilse).
Bununla birlikte, özetlediğiniz protokole ilişkin bazı düşünceler şunlardır:
İki ardışık mesaj bırakılırsa (örneğin yanlış alınırsa) ne olur? İki taraf ne olduğunun farkına varacak mı, yoksa sonraki tüm mesajları bırakmaya devam edecekler mi ('nonce 2'den fazla artmamalıdır' kuralı nedeniyle)?
Yeniden anahtarlamayı denediklerini varsayarsak, bu nasıl koordine edilir? Bir taraf henüz yeniden anahtarlamadıklarını düşünürse ve diğer taraf öyle olduğunu düşünürse, eski anahtarla şifrelenen mesajlara ne olacak? Genel olarak, şifreli metinle birlikte 'hangi anahtarın şifrelenmiş olduğu' etiketini eklemeyi yararlı buluyoruz (DTLS'de bu, 'çağ'dır).
İletişim kanalınız mesajları yeniden sıralayabilir mi? Senin durumunda olamayacağından şüpheleniyorum, ama yapabilirse, bunun nasıl halledilmesi gerektiğini düşünmelisin.
Birisi önceki (geçerli) bir el sıkışma mesajını enjekte ederse ne olur? Bu işleri nasıl karıştırır?
Veri şifreleme yolunda, CBC şifrelemesini ve CMAC bütünlüğünü kullanırsınız. Bu uygulanabilir bir çözüm olsa da, doğru şekilde entegre edilmemişlerse çeşitli dolgu saldırılarına eğilimlidir. Mevcut moda, her ikisini de yapan bir AEAD modu (GCM veya Chacha20 / Poly1305 gibi) kullanmaktır.
Şifrelenmiş trafik tek yönlü mü yoksa çift yönlü mü? Trafik her iki yönde de gidiyorsa, her iki trafiği de korumak için aynı anahtar grubunu kullanıyor musunuz?
"Herhangi bir şey beklendiği gibi değilse, Tokalaşma tekrar gönderilir, ardından yeni değiştirilen parametrelerle mesaj tekrar gönderilir." - bu nasıl çalışıyor? Alıcı mesajı beğenmediğine karar verirse, gönderen mesajı yeniden göndermeyi nereden biliyor?