SSL แบบทางเดียวสามารถรักษาความปลอดภัยอุปกรณ์ IoT ได้หรือไม่

ฉันกำลังพิจารณาอุปกรณ์ IoT ที่เชื่อมต่อกับเครือข่ายท้องถิ่นของฉัน (การตั้งค่าเริ่มต้นไม่มี VPN ไม่มี NAT ไม่มี DMZ) ที่มีหรือไม่มีอินเทอร์เน็ต อุปกรณ์ของฉันจะทำงานเป็นเซิร์ฟเวอร์ HTTP ที่เสนอกลไก RPC พร้อมการตรวจสอบและการอนุญาต โฆษณาตัวเองด้วย mDNS และฉันคุยกับมันโดยใช้แอพมือถือหรือ RaspberryPi ของฉัน

ดูเหมือนว่าบรรทัดฐานในการพัฒนา IoT คือการมี SSL (สองทาง) ซึ่งกันและกัน นั่นหมายความว่า SSL แบบทางเดียวไม่สามารถรักษาความปลอดภัยให้กับทราฟฟิคของฉันได้? ทำไม?

หมายเหตุ:

• ฉันเข้าใจความแตกต่างทางเทคนิคระหว่าง SSL หนึ่งและสองทางฉันไม่เข้าใจว่าทำไม One-way (เกือบ) ไม่เคยถูกพิจารณาในการผลิต IoT
• ฉันเข้าใจว่าการมี SSL ร่วมกันสำหรับอุปกรณ์ในพื้นที่นั้นเป็นเรื่องยาก: คุณต้องใช้รหัสสาธารณะของเซิร์ฟเวอร์และรับรองลูกค้าและในทางกลับกัน ในทางกลับกันดูเหมือนง่ายขึ้น (ไม่ต้องการให้ผู้ใช้ดำเนินการ)
• อุปกรณ์ที่ผลิตจำนวนมากเช่นฟิลิปส์เว้ต้องการเปิดจุดปลาย http ท้องถิ่นและไม่ปลอดภัยกว่าการเข้ารหัส SSL ทางเดียว ทำไมหนึ่งจะเลือกนี้
• ฉันคาดหวังว่าคำถามนี้จะไม่เป็นไปตามความคิดเห็น ขออภัยหากเป็นกรณีนี้

SSL / TLS ทำงานได้ดีเมื่อ "เซิร์ฟเวอร์" อยู่ในตำแหน่งที่ทราบ (ชื่อโฮสต์คงที่) ที่สามารถจับคู่ CN ของใบรับรองที่นำเสนอ

สิ่งนี้ใช้งานไม่ได้กับอุปกรณ์ในเครือข่ายในบ้าน (เช่นอุปกรณ์ IoT ส่วนใหญ่) เพราะพวกเขามักจะได้รับที่อยู่ IP ที่ออกจากบล็อก RFC1918 และไม่มีรายการ DNS ซึ่งหมายความว่าพวกเขาไม่สามารถออกใบรับรองพร้อม (ทำได้ดี แต่เบราว์เซอร์ส่วนใหญ่จะปฏิเสธ) นี่คือเหตุผลที่อุปกรณ์เช่น Philips Hue ใช้จุดปลาย HTTP ที่ไม่ปลอดภัยของอุปกรณ์โดยทั่วไปแล้วพวกเขาจะพึ่งพาการเข้าถึงเครือข่ายที่ปลอดภัยเพื่อปกป้องอุปกรณ์

เมื่อใช้ TLS ร่วมกันจะมีไว้สำหรับเมื่ออุปกรณ์กำลังเชื่อมต่อกับบริการกลางบางอย่างลูกค้ามีคีย์รับรอง / ส่วนตัวของตัวเองเพื่อตรวจสอบว่าสามารถดำเนินการในนามของเจ้าของกับเซิร์ฟเวอร์กลางนั้น

ในฐานะที่เป็นคำชี้แจงสำหรับคำถามของคุณคุณไม่จำเป็นต้องแจกจ่ายเซิร์ฟเวอร์ใบรับรอง / คีย์ให้กับลูกค้าทั้งหมดเพียงแค่ใบรับรอง CA ที่ออกใบรับรองนั้นจำเป็นต้องมีเพื่อพิสูจน์ว่าใบรับรองนั้นเชื่อถือได้

แก้ไข:

ตัวอย่างที่ดีของการเชื่อมต่ออุปกรณ์ในพื้นที่ที่ปลอดภัยคือแสง Tradfri ของ IKEA ซึ่งใช้ COAP บน DTLS ด้วยรหัสที่แบ่งปันล่วงหน้า (ในรหัส QR) บนอุปกรณ์ที่ใช้สร้างคีย์ต่อไคลเอ็นต์ วิธีนี้ช่วยให้มั่นใจว่าสามารถเข้าถึงการตั้งค่าไคลเอนต์ใหม่และปกป้องข้อมูลบนเครือข่ายท้องถิ่น

โดยทั่วไป TLS นั้นดีกว่า x.509 มาก แต่การใช้งานจำนวนมาก จำกัด เพียง x.509

x.509 เป็นเทคนิคสำหรับความไว้วางใจทางอ้อมที่ปลอดภัย "A" trusts "B" ถ้า "B" มีใบรับรองซึ่งลงนามโดย "C" และ "C" เชื่อถือได้โดย "A" สิ่งนี้สามารถใช้ได้ในชีวิตจริงด้วยเช่นกัน คุณเชื่อใจคนที่คุณไม่รู้จักถ้าจดหมายนั้นลงชื่อโดยบุคคลที่คุณไว้ใจ บางทีคุณอาจเห็นหลุมพราง: ถ้าจดหมายบอกว่าโปรดให้กาแฟหนึ่งถ้วยคุณจะไม่ให้รถของคุณ ดังนั้นข้อมูลเพิ่มเติมในใบรับรองจึงเกี่ยวข้องกับขอบเขตความเชื่อถือ นั่นเป็นสาเหตุที่เซิร์ฟเวอร์มักจะมีชื่อ DNS หรือที่อยู่ IP ในใบรับรอง โดยทั่วไปคุณอาจรวมถึงข้อมูลที่แตกต่างกัน (เช่น "โคมไฟในห้องนั่งเล่น") แต่การใช้งานหลายอย่างก็มีการกำหนดค่าไว้ล่วงหน้าอย่างน้อยให้ใช้ / ตรวจสอบข้อมูล DNS / IP และทั้งหมดนี้จะทำงานได้ก็ต่อเมื่อมีคนใส่ใจเกี่ยวกับความน่าเชื่อถือ "

หากคุณสามารถใช้เวลาในการตรวจสอบการใช้งานของคุณถ้ามันยังมีชุดเลขศูนย์ PSK หากไม่ใช่คุณอาจปรับ "การตรวจสอบความถูกต้อง" ของใบรับรองเซิร์ฟเวอร์ แต่มันต้องการการอ่านจำนวนมากเพื่อหาทางออกที่ดี และบางครั้งการใช้ TLS ที่ใช้ก็ไม่ได้นำเสนอสิ่งนั้น