제퍼넷 로고

IoT 장치의 보안

시간

IoT 장치의 보안
일러스트 : © IoT For All

IoT 장치의 보안은 장치가 실행되는 환경과 실제 장치 기능이 구축되는 기반을 형성하는 하드웨어 플랫폼 및 운영 체제를 포괄하는 광범위한 전문 분야입니다. 각 영역에는 서로 다른 기술과 기술이 필요하지만 모든 영역은 함께 안전한 단위를 형성해야 합니다. 다른 모든 영역이 완벽하더라도 한 영역을 무시하면 치명적인 결과를 초래할 수 있다는 것은 엄연한 사실입니다.

그러나 하나의 보안 장치를 사용하여 작업을 수행하는 것은 시작에 불과합니다. 하나의 장치뿐만 아니라 전체 장치를 안전하게 배포하고 운영하는 것은 프로비저닝, 인증 및 ID 관리의 형태로 또 다른 과제를 가져옵니다.

이 기사에서

IoT 보안 분야의 몇 가지 필수 영역을 살펴보겠습니다. IoT 장치는 다양한 형태와 크기로 제공되지만 다음과 같은 보안 관련 측면은 모든 장치에 공통적으로 적용됩니다.

  • IoT 장치의 물리적 보안 경계
  • 하드웨어
  • 운영체제
  • 소프트웨어
  • IoT 장치의 ID 및 프로비저닝
  • IoT 기기 인증

IoT 장치의 물리적 보안 경계

IoT 장치는 일반적으로 데이터 센터에서 실행되는 컴퓨터 시스템과 매우 다른 예측할 수 없고 불안정하며 안전하지 않은 환경에 위치합니다.

충분한 물리적 보안을 보장할 수 없는 경우 물리적 접근 권한을 가진 잠재적인 악의적 행위자의 위협에 직면할 수 있도록 IoT 장치를 준비하는 것이 필수적입니다. 하드웨어 및 소프트웨어 설계자가 이러한 위험을 줄이기 위해 취할 수 있는 몇 가지 조치가 있습니다. 이러한 조치에는 저장 장치의 데이터 암호화와 같은 일반적인 기술과 기사의 나머지 부분에서 살펴볼 IoT 관련 기술이 포함될 수 있습니다.

하드웨어

하드웨어는 IoT 장치 보안의 기반입니다. 하드웨어가 손상되면 IoT 장치가 가질 수 있는 대부분의 소프트웨어 수준 보호 기능이 공격자에 의해 우회될 수 있습니다.

역사적으로 공격자가 컴퓨터 시스템에 물리적으로 접근할 수 있게 되면 기본적으로 보안 관점에서 게임이 종료되었습니다. 다행스럽게도 IoT 장치 및 기타 유형의 모바일 장치 수가 증가함에 따라 이 분야에서 많은 발전이 이루어졌습니다. 이러한 하드웨어 수준 보호의 예는 다음과 같습니다.

  • 신뢰할 수있는 실행 환경 Intel SGX와 같은 TEE(TEE)는 CPU에 의해서만 즉석에서 해독될 수 있는 메모리의 특정 부분(엔클레이브)을 암호화할 수 있도록 하여 엔클레이브에서 시작되지 않은 코드가 이를 읽고 수정하는 것을 효과적으로 방지합니다(운영 체제 및 하이퍼바이저 포함). 있을 수 있습니다).
  • 물리적으로 복제 불가능한 기능 (PUF)는 고유하고 위조할 수 없으며 변경할 수 없는 장치 식별자로 사용될 수 있습니다.
  • A 신뢰할 수있는 플랫폼 모듈 (TPM)은 암호화 키와 같은 중요한 데이터를 위한 전용 암호화 프로세서이자 보안 저장소입니다. TPM 외부에 키를 노출하거나 하드웨어 구성을 검증하지 않고도 암호화된 보안 난수를 생성하고 저장된 키를 사용하여 암호화 작업을 수행할 수 있습니다.

