IoT 장치를 클라우드에 안전하게 연결하기 위한 손쉬운 솔루션

보안 필요성에 대한 인식이 높아짐에도 불구하고 많은 개발자가 IoT 장치를 클라우드에 연결하기 위해 보안을 단축하는 지름길을 찾습니다. 대부분의 경우 적합한 보안 메커니즘의 복잡성, 초소형 배터리로 구동되는 IoT 장치에서 이용 가능한 메모리와 처리 리소스 제한, 제품 배송 필요성 간의 충돌은 극복하기 어려운 문제입니다.

이러한 문제를 해결하고 IoT 장치에서 보안 기능의 구현을 단순화하기 위해 Microchip Technology와 Google은 협업을 통해 Microchip의 안전한 하드웨어 기능과 JWT(JSON Web Token)라 불리는 단순한 데이터 구조를 결합하는 접근 방식을 고안하였습니다. 그 결과 IoT 장치와 Google Cloud IoT Core 서비스 간의 상호 인증을 보증하는 손쉬운 방법을 마련했습니다.

이 기사에서는 IoT 장치 보안 위협을 설명하고 현재 그러한 위협에 대항하는 데 사용되는 장치를 소개합니다. 또한 보안의 빈틈을 식별하고 개발자와 내장형 시스템 설계자가 어떻게 JWT를 이용해 이러한 틈을 메울 수 있는지 설명합니다.

IoT 장치의 보안 취약성

IoT 장치에 대한 공격은 다양한 형태로 나타날 수 있으며 결코 대규모의 IoT 배포에만 국한되지 않습니다. 가장 소규모의 IoT 네트워크일지라도 분산형 서비스 거부(DDoS) 공격 등을 의도하는 봇네트에 있는 수많은 개별 장치의 리소스를 활용하려는 해커의 매력적인 공격 대상입니다. 그 결과 모든 등급의 IoT 장치 설계자는 공격을 막을 수 있는 견고한 하드웨어 기반 보안 메커니즘으로 시스템을 보호해야 할 필요성에 불가피하게 직면하게 됩니다.

예를 들어 암호화 및 인증에 사용되는 개인 키를 저장하는 데 시스템 메모리나 플래시를 사용할 경우 IoT 장치가 취약한 상태로 남게 됩니다. 더 나쁜 경우엔 해커가 개인 키를 훔쳐서 IoT 네트워크 및 연결된 기업 리소스에 대한 액세스를 확보하는 데 사용할 수 있습니다.

보안 IC

Microchip Technology의 CryptoMemory 및 CryptoAuthentication IC 같은 특수 보안 장치에는 개인 키와 기타 비밀 데이터를 보호하기 위한 하드웨어 기반 메커니즘이 탑재되어 있습니다. 이 장치에 통합된 EEPROM 어레이는 장치의 SPI 또는 I²C 직렬 인터페이스를 통해 액세스되는 암호화된 방식의 안전한 메커니즘을 통해서만 도달할 수 있는 안전한 저장소를 제공합니다(그림 1). 그 결과 이 장치는 보안 저장소와 기타 보안 기능을 IoT 장치 설계에 추가할 단순한 방법을 제공하게 됩니다.

그림 1: AT88SC0204C CryptoMemory IC와 같은 Microchip Technology의 하드웨어 보안 장치는 온칩 EEPROM에 대한 액세스를 보호하기 위해 통합 암호화 메커니즘을 사용하여 안전한 저장소를 제공합니다. (이미지 출처: Microchip Technology)

ATECC608A와 같은 Microchip의 CryptoAuthentication 제품군은 안전한 설계에서 일반적으로 사용되는 암호화 알고리즘에 대한 지원을 통해 보안 저장소 기반을 강화합니다. 하드웨어 기능 중 이 장치에는 다음을 포함하는 여러 알고리즘에 대한 하드웨어 가속화가 탑재되어 있습니다.

