외부 메모리에 인증서를 보관하는 것은 나쁜 습관입니까?

우리는 STM32 마이크로 컨트롤러를 사용하여 AWS-IoT를 연구하고 있습니다.

오늘까지 우리는 인증서를 플래시에 쓰고 외부 판독 값에서 플래시를 잠그고있었습니다. 애플리케이션 코드가 증가함에 따라 플래시 공간이 줄어들어 인증서를 SD 카드 / EEPROM에서 외부로 이동하고 필요할 때마다 읽을 때 AWS-IoT에 연결하려고했습니다.

노트:

• 해당 정책은 특정 이름의 장치 만 해당 특정 인증서에 연결할 수 있도록합니다.

• 사물은 2 개의 채널 (이름과 데이터 피드 채널)에만 게시 할 수 있으며 데이터 채널은 데이터 프로세서에 연결되어 악의적 인 패킷이 들어오는 것을 무시합니다.

• 사물이 다른 주제를 게시 / 구독하는 경우 AWS는 사물을 즉시 연결 해제합니다.

장치가 도난 당했음을 감지하면 서버에서 키를 비활성화합니다.

익스플로 터는 인증서 (RootCA, 서버 키, 클라이언트 키)로 무엇을 할 수 있습니까?

익스플로러가 액세스 할 수있는 외부 저장소에 이러한 사용 사례에 대한 인증서를 보관하는 것은 좋지 않습니까?

당신은“인증서”를 언급하지만, 문맥 상 두 가지 다른 것을 언급하고 있다고 생각합니다.

• 장치에는 이 장치에 고유하고 장치 외부에 알려지지 않은 개인 키가 있습니다. 이 키는 장치를 식별합니다. 해당 키에 액세스 할 수있는 사람은 누구나 장치를 가장 할 수 있습니다. 그것은 그들이 특히 할 수 있음을 의미합니다.

  • 장치가 합법적으로 게시 할 권한이있는 채널에 유효하지만 잘못된 데이터를 게시합니다.
  • 합법적 인 장치가 금지되는 유효하지 않은 데이터를 게시하십시오.
  • 사용 사례에 따라 장치 소유자의 일부 개인 정보가 노출 될 수 있습니다.

  이 개인 키는 기밀로 유지하는 것이 좋습니다.

• 장치에는 적어도 하나의 공개 키 가있을 수 있으며 ,이를 통해 어떤 서버와 통신하고 있는지 인식 할 수 있습니다. 누구나이 키를 읽을 수 있다면 괜찮습니다. 공개입니다. 그러나 공격자는 키를 수정할 수 없어야합니다. 그렇지 않으면 장치와 통신하고 서버를 가장 할 수 있습니다. 이를 통해 다음과 같은 작업을 수행 할 수 있습니다.

  • 펌웨어 업데이트를 장치에 푸시하십시오.
  • 구성 업데이트를 장치로 푸시하십시오.
  • 장치가 다른 위치에 데이터를 업로드하도록합니다.

좋은 소식은이 위협 분석이 실제로는 관련이 없다는 것입니다. 보안을 희생 할 필요는 없습니다 ! (적어도 기밀성 및 인증 속성이 아닙니다. 외부에 물건을 저장하는 경우 시스템이 없어 질 수 있기 때문에 가용성이 떨어집니다.)

최소한 한 번은 쓸 수있는 128 비트의 스토리지가 있고 그 이상인 경우 안전한 원격 스토리지 솔루션을 구현할 수 있습니다. 제한된 공간 온 디바이스 스토리지를 사용하여 비밀 키를 저장하십시오. 이 비밀 키는 장치마다 고유해야합니다. STM32에는 하드웨어 RNG가 있으므로 처음 부팅하는 동안 장치에서 생성 할 수 있습니다. 장치에 하드웨어 RNG가없는 경우 안전한 오프 장치 위치에서 키를 생성하여 장치에 주입 할 수 있습니다.

이 키를 사용 하면 장치에서 저장 한 항목에 인증 된 암호화 를 사용 하십시오. 외부 저장소에서 일부 데이터를 읽으려면 데이터를로드하고 암호를 해독 한 후 확인하십시오. 일부 데이터를 외부 저장소에 쓰려면 암호화하고 서명하십시오. 이를 통해 데이터가 내부 저장소의 데이터만큼 기밀이 보장됩니다.

