เกตเวย์ของเราเป็นหัวใจสำคัญของโครงสร้างพื้นฐาน SensorFlow วัตถุประสงค์หลักของพวกเขาคือสองเท่า โดยทำหน้าที่เป็นพร็อกซีสำหรับเซ็นเซอร์ของเราในการส่งต่อข้อมูลเซ็นเซอร์ที่บันทึกไว้ไปยังคลาวด์ รวมถึงส่งผ่านคำสั่งไปยังเซ็นเซอร์ที่ได้รับจากแดชบอร์ด ประการที่สอง พวกมันบรรจุกลไกการตัดสินใจของเราซึ่งรับผิดชอบในการควบคุมอุปกรณ์ที่มีเครื่องมือตามข้อมูลเซ็นเซอร์ที่บันทึกไว้ (เช่น ไม่มีใครอยู่ในห้อง -> ปิดไฟ AC) เราเลือกแนวทางนี้ด้วยเหตุผลหลักสองประการ:

1. ความปลอดภัย: ครั้งแล้วครั้งเล่าที่เราพบเรื่องราวในข่าวเกี่ยวกับอุปกรณ์ Internet of Things (IOT) ที่ถูกแฮกเกอร์โจมตี เรื่องราวเหล่านี้มีส่วนที่เหมือนกัน: ผู้ขายเชื่อมต่อพวกเขาเข้ากับอินเทอร์เน็ตโดยตรง แต่ไม่ได้ตระหนักว่าความสามารถที่จำกัดของอุปกรณ์ทำให้พวกเขาเสี่ยงต่อการโจมตีที่ซับซ้อน และ/หรือใช้ทางลัดในการใช้งานชั้นความปลอดภัยของอุปกรณ์ IOT ด้วยเหตุนี้ เราจึงเลือกที่จะปกป้องอุปกรณ์ของเราที่อยู่ด้านหลังเกตเวย์ของเราเพื่อจำกัดพื้นผิวการโจมตี และเปิดใช้งานการสื่อสารทั้งหมดผ่านอุปกรณ์ที่ซับซ้อนกว่ามาก ซึ่งสามารถใช้โปรโตคอลความปลอดภัยที่ล้ำสมัยได้อย่างง่ายดาย

2. ประสิทธิภาพของระบบ:อินเทอร์เน็ตของสรรพสิ่งควรจะทำให้อาคารมีความชาญฉลาดมากขึ้น อย่างไรก็ตาม เรามักพบว่าซัพพลายเออร์พึ่งพาระบบคลาวด์และการเชื่อมต่ออินเทอร์เน็ตที่โดดเด่นมากเกินไป เพื่อหลีกเลี่ยงไม่ให้อาคารอัจฉริยะกลายเป็นอาคารโง่ทันทีที่อินเทอร์เน็ตหลุด เราได้ออกแบบระบบของเราในลักษณะที่การตัดสินใจอัตโนมัติทั้งหมดจะทำบนเกตเวย์ ไม่ใช่บนคลาวด์ ดังนั้น แม้ว่าจะไม่มีการเชื่อมต่ออินเทอร์เน็ต อุปกรณ์ทั้งหมดจะยังคงได้รับการตรวจสอบและเป็นอัตโนมัติ ข้อมูลที่บันทึกไว้จะคงอยู่บนเกตเวย์และสตรีมกลับไปยังคลาวด์ SensorFlow เมื่ออินเทอร์เน็ตกลับมาออนไลน์อีกครั้ง

เซ็นเซอร์ IOT ของ SensorFlow สื่อสารเฉพาะกับเกตเวย์ SensorFlow โดยใช้โปรโตคอล Airlink ที่เป็นกรรมสิทธิ์ของเรา การสื่อสารนี้เกิดขึ้นในย่านความถี่ต่ำกว่า GHz โดยปกติจะอยู่ระหว่าง 920-925 MHz ขึ้นอยู่กับประเทศ จึงไม่รบกวนโครงสร้างพื้นฐาน Bluetooth หรือ WiFi ที่มีอยู่ แต่ละเกตเวย์สามารถรองรับโหนดเซ็นเซอร์ได้มากถึง 960 ตัว แต่ในทางปฏิบัติ เราพบว่าเรามักจะเชื่อมต่อได้ไม่เกิน 300 โหนดต่อเกตเวย์ ขึ้นอยู่กับช่วงไร้สายที่ทำได้ เนื่องจากเค้าโครงและวัสดุของอาคาร โดยปกติแล้ว เราจะติดตั้งเกตเวย์ได้ไม่เกิน 15 เกตเวย์ต่อไซต์ โดยจำนวนเกตเวย์โดยเฉลี่ยที่ติดตั้งอยู่ที่ประมาณ 7-8
​

