14.3.4. หมายเหตุเกี่ยวกับการป้องกันการอ่านแฟลช

โดยค่าเริ่มต้นจากโรงงาน เฟิร์มแวร์บน OpenMV Cam ที่จัดส่งนั้น อ่านได้ โดยทุกคนที่มีสิทธิ์เข้าถึงอุปกรณ์ทางกายภาพ ผู้โจมตีที่ถือกล้องอยู่ในมือสามารถต่อ SWD probe เข้ากับหัวต่อดีบักได้ ติดต่อกับอินเทอร์เฟซดีบักของ MCU และดัมป์แฟลช ซึ่งรวมถึงโมดูล Python ที่ถูก freeze ทั้งหมดและเนื้อหาของพาร์ติชัน ROMFS เฟิร์มแวร์ OpenMV มาตรฐาน ไม่ เปิดใช้งานการป้องกันการอ่านแฟลชโดยค่าเริ่มต้น

หน้านี้บันทึกข้อมูลดังกล่าวอย่างชัดเจน เพื่อให้ทีมที่จัดส่งผลิตภัณฑ์ทราบว่าความรับผิดชอบอยู่ที่ใด

14.3.4.1. สิ่งที่กล้องทำโดยค่าเริ่มต้น

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

การแลกเปลี่ยนเปลี่ยนไปเมื่อกล้องเปลี่ยนจาก "อุปกรณ์นักพัฒนา" ไปเป็น "ผลิตภัณฑ์" ผลิตภัณฑ์ที่มีมูลค่าขึ้นอยู่กับการรักษาความลับของโค้ดแอปพลิเคชันต้องเปิดใช้งานการป้องกันด้วยตัวเอง เฟิร์มแวร์ OpenMV ไม่ได้ทำสิ่งนี้

14.3.4.2. สิ่งที่ทีมผลิตภัณฑ์ดำเนินการ

ผู้ผลิต MCU ทุกรายมีกลไกการป้องกันการอ่าน รายละเอียดแตกต่างกัน ไม่ว่าจะเป็น fuse ระดับบิต การเปลี่ยนสถานะวงจรชีวิตแบบครั้งเดียว หรือภาพแฟลชที่มีลายเซ็น แต่รูปแบบทั่วไปคือ:

• บิต (หรือชุดบิต) เฉพาะของผู้ผลิตถูกยืนยันลงในซิลิคอน โดยปกติผ่านเครื่องมือของผู้ผลิตที่ติดต่อกับพอร์ตดีบักของ MCU เป็นครั้งสุดท้าย

• หลังจากยืนยัน พอร์ตดีบักปฏิเสธการอ่านแฟลช กล้องยังบูตและรันแอปพลิเคชันได้ตามปกติ เพียงแค่ไม่เปิดเผยเนื้อหาให้กับ probe อีกต่อไป

• การยืนยันนี้ ไม่สามารถย้อนกลับได้ ไม่มีทางใดที่จะนำกล้องกลับสู่สถานะที่ดีบักได้โดยไม่ทำลายมัน

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

นี่คือส่วนที่ง่าย

ส่วนที่ยากคือการปิดทุก เส้นทางอื่น ๆ ที่ผู้โจมตีมีในการรันโค้ดบนกล้องหรืออ่านสิ่งที่แอปพลิเคชันกำลังทำอยู่ การป้องกันการอ่านหยุดเฉพาะ debug probe จากการดัมป์แฟลช กล้องยังต้องปิด:

• MicroPython REPL. REPL ที่เชื่อมต่อผ่าน USB รับ Python ตามอำเภอใจ การป้องกันการอ่านไม่ได้เปลี่ยนแปลงสิ่งนี้ เซสชัน REPL สามารถอ่าน RAM เรียกใช้ฟังก์ชัน ขโมยข้อมูลใด ๆ ที่แอปพลิเคชันที่กำลังทำงานเห็น ในทางปฏิบัติ REPL ที่เข้าถึงได้จะหลีกเลี่ยงทุกสิ่งที่การป้องกันการอ่านให้มา การปิดการเข้าถึง REPL เป็นการเปลี่ยนแปลงบิลด์เฟิร์มแวร์ที่ทีมผลิตภัณฑ์รับผิดชอบ

• การอัปโหลดสคริปต์ผ่าน IDE. เส้นทาง "รันสคริปต์นี้บนกล้อง" ของ IDE ใช้พื้นผิวโปรโตคอล USB เดียวกับที่ REPL ใช้ การปิด REPL จะปิดสิ่งนี้ไปด้วย การเปิดไว้อย่างใดอย่างหนึ่งจะเปิดช่องทางการรันโค้ดตามอำเภอใจเข้าไปในกล้อง

