IoT 기기를 클라우드에 연결하는 안전한 솔루션

　　사람들이 보안의 필요성을 점점 더 인식하고 있지만, 개발자들은 종종 IoT 기기를 클라우드에 연결하는 지름길을 택하게 됩니다. 많은 경우, 적절한 안전 메커니즘의 복잡성, 마이크로배터리 구동 IoT 기기의 제한된 메모리 및 처리 자원, 그리고 제품 운송 수요 사이의 갈등이 극복할 수 없어 보입니다.

　　이러한 문제를 해결하고 IoT 기기에서 보안 기능 구현을 단순화하기 위해, Microchip Technology와 Google은 마이크로칩의 보안 하드웨어 기능과 JSON Web Token(JWT)이라는 간단한 데이터 구조를 결합한 방법을 공동 개발했습니다. 그 결과 IoT 기기와 구글 클라우드 IoT 핵심 서비스 간 상호 인증을 보장하는 간단한 방법이 탄생했습니다.

　　이 글에서는 IoT 기기에 대한 보안 위협을 소개하고, 현재 이러한 위협에 대응하는 데 사용되는 기기들을 소개할 것입니다. 보안 취약점을 식별하고 개발자와 임베디드 시스템 설계자가 JWT를 이용해 취약점을 차단하는 방법을 알 것입니다.

　　IoT 기기의 보안 취약점

　　IoT 기기에 대한 공격은 다양한 형태를 취할 수 있으며, 대규모 IoT 배포에만 국한되지 않습니다. 분산 서비스 거부(DDoS) 공격에 사용되는 봇넷에서 여러 개별 장치의 자원을 악용하려는 해커들에게는 가장 작은 IoT조차도 매력적인 표적이 됩니다. 따라서 모든 유형의 IoT 기기 설계자들은 공격을 방지하기 위해 견고한 하드웨어 기반 보안 메커니즘을 통해 시스템을 보호해야 합니다.

　　예를 들어, 시스템 메모리나 플래시 저장소를 암호화 및 인증용 개인 키를 저장하는 것은 IoT 기기를 공격에 취약하게 만듭니다. 더 나쁜 것은, 해커들이 이 키를 훔쳐 IoT 네트워크와 추가 회사 자원에 접근할 수 있다는 점입니다.

　　안전 IC

　　Microchip Technology의 CryptoMemory와 CryptoAuthentication IC와 같은 전용 보안 장치는 개인 키 및 기타 비밀 데이터를 보호하는 메커니즘에 기반한 하드웨어 기능을 갖추고 있습니다. EEPROM 배열은 이러한 장치에 통합되어 장치의 SPI 또는 I2C 직렬 인터페이스를 통해서만 접근 가능한 안전한 저장 및 암호화 보안 메커니즘을 제공합니다(그림 1 참조). 따라서 이러한 기기들은 어떤 IoT 기기 설계에도 안전한 저장 및 기타 보안 기능을 간단히 추가할 수 있는 방법을 제공합니다.

　　그림 1: 마이크로칩 테크놀로지 하드웨어 보안 장치(예: AT88SC0204C 크립토메모리 IC)는 안전한 저장 장치를 제공하며, 통합 암호화 메커니즘을 사용하여 온칩 EEPROM 접근을 보호합니다. (이미지: 마이크로칩 테크놀로지)

　　Microchip CryptoAuthentication 시리즈의 구성원들(예: ATECC608A)은 보안 저장의 기반을 강화하고 보안 설계에서 흔히 사용되는 암호화 알고리즘을 지원합니다. 하드웨어 기능 중에는 다음과 같은 다양한 알고리즘에 대한 하드웨어 가속 기능이 포함되어 있습니다:

　　비대칭 암호화 알고리즘:

　　FIPS186-3 타원 곡선 디지털 서명 알고리즘 (ECDSA)

　　FIPS SP800-56A 타원 곡선 디피-헬만 (ECDH)

　　NIST 표준 P256 타원 곡선 암호화(ECC)

　　대칭 암호화 알고리즘:

　　SHA-256 해시 코드

　　해시 기반 메시지 인증 코드(HMAC) 암호학

　　AES-128 암호학

　　AES-GCM(갈루아 장 곱셈) 암호학

　　키 파생 함수(KDF):

　　의사 난수 함수(PRF) KDF

　　HMAC 기반 추출 – 확장 중인 KDF (HKDF)