이러한 기술은 수년 동안 연구되고 구현되었지만 PUF는 널리 확산되지 않았으며 TEE는 최근에야 관심을 끌기 시작했습니다. 반면, TPM은 오랫동안 표준으로 간주되어 대부분의 컴퓨터에서 찾을 수 있으며 의심의 여지 없이 IoT 장치의 보안을 크게 향상시킬 수 있습니다.

또한 악의적인 행위자가 IoT 장치를 고의적으로 손상시키는 것이 유일한 위협이 아니라는 점을 잊어서는 안 됩니다. 많은 장치가 야외에 배치되므로 하드웨어에 대한 방수 처리가 필수입니다.

운영체제

운영 체제(OS)가 없는 제한된 IoT 장치가 일반적이지만 많은 장치가 더 복잡하고 OS가 필요합니다.

OS가 위에서 실행되는 모든 컴퓨터 프로세스/프로그램을 방해할 수 있다는 사실(위에서 언급한 TEE와 같은 일부 고급 메커니즘을 사용하지 않는 한)은 OS를 하드웨어와 마찬가지로 IoT 장치 보안의 중요한 부분으로 만듭니다.

첫째, 부팅 중에 악의적으로 수정되지 않은 OS 버전이 로드되도록 보장할 수 있는 방법이 필요합니다. 이러한 보증은 OS에 디지털 서명을 하고 작업 중에 서명을 확인함으로써 달성할 수 있습니다. 부팅. 이에 대한 기준은 다음과 같습니다. 안전 부팅.

마지막으로 모든 운영 체제에는 보안 취약점이 있습니다. 와는 별개로 제로 데이 이러한 취약점은 시기적절한 소프트웨어 패치 제공 및 적용을 통해 효과적으로 해결될 수 있습니다.

소프트웨어/애플리케이션

단일 애플리케이션의 손상은 전체 운영 체제나 하드웨어의 손상보다 훨씬 작은 영향을 미치는 것처럼 보일 수 있습니다. 그러나 이는 공격자가 성공하기 위해 필요한 유일한 것일 수 있습니다. 또한 운영 체제와 달리 많은 애플리케이션은 민감한 비즈니스 데이터를 직접 처리하고 사용자와 상호 작용합니다.

운영 체제에 대한 유사한 조치는 운영 체제 위에서 실행되는 다양한 소프트웨어 패키지 및 애플리케이션에도 적용될 수 있습니다. 실행 파일의 무결성과 시기적절한 보안 업데이트를 확인하는 것이 고려되어야 합니다.

사용자 정의 애플리케이션을 작성할 때 개발자는 코드가 실행될 환경을 신뢰할 수 없다는 점을 고려해야 합니다. 예:

  • 민감한 데이터를 로드할 때 , 강제 메모리 덤프를 통해 민감한 데이터가 노출될 위험을 줄이려면 할당된 메모리를 가능한 한 빨리 해제하고 0으로 설정하세요.
  • 민감한 데이터를 디스크에 쓰기 전에 두 번 생각하십시오. 디스크 암호화가 적용되어 있어도 데이터는 유출됩니다. 중요한 데이터를 디스크에 써야 하는 경우 이전 섹션에서 언급한 TPM(신뢰할 수 있는 플랫폼 모듈)에 저장된 키를 사용하여 암호화하는 것이 좋습니다.

IoT 장치의 식별 및 프로비저닝

여러 IoT 장치를 의미 있게 관리하려면 각 장치에 고유한 ID가 있어야 하며, 새 장치에 ID를 안전하게 할당하고 필요한 경우 기존 장치의 ID를 변경할 수 있는 방법이 있어야 합니다. 이 프로세스를 "장치 프로비저닝"이라고 부를 수 있습니다. IoT 솔루션의 경우, 개별 장치의 데이터를 안전하게 구별하거나 손상된 장치의 연결을 끊기 위해서는 ID가 필수적입니다.

