KR20200066288A - 애셋 업데이트 서비스 - Google Patents

Abstract

복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터(service requester)들에 대한 애셋 업데이트(asset update)를 관리하기 위한 방법이며, 이 방법은 관리 서버에서, 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하는 단계; 관리 서버에서, 업데이트가 적용될 원격 디바이스들의 서브세트를 표시하는, 업데이트 데이터와 연관된 캠페인 데이터를 수신하는 단계; 및 관리 서버에서, 원격 디바이스의 애셋을 업데이트하기 위해 애셋이 검색될 것임을 나타내는 업데이트 통신을, 원격 디바이스들의 서브세트에 송신함으로써 펌웨어 업데이트를 개시하도록 하는 요청을 수신하는 단계를 포함한다.

Description

애셋 업데이트 서비스

본원은 써드 파티에 의해 관리될 수 있는 자동화되고 신뢰할 수 있는 방식으로, 서비스가 네트워크 연결된 전자 디바이스들의 펌웨어 또는 다른 애셋 데이터를 업데이트할 수 있게 하는 메커니즘에 관한 것이다.

원격 전자 디바이스들은 서버에 연결되어 해당 서버와 통신하도록 구성될 수 있다. 서버는 디바이스들과의 작동 및 통신을 관리하도록 구성될 수 있다. 사물 인터넷(IoT) 응용과 같은 다수의 응용들에서는, 서버에 연결되어 해당 서버에 의해 유사하거나 동일한 방식으로 관리되도록 구성된 다수의 유사하거나 동일한 디바이스들이 존재할 수 있다.

디바이스들이 안전하고 신뢰할 수 있는 방식으로 작동하려면, 코드, 키 및/또는 디바이스 구성과 같은 디바이스들의 애셋들에 대한 업데이트를 제공해야 한다. 예를 들어, 보안 결함을 해결하거나 디바이스의 동작을 수정하기 위해, 디바이스에서 작동하는 펌웨어를 업데이트해야 할 수 있다. 다수의 이러한 응용들에서, 디바이스들은 물리적으로 상이하거나 접근 불가능하거나 너무 많아서 각 디바이스의 펌웨어를 개별적으로 직접 및 수동으로 업데이트하는 것은 불가능하다.

따라서, 원격 전자 디바이스들의 애셋들(예를 들어 펌웨어)이 업데이트되는 방식을 개선할 필요가 있다.

복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터(service requester)들에 대한 애셋 업데이트(asset update)를 가능하게 하는 방법이 제공되며, 이 방법은 관리 서버에서, 제 1 서비스 리퀘스터를 위한 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하는 단계 - 업데이트 데이터는 페이로드(payload)가 저장된 위치를 나타내는 페이로드 URI(Uniform Resource Identifier)를 포함하는 매니페스트 데이터(manifest data), 매니페스트 데이터의 신뢰성을 나타내는 인증 정보, 및 페이로드 해시(payload hash)를 포함함 -; 관리 서버에서, 애셋 업데이트가 제 1 서비스 리퀘스터에 대해 적용될 원격 디바이스들의 적어도 하나의 서브세트를 표시하는, 업데이트 데이터와 연관된 캠페인 데이터(campaign data)를 수신하는 단계; 및 관리 서버에서, 원격 디바이스를 업데이트하기 위해 페이로드가 검색될 것임을 나타내는 매니페스트 데이터를 포함하는 업데이트 통신을, 캠페인 데이터에 의해 표시된 원격 디바이스들의 적어도 하나의 서브세트에 송신함으로써 제 1 서비스 리퀘스터에 대한 애셋 업데이트를 개시하도록 하는 요청을 수신하는 단계를 포함한다.

복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터들에 대한 애셋 업데이트를 가능하게 하는 관리 서버가 제공되며, 이 관리 서버는 관리 서버에서, 제 1 서비스 리퀘스터를 위한 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하고 - 업데이트 데이터는 페이로드가 저장된 위치를 나타내는 페이로드 URI(Uniform Resource Identifier)를 포함하는 매니페스트 데이터, 매니페스트 데이터의 신뢰성을 나타내는 인증 정보, 및 페이로드 해시를 포함함 -; 관리 서버에서, 애셋 업데이트가 제 1 서비스 리퀘스터에 대해 적용될 원격 디바이스들의 적어도 하나의 서브세트를 표시하는, 업데이트 데이터와 연관된 캠페인 데이터를 수신하며; 또한 관리 서버에서, 원격 디바이스를 업데이트하기 위해 페이로드가 검색될 것임을 나타내는 매니페스트 데이터를 포함하는 업데이트 통신을, 캠페인 데이터에 의해 표시된 원격 디바이스들의 적어도 하나의 서브세트에 송신함으로써 제 1 서비스 리퀘스터에 대한 애셋 업데이트를 개시하도록 하는 요청을 수신하도록 하는 적어도 하나의 인터페이스를 포함한다.

첨부 도면을 참조하여 본 개시의 예들이 설명될 것이다.
도 1은 일 예에 따른 시스템도를 도시한 것이다.
도 2는 캠페인에 따라 펌웨어 업데이트를 개시하기 위한 예시적인 방법의 흐름도를 도시한 것이다.
도 3은 매니페스트를 생성하기 위한 예시적인 방법의 흐름도를 도시한 것이다.
도 4는 매니페스트를 관리 서버에 업로드하기 위한 예시적인 워크 플로우를 도시한 것이다.
도 5는 페이로드를 관리 서버에 업로드하기 위한 예시적인 워크 플로우를 도시한 것이다.
도 6은 캠페인을 생성하기 위한 예시적인 워크 플로우를 도시한 것이다.
도 7은 캠페인을 처리하기 위한 예시적인 워크 플로우를 도시한 것이다.
도 8은 캠페인의 진행 상황을 모니터링하기 위한 예시적인 워크 플로우를 도시한 것이다.
도 9는 다수의 서비스 리퀘스터들을 포함하는 추가 예에 따른 추가 시스템도를 도시한 것이다.

본 출원은 하나 이상의 원격 디바이스들의 애셋 업데이트가 자동화되고 신뢰할 수 있는 방식으로 가능하게 될 수 있는 장치 및 방법의 제공에 관한 것이다. 애셋 업데이트는 업데이트 캠페인 실행에 대한 책임을 여러 가지 기술적 이점이 있는 업데이트 서비스에 위임할 수 있는 기능을 써드 파티에게 제공한다. 위임의 한 측면은 써드 파티가 업데이트 서비스를 신뢰하여 업데이트를 롤아웃(roll out)하는 것을 원치 않을 수도 있다는 것이다.

본 업데이트 서비스는 써드 파티와 디바이스 간의 확립된 신뢰 관계에 기초하여, 써드 파티가 서비스를 신뢰하지 않고서도 써드 파티를 대신하여 서비스가 업데이트를 수행할 수 있게 하는 방법을 제공한다. 또한, 업데이트 서비스가 반드시 페이로드에 직접 액세스할 필요가 없으며 해당 페이로드를 디바이스들로 직접 전달하지 않아도 된다. 따라서, 실시예들에서, 펌웨어 업데이트의 소유자와 디바이스 관리 엔티티(즉, 제 1 서비스 리퀘스터)는 동일한 엔티티일 필요가 없다.

원격 디바이스가 이미 써드 파티와 확립된 레벨의 신뢰성을 갖고 있기 때문에, 써드 파티가 페이로드 URI를 포함하는 서비스 매니페스트 데이터(manifest data), 매니페스트 데이터의 신뢰성을 나타내는 인증 정보, 및 원격 디바이스로의 전송을 위한 페이로드 해시(payload hash)를 제공하는 것에 의해서, 원격 디바이스는 신뢰할 수 있는 방식으로 애셋 업데이트를 수행하는데 필요한 모든 것을 구비하게 된다. 이에 따라, 매니페스트 정보가 서비스에 배포될 수 있고 서비스 신뢰성을 요구함 없이 다수의 원격 디바이스들에 제공될 수 있다. 이는 원격 디바이스가 (인증 정보로 인해) 매니페스트 데이터를 신뢰할 수 있으며 따라서 제 1 서비스 리퀘스터와 원격 디바이스 간의 신뢰 관계에 기반하여, 페이로드 URI를 신뢰할 수 있기 때문이다. 페이로드 URI를 신뢰할 수 있으므로, 원격 디바이스는 애셋을 검색하는 URI가 유효한 것으로 확신할 수 있다. 또한, 페이로드 해시도 신뢰할 수 있기 때문에, 디바이스는 검색된 해시의 인증을 수행할 수 있으며 따라서 획득된 페이로드를 신뢰할 수 있다.

또한, "제 1 서비스 리퀘스터"는 다수의 상이한 통신 프로토콜들 및 상이한 처리 능력들을 포함할 수 있는, 다수의 상이한 원격 디바이스들에 접속하기 위해 잠재적으로 관계되는 복잡한 기술 능력을 필요로 하지 않는다. 따라서, 제 1 서비스 리퀘스터는 디바이스와 직접 통신할 수 있는 능력을 가질 필요가 없다. 이러한 접근 방식은 디바이스 소유자가 디바이스 통신 인에이블러를 신뢰하지 않아도 되는 방식으로 디바이스 소유자와 디바이스 통신 인에이블러 간의 책임 분리를 가능하게 한다.

다음의 설명은 단지 예시의 방식에 의해서 다수의 예들을 제시하는 것이다.

도 1은 본 기술이 구현될 수 있는 컴퓨팅 시스템(100)을 도시한 것이다.

컴퓨팅 시스템(100)은 관리 서버(120)에 통신 가능하게 커플링된 복수의 원격 전자 디바이스들(110)을 포함한다. 원격 전자 디바이스들(110)은 사물 인터넷(IoT) 디바이스들과 같은, 개별적으로 위치될 수 있는 전자 디바이스들이다. 원격 전자 디바이스들(110)은 상이한 네트워크들 또는 동일한 네트워크를 통해 관리 서버(120)에 연결될 수 있다. 예를 들어, 원격 전자 디바이스들(110)은 유선 또는 무선 연결을 통해 관리 서버(120)에 연결될 수 있다.

관리 서버(120)는 원격 디바이스들 및 관리 서버(120)에 대한 그들의 각각의 연결들을 관리하도록 구성된 컴퓨팅 서버(또는 서버들)이다. 관리 서버를 사용하면 디바이스들의 애셋들을 디바이스들의 소유자 또는 관리자가 관리 및 유지할 수 있다. 디바이스들의 소유자 또는 관리자는 그것이 담당하는 디바이스들의 하나 이상의 애셋들이 업데이트될 것을 요구할 수 있으며, 따라서 해당 요청과 관련된 원격 디바이스들(110)의 업데이트를 관리 서버(120)들에게 요청하는 리퀘스터가 된다. 관리 서버(120)는 원격 디바이스들의 업데이트가 관리될 수 있는 하나 이상의 인터페이스들을 제공할 수 있다. 이것은 포털을 통해 제공된 데이터를 수신하고/하거나 REST API와 같은 API(Application Programming Interface) 게이트웨이를 통해 데이터를 수신하는 인터페이스를 통해 제공될 수 있다.

도 1의 구성에서, 관리 서버(120)는 새로운 펌웨어와 같은 새로운 애셋들을 원격 디바이스들(110)에 제공하여 새로운 애셋들이 디바이스를 업데이트하기 위해 원격 디바이스들(110)에 로딩될 수 있도록 구성될 수 있다. 원격 디바이스의 애셋들로는 코드(예를 들면, 펌웨어 또는 부트로더(bootloader)), 키 프로비저닝 또는 배포, 또는 구성 설정 중의 하나 이상을 포함할 수 있다. 업데이트 펌웨어의 예에서, 새로운 펌웨어가 원격 디바이스들(110)에 로드되어야 하는 많은 이유들이 있을 수 있다. 예를 들어, 펌웨어는 원격 디바이스의 중요한 펌웨어 버그를 수정하거나 또는 디바이스치에 새로운 기능을 추가할 수 있다. 관리 서버(120)는 본 명세서에서 클라우드 업데이트 서비스로 지칭되는 소프트웨어를 포함할 수 있으며, 이것은 원격 디바이스들(110)의 업데이트 관리를 제어하도록 구성된다. 후술하는 바와 같이, 관리 서버(120)는 업데이트 프로세스가 안전하게 되는 것을 보장하도록 동작한다. 펌웨어가 인증되었거나(예를 들어, 악성 펌웨어를 플래시하려는 시도가 방지됨) 펌웨어가 암호화될 수 있는 것으로 결정함으로써 보안이 제공될 수 있다. 관리 서버(120)는 업데이트가 관리 서버(120)로부터 원격 디바이스(110)로 푸시되도록 구성될 수 있으며, 이에 따라 원격 디바이스(110)는 지속적으로 업데이트를 폴링할 필요가 없어서, 디바이스가 더욱 에너지 효율적이게 된다.