　　암호화폐 전문가들에게 이 암호화 기능 집합은 상위 보안 프로토콜을 지원하는 데 필요한 메커니즘의 포괄적인 목록을 나타냅니다. 인증 및 안전한 데이터 교환. 예를 들어, KDF 기능은 전송 계층 보안(TLS) 프로토콜이 교환 세션 시작 전이나 심지어 세션 시작 전에 참여자를 검증하는 데 필요한 기본 메커니즘을 제공합니다.

　　이 프로토콜에서 TLS 세션은 클라이언트로부터 서버로 안전한 세션 시작 요청을 보냅니다. 서버는 디지털 인증서를 사용하여 응답하며, 클라이언트는 이를 통해 서버의 신원을 확인합니다. 클라이언트가 이런 방식으로 서버를 검증한 후, 세션 설정은 서버의 공개키를 사용해 PRF KDF 또는 더 강력한 HDKF로 생성된 임의 값을 암호화하는 세션 키를 계속 생성합니다.

　　TLS 인증 프로토콜은 인터넷 보안의 기초입니다. 인증서 제공자 산업 전체인 인증 기관(CA)은 안전한 통신을 지원하는 핵심 구성 요소로 진화했습니다. 회사는 CA로부터 신뢰할 수 있는 인증서를 받아 자체 서버에 설치하며, 앞서 언급한 표준 TLS 서버 인증 프로토콜을 지원합니다.

　　IoT 애플리케이션의 경우, 네트워크는 기업과 광범위하고 깊이 연결되어 있으며, 이러한 일방향 인증만으로는 보호를 보장하기에 충분하지 않습니다. 예를 들어, 허위 인증서를 가진 해커들은 자신을 IoT 기기의 합법적인 서버인 척하며 더 광범위한 공격의 일부로 가장할 수 있습니다.

　　위험에도 불구하고, IoT 개발자들은 TLS 상호 인증 프로토콜 구현에 어려움을 겪는 경우가 많습니다. TLS를 사용하는 클라이언트 인증에 필요한 인증서, 키, 소프트웨어가 많은 IoT 기기의 성능을 초과할 수 있기 때문입니다. 마이크로칩 테크놀로지와 구글은 협력하여 ATECC608A 기능과 간단한 데이터 구조인 JSON 웹 토큰(JWT)을 결합한 대안 접근법을 만들었습니다. 그 결과 IoT 기기와 구글 클라우드 IoT 핵심 서비스 간 상호 인증을 보장하는 간단한 방법이 탄생했습니다.

　　JWT 기반 인증

　　RFC 7519는 JWT가 JWT를 준비하고 전송하는 주체에 관한 정보를 담는 업계 표준 컨테이너(클레임)임을 명시합니다. JWT 구조 자체는 세 부분으로 구성되어 있습니다:

　　제목, JSON 이름을 포함해: 암호화 알고리즘("alg")(예: ECDSA의 "EC256"은 NIST P-256 곡선을 사용함)과 토큰 유형("type")(이 토큰들의 "JWT") 이름입니다.

　　각 청구에 대한 JSON 이름: 값 쌍을 포함한 페이로드

　　서명: 헤더에 명시된 알고리즘을 사용하여 키, 헤더, 선언 집합을 인코딩하며, 각각은 암호화 전에 base64 URL 인코딩으로 개별적으로 변환됩니다