IoT 장치의 "ID"란 정확히 무엇입니까? 상황에 따라 다릅니다. 그러나 장치에는 자신의 신원이 합법적이라는 것을 증명(인증)할 수 있는 방법이 필요합니다. 물리적 장치 ID와 논리적 장치 ID를 구분할 수 있습니다.

물리적 정체성

물리적 ID는 전체 장치 수명주기 동안 위조할 수 없고, 고유하며, 변경이 불가능하고, 양도할 수 없는 하드웨어 수준 ID이며 일반적으로 비즈니스 도메인과 관련이 없습니다. 이상적인 세계에서는 장치 제조가 완료된 후 물리적 신원이 정확히 한 번 할당됩니다. 이는 예를 들어 모든 하드웨어 구성 요소의 일련 번호를 결합하여 달성할 수 있습니다. 그러나 이 접근 방식은 실제로는 훨씬 더 복잡합니다.

  • 하드웨어 구성 요소가 파손되어 새 것으로 교체될 수 있습니다. 상황을 더욱 복잡하게 만들기 위해 구성 요소를 다른 장치의 수리된 구성 요소로 교체할 수 있습니다.
  • 모든 하드웨어 구성 요소에 일련 번호가 있는 것은 아니며 일련 번호를 쉽게 읽을 수 없습니다.
  • 일련번호는 일반적으로 암호화된 보안 식별자가 아닙니다.

그렇기 때문에 물리적 신원은 일반적으로 제조 과정에서 식별자를 생성하거나 기본으로 간주되는 일부 구성 요소의 일련 번호를 사용하여 "근사"됩니다.

논리적 정체성

반면 논리적 ID는 일반적으로 비즈니스 도메인이나 장치 위치와 같은 기타 비기술적 측면과 긴밀하게 연결됩니다. 물리적 ID와 마찬가지로 논리적 ID는 위조할 수 없고 고유해야 하지만 변경 및 전송이 가능합니다.

물리적 ID와 논리적 ID의 차이를 보여주기 위해 다음 사용 사례 예를 고려하십시오. 자동차 조립 라인의 로봇 팔은 특정 기능을 수행합니다. 고정형 IoT 기기입니다.

이 로봇의 물리적 신원은 암호화된 보안을 생성하여 공장에서 바로 할당됩니다. UUID (e.g., c2c38155-b0d2-48b6-82fd-22fe3b316224).

이 장치는 클라우드 기반 IoT 솔루션 백엔드에 데이터를 보내고 동일한 백엔드로부터 피드백을 받습니다. 이 로봇이 보내는 데이터에는 두 가지 종류가 있습니다.

  • 수행된 기능에 대한 진단 데이터(예: 조립 라인에서 매 시간마다 이 로봇이 처리한 자동차 부품 수).
  • 내부 원격 측정 데이터(예: 각 관절에 적용되는 토크의 양)

로봇이 오작동하여 교체해야 하는 경우 로봇의 물리적 정체성이 변경됩니다.

로봇이 논리적인 정체성을 가지고 있지 않다고 가정해보자. 이 경우 클라우드에 있는 기존 데이터를 새 로봇의 ID와 연관시키는 것은 간단하지 않습니다. 내부 원격 측정 데이터는 원래 로봇에만 관련되므로 문제가 되지 않을 수 있습니다. 그러나 수행된 기능에 대한 진단 데이터는 새 로봇과 관련이 있을 수 있습니다. 또한 오작동하기 전에 원래 로봇과 통신하던 다른 시스템도 이제 로봇이 교체되었음을 인식해야 합니다.

이를 원래 로봇도 자동차 조립 라인의 구성과 관련된 논리적 정체성을 갖고 있었던 상황(예: 라인-03-왼쪽-용접-12)과 비교해 보겠습니다. 이 논리적 ID를 진단 데이터 저장 및 다른 시스템과의 통신에 사용하면 로봇 교체가 훨씬 쉬워질 수 있습니다.

