14.4.6. 운영: 키, 만료, 그리고 문제 해결

배포된 모든 장치에는 세 가지 인증서 관련 작업이 걸쳐 있습니다. 카메라에 올라간 개인 키를 보호하는 일, 인증서가 만료되는 날을 대비해 계획을 세우는 일, 그리고 실제로 나타나는 짧은 오류 유형 목록입니다.

14.4.6.1. 개인 키 보호

카메라가 인증서를 제시할 때마다 – TLS 서버로서, 또는 mTLS의 클라이언트로서 – 그 개인 키는 평문 DER 형식으로 파일 시스템이나 ROMFS의 장치 위에 존재해야 합니다. 그렇게 저장되면 카메라에서 실행되는 모든 코드와 카메라에 물리적으로 접근할 수 있는 누구나 – USB 대용량 저장 드라이브, REPL 프롬프트, 또는 원시 플래시를 통해 – 그 키를 읽을 수 있습니다. ROMFS와 읽기 전용 플래그는 수정은 막지만 추출은 막지 못합니다. 장치에 탑재된 개인 키는 물리적 또는 코드 접근 권한을 가진 끈질긴 공격자에게 복구될 수 있다고 간주하십시오.

이것이 TLS를 무의미하게 만들지는 않습니다 – 다만 어떻게 배포할지를 결정짓습니다:

  • 장치마다 고유한 키와 인증서를 사용하십시오. 하나의 공유 키를 전체 기기군에 플래시하지 마십시오. 단일 기기에서 키를 추출하면 공격자가 모든 카메라를 사칭할 수 있게 됩니다. 장치별 키는 침해를 해당 한 장치로 제한하며, 그 장치는 서버 측에서 폐기하거나 비활성화할 수 있습니다.

  • 인증서의 수명을 짧게 유지하십시오. 탈취된 키는 그 인증서가 유효한 동안에만 유용합니다. 짧은 수명에 정기적인 교체를 더하면 피해를 제한할 수 있습니다(아래의 Certificate expiry and rotation 참조).

  • 가능하다면 장치에 비밀 정보를 아예 두지 마십시오. 서버만 검증하면 되는 경우(mTLS가 아닌 서버 인증)라면, 클라이언트인 카메라는 공개되어 있는 CA 인증서만 저장하며 훔칠 만한 개인 키를 가지지 않습니다.

  • 공개 펌웨어 이미지에 키를 절대 탑재하지 마십시오. 배포하는 펌웨어 빌드의 ROMFS에 구워 넣은 키는 비밀이 아닙니다. 그 펌웨어를 내려받는 누구나 그 키를 가지게 됩니다. 장치별 프로비저닝이란 키를 일반 펌웨어 안이 아니라 그 이후에 프로그래밍하는 것을 의미합니다.

  • 피해 범위를 제한하십시오. 인증서가 인증하는 대상의 권한 범위를 최소화하고(최소 권한 원칙), 유출된 단일 장치 신원을 나머지에 영향을 주지 않고 폐기하거나 비활성화할 수 있도록 하십시오.

위협 모델에 물리적 접근이 가능한 공격자가 포함된다면, 장치 키가 결국 유출될 것이라는 가정 위에서 설계하고 이를 견딜 수 있게 만드십시오. 비밀을 지킬 수단이 없는 하드웨어 위에서 키를 비밀로 유지할 수 있다고 가정하지 마십시오.

14.4.6.2. 인증서 만료와 교체

모든 인증서에는 유효 기간이 담겨 있습니다. 이 기간이 지나면 ssl.CERT_REQUIRED 피어가 연결을 거부합니다 – 따라서 만료는 이론적 위험이 아니라 실제로 예정된 서비스 중단입니다. 유효성 검사를 정확하게 평가하려면 카메라의 시계도 올바르게 설정되어 있어야 합니다.

  • 자체 서명. 수명은 -days로 직접 정합니다. 기간이 지나면 키/인증서를 다시 생성하고 재배포해야 합니다. DER 파일을 다시 복사하거나, 인증서가 구워 넣어진 경우 ROMFS 이미지를 다시 빌드하여 다시 플래시하십시오. 실제로 잊지 않고 조치할 수 있는 -days 값을 선택하십시오.

  • 공개 CA. 이들은 의도적으로 수명이 짧습니다. Let’s Encrypt는 90일짜리 인증서를 발급하며 대략 60일마다 자동 갱신을 기대합니다. “한 번 설치하고 잊어버리는” 선택지는 없습니다.

더 큰 추세는 한 방향입니다. 공개적으로 신뢰되는 TLS 인증서의 최대 유효 기간은 계속 줄어들고 있습니다. 한때 825일이었고, 현재는 398일로 제한되며, CA/Browser Forum은 2029년까지 약 47일 수준으로 단계적으로 줄여나가는 일정을 채택했습니다. 장치 설계에서 얻을 교훈은 인증서가 수명이 짧다고 가정하고 교체가 자동화되거나 적어도 일상적으로 이루어져야 한다고 보는 것입니다 – 사람이 10년짜리 인증서를 교체하는 데 의존하는 제품을 출시하지 마십시오.

실질적으로 카메라에서는 재플래시 없이 인증서를 교체할 수 있는 설계를 선호하십시오(쓰기 가능한 파일 시스템과 원격 업데이트 경로를 함께 두거나, 중앙에서 교체하는 CA를 신뢰하는 클라이언트로 카메라를 운영). 인증서가 반드시 ROMFS에 존재해야 한다면 그 수명에 맞추어 펌웨어 업데이트를 예약하십시오.

14.4.6.3. 문제 해결

  • 시계가 설정되어 있어야 합니다. 전원을 켠 이후 시계를 설정하지 않은 카메라는 인증서 유효성 검사에 실패합니다 – 먼저 ntptime.settime()를 호출하십시오.

  • 호스트 이름이 일치해야 합니다. 클라이언트가 server_hostname를 전달할 때 그 값은 인증서의 subjectAltName(또는 오래된 스택에서는 CN)과 일치해야 하며, 그렇지 않으면 검증이 실패합니다.

  • 잘못된 형식. 카메라에 복사한 PEM 파일은 로드되지 않습니다 – 먼저 DER로 변환하십시오.

  • 인증서 만료. 이전에는 동작했으나 이제 OSError로 실패하는 연결은 단순히 인증서가 만료된 것일 수 있습니다 – 유효 기간을 확인하고 필요에 따라 재생성/재배포하십시오.

  • Ed25519 키는 실패합니다. Ed25519가 아니라 ECDSA P-256/P-384 또는 RSA를 사용하십시오.

  • 오류는 OSError입니다. MicroPython은 ssl.SSLError를 구현하지 않습니다. TLS 실패(잘못된 인증서, 만료, 알 수 없는 CA, 형식 오류, 핸드셰이크 실패)는 OSError로 발생합니다.