시스템(100)은 예를 들어 포털 및 API를 통해 관리 서버(120)에 통신 가능하게 커플링된 개발자 디바이스(130)를 더 포함한다. 개발자 디바이스(130)는 펌웨어 및 해당 메타데이터가 관리 서버(120)에 제공되는 전자 디바이스이다. 이 프로세스는 나중에 더 자세히 설명될 것이다. 개발자 디바이스는 관리 서버(120)가 디바이스의 애셋들에 대한 업데이트를 서비스로서 제공하도록 요청하는 서비스 리퀘스터의 일부를 형성할 수 있다. 개발자 디바이스는 개발자가 원격 디바이스들(110)에 적용될 펌웨어 이미지(또는 다른 애셋 데이터)를 제공할 수 있는 디바이스일 수 있다.

시스템(100)은 관리 서버(120)에 통신 가능하게 커플링된 조작자 디바이스(140)를 더 포함한다. 조작자 디바이스는 디바이스들의 소유자에 의해 원격 디바이스의 관리가 처리될 수 있는 전자 디바이스이다. 따라서, 조작자 디바이스(140)는 원격 디바이스들의 애셋들의 업데이트를 요청하는 서비스 리퀘스터의 일부를 형성한다. 개발자 디바이스(130)를 동작시키는 개발자는 조작자 디바이스(140)를 동작시키는 동일한 엔티티일 수 있거나, 이 엔티티들이 별개의 엔티티들일 수도 있다.

원격 디바이스들(100) 상의, 펌웨어 업데이트와 같은, 애셋들의 업데이트가 관리 서버에 의한 서비스로서 제공되며, 개발자 디바이스(130)로부터의 업데이트 데이터 및 조작자 디바이스(140)로부터의 캠페인 데이터의 통신 결과로서 개시된다. 원격 디바이스들(100)을 업데이트하기 위해, 이들 2개의 엔티티 각각은 서비스 리퀘스터를 대신하여 관리 서버(120)에 의해 관리될 업데이트 프로세스를 집합 적으로 정의하는 각각의 데이터 세트를 제공한다. 개발자 디바이스(130)는 업데이트된 펌웨어 데이터와 같은 업데이트된 애셋의 개발자에 의해 조작되거나 관리될 수 있는 디바이스이다. 이것은 펌웨어를 개발하는 개발자의 위치가 관리 서버(120)의 위치와 분리될 수 있게 한다.

업데이트 데이터는 개발자 디바이스(130)에 의해 제공될 수 있다. 업데이트 데이터는 원격 디바이스(110) 상에서 업데이트될 애셋 및 해당 애셋의 업데이트가 이루어지는 방식에 관한 표시를 제공한다. 예를 들어, 업데이트 데이터는 업데이트될 애셋의 새로운 값 및 원격 디바이스가 새로운 값을 취하기 위해 원격 디바이스에서 충족되어야 하는 기준을 포함할 수 있다. 일부 예들에서, 업데이트 데이터는 페이로드(payload) 데이터 및 매니페스트(manifest) 데이터를 포함할 수 있다.

페이로드 데이터는 원격 디바이스들에 적용될 업데이트된 애셋의 값들을 정의한다. 예를 들어, 업데이트될 애셋이 디바이스의 펌웨어인 경우, 페이로드 데이터는 하나 이상의 원격 디바이스들(110)에 설치될 펌웨어 이미지 데이터를 정의할 수 있다. 페이로드 데이터는 업데이트된 펌웨어를 정의하는 것일 수 있고, 펌웨어 이미지일 수도 있다. 매니페스트 데이터는 페이로드와 관련된 메타데이터(예를 들면, 로컬 디바이스에서 업데이트되는 방법 또는 저장 위치)를 나타낸다. 매니페스트 데이터로서 저장될 수 있는 정보의 유형에 관한 보다 상세한 내용은 아래에서 설명될 것이다. 일 예로서, 매니페스트 데이터는 페이로드를 찾아내는 위치(예를 들면, 페이로드의 URI), 페이로드 데이터가 적용되는 디바이스 타입 및 적용 시에 페이로드 데이터를 신뢰할지 여부를 결정하는 방법을 정의할 수 있다. 매니페스트 데이터는 개발자 디바이스(130)에서 동작하는 매니페스트 툴에 의해 개발자 디바이스(130)에서 생성될 수 있다. 관리 서버(120)는 개발자(130)로부터 업데이트 데이터를 수신하고, 일부 예들에서, 매니페스트 데이터를 원격 디바이스(110)에 전송하여 이미지를 어디에서 획득하고 어떤 조건 하에서 그것을 다운로드 및 적용할 것인지에 대한 개발자의 지시들을 전달하도록 구성된다. 매니페스트 데이터 및 페이로드 데이터라는 용어는 본 명세서에서 펌웨어 이미지 또는 완전한 매니페스트 데이터와 같은 데이터 자체를 지칭하는 것으로 사용된다. 그러나, 본 명세서에서 매니페스트 데이터 및/또는 페이로드 데이터를 전송한다는 것에 대한 언급은 수신 엔티티가 데이터에 개별적으로 액세스할 수 있는 위치를 나타내는 URI를 전송하는 것을 포함할 수 있음을 이해할 것이다.

조작자 디바이스(140)는 특정 세트의 업데이트 데이터와 관련된 캠페인 데이터를 관리 서버(120)에 제공할 수 있다. 조작자 디바이스(140)는 디바이스들의 소유자 또는 디바이스들의 관리를 담당하는 엔티티(예를 들어, 어떤 디바이스들이 어떤 방식으로 업데이트될지를 결정하는 엔티티)에 의해 동작되거나 관리될 수 있는 디바이스이다. 업데이트 캠페인은 원격 디바이스(110)가 업데이트되는 전략(strategy)으로 간주될 수 있으며, 캠페인 데이터에 의해 정의된다. 특정 업데이트 캠페인에 대한 캠페인 데이터는 매니페스트를 디바이스 필터와 커플링시키도록 구성되어 있다. 디바이스 필터는 관리 서버(120)와 통신 가능하게 커플링된 원격 디바이스들(110) 중 어느 것이 업데이트되어야 하는지를 나타낸다. 이러한 방식으로, 디바이스 필터는 관리 서버(120)와 통신 가능하게 연결된 모든 원격 디바이스들에 적용될 필터를 식별하여, 업데이트가 적용될 원격 디바이스(110)의 서브세트를 선택한다. 이와 같이, 관리 서버(120)는 업데이트 캠페인의 캠페인 데이터를 사용하여 디바이스 필터와 매칭되는 모든 디바이스들에 매니페스트를 전송하도록 구성될 수 있다. 일부 구현들에서, 매니페스트는 둘 이상의 업데이트 캠페인에 포함되어, 이것을 상이한 필터들과 커플링시킬 수 있다. 이것은 조작자 디바이스(140)가 그 배치(batch)와 연관된 디바이스 필터에 따라 원격 디바이스들의 서브세트만을 타겟으로 하는 각각의 업데이트 캠페인과 함께, 원격 디바이스들(110)의 업데이트를 배치 방식으로 관리할 수 있게 한다.

매니페스트 포맷

위에서 언급한 바와 같이, 업데이트될 애셋(예를 들어, 펌웨어 이미지)에 대한 페이로드 데이터는 업데이트가 발생하는 방식을 나타내는 매니페스트(예를 들면, 메타데이터)와 별개이다. 페이로드를 매니페스트에서 분리하는 것에 의하여, 페이로드 배포가 단순화된다. 예를 들어, 단일의 페이로드(예를 들면, 펌웨어 이미지)가 개별 디바이스들에 전송될 수 있다. 또한 나중에 설명되는 바와 같이, 메타데이터를 통해 신뢰가 확립되어 있기 때문에, 신뢰하지 않아도 되는 컨텐츠 배포 네트워크를 통해 펌웨어 이미지를 배포할 수 있게 된다.

원격 디바이스가 특정 애셋의 업데이트를 적용하려면, 수신한 업데이트가 신뢰되어야 하는지 것인지 및 적용되어야 하는 것인지를 결정해야 한다. 예를 들어, 디바이스는 업데이트 작성자가 신뢰될 수 있는지 여부, 업데이트가 손상되었는지 여부, 업데이트가 디바이스에 적용되는지 여부, 업데이트가 최신 상태인지 여부, 업데이트가 적용되어야 하는 시점을 알 필요가 있을 수도 있다.

따라서, 디바이스가 업데이트 적용 여부를 결정할 수 있도록 하기 위해 하나 이상의 필드로부터 매니페스트가 도출될 수 있다. 매니페스트의 필드들은 관리 서버(120)에 제공되는 매니페스트 데이터를 형성한다. 매니페스트를 형성하는 인코딩을 생성하는데 다수의 필드들이 사용될 수 있다. 매니페스트가 도출되는 필드는 다음 중 하나 이상을 포함할 수 있다:

ㆍ 매니페스트 및 해당 인증서에 서명하는 개인 키;

ㆍ 사용된 서명 및 암호화 타입을 나타내는 데이터;

ㆍ 매니페스트가 생성된 타임 스탬프;

ㆍ 펌웨어 개발자 및/또는 원격 디바이스 제조자를 식별하는 제조자 ID;

ㆍ 업데이트가 적용되는 디바이스들의 클래스를 식별하는 디바이스 클래스 ID;

ㆍ 예를 들어 파일 형태 및/또는 페이로드에 대한 링크(예를 들어 URL) 형태의 페이로드;

ㆍ 페이로드 타입;

ㆍ 원격 디바이스(110)가 페이로드를 페치해야 하는 URL;

ㆍ 디바이스가 페이로드를 저장해야 하는 위치를 나타내는 저장 식별자;

ㆍ 예를 들어 디바이스의 부하를 기준으로, 페이로드가 설치되어야 하는 조건들을 나타내는 설치 조건 데이터;

ㆍ 예를 들어 가장 빠른 시간과 가장 늦은 시간을 정의하는 것에 의해, 페이로드의 설치가 발생해야 하는 시간 윈도우를 나타내는 설치 시간 데이터; 및

ㆍ 예를 들어 펌웨어 이미지의 해시 및 신뢰할 수 있는 개발자의 시그니처를 포함하는, 매니페스트의 신뢰성을 나타내는 인증 정보.

원격 디바이스(110)에 매니페스트를 제공함으로써, 원격 디바이스(110)는 수신된 업데이트의 설치 여부를 결정할 수 있다. 이 프로세스의 일부로서, 원격 디바이스(110)는 업데이트가 관리 서버(120)로부터 수신된 유효한 업데이트인지 여부를 결정하도록 동작한다. 도 1의 시스템은 악의적인 써드 파티가 원격 디바이스(110)와 통신할 수 없도록 하여 보안 결함을 포함하는 비인가 펌웨어와 같은 비인가 애셋을 원격 디바이스(110)에 강제로 설치할 수 없도록 하는 보안 특징들을 구현할 수 있다.

데이터 검증

매니페스트를 보호하기 위해, 관리 서버(120) 및 개발자 디바이스(130)는 공개 키 암호화와 같은 암호화 방법을 사용하도록 구성된다.

일 예에서, 각각의 원격 디바이스(110) 및 개발자 디바이스(130)는 공개 키 암호화의 일 타입인, 타원 곡선 암호화(elliptic curve cryptography, ECC)를 이용하도록 구성된다(다른 공개 키 암호화 기술들이 대신 사용될 수도 있음). 일 예에서, 개발자 디바이스(130) 및 원격 디바이스(110)에서 동작하는 매니페스트 툴은 타원 곡선 디지털 시그니처 알고리즘(Elliptic Curve Digital Signature Algorithm)을 사용한다. 이 알고리즘은 두 가지 정보, 즉 시크리트(개인 키라고도 함) 및 시크리트에 대응하는 번호(공개 키라고도 함)를 사용한다.

매니페스트에 서명하기 위해, 개인 키의 소유자(개발자 디바이스(130))는 먼저 SHA256을 사용하여 매니페스트의 해시를 계산한 다음, 개인 키를 사용하여 해당 해시를 변환한다. 이 새로운 번호(시그니처라고도 함)가 매니페스트에 추가된다. 나중에, (각 원격 디바이스(110)와 같은) 공개 키를 가진 사람이 SHA256을 사용하여 문서의 해시를 계산하고, 공개 키를 사용하여 시그니처를 다시 해시로 변환하고, 계산된 해시와 시그니처 해시를 비교함으로써 시그니처가 문서와 매칭된다는 것을 검증할 수 있다.

해시들이 동일한 경우, 검증자는 서명자가 개인 키를 소유하고 있다고 확신할 수 있다. 개인 키를 사용하여 행해진 변환의 예가 많이 있더라도, 공개 키로부터 개인 키를 결정하는 것은 계산적으로 어려운 문제이기 때문이다.

공개 키들은 일반적으로 공개 키들 및 이들의 소유자에 대한 추가 정보를 포함하는, 인증서 안에 패키지된다. 이 인증서는 다른 기관(인증 기관)에 의해서 또는 자체적으로(자체 서명된 인증서에 의해) 서명된다. 인증서들은 일반적으로 인증서의 해시(예를 들면, 인증서의 SHA256 해시)와 같은 핑거프린트에 의해서 식별된다.

원격 디바이스는 NIST 권장 곡선인 ECC 곡선 ecc-secp256r1을 사용할 수 있다. 계산이 제한된 플랫폼들에서는 감소된 키 사이즈 및 더 높은 성능으로 인해 원격 디바이스들에서 RSA 대신에 ECC를 사용할 수 있다.