• การยึดจุดเข้าจากระบบไฟล์. ปิดแล้วเมื่อแอปพลิเคชันจัดส่งผ่าน การแช่แข็งสคริปต์ลงในเฟิร์มแวร์ รันไทม์แก้ไข boot.py และ main.py ที่ถูก freeze ก่อนสำเนาในระบบไฟล์ใด ๆ ดังนั้นไม่มีสิ่งใดที่ถูกวางบนแฟลชหรือ SD สามารถแทนที่ได้ การป้องกันนี้ฟรีเมื่อแอปพลิเคชันอยู่ในบิลด์แล้ว

• แฟลชภายนอกบนกล้องรุ่นใหม่. กล้องที่เก็บภาพแอปพลิเคชันในแฟลชภายนอกจะวางภาพนั้นบนชิปที่มองเห็นได้ชัดเจนบน PCB ชิปสามารถถอดออกและอ่านโดยตรงด้วยเครื่องมือที่หาได้ทั่วไป หรืออ่านในตำแหน่งโดยการ probe บัส การป้องกันต้องการการเปิดใช้งานฮาร์ดแวร์ออนชิปที่ถอดรหัสเนื้อหาแฟลชระหว่างการอ่าน การสร้างคีย์เข้ารหัส การจัดเตรียมคีย์นั้นบนกล้อง และการเขียนแบบถาวรลงในหน่วยเก็บข้อมูลแบบโปรแกรมครั้งเดียวของ MCU แต่ละขั้นตอนเหล่านั้นเป็นการดำเนินการแบบครั้งเดียว และหากทำผิดพลาดบนหน่วยการผลิตจะทำให้หน่วยนั้นเสียหาย

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

ทำไมค่าเริ่มต้นจึงเปิด

รายการนี้ยังเป็นเหตุผลที่เฟิร์มแวร์ OpenMV มาตรฐานจัดส่ง โดยไม่มี การป้องกันการอ่านที่เปิดใช้งาน กล้องที่ปิด REPL ปิดการอัปโหลดสคริปต์ผ่าน IDE และล็อกเฟิร์มแวร์คือกล้องที่ไม่สามารถพัฒนาได้เลย เวิร์กโฟลว์ที่ทำให้ OpenMV Cam ใช้งานได้ในตอนแรกก็จะหายไป ค่าเริ่มต้นปล่อยให้ทุกอย่างเปิด ทีมผลิตภัณฑ์เลือกว่าจะปิดส่วนใดบ้างในระหว่างทางสู่หน่วยที่จัดส่ง

14.3.4.3. สิ่งที่การเข้าถึงทางกายภาพยังคงให้ได้

แม้จะมีการป้องกันการอ่านแฟลช ผู้โจมตีที่ถือกล้องยังสามารถทำได้อีกมาก:

• เล่นซ้ำการรับส่งข้อมูลเครือข่ายของกล้องโดยการ sniff ผลลัพธ์

• สังเกตพฤติกรรมที่มองเห็นได้และอนุมานว่ามันตอบสนองต่ออินพุตอย่างไร

• ในบางกรณี กู้คืนความลับผ่านการโจมตีแบบ fault-injection หรือ side-channel ที่เฉพาะเจาะจงกับ MCU ที่ได้รับการป้องกัน

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

14.3.4.4. สิ่งที่เฟิร์มแวร์ OpenMV จัดส่งพร้อม

สรุปเพื่อความชัดเจน:

• ไม่มีการป้องกันการอ่านที่เปิดใช้งานโดยค่าเริ่มต้น

• ไม่มี build flag ในเฟิร์มแวร์มาตรฐานที่เปิดใช้งาน

• ไม่มี API ระดับแอปพลิเคชันที่สามารถเรียกใช้จาก MicroPython

ผลิตภัณฑ์ที่ต้องการการป้องกันจัดส่งเฟิร์มแวร์ที่ปรับแต่งแล้ว การปรับแต่งนั้นอยู่ในบูตโหลดเดอร์ของบอร์ดและกระบวนการผลิต และอยู่นอกโค้ดเบส OpenMV ทีมที่ทำสิ่งนี้เป็นครั้งแรกควรวางแผนให้เป็นงานแยกต่างหากในไทม์ไลน์การพัฒนา ไม่ใช่เป็นสิ่งที่จะเพิ่มในตอนท้าย เพราะความไม่สามารถย้อนกลับได้ทำให้ "เพิ่มทีหลัง" มีราคาแพง