KR20240030815A - 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스 - Google Patents

디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스 Download PDF

Info

Publication number
KR20240030815A
KR20240030815A KR1020220110324A KR20220110324A KR20240030815A KR 20240030815 A KR20240030815 A KR 20240030815A KR 1020220110324 A KR1020220110324 A KR 1020220110324A KR 20220110324 A KR20220110324 A KR 20220110324A KR 20240030815 A KR20240030815 A KR 20240030815A
Authority
KR
South Korea
Prior art keywords
certificate
layer
updating
key
unique
Prior art date
Application number
KR1020220110324A
Other languages
English (en)
Inventor
추연성
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020220110324A priority Critical patent/KR20240030815A/ko
Priority to US18/458,070 priority patent/US20240073033A1/en
Priority to CN202311099330.6A priority patent/CN117640096A/zh
Priority to EP23194683.1A priority patent/EP4333361A1/en
Publication of KR20240030815A publication Critical patent/KR20240030815A/ko

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3265Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)

Abstract

개시된 실시예에 따른 디바이스는 디바이스 식별자 및 고유 보증 아이디를 생성하는 디바이스 식별 엔진; 상기 디바이스 식별자를 수신하고, 상기 디바이스를 인증하는 제1 인증서 및 제2 인증서를 생성하는 제1 레이어;및 상기 제1 인증서 및 상기 제2 인증서를 수신하고 상기 디바이스의 업데이트 여부를 검증하는 제2 레이어를 포함하되, 상기 제1 레이어가 업데이트된 경우, 상기 제1 레이어는 상기 고유 보증 아이디에 기초하여 보증 키(Endorsement Key)를 생성하고, 상기 보증 키에 기반하여 보증 아이디의 서명 요청을 생성한다.

Description