신뢰성은 디바이스, 특히 펌웨어 업데이트의 동작을 수정할 수 있는 모든 작업에 중요하다. 펌웨어 업데이트들의 신뢰성을 검증하면 인터넷에 노출된 디바이스들(예를 들면, 원격 디바이스들(110))이 설계자가 의도한 대로 작동하도록 유지하는 것을 도울 수 있으며; 검증하지 않으면 디바이스들이 손상되거나 파손될 수 있다.

시그니처는 펌웨어에 대한 무결성 및 신뢰성 검증을 모두 제공한다. 기관에 관계없이, 제공된 시그니처가 펌웨어와 매칭되는 경우, 원격 디바이스(110)는 그 시그니처에 대한 개인 키의 소유자가 펌웨어를 승인했다고 확신할 수 있다. 이것은 디바이스에 펌웨어를 전송할 경우 또는 전송 중에 펌웨어를 수정할 경우 누군가를 사칭하는 것을 방지한다.

디바이스들은 매칭되는 인증서를 신뢰함으로써, 개인 키를 몰라도 신뢰할 수 있는 개인 키를 결정할 수 있다. 개인 키들이 적절히 보호되는 경우, 이것으로 인해 디바이스는 인증된 펌웨어만을 설치하게 된다.

매니페스트가 개발자 디바이스(130)에서 개인 키에 의해 서명됨으로서, 시그니처를 생성한다. 원격 디바이스(110)는 검증 인증서를 사용하여 매니페스트의 시그니처를 검증한다. 매니페스트는 검증 인증서와 동일한 개인 키를 사용하여 생성된 경우에만 유효한 시그니처를 갖게 되며, 이는 그것을 생성한 사람은 해당 키에 액세스할 수 있다는 것을 의미한다. 시그니처가 매칭되는 경우, 매니페스트에 권한이 부여된다. 원격 디바이스는 부정확하게 서명된 매니페스트를 거부하게 된다.

또한 매니페스트는 페이로드(예를 들면, 펌웨어 이미지)의 해시(예를 들면, SHA256 해시)를 포함할 수도 있다. 매니페스트에 서명이 되어 있으므로, 다운로드 방법에 관계없이, 매니페스트는 의도된 이미지의 전체 및 변경되지 않은 사본을 설치하는데만 사용될 수 있다.

캠페인 관리 업데이트

전술한 바와 같이, 조작자 디바이스(140)는 원격 디바이스들(110) 중 어느 것이 애셋의 업데이트에 의해 영향을 받는지를 나타내는 디바이스 필터를 포함하는 업데이트 캠페인을 위한 캠페인 데이터를 관리 서버로 송신하도록 구성될 수 있다. 그 후에, 업데이트 캠페인이 관리 서버(120)에 업로드될 경우, 캠페인이 시작되고 모니터링될 수 있다.

업데이트 캠페인을 개시하는 예시적인 프로세스에 대하여 도 2와 관련하여 설명한다. 도 2의 프로세스(200)는 개발자가 예를 들어 펌웨어 이미지 형태로 페이로드를 생성하는 단계 210에서 시작된다. 이 단계는 개발자 디바이스(130)에서 발생할 수 있거나, 또는 페이로드 데이터가 개발자 디바이스(130)로 전달되는 별도의 디바이스에서 발생할 수도 있다. 일부 구성들에서는, 이 단계에서 펌웨어만이 빌드되고 부트로더는 변경되지 않는다. 일부 구성들에서는, 원본 애플리케이션의 메모리 레이아웃이 새로운 애플리케이션에서 유지될 수 있다.

단계 220에서, 페이로드 데이터(예를 들어, 펌웨어 이미지)가 개발자 디바이스(130)로부터 관리 서버(120)로 송신되고 관리 서버 또는 다른 원격 디바이스(도 1에 도시되지 않음)에 저장된다. 일부 구성들에서, 페이로드 데이터가 원격 디바이스들이 기지의(known) 위치로부터 페이로드에 액세스할 수 있도록 개발자 디바이스(130)에 의해 정의된 바와 같이(예를 들어 하나 이상의 매니페스트에서) 사용자 리소스 로케이터(user resource locator, URL)에 저장될 수 있다. 일부 구성들에서, 관리 서버(120)는 전술한 바와 같이, 관리 서버로의 업로드가 API(application programming interface)에 의해 수행될 수 있게 할 수 있다. 일부 구성들에서, 관리 서버는 포털 및 API 게이트웨이를 통해 페이로드가 업로드될 수 있게 할 수 있다. 이러한 구성들에서, 관리 서버(120)는 페이로드의 저장된 위치를 나타내는 URL을 개발자 디바이스(130)로 리턴할 수 있다. 그 후에 이 리턴된 URL이 매니페스트에서 사용될 수 있다. 일부 구성들에서는, 페이로드가 암호화될 수 있다.

단계 230에서, 원격 디바이스들(110)의 애셋(예를 들어, 펌웨어)의 업데이트가 처리되어야 하는 방식을 정의하는 매니페스트 데이터가 생성된다. 매니페스트는 개발자 디바이스(130)에서 생성될 수 있고/있거나 관리 서버(120)로 송신하기 위해 외부에서 생성되어 개발자 디바이스(130)로 전달될 수도 있다. 매니페스트는 개발자 디바이스(130)(또는 다른 디바이스)에서 실행되는 매니페스트 툴에서 생성될 수 있다. 앞서 언급한 바와 같이, 매니페스트는 전술한 바와 같은 원격 디바이스들의 업데이트가 발생하는 방식을 정의하는 하나 이상의 필드를 포함할 수 있다. 또한, 매니페스트는 예를 들어 공개 키 암호화 기술을 사용하여 생성된 매니페스트 시그니처를 포함할 수 있다. 매니페스트는 또한 단계 210 및 220에서 생성되고 송신된 페이로드의 해시를 포함할 수 있다.

단계 240에서, 매니페스트는 개발자 디바이스(130)로부터 관리 서버(120)로 송신될 수 있다. 매니페스트 및 페이로드의 생성 및 송신이 함께 발생할 수 있음을 이해할 것이다. 달리 말하면, 단계 210 및 230이 조합될 수도 있고, 단계 220 및 240이 조합될 수도 있다.

매니페스트는 매니페스트 툴을 사용하여 여러 가지 방법 중 하나로 생성될 수 있다. 예를 들어, 매니페스트 툴은 매니페스트를 생성하는데 사용되는 정보를 포함하는 입력 파일(예를 들면, JSON 입력 파일)을 파싱할 수 있다. 입력 파일에 정보가 누락된 경우, 매니페스트 툴은 입력 파일에 누락된 필드의 디폴트 값을 포함하는 디폴트 파일을 확인할 수 있다. 대안적으로, 매니페스트 툴은 생성된 매니페스트에 삽입될 필드를 정의하는 명령어 라인 인수(command line argument)를 수신하여 매니페스트를 생성할 수 있다.

일부 구성들에서, 암호화되지 않은 페이로드를 갖는 매니페스트는 적어도 (i) 사용할 암호화 모드(예를 들면, none-ecc-secp256r1-sha256), (ii) 페이로드 URI(uniform resource identifier), (iii) 매니페스트 서명에 사용될 인증서의 URI 또는 매니페스트 서명에 사용될 로컬 파일 중 하나, (iv) 해당 인증서의 서명 키인 로컬 파일 및 (v) 벤더 ID 및 디바이스 클래스 ID, 또는 디바이스 ID 중 하나(매니페스트가 적용되는 디바이스들을 식별하기 위해)를 포함할 수 있다.

이 모드에서, 매니페스트 툴은 서명된 매니페스트를 생성하며; 페이로드는 암호화되지 않는다. 타겟 원격 디바이스(들)(110)는 이미 제공된 인증서를 가지고 있거나, 해당 인증서를 페치하는 방법을 제공한다. 매니페스트 생성을 위한 예시적인 접근 방식은 나중에 설명될 것이다.

단계 240에서, 생성된 매니페스트는 단계 220의 페이로드와 유사한 방식으로, 예를 들어 API 및/또는 포털을 통해 관리 서버에 업로드될 수 있다.

단계 250에서, 디바이스 필터가 조작자 디바이스(140)에서 생성된다. 디바이스 필터는 업데이트될 복수의 원격 디바이스들(110)을 표시한다. 처리될 때, 디바이스 필터는 업데이트가 허용되지 않은 원격 디바이스들(110)이 업데이트되는 것을 방지한다. 디바이스 필터의 포맷은 보다 상세하게 설명될 것이다.

단계 260에서, 업데이트 캠페인은 업데이트 캠페인에 대한 캠페인 데이터를 정의함으로써 조작자 디바이스(140)에서 생성된다. 앞서 언급한 바와 같이, 업데이트 캠페인은 원격 디바이스들의 애셋들을 업데이트하는 접근 방식을 정의하며, 펌웨어 업데이트들과 같은 애셋들이 하나 이상의 미리 결정된 원격 디바이스들에 제공되는 구성으로 간주될 수 있다. 일반적으로, 캠페인은 개발자 디바이스(130)로부터 정의된 적어도 하나의 매니페스트 및 조작자 디바이스(140)에서 정의된 디바이스 필터를 포함하거나 이와 연관될 수 있다. 따라서, 업데이트 캠페인은 적용될 애셋 업데이트, 적용되는 방식 및 애셋 업데이트가 정의된 방식으로 적용될 디바이스들을 총괄적으로 정의한다.

따라서, 캠페인 데이터는 매니페스트를 하나 이상의 디바이스들에 알리는 프로세스의 정의인 것으로 간주될 수 있다. 이것은 관리 서버(120)에서 호스팅되는 연결 서비스를 통해 적절한 원격 디바이스(110) 상의 매니페스트 리소스에 기록하는 것에 의해 수행될 수 있다. 특정 원격 디바이스에 즉시 연결할 수 없는 경우, 알림을 놓치거나 업데이트를 놓칠 수 있다. 동일하거나 상이한 디바이스 필터를 사용하여 해당 디바이스들에 대해 다른 두 번째 캠페인을 시작함으로써 이것을 완화할 수 있다. 이미 업데이트된 디바이스들은 두 번째 캠페인을 무시하며, 그 이유는 그것이 디바이스 필터에 나열되어 있지 않거나 또는 이미 최신 펌웨어 버전을 가지고 있기 때문이다. 애셋 업데이트가 적용될 디바이스들의 목록이 등록된 디바이스들의 글로벌 레지스터일 수 있는, 디바이스 디렉토리로부터 도출될 수 있다. 디바이스들의 서브세트를 선택하는 메커니즘은 디바이스 필터이다. 호환되는 디바이스들의 클래스 및/또는 벤더를 갖는 필터를 매니페스트가 미리 설정할 수 있지만, 배치에는 추가적인 디바이스 타겟팅 정보가 필요할 수 있다.

예를 들어, 클래스 또는 벤더 ID 대신에 또는 이에 추가하여, 다른 필드들을 사용하여 캠페인에 따라 알림을 받는 디바이스들을 필터링할 수 있다. 예를 들어, 디바이스들의 물리적 위치를 나타내는 필드들, 디바이스들의 모델 번호 또는 기타 이러한 필드들이 있을 수 있다. 특정 건물의 특정 층 내에서 특정 모델 번호를 갖는 다수의 디바이스들에 대한 업데이트를 알리는 필터 예가 아래에 나와 있다.

model=‘AIRCONv3-revB’, customer=‘ARM’, city=‘CAMBRIDGE’, building=‘CPC1’, floor=‘2’

일부 예들에서, 조작자 디바이스(140)는 관리 서버(120)에 연결하기 위해 API에 액세스할 수 있으며, 이것은 캠페인들 및 디바이스 필터들을 관리하기 위해 다음과 같은 액션들이 일어날 수 있게 한다:

ㆍ 현재 연결된 모든 원격 디바이스들의 목록 보기;

ㆍ 목록을 더 탐색할 수 있도록 필터들을 생성 및 저장;

ㆍ 디바이스 세부 정보 보기 및 편집하기;

ㆍ 디바이스에 사용자 정의 속성들 추가하기;

ㆍ 연결된 디바이스들의 리소스 값 보기;

ㆍ 디바이스 필터 생성, 관리 및 사용;

ㆍ 사용자 정의 속성 추가하기;

ㆍ 디바이스 이벤트 로그에 액세스하기;

ㆍ 디바이스 삭제하기; 및

ㆍ 새로운 인증서 또는 키를 해지 및 생성하기.

원격 디바이스 필터 생성을 설명하기 위해, 원격 디바이스의 수명 주기에 대한 세부 정보를 제공하는 것도 유용하다. 원격 디바이스의 제조 시에, 디바이스에는 관리 서버에 대한 액세스 크레덴셜을 제공하는 디바이스 인증서; 및 애플리케이션 코드가 부트로더와 함께 제공된다.

디바이스가 부트 스트랩 프로세스를 거쳐서, 관리 서버가 제공하는 관리 서비스에 등록하면 디바이스의 상태가 변경된다. 제작된 원격 디바이스는 "등록되지 않은" 상태에서 시작된다. 등록이 완료되면, 원격 디바이스는 "등록된" 상태가 된다. 등록 과정 동안 오류가 발생하면, 디바이스는 등록된 상태로 되지 않는다. 디바이스 상태는 관리 서버를 통해 액세스될 수 있다.

