IoT 장치에서 기존 SSL / TLS 구현에 대한 보안 평가
기존 IoT 장치의 통신 보안에 대한 보안 평가를 수행하고 있습니다. 목표는 현재 설계 / 구현에서 보안 공백을 평가하고 찾는 것입니다.
평가 모드는 주로 기존 설계 및 코드를 참조하는 수동 방식입니다. 이것은 장치의 클라이언트 측에만 해당됩니다. 서버는 클라우드 기반 서버입니다. 장치는 GSM 모듈 (SIMCom SIM900)을 사용하고 있으며 GSM AT 명령을 사용하여 인터넷을 통해 서버에 HTTPS 통신을합니다.
SSL / TLS에 대한 이해를 바탕으로이 평가에 대한 다음 매개 변수 또는 기준을 고려하고 있습니다.
ㅏ. TLS 프로토콜 버전
비. 사용 된 암호 그룹
씨. 인증서 및 키 관리
디. 장치에 설치된 루트 CA
이자형. 장치 ID 관리를위한 임베디드 PKI 측면
에프. 하드웨어 암호화 측면 (SHE / TPM)
올바른 방법으로하고 있습니까? 위의 매개 변수 목록이 Device HW / SW 플랫폼에만 국한된 것은 아니라고 생각하지만; 다소 일반적인. 하지만 그렇게되어야한다고 생각합니다! 매개 변수 목록은 거의 동일합니다. 그러나 이에 대한 실제 평가는 보안 요구 사항 및 장치 공간 및 플랫폼 등과 같은 기타 측면에 따라 달라집니다.
내가 고려하고있는 평가 매개 변수 목록이 좋고 적절합니까?
답변
이것은 좋은 시작이지만 철저한 평가는 이것보다 훨씬 더 깊이 들어가야합니다. 예를 들면 :
클라이언트는 어떻게 난수를 생성합니까? CSPRNG를 사용합니까 ? 또는 Netscape Navigator의 초기 버전에서 사용 된 것과 같은 약한 난수 생성기를 사용합니까? 수동 공격자가 세션 키에 대해 생성 된 난수를 추측하여 네트워크를 통과하는 암호문을 해독 할 수있었습니다.
패딩 오류가 발생하면 클라이언트가 정보를 유출합니까? 그렇다면 Steam Gaming Client 의 경우처럼 패딩 오라클 공격에 취약 할 수 있습니다 .
클라이언트는 ECDSA를 어떻게 구현 합니까? 클라이언트가 생성하는 각 서명에 대해 새로운 랜덤 k 를 생성합니까? 그렇지 않은 경우 수동 공격자가 Sony Playstation 3 의 경우처럼 몇 가지 서명을 관찰 한 후 개인 서명 키를 계산할 수 있습니다 .
이것은 단지 몇 가지 예일뿐입니다. 그러나 보시다시피 암호화 구현에서 미묘한 실수는 비참한 결과를 초래할 수 있습니다. 이것이 암호화가 제대로되기 어려운 이유입니다.