제한된 임베디드 시스템 간의 통신 보안
현재 임베디드 시스템에서 제한된 물리적 통신 채널을 통해 통신을 강화하려고합니다.
시나리오
이 시스템은 소형 임베디드 애플리케이션에 대해 다소 일반적이라고 생각합니다.
관련 임베디드 시스템은 OS가없는 소형 마이크로 컨트롤러로, 안전한 물리적 환경에 있다고 가정 할 수 있습니다. 연결 채널은 공격자가 물리적으로 액세스 할 수 있으며 원하는대로 메시지를 방해 할 수 있습니다.
다른 통신 채널이 가능합니다 : 예 : RS485 또는 RS232. 우리가 구축 할 수있는 주소 지정 및 조잡한 무결성 (예 : 비트 플립의 경우 CRC16)과 같은 것들을 처리하는 조잡한 프로토콜이 있습니다. 느린 TCP라고 생각하십시오.
각 통신 파트너는 CA 역할을 할 수 있고 서명 된 고유 한 인증서 (+ 키)가있는 루트 인증서를 알고 있습니다. 인증서는 자체 서명 된 타원 곡선 prime256v1입니다.
mbedTLS 라이브러리는 이러한 시스템에서 사용할 수 있습니다 (DH, AES, .. 포함).
대부분의 경우 인터넷을 사용할 수 없습니다.
시스템은 시간을 유지하고 충분한 난수를 생성 할 수 있습니다.
나는 프라이버시, 진정성 및 무결성에 도달하고 싶습니다.
해결 방법
암호화 프로토콜의 규칙은 절대 스스로 구현하지 않는 것입니다. 불행히도이 사용 사례와 일치하는 것을 찾지 못했습니다.
나는 또한 기존 질문을 탐색했지만 내가 찾고 있던 완전한 솔루션을 제공하지 못했습니다.
마지막 으로이 답변 에서 자체 프로토콜을 구현하는 것이 마지막 옵션으로 제공됩니다.
이것이 제가 아래에 설명 된 해결책을 생각 해낸 이유입니다.하지만 그것에 대해 완전히 확신하지는 않습니다. 나는 Diffie-Hellmann Key Exchange를 인증하는 방법 에 대한 이 답변 , 무결성을 확인하는 방법에 대한이 답변 및 이러한 프로토콜을 구현하는 방법에 대한 몇 가지 아이디어를 제공하는이 스레드를 지향했습니다 .
통신 보안 프로토콜
가장 먼저 할 일은 대칭 키 K를 무작위로 생성하는 것입니다. 가장 먼저 전송되는 것은 핸드 셰이크 메시지입니다. 다음 필드가 있습니다.
| 들 | 기술 |
|---|---|
| DH | Diffie-Hellmann 키 교환 메시지 g K |
| 인증서 | 전송 장치의 인증서 (체인) |
| MsgIdNonce | 임의의 64 비트 값 |
| 서명 | Cert의 개인 키를 사용하는 전체 메시지의 서명 |
두 장치 모두 이러한 메시지를 보내고받습니다.
메시지가 수신되면 다음이 수행됩니다.
- 인증서가 예상 CA에서 서명되었는지 확인합니다 (체인에 있어야 함).
- msg가 cert 및 해당 키로 올바르게 서명되었는지 확인하십시오.
이러한 검사가 성공하면 전송 및 수신 된 DH g K 메시지가 대칭 키를 계산하는 데 사용됩니다.
이 시점부터 애플리케이션은 AES-CBC로 암호화 된 메시지를 보낼 수 있습니다. 메시지가 비교적 자주 손실 될 수 있으므로 IV는 항상 메시지에 있습니다.
다음은 메시지 형식입니다.
| 들 | 기술 | 암호화 됨 |
|---|---|---|
| IV | AES에 대한 초기 무작위 IV | 아니 |
| MsgIdNonce | 핸드 셰이크 / 마지막 MsgIdNonce + 1 또는 + 2 | 예 |
| 응용 데이터 | 보호 할 데이터 / 명령 | 예 |
| 64 비트로 잘린 CMAC | 무결성 검사를위한 MAC | 예 |
메시지를 수락하려면
- 예상되는 MsgIdNonce (마지막으로받은 것보다 1 개 또는 2 개 이상)-재생 공격 방지, 1 개의 메시지 손실 허용
- 유효한 CMAC 보유-무결성 공격 방지
- 최대 수신됩니다. 마지막 메시지 후 T 초-지연 공격 방지
예상과 다른 것이 있으면 Handshake가 다시 전송되고 새로 교환 된 매개 변수로 메시지가 다시 전송됩니다.
질문
내가 올바른 길을 가고 있는가 아니면 완전히 다른 것을 시도해야합니까?
이것이 내 보안 목표를 제공합니까 아니면 여기서 명백한 취약점을 놓치고 있습니까?
작동 할 수 있습니까?
저와 비슷한 문제에 직면 한 다른 임베디드 엔지니어를 도울 수 있기를 바랍니다!
답변
암호화 프로토콜의 규칙은 절대 스스로 구현하지 않는 것입니다. 불행히도이 사용 사례와 일치하는 것을 찾지 못했습니다.
DTLS 를 고려해 보셨습니까 ? 이는 동일한 문제 (타임 스탬프 제외, 데이터 그램에 타임 스탬프를 삽입하여 추가 할 수 있음)를 해결하려고 시도하며 이미 고려한 사항이 있습니다. 또 다른 가능성은 IPsec입니다. 그러나 DTLS는 문제를 해결하는 데 더 가까워 보입니다 (보호하는 데이터 트래픽이 IP 트래픽이 아닌 경우).
즉, 다음은 귀하가 설명한 프로토콜에 대한 몇 가지 생각입니다.
두 개의 순차적 메시지가 삭제되면 (예 : 잘못 수신 된 경우) 어떻게됩니까? 양측은 무슨 일이 일어 났는지 깨닫게 될까요, 아니면 모든 후속 메시지를 계속 삭제할까요? ( 'nonce는 2 개 이하로 증가하면 안됩니다'규칙 때문에)?
재키를 시도한다고 가정하면 어떻게 조정됩니까? 한 쪽이 아직 키를 다시 입력하지 않았다고 생각하고 다른 쪽이 키를 다시 입력했다고 생각하면 이전 키로 암호화 된 메시지는 어떻게됩니까? 암호문 (DTLS에서는 'epoch')과 함께 '어떤 키가 암호화되는지'태그를 포함하는 것이 일반적으로 유용합니다.
커뮤니케이션 채널에서 메시지 순서를 변경할 수 있습니까? 귀하의 경우에는 불가능하다고 생각하지만 가능하다면 어떻게 처리해야하는지 생각해야합니다.
누군가 이전 (유효한) 핸드 셰이크 메시지를 삽입하면 어떻게됩니까? 그게 어떻게 혼란 스러울까요?
데이터 암호화 경로에서 CBC 암호화 및 CMAC 무결성을 사용합니다. 이것이 실행 가능한 솔루션이지만 올바르게 통합되지 않으면 다양한 패딩 공격이 발생하기 쉽습니다. 현재 유행은 AEAD 모드 (예 : GCM 또는 Chacha20 / Poly1305)를 사용하는 것입니다.
암호화 된 트래픽이 단방향입니까 아니면 양방향입니까? 트래픽이 양방향으로 이동하는 경우 동일한 키 세트를 사용하여 두 트래픽 세트를 보호합니까?
"예상과 다른 것이 있으면 Handshake가 다시 전송되고 새로 교환 된 매개 변수로 메시지가 다시 전송됩니다." -어떻게 작동합니까? 수신자가 메시지가 마음에 들지 않는다고 결정한 경우 발신자는 메시지를 다시 보낼지 어떻게 알 수 있습니까?