관리 서버는 다음과 같은 필드들 중 하나 이상의 필드를 사용하여 구성될 수 있다:

ㆍ 디바이스를 식별하는 디바이스 ID;

ㆍ 디바이스명;

ㆍ 디바이스 설명;

ㆍ 상태;

ㆍ 생성 날짜: 원격 디바이스를 업데이트한 날짜 및 시간;

ㆍ 날짜 부트 스트랩: 원격 디바이스가 부트 스트랩된 날짜 및 시간;

ㆍ 일련 번호: 읽기 전용이며 디바이스의 펌웨어로부터 파퓰레이션될 수 있음;

ㆍ 벤더 ID: 원격 디바이스의 벤더 ID로서, 읽기 전용이며 디바이스의 펌웨어로부터 파퓰레이션될 수 있음;

ㆍ 원격 디바이스 클래스: 원격 디바이스의 타입 ID로서, 읽기 전용이며 디바이스의 펌웨어로부터 파퓰레이션될 수 있음;

ㆍ 공장 명; 및

ㆍ 건물 및 층수와 같은 위치 기반 속성.

상태(state)는 다음과 같은 값들 중 하나를 사용할 수 있다:

ㆍ 미등록: 디바이스가 관리 서버에 추가될 때의 초기 상태;

ㆍ 클라우드 등록: 원격 디바이스가 서비스의 일부에 추가되었고 부트 스트랩이 시작된 상태;

ㆍ 부트 스트랩: 원격 디바이스가 이제 부트 스트랩되었으며 관리 서버가 제공하는 관리 서비스와 동일한 것을 갖지만 아직 업데이트할 수 없는 상태;

ㆍ 등록: 원격 디바이스가 등록되고 업데이트가 가능한 상태; 및

ㆍ 등록 해지: 등록 취소 또는 등록 만료로 인해, 원격 디바이스가 더 이상 등록되어 있지 않은 상태.

대규모 클라우드 배치에서 디바이스들을 관리하는 것은 현장에 있는 매우 많은 수의 디바이스들로 인해 광대한 것일 수 있다. 필드 목록을 유지 관리하여 디바이스들을 선택 및 관리할 수 있는 복잡하고 정교한 필터들이 제공될 수 있다. 그 후에 이 필드들을 사용하여 복잡한 필터들을 생성할 수 있으며, 이것은 다바이스들의 서브세트들과 상호 작용하거나 이들을 모니터링하는데 사용될 수 있다. 예를 들어, 상기한 속성들의 임의 조합에 의하여 디바이스들을 필터링할 수 있다. 또한, 관리 서버는 조작자 디바이스(140)에 의해 커스텀 속성(custom attributy)들이 추가될 수 있게 한다.

단계 270에서 업데이트 캠페인이 시작 또는 배치되어, 업데이트 프로세스가 시작된다. 배치는 지정된 매니페스트를 디바이스 필터에 정의된 디바이스 목록에 알린다. 단계 270에서의 캠페인 시작은 조작자 디바이스(140)가 "시작" 명령을 관리 서버에 전송함으로써 트리거될 수 있다. 이것은 예를 들어 API 또는 포털을 통해 수행될 수 있다. 그 후에 디바이스들에게 매니페스트들을 알리는 프로세스가 시작된다.

단계 280에서, 업데이트 캠페인의 진행 상황이, 관리 서버(120)로부터 진행 상황 또는 상태 정보를 수신하거나 검색함으로써 조작자 디바이스(140)에서 모니터링될 수 있다. 배치 동안에, 디바이스 목록에 정의된 대로 알림 메시지가 디바이스 세트로 전송된다. 그러나, 앞서 언급한 바와 같이 배치의 결과 각 디바이스 세트가 업데이트되지 않을 수도 있다. 예를 들어, 디바이스들이 알림을 보거나 보지 않을 수 있고, 디바이스들이 다양한 이유로(예를 들어, 장치가 저전력이거나 임계 상태에 있는) 알림을 무시할 수 있거나, 또는 다른 배치 또는 다른 수단을 통해 알림을 수신할 수도 있다.

따라서, 본 명세서에서 설명되는 업데이트 메커니즘은 캠페인들이 아닌 디바이스들을 모니터링하는 메커니즘을 제공한다. 편의성을 위해서, 캠페인들은 타겟팅하는 디바이스들에 의해 필터링될 수 있다.

매니페스트 생성

도 3은 단계 230이 수행될 수 있는 예시적인 방법을 도시한 것이다. 단계 310에서, 조작자 디바이스(140)에서 실행되는 매니페스트 툴이 관리 서버(120)에 저장된 페이로드를 페치 및 해시한다. 페이로드는 이용 가능한 경우 로컬 파일로부터 로드되며, 그렇지 않은 경우에는 제공된 URI로부터 로드된다. 단계 320에서, 툴은 (제공된 URI 또는 로컬 파일로부터) 인증서를 페치 및 핑거프린팅한다. 단계 330에서, 툴이 매니페스트의 내부 부분을 생성한다. 매니페스트의 내부 부분은 다음과 같은 메타데이터 중 하나 이상의 요소를 포함할 수 있다:

ㆍ 제공된 ID들;

ㆍ 페이로드가 저장된 URI;

ㆍ 페이로드 크기; 및

ㆍ 페이로드 해시.

방법의 단계 330에서, 매니페스트의 내부 부분이 해시된 후에, 단계 340에서 해시 및 인증서 개인 키를 사용하여 서명된다. 단계 360에서, 내부 부분, 해시, 시그니처, 인증서 핑거프린트 및 인증서 URI가 매니페스트의 외부 부분에 래핑된다.

일부 구성들에서는 암호화 모드(예를 들면, none-ecc-secp256r1-sha256)를 갖는 매니페스트를 생성할 수 있다. 암호화 모드를 갖는 매니페스트를 생성하기 위해, 추가 정보가 제공된다. 예를 들어, 다음과 같은 정보가 제공될 수 있다:

ㆍ 사용할 해싱, 서명 및 암호화 타입(없는 경우 필수 입력에서 계산);

ㆍ 벤더 ID(없는 경우 디폴트에서 추출);

ㆍ 클래스 ID(없는 경우 디폴트에서 추출);

ㆍ 페이로드 파일(명령어 라인에서 덮어 쓸 수 있음);

ㆍ 설명(디폴트는 비어 있음); 및

ㆍ 서명에 사용되는 인증서(없는 경우 디폴트에서 추출)

아래는 모든 필드들이 입력 파일을 통해 제공되는 예시적인 매니페스트이다:

{

"encryptionMode": "none-ecc-secp256r1-sha256",

"vendorId": "<hex representation of the 128-bit RFC4122 GUID that represents the vendor>",

"classId": "<hex representation of the 128-bit RFC4122 GUID that represents the device class>",

"payloadUri": "http://path.to/payload.bin",

"payloadFile": "/path/to/payload.bin",

"description": "Description of the update",

"certificates": [

{ "uri": "http://path.to/certificate.der" , "file": "/path/to/certificate.der" }

]

}

앞서 언급한 바와 같이, 매니페스트 툴에 데이터를 제공할 수 있는 여러 가지 방법이 있다. 툴은 JSON 입력 파일을 파싱할 수 있으며, 이 파일에는 매니페스트를 생성하는데 사용되는 모든 정보가 포함될 수 있다. 입력 파일에 정보가 누락된 경우, 매니페스트 툴은 현재 작업 디렉토리에서 디폴트를 포함하는 파일을 확인할 수 있다. 다른 방법은 명령어 라인 인수를 통해 데이터를 제공하는 것이며; 매니페스트 툴에서 사용되는 다수의 필드들이 명령어 라인에서 오버라이드될 수 있다.

매니페스트들은 암호화 없이, 해시들을 위한 SHA256, secp256r1 곡선에 대한 ECDSA 시그니처들을 사용할 수 있다. 이 암호화 모드는 매니페스트 툴에서 none-ecc-secp256r1-sha256이라고 지칭될 수 있다.

암호화되지 않은 페이로드를 갖는 매니페스트를 생성하기 위해, 다음과 같은 필드들이 사용될 수 있다:

ㆍ 사용할 암호화 모드(예를 들면, none-ecc-secp256r1-sha256);

페이로드 URI;

ㆍ 매니페스트 서명에 사용될 인증서의 URI 또는 매니페스트 서명에 사용될 인증서인 로컬 파일;

ㆍ 해당 인증서의 서명 키인 로컬 파일; 및

ㆍ 벤더 ID 및 디바이스 클래스 ID, 또는 디바이스 ID.

매니페스트에 저장될 수 있는 추가 페이로드 정보는 다음을 포함할 수 있다:

ㆍ 매니페스 버전 - 사용되는 매니페스트 포맷의 버전.

ㆍ 설명 - 업데이트에 대한 프리-텍스트 설명.

ㆍ 벤더 ID - 모듈식 시스템에서 타겟 디바이스 또는 소프트웨어 모듈의 벤더를 식별시키는 RFC4122 UUID. 제공된 경우, 타겟이 이 식별자와 매칭될 수 있음.

ㆍ 클래스 ID - 디바이스 또는 소프트웨어 모듈의 종류, 모델 또는 버전을 식별시키는 RFC4122 UUID. 제공된 경우, 타겟이 이 식별자와 매칭될 수 있음.

ㆍ 디바이스 ID - 타겟 디바이스를 고유하게 식별시키는 RFC4122 UUID. 제공된 경우, 타겟이 이 식별자와 매칭될 수 있음.

ㆍ 타임 스탬프 - 매니페스트의 생성 타임 스탬프. 이것은 롤백 보호를 제공하는데 사용된다. 주어진 트리의 루트 매니페스트만이 롤백 보호에 이 필드를 사용한다.

ㆍ이 값이 증가하면 디바이스는 현재 버전 이하의 버전으로 페이로드를 설치할 수 없다.

ㆍ 안정성을 위해 이전 페이로드 버전으로 롤백해야 하는 경우, 이전 페이로드를 위한 새로운 업데이트 매니페스트가 생성된다.

ㆍ 논스(nonce) - 128 비트 랜덤 필드. 이것은 서명 알고리즘이 사이드-채널 공격의 타이밍으로부터 안전하게 되는 것을 보장하기 위해 매니페스트 툴에 의해 제공된다.

ㆍ 벤더 정보(vendorInfo) - 벤더 고유의 정보이며, 엔드-디바이스가 이 업데이트를 적용하지 않을 수도 있음. 이것은 좁은 환경에 맞는 확장을 위한 것이다(예를 들면, 도어 벤더가 "현재 잠금되어 있지 않다면 이 업데이트를 적용하지 마십시오"라는 플래그를 가질 수 있음).

ㆍ 즉시 적용(applyImmediately) - 이 플래그는 매니페스트에 의해 설명된 업데이트가 가능한 빨리 적용되어야 함을 나타낸다. 설정되지 않으면, 적용되는 다른 매니페스트에 의존되지 않는 한 이 업데이트가 적용되지 않는다.

ㆍ 유효 시작점(validFrom) 및 유효 종점(validTo) - 이 업데이트를 적용할 수 있는 시간. 이 시간 외에는, 이 매니페스트가 적용되지 않는다.

ㆍ 종속성(dependencies) - 다른 매니페스트들 참조(다른 데이터 타입들은 오류임). 이 매니페스트에 의해 설명되는 업데이트는 이 목록에서 참조되는 모든 매니페스트와 함께 원자적으로 적용된다.

ㆍ 페이로드 - 적용할 실제 페이로드를 설명함. 하위 특성들은 아래를 참조하도록 한다:

ㆍ 별칭(aliases) - 매니페스트가 다른 매니페스트에서 참조되는 페이로드를 얻기 위한 대안의 위치를 제공할 수 있음

ㆍ 암호화 모드(encryptionMode) - 이것은 페이로드를 암호화하는데 사용되는 암호화 구성을 설명함

ㆍ 초기화 벡터(initVector) - AES 엔진의 초기화 벡터. 크기는 encryptionMode에 의해 결정된다. AES 암호화가 지정된 경우, 이 필드는 필수이다.

보안 메커니즘(Security Mechanisms)

디바이스의 수명 동안 보안을 유지하기에 충분한 수준의 엔트로피(예를 들면, 15 년 이상의 수명 동안 최소 128 비트의 보안)를 갖는 업데이트의 신뢰성이 입증될 수 있어야 한다. 일반적으로, 이것은 업데이트가 서명되었음을 의미한다. MAC 또는 Zero Knowledge Proofs와 같은 다른 증명 메커니즘도 허용될 수 있다. 매니페스트에는 업데이트 설치 방식에 대한 정보가 포함되어 있으므로, 매니페스트의 신뢰성이 입증될 수 있다. 유효성 검사에 필요한 오버헤드를 줄이기 위해, 매니페스트에는 다른 서명이 아닌 페이로드 다이제스트가 포함된다. 이것은 페이로드의 증명성을 변경하지 않는다. 매니페스트의 신뢰성은 시그니처에 의해 입증될 수 있으며, 페이로드 다이제스트의 신뢰성은 매니페스트에 의해 입증될 수 있고, 페이로드의 신뢰성은 페이로드 다이제스트에 의해서 입증될 수 있다.