เกตเวย์ของเราขึ้นอยู่กับโครงสร้างพื้นฐานอินเทอร์เน็ตของไซต์และสามารถเชื่อมต่อผ่าน WiFi หรืออีเธอร์เน็ต โดยอีเธอร์เน็ตเป็นตัวเลือกที่ต้องการ เราไม่เปิดพอร์ตใดๆ ออกสู่ภายนอก และการสื่อสารทั้งหมดเริ่มต้นโดยใช้คำขอปกติหรือการเชื่อมต่อ VPN เราไม่ได้ใช้โครงสร้างพื้นฐานพร็อกซีใดๆ การลดพื้นที่การโจมตีเพิ่มเติมสามารถทำได้หากไคลเอนต์ตั้งค่าเครือข่ายย่อยเพื่อให้เกตเวย์ของเราเชื่อมต่อ ด้วยเหตุนี้ เราจึงสามารถแยกการสื่อสารของเราออกจากเครือข่ายของโรงแรมได้ โครงสร้างพื้นฐานไฟร์วอลล์ใดๆ ควรได้รับการปรับใช้โดยเครือข่ายไคลเอนต์ที่ให้ไว้ และจะไม่ส่งผลกระทบต่อเกตเวย์ของเรา เนื่องจากการสื่อสารทั้งหมดเป็นแบบขาออก เกตเวย์ต้องการให้เปิดพอร์ตต่อไปนี้บนไฟร์วอลล์สำหรับการสื่อสารขาออก:

ข้อกำหนดแบนด์วิดท์สำหรับเกตเวย์นั้นต่ำมาก เนื่องจากส่วนใหญ่จะส่งต่อข้อมูล IOT ในรูปแบบของข้อความ json แบบสั้น รวมถึงข้อความบันทึกเพื่อวัตถุประสงค์ในการวินิจฉัย ปริมาณการอัพโหลดทั้งหมดของเกตเวย์อยู่ที่ประมาณ 2MB ต่อชั่วโมง ขึ้นอยู่กับการติดตั้งจริง กระแสข้อมูลดาวน์สตรีมจะไม่สำคัญในการดำเนินการตามปกติ และจะไม่เกินสองสามกิโลไบต์ต่อวัน
​

