14.4.6. Các thao tác: khóa, hết hạn và xử lý sự cố¶

Ba công việc liên quan đến chứng chỉ áp dụng cho mọi thiết bị đã triển khai: bảo vệ khóa riêng tư sau khi nó đã được lưu trên camera, lập kế hoạch cho ngày chứng chỉ hết hạn, và danh sách ngắn các chế độ lỗi thường gặp trong thực tế.

14.4.6.1. Bảo vệ khóa riêng tư¶

Bất cứ khi nào camera trình bày một chứng chỉ -- với tư cách là máy chủ TLS, hoặc là máy khách trong mTLS -- khóa riêng tư của nó phải tồn tại trên thiết bị, ở dạng DER thuần túy, trên hệ thống tệp hoặc trong ROMFS. Được lưu trữ theo cách đó, nó có thể được đọc bởi bất kỳ mã nào chạy trên camera và bởi bất kỳ ai có quyền truy cập vật lý: ổ đĩa USB mass-storage, dấu nhắc REPL, hoặc bộ nhớ flash thô. ROMFS và các cờ chỉ đọc ngăn chặn sửa đổi, không phải trích xuất. Hãy coi bất kỳ khóa riêng tư nào được nạp trên thiết bị là có thể phục hồi bởi kẻ tấn công có quyền truy cập vật lý hoặc mã nguồn.

Điều này không làm cho TLS trở nên vô nghĩa -- nó định hình cách bạn triển khai nó:

Sử dụng khóa và chứng chỉ duy nhất cho mỗi thiết bị. Không bao giờ nạp một khóa chung cho toàn bộ hệ thống: việc trích xuất nó từ một đơn vị sẽ cho phép kẻ tấn công mạo danh mọi camera. Khóa riêng cho từng thiết bị giới hạn sự xâm phạm vào chỉ thiết bị đó, mà bạn có thể thu hồi hoặc vô hiệu hóa ở phía máy chủ.
Giữ chứng chỉ có thời gian sống ngắn. Một khóa bị đánh cắp chỉ hữu ích khi chứng chỉ của nó còn hiệu lực; thời gian sống ngắn cùng với việc xoay vòng định kỳ sẽ giới hạn thiệt hại (xem Certificate expiry and rotation bên dưới).
Tránh đặt bí mật trên thiết bị nếu có thể. Nếu bạn chỉ cần xác minh máy chủ (xác thực máy chủ, không phải mTLS), camera với tư cách là máy khách chỉ lưu trữ chứng chỉ CA -- vốn là công khai -- và không giữ khóa riêng tư nào đáng bị đánh cắp.
Không bao giờ đưa khóa vào hình ảnh firmware công khai. Một khóa được nhúng vào ROMFS trong bản dựng firmware mà bạn phân phối không phải là bí mật; bất kỳ ai tải xuống firmware đều có nó. Việc cấp phát theo từng thiết bị có nghĩa là lập trình khóa sau khi cài firmware chung, không phải bên trong nó.
Giới hạn phạm vi ảnh hưởng. Giới hạn phạm vi xác thực của chứng chỉ (đặc quyền tối thiểu), và đảm bảo rằng một danh tính thiết bị bị rò rỉ có thể được thu hồi hoặc vô hiệu hóa mà không ảnh hưởng đến phần còn lại.

Nếu mô hình mối đe dọa của bạn bao gồm những kẻ tấn công có quyền truy cập vật lý, hãy thiết kế dựa trên giả định rằng khóa thiết bị cuối cùng sẽ bị rò rỉ và làm cho điều đó có thể chịu đựng được, thay vì giả định rằng nó có thể được giữ bí mật trên phần cứng không có cơ sở để làm như vậy.

14.4.6.2. Hết hạn và xoay vòng chứng chỉ¶

Mỗi chứng chỉ mang một khoảng thời gian hiệu lực. Khi nó qua đi, một peer ssl.CERT_REQUIRED sẽ từ chối kết nối -- vì vậy hết hạn là một sự cố ngừng hoạt động thực sự, có lịch trình, không phải rủi ro lý thuyết. Đồng hồ của camera cũng phải chính xác để kiểm tra tính hợp lệ được đánh giá trung thực.

Tự ký. Bạn đã chọn thời gian sống với -days. Khi nó hết hạn, bạn phải tạo lại khóa/chứng chỉ và triển khai lại: sao chép lại các tệp DER, hoặc xây dựng lại và nạp lại hình ảnh ROMFS nếu chứng chỉ được nhúng vào. Hãy chọn giá trị -days mà bạn thực sự sẽ nhớ để thực hiện.
CA công khai. Những loại này có chủ định có thời gian sống ngắn. Let's Encrypt cấp chứng chỉ 90 ngày và mong đợi gia hạn tự động khoảng mỗi 60 ngày; không có tùy chọn "cài một lần và quên".

Xu hướng rộng hơn là một chiều: thời gian hiệu lực tối đa của chứng chỉ TLS được tin cậy công khai tiếp tục thu hẹp. Nó đã là 825 ngày, hiện đang bị giới hạn ở 398 ngày, và CA/Browser Forum đã thông qua một lịch trình giảm dần xuống khoảng 47 ngày vào năm 2029. Bài học cho thiết kế thiết bị là giả định rằng chứng chỉ có thời gian sống ngắn và việc xoay vòng phải được tự động hóa hoặc ít nhất là thường xuyên -- không nên phát hành sản phẩm phụ thuộc vào việc con người thay thế chứng chỉ mười năm một lần.

Trên thực tế, trên camera: ưu tiên các thiết kế trong đó chứng chỉ có thể được thay thế mà không cần nạp lại firmware (hệ thống tệp có thể ghi cùng với đường dẫn cập nhật từ xa, hoặc chạy camera như một máy khách tin cậy vào CA mà bạn xoay vòng tập trung). Nếu chứng chỉ phải tồn tại trong ROMFS, hãy lên lịch cập nhật firmware xung quanh thời gian sống của nó.

14.4.6.3. Xử lý sự cố¶

Đồng hồ phải được đặt. Camera chưa đặt đồng hồ từ khi khởi động sẽ không vượt qua kiểm tra tính hợp lệ của chứng chỉ -- hãy gọi ntptime.settime() trước.
Tên máy chủ phải khớp. Khi máy khách truyền server_hostname, nó phải khớp với subjectAltName của chứng chỉ (hoặc CN trên các stack cũ hơn), nếu không xác minh sẽ thất bại.
Định dạng sai. Tệp PEM sao chép vào camera sẽ không tải được -- hãy chuyển đổi sang DER trước.
Chứng chỉ hết hạn. Kết nối đã hoạt động trước đây và bây giờ thất bại với OSError có thể đơn giản là do chứng chỉ hết hạn -- kiểm tra ngày hợp lệ và tạo lại/triển khai lại khi cần.
Khóa Ed25519 thất bại. Sử dụng ECDSA P-256/P-384 hoặc RSA, không phải Ed25519.
Lỗi là OSError. MicroPython không triển khai ssl.SSLError; các lỗi TLS (chứng chỉ xấu, hết hạn, CA không biết, lỗi định dạng, lỗi bắt tay) được đưa ra dưới dạng OSError.