디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스{Device certificate update method and device driving the same}
개시된 실시예는 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스에 관한 것으로, 더욱 상세하게는 디바이스가 변경된 경우 디바이스의 식별을 위한 인증서를 검증하고 인증서 체인을 업데이트 하는 방법에 관한 것이다.
일반적으로 공개키 기반 구조(Public Key Infrastructure, PKI)에서 디바이스들 사이에서 전자 서명은 개인키(또는 비밀키, Private Key)를 이용하여 생성하며 전자서명은 공개키(Public Key)를 이용하여 검증이 가능하다. 공개키 기반 구조(PKI)에서는 인증 기관(Certificate Authority)에서 공개키에 대한 보증을 위해서 인증서를 발행하며 해당 장치의 공개키에 대한 확인을 위해서는 인증 기관이 발행한 공개키가 맞는지를 인증서의 체인 검증을 통해서 확인하게 된다.
인증 기관은 디바이스의 제조 주체가 변경되는 경우, 새로운 인증서를 발급하게 되는데 여기서 SPDM(Secure Protocol and Data Model)이 활용된다.
상술한 SPDM에 의하여 보안 신호를 생성하는 디바이스는 ROM, 디바이스 식별 엔진 및 부트로더(Bootloader), 펌웨어를 포함할 수 있는데 부트로더가 디바이스의 사용 주체에 의하여 업데이트 되는 경우 디바이스가 구동되는데 오류가 발생할 수 있다.
이에, 개시된 실시예는 부트로더가 변경되더라도 디바이스의 정상적인 구동이 가능하게 하는 인증서 업데이트 방법을 제공하고자 한다.
개시된 실시예에 따른 디바이스는 디바이스 식별자 및 고유 보증 아이디를 생성하는 디바이스 식별 엔진; 상기 디바이스 식별자를 수신하고, 상기 디바이스를 인증하는 제1 인증서 및 제2 인증서를 생성하는 제1 레이어;및 상기 제1 인증서 및 상기 제2 인증서를 수신하고 상기 디바이스의 업데이트 여부를 검증하는 제2 레이어를 포함하되, 상기 제1 레이어가 업데이트된 경우, 상기 제1 레이어는 상기 고유 보증 아이디에 기초하여 보증 키(Endorsement Key)를 생성하고, 상기 보증 키에 기반하여 보증 아이디의 서명 요청을 생성한다.
또한, 개시된 실시예에 따른 디바이스 인증서의 업데이트 방법은 디바이스 식별 엔진이 디바이스 식별자 및 고유 보증 아이디를 생성하는 단계; 제1 레이어가 상기 디바이스 식별자를 수신하고, 상기 디바이스를 인증하는 제1 인증서 및 제2 인증서를 생성하는 단계;및 제2 레이어가 상기 제1 인증서 및 상기 제2 인증서를 수신하고 상기 디바이스의 업데이트 여부를 검증하는 단계를 포함하되, 상기 제1 레이어가 업데이트된 경우, 상기 제1 인증서 및 제2 인증서를 생성하는 단계는, 상기 고유 보증 아이디에 기초하여 보증 키(Endorsement Key)를 생성하고, 상기 보증 키에 기반하여 보증 아이디의 서명 요청을 생성하는 단계를 포함한다.
또한, 개시된 실시예에 따른 디바이스의 부트로더가 업데이트 된 경우 변경된 상기 디바이스의 인증서를 업데이트 하는 방법은 루트 인증서의 제1 체인에 기초하여 중간 인증서를 검증하는 단계; 상기 중간 인증서의 제2 체인에 기초하여 상기 부트로더의 변경 여부를 검증하는 단계;및 상기 부트로더가 변경된 것으로 판단되면, 디바이스 서명 요청에 기초하여 상기 중간 인증서에 상기 디바이스 인증서 체인을 업데이트 하는 단계를 포함한다.
상술한 구성을 포함함으로써, 개시된 실시예는 부트로더가 변경되더라도 디바이스의 정상적인 구동이 가능하게 하는 인증서 업데이트 방법을 제공한다.
도 1은 개시된 실시예에 따른 디바이스의 블록도이다.
도 2는 개시된 실시예에 따른 프로세서를 도시한 블록도이다.
도 3은 개시된 실시예에 따른 디바이스 식별 엔진을 도시한 것이다.
도 4는 개시된 실시예에 따른 제1 레이어를 도시한 것이다.
도 5는 개시된 실시예에 따른 제2 레이어를 도시한 것이다.
도 6은 개시된 실시예에 따른 제조사 인증서 블록을 도시한 것이다.
도 7은 개시된 실시예에 따른 중간 생산자 인증서 블록을 도시한 것이다.
도 8은 개시된 실시예에 따른 인증서를 업데이트 하는 것을 도시한 블록도이다.
도 9는 개시된 실시예에 따른 인증서들이 체인으로 결합된 것을 도시한 것이다.
도 10는 개시된 실시예에 따른 인증서 업데이트 방법의 순서도이다.
도 11은 개시된 실시예에 따른 인증서 업데이트 방법에서 서명 요청을 생성하는 과정을 도시한 순서도이다.
도 12은 개시된 실시예에 따른 인증서 업데이트 방법에서 인증서 체인을 업데이트 하는 과정을 도시한 것이다.
도 13는 개시된 실시예에 따른 인증서 업데이트 방법에서 인증서를 검증하고 업데이트 하는 과정을 도시한 것이다.
도 14는 개시된 실시예에 따른 프로세서의 구현예를 도시한 것이다.
본 명세서에서 사용되는 용어에 대해 간략히 설명하고, 실시예들에 대해 구체적으로 설명하기로 한다.
도 1은 개시된 실시예에 따른 디바이스(10)의 블록도이다.
도 1을 참조하면, 본 발명의 일 실시예에 따른 디바이스(10)는 프로세서(100)과 보안 저장소 (Secure Storage, 200)를 포함할 수 있다.
도 1에 도시된 바와 같이, 디바이스(10)은 전자 장치로서 데이터를 처리할 수 있다. 일 예로서, 디바이스(10)의 프로세서(100)는 이동 단말기(mobile device), 스마트 폰(smart phone), PDA(personal digital assistant), PC(personal computer), 태블릿(tablet) PC, 노트북, 넷-북(net-book), 가전 장치 등 다양한 전자 장치에 포함된 구성일 수 있다.
프로세서(100)는 디바이스 식별 엔진(DICE: Device Identify Certificate Engine, 110), 제1 레이어(LAYER0, 120) 및 제2 레이어(LAYER1, 130)를 포함한다.
디바이스 식별 엔진(110)은 디바이스 고유의 식별자를 생성하고 제1 레이어(110)로 디바이스 고유의 식별자를 전달할 수 있다. 여기서, 디바이스 고유의 식별자는 디바이스 인증서를 생성하는데 사용될 수 있다. 또한, 디바이스 식별자는 1회성으로 생성되는 고유의 값일 수 있고, OTP(One time program)을 활용하여 생성될 수 있다. 디바이스 식별 엔진(110)의 구성은 도 2 및 도 3에서 상세히 설명한다.
제1 레이어(120)는 디바이스 식별자(110)로부터 고유의 장지 식별자를 수신하고, 디바이스 인증서 및 에일리어스 인증서를 생성할 수 있다. 또한, 제1 레이어는 디바이스를 부팅하는데 활용되는 부트로더(Boot Loader)일 수 있으며, 디바이스 인증기관으로 디바이스 아이디 서명 요청을 전달할 수 있다. 또한, 제1 레이어(120)는 에일리어스 키, 에일리어스 인증서, 디바이스 아이디 인증서 및 보증 아이디 인증서를 저장하고 제2 레이어(130)에 제공할 수 있다. 예를 들면, 제1 레이어(120)는 에일리어스 키, 에일리어스 인증서, 디바이스 아이디 인증서 및 보증 아이디 인증서를 저장하고, 제2 레이어(130)에 제공하는 램(RAM)으로 구성될 수 있다. 제1 레이어(120)에 대한 설명은 도2 및 도 4에서 상세히 설명한다.
제2 레이어(130)는 디바이스 인증서 및 디바이스 인증서 체인을 저장할 수 있다. 예를 들면, 제2 레이어(130)는 디바이스(10)를 식별하는 인증 기관을 포함하도록 구성된 펌웨어(Firmware)일 수 있다. 예를 들면, 제2 레이어(130)는 SPDM(Secure Protocol and Data Model) 펌웨어일 수 있고, 후술하는 요청자 및 인증서 스토리지가 동작하는 계층일 수 있다. 제2 레이어(130)는 제1 레이어(120)로부터 수신한 에일리어스 키, 에일리어스 인증서, 디바이스 아이디 인증서 및 보증 아이디 인증서를 수신하고 SPDM 프로토콜을 수행할 수 있다. 제2 레이어(130)에 대한 설명은 도 2 및 도 5에서 상세히 설명한다.
보안 스토리지(200)는 반도체 칩으로서 집적 회로(Integrated Circuit, IC)로 구현될 수 있으며, 이에 따라 보안 스토리지(200)는 보안 칩(Security Chip)으로 지칭될 수 있다. 보안 스토리지(200)는 그 내부에 프로세서나 암호화 엔진 등을 포함할 수 있으며, 그 내부에서 수행되는 각종 기능들은 임베디드 하드웨어나 임베디드 소프트웨어로 구현될 수 있다. 보안 스토리지(200)에 구현되는 하드웨어 및/또는 소프트웨어는 공개키 기반의 구조(PKI)에서 인증서 생성에 관련된 동작 및 암호화/복호화에 관련된 동작을 수행할 수 있다.
보안 스토리지(200)는 외부의 공격으로부터 그 내부의 정보를 보호할 수 있는 수단을 포함할 수 있다. 일 예로서, 보안 스토리지(200)는 하드웨어로 구현되는 보호 수단을 포함할 수 있으며, 상기 보호 수단을 통해 외부에서 보안 스토리지(200) 내부의 정보에 접근하는 것을 차단하거나, 또는 외부에서 보안 스토리지(200)의 내부의 정보에 접근하더라도 그 정보를 변경함으로써 원래의 정보가 외부로 유출되는 것을 방지할 수 있다.
보안 스토리지(200)에는 공개키 기반의 통신에 관련된 하나 이상의 키들이 인스톨되어 저장되고, 상기 저장된 키들을 이용한 각종 연산 동작을 수행할 수 있다. 일 예로서, 보안 스토리지(200)는 인증서 생성에 관련된 개인키(예컨대, 인증서 개인키(CA-SK))를 저장할 수 있다. 또한, 보안 스토리지(200)는 공개키 기반의 통신을 수행하기 위한 키 쌍(예컨대, 디바이스 공개키(DEV-PK) 및 디바이스 개인키(DEV-SK))를 저장할 수 있다. 일 예로서, 보안 스토리지(200)는 그 제조 공정시 키 쌍이 인스톨되어 저장될 수 있다. 변형 가능한 실시예로서, 보안 스토리지(200)가 그 내부에 키 쌍을 생성하는 소프트웨어(미도시)를 포함함에 따라, 보안 스토리지(200)의 초기 구동시 디바이스 공개키(DEV-PK) 및 디바이스 개인키(DEV-SK)가 생성될 수도 있다.
한편, 디바이스(10)는 SPDM(Secure Protoclo and Data Model) 등과 같은 보안 프로토콜에 따라 외부의 디바이스와 통신할 수 있다. 일 예로서, 공개키 기반의 통신에서, 외부로 노출되지 않을 필요가 있는 중요한 정보를 이용한 연산은 응답자(Responder, 220)에서 처리되고, 그 연산 결과가 제1 레이어(120)로 제공될 수 있다.
일 예로서, RSA(Rivest Shamir Adleman), ECC(Elliptic Curve Cryptography) 및 DSS(Digital Signature Standard) 등과 같은 암호화 연산에서 디바이스 개인키(DEV-SK)를 이용한 연산이 응답자(220)에서 수행될 수 있다. 또한, 디바이스(10)에 대한 인증을 위해 수행되는 디바이스 개인키(DEV-SK)를 이용한 서명(예컨대, RSA Sign)은 프로토콜 에이전트(220)에서 수행될 수 있다. 또한, 응답자(220)는 요청자(Requester)로부터 보안 프로토콜에 따라 처리된 데이터를 수신할 수 있다. 요청자 에 대한 설명은 도 4에서 상세히 설명한다.
상기와 같은 구성에 따라, 디바이스(10)는 인증서 개인키나 디바이스 개인키 등의 중요 정보의 노출 없이 안전하게 인증서를 발급할 수 있으며, 또한 안전한 보안 프로토콜을 수행할 수 있다. 즉, 인증서 발급 과정이나 보안 프로토콜에 따른 통신을 수행하는 과정에서, 인증서 개인키나 디바이스 개인키를 소프트웨어적으로 암호화하여 이용하는 경우에 비해 상기 개인키들의 노출 가능성을 감소할 수 있다. 상기와 같은 구성에 따라,
도 2는 개시된 실시예에 따른 프로세서(100)를 도시한 블록도이다. 또한, 도 3은 개시된 실시예에 따른 디바이스 식별 엔진을 도시한 것이고, 도 4는 개시된 실시예에 따른 제1 레이어를 도시한 것이고, 도 5는 개시된 실시예에 따른 제2 레이어를 도시한 것이다.
도 2 및 도 3을 참조하면, 프로세서(100)는 디바이스 식별 엔진(110), 제1 레이어(120) 및 제2 레이어(130)을 포함한다.
디바이스 식별 엔진(110)은 디바이스 정보 저장부(111), 제1 함수 생성부(112) 및 제2 함수 생성부(113)을 포함할 수 있다.
디바이스 정보 저장부(111)에는 디바이스(10)의 제조 단계에서 디바이스의 고유 정보가 미리 저장되어 있을 수 있다. 예를 들면, 디바이스 정보 저장부(111)는 노어(NOR) 플래시 메모리 및 낸드(NAND) 플래시 메모리를 포할 수 있으며, OTP(One time programmable) 영역의 임의의 구역에 저장되어 있을 수 있다. 또한, 디바이스 정보 저장부(111)는 하드웨어 형태로 존재할 수 있으며, 저장된 디바이스 정보는 싸이레스 래치(Cyres Latch, CYber Resilient Embedded Systems Latch)를 통하여 접근될 수 있다.
제1 함수 생성부(112)는 디바이스 정보 저장부(111)로부터 디바이스(10) 고유의 정보(CDS)를 수신하고, 제1 레이어(120)로부터 디바이스 아이디(ID)를 수신한다. 제1 함수 생성부(112)는 디바이스 고유의 정보(CDS) 및 디바이스 아이디(ID)를 미리 저장된 함수에 입력할 수 있다. 여기서, 미리 저장된 함수는 HMAC(Hash-based message authentication code)일 수 있으나 이에 한정되는 것은 아니다. 또한, 디바이스 아이디(ID)는 제1 레이어(120)의 해시(Hash) 값 또는 특성(Measurement)값일 수 있다. 예를 들면, 제1 함수 생성부(112)에 저장된 함수가 HMAC 함수인 경우 제1 함수 생성부(111)가 수신하는 디바이스 아이디(ID)는 제1 레이어(120) 코드의 해시(Hash) 값 형태일 수 있다. 여기서, HMAC 함수는 입력은 고유 디바이스 비밀 데이터(UDS) 및 디바이스 아이디(ID)일 수 있다.
제2 함수 생성부(113)는 디바이스 정보 저장부(111)로부터 디바이스(10) 고유의 정보를 수신하고 고유 보증 아이디(UEI)를 생성할 수 있다. 여기서, 제2 함수 생성부(113)는 미리 저장된 함수에 디바이스(10)의 고유 정보를 입력하고, 고유 보증 아이디(UEI)를 생성할 수 있다. 예를 들면, 제2 함수 생성부(113)는 고유 디바이스 비밀 데이터(UDS)를 입력으로 하고, 고유 보증 아이디(UEI)를 출력으로 할 수 있다. 여기서 제2 함수 생성부(113)에 저장된 함수는 키 유도 함수(KDF)일 수 있다. 제1 레이어(120)가 실행되는 경우, 제2 함수 생성부(113)는 생성된 고유 보증 아이디(UEI)를 제1 레이어(120)에 전달할 수 있다. 또한, 고유 보증 아이디(UEI)는 고유 디바이스 비밀 데이터(UDS)로부터 생성되는 것이므로 디바이스(10)가 제조될 당시 입력된 고유 정보를 포함할 수 있다. 또한, 디바이스 식별 엔진(110)은 롬(ROM) 형식의 메모리일 수 있다.
도 2 및 도 4를 참조하면, 제1 레이어(120)는 에일리어스키 저장부(121), 디바이스 아이디 저장부(122), 고유 보증 아이디 저장부(123), 에일리어스키 인증서 생성부(124), 디바이스 아이디 인증서 생성부(125) 및 서명 요청 생성부(126)를 포함한다.
에일리어스키 저장부(121)는 디바이스 식별 엔진(110)으로부터 디바이스 식벽자(CDI) 및 제2 레이어(130)으로부터 펌에어 정보(FD)를 수신하고, 에일리어스키(Alias Key)를 생성한다. 에일리어스키는 에일리어스 개인키(Alias_SK) 및 에일리어스 공개키(Alias_PK)의 비대칭 쌍으로 생성될 수 있다. 여기서, 에일리어스키 쌍(Alias_SK, Alias_PK)은 디바이스 정보를 인증하기 위한 임시 키일 수 있으며, 제2 레이어(130)로 전달된다. 또한, 에일리어스 공개키(Alias_PK)는 에일리어스키 인증서 생성부(123)으로 전달될 수 있다.
디바이스 아이디 저장부(122)는 디바이스 식별자(CDI)를 수신하고, 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)를 생성한다. 여기서, 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)는 비대칭 쌍을 이루며 생성될 수 있으며, 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)는 디바이스 아이디를 구성할 수 있다. 또한, 디바이스 개인키(DEV_SK)는 에일리어스키 인증서 생성부(124)로 전달되고, 디바이스 공개키(DEV_PK)는 디바이스 아이디 인증서 생성부(125)로 전달될 수 있다. 여기서, 디바이스 아이디는 제1 레이어(120)의 해시(Hash) 값 또는 특성(Measurement)값일 수 있다.
고유 보증 아이디 저장부(123)는 디바이스 식별 엔진(110)으로부터 고유 보증 아이디(UEI)를 수신하고, 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)를 생성한다. 고유 보증 아이디(UEI)는 디바이스(10)의 고유 정보를 포함하므로, 보증 개인키(EN_SK) 및 보증 공개키(EN_PK) 또한, 디바이스(10)를 인증하기 위한 고유 정보를 포함한 키 쌍(Pair)일 수 있다. 여기서, 보증 개인키(EN_SK)는 디바이스 아이디 인증서 생성부(125) 및 서명 요청 생성부(126)으로 전달되고, 보증 공개키(EN_PK)는 서명 요청 생성부(126)로 전달될 수 있다. 즉, 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)는 각각 제1 레이어(120)의 변경 여부를 판단하는 인증키로 활용될 수 있다. 따라서, 제1 레이어(120)가 변경되면, 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)도 변경될 수 있다.
에일리어스키 인증서 생성부(124)는 제2 레이어(130)에서 수신한 펌웨어 정보(FD), 에일리어스 공개키(Alias_PK) 및 디바이스 개인키(DEV_SK)를 수신하고 에일리어스 인증서(Alias_Cert)를 생성한다. 에일리어스 인증서(Alias_Cert)는 디바이스 아이디를 암호화 한 것으로 제1 레이어(110)의 업데이트 여부를 확인하는데 활용될 수 있다. 여기서, 에일리어스키 인증서(Alias_Cert)는 디바이스(10)의 정보를 암호화한 인증서일 수 있다. 따라서, 에일리어스 인증서(Alias_Cert)는 제1 레이어(120)가 변경되면 변경될 수 있다.
또한, 디바이스 아이디 인증서 생성부(125)는 디바이스 공개키(DEV_PK) 및 보증 개인키(EN_SK)를 수신하고 디바이스 아이디 인증서(DEVID_Cert)를 생성한다. 디바이스 아이디 인증서(DEVID_Cert)는 제2 레이어(130)의 요청자 (131)에 저장된 제조사 인증서와 체인을 형성할 수 있으며, 제1 레이어(120)의 업데이트 여부를 확인하는데 활용될 수 있다. 예를 들면, 디바이스 아이디 저장부(122)는 디바이스 식별자(CDI)에 기초하여 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)를 생성하므로, 제1 레이어(120)가 변경되는 경우 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)가 변경될 수 있다. 따라서, 제1 레이어(120)가 업데이트 되는 경우, 디바이스 개인키(DEV_SK) 및 디바이스 공개키(DEV_PK)가 변경되고, 디바이스 아이디 인증서(DEVID_Cert)는 변경될 수 있다. 여기서, 디바이스 아이디 인증서(DEVID_Cert)는 X.509 형식을 가질 수 있다. 또한, 디바이스 아이디 인증서(DEVID_Cert)는 보증 개인키(EN_SK)의 서명에 의하여 생성될 수 있다.
서명 요청 생성부(126)는 보증 공개키(EN_PK) 및 보증 개인키(EN_SK)를 수신하고, 보증 아이디 서명 요청(ENID_CSR)을 생성할 수 있다. 즉, 보증 아이디 서명 요청(ENID_CSR)은 디바이스 식별자(CDI)에 기초하여 생성된 보증 개인키(EN_SK)로 서명하여 생성될 수 있다. 제2 레이어(130)로 제공된다. 예를 들면, 보증 아이디 서명 요청(ENID_CSR)은 디바이스 식별자(CDI)에 기초하여 생성된 보증 공개키(EN_PK) 및 보증 개인키(EN_SK)에 기반하여 생성될 수 있다. 한편, 제1 레이어(120)가 변경되면, 디바이스 식별자(CDI)가 변경되므로 디바이스 보증 서명 요청(ENID_CSR)도 변경된다. 따라서, 제1 레이어(120)가 변경되면, 디바이스 아이디 서명 요청(DEVID_CSR)도 변경된다. 후술하는 바와 같이 제2 레이어(120)는 디바이스 아이디 서명 요청(DEVID_CSR)의 변경 여부에 기초하여 제1 레이어(120)의 변경 여부를 판단하고, 제1 레이어(120)의 정보를 업데이트 할 수 있다. 또한, 후술하는 바와 같이 서명 요청(ENID_CSR)은 제1 레이어(120)가 변경된 경우 인증서 체인을 업데이트 하는 데 활용될 수 있다.
도 2 및 도 5를 참조하면, 제2 레이어(130)는 요청자(131) 및 인증서 스토리지(132)를 포함할 수 있다.
요청자(131)는 제1 레이어(120)가 업데이트 된 경우, 응답자(220)로부터 인증서 체인의 정보를 수신하고, 인증서 체인을 검증한다. 예를 들면, 제1 레이어(120)가 업데이트 된 경우, 요청자(131)는 응답자(220)으로부터 디바이스(10)에 미리 저장된 인증서 체인의 루트 인증서, 중간 인증서를 검증할 수 있다. 여기서, 요청자(131)는 루트 인증서에 포함된 루트 인증서 공개키에 의하여 중간 인증서의 서명을 검증하고, 중간 인증서의 서명 검증이 성공되면, 중간 인증서에 포함된 공개키에 기초하여 디바이스 인증서를 검증할 수 있다. 여기서, 루트 인증서는 디바이스(10)의 제조 당시 제조사가 미리 저장한 인증서이고, 중간 인증서는 제1 레이어(120)의 변경 여부를 검증하는 인증서일 수 있다. 또한, 디바이스 인증서는 제1 레이어(120)의 정보를 포함하는 인증서일 수 있다. 제1 레이어(120)가 업데이트 된 경우 인증서를 검증하는 과정에 대한 설명은 도 9에서 상세히 설명한다.
인증서 스토리지(132)는 복수의 슬롯들(132_1, 132_2, 132_3, ···)을 포함하고, 인증서 블록들을 저장할 수 있다. 여기서, 인증서 블록은 디바이스의 정보를 포함하는 루트 인증서, 중간 인증서 및 디바이스 인증서를 포함할 수 있다. 인증서 블록에 대한 설명은 도 6에서 상세히 설명한다. 다만, 슬롯의 개수는 이에 한정되지 아니하고 제n 슬롯(131_n)을 더 포함할 수 있다. 요청자(131)는 복수의 슬롯에 저장된 인증서들에 기초하여 디바이스(10)의 구성에 변경이 있는지 여부를 확인할 수 있다. 예를 들면, 제1 레이어(120)가 중간 생산자(OEM)에 의하여 변경되는 경우, 요청자(131)은 복수의 슬롯에 새로운 제1 레이어(120) 정보를 포함한 인증서를 저장한다.
인증서 스토리지(132)는 미리 저장된 보안 프로토콜을 수행하도록 프로세서(100)를 제어할 수 있다. 예를 들면, 인증서 스토리지(132)는 SPDM 프로토콜을 미리 저장하고, 프로세서(100)의 제1 레이어(120)가 업데이트 되는 경우, 업데이트된 제1 레이어를 인증하고, 인증서 체인을 업데이트 하는 동작을 제어할 수 있다.
도 6은 개시된 실시예에 따른 제조사 인증서 블록(M_cert Blk)을 도시한 것이다.
도 6을 참조하면, 개시된 실시예에 따른 제조사 인증서는 제1 슬롯(132_1)에 저장되어 있을 수 있다.
상술한 바와 같이 제조사 인증서 블록(M_cert Blk)은 제조사 루트 인증서(MR_Cert, 132_1a), 제조사 중간 인증서(MI_Cert, 132_1b) 및 제조사 보증 인증서(ME_Cert, 132_1c)가 체인(CHN)을 형성하여 저장되어 있고, 디바이스 인증서(Dev_Cert, 132_1d) 및 에일리어스 인증서(Alias_Cert, 132_1e)를 포함할 수 있다.
예를 들면, 디바이스(10)의 제조사(Manufacture)는 디바이스(10)를 제조할 때, 디바이스(10)의 고유 정보를 포함하는 제조사 인증서 블록(M_cert Blk)을 제1 슬롯(132_1)에 저장할 수 있다. 제조사 루트 인증서(MR_Cert, 131_1a)는 제조사 중간 인증서(MI_Cert, 132_1b)의 서명에 의하여 제조사 중간 인증서(MI_Cert, 132_1b)를 검증하고 체인(CHN)을 형성할 수 있다. 또한, 제조사 중간 인증서(MI_Cert, 132_1b)는 제조사 보증 인증서(ME_Cert, 132_1c)의 서명을 검증하고, 제조사 보증 인증서(ME_Cert, 132_1c)와 체인(CHN)을 형성할 수 있다. 제조사 루트 인증서(MR_Cert, 132_1a), 제조사 중간 인증서(MI_Cert, 132_1b) 및 제조사 보증 인증서(ME_Cert, 132_1c)가 체인을 형성하면, 디바이스(10)에 대한 인증이 완료된다.
또한, 제조사 인증서 블록(M_cert Blk)은 제조사 보증 인증서(ME_Cert)에 기초하여 발급된 디바이스 인증서(Dev_Cert, 132_1d)와 디바이스 인증서(Dev_Cert, 132_1d)에 기초하여 발급된 에일리어스 인증서(Alias_Cert, 132_1e)를 포함할 수 있다. 여기서, 제조사 루트 인증서(MR_Cert, 132_1a), 제조사 중간 인증서(MI_Cert, 132_1b) 및 제조사 보증 인증서(ME_Cert, 132_1c)가 체인을 형성하면, 디바이스(10)에 대한 인증이 성공적으로 완료된 것으로 판단할 수 있다. 또한, 인증서 스토리지(132)는 디바이스 인증서(Dev_Cert, 132_1d)와 에일리어스 인증서(Alias_Cert, 132_1e)는 신뢰할 수 있는 인증서로 판단될 수 있다. 또한, 디바이스 인증서(Dev_Cert, 132_1d)와 에일리어스 인증서(Alias_Cert, 132_1e)는 신뢰할 수 있는 인증서로 판단되면, 인증서 스토리지(132)는 디바이스(10) 인증 절차를 성공한 것으로 판단할 수 있다. 디바이스(10) 인증 절차가 성공된 것으로 판단되면, 인증서 스토리지(132)는 프로세서(100)를 신뢰할 수 있게 된다.
도 7은 개시된 실시예에 따른 중간 생산자 인증서 블록(OEM_cert Blk)을 도시한 것이다.
도 7을 참조하면, 개시된 실시예에 따른 중간 생산자 인증서 블록(OEM_cert Blk)는 제2 슬롯(132_2)에 저장되어 있을 수 있다. 다만, 중간 생산자 인증서 블록(OEM_cert Blk)은 제3 슬롯 또는 제4 슬롯과 같은 제n 슬롯에 저장될 수도 있으며, 후술하는 방법과 같은 방법으로 커스터머 인증서 블록이 제n 슬롯에 추가적으로 저장될 수 있다.
중간 생산자 인증서 블록(OEM_cert Blk)은 중간 생산자 루트 인증서(OEM MR_Cert, 132_2a), 중간 생산자 중간 인증서(OEM I_Cert, 132_2b), 중간 생산자 보증 인증서(OEM EN_Cert, 132_2c) 및 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)가 체인(CHN)을 형성하여 저장되어 있고, 에일리어스 인증서(Alias_Cert, 132_2e)를 포함할 수 있다.
예를 들면, 디바이스(10)의 중간 생산자(OEM)는 디바이스(10)를 제조할 때, 디바이스(10)의 업데이트 정보를 중간 생산자 인증서 블록(OEM_cert Blk)을 제2 슬롯(132_2)에 저장할 수 있다. 중간 생산자 루트 인증서(OEM R_Cert, 132_2a)는 증간 생산자 중간 인증서(OEM I_Cert, 132_2b)의 서명에 의하여 중간 생산자 중간 인증서(OEM I_Cert, 132_2b)를 검증하고 체인(CHN)을 형성할 수 있다. 또한, 중간 생산자 중간 인증서(OEM I_Cert, 132_2b)는 중간 생산자 보증 인증서(OEM EN_Cert, 132_1c)의 서명을 검증하고, 중간 생산자 보증 인증서(OEM EN_Cert, 132_2c)와 체인(CHN)을 형성할 수 있다. 또한, 중간 생산자 보증 인증서(OEM EN_Cert)는 중간 생산자 디바이스 인증서(OEM DEVID_Cert)의 서명에 의하여 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)와 체인(CHN)을 형성할 수 있다. 중간 생산자 루트 인증서(OEM R_Cert, 132_2a), 증간 생산자 중간 인증서(OEM I_Cert, 132_2b), 중간 생산자 보증 인증서(OEM EN_Cert, 132_1c) 및 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)가 체인을 형성하면, 디바이스(10)에 대한 인증이 완료된다.
또한, 중간 생산자 인증서 블록(OEM_cert Blk)은 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)에 기초하여 생성된 에일리어스 인증서(Alias_Cert, 132_2e)를 포함할 수 있다. 여기서, 중간 생산자 루트 인증서(OEM MR_Cert, 132_2a), 중간 생산자 중간 인증서(OEM I_Cert, 132_2b), 중간 생산자 보증 인증서(OEM EN_Cert, 132_2c) 및 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)가 체인을 형성하면, 인증서 스토리지(132)는 디바이스(10) 인증 절차를 성공한 것으로 판단할 수 있다. 또한, 디바이스(10)에 대한 인증이 성공적으로 완료된 것으로 판단되면, 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)와 에일리어스 인증서(Alias_Cert, 132_2e)는 신뢰할 수 있는 인증서로 판단될 수 있다. 또한, 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d)와 에일리어스 인증서(Alias_Cert, 132_2e)가 신뢰할 수 있는 인증서로 판단되면, 인증서 스토리지(132)는 디바이스(10) 인증 절차를 성공한 것으로 판단할 수 있다. 디바이스(10) 인증 절차가 성공된 것으로 판단되면, 인증서 스토리지(132)는 프로세서(100)를 신뢰할 수 있게 된다.
도 8은 개시된 실시예에 따른 인증서를 업데이트 하는 것을 도시한 블록도이다.
도 8을 참조하면, 제1 레이어(120)가 중간 생산자(OEM)의 레이어로 변경되는 경우 제1 레이어(120)에 저장된 디바이스 인증서(DEV_Cert)도 변경되기 때문에 디바이스(10)의 정상적인 구동을 위해서는 디바이스 인증서가 업데이트 되어야 한다. 여기서, 개시된 실시예는 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d) 또는 에일리어스 인증서(Alias_Cert, 132_2e)중 어느 하나를 활용할 수 있다. 예를 들면, 제1 레이어(120)가 중간 생산자에 의하여 변경된 경우, 기존에 저장된 제조사 루트 인증서(MR_Cert), 제조사 중간 인증서(MI_Cert) 및 제조자 디바이스 인증서(MDEV_Cert)를 사용하는 경우 디바이스(10)는 오류를 발생시킨다. 따라서, 제1 레이어(120)가 변경되면 요청자(131)는 제1 레이어(120)가 변경된 것을 감지하고, 인증서 스토리지(132)는 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d) 또는 에일리어스 인증서(Alias_Cert, 132_2e)중 어느 하나를 요청할 수 있다. 여기서, 요청자(131)는 중간 생산자 디바이스 인증서(OEM DEVID_Cert, 132_2d) 또는 에일리어스 인증서(Alias_Cert, 132_2e)중 어느 하나를 제공함으로써 디바이스(10)의 인증서 체인을 업데이트 하고, 디바이스(10)의 제1 레이어(120) 업데이트를 성공적으로 인증할 수 있다.
즉, 개시된 실시예에 따른 디바이스(10)의 제1 레이어(120)가 업데이트 된 경우, 프로세서(100)는 제1 슬롯(132_1)에 저장된 제1 인증서에 기초하여 제1 레이어(120)의 변경여부를 판단하고, 제1 레이어(120)가 변경된 것으로 판단되면, 변경된 인증 정보를 수신하고, 변경된 인증서 체인을 포함하는 제2 인증서의 정보를 제2 슬롯(132_2)에 업데이트 할 수 있다. 여기서 제1 인증서는 제조사 디바이스 인증서(MDEV_Cert) 이고, 제2 인증서는 중간 생산자 디바이스 인증서(OEM DEV_Cert) 또는 중간 생산자 디바이스 인증서(OEM DEV_Cert)에 기초하여 발급된 에일리어스 인증서(Alias_Cert, 132_2e)로 정의될 수 있다.
도 9a 및 도 9b는 개시된 실시예에 따른 인증서들이 체인으로 결합된 것을 도시한 것이다.
도 9a 및 도 9b를 참조하면, 제1 레이어(120)가 업데이트 되는 경우, 디바이스(10)의 부팅 동작에 오류가 발생할 수 있다. 따라서, 정상적인 디바이스(10)의 부팅 동작을 수행하기 위해서 중간 생산자의 인증서 정보를 업데이트 해야한다.
도 9a는 제조사가 발급한 인증서에 중간 생산자의 디바이스 인증서가 업데이트 되는 것을 도시한 것이다. 제조사는 디바이스(10)가 최초로 제조되는 점에 제조사 루트 인증서(MR_Cert) 및 제조사 중간 인증서(MI_Cert)를 인증서 스토리지(132)에 저장할 수 있다. 여기서, 제조사 루트 인증서(MR_Cert)는 제조사 중간 인증서(MI_Cert)의 서명을 검증하고, 루트 체인(RT_CHN)을 생성할 수 있다. 또한, 중간 생산자(OEM)가 제1 레이어(120)를 업데이트 하는 경우, 제조사 중간 인증서(MI_Cert)는 중간 생산자 디바이스 인증서(OEM)의 서명을 검증하고, 디바이스 체인(DEV_CHN)을 통하여 중간 생산자 디바이스 인증서(OEM DEV_Cert)와 연결될 수 있다. 제조사 루트 인증서(MR_Cert), 제조사 중간 인증서(MI_Cert) 및 중간 생산자 디바이스 인증서(OEM DEV_Cert)가 체인을 형성하여 결합에 성공하면, 인증서 스토리지(132)는 인증 절차가 성공된 것으로 판단하고, 중간 생산자가 변경한 제1 레이어(120)를 신뢰할 수 있다.
도 9b는 제조사가 발급한 인증서에 중간 생산자의 디바이스 인증서가 에일리어스 인증서(Alias_Cert)에 의하여 업데이트 되는 것을 도시한 것이다. 도 9a에서 설명한 바와 같이, 제조사는 디바이스(10)가 최초로 제조되는 점에 제조사 루트 인증서(MR_Cert) 및 제조사 중간 인증서(MI_Cert)를 인증서 스토리지(132)에 저장할 수 있다. 여기서, 제조사 루트 인증서(MR_Cert)는 제조사 중간 인증서(MI_Cert)의 서명을 검증하고, 루트 체인(RT_CHN)을 생성할 수 있다. 또한, 중간 생산자(OEM)가 제1 레이어(120)를 업데이트 하는 경우, 제조사 중간 인증서(MI_Cert)는 중간 생산자 디바이스 인증서(OEM)의 서명을 검증하고, 디바이스 체인(DEV_CHN)을 통하여 중간 생산자 디바이스 인증서(OEM DEV_Cert)에 기초하여 생성된 에일리어스 인증서(Alias_Cert)와 연결될 수 있다. 제조사 루트 인증서(MR_Cert), 제조사 중간 인증서(MI_Cert) 및 에일리어스 인증서(Alias_Cert)가 체인을 형성하여 결합에 성공하면, 인증서 스토리지(132)는 인증 절차가 성공된 것으로 판단하고, 중간 생산자가 변경한 제1 레이어(120)를 신뢰할 수 있다.
도 10은 개시된 실시예에 따른 인증서 업데이트 방법의 순서도이다.
도 10을 참조하면, 프로세서(100)의 제1 레이어(120)가 변경되면, 디바이스(10)는 정상적인 동작을 할 수 없게 된다. 이에, 요청자(131)는 응답자(220)에게 인증서 요청 신호(GET_CERT)를 전송한다(S110).
인증서 요청 신호(GET_CERT)를 수신하면 응답자(220)는 인증서 체인의 해시(CERT CHAIN_Hash) 데이터와 인증서 체인(CERT_CHAIN) 데이터를 요청자(131)에게 제공한다(S120).
인증서 체인의 해시(CERT CHAIN_Hash) 데이터와 인증서 체인(CERT_CHAIN) 데이터를 수신하면, 요청자(131)는 제1 레이어(120)가 변경된 것을 감지하고 인증서 체인을 업데이트 하기 위해 응답자(220)에게 챌린지(CHALLENGE)를 요청한다(S130). 여기서 챌린지는 인증서 체인을 업데이트 하기 위한 인증서 체인 검증 동작의 일부를 의미할 수 있다.
챌린지 신호를 수신하면, 응답자(220)는 챌린지 승인(CHANLLENGE_AUTH)를 한다(S140). 챌린지 승인(CHANLLENGE_AUTH)은 제1 레이어(120)의 변경 정보를 제공하는 것을 포함할 수 있다. 챌린지 승인(CHANLLENGE_AUTH) 메시지는 디바이스 개인키(DEV_SK)에 기초하여 생성될 수 있다.
챌린지 인증(CHANLLENGE_AUTH)이 완료되면, 요청자(131)는 서명 요청 제공 신호(GET_CSR)를 응답자(220)에게 전송하고(S150), 응답자(220)는 디바이스(10)의 서명 요청(CSR: Certificate Signing Request)을 요청자(131)에게 제공한다(S160). 여기서 서명 요청(CSR)은 제1 레이어(120)가 변경되면 새롭게 생성될 수 있다. 또한, 서명 요청(CSR)에는 디바이스(10)의 공개 키와 고유 식별 번호(Serial Number)가 포함될 수 있으며, 디바이스(10)의 개인키에 의하여 서명되어질 수 있다. 또한, 서명 요청(CSR)은 제조사에 의하여 발급되어 저장된 정보일 수 있다.
서명 요청(CSR)이 수신되면, 요청자(131)는 중간 생산자 인증기관(300, OEM CA)로 수신된 서명 요청(CSR)을 전송한다(S170). 또한, 서명 요청(CSR)이 수신되면, 중간 생산자 인증 기관(300, OEM CA)는 인증서 체인(CERT_CHAIN)을 요청자(131)에게 전송한다(S180). 여기서 인증서 체인(CERT_CHAIN)은 중간 생산자가 생성한 인증서의 체인일 수 있으며, 제조사가 생성한 디바이스 인증서와는 다를 수 있다. 즉, 요청자(131)는 서명 요청(CSR)을 중간 생산자 인증 기관(300, OEM CA)에 전송하고, 새로운 인증서 체인을 수신함으로써 인증서를 업데이트 할 수 있다.
중간 생산자 인증 기관(300, OEM CA)으로부터 인증서 체인(CERT_CHAIN)을 수신하면, 요청자(131)는 응답자(220)로 새로운 인증서 셋팅 신호(SET_CERT)를 전송한다(S190a). 새로운 인증서 셋팅 신호(SET_CERT)가 수신되면, 응답자(220)는 제2 레이어(130)의 제2 슬롯(132_2)에 새로운 인증서 체인을 저장하고(SLOT#1 CERT CHAIN UPDATE), 새로운 인증서를 업데이트 할 수 있다(S190b). 다만, 여기서 새로운 인증서가 업데이트 되는 슬롯은 제2 슬롯(132_2)에 한정되지 아니하고, 제3 슬롯(132_3) 또는 제n 슬롯(132_n)을 포함할 수 있다.
도 11은 개시된 실시예에 따른 인증서 업데이트 방법에서 서명 요청을 생성하는 과정을 도시한 순서도이다.
도 11을 참조하면, 제1 레이어(120)에서 서명 요청(CSR)이 생성될 수 있다(S210). 여기서, 서명 요청(CSR)은 중간 생산자의 디바이스 아이디에 대한 서명을 요청하는 것을 포함할 수 있다. 또한, 상술한 바와 같이 서명 요청(CSR)은 제1 레이어(120)에 의하여 결정되는 디바이스 식별자(CDI)에 의하여 생성된 디바이스 고유 보증 아이디(UEI)에 기초하여 생성되는 것이므로, 제1 레이어(120)가 변경되면 서명 요청(CSR)은 새롭게 생성될 수 있다. 또한, 서명 요청(CSR)에는 디바이스(10)의 공개 키와 고유 식별 번호(Serial Number)가 포함될 수 있다. 여기서, 디바이스 아이디는 제1 레이어(120)의 해시(Hash) 값 또는 특성(Measurement)값일 수 있다.
제1 레이어(120)에서 서명 요청(CSR)이 생성되면, 제2 레이어(130)에서는 서명 요청(CSR)을 수신하고, 제1 레이어(120)를 인증한다(S220). 이하 설명하는 바와 같이 제1 레이어(120)의 업데이트를 인증하는 단계는 제1 레이어(120)의 변경 여부를 판단하고, 제1 레이어(120)가 변경된 것으로 판단되면, 변경된 인증 정보를 수신하고 변경된 인증서 체인을 포함하는 제2 인증서의 정보를 제2 슬롯(132_2)에 저장 하는 것을 포함할 수 있다. 예를 들면, 제2 레이어(130)는 제1 레이어(120)부터 서명 요청(CSR)을 수신하고, 서명 요청(CSR)에 대응하여 중간 생산자 디바이스 인증서(OEM DEV_Cert) 체인을 생성하는 것을 포함할 수 있다. 또한, 제2 슬롯(132_2)은 업데이트된 디바이스 아이디 인증서 체인 정보를 저장할 수 있다.
디바이스(10)가 인증되면, 프로세서(100)는 제1 레이어(120)의 변경 여부를 판단한다(S230).
제1 레이어(120)가 변경된 것으로 판단되면, 디바이스 식별 엔진(110)은 변경된 디바이스 고유 보증 아이디(UEI)를 생성하고, 제1 레이어(120)는 고유 보증 아이디(UEI)에 기초하여 고유 보증 키를 생성한다(S240). 여기서 고유 보증 키는 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)를 포함할 수 있으며, 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)는 비대칭 쌍을 이루며 생성될 수 있다.
고유 보증 키를 생성되면, 제1 레이어(120)의 서명 요청 생성부(126)은 변경된 제1 레이어(120) 정보를 포함하는 서명 요청(CSR)을 생성한다(S250).
그러나, 제1 레이어(120)가 변경되지 않은 것으로 판단되면, 인증서 스토리지(132)는 별도의 절차를 거치지 않고 업데이트 과정을 종료할 수 있다.
도 12는 개시된 실시예에 따른 인증서 업데이트 방법에서 인증서 체인을 업데이트 하는 과정을 도시한 것이다.
도 12를 참조하면, 디바이스(10)가 부팅되는 경우 요청자(131)는 제1 레이어(120)의 인증 절차를 수행한다.
여기서, 요청자(131)는 인증서 스토리지(132)에 저장된 루트 인증서에 기초하여 중간 인증서를 검증한다(S310). 루트 인증서는 중간 인증서를 상대로 서명 요청을 할 수 있고, 중간 인증서의 서명이 검증되면, 루트 인증서는 중간 인증서를 신뢰할 수 있다. 또한, 중간 인증서의 검증을 성공하면, 루트 인증서와 중간 인증서는 체인을 형성하여 결합할 수 있다.
여기서 루트 인증서 및 중간 인증서는 제조사가 발급한 인증서일 수 있으나 이에 한정되는 것은 아니다. 예를 들면, 제1 중간 생산자에 의하여 생산된 디바이스를 제2 중간 생산자가 업데이트 하는 경우, 인증 기관(131)에 저장된 인증서들은 제1 중간 생산자에 의하여 발급된 인증서일 수 있다.
중간 인증서의 검증이 완료되면, 중간 인증서가 디바이스 인증서를 검증할 수 있다(S320). 중간 인증서는 디바이스 인증서를 상대로 서명 요청을 할 수 있고, 디바이스 인증서의 서명이 검증되면, 중간 인증서는 디바이스 인증서를 신뢰할 수 있다. 또한, 디바이스 인증서의 검증을 성공하면, 중간 인증서와 디바이스 인증서는 체인을 형성하여 결합할 수 있다.
여기서 요청자(131)는 디바이스 인증서 검증 결과 제1 레이어(120)가 변경되었는지 여부를 판단할 수 있다(S330).
제1 레이어(120)가 변경된 것으로 판단되면, 요청자(131)는 서명 요청 생성 커맨드를 제1 레이어(120)로 전달하고, 제1 레이어(120)의 서명 요청 생성부(126)은 서명 요청(CSR)을 생성한다(S340). 여기서 서명 요청(CSR)은 디바이스 보증 개인키(EN_SK) 및 보증 공개키(EN_PK)에 기초하여 생성될 수 있으며, 디바이스(10)의 고유 보증 아이디(UEI) 정보를 포함할 수 있다.
서명 요청(CSR)이 생성되면, 제2 레이어(130)은 서명 요청(CSR)을 수신하고 인증서 체인을 업데이트 한다(S350). 여기서, 인증서 체인은 중간 제조사 디바이스 인증서의 서명에 기초하여 생성된 것일 수 있다. 제조사 루트 인증서(MR_Cert), 제조사 중간 인증서(MI_Cert) 및 중간 생산자 디바이스 인증서(OEM DEV_Cert)가 체인을 형성하여 결합에 성공하면, 요청자(131)는 인증 절차가 성공된 것으로 판단하고, 중간 생산자가 변경한 제1 레이어(120)를 신뢰할 수 있다.
그러나, 제1 레이어(120)가 변경되지 않은 것으로 판단되면, 요청자(131)는 별도의 절차를 거치지 않고 업데이트 과정을 종료할 수 있다.
도 13은 개시된 실시예에 따른 인증서 업데이트 방법에서 인증서를 검증하고 업데이트 하는 과정을 도시한 것이다.
도 13은 인증서 체인의 업데이트 과정을 중간 제조사(20)가 생성한 인증서와 공개기 생성부(30)가 생성한 공개키(PK)에 의하여 인증서를 검증하는 관점에서 설명된 것이다.
도 13을 참조하면, 제1 레이어(120, Layer0)가 업데이트 되면, 제조사가 제작한 디바이스 식별 엔진(110)에서는 제1 함수에 의하여 디바이스 식별자(CDI)를 생성한다(S410). 여기서 제1 함수는 HMAC함수 일 수 있으며, 디바이스 식별자(CDI)는 디바이스 비밀 정보(CDS) 및 제1 레이어(120)의 식별 정보(ID)에 기초하여 생성될 수 있다.
디바이스 식별자(CDI)가 생성되면, 디바이스 식별 엔진(110)에서는 제2 함수에 의하여 디바이스 고유 보증 식별자(UEI)를 생성한다(S420). 고유 보증 식별자(UEI)는 디바이스 비밀 정보(CDS)를 제2 함수에 입력한 결과 출력되는 값일 수 있다. 여기서, 제2 함수는 KDF 함수일 수 있으나 이에 한정되는 것은 아니다.
디바이스 식별자(CDI) 및 고유 보증 식별자(UEI)가 생성되면, 제1 레이어(120)는 서명 요청(CSR)을 생성할 수 있다(S430). 여기서 서명 요청(CSR)은 디바이스 고유 보증 아이디 인증서(EN_Cert)정보를 포함할 수 있다.
서명 요청(CSR)이 생성되면, 요청자(131)에서는 루트 인증서의 제1 공개키를 생성한다(S440). 여기서 루트 인증서는 요청자 (131)에 저장되어 제1 레이어(120)의 변경여부를 인증하는 인증서를 의미하고, 루트 인증서의 공개키는 제조사에서 발급한 제1 인증서의 변경여부를 검증하는데 활용될 수 있다.
루트 인증서의 공개키가 생성되면, 요청자(131)는 중간 인증서 서명을 검증한다(S450). 중간 인증서와 루트 인증서는 체인을 통하여 결합되어 있을 수 있다.
요청자(131)가 중간 인증서의 서명을 검증하면, 제2 레이어는 인증서 체인을 업데이트 할 수 있다(S460). 즉, 중간 인증서와 루트 인증서의 체인은 유지된 채 변경된 디바이스 고유 보증 인증서(EN_Cert) 또는 에일리어스 인증서(Alias_Cert)의 체인을 저장 함으로써, 요청자(131)는 변경된 인증서를 업데이트할 수 있다.
도 14는 본 발명의 일 실시예에 따른 프로세서(100)의 일 구현 예를 나타내는 블록도이다.
도 14를 참조하면, 어플리케이션 프로세서(700)는 시스템 온 칩(SoC)으로 구현될 수 있으며, 어플리케이션 프로세서(700)는 전술한 실시예들에서의 디바이스에 장착되어 디바이스의 전반적인 동작을 제어할 수 있다. 어플리케이션 프로세서(700)는 CPU(Central processing unit, 710), 보안 프로세서(720), 요청자(730), 디스플레이 콘트롤러(740), ROM(read only memory, 750), 메모리 콘트롤러(760) 및 RAM(random access memory, 770)을 포함할 수 있다. 어플리케이션 프로세서(700)는 도시된 구성요소들 외에도 다른 구성요소, 예컨대, 전원 관리 유닛(power management unit), GPU(Central processing unit) 및 클락 유닛(clock unit) 등을 더 포함할 수 있다.
CPU(710)는 ROM(750) 및/또는 RAM(770)에 저장된 프로그램들이나 데이터를 처리 또는 실행할 수 있다. 예컨대, CPU(710)는 동작 클락에 따라 상기 프로그램들 및 데이터를 처리 또는 실행할 수 있다. CPU(710)는 멀티-코어 프로세서(multi-core processor)로 구현될 수 있다. 상기 멀티-코어 프로세서는 두 개 또는 그 이상의 독립적인 프로세서들(예컨대, 코어들(cores))을 갖는 하나의 컴퓨팅 컴포넌트(computing component)이고, 상기 프로세서들 각각은 프로그램 명령들(program instructions)을 읽고 실행할 수 있다.
ROM(750)은 프로그램들 및/또는 데이터를 불휘발성하게 저장할 수 있다. ROM(750)은 EPROM(erasable programmable read-only memory) 또는 EEPROM(electrically erasable programmable read-only memory)으로 구현될 수 있다. 또한, RAM(770)은 프로그램들, 데이터 및 명령들(instructions)을 일시적으로 저장할 수 있다. 예컨대, ROM(750)에 저장된 프로그램들 및/또는 데이터는 CPU(710)의 제어에 따라 RAM(770)에 일시적으로 저장될 수 있다. RAM(770)은 DRAM(dynamic RAM) 또는 SRAM(static RAM) 등의 메모리로 구현될 수 있다.
메모리 콘트롤러(760)는 외부 메모리 장치와 인터페이스하는 기능을 수행하며, 데이터 억세스 요청에 따라 외부 메모리 장치를 제어하여 데이터를 기록하거나 독출한다. 또한, 디스플레이 콘트롤러(740)는 디스플레이 장치를 구동함으로써 화면의 표시 동작을 제어할 수 있다.
본 발명의 실시예에 따라, 어플리케이션 프로세서(700)는 외부의 별도의 반도체 칩으로 구현될 수 있는 보안 스토리지(또는, 보안 IC)와 통신할 수 있다. 어플리케이션 프로세서(700)의 초기 구동시, 전술한 실시예에 따라 어플리케이션 프로세서(700)와 보안 스토리지에 대해 상호 인증 과정이 수행될 수 있다. 일 실시예로서, 상호 인증이 성공됨에 따라, 어플리케이션 프로세서(700)와 보안 스토리지는 대칭키 등을 이용한 암호화 통신을 수행할 수 있다.
또한 전술한 실시예들에 따라, 어플리케이션 프로세서(700)에 구비되는 보안 프로세서(720) 및 요청자 (730)는 공개키 기반의 통신을 위한 다양한 동작을 수행한다. 예컨대, 공개키 기반의 통신에 관련된 다수의 기능들 중 적어도 일부는 보안 스토리지에서 수행되도록, 어플리케이션 프로세서(700)는 보안 스토리지에 요청을 제공할 수 있다. 전술한 실시예들에 따라, 인증서에 대한 전자 서명이나, 디바이스 개인키 등과 같은 외부로 관련 정보가 노출되지 않을 필요가 있는 중요한 연산은 보안 스토리지에서 수행될 수 있다.
이상의 설명은 본 명세서의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 개시된 실시예들이 속하는 기술 분야에서 통상의 지식을 가진 자라면, 발명의 본질적인 특성에서 벗어나지 않는 범위에서, 개시된 실시예들에 대한 다양한 수정 및 변형이 가능할 것이다. 따라서, 개시된 실시예들은 본 명세서에 기술된 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 개시된 실시예들에 의하여 발명의 기술 사상의 범위가 한정되는 것은 아니다. 개시된 실시예들에 따른 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 개시된 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
이상의 설명은 본 명세서의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 개시된 실시예들이 속하는 기술 분야에서 통상의 지식을 가진 자라면, 발명의 본질적인 특성에서 벗어나지 않는 범위에서, 개시된 실시예들에 대한 다양한 수정 및 변형이 가능할 것이다. 따라서, 개시된 실시예들은 본 명세서에 기술된 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 개시된 실시예들에 의하여 발명의 기술 사상의 범위가 한정되는 것은 아니다. 개시된 실시예들에 따른 발명의 보호 범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 개시된 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.
10: 디바이스
100: 프로세서
110: 디바이스 식별 엔진
111: 디바이스 정보 저장부
112: 제1 함수 생성부
113: 제2 함수 생성부
120: 제1 레이어
121: 에일리어스키 저장부
122: 디바이스 아이디 저장부
123: 고유 보증 아이디 저장부
124: 에일리어스키 인증서 생성부
125: 디바이스 아이디 인증서 생성부
126: 서명 요청 생성부
130: 제2 레이어
131: 요청자
132: 인증서 스토리지
200: 보안 스토리지
210: 인증기관
220: 응답자