• 비대칭 암호화 알고리즘:
  • FIPS186-3 타원 곡선 디지털 서명 알고리즘(ECDSA)
  • FIPS SP800-56A 타원 곡선 디피-헬먼(ECDH)
  • NIST Standard P256 타원 곡선 암호화(ECC)
• 대칭 암호화 알고리즘:
  • SHA-256 해시 암호화
  • 해시 기반 메시지 인증 코드(HMAC) 암호화
  • AES-128 암호화
  • AES-GCM(Galois field multiply) 암호화
• 키 유도 함수(KDF):
  • 의사 난수 함수(PRF) KDF
  • HMAC 기반 추출 및 확장 KDF(HKDF)

암호화 전문가를 위한 이 암호 기능 집합은 인증 및 안전한 데이터 교환에 더 높은 수준의 보안 프로토콜을 지원하기 위해 필요한 포괄적인 메커니즘 목록을 나타냅니다. 예를 들어 KDF 기능은 데이터 교환이 진행되기 전에 데이터 교환 세션의 참가자를 인증하기 위한 전송 계층 보안(TLS) 프로토콜에 필요한 필수적인 메커니즘을 제공합니다.

이 프로토콜에서 TLS 세션은 클라이언트가 보안 세션을 시작하기 위해 서버에 요청을 전송하는 데에서 시작됩니다. 서버는 디지털 인증서로 응답하며 클라이언트는 응답을 통해 서버 ID를 확인합니다. 클라이언트가 이 방식으로 서버를 인증하면 클라이언트가 서버의 공개 키를 통해 PRF KDF 또는 더욱 견고한 HDKF를 사용하고 이로 인해 생성된 무작위 값을 암호화하여 세션 키를 생성하는 방식으로 세션 설정이 진행됩니다.

TLS 인증 프로토콜은 인터넷 보안의 토대입니다. 인증 기관(CA)이라 불리는 전체 인증서 제공업계는 이 중대한 보안 통신 부품을 지원하도록 진화했습니다. 기업은 CA로부터 신뢰할 수 있는 인증서를 확보해 자체 서버에 설치하여 위에 설명된 표준 TLS 서버 인증 프로토콜을 지원합니다.

네트워크가 기업 소스와 폭넓고 심도 있게 연결되는 IoT 응용 분야의 경우 이러한 종류의 단방향 인증으로는 보호를 보장하기에 충분하지 않습니다. 예를 들어 허위 인증서를 보유한 해커가 폭넓은 공격 중 하나로 자신을 합법적인 서버로 가장하고 IoT 장치에 접근할 수 있습니다.

이러한 위험성에도 불구하고 IoT 개발자는 TLS 상호 인증 프로토콜을 구현하면서 어려움을 겪는 경우가 많은데, 이는 TLS를 통해 클라이언트 인증을 구현하기 위해 필요한 인증서, 키 및 소프트웨어가 여러 IoT 장치의 기능 범위를 초과할 수 있기 때문입니다. Microchip Technology와 Google은 협업하여 ATECC608A 기능을 JWT(JSON Web Token)라 불리는 단순한 데이터 구조와 결합하는 대안적 접근 방식을 고안했습니다. 그 결과 IoT 장치와 Google Cloud IoT Core 서비스 간의 상호 인증을 보증하는 손쉬운 방법을 마련했습니다.

JWT 기반 인증

RFC 7519에 명시된 JWT는 JWT를 준비 및 전송하는 엔티티에 관한 산업 표준 컨테이너로, 클레임이라 불리는 정보를 담고 있습니다. JWT 구조 자체는 다음 3가지 섹션으로 구성됩니다.

• 헤더는 토큰 및 해당 유형("typ")의 토큰(이러한 토큰의 경우 “JWT”)에 서명하는 데 사용되는 암호화 알고리즘(예: NIST P-256 곡선을 사용하는 ECDSA의 “EC256”)의 이름("alg")에 대한 JSON 이름:값 쌍을 포함합니다.
• 페이로드는 각 클레임에 대한 JSON 이름:값 쌍을 포함합니다.
• 서명은 헤더에서 지정된 알고리즘을 사용해 헤더 및 클레임 집합과 함께 비밀 키를 인코딩하며 헤더 및 클레임 집합은 암호화 전에 별도로 base64 URL로 인코딩된 표현으로 변환됩니다.