일부 구성들에서는, 권한이 있는 업데이트 작성자가 매니페스트에 서명한다. 업데이트 작성자는 업데이트 이미지를 구성한 액터이다. 중개 서명자(intermediary signer)는 사용될 수 없다. 이러한 구성들에서는, 타겟 디바이스가 안전하고 취소할 수 없는 방식으로 프로비저닝된 업데이트를 인증하는데 사용하는 공개 키를 가지고 있다. 디바이스는 이전의 키로 서명되지 않는 한 새로운 키를 허용하지 않는다. 디바이스는 이러한 감사 기록(audit trail)을 유지해야 한다.

디바이스들은 작성자 공개 키를 정기적으로 만료시키며, 작성자가 신뢰될 수 없게 될 경우에는 작성자 공개 키를 취소한다. 이것은 인증서 만료 및 인증서 해지에 의해서 수행될 수 있다. 서버는 디바이스에 대한 매니페스트 시그니처 인증 해지 확인을 단순화하기 위해 OCSP 스테이플링(OCSP stapling)과 유사한 메커니즘을 사용할 수 있다. 관리 서버(120)는 원격 디바이스(110)를 대신하여 인증서를 페치하고, 매니페스트에 대한 유효성 검증과 관련된 인증서에 대한 개별 해지 상태를 첨부하도록 구성될 수 있다.

업데이트 작성자는 서명에 HSM을 사용할 수 있다. 매니페스트의 내용은 서명 전후에 비교될 수 있다. 이러한 비교는 서명한 것 이외의 머신에서 수행될 수도 있다. 대규모 배치의 경우, HSM이 있는 Air-Gapped 컴퓨터에서 매니페스트를 검증할 수 있다.

대규모 배치의 경우, 업데이트 작성자는 보안 컴파일러를 실행하는 에어 갭 빌드 머신(air-gapped build machine)을 사용할 수 있다. 선택적으로, 컴파일러에는 벤더에 의한 서명이 이루어질 수 있다. 대규모 배치의 경우, 컴파일러 자체가 모든 빌드 출력에 서명할 수 있다. 결과 바이너리의 다이제스트는 매니페스트의 다이제스트와 비교되어야 한다. 업데이트 작성자는 매니페스트를 타겟 디바이스로 디스패치하기 전에 클라우드 서비스에서 검색된 매니페스트의 내용을 확인할 수 있다. 매니페스트에는 페이로드 다이제스트가 포함될 수 있다.

매니페스트는 전반적으로, 단조 증가하는 시퀀스 번호를 포함할 수 있다. 다수의 허가된 펌웨어 작성자가 존재하는 경우에도, 매니페스트에 제공된 시퀀스 번호는 단조 증가할 수 있다.

매니페스트 및 그 내용은 비정규 형태로 저장 또는 전송된다. 이러한 메커니즘이 기술적으로 필요한 경우(예를 들면, 데이터베이스), 비정규 데이터의 수신자가 매니페스트를 전송하고 검증한다. 페이로드 암호화 키 보호. 디바이스 벤더는 위험 분석을 수행하고, 원하는 수준의 페이로드 보안을 선택할 수 있다.

암호화된 페이로드는 다음과 같은 다양한 보안 수준으로 제공될 수 있다:

ㆍ 클래스 0 페이로드: 암호화되지 않음. 이 페이로드는 공개적으로 액세스 가능한 것으로 알려져 있다.

ㆍ 클래스 1 페이로드: 영구 사전 공유 키에 의해서 암호화되며, 선택적으로는 키 도출 함수에 의해서 암호화됨. 페이로드 내용의 노출로 인한 위험이 낮다. 하나의 키가 손상되면 향후 모든 페이로드가 손상된다.

ㆍ 클래스 2 페이로드: 별도의 사전 공유 키(pre-shared key)가 모든 디바이스에 대해 구성되며, 선택적으로 키 도출 함수를 사용함. 임의의 개별 디바이스로의 페이로드 전달을 취소할 수 있다.

ㆍ 클래스 3 페이로드: 디바이스들이 공개 키 기반 키 합의를 사용하여, 각 디바이스가 디바이스 별 키를 사용하여 암호화된 동일한 페이로드 암호 해독 키를 받도록 함. 키 배포를 위한 개인 키는 각 배치마다 생성된다. 임의의 개별 디바이스로의 페이로드 전달을 취소할 수 있다.

ㆍ 클래스 4 페이로드: 각 디바이스는 독립적인 보안 채널을 통해 개별적으로 협의된 난수를 수신한 후, 이 난수를 공개 키 기반 키 합의에 사용함. 그 후에 이 키를 사용하여 페이로드 암호화 키를 해독한다. 이것이 FS(Forward Secrecy)를 구성한다.

ㆍ 클래스 5 페이로드: 각 디바이스가 독립적인 보안 채널을 통해 개별적으로 협의된 난수를 수신한 후, 이 난수를 공개 키 기반 키 합의에 사용함. 페이로드가 이 키로 암호화된다. 이것은 브로드캐스트 친화적이지 않다.

디바이스 벤더는 이러한 페이로드 보안 클래스들 중 어떤 것이 위험 프로파일에 가장 적합한지를 선택하고, 대칭 키(사전 공유, 저에너지, 보호하기 어려움), 비대칭 키(공유되지 않음, 고에너지, 보호하기 쉬움), 에너지 프로파일 등의 사용을 밸런싱한다. 암호화된 페이로드가 사용될 때, 매니페스트는 페이로드 암호화 키의 다이제스트를 포함할 수 있다. 칩 외부에 저장된 모든 펌웨어 업데이트는 고유한 디바이스 별 암호화 키로 서명될 수 있다. 칩 외부에 저장된 모든 펌웨어 업데이트는 고유한 디바이스 별 암호화 키로 암호화될 수 있다. 디바이스들은 추출(extraction)을 방지하기 위해 고유한 디바이스 별 암호화 키를 사용하여 오프-칩 데이터를 암호화할 수 있다. 디바이스들은 적절한 디버그 보호 퓨즈들을 버닝(burning)하여 SWD/JTAG 판독 기능들을 비활성화할 수 있다. 디바이스가 보안 디버거(secure debugger)를 지원하는 경우에는, 이것이 비활성화될 필요가 없다. 디바이스들은 매니페스트 타임 스탬프에 대해 인증서 만료 시간을 확인할 수 있다. 타임 스탬프가 서명에 사용된 인증서의 만료 시간보다 이후인 경우 매니페스트는 수락될 수 없다. 설치 시간이 서명에 사용된 인증서의 만료 시간보다 이후인 경우 매니페스트는 수락될 수 없다. 디바이스들은 보안 원점들을 기반으로 하는 논리 시계를 사용하여 시간을 보안성 있게 적용할 수 있다. RTC들도 공격받을 수 있기 때문에, 이것은 RTC의 유무에 관계없이 적용된다.

매니페스트들은 안전한 인증 채널을 통해 디바이스들로 전달될 수 있다. 페이로드들은 안전한 인증 채널을 통해 전달될 수 있다. 안전한 인증 채널을 통해 매니페스트, 페이로드를 전달하지 않을 경우의 위험은 이 요구 사항에 의해 완화된 위협들을 통한 서비스 거부 위험 증가이다. 각 디바이스는 고유한 암호화 가능 증명 아이덴티티를 가질 수 있다. 이 아이덴티티는 서버, 피어 디바이스 또는 사용자 애플리케이션과 같은 통신 파트너에 의해 검증될 수 있다. 타겟 디바이스는 그 애플리케이션 공간에 적합한 레이트 제한을 구현할 수 있다. 디바이스로 하여금 많은 양의 에너지 및/또는 플래시 사이클을 사용하게 할 수 있기 때문에, 많은 매니페스트를 빠르게 전송할 수 없다.

상태 보고들은 신뢰할 수 있는 개인 통신 매체를 통해 라우팅되어야 하며, 이것은 공격자가 디바이스에서 보낸 패킷들을 검사하고 차단할 패킷들을 선택하지 못하게 한다.

페이로드에 대한 모든 설명 정보가 서명될 수 있다. 이것은 다음을 포함할 수 있다:

ㆍ 페이로드 위치

ㆍ 페이로드 다이제스트

ㆍ 페이로드 크기

ㆍ 페이로드 타입

ㆍ 페이로드 적용을 위한 모든 지침들 또는 파라미터들

ㆍ 페이로드가 이 디바이스에서 사용될 수 있는지 여부를 식별하는 임의의 규칙들

저장 위치가 둘 이상인 시스템에서는, 업데이트 작성자가 ACL(Access Control List)에 의해서 식별될 수 있다. 이 ACL은 디바이스에서 업데이트 작성자가 수행하는 것이 허용되는 작업을 식별시킨다. 업데이트를 설치하려면, 타겟 스토리지 위치에 필요한 권한을 충족해야 할 수 있다. 이 권한은 업데이트 작성자의 시그니처에 의해 부여된다. 매니페스트를 수신하는 모든 액터들은 해당 컨텐트를 처리하기 전에 매니페스트의 신뢰성의 유효성을 검사한다.

트러스트 앵커는 디바이스가 특정 태스크에 대해 완전히 신뢰하는 제조 시에 디바이스에 설치된 공개 키로 간주될 수 있다. 트러스트 앵커는 교체, 취소 또는 만료되어서는 안된다. 트러스트 델리게이트는 트러스트 앵커 또는 트러스트 델리게이트에 의해 서명된 공개 키로 간주될 수 있다. 궁극적으로, 위임의 각 체인은 트러스트 앵커로 끝난다. 트러스트 델리게이트는 언제든지 교체, 취소 또는 만료될 수 있다.

본 명세서에서 설명된 시스템들에 적용될 수 있는 보안 모델은 위에서 설명한 보안 요구 사항들을 사용하여 빌드된다.

1. 신뢰성(Trust)

i. 제조 시에, 각 디바이스에는 업데이트를 위해 신뢰하는 하나 이상의 공개 키가 보안성 있게 제공된다. 이것을 트러스트 앵커라고 한다. 트러스트 앵커 또는 트러스트 델리게이트에 의해서 각 업데이트를 검증할 수 있다. 트러스트 델리게이트는 트러스트 앵커의 개인 키에 의해서 서명된 공개 키이다.

ii. 트러스트 델리게이트가 추가로 위임할 수 있다.

iii. 신뢰 위임은 트러스트 델리게이트들의 권한을 제한하기 위한 메커니즘을 제공할 수 있다.

iv. 트러스트 델리게이트들은 만료 날짜를 가질 수 있다.

v. 트러스트 앵커 또는 트러스트 앵커에 더 가까운 트러스트 델리게이트만이 트러스트 델리게이트를 취소할 수 있다.

vi. 트러스트 앵커 또는 트러스트 델리게이트가 칩 외부에 저장되면, 이것이 암호화 및 서명된다.

2. 매니페스트(Manifests)

i. 매니페스트라고 불리는 메타데이터 블록이 업데이트를 설명하는데 사용된다.

ii. 매니페스트는 업데이트 작성자에 의해 서명된다. 클라우드 서명은 금지될 수 있다.

iii. 매니페스트는 업데이트 작성자의 컴퓨터 또는 업데이트 작성자의 HSM에서 서명될 수 있다. 업데이트 작성자는 매니페스트의 서명 전 내용과 서명 후 내용을 비교한다.

iv. 매니페스트는 PKCS-7 또는 RFC5652로도 불리는 업계 표준 컨테이너 포맷, CMS를 사용하여 서명될 수 있다.

v. CMS(PKCS-7/RFC5652)를 사용하여, 표준 PKCS-11 호환 HSM 또는 스마트 카드에 의해서 매니페스트가 서명될 수 있다. 이것은 에어 갭 HSM(air-gapped HSM)에서 수행될 수도 있다.

vi. 매니페스트는 하나 이상의 트러스트 앵커 또는 트러스트 델리게이트에 의해 서명될 수도 있다.

vii. 따라서 매니페스트는 다음을 포함할 수 있다:

a. 강도가 적어도 SHA-256일 수 있는, 페이로드의 다이제스트;

b. UTC 타임 스탬프(초);

c. 페이로드 위치;

d. 페이로드 다이제스트;

e. 페이로드 크기;

f. 페이로드 타입;

g. 페이로드를 적용하기 위한 모든 지침 또는 파라미터;

h. 페이로드가 이 디바이스에서 사용될 수 있는지 여부를 식별시키는 규칙들; 및

i. 페이로드가 암호화되는 경우, 매니페스트는 페이로드 키의 다이제스트를 포함한다.

3. 페이로드

i. 페이로드는 여러 모델을 사용하여 암호화될 수 있다. 암호화된 경우, 매니페스트는 디바이스가 페이로드의 암호를 해독하는데 필요한 정보를 포함하고 있지만, 다른 사람이 암호를 해독할 수 있을 정도의 충분한 정보를 포함하고 있지 않다.

ii. 다운로드가 완료된 경우, 페이로드는 업데이트 클라이언트에 의해서 서명되며, 다음 중 어느 하나에 저장된다:

a. 온-칩; 또는

b. 오프-칩(암호화되거나(예를 들면, AES-128 이상으로) 및/또는 128 비트 이상의 보안으로 서명됨).

4. 서비스

i. 업데이트 작성자는 매니페스트 시그니처의 서비스 측 유효성 검사를 허용하기 위해 업데이트 인증서를 서비스 계정에 업로드할 수 있다.