Claims (20)

  1. 디바이스 식별자 및 고유 보증 아이디를 생성하는 디바이스 식별 엔진;
    상기 디바이스 식별자를 수신하고, 상기 디바이스를 인증하는 제1 인증서 및 제2 인증서를 생성하는 제1 레이어;및
    상기 제1 인증서 및 상기 제2 인증서를 수신하고 상기 디바이스의 업데이트 여부를 검증하는 제2 레이어를 포함하되,
    상기 제1 레이어가 업데이트된 경우,
    상기 제1 레이어는 상기 고유 보증 아이디에 기초하여 보증 키(Endorsement Key)를 생성하고, 상기 보증 키에 기반하여 보증 아이디의 서명 요청을 생성하는 디바이스.
  2. 제1 항에 있어서,
    디바이스 식별 엔진은,
    고유 디바이스 비밀 데이터를 미리 저장된 제1 함수에 입력하여 디바이스 식별자를 생성하는 디바이스.
  3. 제2 항에 있어서,
    디바이스 식별 엔진은,
    고유 디바이스 비밀 데이터를 미리 저장된 제2 함수에 입력하여 고유 보증 아이디를 생성하는 디바이스.
  4. 제1 항에 있어서,
    상기 제1 레이어는
    보증 키 생성부를 포함하고,
    상기 보증 키 생성부는 보증 개인키 및 보증 공개키를 생성하는 디바이스.
  5. 제4 항에 있어서,
    상기 제1 레이어는
    보증 서명 생성부를 더 포함하고,
    상기 보증 서명 생성부는 상기 보증 개인키 및 상기 보증 공개키에 기초하여 보증 서명 요청을 생성하는 디바이스.
  6. 제1 항에 있어서,
    상기 제2 레이어는,
    상기 제2 인증서 및 서명 요청에 기초하여 상기 제1 레이어의 업데이트를 검증하는 요청자를 포함하는 디바이스.
  7. 제6 항에 있어서,
    상기 요청자는,
    제1 레이어가 업데이트된 것으로 판단되면,
    상기 서명 요청에 기초하여 상기 디바이스의 인증서 체인을 업데이트 하는 디바이스.
  8. 디바이스 식별 엔진이 디바이스 식별자 및 고유 보증 아이디를 생성하는 단계;
    제1 레이어가 상기 디바이스 식별자를 수신하고, 상기 디바이스를 인증하는 제1 인증서 및 제2 인증서를 생성하는 단계;및
    제2 레이어가 상기 제1 인증서 및 상기 제2 인증서를 수신하고 상기 디바이스의 업데이트 여부를 검증하는 단계를 포함하되,
    상기 제1 레이어가 업데이트된 경우,
    상기 제1 인증서 및 제2 인증서를 생성하는 단계는,
    상기 고유 보증 아이디에 기초하여 보증 키(Endorsement Key)를 생성하고, 상기 보증 키에 기반하여 보증 아이디의 서명 요청을 생성하는 단계를 포함하는 디바이스 인증서의 업데이트 방법.
  9. 제8 항에 있어서,
    디바이스 식별자 및 고유 보증 아이디를 생성하는 단계는,
    고유 디바이스 비밀 데이터를 미리 저장된 제1 함수에 입력하여 디바이스 식별자를 생성하는 것을 포함하는 디바이스 인증서의 업데이트 방법.
  10. 제9 항에 있어서,
    디바이스 식별자 및 고유 보증 아이디를 생성하는 단계는,
    고유 디바이스 비밀 데이터를 미리 저장된 제2 함수에 입력하여 고유 보증 아이디를 생성하는 것을 포함하는 디바이스 인증서의 업데이트 방법.
  11. 제8 항에 있어서,
    상기 제1 인증서 및 제2 인증서를 생성하는 단계는,
    보증 개인키 및 보증 공개키를 포함하는 보증 키를 생성하는 단계를 더 포함하는 디바이스 인증서의 업데이트 방법.
  12. 제11 항에 있어서,
    상기 제1 인증서 및 제2 인증서를 생성하는 단계는,
    상기 보증 개인키 및 상기 보증 공개키에 기초하여 보증 서명 요청을 생성하는 단계를 더 포함하는 디바이스 인증서의 업데이트 방법.
  13. 제8 항에 있어서,
    상기 디바이스의 업데이트 여부를 검증하는 단계는,
    상기 제1 인증서, 제2 인증서 및 서명 요청에 기초하여 상기 제1 레이어의 업데이트를 검증하는 보안 프로토콜을 수행하는 단계를 포함하는 디바이스 인증서의 업데이트 방법.
  14. 제13 항에 있어서,
    상기 디바이스의 업데이트 여부를 검증하는 단계는,
    제1 레이어가 업데이트된 것으로 판단되면,
    상기 서명 요청에 기초하여 상기 디바이스의 인증서 체인을 업데이트 하는 것을 포함하는 디바이스 인증서의 업데이트 방법.
  15. 디바이스의 부트로더(Bootloader)가 업데이트 된 경우 변경된 상기 디바이스의 인증서를 업데이트 하는 방법에 있어서,
    루트 인증서의 제1 체인에 기초하여 중간 인증서를 검증하는 단계;
    상기 중간 인증서의 제2 체인에 기초하여 상기 부트로더의 변경 여부를 검증하는 단계;및
    상기 부트로더가 변경된 것으로 판단되면,
    디바이스 서명 요청에 기초하여 상기 중간 인증서에 상기 디바이스 인증서 체인을 업데이트 하는 단계를 포함하는 디바이스 인증서의 업데이트 방법.
  16. 제15 항에 있어서,
    상기 디바이스 인증서 체인을 업데이트 하는 단계는,
    고유 디바이스 비밀 데이터를 미리 저장된 제1 함수 및 제2 함수에 입력하여 디바이스 식별자를 생성하고, 고유 보증 아이디를 생성하는 것을 포함하는 디바이스 인증서의 업데이트 방법.
  17. 제15 항에 있어서,
    상기 디바이스 인증서 체인을 업데이트 하는 단계는,
    보증 개인키 및 보증 공개키를 생성하고, 상기 보증 개인키 및 상기 보증 공개키에 기초하여 보증 키를 생성하는 것을 포함하는 디바이스 인증서의 업데이트 방법.
  18. 제17 항에 있어서,
    상기 디바이스 인증서 체인을 업데이트 하는 단계는,
    상기 보증 개인키 및 상기 보증 공개키에 기초하여 보증 서명 요청을 생성하는 디바이스 인증서의 업데이트 방법.
  19. 제15 항에 있어서,
    상기 디바이스 인증서 체인을 업데이트 하는 단계는,
    상기 제1 인증서, 제2 인증서 및 서명 요청에 기초하여 상기 제1 레이어의 업데이트를 검증하는 디바이스 인증서의 업데이트 방법.
  20. 제19 항에 있어서,
    제1 레이어가 업데이트된 것으로 판단되면,
    상기 서명 요청에 기초하여 상기 디바이스의 인증서 체인을 업데이트 하는 디바이스 인증서의 업데이트 방법.
