앱과 IoT 장치 간의 통신을 어떻게 보호합니까?

현재 모바일 응용 프로그램 (현재 Ionic 플랫폼 사용)과 내장 장치 간의 Bluetooth 통신을 포함하는 프로젝트를 진행하고 있습니다. 비교를 위해 당사 제품은 스마트 잠금 장치 와 유사합니다 .

보안은 가장 중요하며 하드웨어와 소프트웨어를 해킹 할 수 없도록하는 방법을 모색하고 있습니다. 시스템 보안을 위해 어떤 조치를 취해야합니까?

편집 : 예, 현재 통신을 암호화하고 있으며 장치가 서버와 통신 할 때 HTTPS를 사용합니다.

security bluetooth mobile-applications

— 조엘 브루어
소스

HTTPS를 사용 하시겠습니까? 두 장치를 모두 코딩하고 있습니까? 암호화?

— Mawg는 모니카 복원

Consiedr은 또한 security.stackexchange.com에

— Mawg는 모니카가 복원

@Mawg 내가 아는 한 HTTPS는 블루투스에는 적용되지 않는다 (적어도 규범 적 / 정신적 인 의미는 아님).

— 금발 미녀

나는 이것이 IoT 고유의 방식을 보여주지 못하기 때문에이 질문을 주 제외로 닫으려고 투표하고 있습니다. 장치 간의 통신을 보호하는 것입니다.

— Helmar

@Helmar 기기 간 통신은 IoT의 매우 중요한 기능이며 정의 기능이기도하므로이 질문이 주제가 아닌 이유를 알 수 없습니다.

— Gilles 'SO- 악의를 멈춰라'

답변:

기기가 충분히 안전하도록 몇 가지 팁이 있습니다.

블루투스 통신에 암호화를 추가하십시오. 암호화 키를 사용하지 않는 것이 좋습니다. 예를 들어, 모바일 앱의 초기 설정에서 AES 키를 사용하여 기기에 있거나 상자에 인쇄 된 QR 코드를 스캔하도록 사용자에게 요청할 수 있습니까? 당신에게 달려 있습니다. 이것은 누군가가 일반 텍스트로 무선으로 전송 된 암호를 보지 못하게하기위한 것입니다.
가능하면 선택한 암호화 알고리즘의 ECB (CBC 사용) 모드에서 멀리 떨어져 전송 된 데이터에 대한 정보를 얻을 수 있습니다. 자세한 내용은 여기를 참조하십시오 .
블루투스 데이터 전송시 메시지를 반복 할 수 없도록 고유 한 ID를 포함해야합니다 (예 : 타임 스탬프 포함). TOTP와 유사한 시스템을 구현할 수도 있습니다.
쉽게 플래시 할 수있는 장치에 포트를 넣으십시오. 따라서 소프트웨어에 버그가 있음을 알게되면 (어떤 이유로 든 OTA를 업데이트 할 수 없음) 장치는 값 비싼 문진이 아니라 장치 일뿐입니다 PC에 연결하고 새 소프트웨어로 플래시해야합니다.
추가 : 불량 루트 인증서 (아마도 자체 발급되고 클라이언트 장치에 설치됨)를 가진 사람이 서버 통신을 가로 챌 수 없도록하려면 HTTPS 인증서를 확인하십시오. 여기에 안드로이드를 요구하는 SO가 있습니다 .iOS에 대해서도 비슷한 리소스를 찾을 수 있어야합니다 .

또한 암호화 및 암호화에 대한 자세한 내용을 보려면 장치를 보호하는 데 사용할 전자 책을 확인 하십시오 (무료) . 암호화 알고리즘의 좋고 나쁜 구현에 대해 많이 이야기하며 제품 보안에 도움이됩니다. (참고 1 : 자신의 알고리즘을 만들지 마십시오. 참고 2 : crypto101 또는 lvh와 관련이 없습니다.)

— 아베
소스

“가능한 경우 ECB를 멀리하십시오”. 아니, 나쁜 조언. 통과 할 수있는 조언은“절대 ECB를 사용하지 말라”지만 여전히 불완전합니다. 더 나은 대답은 문자 CBC를 코드에 입력하면 잘못하고 있다는 것 입니다. 특히 AES-CBC는 의사 소통의 완전성 또는 진정성을 보장하지 않습니다.

— Gilles 'SO- 악의