ii. 매니페스트 수령 시의 업데이트 서비스:

a. 매니페스트의 시그니처를 유효성 검사한다. 사용 가능한 해당 인증서가 없으면, 업데이트 서비스가 오류를 보고한다.

b. 모든 일반 매니페스트 필드의 유효성을 검사한다. 일부 필드는 디바이스에서만 사용할 수 있는 지식이 없으면 검증할 수 없다.

iii. 업데이트 작성자는 매니페스트의 서비스 측 유효성 검사를 옵트 아웃할 수 있지만, 이것은 디폴트 위치가 아닐 수도 있다.

iv. 디바이스 관리자는 디바이스들에 대한 업데이트 배치를 승인하기 전에 매니페스트들 중의 사람이 읽을 수 있는 부분을 검사할 수 있다. 이것은 시그니처를 추가하는 것 없이 수행될 수 있다.

v. 업데이트 서비스는 사용자에게 제공되는 데이터가 올바른 것인지 확인한다.

a. 사용자는 매니페스트 유효성 검사에 사용된 공개 키를 업데이트 서비스에 업로드한다.

b. 매니페스트를 받으면, 업데이트 서비스는 해당 시그니처의 유효성을 검사한다.

c. 검색에 대한 응답으로 매니페스트를 추출할 경우, 업데이트 서비스는 해당 시그니처의 유효성을 검사한 다음, 매니페스트 내용을 검색어와 비교한다.

d. 업데이트 서비스는 임의의 API를 통해 정규 매니페스트를 제공한다.

e. SDK와 웹 포털 모두는 매니페스트 시그니처를 로컬로 유효성 검사한 다음, 매니페스트를 필요한 데이터 포맷으로 파싱한다.

f. SDK와 웹 포털 모두는 사용자가 확인할 수 있도록 로컬로 파싱된, 매니페스트의 내용을 표시하는 "최종 확인(final check)" 메커니즘을 제공한다. 이 내용은 이전에 사용자에게 표시된 다른 필드들과 비교되며, 불일치 부분이 하이라이팅된다.

vi. 업데이트 서비스는 TLS 또는 DTLS를 통해 매니페스트를 타겟 디바이스에 전달한다.

vii. 업데이트 서비스는 TLS 또는 DTLS를 통해서만 상태 보고를 수락한다.

viii. 업데이트 서비스는 최신 TLS/DTLS 연결들만 허용하도록 적절한 단계들을 수행한다.

ix. 업데이트 서비스는 고유한 디바이스들만 서비스에 연결되도록 한다.

x. 업데이트 서비스는 각 디바이스의 아이덴티티를 암호적으로 검증한다.

5. 디바이스

i. 디바이스는 고유한 개인 키를 갖는다.

ii. 각 매니페스트가 수신된 후, 업데이트 성공 여부에 관계없이, 디바이스는 쿨링 오프(cooling-off) 기간에 들어가 "레이트 리미트(Rate Limit)" 오류가 있는 모든 매니페스트를 거부한다.

iii. 디바이스가 매니페스트를 수신하면, 다음을 수행한다:

a. 매니페스트 시그니처를 검증한다.

b. 매니페스트의 타임 스탬프가 인증서 만료보다 이전인지를 확인한다.

c. 매니페스트의 설치 시간이 인증서 만료보다 이전인지를 확인한다.

d. 모든 매니페스트 필드들을 검증한다.

매니페스트 업로드

도 4는 매니페스트를 생성하여 관리 서버(120)에 업로드하기 위한 예시적인 워크 플로우를 도시한 것이다. 도 4에서 볼 수 있듯이, 이 예에 도시되어 있는 다수의 상이한 요소들이 존재한다. 전술한 바와 같이, 관리 서버(120)는 예를 들어 펌웨어 이미지의 형태로 펌웨어 페이로드를 저장 및 유지하기 위한 서비스를 포함하는 애셋 업데이트 서비스를 제공하도록 구성된다. 이 서비스는 도 4에 도시된 바와 같은, 펌웨어 카탈로그 서비스에서 처리될 수 있다. 또한, 매니페스트 데이터의 스토리지가 매니페스트 스토리지에 제공된다. 관리 서버(120)는 매니페스트 스토리지 내에 매니페스트들의 스토리지를 직접 저장하거나 원격으로 관리한다. 관리 서버(120)는 또한 매니페스트들이 개발자 디바이스로부터 업로드될 수 있는 API 게이트웨이 및 포털을 제공한다. 개발자 디바이스는 매니페스트의 생성을 처리하도록 구성된 업데이트 툴 및 매니페스트가 관리 서버(120)에 업로드되기 전에 매니페스트에 서명하도록 구성된 서명 툴을 작동시키도록 구성될 수 있다.

도 4의 워크 플로우는 단계 401에서 시작되며 이 단계에서는 매니페스트 생성 요청이 개발자 디바이스에서 생성되어, 업데이트 툴로 전달된다. 단계 402에서, 매니페스트가 생성되어, 개발자 디바이스로 전달된다. 단계 403에서는, 서명되지 않은 매니페스트가, 단계 404에서의 서명 키와 함께 서명 툴로 전달된다. 매니페스트가 서명 키를 사용하여 서명되어, 단계 405에서 개발자 디바이스로 리턴된다. 단계 406에서, 서명된 펌웨어 매니페스트를 관리 서버(120)에 업로드하도록 하는 요청이 개발자 디바이스에 의해 이루어진다. 이 요청은 단계 406에서 포털 및 단계 407에서 API 게이트웨이를 통해 이루어진다. 단계 408에서, 서명된 매니페스트를 업로드하도록 하는 요청이 펌웨어 카탈로그로 전달되어 단계 409에서 매니페스트의 크기가 미리 결정된 한계를 초과하는지 확인하고 매니페스트 필드들을 파싱한다. 단계 410에서, 매니페스트가 저장될 매니페스트 스토리지로 전송된다. 단계 411 내지 416에서, 매니페스트가 매니페스트 스토리지에 성공적으로 저장되었음을 확인하는 확인 메시지가 요소들을 통해 리턴된다.

페이로드 업로드

도 5는 관리 서버(120)로 업데이트될 애셋의 페이로드를 생성 및 업로드하기 위한 예시적인 워크 플로우(500)를 도시한 것이다.

도 5에서 볼 수 있듯이, 이 워크 플로에는 다수의 요소들이 존재한다. 이 예에서, 관리 서버(120)는 또한 예를 들어 펌웨어 이미지 형태로 애셋 페이로드를 저장 및 유지하기 위한 서비스를 제공하도록 구성된다. 이 서비스는 도 5에 도시된 바와 같은, 펌웨어 카탈로그 서비스에서 처리될 수 있다. 또한, 관리 서버(120)는 펌웨어 페이로드들의 스토리지를 펌웨어 스토리지에 직접 저장하거나 원격으로 관리한다. 관리 서버(120)는 또한 펌웨어 이미지가 업로드될 수 있는 API 게이트웨이 및 포털을 제공한다. 또한, 개발자 디바이스는 펌웨어 이미지를 빌드하는데 사용될 수 있는 빌드 툴들에 액세스할 수도 있다.

워크 플로우는 단계 501에서 시작되며 이 단계에서 펌웨어 이미지 빌드 요청이 개발자 디바이스로부터 빌드 툴로 전송된다. 빌드 툴은 단계 502에서 컴파일된 이미지를 개발자 디바이스로 리턴한다. 단계 503에서, 펌웨어 업로드 요청이 포털을 통해 전달되고 단계 504에서 API 게이트웨이를 통해 전달됨으로써, 단계 505에서 관리 서버(120) 내의 펌웨어 카탈로그 서비스로 전달된다. 단계 506에서, 펌웨어 이미지가 펌웨어 스토리지에 저장된다. 단계 507, 508, 509 및 510에서 펌웨어가 저장되었음을 확인하는 확인 메시지가 개발자 디바이스로 리턴된다.

캠페인 생성

도 6은 캠페인을 생성하고 이 캠페인을 관리 서버(120)에 제공하기 위한 예시적인 워크 플로우(600)를 도시한 것이다. 도 6에서 볼 수 있듯이, 이 워크 플로에는 다수의 요소들이 존재한다. 이 예에서, 관리 서버(102)는 업데이트 서비스가 제공될 수 있게 한다. 이 업데이트 서비스는 관리 서버(120) 내의 소프트웨어 모듈로서 구현되는 것으로 간주될 수 있다. 워크 플로우를 설명하기 위해 소프트웨어 모듈을 여러 하위 모듈 또는 하위 서비스로 분리할 수 있다. 이 예에서, 포털은 조작자 디바이스(140)가 관리 서버(120)와 상호 작용하거나 인터페이스할 수 있는 인터페이스를 제공하는 관리 서버(120)에 의해 제공되는 웹 포털이다.

또한 통신들이 관리 서버(120)의 하위 서비스들로 전달되는 API 게이트웨이가 제공된다. 도 6의 예에서, 관리 서버(120)에 의해 운영되는 다수의 상이한 하위 서비스들이 존재한다. 실제에 있어서, 관리 서버(120)의 동작은 그것이 단일 서비스가 되도록 하는 더 높은 추상화 레벨에서 고려될 수 있다. 그러나, 데이터의 워크 플로우를 설명하기 위해, 이 예에서는 세 가지 하위 서비스가 예시되어 있다 - 즉, 수신된 펌웨어 페이로드들의 저장 및 유지를 관리하는 펌웨어 카탈로그 서비스와, 디바이스 필터들의 저장 및 유지를 관리하는 디바이스 카탈로그 서비스와, 생성된 캠페인의 배치를 관리하는 배치 서비스.

도 6의 워크 플로우는 단계 601에서 시작되며, 이 단계에서 조작자 디바이스가 새로운 캠페인의 생성을 요청한다. 단계 602에서, 새로운 캠페인 생성 요청에 응답하여, 펌웨어 카탈로그 서비스를 통해 액세스 가능한 가용 매니페스트 목록에 대한 요청이 포털을 통해 API 게이트웨이에 발행된다. 단계 603에서, API 게이트웨이는 가용 매니페스트 목록을 획득하도록 하는 요청을 배치 서비스에 전달한다. 단계 604에서, 가용 매니페스트 목록를 나타내는 매니페스트 목록이 펌웨어 카탈로그 서비스로부터 API 게이트웨이로 전송된다. 매니페스트 목록이 단계 605에서 API로부터 전송되어, 포털을 통해 조작자 디바이스에게 제시된다. 단계 606에서, 조작자 디바이스는 캠페인과 연관될 가용 매니페스트 목록으로부터 특정 매니페스트를 선택하고, 선택된 매니페스트에 기초하여 캠페인을 생성하는 프로세스를 시작한다.

단계 607에서, 캠페인 생성 메시지가 클라우드 포털로부터 API 게이트웨이로 전송되며, 이 캠페인 생성 메시지는 선택된 매니페스트와 연관될 매니페스트의 표시를 포함한다. 단계 608에서, API 게이트웨이가 캠페인 생성 메시지를 배치 서비스에 전달하여 선택된 매니페스트와 관련된 캠페인의 생성을 기록한다. 단계 609 및 610에서, 캠페인이 배치 서비스에서 생성되었다는 확인 메시지가 전송된다.

단계 611에서, 포털은 유효한 디바이스 필터 목록에 대한 요청을 API 게이트웨이에 발행한다. 예를 들어, 선택된 매니페스트에 나열된 디바이스 제조자 및 모델 번호를 지정하는 필터들로부터 유효한 필터들이 선택될 수 있다. 추가적으로 또는 대안적으로 매니페스트의 다른 필드들이, 매니페스트를 기반으로 하여 사용될 유효한 디바이스 필터 목록을 식별하는데 사용될 수 있다. 단계 612에서 유효 목록에 대한 요청이 API 게이트웨이로부터 디바이스 카탈로그 서비스로 전송된다. 디바이스 카탈로그는 디바이스 카탈로그 서비스에서 이용 가능한 필터들 중 어느 것이 유효한지를 결정하고, 단계 613에서 유효 목록을 API 게이트웨이로 리턴하며, 그 후에 이것이 단계 614에서 포털로 전달된다. 단계 615에서, 사용될 디바이스 필터가 유효한 디바이스 필터 목록으로부터 선택되어 포털에 제공된다. 포털은 단계 616 및 617에서 API 게이트웨이를 통해 캠페인 업데이트 메시지를 배치 서비스에 전송한다. 캠페인 업데이트 메시지는 사용될 디바이스 필터를 나타낸다. 배치 서비스에서 수신되는 경우, 캠페인이 배치 서비스에서 업데이트된다. 단계 618 및 619에서는 업데이트가 이루어졌음을 확인하는 확인 메시지가 포털로 리턴되어, 조작자 디바이스에게 제시된다.