KR1020220110324A 2022-08-31 2022-08-31 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스 KR20240030815A (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020220110324A KR20240030815A (ko) 2022-08-31 2022-08-31 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스
US18/458,070 US20240073033A1 (en) 2022-08-31 2023-08-29 Method of updating device certificate and device for driving the method
CN202311099330.6A CN117640096A (zh) 2022-08-31 2023-08-29 更新设备证书的方法和用于驱动该方法的设备
EP23194683.1A EP4333361A1 (en) 2022-08-31 2023-08-31 Method of updating device certificate and device for driving the method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020220110324A KR20240030815A (ko) 2022-08-31 2022-08-31 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스

Publications (1)

Publication Number Publication Date
KR20240030815A true KR20240030815A (ko) 2024-03-07

Family

ID=87889166

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020220110324A KR20240030815A (ko) 2022-08-31 2022-08-31 디바이스 인증서의 업데이트 방법 및 이를 구동하는 디바이스

Country Status (4)

Country Link
US (1) US20240073033A1 (ko)
EP (1) EP4333361A1 (ko)
KR (1) KR20240030815A (ko)
CN (1) CN117640096A (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11533183B2 (en) * 2020-01-10 2022-12-20 Lennox Industries Inc. Secure provisioning of digital certificate

Also Published As

Publication number Publication date
US20240073033A1 (en) 2024-02-29
CN117640096A (zh) 2024-03-01
EP4333361A1 (en) 2024-03-06

Similar Documents

Publication Publication Date Title
EP3458999B1 (en) Self-contained cryptographic boot policy validation
US10437985B2 (en) Using a second device to enroll a secure application enclave
JP5497171B2 (ja) セキュア仮想マシンを提供するためのシステムおよび方法
EP3637297A1 (en) Securing firmware
CN111264044B (zh) 芯片、生成私钥的方法和可信证明的方法
JP6103169B1 (ja) セキュリティ装置、及びセキュリティ方法
US9405912B2 (en) Hardware rooted attestation
US9673979B1 (en) Hierarchical, deterministic, one-time login tokens
US20050166051A1 (en) System and method for certification of a secure platform
US9225530B2 (en) Secure crypto-processor certification
WO2006002282A1 (en) Systems and methods for performing secure communications between an authorized computing platform and a hardware component
TW201502855A (zh) 使用安全加強晶片之用於資料之安全儲存之系統、方法及裝置
US10853472B2 (en) System, apparatus and method for independently recovering a credential
JP2022028632A (ja) デバイス、及び方法
KR20200075451A (ko) 디바이스 고유암호키 생성기 및 방법
US20240073033A1 (en) Method of updating device certificate and device for driving the method
JP2018117185A (ja) 情報処理装置、情報処理方法
US20230224169A1 (en) Verifying secure software images using digital certificates
KR20240047215A (ko) 인증서의 업데이트 방법 및 이를 구동하는 디바이스의 인증서업데이트 시스템
CN116710914A (zh) 边缘设备的密钥撤销
KR20230137422A (ko) 디지털 장치를 위한 신뢰할 수 있는 컴퓨팅
US20210194705A1 (en) Certificate generation method
US20210344515A1 (en) Authentication-permission system, information processing apparatus, equipment, authentication-permission method and program
CN113641986B (zh) 基于SoftHSM实现联盟链用户私钥托管方法与系统
CN116015976A (zh) 一种数据加密传输方法及装置