　　RFC 7519는 페이로드나 기타 부품에 대한 청구 명시에 큰 유연성을 제공합니다. 이 표준은 서명이나 암호화 없이 생성되는 안전하지 않은 JWT도 허용하며, 이 경우 헤더에는 알고리즘 이름인 value pair {{alg":"none"}가 포함됩니다. 구글 클라우드 IoT 핵심 서비스와 함께 사용되는 JWT의 경우, 구글은 서명 섹션과 세 가지 필수 선언을 포함하는 페이로드가 필요합니다.

　　"iat" - ISO 8601 UTC 타임스탬프 형식으로 토큰을 생성할 때의 "발행 시간"으로, 1970-01-01T00:00:00Z 이후의 초 단위(예: 2019년 6월 30일 1561896000 12:00 GMT)

　　"exp" - 클라이언트와 서버 간 서로 다른 시스템 클럭 편향을 해결하기 위해 최대 24시간을 초과하는 토큰 만료 시간을 지정하는 UTC 타임스탬프, 최대 24시간 초과 및 10분 유예 기간을 포함합니다 (예: 2019년 7월 1일 1561982400 GMT 00:00 00:00)

　　"aud" - 개발자의 Google Cloud 프로젝트 ID를 포함하는 문자열

　　< p> 구글의 IoT 기기 인증 솔루션은 전통적인 TLS 기반 서버 인증과 이러한 비교적 간단한 IoT 기기 인증용 선언으로 만들어진 JWT를 결합합니다. 새 세션을 시작하기 위해 IoT 장치는 서버에 보안 소켓을 열고 앞서 설명한 동일한 TLS 프로토콜로 서버를 인증합니다.

　　이 과정의 다음 단계는 Google IoT Cloud의 경량 메시지 큐 텔레메트리 전송(MQTT) 프로토콜을 IoT 네트워크 거래에 의존하는 것입니다. 인증된 서버에 보안 소켓을 사용하여, IoT 장치는 고유한 JWT를 로그인 비밀번호로 사용하여 해당 서버(인벤토리 1)의 MQTT 호스트 서비스에 "로그인"합니다.

　　IoT 기기들은 로그인 시퀀스의 일부로 사용자 이름을 전송하지만, 사용자 이름은 인증에 사용되지 않습니다. 따라서 가상 사용자 이름(목록 2)이 이전되었습니다. 대신 IoT 기기 인증은 로그인 비밀번호로 전송되는 JWT를 기반으로 합니다. JWT 서명은 헤더, 페이로드, 장치 개인 키의 조합이기 때문에, 구글 클라우드 IoT 핵심 서비스는 JWT가 실제로 권한 있는 장치에서 나오는지 검증할 수 있습니다. 이 검증을 위해 Google Cloud IoT Services는 아래에 설명된 키 관리 프로세스를 통해 IoT 기기 개발자가 구글 클라우드에 저장했던 기기 공개키를 사용합니다. TLS만 사용하는 것과 비교할 때, 이 방법은 하이브리드 방식을 통해 상호 인증을 제공하여 프로세스 속도를 높이고 IoT 장치의 자원 요구량을 줄입니다.

　　주요 지원 요인

　　ATECC608A과 공급망의 기능성이 이 접근법의 핵심 동인입니다. 모든 MCU는 결국 JWT 헤더와 페이로드로부터 암호화된 암호화 서명을 생성할 수 있지만, 하드웨어 기반 보안 키 저장이 없으면 소프트웨어 전용 방법도 공격에 취약합니다. 또한, 엄격한 응답 시간 요구가 있는 많은 자원 제한 IoT 장치나 애플리케이션에서는 "소프트웨어 전용" 구현에 필요한 프로세서 부하와 실행 지연이 금지될 수 있습니다. 마지막으로, 광범위한 보안 알고리즘과 더 발전된 프로토콜 경험이 없으면 개발자들이 필요한 소프트웨어 기능을 구현하기 어렵습니다. Microchip은 CryptoAuthLib 라이브러리(그림 2)를 통해 이러한 문제를 해결합니다.

　　그림 2: CryptoAuthLib는 하드웨어 추상화 계층(HAL)을 사용하여 API 기능과 코어 원시 요소를 기본 하드웨어와 분리하기 때문에, 개발자는 다양한 지원 장치에 맞게 소프트웨어를 배치할 수 있습니다. (이미지: 마이크로칩 테크놀로지)

　　Microchip CryptoAuthLib는 Google JWT 인증 프로토콜과 같은 안전한 IoT 기능 구현을 단순화하여, 복잡한 보안 작업을 CryptoAuthLib 애플리케이션 프로그래밍 인터페이스(API)를 통해 제공하는 함수 호출 집합으로 단순화합니다. IoT 개발자들에게 가장 중요한 기능은 Microchip CryptoAuthLib 핵심 기능으로, ATECC608A와 같은 Microchip 암호화 IC를 완전히 활용해 설계 시 보안 기능 실행을 가속화합니다. 예를 들어, 목록 1에서는 atca_jwt_finalize()에 대한 호출이 사용 가능한 암호화 장치(예: ATECC608A)를 사용하여 목록 2의 비밀번호에 대한 JWT를 생성합니다. 이 경우 JWT 서명의 암호화를 가속화ATECC608A 설계를 통합된 보안 저장 키부터 앞서 설명한 서명 생성 과정을 완료하는 과정을 완료합니다.

　　하지만 복잡한 소프트웨어와 보안 장치에도 불구하고, IoT 기기는 키와 인증서를 관리하는 전통적인 방식 때문에 여전히 공격에 취약합니다. 과거에는 개인 키가 외부에서 생성되어 제조, 배포, 심지어 배포 시 보안 저장장치에 로드되어야 했습니다. 하드웨어 보안 모듈과 보안 시설을 사용할 때조차, 유일한 기기가 '알아야 한' 것 외에 잠시 존재하는 비밀은 우연히 또는 의도적으로 노출될 수 있는 보안 취약점을 나타냅니다. 마이크로칩과 구글은 ATECC608A 역량을 활용해 전통적인 보안 취약점을 대부분 제거했습니다.

　　이 새로운 접근법에서 마이크로칩은 ATECC608A의 기능을 이용해 장치에 개인 키를 남기지 않고 키 쌍을 생성할 수 있습니다(그림 3). 마이크로칩은 고객이 제공하고 마이크로칩 보안 시설 내 보안 서버에 저장하는 장치가 생성한 공개 키를 중간 인증서로 서명합니다. 마지막으로, 마이크로칩은 공개키를 Google Cloud IoT Device Manager의 고객 계정으로 안전하게 전송하며, 이 관리자는 기기당 최대 세 개의 공개키를 저장하여 키 순환 정책을 지원합니다. 배포 후 IoT 장치는 ATECC608A 보안 기능을 활용해 앞서 설명한 상호 인증 과정에서 사용되는 JWT를 생성할 수 있습니다.

　　그림 3: 마이크로칩 기술과 구글 클라우드 IoT 서비스의 결합은 키 및 인증서 구성을 단순화하여 IoT 애플리케이션 보안을 강화하는 보호된 메커니즘을 제공합니다. (이미지: 구글)

　　마이크로칩과 구글의 협력을 통해 개발자들은 이 중요한 키 관리 프로세스를 완전히 분리할 수 있습니다. 사용자 지정 요구사항을 위해 개발자는 CryptoAuthLib API 함수 atcab_genkey()를 사용하여 자체 키 관리 프로세스를 구현할 수 있으며, 이를 통해 키 쌍을 생성하고 개인 키를 안전한 저장소에 저장하며 관련 공개키를 반환ATECC608A 수 있습니다. /p>

　　키 생성 및 기타 ATECC608A 보안 기능을 탐색하기 위해 개발자들은 Microchip SAM D21 Xplained Pro 평가 키트를 중심으로 한 포괄적인 개발 환경을 빠르게 구축할 수 있습니다. 32비트 Arm ® Cortex-M0 ® + MCU ATSAMD21J18A Microchip을 기반으로 한 SAM D21 Xplained Pro 키트는 Microchip의 Advanced Software Framework(ASF)가 지원하는 완전한 하드웨어 플랫폼 드라이버 및 코드 모듈을 제공합니다.

　　ATECC608A 포함 CryptoAuthentication 장치를 평가하기 위해 개발자는 CryptoAuth XPRO-B 애드온 보드를 Xplained Pro 보드의 두 개 확장 헤드 중 하나에 삽입하면 됩니다. Microchip은 CryptoAuthLib와 ATECC608A의 보안 기능을 평가하기 위한 예시 소프트웨어를 제공합니다. 더 나아가, 개발자들은 Microchip ATWINC1500-XPRO Wi-Fi 애드온보드를 다른 헤더에 삽입하여 Microchip 샘플 소프트웨어를 실행할 수 있으며, 이는 TLS 서버 인증과 JWT 장치 인증을 포함한 이 글에서 설명한 상호 인증 과정을 보여줍니다.

　　결론

　　IoT 애플리케이션 보안에는 여러 요구사항이 있지만, 주요 과제는 종종 IoT 기기와 클라우드 자원에 대한 상호 인증 구현에 있습니다. 자원이 제한된 IoT 시스템에서는 전통적인 프로토콜이 사용 가능한 메모리와 처리 자원을 초과할 수 있습니다. Microchip Technology의 CryptoAuthLib 라이브러리와 ATECC608A CryptoAuthentication IC를 활용하여, 개발자들은 JSON Web Tokens를 기반으로 IoT 기기를 Google Cloud IoT 서비스에 안전하게 연결할 수 있는 보다 효율적인 접근법을 구현할 수 있습니다.