RFC 7519는 페이로드 또는 기타 섹션에서 클레임을 지정하는 데 상당한 유연성을 제공합니다. 이 표준은 서명이나 암호화 없이 생성된 비보안 JWT도 허용하며, 이 경우 헤더에 포함되는 해당 알고리즘에 대한 이름:값 쌍은 {"alg":"none"}입니다. Google Cloud IoT Core 서비스와 사용되는 JWT에 대해 Google은 다음을 포함하는 3가지 필수 클레임이 포함된 페이로드와 더불어 서명 섹션을 요구합니다.

• “iat” - “발행 시점” 시간. 1970-01-01T00:00:00Z 이후 시간을 초 단위로 표시하는 ISO 8601 UTC 시간 스탬프 형식으로 토큰이 생성된 시점을 표시합니다(예: 2019년 6월 30일 오후 12시 GMT의 경우 1561896000).
• "exp" - UTC 시간 스탬프. “iat” 값에서 최대 24시간이 경과한 시간에 서로 다른 클라이언트와 서버 간의 시스템 시계 왜곡을 고려하여 10분의 유예 시간을 더한 값으로 토큰 만료 시간을 지정합니다(예: 2019년 7월 1일 오후 12시 GMT의 경우 1561982400).
• "aud" - 개발자의 Google Cloud 프로젝트 ID가 포함된 문자열입니다.

Google의 IoT 장치 인증 체계는 TLS를 기반으로 하는 일반적인 서버 인증과 이러한 비교적 단순한 클레임으로 생성된 JWT를 사용하는 IoT 장치 인증을 혼합한 형태입니다. 새 세션을 시작하려면 IoT 장치에서는 서버에 대한 보안 소켓을 열고 앞에서 설명한 바와 동일한 TLS 프로토콜을 사용해 서버를 인증합니다.

이 공정의 다음 단계는 IoT 네트워크 트랜잭션을 위한 Google IoT 클라우드의 경량 MQTT(message queueing telemetry transport) 프로토콜 사용에 의존합니다. 인증된 서버에 보안 소켓을 사용하면 IoT 장치가 고유 JWT를 로그인 암호로 사용하여 서버의 MQTT 호스트 서비스로 로그인합니다(목록 1).

복사/* Populate the buffer with the username */int config_get_client_username(char* buf, size_t buflen){ if(buf && buflen) { int rv = snprintf(buf, buflen, "unused");  if(0 < rv && rv < buflen) { buf[rv] = 0; return 0; } } return -1;} /* Populate the buffer with the user's password */int config_get_client_password(char* buf, size_t buflen){ int rv = -1;  if(buf && buflen) { atca_jwt_t jwt;  uint32_t ts = time_utils_get_utc();  rv = atcab_init(&cfg_ateccx08a_i2c_default); if(ATCA_SUCCESS != rv) { return rv; }  /* Build the JWT */ rv = atca_jwt_init(&jwt, buf, buflen); if(ATCA_SUCCESS != rv) { return rv; }  if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "iat", ts))) { return rv; }  if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_numeric(&jwt, "exp", ts + 86400))) { return rv; }  if(ATCA_SUCCESS != (rv = atca_jwt_add_claim_string(&jwt, "aud", config_gcp_project_id))) { return rv; }  rv = atca_jwt_finalize(&jwt, 0);  atcab_release(); } return rv;}

목록 1: Google Cloud Platform IoT Core용 Microchip Technology의 소프트웨어 샘플 저장소에 포함된 모듈은 MQTT 호스트를 통한 클라이언트 인증에 암호로 사용할 가짜 사용자 이름과 JWT 개체를 생성하는 루틴을 제공합니다. (코드 출처: Microchip Technology)