인증 된 암호화는 기밀성과 보장하기에 충분 인증 데이터를하지만, 아주의 보증하지 않습니다 무결성을 .

• 데이터 청크가 두 개 이상인 경우 장치가 데이터 청크를 다시 읽을 때 이것이 올바른 청크인지 확신 할 수 없습니다. 해결 방법 : (예 중 하나를 사용하여 각 청크를 시작 각 청크의 내용에 고유 한 식별자를 포함 "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• 어느 시점에서 데이터를 업데이트하면 다시 읽을 때 해당 데이터의 최신 버전을 받고 있는지 확인할 수 없습니다. 외부 저장소를 수정할 수있는 사용자는 가짜 검사를 수행 할 수 없기 때문에 정품 확인에 실패 할 수 있지만 정통이었던 것이 여전히 정품이기 때문에 오래된 데이터를 복원 할 수 있습니다. 솔루션 : 외부에 저장된 각 데이터 청크에 해당 청크의 새 버전을 작성할 때마다 증가하는 카운터를 포함하십시오. 청크를 다시 읽으면 예상 버전인지 확인하십시오.

내부 저장소에 공간이있는 제한된 공간에서 외부 저장소가 손상되거나 손실 된 경우 장치를 브릭 킹하지 않으려면 장치를 "좋은"상태 (예 : 공장 초기화)로 재설정하는 데 필요한 모든 것을 우선적으로 고려해야합니다. . 두 번째 우선 순위는 성능 고려 사항입니다.

약간의 맥락

AWS IoT에서 MQTT 를 사용하고 있으므로 인증 및 보안 을 위해 X.509 인증서를 사용해야 합니다. Amazon은 인증서 보안 방법에 대한 약간의 지침을 제공 하므로 여기에 인용하겠습니다.

인증서를 사용하면 비대칭 키를 장치와 함께 사용할 수 있습니다. 즉, 민감한 암호화 자료가 장치를 떠나지 않도록하면서 개인 키를 장치의 안전한 저장소에 구울 수 있습니다.

현재 STM32의 RDP ( 읽기 방지)를 사용하고 있기 때문에 가장 결정적인 공격자를 제외한 모든 공격자가 현재 체계에서 인증서에 액세스하는 데 문제가 있습니다.

글로벌 읽기 출력 보호 기능을 사용하면 내장 된 펌웨어 코드 (플래시 메모리에 사전로드 됨)를 통해 리버스 엔지니어링, 디버그 도구 또는 기타 침입 공격 수단을 사용하여 덤핑을 방지 할 수 있습니다.

• 레벨 0-보호 없음 (기본값)
• 레벨 1-플래시 메모리는 RAM로드 코드에 의한 디버깅 또는 코드 덤프에 의한 판독으로부터 보호됩니다
• 레벨 2-모든 디버그 기능이 사용 불가능합니다

외부 저장소가 안전합니까?

아마 아닙니다 으로 보안 . 클라이언트의 개인 키를 도난당한 경우 공격자는 실제로 장치에없는 데이터를 장치에서 보낸 것처럼 보낼 수 있습니다. 어떤 데이터를 전송하는지는 확실하지 않지만 신뢰할 수없는 데이터는 보안 위험이 될 수 있습니다.

어떤 비트를 비공개로 유지해야합니까?

AWS IoT에서 디바이스 인증서를 생성하면 다음과 같은 이미지가 표시됩니다.

^{AWS IoT 설명서의 디바이스 인증서 생성 및 활성화 페이지의 이미지 .}

개인 키는 당신이 정말로 비공개 로 유지 해야하는 것입니다. 가능한 경우 읽기 보호 된 메모리에 확실히 저장해야합니다. 공개 키와 인증서는 공유되도록 설계되었으므로 공간이 부족하면 안전하게 외부 저장소로 옮길 수 있습니다. SSL / TLS는 어떻게 작동합니까? 페이지에서 좀 더 많은 내용을 얻을 수 있습니다 . Wikipedia의 Information Security Stack Exchange 및 공개 키 암호화 개인 키가 비밀이되어야 하는 이유 를 설명하기 위해이 이미지를 포함시키지 않으면 나는 당신에게 장애를 겪고 있다고 생각 합니다.

.

^{공개적으로 공개 된 Wikipedia의 이미지 .}

디바이스의 퍼블릭 키 는 AWS IoT가 디바이스에 전송하기 위해 메시지에 서명하는 데 사용하는 것입니다 (단, 메시지를 보내는 사람을 증명하지는 않습니다 ). 따라서 비밀 키가 아니기 때문에 누군가 공개 키를 훔치는 것이 큰 재앙이 아닙니다.

개인 키는 공격자가이 훔치는 경우가 약간 더 큰 문제는 그래서 당신의 장치가 사용하는 메시지를 해독하는 것입니다.

또한 공격자가 RootCA 인증서를 훔친 경우 어떻게되는지 물었습니다. 누군가 AWS IoT의 개인 키를 훔친 경우 재앙이 될 수 있지만 디바이스의 RootCA 인증서 는 그렇지 않습니다 . RootCA.crt그 아마존은 당신이 줄 을 완전히 공개 하고, 목적은 당신이 (대부분 중간자 AWS의 IoT의 서버 척) 어떤 방법으로 공격을 받고하지 않는 것을 확인할 수 있도록합니다.

해킹 된 장치는 어떤 피해를 입을 수 있습니까?

도난당한 장치는 정책에 나열된 작업 만 수행 할 수 있습니다 . 최소한의 특권 원칙 을 따르십시오 . 기기에 절대적으로 필요한 권한 만 부여 하면 최악의 상황이 발생할 경우 너무 큰 혼란을 겪을 수 없습니다. 구체적인 경우 :

사물은 2 개의 채널 (이름과 데이터 피드 채널)에만 게시 할 수 있으며 데이터 채널은 데이터 프로세서에 연결되어 악의적 인 패킷이 들어오는 것을 무시합니다.

잘 됐네요 모든 공격은 디바이스가 공개 할 수있는 두 개의 MQTT 주제로 분리되어야하므로 대규모 피해를 유발하지 않습니다.

이상적으로는 전체 시스템이 단일 장치를 해부하면 일반적으로 시스템이 아닌 해당 장치 만 깨지도록 설계해야합니다.

특히 칩간에 표준 전기 인터페이스를 통과하도록 키를 별도의 메모리에 저장하는 경우 이미 게시하기에 안전하거나 장치의 특정 물리적 인스턴스에 고유 한 키 여야합니다.

단일 장치에서 개별 키를 추출하여 여러 무단 복제본에서 발생하는 트래픽 양에 남용되거나 표시되기 시작하면 서버 측에서 해당 키를 차단할 수 있습니다.

물론 키에는 권한이없는 사람이 추출 된 몇 가지 예제에서 추측하거나 고유 한 호환 가능한 인스턴스를 생성 할 수없는 특성이 있어야합니다. 즉, 유효한 키가있는 곳에서 생성 한 키 레코드가 필요합니다. 거대한 가능성 공간의 작고 예측할 수없는 부분 만, 또는 생성 한 키에 서명하고 시스템이 서명 증명과 함께 키만 허용하도록해야합니다.

클라이언트 키를 비밀로 유지하려고 노력해야합니다 (그러나 다른 답변에서 설명한대로 키를 잃어버린 의미를 이해하십시오 (1)). 서버 퍼블릭 키와 AWS 퍼블릭 인증서는 비밀을 유지하려는 것이 아니라 손상된 디바이스의 AWS 인증서를 교체하여 디바이스가 디바이스를 실행하도록 설득 할 수 있기 때문에 디바이스 엔드에서 보안을 유지하는 데 중요합니다. 공격자의 호스트와 교환하거나 중간자에게 AWS와의 통신을 교환합니다.

이렇게하면 (2) 공격자가 TLS 보안을 제거하여 클라이언트 키를 리버스 엔지니어링 할 수있는 보안을 충분히 줄일 수 있습니다.

이러한 추론 에 의해 외부 메모리 장치에 노출되는 것이 안전한 유일한 키 는 서버 공개 키입니다. 이 (3)을 변경하면 디바이스가 액세스를 조작하기 어려운 악성 AWS 서비스에만 연결될 수 있습니다. 이 키만 유출하더라도 누군가가 일부 전송을 스누핑하거나 위조 할 수 있습니다 (예 : TLS 계층이 어떻게 든 다운 그레이드 될 수있는 경우).

요약하자면, 위험은 단순히 정보를 유출하는 것이 아니라 신뢰할 수있는 보안 정보로 (신뢰할 수있는) 펌웨어를 제공 할 수있는 위험이 있습니다.