@Gilles ECB는 현재 평범한 텍스트 또는 단순히 설정된 값으로 xor로 물건을 전송하는 모든 iot 장치보다 확실히 낫습니다. 그러나 ECB는 제품을 "해킹 할 수 없습니다"(기술적으로는 아무것도하지 않습니다). 현재 가능한 한 오랫동안 최대한 안전하게 유지하고 ECB를 포함하지 않고 AES-CBC 256의 적절한 구현을 수행 할 수 있습니다).

— Ave

종단 간 TCP를 사용할 수있는 경우 종단 간 TLS (예 : HTTPS)를 사용하십시오.

특히 암호화와 관련하여 휠을 재발 명하지 마십시오. 대부분의 사람들이 잘못 알고 있습니다. 장치에 TLS를 지원하기에 리소스가 너무 많이 제한되어 있지 않은 경우 AES 수준으로 내려 가면 잘못 된 것 입니다. 실수는 암호화하고 인증을 잊는 것입니다. 서버와 장치 사이에 암호화 된 채널 대신 서버와 MITM (Man-in-the-Middle) 사이에 암호화 된 채널이있는 경우 암호화는 아무런 이점이 없습니다. . TLS를 사용할 수없는 경우 사용하는 프로토콜이 모두 인증 하고 기밀 정보를 암호화해야합니다.

TLS를 안전하게 사용하려면 각 참가자의 관점에서 필요한 것이 무엇인지 생각하십시오. 일반적으로 장치는 합법적 인 서버와 통신하고 있음을 알아야합니다. 즉, 서버의 인증서를 확인해야합니다. 장치에는 인증 기관의 X.509 인증서가 신뢰할 수있는 것으로 기록되어 있어야합니다. 이를 위해서는 공격자가 수정할 수없는 저장소가 필요하지만 저장소의 기밀성이 필요하지 않습니다. 서버 인증서를 직접 하드 코딩해서는 안됩니다. 손상된 경우 해당 인증서를 쉽게 교체 할 수 없기 때문입니다. 대신, 장치는 예상 ID를 저장합니다서버의 (호스트 이름) 및 특정 공개 키가 예상 호스트 이름에 속하는지 확인하는 인증 기관의 인증서. 다시 한 번 휠을 다시 만들지 말고 TLS 라이브러리 또는 응용 프로그램에서 제공 한 인증서 확인에 의존하십시오.

서버가 합법적 인 클라이언트와 통신하고 있음을 알아야하는 경우 각 클라이언트에는 자체 클라이언트 인증서가 있어야합니다. 이를 위해서는 클라이언트에 기밀 저장소가 필요합니다. 클라이언트 인증서를 TLS 라이브러리에서 TLS 세션 열기 기능으로 전달하거나 애플리케이션 구성에서 설정하십시오.

서버와 장치 간의 통신을 보호합니다. 모바일 응용 프로그램이 장치와 직접 통신 할 수있는 경우 (예 : 로컬 Wi-Fi 네트워크에있는 동안 연결이 끊긴 경우) 스마트 스위치와 휴대폰간에 페어링을 수행해야합니다. 페어링은 키 교환, 바람직하게는 리소스가 허용하는 경우 공개 키 교환, 그렇지 않으면 비밀 키의 동의를 의미합니다. 이 페어링의 목표는 각 장치가 대화하는 사람을 알 수 있도록하는 것입니다.

모바일 장치에서 스마트 스위치로 또는 서버를 통해 직접 이동하는지 여부에 관계없이 제어 채널도 보호해야합니다. 권한 부여에 대해 생각해보십시오. 스위치에 대한 액세스 수준이 다릅니 까 (예 : 재구성을 허용하는 제어 레벨과 온 / 오프 스위칭 만 허용하는 기본 채널)? 이는 일반적으로 보안 채널 (가능한 경우 TLS)을 설정 한 후 인증 단계에 의해 처리됩니다.

다른 고려 사항은 펌웨어 업데이트입니다. 그것은 까다로운 일입니다. 한편으로는 절대적인 보안과 같은 것은 없기 때문에 지금 적용 할 보안 패치가 있습니다. 반면, 펌웨어 업그레이드 메커니즘은 복잡한 것이며 자체 버그가있을 수 있습니다. 최소한 펌웨어 업그레이드에 서명해야합니다. 보안 채널에 대한 트러스트는 정적 보안 확인보다 크며, 때로는 네트워크 연결없이 펌웨어 업데이트를 적용 할 수 있기 때문에 업그레이드를 위해 통신 채널의 보안에만 의존하는 것은 까다 롭습니다. 서명을 확인하는 것 외에도 이상적으로는 롤백에 대한 보호 기능을 갖추어야합니다.

— 질 'SO- 악마 그만해'
소스