14.4.6. การดำเนินการ: คีย์ การหมดอายุ และการแก้ปัญหา

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

14.4.6.1. การปกป้องคีย์ส่วนตัว

ทุกครั้งที่กล้อง นำเสนอ ใบรับรอง -- ในฐานะเซิร์ฟเวอร์ TLS หรือในฐานะไคลเอนต์ใน mTLS -- คีย์ส่วนตัวของมันต้องอยู่บนอุปกรณ์ในรูปแบบ DER ธรรมดา บนระบบไฟล์หรือใน ROMFS การจัดเก็บในลักษณะนี้ทำให้โค้ดใด ๆ ที่รันบนกล้องและทุกคนที่มีการเข้าถึงทางกายภาพสามารถอ่านได้ ไม่ว่าจะผ่าน USB mass-storage drive, REPL prompt หรือ raw flash ROMFS และ read-only flags ป้องกัน การแก้ไข ไม่ใช่ การดึงข้อมูล ถือว่าคีย์ส่วนตัวที่ติดตั้งบนอุปกรณ์สามารถกู้คืนได้โดยผู้โจมตีที่มุ่งมั่นซึ่งมีการเข้าถึงทางกายภาพหรือโค้ด

สิ่งนี้ไม่ได้ทำให้ TLS ไม่มีประโยชน์ -- มันกำหนดวิธีการติดตั้งใช้งาน:

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

• รักษาอายุใบรับรองให้สั้น คีย์ที่ถูกขโมยมีประโยชน์ต่อเมื่อใบรับรองยังมีผลบังคับใช้อยู่ อายุสั้นบวกกับการหมุนเวียนตามปกติจะจำกัดความเสียหาย (ดู Certificate expiry and rotation ด้านล่าง)

• หลีกเลี่ยงการเก็บข้อมูลลับบนอุปกรณ์เมื่อทำได้ หากคุณต้องการตรวจสอบเฉพาะ เซิร์ฟเวอร์ (การพิสูจน์ตัวตนเซิร์ฟเวอร์ ไม่ใช่ mTLS) กล้องในฐานะไคลเอนต์จะจัดเก็บเฉพาะใบรับรอง CA -- ซึ่งเป็นสาธารณะ -- และไม่มีคีย์ส่วนตัวที่ควรค่าแก่การขโมย

• อย่าใส่คีย์ใน firmware image สาธารณะ คีย์ที่ฝังอยู่ใน ROMFS ใน firmware build ที่คุณแจกจ่ายไม่ใช่ข้อมูลลับ ใครก็ตามที่ดาวน์โหลด firmware ก็มีมันด้วย การจัดเตรียมต่ออุปกรณ์หมายถึงการโปรแกรมคีย์ หลังจาก firmware ทั่วไป ไม่ใช่ภายในมัน

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

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

14.4.6.2. การหมดอายุและการหมุนเวียนใบรับรอง

ใบรับรองทุกใบมีช่วงความถูกต้อง เมื่อผ่านไปแล้ว peer ที่ใช้ ssl.CERT_REQUIRED จะปฏิเสธการเชื่อมต่อ -- ดังนั้นการหมดอายุจึงเป็นการหยุดทำงานที่แท้จริงและมีกำหนดการ ไม่ใช่ความเสี่ยงเชิงทฤษฎี นาฬิกาของกล้องต้องถูกต้องด้วยเพื่อให้การตรวจสอบความถูกต้องถูกประเมินอย่างซื่อสัตย์

• Self-signed คุณเลือกอายุด้วย -days เมื่อหมดอายุคุณต้องสร้างคีย์/ใบรับรองใหม่และ redeploy: คัดลอกไฟล์ DER ใหม่ หรือสร้างและ reflash ROMFS image ใหม่หากใบรับรองถูกฝังไว้ เลือกค่า -days ที่คุณจะจำได้จริง ๆ

• Public CA ใบรับรองเหล่านี้จงใจมีอายุสั้น Let's Encrypt ออกใบรับรอง 90 วันและคาดหวังการต่ออายุอัตโนมัติประมาณทุก 60 วัน ไม่มีตัวเลือก "ติดตั้งครั้งเดียวแล้วลืม"

แนวโน้มที่กว้างขึ้นนั้นเป็นทิศทางเดียว: อายุสูงสุดของใบรับรอง TLS ที่น่าเชื่อถือสาธารณะยังคงลดลงอย่างต่อเนื่อง เคยเป็น 825 วัน ปัจจุบันถูกจำกัดที่ 398 วัน และ CA/Browser Forum ได้กำหนดตารางเวลาที่จะลดลงเหลือประมาณ 47 วันภายในปี 2029 บทเรียนสำหรับการออกแบบอุปกรณ์คือสมมติว่าใบรับรองมีอายุสั้นและการหมุนเวียนต้องเป็นแบบอัตโนมัติหรืออย่างน้อยต้องเป็นประจำ -- อย่าส่งมอบผลิตภัณฑ์ที่ต้องพึ่งพามนุษย์ในการเปลี่ยนใบรับรองสิบปี

ในทางปฏิบัติบนกล้อง: ให้ความสำคัญกับการออกแบบที่ใบรับรองสามารถแทนที่ได้โดยไม่ต้อง reflash (ระบบไฟล์ที่เขียนได้บวกกับเส้นทางการอัปเดตระยะไกล หรือการรันกล้องเป็น ไคลเอนต์ ที่เชื่อถือ CA ที่คุณหมุนเวียนจากส่วนกลาง) หากใบรับรองต้องอยู่ใน ROMFS ให้กำหนดตารางการอัปเดต firmware ตามอายุของมัน

14.4.6.3. การแก้ปัญหา

• ต้องตั้งนาฬิกา กล้องที่ยังไม่ได้ตั้งนาฬิกาหลังจากเปิดเครื่องจะล้มเหลวในการตรวจสอบความถูกต้องของใบรับรอง -- เรียก ntptime.settime() ก่อน

• ชื่อโฮสต์ต้องตรงกัน เมื่อไคลเอนต์ส่ง server_hostname ต้องตรงกับ subjectAltName ของใบรับรอง (หรือ CN บน stacks เก่า) มิฉะนั้นการตรวจสอบจะล้มเหลว

• รูปแบบผิด ไฟล์ PEM ที่คัดลอกไปยังกล้องจะโหลดไม่ได้ -- แปลงเป็น DER ก่อน

• ใบรับรองหมดอายุ การเชื่อมต่อที่เคยทำงานได้และตอนนี้ล้มเหลวด้วย OSError อาจเป็นเพียงเพราะใบรับรองหมดอายุ -- ตรวจสอบวันที่ความถูกต้องและสร้าง/deploy ใหม่ตามต้องการ

• คีย์ Ed25519 ล้มเหลว ใช้ ECDSA P-256/P-384 หรือ RSA ไม่ใช่ Ed25519

• ข้อผิดพลาดคือ OSError MicroPython ไม่ได้ implement ssl.SSLError; ความล้มเหลวของ TLS (ใบรับรองผิด หมดอายุ CA ไม่รู้จัก ข้อผิดพลาดรูปแบบ ความล้มเหลวของ handshake) จะถูก raise เป็น OSError