IoT 장치가 이 로그인 시퀀스 일부로 사용자 이름을 전송하지만 해당 사용자 이름은 인증에 사용되지 않습니다. 결과적으로 가짜 사용자 이름이 전송됩니다(목록 2). 대신 로그인 암호로 전송된 JWT를 바탕으로 IoT 장치 인증이 진행됩니다. JWT 서명은 헤더, 페이로드 및 장치 개인 키의 조합이므로 Google Cloud IoT Core 서비스는 JWT가 실제로 인증된 장치에서 제공되었는지 검증할 수 있습니다. Google Cloud IoT 서비스는 아래에 설명된 키 관리 공정을 통해 IoT 장치 개발자가 이전에 Google Cloud에 저장했던 장치의 공개 키를 이 검증에 사용합니다. TLS 하나만 사용할 때와 대조적으로 이 접근 방식은 IoT 장치의 리소스 요구 사항을 낮추면서 공정을 가속하는 하이브리드 접근 방식으로 상호 인증을 제공합니다.

복사/* Connect the MQTT Client to the host */static int client_connect(void* pCtx){ MQTTPacket_connectData mqtt_options = MQTTPacket_connectData_initializer; struct _g_client_context* ctx = (struct _g_client_context*)pCtx; size_t buf_bytes_remaining = CLIENT_MQTT_RX_BUF_SIZE;  mqtt_options.keepAliveInterval = MQTT_KEEP_ALIVE_INTERVAL_S; mqtt_options.cleansession = 1;  /* Client ID String */ mqtt_options.clientID.cstring = (char*)&ctx->mqtt_rx_buf[0]; if(config_get_client_id(mqtt_options.clientID.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  /* Username String */ mqtt_options.username.cstring = mqtt_options.clientID.cstring + strlen(mqtt_options.clientID.cstring) + 1; buf_bytes_remaining -= (mqtt_options.username.cstring - mqtt_options.clientID.cstring); if(config_get_client_username(mqtt_options.username.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  /* Password String */ mqtt_options.password.cstring = mqtt_options.username.cstring + strlen(mqtt_options.username.cstring) + 1; buf_bytes_remaining -= (mqtt_options.password.cstring - mqtt_options.username.cstring); if(config_get_client_password(mqtt_options.password.cstring, buf_bytes_remaining)) { return MQTTCLIENT_FAILURE; }  return MQTTConnect(&ctx->mqtt_client, &mqtt_options);}

목록 2: Microchip의 소프트웨어 샘플 저장소에 제공된 이 함수는 초기 연결 단계 중에 IoT 장치를 MQTT 서버에 인증하는 암호로 JWT 개체를 사용하는 과정을 보여줍니다. (코드 출처: Microchip Technology)

중대한 조력자

ATECC608A 및 그 공급망의 기능은 이 접근 방식에서 중대한 역할을 합니다. 모든 MCU는 결국 JWT 헤더 및 페이로드에서 암호화된 서명을 생성할 수 있지만 하드웨어 기반의 보안 키 저장소 없이 소프트웨어만으로 수행된 모든 접근 방식은 여전히 취약합니다. 또한 “소프트웨어만” 이용한 구현에 필요한 프로세서 부하 및 실행 지연은 엄격한 응답 시간 요구 사항으로 인해 수많은 리소스가 제한된 IoT 장치나 응용 제품에서 감당하기 어려울 수 있습니다. 마지막으로 보안 알고리즘과 더 높은 수준의 프로토콜에 관한 광범위한 경험을 갖추지 못한 개발자가 필요한 소프트웨어 기능을 구현하기란 상당히 까다롭습니다. Microchip은 CryptoAuthLib 라이브러리를 통해 이러한 문제를 해소합니다(그림 2).

그림 2: CryptoAuthLib에서 하드웨어 추상화 계층(HAL)을 이용해 기저의 하드웨어에서 API 기능과 주요 기본 요소를 분리하므로 개발자가 광범위한 지원 장치를 목표로 소프트웨어를 개발할 수 있습니다. (이미지 출처: Microchip Technology)

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

하지만 정교한 소프트웨어와 보안 장치를 사용하더라도 키 및 인증서를 관리하는 데 필요했던 기존 방법으로 인해 IoT 장치가 취약한 상태를 벗어나지 못할 수도 있습니다. 과거에는 개인 키가 제조, 유통 또는 배포 중 외부적으로 생성되어 보안 저장소 장치에 로드되어야 했습니다. 하드웨어 보안 모듈과 보안 시설을 사용하더라도 이러한 비밀이 이를 “알아야 할” 유일한 장치의 외부에 잠시 존재한다는 사실은 개인 키가 사고 또는 의도적으로 노출될 수 있다는 보안 약점을 드러냅니다. Microchip과 Google은 ATECC608A의 기능을 활용해 이러한 전통적인 보안상의 약점을 상당 부분 줄일 수 있었습니다.

이 새로운 접근 방식에서 Microchip은 개인 키가 장치를 이탈하는 일 없이 키 쌍을 생성하는 ATECC608A의 기능을 사용합니다(그림 3). 그런 다음 Microchip은 고객이 제공하고 Microchip 보안 시설 내 보안 서버에 저장된 중간 인증서로 장치에서 생성한 공개 키에 서명합니다. 마지막으로 Microchip은 이 공개 키를 Google Cloud IoT Device Manager의 고객 계정으로 안전하게 전송하며 여기에는 키 순환 정책을 지원하도록 각 장치에 공개 키를 최대 3개 저장할 수 있습니다. 배포된 IoT 장치는 ATECC608A 보안 기능을 사용하여 앞에서 설명한 상호 인증 공정에 사용될 JWT를 생성할 수 있습니다.

그림 3: Microchip Technology 및 Google Cloud IoT 서비스는 키 및 인증서 제공을 단순화하기 위해 결합되어 IoT 응용 제품의 보안을 강화하도록 고안된 보호 메커니즘을 제공합니다. (이미지 출처: Google)

Microchip과 Google 간의 협업 덕분에 개발자는 이 중대한 키 관리 공정의 부담에서 완전히 벗어날 수 있게 되었습니다. 그렇지만 개발자는 고객의 요구 사항을 위해 ATECC608A가 키 쌍을 생성하고, 보안 저장소에 개인 키를 보관하고, 관련 공개 키를 반환하게 하는 CryptoAuthLib API 함수 atcab_genkey()를 이용해 자체 키 관리 공정을 구현할 수도 있습니다.

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

개발자는 ATECC608A를 포함한 CryptoAuthentication 장치를 평가하기 위해 CryptoAuth XPRO-B 애드온 기판을 Xplained Pro 기판의 두 확장 헤더 중 하나에 끼워볼 수 있습니다. Microchip은 ATECC608A가 포함된 CryptoAuthLib의 보안 기능을 평가하는 샘플 소프트웨어를 제공합니다. 또한 개발자는 Microchip의 ATWINC1500-XPRO Wi-Fi 애드온 기판을 다른 헤더에 끼워 이 기사에 설명된 TLS 서버 인증과 JWT 장치 인증을 모두 포함한 상호 인증 흐름을 시연하는 Microchip의 샘플 소프트웨어를 실행할 수도 있습니다.

결론

IoT 응용 제품의 보안이 여러 요구 사항을 제시하지만 가장 중요한 문제는 IoT 장치 및 클라우드 리소스에 관한 상호 인증을 구현하는 데 있는 경우가 많습니다. 리소스가 제한되는 IoT 시스템에서 기존의 프로토콜은 사용 가능한 메모리 및 처리 리소스를 초과할 수 있습니다. 개발자는 Microchip Technology의 CryptoAuthLib 라이브러리 및 ATECC608A CryptoAuthentication IC를 사용하여 IoT 장치를 Google Cloud IoT 서비스에 안전하게 연결하도록 JSON Web Token을 토대로 더 효율적인 접근 방식을 구현할 수 있습니다.