Tek Yönlü SSL bir IoT cihazını güvence altına alabilir mi?

İnternet erişimi olan veya olmayan yerel ağıma bağlı bir IoT cihazını (varsayılan ayarlar, VPN yok, NAT yok, DMZ yok) düşünüyorum. Cihazım, kimlik doğrulama ve yetkilendirme içeren bir RPC mekanizması sunan bir HTTP sunucusu olarak çalışacaktır. MDNS ile kendini tanıtır ve mobil uygulamamı veya RaspberryPi'mi kullanarak onunla konuşurum.

Görünüşe göre IoT geliştirmedeki norm karşılıklı (iki yönlü) SSL'ye sahip olmak. Bu, tek yönlü SSL'nin trafiğimi güvence altına alamayacağı anlamına mı geliyor? Neden?

Notlar:

• Bir ve iki yönlü SSL arasındaki teknik farkları anlıyorum, IoT üretiminde neden Tek yönlü (neredeyse) hiç düşünülmediğini anlamıyorum.
• Yerel bir cihaz için karşılıklı SSL'ye sahip olmanın zor olduğunu anlıyorum: sunucu ortak anahtarını paylaşmanız ve istemciye veya tam tersine onaylamanız gerekir. Diğer yandan, tek yönlü daha kolay görünüyor (kullanıcı işlemi gerektirmez).
• Philips Hue gibi toplu üretilen bazı cihazlarda, tek yönlü SSL şifrelemesinden ziyade yerel bir http bitiş noktası açık ve güvenli değil. Neden bu seçim yapılır?
• Bu sorunun görüşe dayalı olmamasını bekliyorum. Durum böyleyse özür dileriz.

SSL / TLS, "sunucu" sunduğu sertifikanın CN'siyle eşleşebilecek bilinen bir konumda (sabit bir ana bilgisayar adı) olduğunda iyi çalışır.

Bu, RFC1918 bloklarından verilen IP adreslerini alma eğiliminde oldukları ve DNS girişleri olmadığı için ev ağlarındaki cihazlarda (örneğin çoğu IoT cihazı) iyi çalışmaz. Bu, sertifikalarla verilemeyecekleri anlamına gelir (iyi yapabilirler, ancak çoğu tarayıcı bunları reddeder). Bu nedenle Philips Hue gibi cihazlar cihazın güvenli olmayan HTTP uç noktalarını kullanır, temel olarak cihazı korumak için güvenli olan ağa erişmeye dayanırlar.

Karşılıklı TLS kullanıldığında, cihaz bazı merkezi hizmetlere bağlandığında kullanılır, istemcinin bu merkezi sunucu ile sahip adına hareket edebildiğini doğrulamak için kendi sertifika / özel anahtarı vardır.

Sorunuz için bir açıklama noktası olarak, sunucu sertifikasını / anahtarını tüm istemcilere dağıtmanız gerekmez, yalnızca sertifikayı veren CA'nın sertifikanın güvenilir olduğunu kanıtlamak için sertifikası gerekir.

DÜZENLE:

Güvenli bir yerel aygıt bağlantısına iyi bir örnek, IKEA'nın, istemci başına bir anahtar oluşturmak için kullanılan aygıtta önceden paylaşılan bir anahtarla (QR kodunda) DAP üzerinden COAP kullanan Tradfri aydınlatmasıdır. Bu, yeni bir istemci kurmak için fiziksel erişim sağlar ve yerel ağda uçuş halindeki verileri korur.

Genel olarak, TLS x.509'dan çok daha iyidir, ancak birçok uygulama bunu yalnızca x.509 ile sınırlar.

x.509 güvenli dolaylı güven tekniğidir. "A", "B" tarafından imzalanmış bir sertifikaya sahipse "B" ye güvenir ve "A" tarafından "C" ye güvenilir. Bu gerçek hayatta da işe yarıyor; güvendiğiniz bir kişi tarafından imzalanmış bir mektup sunuluyorsa, tanımadığınız birine güvenirsiniz. Belki bir tuzak görüyorsunuz: mektup söylerse, lütfen bir fincan kahve verin arabanızı vermeyeceksiniz. Bu nedenle, sertifikadaki ek bilgiler de güveni kapsamakla ilgilidir. Bu nedenle bir sunucu genellikle sertifikasında dns adı veya ip adresi içerir. Genel olarak farklı bilgiler ekleyebilirsiniz (örn. "Oturma odası lambası"), ancak birçok uygulama en azından DNS / IP öğelerini kullanmak / kontrol etmek için önceden yapılandırılmıştır. Ve tüm bunlar sadece biri güvenilir olanı önemsiyorsa işe yarıyor "

İçinde zaman geçirebilirseniz, PSK şifre paketleri de sunuyorsa uygulamanızı kontrol edin. Değilse, belki sunucu sertifikasının "doğrulama kontrolünü" ayarlayabilirsiniz. Ancak iyi bir çözüm bulmak için çok fazla okuma gerekir. Ve bazen kullanılan TLS uygulaması bunu sunmuyor.