단계 620에서, 조작자 디바이스는 단계 620에서 웹 포털에 데이터를 입력함으로써 캠페인 업데이트의 시작을 개시한다. 예를 들어, 캠페인 시작 메시지 또는 사용자 인터페이스와의 상호 작용의 형태를 취할 수 있다. 단계 621 및 622에서, 캠페인 시작 메시지가 웹 포털로부터, API 게이트웨이를 통해 및 배치 서비스로 전송된다. 대역폭이 존재하는 경우 배포 서비스는 즉시 캠페인 업데이트를 개시할 수 있다. 대안적으로, 현재 다른 캠페인이 진행중인 경우, 리소스를 사용할 수 있게 되면 처리되도록 하기 위해 배치 서비스가 대기될 수 있다. 단계 623, 624 및 625에서, 캠페인 업데이트가 개시되었다는 확인이 조작자 디바이스로 리턴된다. 이러한 접근 방식을 제공함으로써, 캠페인을 생성하기 위해 조작자 디바이스가 페이로드 사본을 받을 필요가 없게 된다.

일부 구성들에서는, 생성된 캠페인 데이터가 관리 서버(120)로 업로드되기 전에 서명될 수 있다. 이러한 접근 방식들에서는, 캠페인 데이터를 인증하고 수락하기 위해 업데이트될 원격 디바이스(110)에 의해 서명된 캠페인 데이터가 요구될 수 있다. 캠페인 데이터는 공개 키 암호화 시그니처 또는 키-해시 메시지 인증 코드(HMAC)를 사용하여 서명될 수 있다. 캠페인 데이터의 서명은 악의적으로 변경되는 것을 방지하는 캠페인 데이터의 엔드 투 엔드 보안을 달성한다.

원격 디바이스(110)는 수신된 캠페인 데이터와 수신된 매니페스트 데이터 사이의 임의의 충돌을 해결하는 동작을 수행하도록 구성될 수 있다. 예를 들어, 원격 디바이스는 특정 제조자에 속하는 디바이스들이 업데이트되어야 한다는 것을 나타내는 매니페스트 데이터를 수신할 수 있지만 다른 제조자를 허용하는 캠페인 데이터를 수신할 수 있다(예를 들어, 캠페인 데이터는 유효한 매니페스트 데이터에 대한 예외를 만들 수 있다). 원격 디바이스(110)는 예를 들어 미리 정해진 규칙에 기초하여 캠페인 데이터 및 매니페스트 데이터 중 하나를 자동으로 연기함으로써 충돌을 자동으로 조정할 수 있다. 대안적으로, 원격 디바이스(110)는 사용자 개입에 의해 해결되어야 하는 충돌을 관리 서버(120)에게 통지할 수 있다.

캠페인 처리

도 7은 캠페인 시작 요청에 응답하여 캠페인 데이터를 처리함으로써 캠페인 업데이트를 개시하기 위한 관리 서버(120) 내의 예시적인 워크 플로우(700)를 도시한 것이며 이것은 도 6과 관련하여 논의된다. 전술한 바와 같이, 도 7의 예는 관리 서버(120)에 의해 제공되는 다수의 상이한 하위 서비스들을 도시한 것이다. 일부 구현들에서, 관리 서버(120)는 단일 서비스로서 동작할 수 있다. 그러나, 예시의 목적을 위해, 캠페인 처리는 하위 서비스 접근 방식과 관련하여 설명될 것이다.

도 7의 워크 플로우는 단계 701에서 시작되며, 이 단계에서는 배치 서비스가 처리 대상인 후속 대기 캠페인에 관한 정보를 검색한다. 단계 702에서 검색된 캠페인 정보에 따라, 배치 서비스는 캠페인 데이터의 디바이스 필터에 기초하여 업데이트 캠페인이 적용될 디바이스들의 필터를 수행하고, 업데이트가 적용될 디바이스 목록을 디바이스 카탈로그 서비스로부터 검색한다.

단계 703에서, 캠페인 메타데이터 엔트리들이 디바이스에 대해 생성되고 단계 704에서, 배치 서비스가 디바이스 카탈로그 서비스에 데이터를 제공함으로써, 업데이트된 애셋 데이터의 배치를 원격 디바이스에 반영하기 위해 단계 705에서 원격 디바이스에 대한 디바이스 로그가 업데이트될 수 있다.

단계 706에서, 매니페스트 데이터에 대한 요청이 배치 서비스로부터 펌웨어 카탈로그로 전송되고, 단계 707에서 펌웨어 카탈로그가 매니페스트의 사본을 리턴한다. 업데이트된 매니페스트 데이터가 단계 708에서 커넥터 채널 서비스로 전송되며, 이 커넥터 채널 서비스는 디바이스 필터에 따라 매니페스트 데이터를 하나 이상의 원격 디바이스로 전송한다. 디바이스들은 통신 성공에 기초하여, 통신 수신을 확인 응답하거나 확인 응답하지 않는다. 단계 710에서 업데이트 결과 상태가 배치 서비스로 리턴되며, 이 배치 서비스는 단계 711에서 원격 디바이스와 연관된 메타데이터를 업데이트한다.

캠페인 모니터링

도 8은 캠페인 진행 상황을 모니터링하기 위한 예시적인 워크 플로우를 도시한 것이다. 전술한 도면에서와 같이, 이 예에서 관리 서버는 디바이스 카탈로그 서비스, 커넥터 채널 서비스 및 배치 서비스를 포함하는 복수의 하위 서비스를 포함한다. 또한, 조작자 디바이스는 포털 및 API 게이트웨이를 통해 관리 서버(120)와 통신할 수 있다.

워크 플로우(800)는 단계 801에서 시작되며, 이 단계에서 커넥터 채널 서비스가 디바이스의 리소스의 변경을 통지 받는다. 예를 들어 HTTP 콜백을 사용하여 이것이 이루어질 수 있다. 단계 802에서, 커넥터 채널 서비스가 디바이스 카탈로그 서비스에게 리소스 변경을 통지한다. 단계 803에서, 디바이스 카탈로그 서비스가 리소스 변경과 관련된 디바이스 로그 엔트리를 생성한다. 단계 804에서, 커넥터 채널 서비스는, 모든 디바이스들이 타겟 버전에 도달한 경우 이것을 배치 서비스에 통지하고, 이 시점에서 캠페인이 완료된 것으로 표시될 수 있다.

임의의 시점에서, 조작자 디바이스는 단계 805에서 포털을 통해 캠페인을 모니터링하기 위한 명령을 개시한다. 단계 806 및 807에서, 포털은 캠페인에 대한 디바이스 로그 엔트리들을 요청하고 이것이 단계 807에서 디바이스 카탈로그 서비스로부터 검색되어 단계 808에서 API 게이트웨이로 리턴된다. 그 후에 캠페인 업데이트에 따라 원격 디바이스들의 애셋 업데이트 상태를 조작자 디바이스에 표시하기 위해 조작자 디바이스에게 로그들을 제공할 수 있다.

다수의 서비스 리퀘스터들

도 9는 관리 서버(120), 개발자(130) 및 조작자 디바이스(140) 및 복수의 원격 디바이스들(110)을 포함하는 컴퓨팅 시스템(900)을 도시한 것이다. 이러한 요소들은 도 1의 유사한 요소들에 대응한다.

도 9의 구성에서, 원격 디바이스들(110), 개발자 디바이스(130) 및 조작자 디바이스(140)는 모두 제 1 서비스 리퀘스터와 관련되어 있다는 점에서 모두 링크되어있다. 서비스 리퀘스터는 허용된 원격 디바이스들에 대한 공통 액세스 수준을 가진 관련 조직 또는 사용자로 간주될 수 있다. 예를 들어, 개발자(130)는 제 1 서비스 리퀘스터가 요청한 제 1 서비스의 일부를 형성하는 원격 디바이스들(110)을 위한 펌웨어를 개발한다. 이와 같이, 제 1 서비스 리퀘스터의 개발자(130)에 의해 생성된 페이로드 및 매니페스트는 제 1 서비스 리퀘스터의 조작자 디바이스(140)에 의해 액세스될 수 있다.

관리 서버(120)는 개별 서비스 리퀘스터에 의해 각각 요청된 다수의 업데이트 서비스들을 병렬적으로 관리하도록 구성될 수 있다. 예를 들어, 도 9의 구성에서, 3개의 업데이트 서비스가 병렬적으로 요청되고 있다. 제 1 업데이트 서비스는 개발자(130), 조작자 디바이스(140) 및 원격 디바이스들(110)의 형태로 제 1 서비스 리퀘스터에 의해 요청되고 있다(제 1 서비스는 클리어 배경을 가진 디바이스들에 의해 도시됨). 제 2 업데이트 서비스는 개발자 디바이스(131), 조작자 디바이스(141) 및 원격 디바이스들(111)의 형태로 제 2 서비스 리퀘스터에 의해 요청되고 있다(옅은 점선 배경으로 도시됨). 제 3 업데이트 서비스는 개발자 디바이스(132), 조작자(142) 및 원격 디바이스들(112)(더 짙은 점선 배경으로 도시됨) 형태의 제 3 서비스 리퀘스터에 의해 요청되고 있다.

특정 서비스 리퀘스터의 경우, 해당 서비스의 조작자 디바이스는 해당 서비스 제공자의 개발자 디바이스로부터 관리 서버(120)에 제공된 페이로드 데이터 및 매니페스트 데이터에 액세스할 수 있다. 그러나, 특정 서비스 리퀘스터는 반드시 다른 서비스 리퀘스터의 페이로드 데이터 및 매니페스트 데이터에 액세스할 필요는 없다. 유사하게, 관리 서버에 통신 가능하게 연결된 원격 디바이스들의 서브세트는 통상적으로 특정 서비스 리퀘스터와 연관될 것이다. 따라서 이러한 원격 디바이스들은 동일한 서비스 리퀘스터와 연관된 캠페인을 사용하여 참조 및 업데이트될 수 있다. 그러나, 그 서비스 리퀘스터가 명시적으로 허용하지 않는 한, 일 서비스 리퀘스터는 서비스 리퀘스터에 속하지 않은 원격 디바이스들에 액세스하거나 업데이트할 수 없다.

도 9의 예에서, 제 1 서비스 리퀘스터는 조작자 디바이스(140) 및 개발자 디바이스(130)를 사용하여 원격 디바이스들(110) 중 적어도 일부의 업데이트를 제어할 수 있다. 그러나, 제 2 및 제 3 서비스 리퀘스터들에 의해 디바이스들이 업데이트되므로, 제 1 서비스 리퀘스터는 디바이스들(111 및 112)을 업데이트하는 것이 방지될 수 있다. 이 기능을 제공함으로써, 단일 관리 서버는 동일한 인터페이스들을 사용하여 상이한 당사자들의 여러 업데이트 캠페인들을 운영할 수 있다. 따라서 펌웨어를 업데이트하는데 통일되고 표준화된 접근 방식을 사용하여 안전한 방식으로 여러 물리적 위치에 있는 여러 디바이스들에 적용될 수 있게 된다.

당업자가 이해할 수 있는 바와 같이, 시스템의 다양한 요소들 간의 통신은 유선 연결 또는 무선 연결에 의해 수행될 수 있다. 예를 들어, 본 명세서에서 설명된 메커니즘들은 디바이스들과 서버들 사이의 업데이트 방법 및 통신 방법에 무관한 방식으로 수행될 수 있다. 예를 들어, 본 명세서에서 설명된 메커니즘들은 동일한 포맷에 의해 커버되는 USB 대용량 스토리지(CMSIS-DAP), 서버 API, UART, ZigBee, BLE, 이더넷(TFTP+DHCP) 및 WIFI를 통한 업데이트에 적용 가능하다. 또한, 디바이스들과 서버들 간의 통신은 유선 또는 무선 통신을 통해 발생할 수 있다. 다양한 디바이스들 간의 통신은 직접적이거나 간접적일 수 있고, 따라서 하나 이상의 게이트웨이를 통해 발생할 수 있으며, 디바이스들 간의 통신 채널이 확립된다면 하나 이상의 상이한 통신 프로토콜 또는 물리적 전송 매체를 통해 발생할 수도 있다.

또한 이해되는 바와 같이, 본 명세서에서 디바이스 또는 서버에 대한 언급은 단일 하드웨어 요소로 제한되는 것으로 해석되어서는 안된다. 본 명세서에 설명된 기술들은 단일 디바이스 또는 서버의 동작 또는 단일 서비스의 제공이 하나 이상의 물리적 디바이스 또는 서버 사이에 분산될 수 있는 클라우드 컴퓨팅 기술에 적용 가능하다. 따라서, 본 명세서에서 서버에 대한 언급은 단일의 설명된 서버 기능을 제공하기 위해 통신 가능하게 연결된 복수의 서버들에 대한 언급을 포함해야 한다.

일 특정 양태에서, 본 기술들은 복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터들에 대한 애셋 업데이트 서비스를 관리하기 위한 방법을 제공하며, 이 방법은 관리 서버에서, 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하는 단계; 관리 서버에서, 업데이트가 적용될 원격 디바이스들의 서브세트를 표시하는, 업데이트 데이터와 연관된 캠페인 데이터를 수신하는 단계; 및 관리 서버에서, 원격 디바이스의 애셋을 업데이트하기 위해 애셋이 검색될 것임을 나타내는 업데이트 통신을, 원격 디바이스들의 서브세트에 송신함으로써 펌웨어 업데이트를 개시하도록 하는 요청을 수신하는 단계를 포함한다.

