IoT ได้มีจำนวนเพิ่มขึ้นมากแต่ปัญหาที่ตามมาคือความมั่นคงปลอดภัยที่เกิดขึ้นหลายประการ โดยวันนี้จึงขอสรุปบทความจาก Cloudflare ผู้ให้บริการ CDN และบรรเทาการโจมตีแบบ DDoS โดยจะกล่าวถึงสาเหตุของปัญหาว่าแม้จะมีวิธีการแก้ปัญหาด้วยการอัปเดตซอฟต์แวร์และเปิดใช้งาน TLS แล้ว แต่ก็มีเหตุผลในการใช้งานจริงว่าทำไมมันจึงไม่ง่ายเหมือนที่เราคิด
ปัญหาการอัปเดตของ IoT
- ผู้ใช้งานมือถือหรือคอมพิวเตอร์สามารถเข้าใจและตอบสนองกับการอัปเดตซอฟต์แวร์ใหม่ๆ ได้ แต่ในทางกลับกันจะมีสักกี่คนที่รู้ว่าควรทำอย่างไรกับการอัปเดตอุปกรณ์ IoT ซึ่งไม่เคยเกิดขึ้นมาก่อน เช่น หากต้องอัปเดตอุปกรณ์วัดอุณหภูมิคุณจะทำอย่างไร
- หากอุปกรณ์มีอายุการใช้งานนานอย่าง เช่น ในชีวิตจริงเราใช้ตู้เย็นกันเป็น 10 ปี ดังนั้นปัญหาเลวร้ายที่ตามมาคือความเข้ากันได้ของซอฟต์แวร์ใหม่กับอุปกรณ์เก่า ซึ่งมันอาจจะไม่สามารถอัปเดตซอฟต์แวร์เวอร์ชันใหม่ได้แล้ว
- ปัญหาแบตเตอรี่หากอัปเดตซอฟแวร์ใหม่มันอาจจะทำให้ใช้แบตเตอรี่มากขึ้น ดูอย่างไอโฟนสิ
- IoT เป็นอุปกรณ์ที่ Lightweight นั่นหมายความว่ามันไม่ได้ใช้งาน OS ทั้งตัว มันเพียงแต่ใช้ไฟล์ไบนารี่บน Firmware นั่นทำให้มันมีข้อจำกัดในการอัปเดตแพตซ์ในภายหลัง
- เป็นไปได้ที่การอัปเดตแพตซ์อาจทำให้อุปกรณ์หลายพันชิ้นเกิดมีปัญหา ดังนั้นนักพัฒนามักจะกลัวการผลักดันแพตซ์ไปให้ผู้ใช้ในคราวเดียว
ทำไม IoT ถึงถูกโจมตี 2 เหตุผลง่ายๆ คือนอกจากมันป้องกันได้ยากแล้วมันยังสามารถต่อยอดเข้าไปถึงแอปพลิเคชันอื่นๆ ได้ อีกทั้งหากมีใครคนนึงเข้าถึงอุปกรณ์คุณได้แล้วก็หมายถึงการเข้าถึงเครือข่ายซึ่งส่งทราฟฟิคเข้าไปในระบบได้ แล้วคำถามคือจะป้องกันอย่างไร เราต้องป้องกันตามการไหลผ่านของทราฟฟิคที่อุปกรณ์ IoT ส่งข้อมูลเป็นลำดับชั้นที่จุดต่างๆ เพื่อจำแนกข้อมูลไม่ดีออกไป เช่น ระดับเซิร์ฟเวอร์ของแอปพลิเคชัน ส่วน CDN ที่ข้อมูลอุปกรณ์ไหลผ่าน รวมถึง ISP ที่อุปกรณ์ใช้งานด้วย
การใช้งาน TLS แบบเดิมมันไม่ได้ Lightweight
อย่างที่ทราบกันดีอุปกรณ์ IoT ถูกออกแบบมาให้ใช้ชิปพลังงานต่ำ โดย Ram ของมันอาจจะมีขนาดแค่ 256 หรือ 512 กิโลไบต์เท่านั้นเอง เพื่อใช้ในการส่งและรับข้อมูลเล็กๆ จำนวนมากตามคาบเวลา สมมติว่าใช้เซนเซอร์เพื่อจับความเร็วของลมทุก 30 วินาทีผ่าน HTTP มันจะมีแค่ 2 Packet คือ Post Request และ Respond แต่หากใช้ TLS 1.2 แบบปกติจะเกิดเหตุการณ์ตามรูปด้านล่าง ซึ่งไม่ได้ตอบโจทย์เรื่อง Lightweight ของ IoT เลยเพราะมันเพิ่ม Overhead จากข้อมูลเดิมทำให้ใช้เวลาในการส่งข้อมูลเพิ่มขึ้น
แต่หากเราใช้ TLS 1.3 ตามรูปด้านล่างจะเห็นว่ามันตัดขั้นตอนของ TLS 1.2 ไปครึ่งหนึ่งเลยทีเดียว ซึ่งฝั่งไคลเอนต์จะทำนายว่าโปรโตคอลหรืออัลกอริทึมใดที่เซิร์ฟเวอร์จะเลือกใช้ โดยมันจะส่งพารามิเตอร์และ Share Key เหล่านั้นไปให้เซิร์ฟเวอร์ใน Hello Packet ถ้าฝั่งเซิร์ฟเวอร์ตอบรับตามนี้มันจะส่ง Share Key ของอัลกอริทึมเดียวกันกลับมาเป็นอันจบกระบวนการ
อย่างไรก็ตามปัญหาที่เกิดขึ้นคือแม้ว่าจะมี TLS 1.3 ออกมาแต่ตัวกลางที่ ISP หรือองค์กรต่างๆ ใช้ยังคงตื่นตระหนกเมื่อพบ TLS 1.3 และปิดการเชื่อมต่อไป คล้ายกับตอนที่อัปเกรตการใช้งานเป็น TLS 1.2 แต่ตัวกลางยังรองรับแค่ TLS 1.1 ดังนั้นมันคงต้องใช้เวลาสักพัก
อีกเรื่องหนึ่งคือขนาดของ Certificate ที่ใช้ในกระบวนการ TLS เพื่อพิสูจน์ตัวตนของทั้งสองฝั่งในการส่งที่ต้องถูกเก็บไว้ในตัวอุปกรณ์ IoT ที่มีขนาดจำกัด โดยอัลกอริทึม RSA ขนาดของ Certificate อาจมีถึง 1,024 ถึง 2,048 ไบต์เนื่องจากขนาดของมันสัมพันธ์กับระดับความมั่นคงปลอดภัย แต่ก็มีอัลกอริทึมการเข้ารหัสที่ใหม่กว่าเรียกว่า Elliptic Curve ที่สามารถทำให้ใช้ Key ที่เล็กลงแต่มีระดับความมั่นคงปลอดภัยเทียบเคียงได้กับ RSA
Plaintext โปรโตคอลแบบเดิมของ IoT
มีโปรโตคอลอย่าง MQTT ที่ถูกคิดขึ้นเมื่อ 20 ปีที่แล้ว โดยแนวคิดคือมันจะมี Proxy เซิร์ฟเวอร์เป็นนายหน้าเพื่อคอยรับสารระหว่างแอปพลิเคชันของ IoT และกระจายสารเหล่านั้นไม่ยังอุปกรณ์ IoT ที่ต้องการรับสาร เนื่องด้วยการที่มันถูกคิดค้นมานานแล้วเพื่อใช้ในบริษัทพวกน้ำมันและแก๊สที่เพียงแค่รับส่งข้อมูลจากเซนเซอร์โดยปราศจากการเข้ารหัสดังนั้นมันจึงไม่ตอบโจทย์ความมั่นคงปลอดภัย อีกโปรโตคอลหนึ่งอย่าง CoAP ที่มีการส่ง Request และ Respond เหมือนกับ HTTP หากแต่เป็นการส่งบน UDP ถ้าเรานำมาใช้กับ TLS มันจะเกิดขั้นตอนที่ไม่ตอบโจทย์เรื่อง Lightweight เช่นเดิมดังรูปด้านล่าง