IoT 장치 인증

IoT 장치가 어떤 식별자를 사용하고 어떻게 생성되는지에 관계없이 장치는 자신이 사용하는 식별자가 합법적이라는 것을 증명해야 합니다. 식별자가 합법적이고 올바른 장치에서 사용되는지 확인하는 프로세스를 인증이라고 합니다.

IoT 장치의 인증은 항상 다음을 기반으로 합니다. 대칭 or 비대칭(공개) 키 암호화 알고리즘 및 해싱 알고리즘. 이러한 알고리즘에는 항상 장치 어딘가에 저장된 비밀 키가 필요합니다.

인증이 정확히 작동하는 방식은 특정 알고리즘에 따라 다릅니다. 그러나 항상 다음 두 가지 가정이 있습니다.

  • 장치의 ID는 비밀 키와 바인딩됩니다.
  • 비밀 키는 정말 비밀입니다.
  • 비대칭 알고리즘의 경우 장치에서만 알 수 있습니다.
  • 대칭 알고리즘의 경우 장치와 인증 당사자(예: IoT 솔루션 지원)만 이를 알 수 있습니다.

비밀 키 처리

비밀 키가 저장되는 위치와 방법은 장치의 기능과 특정 인증 알고리즘에 따라 다릅니다. 최첨단 접근 방식은 TPM(신뢰할 수 있는 플랫폼 모듈)에 키를 보관하는 것입니다. TPM은 비밀 키를 노출하지 않고 직접 암호화 작업을 실행하여 키 유출로부터 보호할 수 있습니다.

좋은 방법은 기본 키의 노출을 최소화하고 다음을 제공하기 위해 기본 키에서 수명이 짧은/세션 기반 키를 파생시키는 것입니다. 전진 비밀.

가장 널리 사용되는 알고리즘, 표준 및 프로토콜은 다음과 같습니다.

  • RSA, 타원 곡선, SHA2: 기본 비대칭(공개) 키 암호화 및 해싱 알고리즘.
  • X.509 인증서: 인증서라는 개체를 통해 비대칭 키와 ID를 결합하는 방법을 정의하는 표준입니다.
  • mTLS: TCP 연결 보안을 위한 프로토콜입니다. 일반 TLS와 달리 연결의 양쪽이 모두 인증됩니다. 위에서 언급한 기본 암호화 및 해싱 알고리즘과 X.509 인증서를 기반으로 구축되었습니다.
  • HMAC: 장치가 자신의 신원을 증명하는 데 사용할 수 있는 서명된 장치 식별자를 생성할 수 있는 대칭 키 기반 알고리즘입니다.

주요 요점

IoT 보안의 성격은 다양합니다. 다양한 종류의 IoT 장치가 존재하지만 IoT 솔루션 설계자가 고려해야 할 몇 가지 일반적인 보안 측면이 있습니다.

  • 장치가 실행되는 환경(물리적 보안 경계)입니다.
  • 장치가 구축된 기반(하드웨어, 운영 체제)입니다.
  • 장치를 유용하게 만드는 실제 코드(소프트웨어)입니다.
  • 소프트웨어가 안전하고 제어 가능하며 확장 가능한 방식으로 실행되는 데 필요한 프로세스(ID, 프로비저닝 및 인증)입니다.

반면에, 이 기사에서 제공하는 모든 제안을 맹목적으로 따르고 구현하는 것은 좋은 생각이 아닙니다. 다양한 IoT 솔루션에 대한 일부 조치는 다른 조치보다 더 중요하며, 일부는 특정 상황에서는 관련성이 없거나 실행 가능하지 않을 수도 있습니다. 그러나 완화된 보안 조치는 항상 의식적으로 적절한 고려를 거쳐 수행되어야 합니다.

spot_img

최신 인텔리전스

spot_img