다른 특정 양태에서, 본 기술들은 복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터들에 대한 애셋 업데이트 서비스를 관리하기 위한 관리 서버를 제공하며, 이 관리 서버는 관리 서버에서, 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하고; 관리 서버에서, 업데이트가 적용될 원격 디바이스들의 서브세트를 표시하는, 업데이트 데이터와 연관된 캠페인 데이터를 수신하며; 또한 관리 서버에서, 원격 디바이스의 애셋을 업데이트하기 위해 애셋이 검색될 것임을 나타내는 업데이트 통신을, 원격 디바이스들의 서브세트에 송신함으로써 펌웨어 업데이트를 개시하도록 하는 요청을 수신하도록 하는 적어도 하나의 인터페이스를 포함한다.

본 명세서에 설명된 방법들은 하드웨어 또는 소프트웨어 또는 하드웨어와 소프트웨어의 임의의 조합으로 구현될 수 있다. 예를 들어, 여기에 설명된 방법들은 컴퓨터 판독 가능 명령어들을 포함하는 컴퓨터 판독 가능 코드로서 구현될 수 있다. 컴퓨터 판독 가능 명령어들은 하드 디스크 또는 솔리드 스테이트 메모리와 같은 비일시적 컴퓨터 판독 가능 저장 매체를 포함하는 컴퓨터 판독 가능 저장 매체에 저장될 수 있다.

Claims (29)

1. 복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터(service requester)들에 대한 애셋 업데이트(asset update)를 가능하게 하는 방법으로서,
   관리 서버에서, 제 1 서비스 리퀘스터를 위한 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하는 단계 - 상기 업데이트 데이터는 페이로드(payload)가 저장된 위치를 나타내는 페이로드 URI(Uniform Resource Identifier)를 포함하는 매니페스트 데이터(manifest data), 상기 매니페스트 데이터의 신뢰성을 나타내는 인증 정보, 및 페이로드 해시(payload hash)를 포함함 -;
   상기 관리 서버에서, 애셋 업데이트가 상기 제 1 서비스 리퀘스터에 대해 적용될 상기 원격 디바이스들의 적어도 하나의 서브세트를 표시하는, 상기 업데이트 데이터와 연관된 캠페인 데이터(campaign data)를 수신하는 단계; 및
   상기 관리 서버에서, 상기 원격 디바이스를 업데이트하기 위해 페이로드가 검색될 것임을 나타내는 상기 매니페스트 데이터를 포함하는 업데이트 통신을, 상기 캠페인 데이터에 의해 표시된 상기 원격 디바이스들의 상기 적어도 하나의 서브세트에 송신함으로써 상기 제 1 서비스 리퀘스터에 대한 상기 애셋 업데이트를 개시하도록 하는 요청을 수신하는 단계
   를 포함하는, 방법.
2. 제 1 항에 있어서,
   상기 애셋은 상기 원격 디바이스의 펌웨어를 포함하는, 방법.
3. 제 2 항에 있어서,
   상기 업데이트 데이터는,
   상기 하나 이상의 원격 디바이스들에 적용될 펌웨어 업데이트의 펌웨어 데이터를 포함하는 페이로드 데이터; 및
   상기 페이로드 데이터의 설치와 관련된 메타데이터를 포함하는 매니페스트 데이터를 포함하는, 방법.
4. 제 3 항에 있어서,
   상기 캠페인 데이터는 상기 매니페스트 데이터와 연관된 것이며, 상기 업데이트 통신은 상기 페이로드가 적용될 매니페스트 데이터를 포함하는, 방법.
5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
   상기 캠페인 데이터는 상기 업데이트가 적용될 원격 디바이스들을 식별하기 위해 적용할 필터를 나타내는 디바이스 필터(device filter)를 포함하는, 방법.
6. 제 5 항에 있어서,
   각각의 원격 디바이스는 상기 디바이스와 관련된 정보를 식별시키는 하나 이상의 필드들과 연관되어 있고, 상기 디바이스 필터는 상기 원격 디바이스들 중 어느 원격 디바이스가 상기 캠페인 데이터에 따라 업데이트될 것인지를 식별시키는데 사용되는 하나 이상의 필드들에 대한 값들을 포함하는, 방법.
7. 제 1 항 내지 제 6 항 중 어느 한 항에 있어서,
   상기 업데이트 데이터 및 상기 캠페인 데이터는 API(application programming interface)를 통해 수신되는, 방법.
8. 제 1 항 내지 제 7 항 중 어느 한 항에 있어서,
   상기 관리 서버는 상기 원격 디바이스에서의 상기 펌웨어 업데이트의 상태를 나타내는 업데이트 상태 정보를 상기 원격 디바이스들의 서브세트로부터 수신하도록 더 구성되는, 방법.
9. 제 1 항 내지 제 8 항 중 어느 한 항에 있어서,
   상기 업데이트 데이터는 개발자 디바이스로부터 수신되고, 상기 캠페인 데이터는 조작자 디바이스로부터 수신되며, 상기 개발자 디바이스와 상기 조작자 디바이스는 제 1 서비스 리퀘스터와 연관된 것인, 방법.
10. 제 1 항 내지 제 9 항 중 어느 한 항에 있어서,
    상기 관리 서버에서, 하나 이상의 원격 디바이스들에서 업데이트될 제 2 펌웨어를 나타내는 제 2 업데이트 데이터를 수신하는 단계;
    상기 관리 서버에서, 업데이트가 적용될 상기 원격 디바이스들의 제 2 서브세트를 표시하는, 상기 제 2 업데이트 데이터와 연관된 제 2 캠페인 데이터를 수신하는 단계 - 상기 제 2 서브세트는 상기 제 1 서브세트와 상이함 -; 및
    상기 원격 디바이스의 펌웨어를 업데이트하기 위해 상기 제 2 펌웨어가 검색될 것임을 나타내는 제 2 업데이트 통신을 상기 원격 디바이스들의 상기 제 2 서브세트에 송신함으로써 상기 제 2 펌웨어 업데이트를 개시하도록 하는 요청을 수신하는 단계를 더 포함하는, 방법.
11. 제 10 항에 있어서,
    상기 제 2 업데이트 데이터는,
    하나 이상의 원격 디바이스들에 적용될 제 2 펌웨어 업데이트의 제 2 펌웨어 데이터를 포함하는 제 2 페이로드 데이터; 및
    상기 제 2 페이로드 데이터와 관련된 제 2 메타데이터를 포함하는 제 2 매니페스트 데이터를 포함하는, 방법.
12. 제 11 항에 있어서,
    상기 제 2 캠페인 데이터는 상기 제 2 매니페스트 데이터와 연관된 것이며, 상기 제 2 업데이트 통신은 상기 제 2 페이로드가 적용될 제 2 매니페스트 데이터를 포함하는, 방법.
13. 제 10 항 내지 제 12 항 중 어느 한 항에 있어서,
    상기 제 2 캠페인 데이터는 상기 제 2 업데이트가 적용될 원격 디바이스들을 식별하기 위해 적용할 제 2 필터를 나타내는 제 2 디바이스 필터를 포함하는, 방법.
14. 제 13 항에 있어서,
    각각의 원격 디바이스는 상기 디바이스와 관련된 정보를 식별시키는 하나 이상의 필드들과 연관되어 있고, 상기 제 2 디바이스 필터는 상기 원격 디바이스들 중 어느 원격 디바이스가 상기 제 2 캠페인 데이터에 따라 업데이트될 것인지를 식별시키는데 사용되는 하나 이상의 필드들에 대한 값들을 포함하는, 방법.
15. 제 10 항 내지 제 14 항 중 어느 한 항에 있어서,
    상기 제 2 업데이트 데이터 및 상기 제 2 캠페인 데이터는 API(application programming interface)를 통해 수신되는, 방법.
16. 제 10 항 내지 제 15 항 중 어느 한 항에 있어서,
    상기 관리 서버는 상기 원격 디바이스에서의 상기 제 2 펌웨어 업데이트의 상태를 나타내는 제 2 업데이트 상태 정보를 상기 원격 디바이스들의 상기 제 2 서브세트로부터 수신하도록 더 구성되는, 방법.
17. 제 10 항 내지 제 16 항 중 어느 한 항에 있어서,
    상기 제 2 업데이트 데이터는 제 2 개발자 디바이스로부터 수신되고, 상기 제 2 캠페인 데이터는 제 2 조작자 디바이스로부터 수신되고, 상기 제 2 개발자 디바이스와 상기 제 2 조작자 디바이스는 제 2 서비스 리퀘스터와 연관된 것인, 방법.
18. 제 1 항 내지 제 17 항 중 어느 한 항에 있어서,
    상기 펌웨어 업데이트를 개시하도록 하는 요청에 응답하여, 상기 원격 디바이스의 펌웨어를 업데이트하기 위해 상기 펌웨어가 검색될 것임을 나타내는 업데이트 통신을 상기 원격 디바이스들의 서브세트로 송신하는 단계를 더 포함하는, 방법.
19. 제 3 항 내지 제 18 항 중 어느 한 항에 있어서,
    상기 관리 서버에 저장된 매니페스트들의 목록에 대한 매니페스트 요청을 수신하는 단계;
    상기 매니페스트 요청에 응답하여, 상기 관리 서버에 저장된 상기 매니페스트들의 목록을 리턴하는 단계;
    상기 관리 서버에 저장된 디바이스 필터들의 목록에 대한 디바이스 필터 요청을 수신하는 단계;
    상기 디바이스 필터 요청에 응답하여, 상기 관리 서버에 저장된 상기 디바이스 필터들로부터 결정되는 유효한 디바이스 필터들의 목록을 리턴하는 단계를 더 포함하는, 방법.
20. 제 19 항에 있어서,
    상기 디바이스 필터 요청은 매니페스트를 식별시키며, 상기 방법은,
    상기 식별된 매니페스트에 정의된 하나 이상의 필드들을 만족시키는 디바이스 필터들에 기초하여, 저장된 디바이스 필터들의 서브세트를 선택함으로써 상기 관리 서버에 저장된 상기 디바이스 필터들로부터 상기 유효한 디바이스 필터들의 목록을 결정하는 단계를 더 포함하는, 방법.
21. 제 19 항 또는 제 20 항에 있어서,
    상기 디바이스 필터 요청은 매니페스트를 식별시키며, 상기 방법은,
    상기 식별된 매니페스트에 열거되어 있는 디바이스 제조자 및 모델 번호 중 적어도 하나를 만족시키는 디바이스 필터들에 기초하여, 저장된 디바이스 필터들의 서브세트를 선택함으로써 상기 관리 서버에 저장된 상기 디바이스 필터들로부터 상기 유효한 디바이스 필터들의 목록을 결정하는 단계를 더 포함하는, 방법.
22. 제 1 항 내지 제 21 항 중 어느 한 항에 있어서,
    상기 관리 서버는 상기 캠페인 데이터에 따라 하나 이상의 캠페인들을 저장하는, 방법.
23. 제 1 항 내지 제 22 항 중 어느 한 항에 있어서,
    상기 수신된 캠페인 데이터는 상기 관리 서버에서 수신되기 전에 서명되는, 방법.
24. 제 23 항에 있어서,
    상기 캠페인 데이터는 공개 키 암호화 시그니처 또는 키-해시 메시지 인증 코드(keyed-hash message authentication code, HMAC)를 사용하여 서명되는, 방법.
25. 제 22 항 또는 제 23 항에 있어서,
    상기 캠페인 데이터는 인증을 위해 상기 원격 디바이스들의 서브세트로 전송되는, 방법.
26. 복수의 원격 디바이스들에서 하나 이상의 서비스 리퀘스터들에 대한 애셋 업데이트를 가능하게 하는 관리 서버로서,
    상기 관리 서버에서, 제 1 서비스 리퀘스터를 위한 하나 이상의 원격 디바이스들에서 업데이트될 애셋을 나타내는 업데이트 데이터를 수신하고 - 상기 업데이트 데이터는 페이로드가 저장된 위치를 나타내는 페이로드 URI(Uniform Resource Identifier)를 포함하는 매니페스트 데이터, 상기 매니페스트 데이터의 신뢰성을 나타내는 인증 정보, 및 페이로드 해시를 포함함 -;
    상기 관리 서버에서, 업데이트가 상기 제 1 서비스 리퀘스터에 대해 적용될 상기 원격 디바이스들의 적어도 하나의 서브세트를 표시하는, 상기 업데이트 데이터와 연관된 캠페인 데이터를 수신하며; 또한
    상기 관리 서버에서, 상기 원격 디바이스를 업데이트하기 위해 페이로드가 검색될 것임을 나타내는 상기 매니페스트 데이터를 포함하는 업데이트 통신을, 상기 캠페인 데이터에 의해 표시된 상기 원격 디바이스들의 상기 적어도 하나의 서브세트에 송신함으로써 상기 제 1 서비스 리퀘스터에 대한 상기 애셋 업데이트를 개시하도록 하는 요청을 수신하도록 하는
    적어도 하나의 인터페이스를 포함하는, 관리 서버.
27. 제 1 항 내지 제 25 항 중 어느 한 항의 방법을 수행하기 위한, 장치.
28. 프로세서에 의해 실행될 때, 상기 프로세서로 하여금 제 1 항 내지 제 25 항 중 어느 한 항의 방법을 수행하게 하는 컴퓨터 판독 가능 명령어들을 포함하는, 코드.
29. 제 28 항의 코드를 저장하도록 구성되는, 컴퓨터 판독 가능 저장 매체.

Images