เกตเวย์โต้ตอบกับบริการภายนอก 3 รายการ:
​
1. อเมซอนเว็บเซอร์วิส (AWS)- รันโครงสร้างพื้นฐานคลาวด์ทั้งหมดที่ประกอบเป็นการวิเคราะห์ SensorFlow และแบ็กเอนด์แดชบอร์ด การโต้ตอบทั้งหมดได้รับการรักษาความปลอดภัยโดยใช้ AWS Cognito ซึ่งเป็นบริการที่ให้การตรวจสอบสิทธิ์ การอนุญาต และการจัดการผู้ใช้ (https://aws.amazon.com/cognito)

2. บาเลนา.io- -https://Balena.io/
Balena ถูกใช้เป็นการจัดการกลุ่มยานพาหนะสำหรับเกตเวย์ โดยรายงานสถานะของเกตเวย์และจัดการการอัปเดต/แพตช์ใดๆ ไปยังเกตเวย์ BalenaOS เป็นระบบปฏิบัติการพื้นฐานของเกตเวย์ แอปพลิเคชันหลักทำงานในคอนเทนเนอร์ Docker บนระบบปฏิบัติการ คุณสามารถดูคำอธิบายโดยละเอียดเกี่ยวกับการใช้งานด้านความปลอดภัยที่เกี่ยวข้องกับ Balena ได้ที่นี่:https://www.balena.io/docs/learn/welcome/security/
การสื่อสารของ Balena: 1. VPN สำหรับการรายงานเวลาทำงานของระบบและการส่งบันทึก 2. บริการสำรวจเพื่อตรวจสอบว่ามีการอัปเดตใดๆ หรือไม่

1. ทางกระดาษ- -https://papertrailapp.com
ข้อมูลบันทึกจากเกตเวย์จะถูกส่งไปยัง Papertrail เพื่อการจัดการบันทึก ใช้สำหรับการอ่านบันทึกอย่างง่ายดายสำหรับปัญหาการแก้ไขปัญหาต่างๆ บันทึกสามารถค้นหาได้เป็นเวลา 2 สัปดาห์และเก็บถาวรเป็นเวลาหนึ่งปี (ที่เก็บข้อมูลพื้นฐานคือ AWS S3)

รูปที่ 1ให้รายละเอียดเกี่ยวกับองค์ประกอบต่างๆ ที่สื่อสารกันในสถานที่และวิธีการโต้ตอบกัน

รูปที่ 1: ภาพรวมเครือข่ายที่ให้รายละเอียดช่องทางการสื่อสารระหว่างโหนด เกตเวย์ และบริการภายนอกของเรา
​

แดชบอร์ดของเราช่วยให้ลูกค้าสามารถดูข้อมูลที่บันทึกไว้และควบคุมระบบ AC ที่ติดตั้งอุปกรณ์ได้ สามารถเข้าถึงได้จากเว็บเบราว์เซอร์ใดก็ได้ และได้รับอนุญาตผ่านการเข้าสู่ระบบชื่อผู้ใช้และรหัสผ่าน โฮสต์บน Google Firebase และประกอบด้วย html, javascript และรูปภาพต่างๆ การสื่อสารทั้งหมดดำเนินการด้วย AWS cloud ผ่าน TLS

การตรวจสอบสิทธิ์และการอนุญาตสำหรับแดชบอร์ดยังใช้บริการ AWS cognito (https://aws.amazon.com/cognito). เราจะสร้างบัญชีผู้ใช้ตามคำขอของลูกค้าเพื่อให้เฉพาะพนักงานที่เกี่ยวข้องเท่านั้นที่สามารถเข้าถึงแดชบอร์ดได้

หน้าที่ป้องกัน AWS (https://aws.amazon.com/guardduty/) ใช้เพื่อตรวจสอบบัญชีคลาวด์สำหรับกิจกรรมที่ผิดปกติหรือน่าสงสัย
​

ข้อมูลที่ส่งไปยัง AWS Cloud จะถูกจัดเก็บไว้ใน DynamoDB (ฐานข้อมูล NoSql) เพื่อวัตถุประสงค์ในการให้บริการแอปพลิเคชัน ข้อมูลยังถูกจัดเก็บไว้ในฐานข้อมูลอนุกรมเวลาประสิทธิภาพสูง (ส่วนขยาย Postgres + TimeScaleDB) เพื่อวัตถุประสงค์ด้านวิทยาศาสตร์ข้อมูล ฐานข้อมูลทั้งสองโฮสต์โดย AWS DynamoDB ทำงานเป็นบริการที่ได้รับการจัดการจาก AWS และฐานข้อมูลอนุกรมเวลาของเราโฮสต์บนอินสแตนซ์ AWS EC2
​

เราปรารถนาที่จะให้บริการแบบ end-to-end แก่ลูกค้าของเรา และมีการสนับสนุนโดยเฉพาะในการสแตนด์บายเพื่อแก้ไขปัญหาของระบบผ่านความสามารถในการบำรุงรักษาระยะไกลของเรา ซึ่งรวมถึงความสามารถในการอัปเดตเฟิร์มแวร์ของโหนดเซ็นเซอร์โดยใช้กระบวนการอัปเดตแบบ over-the-air ระหว่างเกตเวย์และเซ็นเซอร์ เราใช้สิ่งนี้เพื่อส่งมอบการอัปเดตความปลอดภัย การแก้ไขข้อบกพร่อง หรือคุณสมบัติใหม่ให้กับเซ็นเซอร์ของเรา นอกจากนี้ เรายังมีความสามารถในการอัปเดตซอฟต์แวร์เกตเวย์ของเราจากระยะไกล รวมถึงการเริ่ม รีสตาร์ท และปิดเกตเวย์โดยใช้บริการ balena.io ในบางกรณีซึ่งเกิดขึ้นไม่บ่อยนัก หากมาตรการระยะไกลทั้งหมดล้มเหลว เราจะขอความช่วยเหลือจากวิศวกรโรงแรมในสถานที่ ส่วนใหญ่จะเป็นการเปลี่ยนแบตเตอรี่หรือการแลกเปลี่ยนฮาร์ดแวร์ที่เสียหายหรือเสียหาย ในกรณีที่งานปัจจุบันซับซ้อนเกินกว่าที่วิศวกรนอกสถานที่จะดำเนินการได้ เราจะส่งผู้จัดการโครงการติดตั้งเฉพาะของเราไปทำงานที่จำเป็น โดยจะมีการประเมินเป็นรายกรณีไป
​

เฉพาะเกตเวย์ SensorFlow เท่านั้นที่เชื่อมต่อโดยตรงกับเครือข่ายของลูกค้า ในขณะที่โหนดเซ็นเซอร์จะสื่อสารกับเกตเวย์ของเราเท่านั้น และไม่เคยเชื่อมต่อกับอินเทอร์เน็ตโดยตรง ด้วยเหตุนี้ มีเพียงเกตเวย์เท่านั้นที่อาจเสี่ยงต่อการโจมตีทางไซเบอร์ระยะไกลผ่านทางอินเทอร์เน็ต โดยปกติแล้วเราจะเชื่อมต่อเกตเวย์ของเรากับเครือข่ายเดียวกันกับที่แขกของโรงแรมเชื่อมต่อด้วย ซึ่งหมายความว่าจากมุมมองของการออกแบบเครือข่าย ความเสี่ยงด้านความปลอดภัยที่เกี่ยวข้องกับเกตเวย์ของเราสามารถพิจารณาได้เท่ากับความเสี่ยงของอุปกรณ์ใดๆ ที่แขกอาจเชื่อมต่อกับเครือข่ายโรงแรม แม้ว่าผู้โจมตีจะสามารถเข้าถึงหรือควบคุมเกตเวย์ SensorFlow ได้อย่างสมบูรณ์ แต่ผลที่ตามมาก็จะน้อยมากและแยกออกจากเกตเวย์ที่เป็นปัญหา
​

1. (เล็กน้อย) การหยุดชะงักหรือการปิดใช้งานระบบอัตโนมัติ: สิ่งนี้จะทำให้สูญเสียการประหยัดและข้อมูลบางส่วนในห้องที่ให้บริการโดยเกตเวย์นี้ กรณีนี้จะเกิดขึ้นหากผู้โจมตีหยุดแอปพลิเคชัน SensorFlow ที่ทำงานบนเกตเวย์

2. (เล็กน้อย) ผลกระทบต่อความสะดวกสบายของแขก: สิ่งนี้อาจเกิดขึ้นได้หากผู้โจมตีจัดการปิด FCU หลังจากเข้าถึงเกตเวย์ อย่างไรก็ตาม สิ่งนี้ไม่น่าจะเป็นไปได้อย่างยิ่ง เนื่องจากผู้โจมตีจะต้องทำวิศวกรรมย้อนกลับโปรโตคอลที่เป็นกรรมสิทธิ์ของเราโดยสมบูรณ์ เพื่อให้สามารถส่งคำสั่งที่ถูกต้องไปยังอุปกรณ์ของเรา ซึ่งถือเป็นความพยายามทางวิศวกรรมอย่างจริงจัง ความเสียหายสามารถควบคุมได้อย่างง่ายดายด้วยการปิดเกตเวย์ที่ได้รับผลกระทบ ซึ่ง ณ จุดนี้เทอร์โมสตัทของเราจะกลับมาทำงานแบบออฟไลน์ตามปกติ เป็นไปไม่ได้ที่จะจับโครงสร้างพื้นฐานเป็นตัวประกันอย่างถาวรผ่านเวกเตอร์การโจมตีนี้

3. (รอง) การเข้าถึงเครือข่ายโรงแรม: ผู้โจมตีที่ได้รับการควบคุมเกตเวย์สามารถใช้เกตเวย์เพื่อฟังการรับส่งข้อมูลเครือข่ายหรือรบกวนเครือข่ายด้วยสัญญาณรบกวน ผลที่ตามมาของสถานการณ์นี้ขึ้นอยู่กับการตั้งค่าเครือข่ายของโรงแรมเป็นหลัก โดยปกติเราแนะนำให้เกตเวย์เชื่อมต่อกับซับเน็ตแยกของตนเองหรือเครือข่ายเดียวกันกับที่แขกของโรงแรมเชื่อมต่อด้วยสิทธิพิเศษและข้อจำกัดเดียวกัน การตั้งค่าเครือข่ายที่ออกแบบมาอย่างดีจึงไม่อนุญาตให้อุปกรณ์บนเครือข่ายของเกตเวย์หรือเครือข่ายแขกเข้าถึงโครงสร้างพื้นฐานเครือข่ายโรงแรมที่สำคัญ
​

สถานการณ์นี้อธิบายถึงผู้โจมตีที่พยายามเข้าถึงเกตเวย์ระยะไกลผ่านพอร์ตที่เปิดอยู่

ความน่าจะเป็น: เป็นไปไม่ได้

เวกเตอร์การโจมตีนี้ถือว่าเป็นไปไม่ได้ เนื่องจากเกตเวย์ไม่รับฟังพอร์ตใดๆ จากภายนอก และการสื่อสารใดๆ ก็เริ่มออกจากเกตเวย์ ลักษณะการทำงานนี้สืบทอดมาจาก BalenaOS ซึ่งเป็นระบบปฏิบัติการที่สร้างฐานของซอฟต์แวร์เกตเวย์ คุณสามารถดูคำอธิบายโดยละเอียดเกี่ยวกับการใช้งานด้านความปลอดภัยที่เกี่ยวข้องกับ Balena และวิธีการจัดการการสื่อสารและการอนุญาตได้ที่นี่:

https://www.balena.io/docs/learn/welcome/security/

เรารันแอปพลิเคชัน SensorFlow ภายในคอนเทนเนอร์นักเทียบท่าที่ด้านบนของ BalenaOS ซึ่งโต้ตอบกับโครงสร้างพื้นฐานคลาวด์ SensorFlow การสื่อสารทั้งหมดกับคลาวด์ของเราจะถูกส่งออกไปอีกครั้งและไม่มีการเปิดพอร์ต ดังนั้นแอปพลิเคชันของเราจึงไม่เพิ่มพื้นที่การโจมตีเพิ่มเติมให้กับเกตเวย์

เนื่องจากที่กล่าวมาข้างต้น จึงเป็นไปไม่ได้ที่ผู้โจมตีจะค้นหาและโจมตีเกตเวย์ของเราจากระยะไกลโดยไม่ละเมิดโครงสร้างพื้นฐานเครือข่ายของลูกค้าก่อน โดยเฉพาะอย่างยิ่งหากเกตเวย์ได้รับการปกป้องเพิ่มเติมด้วยไฟร์วอลล์ซึ่งจำกัดการเข้าถึงเครือข่ายของไคลเอ็นต์ แม้ว่าพวกเขาจะผ่านไฟร์วอลล์ได้ แต่ก็ยังไม่พบพอร์ตเปิดใด ๆ ที่จะโจมตีเกตเวย์ของเรา
​

วิธีเดียวที่จะโจมตีเกตเวย์ได้คือให้ผู้โจมตีปลอมแปลงเป็นคลาวด์ Balena หรือคลาวด์ SensorFlow ผู้โจมตีที่ประสบความสำเร็จอาจพยายามส่งคำสั่งไปยังเทอร์โมสตัทที่เชื่อมต่อหรือแลกเปลี่ยนเฟิร์มแวร์เกตเวย์กับเฟิร์มแวร์ของตนเอง

ความน่าจะเป็น: หายาก

เราถือว่าสถานการณ์การโจมตีนี้ไม่น่าจะประสบความสำเร็จมากนัก เนื่องจาก API ทั้งหมดของเราได้รับการรักษาความปลอดภัยผ่านการเข้ารหัส HTTPS TLS มาตรฐาน และการอนุญาตและการรับรองความถูกต้องตามใบรับรอง สิ่งนี้จะเกิดขึ้นกับตำแหน่งข้อมูลบริการที่นำเสนอโดย Balena สำหรับการควบคุมและการบำรุงรักษาระยะไกล รวมถึง API คลาวด์ SensorFlow ทั้งหมดที่ได้รับการรักษาความปลอดภัยโดยบริการ AWS Cognito ผู้โจมตีจะต้องขโมยใบรับรองรูท SensorFlow หรือ Balena ได้สำเร็จจึงจะประสบความสำเร็จกับเวกเตอร์การโจมตีนี้
​

หากผู้โจมตีเข้าถึงเกตเวย์ทางกายภาพได้ พวกเขาอาจพยายามเปลี่ยนเฟิร์มแวร์ของเกตเวย์ของเราโดยการสลับการ์ด SD ที่เก็บระบบปฏิบัติการออก และสร้างอุปกรณ์บนเครือข่ายโรงแรมภายใต้การควบคุมของพวกเขาและมีแนวโน้มว่าจะถูกอนุญาตพิเศษในการเชื่อมต่อ โดยไม่ต้องผ่านพอร์ทัลเชลย

ความน่าจะเป็น: หายาก

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

โหนดเซ็นเซอร์ของเรากำลังเชื่อมต่อกับเกตเวย์ของเราผ่านโปรโตคอลที่เป็นกรรมสิทธิ์ของเราที่เรียกว่า AirLink เท่านั้น ด้วยเหตุนี้จึงไม่สามารถเข้าถึงได้โดยสิ้นเชิงและไม่สามารถค้นพบได้จากภายนอก ดังนั้นจึงไม่สามารถถูกโจมตีโดยตรงได้ โหนดของเราไม่พูดโปรโตคอลที่ใช้ IP ใดๆ และด้วยเหตุนี้ จึงไม่สามารถโต้ตอบโดยตรงกับโครงสร้างพื้นฐานเครือข่ายของโรงแรมได้ ความสามารถด้านแบนด์วิธยังถูกจำกัดอย่างมากด้วยการออกแบบ ทำให้ไม่เหมาะสำหรับการโจมตีโครงสร้างพื้นฐานเครือข่ายของโรงแรม นี่เป็นผลมาจากการใช้ LoRa กับ WiFi หรือ Bluetooth การสื่อสารทั้งหมดเกิดขึ้นในรูปแบบไบนารี่ ทำให้การพยายามวิศวกรรมย้อนกลับของโปรโตคอลของเราทำได้ยากมาก
​

1. (เล็กน้อย) ผลกระทบต่อความสะดวกสบายของแขก: หากผู้โจมตีจัดการเพื่อเชื่อมต่อโหนดโกงหรือเข้าควบคุมโหนดอย่างสมบูรณ์ เขาสามารถส่งข้อมูลการเข้าใช้ที่ผิดพลาดซึ่งอาจส่งผลต่อพฤติกรรมของ FCU ในห้องเหล่านั้น ซึ่งอาจส่งผลให้ผู้เข้าพักรู้สึกไม่สบายตัว ผลกระทบสามารถบรรเทาลงได้อย่างง่ายดายโดยการปิด SensorFlow Gateways หรือขึ้นบัญชีดำโหนดจากเครือข่าย Gateway

2. (รองลงมา) การหยุดชะงักหรือการปิดใช้งานระบบอัตโนมัติ: หากผู้โจมตีจัดการเพื่อปิดใช้งานหรือยกเลิกการเชื่อมต่อโหนดเซ็นเซอร์ ระบบอัตโนมัติจะถูกปิดใช้งาน ซึ่งส่งผลให้สูญเสียการออมและการสูญเสียข้อมูล
​

ในกรณีนี้ ผู้โจมตีพยายามติดตั้งโหนดที่เป็นอันตรายในสถานที่ให้บริการ

ความน่าจะเป็น: หายาก

เนื่องจากโปรโตคอลของเราเป็นกรรมสิทธิ์และไม่ได้เผยแพร่ จึงมีคนต้องทำวิศวกรรมย้อนกลับเต็มรูปแบบของโปรโตคอลไร้สายของเราเพื่อพยายามเชื่อมต่อโหนดโกงกับระบบ SensorFlow สิ่งนี้จะทำให้ผู้โจมตีต้องอยู่ในสถานที่เป็นเวลาหลายวันหรือหลายสัปดาห์เพื่อรวบรวมข้อมูลที่เพียงพอจากการสื่อสารปกติเพื่อให้มีโอกาสถอดรหัสโปรโตคอลจากระยะไกล

นอกจากนี้ โหนดทั้งหมดของเรายังมีหมายเลขประจำตัวที่ไม่ซ้ำกัน ซึ่งเรียกว่าที่อยู่ MAC ซึ่งเราบันทึกไว้ก่อนที่จะนำอุปกรณ์เข้าไซต์งาน เกตเวย์ของเราจะปฏิเสธโหนดใดๆ ที่ไม่มีที่อยู่ MAC ที่รู้จัก ที่อยู่ MAC ของโหนดจะมีการแลกเปลี่ยนในระหว่างกระบวนการเชื่อมต่อเริ่มต้นเท่านั้น ทำให้ผู้โจมตีโจมตีแบบกำหนดเป้าหมายได้ยาก หากผู้โจมตีใช้ความพยายามทั้งหมดนี้ ความเสียหายเพียงอย่างเดียวที่เขาสามารถทำได้คือการควบคุม FCU ในห้องพักของโรงแรมโดยไม่สามารถมองเห็นได้ว่าพวกเขากำลังควบคุมห้องใดอยู่ ด้วยความพยายามทั้งหมดนี้ พวกเขาสามารถสร้างความรำคาญให้กับแขกได้เพียงเล็กน้อยเท่านั้น แม้ว่าผู้โจมตีจะพยายามสร้างความเสียหายโดยใช้การโจมตีแบบเล่นซ้ำในการสื่อสารของเรา พวกเขาจะต้องได้รับความเข้าใจโดยละเอียดเกี่ยวกับกำหนดเวลาการสื่อสารของเครือข่ายของเรา ซึ่งจะจำกัดความสำเร็จของเวกเตอร์การโจมตีนี้อย่างมาก
​

โหนดเซ็นเซอร์ของเราได้รับการอัปเกรดจากระยะไกล เกตเวย์ของเราทริกเกอร์การอัปเกรดนี้

ความน่าจะเป็น: หายาก

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

เครือข่ายไร้สายทุกเครือข่ายเสี่ยงต่อการถูกโจมตีจากการรบกวนเครือข่าย ดังนั้นผู้โจมตีในสถานที่จึงสามารถตัดการเชื่อมต่อบางโหนดได้สำเร็จโดยการรบกวนความถี่ที่ระบบ SensorFlow ทำงาน ไม่สามารถป้องกันสิ่งนี้ได้ แต่ผลลัพธ์เดียวคือการปิดใช้งานระบบอัตโนมัติและทำให้ข้อมูลบางส่วนสูญหาย
​

ความน่าจะเป็น: หายาก

ทั้งหมดที่กล่าวมาข้างต้นต้องใช้ความพยายามทางวิศวกรรมย้อนกลับจึงจะประสบความสำเร็จ วิธีที่เร็วที่สุดในการทำเช่นนี้คือพยายามดาวน์โหลดเฟิร์มแวร์จากโหนดของเรา จากนั้นลองถอดรหัสมัน
​

ความน่าจะเป็น: หายาก

สิ่งนี้เป็นไปไม่ได้เนื่องจากเราล็อกโหนดของเราหลังการเขียนโปรแกรม ซึ่งหมายความว่าการเชื่อมต่อเครื่องมือเพื่อดาวน์โหลดเฟิร์มแวร์จะต้องปลดล็อคโหนดซึ่งจะลบเฟิร์มแวร์ทันที