KR20210057149A - 스마트 계약 기반 데이터 처리 방법, 기기 및 저장 매체 - Google Patents
스마트 계약 기반 데이터 처리 방법, 기기 및 저장 매체 Download PDFInfo
- Publication number
- KR20210057149A KR20210057149A KR1020217010913A KR20217010913A KR20210057149A KR 20210057149 A KR20210057149 A KR 20210057149A KR 1020217010913 A KR1020217010913 A KR 1020217010913A KR 20217010913 A KR20217010913 A KR 20217010913A KR 20210057149 A KR20210057149 A KR 20210057149A
- Authority
- KR
- South Korea
- Prior art keywords
- version
- firmware
- update
- node
- announcement
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H04L67/32—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3236—Cryptographic 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 using cryptographic hash functions
- H04L9/3239—Cryptographic 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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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/3247—Cryptographic 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
-
- H04L2209/38—
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
본 개시의 실시예는 지능형 계약에 기초한 데이터 처리 방법, 기기 및 저장 매체를 개시한다. 상기 데이터 처리 방법은, 실행 노드에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하는 단계 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -; 상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 단계; 및 상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하는 단계를 포함한다. 상기 펌웨어 버전 발표 기록은 상기 블록체인상의 발표 노드에 의해 컨센서스 메커니즘에 기초하여 결정된다.
Description
관련 출원
본 출원은 2019년 8월 29일 중국 국가 지적 재산국에 출원된 "지능형 계약에 기초한 데이터 처리 방법, 기기 및 저장 매체(DATA PROCESSING METHOD BASED ON INTELLIGENT CONTRACT, DEVICE, AND STORAGE MEDIUM)"라는 명칭의 중국 특허출원 제201910808351.8호에 대해 우선권을 주장하며, 그 내용 전부는 인용에 의해 본 출원에 포함된다.
본 개시는 인터넷 기술 분야에 관한 것으로, 특히 지능형 계약에 기초한 데이터 처리 방법, 기기 및 저장 매체에 관한 것이다.
서버 펌웨어는 서버의 EPROM(Erasable Programmable Read-Only Memory) 또는 EEPROM(Electrical Erasable Programmable Read-Only Memory)에 기입된 프로그램이다. 대응하는 운영 체제에서 하드웨어 기기의 기본 파라미터 및 프로그램은 서버 펌웨어에 저장될 수 있는데, 이는 운영 체제에 대해 최하위 레벨에서 가장 직접적인 하드웨어 제어를 제공할 수 있는 것으로 이해될 수 있다.
현재 서버의 운영 및 유지보수 담당자는 오프라인 분석, 인밴드(inband) 네트워크, 또는 시스템 관리 인트럽트와 같은 펌웨어 업데이트 방법을 통해 서버의 펌웨어(예: BIOS(Basic Input/Output System)의 펌웨어)에 대한 업데이트 작업을 수행하여, 운영 체제에 새로운 기능을 추가하거나 운영 체제의 이상을 복구할 수 있다.
본 개시의 실시예는 펌웨어 업데이트의 보안성 및 신뢰성을 향상시키기 위해 지능형 계약, 기기 및 저장 매체에 기초한 데이터 처리 방법을 제공한다.
본 개시의 일 실시예는 계약 노드인 전자 기기에 의해 수행되는 지능형 계약에 기초한 데이터 처리 방법을 제공하며, 상기 데이터 처리 방법은,
본 개시의 일 실시예는 계약 노드(contract node)인 전자 기기에 의해 수행되는 지능형 계약에 기초한 데이터 처리 방법을 제공하며, 상기 데이터 처리 방법은,
실행 노드(execution node)에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하는 단계 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 단계 - 상기 펌웨어 버전 발표 기록은 컨센서스 메커니즘(consensus mechanism)에 기초하여 상기 블록체인상의 발표 노드(release node)에 의해 결정됨 -; 및
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하는 단계를 포함한다.
본 개시의 일 실시예는 계약 노드에 적용되는, 지능형 계약에 기초한 데이터 처리 장치를 제공하며, 상기 데이터 처리 장치는,
실행 노드에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하도록 구성된 요청 수신 모듈 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하도록 구성된 계약 호출 모듈 - 상기 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 상기 블록체인상의 발표 노드에 의해 결정됨 -; 및
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하도록 구성된 유효성 결정 모듈을 포함한다.
본 개시의 실시예는 프로세서 및 메모리를 포함하는 노드 기기를 제공하며, 상기 프로세서는 상기 메모리에 연결되고, 상기 메모리는 프로그램 코드를 저장하도록 구성되며, 상기 프로세서는 상기 프로그램 코드를 호출하여, 다음 작업:
제1 서버 노드에 대한 실행 노드에 의해 송신되는 펌웨어 업데이트 요청을 수신하는 작업 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 작업 - 상기 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 상기 블록체인상의 발표 노드에 의해 결정됨 -; 및
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하는 작업을 수행하도록 구성된다.
본 개시의 실시예는 컴퓨터 프로그램을 저장하는 컴퓨터 저장 매체를 제공하며, 상기 컴퓨터 프로그램은 프로그램 명령어를 포함하고, 상기 프로그램 명령어는 프로세서에 의해 실행될 때, 본 개시의 실시예 중 어느 하나에 따른 방법이 수행되게 한다.
본 개시의 실시예의 기술적 방안을 보다 명확하게 설명하기 위해, 이하에서는 실시예를 설명하는 데 필요한 첨부 도면을 간략하게 소개한다. 명백히, 이하의 설명에서 첨부 도면은 본 개시의 일부 실시예를 도시할 뿐이며, 당업자라면 창의적인 노력 없이 이러한 첨부 도면으로부터 다른 도면을 더 도출할 수 있을 것이다.
도 1은 본 개시의 일 실시예에 따른 블록체인 네트워크 토폴로지 구조의 개략 구조도이다.
도 2는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 방법의 개략 흐름도이다.
도 3은 본 개시의 일 실시예에 따른 중첩된 해시 체인(nested hash chain)의 블록 구조의 개략도이다.
도 4a 및 도 4b는 본 개시의 일 실시예에 따른 버전 발표 제어를 수행하는 개략도이다.
도 5는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 다른 데이터 처리 방법의 개략 흐름도이다.
도 6은 본 개시의 일 실시예에 따른 버전 발표 행위 정보를 획득하는 개략도이다.
도 7은 본 개시의 일 실시예에 따른 펌웨어 버전 업데이트 기록을 구축하는 개략도이다.
도 8은 본 개시의 일 실시예에 따른 발표 노드를 사용하여 보안 감사를 수행하는 개략도이다.
도 9는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 장치의 개략 구성도이다.
도 10은 본 개시의 일 실시예에 따른 노드 기기의 개략 구성도이다.
도 1은 본 개시의 일 실시예에 따른 블록체인 네트워크 토폴로지 구조의 개략 구조도이다.
도 2는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 방법의 개략 흐름도이다.
도 3은 본 개시의 일 실시예에 따른 중첩된 해시 체인(nested hash chain)의 블록 구조의 개략도이다.
도 4a 및 도 4b는 본 개시의 일 실시예에 따른 버전 발표 제어를 수행하는 개략도이다.
도 5는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 다른 데이터 처리 방법의 개략 흐름도이다.
도 6은 본 개시의 일 실시예에 따른 버전 발표 행위 정보를 획득하는 개략도이다.
도 7은 본 개시의 일 실시예에 따른 펌웨어 버전 업데이트 기록을 구축하는 개략도이다.
도 8은 본 개시의 일 실시예에 따른 발표 노드를 사용하여 보안 감사를 수행하는 개략도이다.
도 9는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 장치의 개략 구성도이다.
도 10은 본 개시의 일 실시예에 따른 노드 기기의 개략 구성도이다.
이하에서는 본 개시의 실시예에서의 첨부 도면을 참조하여 본 발명의 실시예에서의 기술적 방안을 명확하고 완전하게 설명한다. 명백히, 설명된 실시예는 모든 실시예가 아니라 본 개시의 실시예의 일부이다. 본 출원의 실시예에 기초하여, 임의의 창의적인 노력 없이 당업자에 의해 획득된 다른 모든 실시예는 모두 본 출원의 보호 범위 내에 속한다.
현재, 서버 벤더의 공식 웹사이트에 의해 제공되는 펌웨어는 오픈 다운로드 상태이기 때문에, 어떤 펌웨어 업데이트 방식을 사용하든, 운영 및 유지보수 담당자는 서버 벤더의 공식 웹사이트로부터 대응하는 모델의 펌웨어를 다운로드하여, 사용된 펌웨어 업데이트 방법의 단계에 따라 펌웨어 업그레이드 작업을 수행할 수 있다. 따라서, 펌웨어 업데이트를 위한 펌웨어의 데이터가 불법적으로 침투 및 변조되면, 운영 체제의 최하위 레벨의 보안 보호가 심각하게 위협받는다. 다시 말해, 기존 펌웨어 업데이트 방식으로는 펌웨어 업데이트의 보안성과 신뢰성을 보장할 수 없다.
도 1은 본 개시의 일 실시예에 따른 블록체인 네트워크 토폴로지 구조의 개략 구조도이다. 도 1에 도시된 블록체인 네트워크 토폴로지 구조는 기업 인트라넷에서 대규모 서버가 있는 애플리케이션 시나리오에 적용될 수 있다. 도 1에 도시된 바와 같이. 블록체인 네트워크 토폴로지 구조는 도 1에 도시된 발표 계층(100), 계약 계층(200) 및 구현 계층(300)을 포함될 수 있다.
도 1에 도시된 바와 같이, 발표 계층(100)에 위치한 노드는 발표 노드라고 할 수 있으며, 구체적으로는 도 1에 도시된 발표 노드(10a), 발표 노드(10b) 및 발표 노드(10c)를 포함될 수 있다. 발표 계층(100)은 다른 발표 노드(도 1에 도시되지 않음)를 더 포함할 수 있음을 이해해야 한다. 도 1에 도시된 바와 같이, 계약 계층(200)에 위치한 노드는 통칭하여 계약 노드라고 할 수 있으며, 계약 노드는 블록체인에 저장된 지능형 계약을 호출하고 실행할 수 있는 노드로 이해될 수 있다.
구체적으로, 계약 계층(200)은 도 1에 도시된 계약 노드(20a) 및 계약 노드(20b)를 포함될 수 있다. 도 1에 도시된 바와 같이, 구현 계층(300)에 위치한 노드는 주로 두 가지 유형의 노드를 포함하는데, 두 가지 유형의 노드 중 한 유형의 노드를 실행 노드라고 할 수 있고, 다른 유형의 노드는 서버 노드라고 할 수 있다. 실행 노드는 구체적으로, 도 1에 도시된 실행 노드(30a) 및 실행 노드(30b)를 포함할 수 있다. 유사하게, 서버 노드는 구체적으로, 도 1에 도시된 서버 노드(40a), 서버 노드(40b) 및 서버 노드(40c)를 포함할 수 있다.
도 1에 도시된 바와 같이, 블록체인 네트워크 토폴로지 구조에 위치하는 발표 노드, 계약 노드, 실행 노드, 및 서버 노드를 통칭하여 블록체인 네트워크의 노드라고 할 수 있음을 이해해야 한다. 블록체인 네트워크에서, 노드는 서로 완전히 연결될 수 있다. 예를 들어, 도 1에 도시된 바와 같이, 발표 노드(10a)와 계약 노드(20a) 사이의 제1 네트워크 연결 방식은 완전한 연결 방식으로 지칭될 수 있다. 즉, 본 개시의 일 실시예에서, 하나의 홉(hop)으로 연결할 수 있는 네트워크 연결 방식은 완전한 연결 방식으로 지칭될 수 있다. 본 개시의 일 실시예에서, 블록체인의 노드는 또한 물리 네트워크를 통해 연결될 수 있다. 예를 들어, 도 1에 도시된 바와 같이, 계약 노드(20a)와 계약 노드(20b) 사이의 제2 네트워크 연결 방식은 물리 네트워크(예: 가상 네트워크 어댑터)를 통해 연결되어야 할 수 있다. 즉, 하나의 홉으로 연결할 수 없는 네트워크 연결 방식은 물리 네트워크를 통한 물리 네트워크 연결 방식이라고 할 수 있다.
도 1에 도시된 발표 노드(10a)는 벤더(예: 벤더 A)에서 발표한 최신 버전의 펌웨어 파일(예: 펌웨어 파일 x)을 수신할 수 있다. 또한, 발표 노드(10a)는 획득 한 펌웨어 파일 x에 대해 파일 구조 파싱을 수행하여, 펌웨어 파일 x의 파일 내용에 따라 펌웨어 파일 x의 내부 버전 번호(예: 최신 펌웨어 버전 번호 AAAA)를 추가로 결정하고, 버전 번호에 대응하는 해시 값(예: 해시 값 1)을 계산할 수 있다. 또한, 도 1에 도시된 바와 같이, 블록체인 네트워크의 발표 노드(10a)는 벤더 A의 펌웨어 버전 발표 파라미터(즉, 최신 펌웨어 버전 번호 AAAA 및 해시 값 1)를 계약 노드(20a)와의 완전한 연결을 사용하여 인접한 계약 노드(20a)에 발표할 수 있다. 게다가 계약 노드는 벤더 A의 버전 발표 파라미터를 계약 계층(200)의 다른 계약 노드(예: 계약 노드(20b))에 전파할 수 있다. 다시 말해, 본 개시의 일 실시예에서, 발표 노드는 계약 계층(200)의 모든 계약 노드에, 벤더 A가 발표한 펌웨어 버전 발표 파라미터(즉, 펌웨어 버전 번호 AAAA 및 해시 값 1)를 브로드캐스팅할 수 있다.
계약 노드(20a)에 펌웨어 버전 발표 파라미터를 발표하는 경우, 발표 노드(10a)는 발표 노드(10a)의 개인 키를 사용하여 펌웨어 버전 발표 파라미터에 서명하고, 서명된 정보 및 발표 노드(10a)의 공개 키를 버전 발표 확인 정보로서 사용하여, 버전 발표 확인 정보를 계약 노드(20a)에 함께 제공하므로, 계약 노드(20a)는 시간 임계 메커니즘을 사용하여(즉, 미리 설정된 시간 윈도 T 내에), 블록체인에 대한 컨센서스를 완료할 수 있음을 이해해야 한다. 본 개시의 일 실시예에서, 기업 내의 블록체인 네트워크(예: 사설 블록체인 네트워크)상에서, 블록체인의 컨센서스는 계약 계층(200)의 계약 노드에서 수행되도록 제한될 수 있다.
예를 들어, 발표 노드(10a)에 의해 전송되는 버전 발표 확인 정보를 수신한 후, 계약 노드(20a)는 미리 설정된 시간 윈도 T 내에 대기할 수 있다. 시간 윈도 T 내에 동일한 펌웨어 버전 발표 파라미터를 브로드캐스팅하는 다른 발표 노드가 있는 경우(예: 도 1에 도시된 발표 노드(10b)), 이는 발표 노드 간에 컨센서스에 도달했음을 간접적으로 지시한다. 이 경우, 계약 노드는 계약 컨센서스에 도달하였음을 보증하기 위해, 버전 발표 파라미터를 포함하는 펌웨어 버전 발표 기록을 블록체인에 기입(write)할 수 있다. 그렇지 않고, 벤더 A에 의해 발표되고 다른 발표 노드에 의해 브로드캐스팅되는 펌웨어 버전 발표 파라미터가 시간 윈도 T를 넘어 다른 시간에 수신되면, 이는 벤더 A에 의해 발표된 버전 발표 파라미터가 수락되지 않았음을 간접적으로 지시한다. 이 경우, 계약 노드는 버전 발표 파라미터를 포함하고 발표 노드(10a)에 의해 브로드캐스팅되어 시간 윈도 T 내에 수신되는 블록을 블록체인에 기입하지 않는다. 본 개시명의 일 실시예에서는, 발표 노드에 대한 불법적인 공격자 침입으로 인한 체계적 위험(systematic risk)을 노드 간의 컨센서스를 사용하여 효과적이고 근본적으로 회피할 수 있음을 알 수 있다.
계약 계층(200)의 계약 노드는 물리 네트워크를 통해 서로 통신할 수 있기 때문에, 계약 노드(20a)는 버전 발표 파라미터를 포함하는 블록을 수신한 후, 버전 발표 파라미터를 포함하는 블록을 계약 노드와 동기화하여, 더 나아가 계약 컨센서스에 도달할 수 있음을 이해해야 한다. 즉, 본 개시의 일 실시예에서, 벤더 A에 의해 발표된 버전 발표 파라미터(즉, 펌웨어 버전 번호 AAAA 및 해시 값 1)는 컨센서스 메커니즘을 사용하여 최신 버전의 벤더 펌웨어 정보로서 블록체인상에서 더욱 효과적으로 결정될 수 있다.
본 개시의 일 실시예에서 설명되는 블록체인은 특수한 분산 데이터베이스(special distributed database)이거나, 분산 원장 시스템(distributed ledger system)이라고 할 수 있다. 분산 데이터베이스(즉, 블록체인)는 다음의 같은 두 가지 기능을 가질 수 있다: 한 가지 기능은 정보를 저장하는 것이다, 즉, 블록체인상의 노드는 저장되어야 할 임의의 정보를, 전술한 시간 임계 메커니즘을 사용하여 컨센서스에 도달한 후 블록체인에 기입할 수 있고, 컨센서스 메커니즘을 사용하여 블록체인상에서 계약 컨센서스에 도달할 수 있다. 여기서 컨센서스 메커니즘은 작업 증명(proof of work, PoW), 지분 증명(proof-of-stake, PoS), 및 실용적 비잔틴 장애 허용(practical byzantine fault tolerance, PBFT)과 같은 방식을 더 포함할 수 있으며, 이에 한정되지 않음을 이해해야 한다. 다른 기능은 누구나 서버를 설정하고 블록체인 네트워크에 서버를 추가하여 노드가 되도록 할 수 있다는 것이다. 따라서, 분산 원장 시스템은 복수의 스테이션(station), 서로 다른 지리적 위치, 또는 복수의 기구(organization)에 의해 구성된 블록체인 네트워크에서 공유될 수 있는 자산 데이터베이스로 이해될 수 있다. 블록체인 네트워크의 참여자는 실제 원장의 유일한 사본을 획득할 수 있다. 원장 내의 임의의 수정사항은 모든 사본에 반영되며, 반영 시간은 몇 분 또는 심지어 몇 초 이내일 수 있다.
동일한 블록체인 네트워크에서, 블록체인의 컨센서스 도달(즉, 발표 노드 간의 컨센서스 및 계약 노드 간의 컨센서스) 및 지능형 계약의 실행은 특정 계약 노드에서 수행되도록 제한될 수 있음을 이해해야 한다. 본 개시에서 설명되는 지능형 계약은 업데이트 작업을 수행하는 실행자(예: 도 1에 도시된 실행 노드(30a))와 업데이트된 서버(즉, 도 1에 도시된 서버 노드(40a))가 공동으로 참여하는 펌웨어 업데이트 계약이다. 펌웨어 업데이트 계약은, 서버 노드(40a)(즉, 제1 서버 노드)에 대한 실행 노드(30a)의 펌웨어 업데이트 요청(즉, 펌웨어 업데이트 요청)을 수신하는 경우, 계약 노드(20a)는 블록체인으로부터, 실행 노드에 의해 송신되는 펌웨어 업데이트 요청의 유효성을 결정하기 위해, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록과 펌웨어 업데이트 요청에서의 업데이트된 버전 파라미터를 획득할 수 있음을 지시하는 데 사용될 수 있다. 이를 고려하여, 본 개시의 일 실시예에서, 계약 노드(20a)가 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하는 경우, 실행 노드(30a)가 업데이트된 버전 파라미터에 기초하여, 현재 제1 서버 노드에서 운영되는 운영 버전 파라미터(running version parameter)를 업데이트하도록 허용될 수 있음을 지시한다. 그렇지 않으면, 실행 노드는 제1 서버 노드상에서 펌웨어 업데이트를 수행할 수 없다. 펌웨어 업데이트 작업이 유효한지 무효한지는 지능형 계약을 호출함으로써 효과적으로 구분되어, 무효한 경우에 펌웨어 업데이트를 방지함으로써, 펌웨어 업데이트의 보안성과 신뢰성을 효과적으로 향상시킬 수 있음을 알 수 있다.
본 개시의 일 실시예에서, 블록체인은 블록 구조에서의 블록으로 구성될 수 있다. 블록으로 형성된 블록체인은 중첩된 해시 체인이라고 지칭될 수 있다, 즉, 중첩된 해시 체인에서의 각각의 블록은 이전 블록의 해시와, 제1 서버 노드(예: 도 1에 도시된 서버 노드(40a))에 대해 펌웨어 업데이트를 수행하기 위한 복수의 이력 버전 업데이트 행위 정보를 포함한다. 이력 버전 업데이트 행위 정보를 포함하는 버전 업데이트 기록은 통칭하여 펌웨어 버전 업데이트 기록이라고 할 수 있다. 본 개시의 일 실시예에서, 블록은 대응하는 펌웨어 버전 업데이트 기록을 포함할 수 있고, 본 개시의 일 실시예에서, 블록은 대응하는 펌웨어 버전 발표 기록을 더 포함할 수 있음을 이해해야 한다. 이해의 편의를 위해, 본 개시의 일 실시예에서, 펌웨어 버전 업데이트 기록을 포함하는 블록을 통칭하여 제1 블록이라고 할 수 있고, 펌웨어 버전 발표 기록을 포함하는 블록을 통칭하여 제2 블록이라고 할 수 있다. 제1 블록은 펌웨어 버전 업데이트 기록을 포함할 수 있으며, 펌웨어 버전 업데이트 기록에서의 버전 업데이트 행위 정보는 제1 버전 파라미터 및 제2 버전 파라미터를 포함(carry)할 수 있으며, 제2 버전 파라미터는 제1 버전 파라미터에 대한 펌웨어 업데이트가 수행된 후 획득된 버전 파라미터이다. 펌웨어 버전 업데이트 기록은 제1 서버 노드의 펌웨어 버전 정보에 대한 업데이트 작업을 수행하는 행위의 버전 업데이트 행위 정보를 기록하는 데 사용될 수 있음을 알 수 있다. 제1 서버 노드에서의 복수의 펌웨어에 대한 펌웨어 업데이트 작업이 완료되었으면, 복수의 이력 버전 업데이트 행위 정보가 생성될 수 있다.
본 개시의 일 실시예에서, 모든 유효한 펌웨어 업데이트 작업에 대응하는 펌웨어 버전 업데이트 기록과, 버전 발표 작업에 대응하는 펌웨어 버전 발표 기록은 블록체인에 기록될 수 있으므로, 발표 노드는 나중에 체인상의 서버 노드 각각의 보안 상태를 조회할 수 있다. 예를 들어, 발표 노드는 경보용 대규모 서버 노드 중에서 비정상으로 의심되는 서버 노드를 찾고 대응하는 비상 대응 프로세스를 사용하기 위해, 각각 서버 노드의 온 오프 체인 펌웨어 정보 및 온 체인 펌웨어 정보에 대해 보안 감사를 수행할 수 있다. 예를 들어, 비정상으로 의심되는 서버 노드에 대해 네트워크 분리를 수행하여, 불법 침입 수단을 검출하는 능력을 효과적으로 향상시키고 기업 인트라넷의 보안을 크게 향상시킬 수 있다.
본 개시의 일 실시예에서, 도 1에 도시된 바와 같다. 도 1에 도시된 바와 같이, 실행 노드(30a)는 서버 노드(40a)(즉, 제1 서버 노드)에 대해 펌웨어 업데이트를 수행하기 전에, 도 1에 도시된 계약 노드(20a)에 펌웨어 업데이트 요청을 송신할 수 있다. 따라서, 계약 노드(20a)가 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하는 경우, 실행 노드(30a)는 펌웨어 업데이트를 수행하도록 허용될 수 있다. 본 개시의 일 실시예에서, 제1 서버 노드(예: 도 1에 도시된 서버 노드(40b)) 대해 펌웨어 업데이트가 수행된 후, 새로운 펌웨어 버전 업데이트 기록이 생성될 수 있으며, 새로운 펌웨어 버전 업데이트 기록을 포함하는 블록은 새로운 제1 블록으로 지칭될 수 있다. 따라서, 새로운 제1 블록이 블록체인에 순차적으로 기록될 수 있으므로, 발표 노드는 블록체인상의 제1 서버 노드의 보안 상태에 대한 감사를 후속적으로 수행할 수 있다. 즉, 발표 노드는 블록체인의 제1 블록에 저장된 제1 서버 노드의 온 체인 펌웨어 정보와 로컬로 수집된 오프 체인 펌웨어 정보에 기초하여, 제1 서버 노드의 보안 상태를 평가할 수 있다. 온 체인 펌웨어 정보가 오프 체인 펌웨어 정보와 일치하면, 정상 값(normal value)이 회신될 수 있다. 그렇지 않으면, 제1 서버 노드의 보안 상태가 비정상임을 지시한다. 이 경우, 발표 노드는 이동 단말기 또는 웹 단말기의 경보 정보의 방식으로 경보 정보(즉, 워크시트 정보)를 제1 서버 노드에 대응하는 사용자에게 회신할 수 있다.
계약 노드(20a)가 펌웨어 업데이트 요청을 획득하고 펌웨어 버전 발표 기록, 펌웨어 버전 업데이트 기록 및 업데이트된 버전 파라미터에 기초하여 펌웨어 업데이트 요청의 유효성에 대한 인증을 수행하는 구체적인 프로세스에 대해서는, 도 2 ∼ 도 8에 대응하는 다음의 실시예를 참조할 수 있다.
또한, 도 2는 본 개시명의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 방법의 개략 흐름도이다. 도 1에 도시된 바와 같이. 도 2를 참조하면, 본 방법은 계약 노드로서 전자 기기에 적용될 수 있으며, 구체적으로 단계 S101 내지 단계 S103을 포함될 수 있다.
단계 S101. 실행 노드에 의해 송신되는 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신한다.
구체적으로, 계약 노드는 제1 서버 노드에 대한, 실행 노드에 의해 송신되는 펌웨어 업데이트 요청을 수신할 수 있다. 본 개시의 일 실시예에서, 펌웨어 업데이트의 보안성 및 신뢰성을 보장하기 위해, 실행 노드는 제1 서버 노드에 대해 펌웨어 업데이트를 수행하기 전에, 펌웨어 업데이트 요청을 계약 노드에 송신해야 하며, 펌웨어 업데이트 요청은 적어도 제1 서버 노드의 업데이트된 버전 파라미터를 포함할 수 있다. 본 개시의 일 실시예에서, 펌웨어 업데이트 요청은 제1 서버 노드의 운영 버전 파라미터를 더 포함될 수 있다.
운영 버전 파라미터는 제1 서버 노드에 의해 현재 운영되는 구(old) 펌웨어 버전 정보 및 구 펌웨어 버전 정보의 해시 값을 포함할 수 있다. 본 개시의 일 실시예에서, 업데이트된 버전 파라미터는 제1 서버 노드에 대해 펌웨어 업데이트를 수행하기 위해 계획된 신(new) 펌웨어 버전 정보 및 신 펌웨어 버전 정보의 해시 값을 포함될 수 있다. 이해의 편의를 위해, 본 개시의 일 실시예에서, 제1 서버 노드에 의해 현재 운영되는 구 펌웨어 버전 정보는 운영 버전 정보(예: 펌웨어 버전 V1)로 지칭될 수 있고, 펌웨어 버전 정보의 해시 값은 운영 버전 해시 값(예: 해시 값 H1)으로 지칭될 수 있다. 또한, 본 개시의 일 실시예에서, 현재 제1 서버 노드에 대해 펌웨어 업데이트를 수행하기 위해 계획된 신 펌웨어 버전 정보는 업데이트된 버전 정보(예: 펌웨어 버전 V2)로 지칭될 수 있고, 및 신 펌웨어 버전 정보의 해시 값은 업데이트된 버전 해시 값(예: 해시 값 H2)으로 지칭될 수 있다. 여기서 운영 버전 해시 값은 또한 구 펌웨어 해시 값으로 지칭될 수 있음을 이해할 수 있다. 마찬가지로, 업데이트된 버전 해시 값은 또한 신 펌웨어 해시 값으로 지칭될 수 있다.
본 개시의 일 실시예에서, 펌웨어 업데이트 요청을 송신하기 전에, 실행 노드는 획득된 운영 버전 파라미터 및 업데이트된 버전 파라미터를 펌웨어 버전 업데이트 기록을 생성하기 위해 후속적으로 사용되는 입력 정보라고 지칭할 수 있다, 즉, 실행 노드는 제1 서버 노드에 의해 현재 운영되는 운영 버전 파라미터(즉, 펌웨어 버전 V1 및 해시 값 H1) 및 제1 서버 노드의 펌웨어를 업데이트하기 위해 계획된 업데이트된 버전 파라미터(즉, 펌웨어 버전 V2 및 해시 값 H2)를 입력 정보라고 지칭하고, 실행 노드의 개인 키를 사용하여 입력 정보에 서명하고, 서명된 제1 서명 정보와 실행 노드의 공개 키를 업데이트 요청에 추가하여, 펌웨어 업데이트 요청을 획득할 수 있다. 따라서, 본 개시의 일 실시예에서, 계약 노드는 펌웨어 업데이트 요청을 수신한 후, 실행 노드의 수신된 공개 키를 사용하여 실행 노드의 제1 서명 정보에 대해 서명 검증을 수행하고, 검증이 성공한 경우, 실행 노드에 의해 제공되는 업데이트된 버전 파라미터 및 운영 버전 파라미터를 획득할 수 있다.
실행 노드는 도 1에 대응하는 전술한 실시예에서의 구현 계층(300)에 위치한 실행 노드(30a)일 수 있고, 제1 서버 노드는 도 1에 대응하는 전술한 실시예에서의 구현 계층(300)에 위치한 서버 노드(40a)일 수 있다. 계약 노드는 도 1에 대응하는 전술한 실시예에서의 계약 계층(200)에 위치한 계약 노드(20a)일 수 있다. 본 개시의 일 실시예에서, 블록체인에서의 실행 노드(30a), 서버 노드(40a) 및 계약 노드(20a)는 블록체인 네트워크에서의 노드로 통칭될 수 있다. 블록체인에 추가된 각각의 노드에 대해, 블록체인은 대응하는 공개 키 쌍과 대응하는 개인 키 쌍을 노드에 할당할 수 있음을 이해해야 한다. 각각의 노드의 공개 키는 블록체인의 다른 노드에 의해 학습될 수 있다. 그러나 각각의 개인 키는 대응하는 노드에 의해 독립적으로 적절하게 저장될 수 있다. 예를 들어, 서버 노드의 경우, 엔티티가 물리적인 기기이기 때문에, 서버 노드의 개인 키는 신뢰 실행 환경(trusted execution environment, TEE)의 신뢰 컴퓨팅 환경에 기초하여 저장될 수 있다. 이러한 방식으로, 블록체인의 다른 노드가 서버 노드의 개인 키를 알 수 없도록 보장할 수 있다. 다른 예에서, 실행 노드의 개인 키는 특정 저장 매체를 사용하여 저장될 수 있다. 블록체인에서의 노드의 개인 키가 적절하게 저장되어, 후속하는 계약 실행 프로세스의 보안성과 신뢰성을 보장할 수 있음을 알 수 있다.
블록체인은 구현 계층(300)에서의 실행 노드에 대응하는 공개 키 쌍과 대응하는 개인 키 쌍을 할당하는데, 이는 실행 노드에 특수 ID를 할당하는 것과 동일하므로, 불법 공격자에 의한, 실행 노드의 신원을 위조하여 서버 펌웨어를 무효하게 조작하는 전술한 어려움을 효과적으로 개선할 수 있다.
단계 S102. 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 지능형 계약에 기초하여 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록, 컨센서스 메커니즘에 기초하여 블록체인상의 발표 노드에 의해 결정되는 펌웨어 버전 발표 기록을 획득한다.
구체적으로, 계약 노드는 블록체인에서의 제1 서버 노드의 블록체인 주소를 획득하기 위해 지능형 계약을 호출할 수 있으며, 블록체인 주소는 제1 서버 노드의 공개 키 정보에 따라 해시 계산이 수행된 후에 블록체인에 의해 고유하게() 결정된다. 또한, 계약 노드는 블록체인으로부터의 블록체인 주소에 기초하여, 제1 서버 노드와 연관된 제1 블록 및 제2 블록을 획득될 수 있다. 또한, 계약 노드는 제1 블록에서, 제1 버전 파라미터와 제2 버전 파라미터를 포함하는 이력 버전 업데이트 행위 정보를 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록으로서 결정할 수 있으며, 제2 버전 파라미터는 제1 버전 파라미터에 대해 펌웨어 업데이트가 수행된 후 획득된 버전 파라미터이다. 또한, 계약 노드는 제2 블록에서, 제1 서버 노드와 연관된 이력 버전 발표 행위 정보를 펌웨어 버전 발표 기록으로서 결정할 수 있다.
본 개시의 일 실시예에서, 블록체인 네트워크에서의 각각의 노드(즉, 각각의 분산 노드)는 블록체인 시스템에서 정보를 수신, 처리 및 피드백하기 위해 개별로 사용될 수 있음을 도 1에 도시된 블록체인 네트워크 토폴로지 구조로부터 알 수 있다. 즉, 블록체인 네트워크에 위치한 노드는 정보를 수신할 뿐만 아니라 정보를 생성하며, 노드 간의 통신은 공통 블록체인을 유지함으로써 유지될 수 있다.
본 개시의 일 실시예에서, 블록체인 네트워크의 노드(예: 계약 노드)는 새로운 블록을 생성할 수 있다. 블록체인 네트워크의 다른 노드(예: 도 1에 대응하는 전술한 실시예의 다른 계약 노드)은 새로운 블록이 생성된 후 브로드캐스팅 방식으로 통지되고, 그런 다음 블록을 검증한다. 블록체인 네트워크의 51% 이상의 노드 검증이 성공하는 경우, 노드 간의 컨센서스(예: 계약 컨센서스)에 도달한 것으로 결정된다. 이 경우, 새로운 블록이 블록체인에 추가될 수 있다.
본 개시의 일 실시예에서, 지능형 계약을 사용하여 서버 노드의 펌웨어를 업데이트 및 제어하는 프로세스에서, 제2 버전 파라미터를 사용하여 서버 노드에서의 펌웨어의 제1 버전 파라미터(예: 제1 서버 노드는 도 1에 대응하는 전술한 실시예에서의 서버 노드(40a)임)에 대해 계약 노드는 실행 노드에 의해 매번 수행되는 펌웨어 업데이트의 버전 업데이트 행위 정보를 서버에 기록할 수 있다. 본 개시의 일 실시예에서, 업데이트 작업은 서버 노드에서의 하나 이상의 펌웨어에 대해 수행될 수 있으며, 이는 여기서 한정되지 않는다.
본 개시의 일 실시예에서, 실행 노드가 서버 노드에서의 펌웨어 업데이트 작업을 완료할 때마다, 실행 노드는 펌웨어 업데이트 로그 정보, 즉 서브펌웨어 버전 업데이트 기록을 생성할 수 있다. 하나의 펌웨어 업데이트 로그 정보(즉, 서브펌웨어 버전 업데이트 기록)은 제1 서버 노드에서의 펌웨어에 대해 수행된 펌웨어 업데이트의 버전 업데이트 행위 정보를 포함할 수 있다. 본 개시의 일 실시예에서, 계약 노드는 또한 각각의 펌웨어의 버전 업데이트 행위 정보를 포함하는 서브펌웨어 버전 업데이트 기록을 제1 서버 노드에서의 펌웨어의 펌웨어 버전 업데이트 기록으로서 통칭할 수 있다.
본 개시의 일 실시예에서, 제1 서버 노드에서의 펌웨어가 업데이트되기 전에 획득된 구 펌웨어 버전 정보 및 구 펌웨어 해시 값은 제1 버전 파라미터로 지칭될 수 있고, 제1 서버 노드에서의 펌웨어가 업데이트된 후 획득된 신 펌웨어 버전 정보 및 신 펌웨어 해시 값은 제2 버전 파라미터로 지칭될 수 있다.
펌웨어 업데이트가 서버 노드(40a)에 대해 수행되는 애플리케이션 시나리오에서, 결정된 유효성의 모든 업데이트 결과(즉, 펌웨어 버전 업데이트 기록)는 블록체인에 순차적으로 기입될 수 있다. 이러한 방식으로, 현재 단계 S101에서 펌웨어 업데이트 요청을 수신하는 경우, 서버 노드는 블록체인으로부터의 서버 노드의 블록체인 주소에 기초하여, 제1 서버의 펌웨어와 연관된 제1 블록 및 제2 블록을 획득할 수 있다. 본 개시의 일 실시예에서, 제1 블록은 하나 이상의 제1 블록을 포함할 수 있다. 각각의 제1 블록은 대응하는 업데이트 타임스탬프에 대응하는 펌웨어 버전 업데이트 기록을 포함할 수 있고, 펌웨어 버전 업데이트 기록은 하나 이상의 서브펌웨어 버전 업데이트 기록을 포함할 수 있다. 이해의 편의를 위해, 본 개시의 일 실시예에서, 각각의 서브펌웨어 버전 업데이트 기록은 제1 서버 노드에서의 대응하는 펌웨어의 펌웨어 버전 업데이트 기록으로서 통칭될 수 있다. 제1 서버 노드의 대응하는 펌웨어의 버전 정보에 대한 업데이트 작업이 완료될 때마다, 펌웨어 버전 업데이트 기록을 획득하기 위해, 서브펌웨어 버전 업데이트 기록이 생성될 수 있음을 이해해야 한다.
본 개시의 일 실시예에서, 이전 블록의 생성에서부터 새로운 블록의 생성까지의 블록 생성 기간에, 실행 노드가 제1 서버 노드에서의 펌웨어 하나에 대해서만 업데이트 작업을 완료하면, 실행 노드는 하나의 서브펌웨어 버전 업데이트 기록을 획득할 수 있다. 이 경우, 서브펌웨어 버전 업데이트 기록은 새론 블록에서의 펌웨어 버전 업데이트 기록으로서 사용될 수 있다. 본 개시의 일 실시예에서, 블록 생성 기간에, 실행 노드가 제1 서버 노드에서의 복수의 펌웨어에 대한 업데이트 작업을 완료하였으면, 실행 노드는 복수의 서브펌웨어 버전 업데이트를 획득할 수 있다. 이 경우, 서브펌웨어 버전 업데이트 기록은 새로운 블록에서의 펌웨어 버전 업데이트 기록으로 통칭될 수 있다.
유사하게, 본 개시의 일 실시예에서, 제2 블록은 하나 이상의 제2 블록을 포함할 수 있다. 각각의 제2 블록은 대응하는 발표 타임스탬프에 대응하는 펌웨어 버전 발표 기록을 포함할 수 있다. 제1 서버 노드의 대응하는 펌웨어의 버전 정보에 대한 발표 작업이 완료될 때마다, 펌웨어 버전 발표 기록이 생성될 수 있음을 이해해야 한다.
현재 지능형 계약을 호출하는 현재 프로세스에서, 이전에 지능형 계약을 호출함으로써 획득된 펌웨어 버전 업데이트 기록에서의 버전 업데이트 행위 정보는 이력 버전 업데이트 행위 정보로 지칭될 수 있고, 이전에 획득된 펌웨어 버전 발표 기록에서의 버전 발표 행위 정보는 이력 버전 발표 행위 정보로 지칭될 수 있다.
이해의 편의를 위해, 본 개시의 일 실시예에서는 타깃 펌웨어의 펌웨어 버전 업데이트 기록과 제1 블록 사이의 연관 관계를 설명하기 위해, 제1 서버 노드에서의 타깃 펌웨어에 대해 펌웨어 업데이트를 수행한 후 획득된 펌웨어 버전 업데이트 기록을 예로 사용한다. 또한, 도 3은 본 개시의 일 실시예에 따른 중첩된 해시 체인의 블록 구조의 개략도이다. 도 3에 도시된 중첩된 해시 체인은 도 3에 도시된 블록 N, 블록 N+1 및 블록 N+2를 포함할 수 있다. N은 양의 정수일 수 있다. 도 3에 도시된 바와 같이, 각각의 블록은 제1 서버 노드에 대해 펌웨어 업데이트를 수행한 후 획득된 펌웨어 업데이트 로그 정보를 기록한다. 본 개시의 일 실시예에서, 각각의 펌웨어 업데이트 로그 정보(즉, 서브펌웨어 버전 업데이트 기록)는 펌웨어 버전 업데이트 기록으로 통칭될 수 있다.
도 3에 도시된 각각의 블록(즉, 제1 블록)은 이전 블록(즉, 이전 제1 블록)의 해시(헤더라고 함)와 대응하는 펌웨어 버전 업데이트 기록을 포함할 수 있다, 즉, 중첩된 해시 체인에서의 블록에 있는 데이터는 유일성(uniqueness) 및 추적성(traceability)을 가질 수 있다. 도 3에 도시된 바와 같이, 블록 N은 블록 N 이전의 블록의 해시 값(즉, 도 3에 도시된 블록 N-1의 해시) 및 제1 서브 노드에 대해 펌웨어 업데이트 작업이 수행된 후 획득된 펌웨어 버전 업데이트 기록 1을 포함할 수 있다. 마찬가지로, 블록 N+1은 블록 N+1 이전 블록의 해시 값(즉, 도 3에 도시된 블록 N의 해시) 및 제1 서버 노드에 대해 다른 펌웨어 업데이트 작업이 수행된 후 획득된 펌웨어 버전 업데이트 기록 2를 포함할 수 있다. 유사하게, 블록 N+2는 블록 N+2 이전 블록의 해시 값(즉, 도 3에 도시된 블록 N+1의 해시) 및 제1 서버 노드에 대해 또 다른 펌웨어 업데이트 작업이 수행된 후에 획득된 펌웨어 버전 업데이트 기록 3을 포함할 수 있다. 도 3에 도시된 블록 N, 블록 N+1 및 블록 N+2가 제1 블록으로 지칭될 수 있음을 이해해야 한다. 제1 블록은 제1 서버 노드에서의 타깃 펌웨어(예: 펌웨어 K)의 펌웨어 버전 정보에 대해 업데이트 작업을 수행한 후 획득된 서브펌웨어 버전 업데이트 기록을 포함할 수 있다.
예를 들어, 블록 N은 펌웨어 K의 서브펌웨어 버전 업데이트 기록을 포함할 수 있고, 블록 N+1은 펌웨어 K의 서브펌웨어 버전 업데이트 기록을 포함할 수 있으며, 블록 N+2는 서브펌웨어 버전 업데이트 기록을 포함될 수 있다.
도 3에 도시된 바와 같이, 이해의 편의를 위해, 본 개시의 일 실시예에서, 제1 블록에서의 하나의 블록(예: 블록 N+1)을 예로 사용하여, 블록 N+2에서의 펌웨어 버전 업데이트 기록 2가 복수의 서브펌웨어 버전 업데이트 기록을 포함할 수 있고, 구체적으로 도 3에 도시된 업데이트 기록 1, 업데이트 기록 2, 업데이트 기록 3 및 업데이트 기록 4일 수 있음을 설명한다. 업데이트 기록 1은 블록 N+1에서 발견되고 펌웨어 K의 서브펌웨어 버전 업데이트 기록일 수 있다.
도 3에 도시된 블록 N+1은 도 3에 도시된 블록 헤더(10) 및 블록 본체(20)를 포함할 수 있다. 도 3에 도시된 바와 같이, 블록 헤더(10)는 이전 블록(즉, 도 3에 도시된 블록 N)의 해시 값, 타임스탬프, 계산 난이도 값, 블록 N+1을 생성하기 위한 난수 세트, 및 머클 트리 루트(머클 트리 루트는 블록 N+1의 해시 값일 수 있다, 즉, 블록 N+1의 해시 값은 도 3에 도시된 블록 N+2에서의 블록 헤더에서 부모 블록 해시 값으로 사용될 수 있음)을 포함할 수 있다. 본 개시의 일 실시예에서, 이전 블록의 해시 값은 부모 블록 해시 값으로 지칭될 수 있음을 이해해야 한다. 도 3에 도시된 블록 헤더(10)의 타임스탬프는 블록체인에서 하나의 블록의 위치를 유일하게 식별할 수 있게 한다. 또한, 도 3에 도시된 블록 본체(20)는 블록 N+1이 생성되기 전과 블록 N이 생성된 후의 이 기간에 제1 서버 노드의 펌웨어를 업데이트하기 위한 모든 이력 버전 업데이트 행위 정보를 포함할 수 있다. 본 개시의 일 실시예에서, 제1 서버 노드에서의 하나의 펌웨어에 대한 업데이트 작업이 완료될 때마다, 하나의 서브펌웨어 버전 업데이트 기록이 생성될 수 있다(즉, 하나의 업데이트 기록 또는 하나의 펌웨어 업데이트 로그 정보가 생성될 수 있다). 본 개시의 일 실시예에서, 이 기간 내에 완료된 모든 펌웨어 업데이트 작업에 대응하는 업데이트 기록은 도 3에 도시된 펌웨어 버전 업데이트 기록 2로 지칭될 수 있다, 즉, 펌웨어 버전 업데이트 기록 2는 복수의 서브펌웨어 버전 업데이트 기록을 포함할 수 있다. 구체적으로, 도 3에 도시된 바와 같이, 업데이트 기록 1, 업데이트 기록 2, 업데이트 기록 3 및 업데이트 기록 4는 머클 트리 형태로 함께 구조화될 수 있다(organized).
도 3에 도시된 머클 트리의 구축 과정은 해시 값을 재귀적으로 계산하는 프로세스(즉, 해시 값을 재귀적으로 계산)임을 이해해야 한다. 도 3에서는 업데이트 기록 1 및 업데이트 기록 2가 예로 사용되며, 업데이트 기록 1에 대응하는 해시 값 1은 SHA256 해시 계산 방법을 사용하여 계산을 통해 획득될 수 있다. 마찬가지로, 업데이트 기록 2에 대응하는 해시 값 2은 SHA256 해시 계산 방법을 사용하여 계산을 통해 획득될 수 있다. 또한, 해시 값 1과 해시 값 2는 직렬로 연결되고, 해시 변환이 계속 수행되어, 도 3에 도시된 해시 값 12를 획득한다. 유사하게, 업데이트 기록 3 및 업데이트 기록 4의 경우, 도 3에 도시된 해시 값 34는 계층별로 재귀적 계산을 수행하여 획득될 수 있으므로, 최종적으로 하나의 루트(즉, 도 3에 도시된 해시 값 1234)가 남을 때까지, 해시 값 12와 해시 값 34이 해시 변환을 수행하기 위해 추가로 직렬로 연결된다. 이 경우, 본 개시의 일 실시예에서, 최종적으로 획득된 모든 트랜잭션 정보의 해시 값은 N+1 블록의 머클 트리 루트로서 사용될 수 있다. 머클 트리의 확장 성이 우수하고, 업데이트 기록의 수량에 관계없이, 고정 길이의 머클 트리와 머클 트리 루트가 최종적으로 생성될 수 있음을 알 수 있다. 본 개시의 일 실시예에서, 머클 트리의 구조는 펌웨어 버전을 추적하는 후속 프로세스에서 버전 검색의 효율성을 보장하기 위해 사용될 수 있음을 이해해야 한다.
본 개시의 일 실시예에서, 버전 관리 제어(예: 버전 발표 제어 및 버전 업데이트 제어)는 펌웨어의 소스를 혼합하는 동일한 블록체인 네트워크를 사용하여 제1 서버 노드에서의 펌웨어에 대해 수행될 수 있음을 이해해야 한다. 즉, 서버 벤더는 버전 관리 프로스 제어 시에 구별되어야 한다. 예를 들어, 서로 다른 벤더에 의해 발표된 펌웨어 버전 정보에 대해 펌웨어 업데이트를 수행하는 프로세스에서, 버전 업데이트 제어는 서로 다른 계약 노드를 사용하여 수행될 수 있다. 예를 들어, 펌웨어 업데이트는, 도 1에 도시된 계약 노드(20a)를 사용하여, 벤더 A에 의해 발표된 펌웨어 버전 정보에 대해 수행될 수 있고, 펌웨어 업데이트는, 도 1에 도시된 계약 노드(20b)를 사용하여, 벤더 B에 의해 발표된 펌웨어 버전 정보에 대해 수행될 수 있다. 또한, 본 개시의 일 실시예에서, 상이한 벤더에 의해 발표된 펌웨어 버전 정보의 펌웨어 업데이트를 관리하기 위해 상이한 블록체인 네트워크가 추가로 확립될 수 있다. 블록체인 네트워크를 확립하는 구체적인 형태는 여기에 한정되지 않는다.
또한, 이해의 편의를 위해, 본 개시의 일 실시예에서, 예를 들어, 업데이트 작업은 제1 서버 노드에서의 하나의 펌웨어(예: 펌웨어 K)를 타깃 펌웨어로 하여 수행된다. 지능형 계약을 호출하는 경우, 계약 노드는 블록체인에서의 제1 서버 노드의 블록체인 주소를 획득하고, 펌웨어 K의 이력 업데이트 상태 및 이력 발표 상태에 관해 블록체인 주소에 대응하는 블록체인 기록을 참고할 수 있다. 즉, 본 개시의 일 실시예에서, 제1 서버 노드와 연관된 제1 블록 및 제2 블록은 블록체인으로부터 획득될 수 있다. 따라서, 제1 블록에서의 타깃 펌웨어의 제1 버전 파라미터 및 제2 버전 파라미터를 포함하는 이력 버전 업데이트 행위 정보는 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록으로서 사용될 수 있다. 한편, 계약 노드는 단계 S103을 추가로 수행하고 실행 노드에 의해 현재 송신되는 펌웨어 업데이트 요청의 유효성을 구별하기 위해, 제2 블록으로부터 제1 서버 노드에서의 펌웨어 K와 연관된 과거 버전 발표 행위 정보를 펌웨어 버전 발표 기록으로서 사용할 수 있어, 펌웨어 업데이트의 보안성 및 신뢰성을 향상시킬 수 있다.
펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 블록체인상의 발표 노드에 의해 결정됨을 이해해야 한다. 즉, 본 개시의 일 실시예에서, 발표 노드 간에 컨센서스에 도달할 수 있는 경우, 발표 노드에 의해 발표된 신 펌웨어 버전 발표 파라미터가 계약 노드에 의해 인식될 수 있다고 결정된다. 따라서 계약 노드 간에 컨센서스에 추가로 도달하는 경우, 신 펌웨어 버전 발표 파라미터를 포함하는 블록이 저장을 위해 블록체인에 기입될 수 있다.
이해의 편의를 위해, 또한, 도 4a 및 도 4b는 본 개시의 일 실시예에 따른 버전 발표 제어를 수행하는 개략도이다. 도 4a에 도시된 바와 같이, 발표 노드 1(예를: 도 1에 대응하는 전술한 실시예에서의 발표 노드(10a)일 수 있음))에 의해 브로드캐스트되는 펌웨어 K의 신 펌웨어 버전 발표 파라미터(즉, 펌웨어 버전 발표 파라미터 1)를 수신하는 경우, 계약 노드 1은 도 4a에 도시된 시간 윈도 T 내에서 대기할 수 있다. 즉, 계약 노드는 다른 발표 노드에 의해 발표되는 동일한 펌웨어 버전 발표 파라미터를 수신하기 위해, 도 1에 대응하는 전술한 실시예에서 미리 설정된 시간 윈도 T)내에서 대기할 수 있다. 계약 노드가 펌웨어 버전 발표 파라미터를 획득하는 구체적인 프로세스에 대해서는, 도 4b에 도시된 단계 S1 ∼ 단계 S3을 참조할 수 있다. 도 4b에 도시된 바와 같이, 발표 노드 1은 벤더(예: 벤더 A)에 의해 발표된 최신 버전의 펌웨어 파일을 수신하고, 수신한 최신 버전의 펌웨어 파일에 대해 파일 구조 파싱을 수행하여, 추가로 파일 내용에 따라 파일의 해시 값을 계산하고 내부 버전 번호의 해시 값을 계산할 수 있다. 여기서 내부 버전 번호는 제1 서버 노드에서의 펌웨어 K에 대해 벤더 A에 의해 발표된 최신 펌웨어 버전 정보임을 이해해야 한다. 펌웨어 K의 최신 펌웨어 버전 정보 및 최신 펌웨어 버전 정보의 해시 값은 펌웨어 K의 펌웨어 버전 발표 파라미터로 지칭될 수 있으며, 펌웨어 버전 발표 파라미터를 포함하는 펌웨어 발표 요청은 도 4b에 도시된 계약 노드 1에 전송되므로, 계약 노드 1은 도 4b에 도시된 단계 S5를 수행할 수 있다.
본 개시의 일 실시예에서, 블록체인에서, 데이터 송신 무결성(data transmission integrity)을 보장하기 위해, 펌웨어 K의 펌웨어 버전 발표 파라미터를 도 4b에 도시된 계약 노드 1에 전송하기 전에, 발표 노드 1은 발표 노드 1의 개인 키를 사용하여 펌웨어 버전 발표 파라미터(즉, 도 4a에 도시된 펌웨어 버전 발표 파라미터 1)를 추가로 서명하여, 서명 결과 및 발표 노드 1의 공개 키를 계약 노드 1로 함께 제공한다. 따라서, 계약 노드 1은 발표 노드 1에 의해 전송되는 펌웨어 발표 요청을 수신하는 경우, 발표 노드 1의 공개 키를 사용하여 서명 결과에 대해 서명 검증을 수행하여, 펌웨어 발표 요청에 포함된 펌웨어 버전 발표 파라미터 1을 획득할 수 있다.
도 4a에 도시된 바와 같이, 계약 노드 1은 펌웨어 버전 발표 파라미터 1을 획득한 후, 시간 윈도 T 내에서 대기한다. 다른 발표 노드(예: 도 4a에 도시된 발표 노드 2)에 의해 발표된 동일한 펌웨어 버전 발표 파라미터(즉, 펌웨어 버전 발표 파라미터 1)이 시간 윈도 T 내에 존재하면, 계약 노드 1은 발표 노드 1과 발표 노드 2 사이에 컨센서스에 도달했다고 간접적으로 결정할 수 있다. 이 경우 계약 노드 1은 펌웨어 버전 발표 파라미터 1을 포함하는 블록을 획득하고, 펌웨어 버전 발표 파라미터 1을 포함하는 블록을 블록체인에 기입하도록 요청할 수 있다.
본 개시의 일 실시예에서, 펌웨어 버전 발표 파라미터 1을 포함하는 블록을 블록체인에 새로운 블록(예를 들어, 블록 A)으로서 기입하기 전에, 계약 노드 1은 블록 A를, 물리 네트워크를 통해 도 1에 대응하는 전술한 실시예에서의 계약 계층(200)의 다른 계약 노드와 동기화해야 한다. 도 4a에 도시된 바와 같이, 블록 A는 다른 계약 노드 중의 51% 이상의 계약 노드가 계약 컨센서스에 도달한 것으로 결정하는 경우에 펌웨어 버전 발표를 포함하는 블록(즉, 블록 A)을 블록체인에 기입하기 위해, 물리 네트워크를 통해 계약 노드 2, 계약 노드 3, ... 및 계약 노드 n과 동기화될 수 있다. 노드 간의 컨센서스는 특정 기능을 가진 계약 노드(예: 계약 노드 1)에 한정되고, 버전 발표 제어는 계약 노드를 사용하여 효과적으로 수행할 수 있음을 알 수 있다. 즉, 벤더 A가 발표한 펌웨어 버전 정보가 최신 버전의 벤더 펌웨어 정보라고 결정되는 경우, 블록 A가 블록체인에 기입된다. 이 경우, 본 개시의 일 실시예에서, 블록 A는 최신 발표 타임스탬프를 갖는 제2 블록으로 지칭될 수 있다. 즉, 최신 발표 타임스탬프를 갖는 제2 블록에 포함된 펌웨어 버전 발표 기록의 버전 발표 행위 정보는 제1 이력 버전 발표 행위 정보로 지칭될 수 있다. 또한, 블록체인에 있고 제1 서버 노드의 펌웨어 K와 연관된 다른 제2 블록에 포함된 펌웨어 버전 발표 기록에서의 버전 발표 행위 정보는 제2 이력 버전 발표 행위 정보로 지칭될 수 있다.
본 개시의 일 실시예에서, 펌웨어 버전 발표 기록을 포함하고 제1 서버 노드와 연관된 블록은 제2 블록으로 지칭될 수 있다. 계약 노드는 제2 블록으로부터 제1 서버 노드에서의 타깃 펌웨어(즉, 펌웨어 K)와 연관된 이력 버전 발표 행위 정보를 획득하여, 획득한 이력 버전 발표 행위 정보를 대응하는 펌웨어의 펌웨어 버전 발표 기록으로서 사용할 수 있다. 업데이트된 버전 파라미터는 펌웨어 버전 발표 기록과 비교되며, 타깃 펌웨어(즉, 펌웨어 K)의 펌웨어 버전 정보가 최신 펌웨어 버전 발표 파라미터 1에서의 펌웨어 버전 정보로 업데이트되었는지의 여부를 판정할 수 있다.
단계 S103. 펌웨어 버전 업데이트 기록, 펌웨어 버전 발표 기록 및 업데이트된 버전 파라미터에 따라 펌웨어 업데이트 요청의 유효성을 결정한다.
구체적으로, 계약 노드는 펌웨어 버전 업데이트 기록에서의 제1 버전 파라미터에 기초하여, 업데이트된 버전 파라미터에 대해 롤백 검출을 수행할 수 있으며; 제1 버전 파라미터가 업데이트된 버전 파라미터와 동일함을 검출한 것에 응답하여, 버전 롤백이 존재한다고 결정하고, 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정하며 - 무효한 업데이트 요청은 실행 노드가 제1 서버 노드의 버전 정보에 대한 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용됨 -; 제1 버전 파라미터가 업데이트된 버전 파라미터와 다름을 검출한 것에 응답하여, 버전 롤백이 존재하지 않는다고 결정하고, 업데이트된 버전 파라미터 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청의 유효성을 결정한다.
펌웨어 업데이트 요청은 제1 서버 노드의 운영 버전 파라미터를 더 포함한다. 이 경우, 계약 노드이 업데이트된 버전 파라미터 및 펌웨어 버전 발표 기록에 기초한 펌웨어 업데이트 요청의 유효성을 결정하는 것은, 구체적으로 다음 단계: 펌웨어 버전 발표 기록과 연관된 이력 버전 발표 행위 정보로부터 제1 버전 발표 행위 정보를 획득하는 단계 - 제1 버전 발표 행위 정보는 이력 버전 발표 행위 정보에서 최신 버전 발표 타임스탬프를 갖는 버전 발표 행위 정보임 -; 및 제1 버전 발표 행위 정보에 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정하는 단계를 포함할 수 있다.
본 개시의 일 실시예에서, 버전 롤백을 방지하기 위해, 펌웨어 K의 참조된(consulted) 이력 버전 업데이트 상태에 따라 펌웨어 K의 펌웨어 버전 정보에 대한 펌웨어 업데이트를 수행하기 위해, 업데이트된 버전 파라미터에 대해 롤백 검출이 수행될 수 있다. 펌웨어 K의 펌웨어 버전 업데이트 기록(예: 도 3에 도시된 업데이트 기록 1에 대응하는 서브펌웨어 버전 업데이트 기록)에서의 제1 파라미터가, 업데이트된 버전 파라미터에 업데이트된 버전 정보(예: 펌웨어 버전 번호 BBBB) 및 업데이트된 버전 해시 값(예: 해시 값)을 포함하면, 버전 롤백이 존재하는 것으로 결정된다. 따라서 펌웨어 업데이트 요청이 무효한 업데이트 요청으로 결정될 수 있다. 본 개시의 일 실시예에서는, 타깃 펌웨어(즉, 펌웨어 K)의 모든 이력 버전 업데이트 행위 정보를 획득할 수 있으며, 각각의 이력 버전 업데이트 행위 정보는 펌웨어 버전 업데이트 기록으로 지칭될 수 있다.
또한, 이해의 편의를 위해, 표 1은 본 개시의 일 실시예에서 제공되는 펌웨어 K의 펌웨어 버전 업데이트 기록 표이다. 펌웨어 K에 대한 펌웨어 업데이트가 한 번 수행될 때마다, 펌웨어 K의 펌웨어 버전 업데이트 기록이 생성될 수 있음을 이해해야 한다. 펌웨어 버전 업데이트 기록 A는 실행 노드가 제1 서버 노드에서의 펌웨어 K에 대한 펌웨어 업데이트를 처음 수행한 후 획득되고, 펌웨어 버전 업데이트 기록 B는 실행 노드가 제1 서버 노드에서의 펌웨어 K에 대한 펌웨어 업데이트를 두 번째로 수행한 후에 획득된다.
[표 1]
지능형 계약을 호출하는 경우, 계약 노드는 타깃 펌웨어(즉, 펌웨어 K)와 연관된 모든 펌웨어 버전 업데이트 기록을 제1 서버 노드와 연관된 제1 블록에 조회하고, 업데이트 시간 순서에 따라 표 1에 나타낸 펌웨어 버전 업데이트 기록 표를 구축할 수 있다. 표 1에 나타낸 바와 같이, 모든 제1 블록을 조회하여 획득된 펌웨어 K의 펌웨어 버전 업데이트 기록이 표 1에 나타낸 펌웨어 버전 업데이트 기록 A와 펌웨어 버전 업데이트 기록 B이고, 펌웨어 K의 다른 펌웨어 버전 업데이트 기록 이 제1 서버 노드와 연관된 제1 블록으로부터 획득되지 않으면, 본 개시의 일 실시예에서 실행 노드는 펌웨어 버전 업데이트 기록 B에서의 제2 버전 파라미터 B2에 있는 펌웨어 버전 정보 3 및 펌웨어 해시 값 3을 펌웨어 K에 의해 현재 운영되는 운영 버전 파라미터로서 사용할 수 있다. 즉, 계약 노드에 의해 수신된 펌웨어 업데이트 요청은 표 1에 나타낸 제2 버전 파라미터 B2를 포함할 수 있으며, 펌웨어 K에 대해 펌웨어 업데이트를 수행하기 위해 계획된 업데이트된 버전 파라미터(예: 펌웨어 버전 정보 4 및 펌웨어 해시 값 4)를 더 포함될 수 있다. 이 경우, 계약 노드는 펌웨어 버전 업데이트 기록 표로부터 각각의 펌웨어 버전 업데이트 기록에서의 제1 버전 파라미터(즉, 표 1에 나타낸 제1 버전 파라미터 A1 및 제1 버전 파라미터 B1)를 획득하고, 두 개의 제1 버전 파라미터에 따라 업데이트된 버전 파라미터에 대해 롤백 검출을 수행할 수 있다. 두 개의 제1 버전 파라미터가 모두 업데이트된 버전 파라미터와 다르면, 버전 롤백이 존재하지 않는다 것으로 결정될 수 있다. 그렇지 않고, 두 개의 제1 버전 파라미터 중 어느 하나가 업데이트된 버전 파라미터와 동일하면, 버전 롤백이 존재하는 것으로 결정될 수 있다.
제1 버전 파라미터가 업데이트된 버전 파라미터와 동일한지의 여부를 판정하는 경우, 업데이트된 버전 파라미터에 있는 업데이트된 버전 정보와 업데이트된 버전 해시 값은 각각 제1 버전 파라미터의 펌웨어 버전 파라미터에 있는 펌웨어 버전 정보와 펌웨어 버전 해시 값과 비교됨을 이해해야 한다. 예를 들어, 업데이트된 버전 파라미터에서의 업데이트된 버전 정보는 제1 버전 파라미터 B1의 펌웨어 버전 정보 2와 비교될 수 있고, 업데이트된 버전 파라미터에서의 업데이트된 버전 해시 값은 제1 버전 파라미터 B1의 펌웨어 해시 값 2와 비교될 수 있다. 따라서, 업데이트된 버전 정보(즉, 펌웨어 버전 정보 4)가 표 1에서의 펌웨어 버전 정보 2와 동일하고 업데이트된 버전 해시 값(즉, 펌웨어 해시 값 4)이 표 1에서의 펌웨어 해시 값 2와 동일한 경우, 버전 롤백이 존재하는 것으로 결정될 수 있다.
펌웨어 버전 발표 기록의 제1 버전 파라미터를 사용하여, 업데이트된 버전 파라미터에 대해 롤백 검출을 수행하는 경우, 펌웨어 업데이트 요청에서 운영 버전 파라미터를 포함하는 펌웨어 버전 업데이트 기록(즉, 펌웨어 버전 업데이트 기록 B)이, 펌웨어 버전 업데이트 기록 B에서의 제1 버전 파라미터(즉, 표 1의 제1 버전 파라미터 B1)에 따라, 업데이트된 버전 파라미터에 대한 롤백 검출을 수행하기 위해, 순회에 의해 순차적으로 더 먼저 발견될 수 있음을 이해해야 한다. 제1 버전 파라미터 B1에 있는 펌웨어 버전 정보 2와 펌웨어 버전 해시 값 2가 업데이트된 버전 파라미터에 있는 펌웨어 버전 정보 4와 펌웨어 버전 해시 값 4와 각각 다르면, 이전 블록에서의 펌웨어 버전 업데이트 기록은, 제1 서버 노드에서 펌웨어 K와 연관된 모든 제1 블록의 버전 업데이트 기록중 어느 것도 업데이트된 버전 파라미터와 동일한 제1 버전 파라미터를 포함하지 않는 것으로 결정되고, 버전 롤백이 존재하지 않는다고 결정될 수 있을 때까지, 계속 검색될 수 있다.
무효한 업데이트 요청은, 실행 노드가 제1 서버 노드의 버전 정보에 대한 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용된다. 계약 노드가 펌웨어 K의 펌웨어 버전 업데이트 기록으로부터 대응하는 업데이트된 버전 파라미터를 발견하면, 버전 롤백이 존재한다고 결정함을 알 수 있다, 즉, 실행 노드가 업데이트된 버전 파라미터를 사용하여 펌웨어 K에 대해 펌웨어 업데이터를 수행하였다. 이 경우, 계약 노드는 펌웨어 K에 대한 펌웨어 업데이트 작업을 무효한 작업의 경우로 간주한다. 다시 말해, 계약 노드는 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정할 수 있다. 본 개시의 일 실시예에서, 표 1의 모든 제1 버전 파라미터가 업데이트된 버전 파라미터와 다른 것으로 검출되면, 버전 롤백이 존재하지 않는 것으로 결정된다. 즉, 펌웨어 K의 버전 정보에 대한 펌웨어 업데이트 수행에 현재 사용되는 업데이트된 버전 파라미터가 펌웨어 K에 대한 펌웨어 업데이트 수행에 사용되지 않았다고 결정하는 경우, 계약 노드는 다음에 업데이트된 버전 파라미터 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청의 유효성을 추가로 결정할 수 있다.
마찬가지로, 펌웨어 버전 발표 기록이 업데이트된 버전 파라미터를 포함하면, 업데이트된 버전 파라미터에서의 펌웨어 버전 정보가 최신 발표된 펌웨어 버전 발표 파라미터에서의 최신 발표된 펌웨어 버전 정보인지의 여부가 추가로 판정되어야 한다. 업데이트된 버전 파라미터에서의 펌웨어 버전 정보가 최신 발표된 펌웨어 버전 발표 파라미터에서의 최신 발표된 펌웨어 버전 정보인 것으로 판정되면, 그 둘의 해시 값이 일치하는 경우 계약 검출이 성공한 것으로 결정될 수 있다. 즉, 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정된다. 그렇지 않으면, 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정된다. 이 경우, 계약 노드는 무효한 펌웨어 업데이트 요청을 거절한다. 본 개시의 일 실시예에서, 업데이트된 버전 정보가 최신 펌웨어 버전 정보가 아니면, 업데이트된 버전 파라미터를 사용하여 펌웨어 업데이트를 수행한 M개의 제2 서버 노드가 블록체인에서 검색되어야 하며, M개의 제2 서버 노드의 펌웨어 버전 업데이트 정보가 더 획득될 수 있다. M개의 제2 서버 노드의 버전 업데이트 행위 정보에서의 제2 버전 파라미터가 모두 운영 버전 파라미터를 포함함을 검출한 것에 응답하여, 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정된다. 그렇지 않으면, 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정된다.
본 개시의 일 실시예에서, 업데이트된 버전 정보이고 제1 서버 노드에서의 타깃 펌웨어를 업데이트해야 하는 업데이트된 버전 파라미터가 이미 블록체인에 존재하지만, 최신 펌웨어 버전 정보가 아니면, 각각의 제2 서버 노드는 획득된 M개의 제2 서버 노드에서 제1 서버 노드와 동일한 업데이트 방식을 채택하는지의 여부(즉, 동일한 운영 버전 파라미터 및 동일한 업데이트된 버전 파라미터가 필요함)가 검출되어야 한다. 각각의 제2 서버 노드가 제1 서버 노드와 동일한 업데이트 방식을 채택하는 것으로 결정하면, 펌웨어 업데이트 요청은 유효한 업데이트 요청인 것으로 결정될 수 있다.
본 개시의 일 실시예에서, 제1 서버 노드에 대한, 실행 노드에 의해 송신되는 펌웨어 업데이트 요청을 수신하는 경우, 제1 단말기는 지능형 계약을 호출하여 실행 노드에 의해 개시된 펌웨어 업데이트 요청에 대해 지능형 업데이트 관리 제어를 수행할 수 있어, 펌웨어 업데이트의 보안성을 보장할 수 있다. 펌웨어 업데이트 요청은 제1 서버 노드의 펌웨어를 업데이트하기 위해 계획된 업데이트된 버전 파라미터를 포함할 수 있다. 또한, 계약 노드는, 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하여, 획득한 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청에서의 업데이트된 버전 파라미터에 대해 계약 검출을 수행하고, 계약 검출 결과를 충족하는 펌웨어 업데이트 요청은 유효한 업데이트 요청인 것으로 결정할 수 있다. 그렇지 않으면, 계약 검출 결과를 충족하지 않는 펌웨어 업데이트 요청은 무효한 업데이트 요청으로 결정될 수 있다. 제1 서버 노드의 최하위 레벨에서 펌웨어에 대해 계약 노드에 의해 수행되는 모든 업데이트 작업에 대해, 지능형 계약을 사용하여 유효한 펌웨어 업데이트 작업 또는 무효한 펌웨어 업데이트 작업을 효과적으로 구분하여, 펌웨어 업데이트의 신뢰성을 향상시킬 수 있음을 알 수 있다.
또한, 도 5는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 다른 데이터 처리 방법의 개략 흐름도이다. 이 데이터 처리 방법은 계약 노드의 역할을 하는 전자 기기에 적용할 수 있으며 다음 단계를 포함될 수 있다.
단계 S201. 실행 노드에 의해 송신되는 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신한다.
펌웨어 업데이트 요청은 적어도 제1 서버 노드의 업데이트된 버전 파라미터를 포함한다.
단계 S202. 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 지능형 계약에 기초한 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하며, 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 따라 블록체인상의 발표 노드에 의해 결정된다.
구체적으로, 지능형 계약이 호출되고 블록체인에서의 제1 서버 노드의 블록체인 주소가 획득되고, 블록체인 주소는 제1 서버 노드의 공개 키 정보에 따라 해시 계산이 수행된 후 블록체인에 의해 고유하게(uniquely) 결정되며; 제1 서버 노드와 연관된 제1 블록 및 제2 블록이 블록체인 주소에 기초하여 블록체인으로부터 획득되고; 제1 버전 파라미터와 제2 버전 파라미터를 포함하는 이력 버전 업데이트 행위 정보는 제1 블록에서의 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록으로서 결정되고, 제2 버전 파라미터는 제1 버전 파라이터에 대한 펌웨어 업데이트가 수행된 후 획득된 버전 파라미터이며; 제1 서버 노드와 연관된 이력 버전 발표 행위 정보는 제2 블록에서의 펌웨어 버전 발표 기록으로서 결정된다.
단계 S203. 펌웨어 버전 업데이트 기록에서의 제1 버전 파라미터에 기초하여, 업데이트된 버전 파라미터에 대한 롤백 검출을 수행한다.
구체적으로, 계약 노드는 롤백 검출 결과에 따라, S203 단계를 수행한 후 S204 단계 또는 S205 단계를 수행할지의 여부를 판정할 수 있다.
단계 S204. 제1 버전 파라미터가 업데이트된 버전 파라미터와 동일함을 검출한 것에 응답하여, 버전 롤백이 존재한다고 결정하고, 펌웨어 업데이트 요청이 무효한 업데이트 요청리라고 결정한다.
무효한 업데이트 요청은 실행 노드가 제1 서버 노드의 버전 정보에 대한 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용된다. 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정한 후, 계약 노드는 단계 S207 및 단계 S208을 수행하기 위해 전환할 수 있음을 이해해야 한다.
단계 S205. 제1 버전 파라미터가 업데이트된 버전 파라미터와 다름을 검출한 것에 응답하여, 버전 롤백이 존재하지 않는다고 결정하고, 업데이트된 버전 파라미터 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청의 유효성을 결정한다.
구체적으로, 펌웨어 업데이트 요청은 제1 서버 노드의 운영 버전 파라미터를 더 포함될 수 있다. 제1 버전 발표 행위 정보는 펌웨어 버전 발표 기록과 연관된 이력 버전 발표 행위 정보로부터 획득되며, 제1 버전 발표 행위 정보는 이력 버전 발표 행위 정보에서 최신 버전 발표 타임스탬프를 갖는 버전 발표 행위 정보이고; 제1 버전 발표 행위 정보가 업데이트된 버전 파라미터를 포함하는 경우 펌웨어 업데이트 요청은 유효한 업데이트 요청인 것으로 결정된다. 본 개시 내용의 일 실시예에서, 제1 버전 발표 행위 정보가 업데이트된 버전 파라미터를 포함하지 않고, 이력 버전 발표 행위 정보에서의 제2 버전 발표 행위 정보가 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여, 업데이트된 버전 파라미터를 사용하여 펌웨어 업데이트가 이미 수행된 M개의 제2 서버 노드가 블록체인에서 검색되며, M은 2보다 큰 양의 정수이다. 또한, M개의 제2 서버 노드의 버전 업데이트 행위 정보가 획득된다. M개의 제2 서버 노드의 버전 업데이트 행위 정보가 운영 버전 파라미터를 포함하는 경우, 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정된다. 본 개시의 일 실시예에서, M개의 제2 서버 노드의 버전 업데이트 행위 정보가 운영 버전 파라미터의 버전 업데이트 행위 정보를 포함하지 않는 경우, 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정한다.
이해의 편의를 위해, 또한, 도 6은 본 개시의 일 실시예에 따른 버전 발표 행위 정보를 획득하는 개략도이다. 도 6에 도시된 바와 같이, 계약 노드 1은 도 6에 도시된 블록체인으로부터 펌웨어 K의 버전 발표 행위 정보를 획득될 수 있고, 버전 발표 행위 정보는 제1 버전 발표 행위 정보 및 제2 버전 발표 행위 정보를 포함할 수 있다. 도 6에 도시된 업데이트된 버전 정보 1이 체인상에 존재하는지의 여부를 신속하게 판정하기 위해, 업데이트된 버전 파라미터에서의 업데이트된 버전 정보 1은 모든 버전 발표 행위 정보의 펌웨어 버전 발표 정보와 비교됨을 이해해야 한다. 업데이트된 버전 정보 1이 체인상에 존재한다고 판정되면, 업데이트된 버전 정보 1이 최신 발표된 펌웨어 버전 발표 정보인지의 여부가 추가로 판정될 수 있다. 업데이트가 요청된 버전이 최신 버전이면, 업데이트된 버전 정보의 해시 값은 최신 발표된 펌웨어 버전 발표 정보의 해시 값과 직접 비교될 수 있음을 이해해야 한다. 업데이트된 버전 정보의 해시 값이 최신 발표된 펌웨어 버전 발표 정보의 해시 값과 동일하면, 즉, 펌웨어 버전의 해시 값이 일치하는 것으로 결정되면, 계약 검출을 통해, 단계 S201에서 실행 노드에 의해 송신된 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정될 수 있다. 본 개시의 일 실시예에서, 업데이트된 버전 정보의 해시 값이 최신 발표된 펌웨어 버전 발표 정보의 해시 값과 다른 경우, 계약 검출은 실패한 것으로 결정되고, 단계 S207 및 단계 S208을 수행하기 위해 전환된다.
제1 버전 발표 행위 정보는 제1 서버 노드의 블록체인 주소에 기초하여 블록체인으로부터 계약 노드 1에 의해 발견되는, 펌웨어 K의 최신 발표 상태이다. 이 경우, 제1 버전 발표 행위 정보는 펌웨어 K의 이력 버전 발표 행위 정보에서 최신 버전 발표 타임스탬프를 갖는 버전 발표 행위 정보일 수 있다. 따라서, 본 개시의 일 실시예에서, 실행 노드가 업데이트를 요청하는 버전(즉, 업데이트된 버전 정보 1)이 최신 버전인지의 여부가 제1 버전 발표 행위 정보를 사용하여 신속하게 판정될 수 있다.
도 6에 도시된 바와 같이, 업데이트가 요청되는 버전이 최신 버전이 아닌 것으로 판정되는 경우, 업데이트된 버전 정보 1을 사용하여 펌웨어 업데이트가 이미 수행된 M개의 다른 서버 노드가 획득될 수 있으며, M개의 다른 서버 노드는 각각 제2 서버 노드로 지칭될 수 있음을 이해해야 한다. 이 경우, 계약 노드는 대응하는 제2 서버 노드와 연관된 펌웨어 버전 업데이트 기록을, 각각의 제2 서버 노드의 블록체인 주소에 기초하여, 도 6에 도시된 블록체인 네트워크에 개별적으로 조회할 수 있다, 즉 M개의 제2 서버 노드의 버전 업데이트 행위 정보가 획득될 수 있다.
M개의 제2 서버 노드의 버전 업데이트 행위 정보가 운영 버전 파라미터를 포함함을 검출한 것에 응답하여, 펌웨어 업데이트 요청이 유효한 업데이트 요청인 것으로 결정됨을 이해해야 한다. 즉, M개의 제2 서버 노드가 펌웨어 업데이트 방식으로 펌웨어 K를 업데이트했다고 결정한 경우, 계약 노드는 실행 노드가 동일한 펌웨어 업데이트 방식으로 제1 서버 노드에서의 펌웨어 K에 대한 펌웨어 업데이트를 수행하는 것을 허용할 수 있다. 예를 들어, M개의 제2 서버 노드가 현재 운영 제1 펌웨어 버전 정보에서, 업데이트가 요청된 제2 펌웨어 버전 정보로 업데이트되는 경우, 실행 노드는 제1 서버 노드의 펌웨어 K의 펌웨어 버전 정보를 제1 펌웨어 버전 정보에서 제2 펌웨어 버전 정보로 업데이트할 수 있다.
이를 고려하여, 본 개시의 일 실시예에서, 동일 기업의 인트라넷 환경에서, 불법 공격자는 적은 수의 기계(즉, 제1 서버 노드)을 포획하고 또한 제1 서버 노드의 펌웨어에 대해 업데이트 작업을 수행될 수 있다. 그러나 제1 서버 노드에 대한 업데이트 작업은 펌웨어 업데이트 방식으로 대부분(즉, M개)의 다른 기계(즉, 제2 서버 노드)의 업데이트 작업과 비교되며, 업데이트 작업은, 제1 서버 노드에 대한 업데이트 작업이 대부분의 다른 기계의 업데이트 작업과 일치하지 않는 것으로 결정되는 경우, 효과적으로 무효한 작업으로 간주될 수 있다. 따라서, 무효한 작업에 대응하는 제1 서버 노드는 대규모 서버 클러스터에서 비정상 노드로서 빠르게 결정될 수 있다.
도 5에 도시된 바와 같이, 단계 S205를 수행한 후, 계약 노드는 펌웨어 업데이트 요청이 유효한 업데이트 요청인 경우로 결정되는 경우 단계 S206을 추가로 수행할 수 있다. 본 개시의 일 실시예에서, 계약 노드는 펌웨어 업데이트 요청이 무효한 업데이트 요청인 것으로 결정되는 경우 단계 S207 및 단계 S208을 추가로 수행될 수 있다.
단계 S206. 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정한 것에 응답하여, 제1 서버 노드에 대해 펌웨어 업데이트를 수행하는 데 사용되는 피드백 정보를 실행 노드에 회신하고, 피드백 정보는 제1 서버 노드의 펌웨어 버전 정보를 운영 버전 파라미터에서의 운영 버전 정보로부터 갱신된 버전 파라미터에서의 갱신된 버전 정보로 업데이트하도록 실행 노드에 명령하는 데 사용된다.
단계 S207. 펌웨어 업데이트 요청이 무효한 업데이트 요청임을 검출한 것에 응답하여, 계약 실행이 실패한 것으로 결정하고, 무효한 업데이트 요청을 실행 노드에 회신한다.
단계 S208. 제1 서버 노드에 대한, 실행 노드에 의해 전송되는 다음 펌웨어 업데이트 요청이 수신되는 경우, 다음 펌웨어 업데이트 요청을 무효한 업데이트 요청으로 식별하며, 무효한 업데이트 요청은 보안 감사 중에 실행 노드에 대한 경보 정보를 생성하도록 발표 노드에 명령하는 데 사용된다.
본 개시의 일 실시예에서, 단계 S206을 수행한 후, 계약 노드는 다음 단계: 제1 서버 노드가 업데이트된 버전 파라미터에 서명한 후 획득된 확인 정보를 수신하는 단계 - 확인 정보는 실행 노드가 제1 서버 노드의 펌웨어 버전 정보를 업데이트 하였음을 지시함 -; 제1 서버 노드의 공개 키 정보를 사용하여 확인 정보에 대해 서명 검증을 수행하고, 서명 검증이 성공한 경우, 지능형 계약의 호출이 완료된 것으로 결정하는 단계; 및 확인 정보 및 펌웨어 업데이트 요청에 기초하여 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하고, 제1 서버 노드의 블록체인 주소에 기초하여, 업데이트된 펌웨어 버전 업데이트 기록을 블록체인에 기입하는 단계를 추가로 수행할 수 있다.
이해의 편의를 위해, 또한, 도 7은 본 개시의 일 실시예에 따른 펌웨어 버전 업데이트 기록을 구축하는 개략도이다. 도 7에 도시된 바와 같이, 펌웨어 버전 업데이트 기록 4는 입력 정보와 출력 정보에 의해 형성된다. 도 7에 도시된 바와 같이, 입력 정보는 계약 노드에 의한 지능형 계약을 실행하는 프로세스에 관여한 노드 A에 의해 제공되는 운영 버전 파라미터 및 업데이트된 버전 파라미터일 수 있다. 따라서, 실행 노드 A가 계약 노드에 펌웨어 업데이트 요청을 송신하기 전에, 실행 노드 A는 제1 서버 노드의 펌웨어를 업데이트하기 위해 현재 계획된 업데이트된 버전 파라미터 및 제1 서버 노드에 의해 현재 운영되는 운영 버전 파라미터를 제공해야 한다. 이 경우, 제1 서버 노드는 펌웨어 K의 운영 버전 파라미터(즉, 도 7에 도시된 구 펌웨어 버전 V1 및 구 펌웨어 해시 값 H1) 및 업데이트된 버전 파라미터(즉, 도 7에 도시된 신 펌웨어 버전 V2 및 펌웨어 K의 신 펌웨어 해시 값 H2)를 입력 정보로 지칭할 수 있다. 본 개시의 일 실시예에서, 실행 노드 A는 입력 정보를 획득하는 경우, 실행 노드 A의 개인 키를 사용하여 입력 정보에 서명하여, 제1 서명 정보를 획득하고, 실행 노드 A에 의한 서명 후 획득된 제1 서명 정보와 함께 실행 노드 A의 공개 키를 펌웨어 업데이트 요청에 추가하고, 그 펌웨어 업데이트 요청을 계약 노드에 송신한다. 따라서 지능형 계약을 호출하는 프로세스에서, 계약 노드는 실행 노드 A의 공개 키를 사용하여 제1 서명 정보에 대해 서명 검증을 수행하여, 펌웨어 업데이트 요청으로부터 입력 파라미터(즉, 입력 정보)를 획득할 수 있다, 즉, 펌웨어 K의 업데이트된 버전 파라미터와 운영 버전 파라미터를 획득할 수 있다.
도 7에 도시된 바와 같이, 출력 정보는 서버 노드 B(즉, 제1 서버 노드)에 의해 취득 및 보고되는 신 운영 버전 파라미터를 포함할 수 있으며, 신 운영 버전 파라미터는 업데이트된 버전 파라미터를 사용하여 운영 버전 파라미터에 대해 펌웨어 업데이트를 수행함으로써 획득될 수 있다. 이 경우, 제1 서버 노드에서 운영되는 신 운영 버전 정보는 도 7에 도시된, 신 펌웨어 버전이 V2이고 신 펌웨어 해시 값이 H2인 업데이트된 버전 파라미터일 수 있다. 도 7에 도시된 바와 같이, 계약 노드에 확인 정보를 전송하기 전에, 제1 서버 노드는 현재 취득한 신 운영 버전 파라미터를 출력 정보로서 사용하고, 서버 노드 B의 개인 키를 사용하여 출력 정보에 서명하여, 제2 서명 정보를 획득하고, 제2 서명 정보를 서버 노드 B의 공개 키와 함께 출력 정보에 추가하고, 확인 정보를 계약 노드에 전송할 수 있다. 따라서, 계약 노드는 서버 노드 B에 의해 전송되는 확인 정보를 수신한 후, 서버 노드 B의 공개 키를 사용하여 확인 정보에 대해 서명 검증을 수행하여, 서버 노드 B에 의해 제공하는 출력 정보를 획득할 수 있다, 즉, 서버 노드 B에 의해 제공되는 신 운영 버전 파라미터를 획득할 수 있다.
또한, 계약 노드는 도 7에 도시된 입력 정보 및 출력 정보에 기초하여, 제1 서버 노드와 연관된 타깃 버전 업데이트 행위 정보를 결정하고, 타깃 버전 업데이트 행위 정보에 기초하여 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트한다. 즉, 도 7에 도시된 바와 같이, 계약 노드는 입력 정보, 입력 정보에 대한 실행 노드 A의 서명, 실행 노드 A의 공개 키, 출력 정보, 출력 정보에 대한 서버 노드 B의 서명 및 서버 노드의 공개 키에 따라 도 7에 도시된 펌웨어 버전 업데이트 기록 4를 생성하고, 펌웨어 버전 업데이트 기록 4를 도 7에 도시된 블록체인 20에 기입할 수 있다. 본 개시 내용의 일 실시예에서, 도 7에 도시된 블록체인 20은, 도 6에 대응하는 전술한 실시예에서의 블록체인 10은 동일한 블록체인 네트워크에 속할 수 있으며, 이는 여기서 한정되지 않는다.
본 개시의 일 실시예에서, 이해의 편의를 위해, 펌웨어 버전 업데이트 기록 4를 포함하는 블록(즉, 블록 N+3)은 도 3에 도시된 중첩 해시 체인의 구조에 기초하여 블록 N+2 뒤에 추가될 수 있다. 계약 노드는 펌웨어 버전 업데이트 기록 4의 해시 값을 계산할 수 있다. 블록 N+2가 생성된 후 블록 N+3이 생성되지 전의 이 기간에 제1 서버 노드의 다른 펌웨어에 대한 업데이트 작업이 없으면, 펌웨어 버전 업데이트 기록 3의 해시 값이 블록 N+3의 머클 트리 루트로서 사용될 수 있고, 이전 블록의 해시 값이 블록 N+3의 블록 헤더에서 부모 블록 해시 값으로 사용될 수 있으므로, 블록 N+3은 블록 N+2 뒤의 동일한 블록체인에 기입될 수 있다. 본 개시의 일 실시예에서, 새로운 블록이 생성되는 경우, 새로 생성된 블록은 여전히 전체 네트워크에 브로드캐스팅되어야 하므로, 다른 노드는 새로운 블록을 발견하고 컨센서스에 도달한 후, 블록 N+3이 N+2 블록이 위치한 블록체인에 기입되는 것으로 결정하여, 순차적 저장을 수행한다.
이해의 편의를 위해, 또한, 도 8은 본 개시의 일 실시예에 따른 발표 노드를 사용하여 보안 감사를 수행하는 개략도이다. 도 8에 도시된 블록체인 30은 도 7에 도시된 펌웨어 버전 업데이트 기록 4를 포함하는 블록 N+3을 도 3에 대응하는 전술한 실시예에서의 중첩된 해시 체인에 기입함으로써 형성된 블록체인일 수 있다.
본 개시의 일 실시예에서, 모든 업데이트 결과(즉, 펌웨어 버전 업데이트 기록 4)는 블록체인상에 기록되고, 변조가 불가능하고 쉽게 손실되지 않는 분산 데이터 참조가 보안 상태의 후속 감사를 위해 제공될 수 있어, 모든 기계의 보안 상태에 대한 감사를 구현할 수 있다. 보안 상태에 대한 감사 시에, 발표 노드는 감사 대상 기계로부터 판독된 펌웨어 데이터를 자동으로 취득 및 분석하고, 온 체인 펌웨어 정보가 오프 체인 펌웨어 정보와 일치하지 않는다고 결정한 경우 비정상에 대한 경보를 빠르게 제공할 수 있어, 진보된 위협 침입 수단을 검출하는 능력을 효과적으로 향상시키고 기업 인트라넷의 보안성을 크게 향상시킨다.
본 개시의 일 실시예에서, 실행 노드가 제1 서버 노드의 펌웨어에 대한 업데이트 작업을 완료한 후, 블록체인상의 다른 노드(예: 취득 노드(acquisition node)는 오프 체인의 제1 서버 노드에서 펌웨어 정보를 계속하여 취득하도록 구성될 수 있다. 취득 빈도는 제1 서버 노드가 재시작될 때마다 제1 서버 노드의 펌웨어 정보의 취득이 시작되는 것일 수 있다. 대안으로, 본 개시의 일 실시예에서, 제1 서버 노드의 펌웨어 정보의 취득은 정기적으로 또는 주기적으로 시작될 수 있다. 취득 방식은 자동 취득 및 분석 도구(예: 균일한 확장 가능한 펌웨어 인터페이스 도구)의 사용으로 한정되지 않는다. 발표 노드는 블록체인상에 위치한 임의의 서버 노드의 보안 상태에 대해 보안 감사를 수행하여, 서버 노드의 온 체인 펌웨어 정보와 서버 노드의 오프 체인 펌웨어 정보를 비교함으로써 서버 노드의 보안 상태를 결정할 수 있다.
이해의 편의를 위해, 본 개시의 일 실시예에서, 서버 노드 중 하나의 서버 노드(즉, 도 1에 대응하는 전술한 실시예의 서버 노드(40a)가 제1 서버 노드로 사용됨)를 예로 사용하여, 발표 노드가 서버 노드(40a)(즉, 제1 서버 노드)에 대해 보안 감사를 수행하는 구체적인 구현 프로세스를 설명한다. 본 개시의 일 실시예에서, 대안으로, 발표 노드는 서버 노드(40a)로부터 서버 노드(40a)에서 현재 운영되는 펌웨어 정보를 정기적으로 또는 주기적으로 판독할 수 있으며, 현재 판독된 펌웨어 정보를 오프 체인 펌웨어 정보로 지칭할 수 있다.
취득 노드에 대해 설명하면, 취득 노드는 또한 서버 노드(40a)(즉, 제1 서버 노드)로부터 판독된 펌웨어 정보를 데이터 미들 플랫폼으로 다시 정기적으로 또는 주기적으로 송신할 수 있으며, 그러면 데이터 미들 플랫폼은 판독된 펌웨어 정보를 백그라운드로 송신할 수 있으므로, 판독된 펌웨어 정보가 백그라운드에서 스크리닝 및 필터링되어, 제1 서버 노드의 오프 체인 펌웨어 정보를 획득할 수 있다. 이러한 방식으로, 후속적으로 제1 서버 노드의 보안 상태에 대한 보안 감사를 수행해야 하는 경우, 발표 노드는 백그라운드로부터 제1 서버 노드의 오프 체인 펌웨어 정보를 획득할 수 있다.
또한, 발표 노드는 제1 서버 노드의 블록체인 주소에 기초하여 블록체인으로부터 최신 업데이트 상태를 추가로 획득할 수 있다, 즉, 펌웨어 갱신이 제1 서버 노드(즉, 도 8에 도시된 최신 타임스탬프를 갖는 블록 N+3에 위치한 펌웨어 버전 업데이트 기록 4)에서의 펌웨어에 대해 수행된 후 획득된 최신 펌웨어 버전 업데이트 기록을 발견할 수 있으므로, 펌웨어 버전 업데이트 기록 4에 기록된 제1 서버 노드의 펌웨어 정보(즉, 온 체인 펌웨어 정보)가 오프 체인 펌웨어 정보에 대한 비교 참조로서 사용될 수 있다. 따라서, 오프 체인 펌웨어 정보가 온 체인 펌웨어 정보와 일치하는 것으로 결정되는 경우, 제1 서버 노드에 대한 현재 보안 감사가 성공한 것으로 결정되므로, 정상 값이 제1 서버 노드가 속한 사용자 또는 단말기에 회신될 수 있다. 본 개시의 일 실시예에서, 비교를 통해 오프 체인 펌웨어 정보와 온 체인 펌웨어 정보가 일치하지 않는 것으로 결정되면, 이는 제1 서버 노드의 펌웨어 무결성 상태가 비정상임을 지시한다. 이 경우, 경보 정보가 이동단말기 또는 웹 단말기 경보 정보(워크시트 경보이라고도 함) 방식으로 제1 서버 노드가 속한 관리자 또는 사용자에게 회신된다.
워크시트 정보(즉, 경보 정보)는 다음을 포함하지만 이에 한정되는 것은 아니다: (1) 이벤트 시간(즉, 제1 서버 노드에 대해 보안 감사를 수행한 시간); (2) 서비스 정보, 예를 들어 기계 담당자, 소속 구역, 소속 서비스, 대응하는 IP 및 대응하는 공개 키; (3) 보고된 펌웨어 버전 및 펌웨어 해시; (4) 체인상에 기록된 기계 정보(예: 기계의 공개 키, 펌웨어 버전 및 펌웨어 해시); (5) 업데이트 시간, 업데이트 실행자에 대한 정보 등을 포함하는 이전의 업데이트된 이벤트.
워크시트 정보가 침입을 받는 위험 상태에 있다고 결정하면, 비상 대응 프로세스가 시작될 수 있음을 이해해야 한다. 예를 들어, 네트워크 분리가 비정상적인 기계에 대해 수행될 수 있고 세부 보안 감사를 추가로 수행될 수 있다.
본 개시의 일 실시예에서, 제1 서버 노드에 대한 실행 노드에 의해 송신되는 펌 웨어 업데이트 요청을 수신하는 경우, 제1 단말기는 지능형 계약을 호출하여 실행 노드에 의해 개시된 펌웨어 업데이트 요청에 대한 지능형 업데이트 관리 제어를 수행함으로써, 펌웨어 업데이트의 보안성을 보장한다. 펌웨어 업데이트 요청은 제1 서버 노드의 펌웨어를 업데이트하기 위해 계획된 업데이트된 버전 파라미터를 포함할 수 있다. 또한, 계약 노드는 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하여, 획득한 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청에서의 업데이트된 버전 파라미터에 대한 계약 감사를 수행하고, 계약 검출 결과를 충족하는 펌웨어 업데이트는 유효한 업데이트 요청인 것으로 결정할 수 있다. 그렇지 않으면, 계약 검출 결과를 충족하지 않는 펌웨어 업데이트는 무효한 업데이트 요청인 것으로 결정할 수 있다. 제1 서버 노드의 최하위 레벨에서 펌웨어에 대해 계약 노드에 의해 수행되는 모든 업데이트 작업에 대해, 유효한 펌웨어 업데이트 작업 또는 무효한 펌웨어 업데이트 작업이 능능형 계약을 사용함으로써 효과적으로 구분되어, 펌웨어 업데이트의 신뢰성을 향샹시킬 수 있다.
또한, 도 9는 본 개시의 일 실시예에 따른 지능형 계약에 기초한 데이터 처리 장치의 개략 구성도이다. 데이터 처리 장치(1)는 도 1에 대응하는 전술한 실시예에서의 계약 노드(20a)에 적용될 수 있다. 도 9에 도시된 바와 같이, 데이터 처리 장치(1)는 요청 수신 모듈(10), 계약 호출 모듈(20) 및 유효성 결정 모듈(30)을 포함될 수 있다. 데이터 처리 장치(1)는 확인 수신 모듈(40), 서명 검증 모듈(50), 및 기록 업데이트 모듈(60)을 더 포함할 수 있다.
요청 수신 모듈(10)은 실행 노드에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하도록 구성되며, 펌웨어 업데이트 요청은 적어도 제1 서버 노드의 업데이트된 버전 파라미터를 포함한다.
계약 호출 모듈(20)은 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 지능형 계약에 기초하여 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하도록 구성되며, 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 블록체인상의 발표 노드에 의해 결정된다.
계약 호출 모듈(20)은 주소 획득 유닛(201), 블록 획득 유닛(202), 업데이트 기록 결정 유닛(203) 및 발표 기록 결정 유닛(204)을 포함한다.
주소 획득 유닛(201)은 지능형 계약을 호출하여 블록체인에서의 제1 서버 노드의 블록체인 주소를 획득하도록 구성되며, 블록체인 주소는, 블록체인에 의해 제1 서버 노드의 공개 키 정보에 따라 해시 계산이 수행된 후에 고유하게 결정된다.
블록 획득 유닛(202)은 블록체인으로부터의 블록체인 주소에 기초하여, 제1 서버 노드와 연관된 제1 블록 및 제2 블록을 획득하도록 구성된다.
업데이트 기록 결정 유닛(203)은 제1 블록으로부터의 이력 버전 업데이트 행위 정보를, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록으로서 결정하도록 구성된다. 이력 버전 업데이트 행위 정보는 제1 버전 파라미터 및 제2 버전 파라미터를 포함하고, 제2 버전 파라미터는 제1 버전 파라미터에 대해 펌웨어 업데이트가 수행된 후에 획득된 버전 파라미터이다.
발표 기록 결정 유닛(204)은 펌웨어 버전 발표 기록이 제2 블록으로부터의 제1 서버 노드와 연관된 이력 버전 발표 행위 정보인 것으로 결정하도록 구성된다.
주소 획득 유닛(201), 블록 획득 유닛(202), 업데이트 기록 결정 유닛(203) 및 발표 기록 결정 유닛(204)의 구체적인 구현에 대해서는, 도 2에 대응하는 실시예에서의 단계 S102에 대한 설명을 참조할 수 있으며, 세부 사항은 여기서 다시 설명하지 않는다.
유효성 결정 모듈(30)은 펌웨어 버전 업데이트 기록, 펌웨어 버전 발표 기록 및 업데이트된 버전 파라미터에 따라 펌웨어 업데이트 요청의 유효성을 결정하도록 구성된다.
유효성 결정 모듈(30)은 롤백 검출 유닛(301), 무효성 결정 유닛(302) 및 유효성 결정 유닛(303)을 포함한다.
롤백 검출 유닛(301)은 펌웨어 버전 업데이트 기록에서의 제1 버전 파라미터에 기초하여 업데이트된 버전 파라미터에 대해 롤백 검출을 수행하도록 구성된다.
무효성 결정 유닛(302)은 제1 버전 파라미터가 업데이트된 버전 파라미터와 동일함을 검출한 것에 응답하여, 버전 롤백이 존재한다고 결정하고, 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정하도록 구성되며, 무효한 업데이트 요청은 실행 노드가 제1 서버 노드의 버전 정보에 대해 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용된다.
유효성 결정 유닛(303)은 제1 버전 파라미터가 업데이트된 버전 파라미터와 다름을 검출한 것에 응답하여, 버전 롤백이 존재하지 않는다고 결정하고, 업데이트된 버전 파라미터 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청의 유효성을 결정하도록 구성된다.
펌웨어 갱신 요청은 제1 서버 노드의 운영 버전 파라미터를 더 포함한다.
유효성 결정 유닛(303)은, 제1 발표 서브유닛(3031) 및 제1 결정 서브유닛(3032)을 더 포함한다. 유효성 결정 유닛은 노드 획득 서브유닛(3033), 행위 획득 서브유닛(3034), 제2 결정 서브유닛(3035), 제3 결정 서브유닛(3036), 피드백 서브유닛(3037), 회신 요청 서브유닛(3038) 및 무효성 식별 서브유닛(3039)을 더 포함한다.
제1 발표 서브유닛(3031)은 펌웨어 버전 발표 기록과 연관된 이력 버전 발표 행위 정보로부터 제1 버전 발표 행위 정보를 획득하도록 구성되며, 제1 버전 발표 행위 정보는 기록 버전 발표 행위 정보에서 최신 버전 발표 타임스탬프를 갖는 버전 발표 행위 정보이다.
제1 결정 서브유닛(3032)은 제1 버전 발표 행위 정보가 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여, 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하도록 구성된다.
본 개시의 일 실시예에서, 노드 획득 서브유닛(3033)은 이력 버전 발표 행위 정보에서 제1 버전 발표 행위 정보는 업데이트된 버전 파라미터를 포함하지 않고, 제2 버전 발표 행위 정보는 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여, 업데이트된 버전 파라미터를 사용하여 펌웨어 업데이트가 수행되는 M개의 제2 서버 노드를 블록체인에서 검색하도록 구성되며, M은 2보다 큰 양의 정수이다.
행위 획득 서브유닛(3034)은 M개의 제2 서버 노드의 버전 업데이트 행위 정보를 획득하도록 구성된다.
제2 결정 서브유닛(3035)은 M개의 제2 서버 노드의 버전 업데이트 행위 정보가 운영 버전 파라미터를 포함함을 검출한 것에 응답하여 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하도록 구성된다.
제3 결정 서브유닛(3036)은 운영 버전 파라미터를 포함하지 않는 버전 업데이트 행위 정보가 M개의 제2 서버 노드의 버전 업데이트 행위 정보 중에 존재함을 검출한 것에 응답하여 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정하도록 구성된다.
본 개시의 일 실시예에서, 피드백 서브유닛(3037)은, 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정한 것에 응답하여, 제1 서버 노드에 대한 펌웨어 업데이트를 수행하기 위해 사용된 피드백 정보를 실행 노드에 회신하도록 구성되며, 피드백 정보는 서버 노드의 펌웨어 버전 정보를 운영 버전 파라미터에서의 운영 버전 정보로부터, 업데이트된 버전 파라미터에서의 업데이트된 버전 정보로 업데이트하도록 실행 노드에 명령하는 데 사용된다.
본 개시의 일 실시예에서, 요청 회신 서브유닛(3038)은, 펌웨어 업데이트 요청이 무효한 업데이트 요청임을 검출한 것에 응답하여, 계약 실행이 실패한 것으로 결정하고, 무효한 업데이트 요청을 실행 노드에 회신하도록 구성된다.
무효성 식별 서브유닛(3039)은, 제1 서버 노드에 대한 실행 노드에 의해 송신되는 다음 펌웨어 업데이트 요청이 수신되는 경우, 다음 펌웨어 업데이트 요청을 무효한 업데이트 요청인 것으로 식별하도록 구성되며, 무효한 업데이트 요청은 보안 감사 중에 실행 노드에 대한 경보 정보를 생성하도록 발표 노드에 명령하는 데 사용된다.
경보 정보는 블록체인으로부터 획득된 제1 서버 노드의 온 체인 업데이트 버전 파라미터와, 제1 서버 노드로부터 로컬로 취득되는 업데이트된 운영 버전 파라미터에 따라 보안 감사가 수행된 후에 발표 노드에 의해 획득된다.
제1 발표 서브유닛(3031), 제1 결정 서브유닛(3032), 노드 획득 서브유닛(3033), 행위 획득 서브유닛(3034), 제2 결정 서브유닛(3035), 제3 결정 서브유닛(3036), 피드백 서브유닛(3037), 요청 회신 서브유닛(3038) 및 무효성 식별 서브유닛(3039)의 구체적인 구현에 대해서는, 도 2에 대응하는 실시예의 단계 S103에 관한 설명을 참조할 수 있으며, 세부사항은 여기서 다시 설명하지 않는다.
롤백 검출 유닛(301), 무효성 결정 유닛(302), 유효성 결정 유닛(303)의 구체적인 구현에 대해서는, 도 3에 대응하는 실시예의 단계 S103에 관한 설명을 참조할 수 있으며, 세부사항은 여기서 다시 설명하지 않는다.
본 개시의 일 실시예에서, 확인 수신 모듈(40)은 제1 서버 노드가 업데이트된 버전 파라미터에 서명한 후 확인 정보를 수신하도록 구성되며, 확인 정보는 실행 노드가 제1 서버 노드의 펌웨어 버전 정보를 업데이트했음을 지시하는 데 사용된다.
서명 검증 모듈(50)은 제1 서버 노드의 공개 키 정보를 사용하여 확인 정보에 대해 서명 검증을 수행하고, 서명 검증이 성공하는 경우, 지능형 계약의 호출이 완료된 것으로 결정하도록 구성된다.
기록 업데이트 모듈(60)은 확인 정보 및 펌웨어 업데이트 요청에 기초하여 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하고, 업데이트된 펌웨어 버전 업데이트 기록을 제1 서버 노드의 블록체인 주소에 기초하여 블록체인에 기입하도록 구성된다.
기록 업데이트 모듈(60)은 제1 정보 결정 유닛(601), 제2 정보 결정 유닛(602), 업데이트 행위 결정 유닛(603) 및 기록 기입 유닛(604)을 포함한다
제1 정보 결정 유닛(601)은 펌웨어 업데이트 요청에 있는 업데이트된 버전 파라미터 및 운영 버전 파라미터를 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록을 구성하기 위한 입력 정보로서 사용하도록 구성된다.
제2 정보 결정 유닛(602)은 확인 정보에 포함된 업데이트된 버전 파라미터를 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록을 구성하기 위한 출력 정보로서 사용하도록 구성된다.
업데이트된 행위 결정 유닛(603)은 입력 정보 및 출력 정보에 기초하여, 제1 서버 노드와 연관된 타깃 버전 업데이트 행위 정보를 결정하고, 타깃 버전 업데이트 행위 정보에 기초하여 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하도록 구성된다.
기록 기입 유닛(604)은 업데이트된 펌웨어 버전 업데이트 기록을 제1 서버 노드의 블록체인 주소에 기초하여 블록체인에 기록하도록 구성된다.
제1 정보 결정 유닛(601), 제2 정보 결정 유닛(602), 업데이트된 행위 결정 유닛(603) 및 기록 기입 유닛(604)의 구체적인 구현에 대해서는, 도 2에 대응하는 실시예의 펌웨어 버전 업데이트에 대한 기록의 설명을 참조할 수 있으며, 세부사항은 여기서 다시 설명하지 않는다.
요청 수신 모듈(10), 계약 호출 모듈(20) 및 유효성 결정 모듈(30)의 구체적인 구현에 대해서는, 도 2에 대응하는 실시예의 단계 S101 ∼ 단계 S103에 대한 설명을 참조할 수 있으며, 세부사항은 여기서 다시 설명하지 않는다. 본 개시의 일 실시예에서, 확인 수신 모듈(40), 서명 검증 모듈(50) 및 기록 업데이트 모듈(60)의 구체적인 구현에 대해서는, 도 5에 대응하는 실시예의 단계 S201 ∼ 단계 S208에 대한 설명을 참조할 수 있으며, 세부사항은 여기서 다시 설명하지 않는다.
본 개시의 일 실시예에서, 제1 서버 노드에 대한 실행 노드에 의해 송신되는 펌웨어 업데이트 요청을 수신하는 경우, 제1 단말기는 지능형 계약을 호출하여 실행 노드에 의해 개시된 펌웨어 업데이트 요청에 대한 지능형 업데이트 관리 제어를 수행될 수 있어, 펌웨어 업데이트의 보안성을 보장한다. 펌웨어 업데이트 요청은 제1 서버 노드의 펌웨어를 업데이트하기 위해 계획된 업데이트된 버전 파라미터를 포함할 수 있다. 또한, 계약 노드는 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하여, 획득한 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록에 기초하여 펌웨어 업데이트 요청에서의 업데이트된 버전 파라미터에 대한 계약 검출을 수행하고, 계약 검출 결과를 충족하는 펌웨어 업데이트 요청은 유효한 업데이트 요청인 것으로 결정한다. 그렇지 않으면, 계약 검출 결과를 충족하지 않는 펌웨어 업데이트 요청은 무효한 업데이트 요청으로 결정될 수 있다. 제1 서버 노드의 최하위 레벨에서 펌웨어에 대해 계약 노드에 의해 수행되는 모든 업데이트 작업에 대해, 지능형 계약을 사용함으로써 유효한 펌웨어 업데이트 작업 또는 무효한 펌웨어 업데이트 작업을 효과적으로 구분하여, 펌웨어 업데이트의 신뢰성을 향상시킬 수 있다.
또한, 도 10은 본 개시의 일 실시예에 따른 노드 기기의 개략 구성도이다. 도 10에 도시된 바와 같이, 노드 기기(1000)는 도 1에 대응하는 전술한 실시예에서의 계약 노드(20a)에 적용될 수 있으며, 노드 기기(1000)는 프로세서(1001), 네트워크 인터페이스(1004), 메모리(1005), 사용자 인터페이스(1003) 및 하나 이상의 통신 버스(1002)를 포함할 수 있다. 통신 버스(1002)는 구성요소 간의 연결 및 통신을 구현하도록 구성된다. 사용자 인터페이스(1003)는 디스플레이 및 키보드를 포함할 수 있다. 사용자 인터페이스(1003)는 표준 유선 인터페이스 또는 무선 인터페이스를 더 포함할 수 있다. 본 개시의 일 실시예에서, 네트워크 인터페이스(1004)는 표준 유선 인터페이스 또는 무선 인터페이스(예: Wi-Fi 인터페이스)를 포함할 수 있다. 메모리(1005)는 고속 RAM일 수 있거나, 예를 들어, 하나 이상의 자기 디스크 메모리와 같은, 비휘발성 메모리일 수 있다. 본 개시의 일 실시예에서, 메모리(1005)는 대안으로 프로세서(1001)로부터 떨어져 위치한 하나 이상의 저장 기기일 수 있다. 도 10에 도시된 바와 같이, 컴퓨터 저장 매체로 사용되는 메모리(1005)는 운영 체제, 네트워크 통신 모듈, 사용자 인터페이스 모듈, 및 기기 제어 애플리케이션 프로그램을 포함할 수 있다.
노드 기기(1000)의 네트워크 인터페이스(1004)는 블록체인 내의 다른 노드 기기(예: 애플리케이션 서버)와 추가로 연결될 수 있고, 사용자 인터페이스(1003)는 디스플레이 및 키보드를 더 포함할 수 있다. 도 10에 도시된 노드 기기(1000)에서, 네트워크 인터페이스(1004)는 네트워크 통신 기능을 제공할 수 있다. 사용자 인터페이스(1003)는 주로 사용자에게 입력 인터페이스를 제공하도록 구성된다. 프로세서(1001)는 메모리(1005)에 저장된 애플리케이션 프로그램을 호출하여, 다음 작업:
제1 서버 노드에 대한 실행 노드에 의해 송신되는 펌웨어 업데이트 요청을 수신하는 작업 - 펌웨어 업데이트 요청은 적어도 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 지능형 계약에 기초하여 블록체인으로부터, 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 작업 - 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 블록체인상의 발표 노드에 의해 결정됨 -; 및
펌웨어 버전 업데이트 기록, 펌웨어 버전 발표 기록 및 업데이트된 버전 파라미터에 따라 펌웨어 업데이트 요청의 유효성을 결정하는 작업을 수행하도록 구성된다.
본 개시의 일 실시예에서 설명된 노드 기기(1000)는 전술한 대응하는 실시예에서의 지능형 계약에 기초한 데이터 처리 방법의 설명을 구현할 수 있으며, 또한 전술한 대응 실시예에서의 지능형 계약에 기초한 데이터 처리 장치 1의 설명을 구현할 수도 있다. 세부사항은 여기서 다시 설명하지 않는다. 또한, 동일한 방법을 사용하여 얻은 유익한 효과는 여기서 다시 설명하지 않는다.
또한, 본 개시의 일 실시예는 컴퓨터 저장 매체를 더 제공한다. 컴퓨터 기억 매체는 전술한 지능형 계약에 기초한 데이터 처리 장치 1에 의해 실행되는 컴퓨터 프로그램을 저장하고, 컴퓨터 프로그램은 프로그램 명령어를 포함한다. 프로그램 명령을 실행할 때, 프로세서는 전술한 대응하는 실시예에서의 지능형 계약에 기초한 데이터 처리 방법의 설명을 구현할 수 있다. 따라서 세부사항은 여기서 다시 설명하지 않는다. 또한, 동일한 방법을 사용하여 얻은 유익한 효과는 여기서 다시 설명하지 않는다. 본 개시의 컴퓨터 저장 매체의 실시예에 개시되지 않은 기술적 세부 사항은 본 발명의 방법 실시예의 설명을 참조한다.
당업자라면 전술한 실시예의 방법의 프로세스의 전부 또는 일부가 관련 하드웨어에 명령하는 컴퓨터 프로그램에 의해 구현될 수 있음을 이해할 수 있을 것이다. 프로그램은 컴퓨터로 판독 가능한 저장 매체에 저장될 수 있다. 프로그램 실행 시에, 전술한 방법 실시예의 프로세스가 포함될 수 있다. 전술한 저장 매체는 자기 디스크, 광 디스크, ROM(Read-Only Memory), RAM(Random Access Memory) 등일 수 있다.
이상에서 개시된 것은 단지 본 개시의 실시예의 예일 뿐이며, 본 개시의 보호 범위를 한정하려는 의도가 아님은 물론이다. 따라서, 본 개시의 청구범위에 따라 이루어진 동등한 변형은 본 개시의 범위 내에 속할 것이다.
Claims (15)
- 계약 노드(contract node)인 전자 기기에 의해 수행되는 지능형 계약에 기초한 데이터 처리 방법으로서,
실행 노드(execution node)에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하는 단계 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 단계 - 상기 펌웨어 버전 발표 기록은 컨센서스 메커니즘(consensus mechanism)에 기초하여 상기 블록체인상의 발표 노드(release node)에 의해 결정됨 -; 및
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하는 단계
를 포함하는 데이터 처리 방법. - 제1항에 있어서,
상기 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하는 단계는,
상기 지능형 계약을 호출하여 상기 블록체인에서의 상기 제1 서버 노드의 블록체인 주소를 획득하는 단계 - 상기 블록체인 주소는, 상기 블록체인에 의해 상기 제1 서버 노드의 공개 키 정보에 따라 해시 계산이 수행된 후에 고유하게 결정됨 -;
상기 블록체인으로부터의 상기 블록체인 주소에 기초하여, 상기 제1 서버 노드와 연관된 제1 블록 및 제2 블록을 획득하는 단계;
상기 제1 블록으로부터의 이력 버전 업데이트 행위 정보를 상기 제1 서버 노드와 연관된 상기 펌웨어 버전 업데이트 기록으로서 결정하는 단계 - 상기 이력 버전 업데이트 행위 정보는 제1 버전 파라미터 및 제2 버전 파라미터를 포함하고, 상기 제2 버전 파라미터는 상기 제1 버전 파라미터에 대해 펌웨어 업데이트가 수행된 후에 획득된 버전 파라미터임 -; 및
상기 제2 블록으로부터의 상기 제1 서버 노드와 연관된 이력 버전 발표 행위 정보를 상기 펌웨어 버전 발표 기록으로서 결정하는 단계를 포함하는, 데이터 처리 방법. - 제2항에 있어서,
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하는 단계는,
상기 펌웨어 버전 업데이트 기록에서의 상기 제1 버전 파라미터에 기초하여 상기 업데이트된 버전 파라미터에 대해 롤백 검출(rollback detection)을 수행하는 단계;
상기 제1 버전 파라미터가 상기 업데이트된 버전 파라미터와 동일함을 검출한 것에 응답하여, 버전 롤백이 존재한다고 결정하고, 상기 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정하는 단계 - 상기 무효한 업데이트 요청은 상기 실행 노드가 상기 제1 서버 노드의 버전 정보에 대한 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용됨 -;
상기 제1 버전 파라미터가 상기 업데이트된 버전 파라미터와 다름을 검출한 것에 응답하여, 상기 버전 롤백이 존재하지 않는다고 결정하고, 상기 업데이트된 버전 파라미터 및 상기 펌웨어 버전 발표 기록에 기초하여 상기 펌웨어 업데이트 요청의 유효성을 결정하는 단계를 포함하는, 데이터 처리 방법. - 제3항에 있어서,
상기 업데이트된 버전 파라미터 및 상기 펌웨어 버전 발표 기록에 기초하여, 상기 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하는 것은,
상기 펌웨어 버전 발표 기록과 연관된 이력 버전 발표 행위 정보로부터 제1 버전 발표 행위 정보를 획득하는 것 - 상기 제1 버전 발표 행위 정보는 상기 이력 버전 발표 행위 정보에서 최신 버전 발표 타임스탬프를 갖는 버전 발표 행위 정보임 -; 및
상기 제1 버전 발표 행위 정보가 상기 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여 상기 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하는 것을 포함하는, 데이터 처리 방법. - 제4항에 있어서,
상기 펌웨어 업데이트 요청은 상기 제1 서버 노드의 운영 버전 파라미터를 더 포함하고;
상기 데이터 처리 방법은,
상기 제1 버전 발표 행위 정보가 상기 업데이트된 버전 파라미터를 포함하지 않고, 상기 이력 버전 발표 행위 정보에서의 제2 버전 발표 행위 정보가 상기 업데이트된 버전 파라미터를 포함함을 검출한 것에 응답하여, 상기 업데이트된 버전 파라미터를 사용하여 펌웨어 업데이트가 수행되는 M개의 제2 서버 노드에 대한 블록체인을 검색하는 단계 - M은 2보다 큰 양의 정수임 -;
상기 M개의 제2 서버 노드의 버전 업데이트 행위 정보를 획득하는 단계;
상기 M개의 제2 서버 노드의 버전 업데이트 행위 정보가 상기 운영 버전 파라미터를 포함함을 검출한 것에 응답하여, 상기 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정하는 단계; 및
상기 운영 버전 파라미터를 포함하지 않는 버전 업데이트 행위 정보가 상기 M개의 제2 서버 노드의 버전 업데이트 행위 정보에 존재함을 검출한 것에 응답하여, 상기 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정하는 단계를 더 포함하는 데이터 처리 방법. - 제5항에 있어서,
상기 펌웨어 업데이트 요청이 유효한 업데이트 요청이라고 결정한 것에 응답하여, 상기 제1 서버 노드에 대해 펌웨어 업데이트를 수행하는 데 사용되는 피드백 정보를 상기 실행 노드에 회신하는 단계 - 상기 피드백 정보는 상기 제1 서버 노드의 펌웨어 버전 정보를 상기 운영 버전 파라미터의 운영 버전 정보로부터 상기 업데이트된 버전 파라미터의 업데이트된 버전 정보로 업데이트하도록 상기 실행 노드에 명령하는 데 사용됨 -를 더 포함하는 데이터 처리 방법. - 제5항에 있어서,
상기 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 검출한 것에 응답하여, 계약의 실행이 실패한 것으로 결정하고, 상기 무효한 업데이트 요청을 상기 실행 노드에 회신하는 단계; 및
상기 실행 노드에 의해 송신되는 상기 제1 서버 노드에 대응하는 다음 펌웨어 업데이트 요청이 수신되는 경우, 상기 다음 펌웨어 업데이트 요청을 무효한 업데이트 요청으로서 식별하는 단계 - 상기 무효한 업데이트 요청은 보안 감사 중에 상기 실행 노드에 대한 경보 정보를 생성하도록 상기 발표 노드에 명령하는 데 사용됨 -를 더 포함하는 데이터 처리 방법. - 제7항에 있어서,
상기 경보 정보는, 상기 블록체인으로부터 획득된 상기 제1 서버의 온 체인(on-chain) 업데이트된 버전 파라미터, 및 상기 제1 서버 노드로부터 로컬로 취득된 업데이트된 운영 버전 파라미터에 따라 상기 보안 감사가 수행된 후, 상기 발표 노드에 의해 획득되는, 데이터 처리 방법. - 제1항에 있어서,
상기 제1 서버 노드가 상기 업데이트된 버전 파라미터에 서명한 후의 확인 정보를 수신하는 단계 - 상기 확인 정보는 상기 실행 노드가 상기 제1 서버 노드의 펌웨어 버전 정보를 업데이트하였음을 지시함 -;
상기 제1 서버 노드의 공개 키 정보를 사용하여 상기 확인 정보에 대해 서명 검증을 수행하고, 서명 검증이 성공한 경우, 상기 지능형 계약의 호출이 완료된 것으로 결정하는 단계; 및
상기 확인 정보 및 상기 펌웨어 업데이트 요청에 기초하여 상기 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하고, 상기 제1 서버 노드의 블록체인 주소에 기초하여, 업데이트된 펌웨어 버전 업데이트 기록을 상기 블록체인에 기입하는 단계를 더 포함하는 데이터 처리 방법. - 제9항에 있어서,
상기 확인 정보 및 상기 펌웨어 업데이트 요청에 기초하여 상기 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하고, 상기 제1 서버 노드의 블록체인 주소에 기초하여, 업데이트된 펌웨어 버전 업데이트 기록을 상기 블록체인에 기입하는 단계는,
상기 펌웨어 업데이트 요청에서의 상기 업데이트된 버전 파라미터 및 운영 버전 파라미터를, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록을 구축하기 위한 입력 정보로서 사용하는 단계;
상기 확인 정보에 포함된 상기 업데이트된 버전 파라미터를, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록을 구축하기 위한 출력 정보로서 사용하는 단계;
상기 입력 정보 및 상기 출력 정보에 기초하여, 상기 제1 서버 노드와 연관된 타깃 버전 업데이트 행위 정보를 결정하고, 상기 타깃 버전 업데이트 행위 정보에 기초하여 상기 제1 서버 노드의 펌웨어 버전 업데이트 기록을 업데이트하는 단계; 및
업데이트된 펌웨어 버전 업데이트 기록을 상기 제1 서버 노드의 블록체인 주소에 기초하여 상기 블록체인에 기입하는 단계를 포함하는, 데이터 처리 방법. - 계약 노드에 적용되는, 지능형 계약에 기초한 데이터 처리 장치로서,
실행 노드에 의해 송신되는, 제1 서버 노드에 대응하는 펌웨어 업데이트 요청을 수신하도록 구성된 요청 수신 모듈 - 상기 펌웨어 업데이트 요청은 적어도 상기 제1 서버 노드의 업데이트된 버전 파라미터를 포함함 -;
상기 펌웨어 업데이트 요청에 따라 지능형 계약을 호출하고, 상기 지능형 계약에 기초하여 블록체인으로부터, 상기 제1 서버 노드와 연관된 펌웨어 버전 업데이트 기록 및 펌웨어 버전 발표 기록을 획득하도록 구성된 계약 호출 모듈 - 상기 펌웨어 버전 발표 기록은 컨센서스 메커니즘에 기초하여 상기 블록체인상의 발표 노드에 의해 결정됨 -; 및
상기 펌웨어 버전 업데이트 기록, 상기 펌웨어 버전 발표 기록 및 상기 업데이트된 버전 파라미터에 따라 상기 펌웨어 업데이트 요청의 유효성을 결정하도록 구성된 유효성 결정 모듈
을 포함하는 데이터 처리 장치. - 제11항에 있어서,
상기 지능형 계약 호출 모듈은,
상기 지능형 계약을 호출하여 상기 블록체인에서의 상기 제1 서버 노드의 블록체인 주소를 획득하도록 구성된 주소 획득 유닛 - 상기 블록체인 주소는, 상기 블록체인에 의해 상기 제1 서버 노드의 공개 키 정보에 따라 해시 계산이 수행된 후에 고유하게 결정됨 -;
상기 블록체인으로부터의 상기 블록체인 주소에 기초하여, 상기 제1 서버 노드와 연관된 제1 블록 및 제2 블록을 획득하도록 구성된 블록 획득 유닛;
상기 제1 블록으로부터의 이력 버전 업데이트 행위 정보를, 상기 제1 서버 노드와 연관된 상기 펌웨어 버전 업데이트 기록으로서 결정하도록 구성된 업데이트 기록 결정 유닛 - 상기 이력 버전 업데이트 행위 정보는 제1 버전 파라미터 및 제2 버전 파라미터를 포함하고, 상기 제2 버전 파라미터는 상기 제1 버전 파라미터에 대해 펌웨어 업데이트가 수행된 후에 획득된 버전 파라미터임 -; 및
상기 제2 블록으로부터의 상기 제1 서버 노드와 연관된 이력 버전 발표 행위 정보를, 상기 펌웨어 버전 발표 기록으로서 결정하도록 구성된 발표 기록 결정 유닛을 포함하는, 데이터 처리 장치. - 제12항에 있어서,
상기 유효성 결정 모듈은,
상기 펌웨어 버전 업데이트 기록에서의 상기 제1 버전 파라미터에 기초하여 상기 업데이트된 버전 파라미터에 대해 롤백 검출을 수행하도록 구성된 롤백 검출 유닛;
상기 제1 버전 파라미터가 상기 업데이트된 버전 파라미터와 동일함을 검출한 것에 응답하여, 버전 롤백이 존재한다고 결정하고, 상기 펌웨어 업데이트 요청이 무효한 업데이트 요청이라고 결정하도록 구성된 무효성 결정 유닛 - 상기 무효한 업데이트 요청은 상기 실행 노드가 상기 제1 서버 노드의 버전 정보에 대해 펌웨어 업데이트를 수행할 권한이 없음을 지시하는 데 사용됨 -;
상기 제1 버전 파라미터가 상기 업데이트된 버전 파라미터와 다름을 검출한 것에 응답하여, 상기 버전 롤백이 존재하지 않는다고 결정하고, 상기 업데이트된 버전 파라미터 및 상기 펌웨어 버전 발표 기록에 기초하여 상기 펌웨어 업데이트 요청의 유효성을 결정하도록 구성된 유효성 결정 유닛을 포함하는, 데이터 처리 장치. - 프로세서 및 메모리를 포함하는 노드 기기로서,
상기 프로세서는 상기 메모리에 연결되고, 상기 메모리는 프로그램 코드를 저장하도록 구성되며, 상기 프로세서는 상기 프로그램 코드를 호출하여 제1항 내지 제10항 중 어느 한 항에 따른 방법을 수행하도록 구성되는,
노드 기기. - 컴퓨터 프로그램을 저장하는 컴퓨터 저장 매체로서,
상기 컴퓨터 프로그램은 프로그램 명령어를 포함하고, 상기 프로그램 명령어는 프로세서에 의해 실행될 때, 제1항 내지 제10항 중 어느 한 항에 따른 방법이 수행되게 하는,
컴퓨터 저장 매체.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910808351.8A CN110535938B (zh) | 2019-08-29 | 2019-08-29 | 一种基于智能合约的数据处理方法、设备及存储介质 |
CN201910808351.8 | 2019-08-29 | ||
PCT/CN2020/101558 WO2021036545A1 (zh) | 2019-08-29 | 2020-07-13 | 一种基于智能合约的数据处理方法、设备及存储介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20210057149A true KR20210057149A (ko) | 2021-05-20 |
KR102577139B1 KR102577139B1 (ko) | 2023-09-08 |
Family
ID=68665284
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020217010913A KR102577139B1 (ko) | 2019-08-29 | 2020-07-13 | 스마트 계약 기반 데이터 처리 방법, 기기 및 저장 매체 |
Country Status (6)
Country | Link |
---|---|
US (1) | US11733991B2 (ko) |
EP (1) | EP4024812B1 (ko) |
JP (1) | JP7199775B2 (ko) |
KR (1) | KR102577139B1 (ko) |
CN (1) | CN110535938B (ko) |
WO (1) | WO2021036545A1 (ko) |
Families Citing this family (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11347858B2 (en) * | 2019-07-22 | 2022-05-31 | Dell Products L.P. | System and method to inhibit firmware downgrade |
CN110535938B (zh) * | 2019-08-29 | 2021-07-27 | 腾讯科技(深圳)有限公司 | 一种基于智能合约的数据处理方法、设备及存储介质 |
CN111182527B (zh) * | 2019-12-27 | 2022-07-26 | 深圳市云伽智能技术有限公司 | Ota固件升级方法、装置、终端设备及其存储介质 |
CN111447092B (zh) * | 2020-03-26 | 2022-11-01 | 杭州复杂美科技有限公司 | 版本监测方法、设备和存储介质 |
CN113495750B (zh) * | 2020-04-01 | 2023-02-10 | 中移物联网有限公司 | 一种设备的升级检测方法、装置及服务器 |
CN111506327B (zh) * | 2020-04-15 | 2023-04-21 | 深圳市迅雷网络技术有限公司 | 区块链节点热升级方法及相关设备 |
CN112491812B (zh) | 2020-07-08 | 2022-03-01 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的哈希更新方法及装置 |
CN113971289A (zh) | 2020-07-08 | 2022-01-25 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的可信启动方法及装置 |
CN112148333B (zh) * | 2020-10-10 | 2023-11-03 | 上海聪链信息科技有限公司 | 区块链服务器固件更新系统 |
CN112162768B (zh) * | 2020-10-14 | 2022-09-30 | 支付宝(杭州)信息技术有限公司 | 一种区块链升级方法和系统 |
CN112162770B (zh) * | 2020-10-20 | 2023-11-10 | 深圳技术大学 | 基于区块链实现完整性验证的固件版本升级方法及装置 |
CN112347456B (zh) | 2020-10-28 | 2023-09-01 | 达闼机器人股份有限公司 | 程序验证方法和装置、平台和用户终端及在线服务系统 |
WO2022140400A1 (en) * | 2020-12-22 | 2022-06-30 | Protectedby.Ai, Inc. | System and method for securing computer code using dynamically generated digital signatures |
CN112699112B (zh) * | 2020-12-31 | 2024-02-06 | 东莞盟大集团有限公司 | 一种基于区块链技术的数据挖掘流程分享方法 |
US11775562B2 (en) | 2021-03-12 | 2023-10-03 | Landis+Gyr Technology, Inc. | Distributed ledgers on network gateways |
US11662993B2 (en) * | 2021-05-18 | 2023-05-30 | Kyndryl, Inc. | Autonomous management of temporal updates and rollbacks |
CN113568971A (zh) * | 2021-06-25 | 2021-10-29 | 华能招标有限公司 | 基于区块链的招投标管理方法、装置、计算机设备及介质 |
CN113722548B (zh) * | 2021-08-30 | 2024-07-16 | 北京天空卫士网络安全技术有限公司 | 一种业务系统中引用关系的处理方法和装置 |
WO2023119398A1 (ja) * | 2021-12-21 | 2023-06-29 | 株式会社東芝 | ブロックチェーンシステム、ブロックチェーンシステム更新方法及びプログラム |
CN114520774B (zh) * | 2021-12-28 | 2024-02-23 | 武汉虹旭信息技术有限责任公司 | 基于智能合约的深度报文检测方法及装置 |
CN115098518B (zh) * | 2022-06-08 | 2024-04-09 | 西安工业大学 | 一种四层智能合约的链上升级方法 |
CN115174385B (zh) * | 2022-06-15 | 2024-04-02 | 桂林电子科技大学 | 一种基于区块链的工业物联网设备固件软件更新方法 |
CN117908912A (zh) * | 2022-10-19 | 2024-04-19 | 戴尔产品有限公司 | 双向版本兼容性控制 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101796690B1 (ko) * | 2016-06-28 | 2017-11-10 | 상명대학교 천안산학협력단 | 블록체인 기반의 펌웨어 무결성 검증 시스템 및 그 방법 |
US20190163912A1 (en) * | 2017-11-30 | 2019-05-30 | Mocana Corporation | System and method for recording device lifecycle transactions as versioned blocks in a blockchain network using a transaction connector and broker service |
WO2019148050A1 (en) * | 2018-01-25 | 2019-08-01 | Fortress Cyber Security, LLC | Secure storage of data and hashes via a distributed ledger system |
Family Cites Families (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8683443B2 (en) * | 2011-08-25 | 2014-03-25 | Salesforce.Com, Inc. | Streamlined methodology for resolving software integration conflicts |
JP2013125405A (ja) * | 2011-12-14 | 2013-06-24 | Seiko Epson Corp | ファームウェア書換方法およびファームウェア、ならびに電子機器 |
CN103544030A (zh) * | 2013-07-04 | 2014-01-29 | Tcl集团股份有限公司 | 软件升级方法、软件升级系统及智能终端 |
JP2016126693A (ja) * | 2015-01-08 | 2016-07-11 | 富士通株式会社 | 制御手順方法、制御手順プログラム及び制御手順装置 |
JP2016161986A (ja) * | 2015-02-26 | 2016-09-05 | キヤノン株式会社 | システム、バージョンアップ方法およびプログラム、並びに、情報処理装置 |
US10033534B2 (en) * | 2015-12-01 | 2018-07-24 | Intel Corporation | Methods and apparatus to provide for efficient and secure software updates |
US10185550B2 (en) * | 2016-09-28 | 2019-01-22 | Mcafee, Inc. | Device-driven auto-recovery using multiple recovery sources |
CN106648669B (zh) * | 2016-12-26 | 2020-04-10 | 广东芬尼克兹节能设备有限公司 | 产品设备远程固件升级方法及系统 |
CN106972961A (zh) * | 2017-03-21 | 2017-07-21 | 上海动联信息技术股份有限公司 | 一种基于蓝牙的安全设备固件升级方法 |
CN107329794A (zh) * | 2017-07-24 | 2017-11-07 | 上海斐讯数据通信技术有限公司 | 一种发布固件、升级固件的方法及系统 |
CN108270874B (zh) * | 2018-02-05 | 2021-04-23 | 武汉斗鱼网络科技有限公司 | 应用程序的更新方法及装置 |
CN108830720B (zh) | 2018-06-21 | 2021-04-30 | 北京京东尚科信息技术有限公司 | 智能合约运行方法、装置、系统和计算机可读存储介质 |
US20200058007A1 (en) * | 2018-08-15 | 2020-02-20 | NEC Laboratories Europe GmbH | Data exchange platform using blockchain |
CN109493216B (zh) * | 2018-09-30 | 2021-02-09 | 北京小米移动软件有限公司 | 模型训练方法、装置、系统及存储介质 |
DE102018129354A1 (de) * | 2018-11-21 | 2020-05-28 | Phoenix Contact Gmbh & Co. Kg | Verfahren zum Bearbeiten von Anwendungsprogrammen auf einem verteilten Automatisierungssystem |
CN109889589B (zh) * | 2019-02-18 | 2021-11-23 | 闪联信息技术工程中心有限公司 | 一种基于区块链实现嵌入式硬件ota升级系统及方法 |
CN110096294B (zh) * | 2019-05-07 | 2022-08-16 | 柏科智能(厦门)科技有限公司 | 一种可任意断点无线升级mcu应用程序的方法 |
CN110535938B (zh) * | 2019-08-29 | 2021-07-27 | 腾讯科技(深圳)有限公司 | 一种基于智能合约的数据处理方法、设备及存储介质 |
-
2019
- 2019-08-29 CN CN201910808351.8A patent/CN110535938B/zh active Active
-
2020
- 2020-07-13 EP EP20829525.3A patent/EP4024812B1/en active Active
- 2020-07-13 KR KR1020217010913A patent/KR102577139B1/ko active IP Right Grant
- 2020-07-13 WO PCT/CN2020/101558 patent/WO2021036545A1/zh unknown
- 2020-07-13 JP JP2021515047A patent/JP7199775B2/ja active Active
-
2021
- 2021-01-25 US US17/157,965 patent/US11733991B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR101796690B1 (ko) * | 2016-06-28 | 2017-11-10 | 상명대학교 천안산학협력단 | 블록체인 기반의 펌웨어 무결성 검증 시스템 및 그 방법 |
US20190163912A1 (en) * | 2017-11-30 | 2019-05-30 | Mocana Corporation | System and method for recording device lifecycle transactions as versioned blocks in a blockchain network using a transaction connector and broker service |
WO2019148050A1 (en) * | 2018-01-25 | 2019-08-01 | Fortress Cyber Security, LLC | Secure storage of data and hashes via a distributed ledger system |
Non-Patent Citations (1)
Title |
---|
Yohan Alexander et al. An Over-the-Blockchain Firmware Update Framework for IoT Devices. 2018 IEEE Conference on Dependable and Secure Computing, 2018년 12월 10일. 1-8면. * |
Also Published As
Publication number | Publication date |
---|---|
US20210149663A1 (en) | 2021-05-20 |
EP4024812B1 (en) | 2024-06-26 |
EP4024812A1 (en) | 2022-07-06 |
CN110535938A (zh) | 2019-12-03 |
US11733991B2 (en) | 2023-08-22 |
JP7199775B2 (ja) | 2023-01-06 |
CN110535938B (zh) | 2021-07-27 |
EP4024812A4 (en) | 2022-10-19 |
KR102577139B1 (ko) | 2023-09-08 |
JP2022502738A (ja) | 2022-01-11 |
WO2021036545A1 (zh) | 2021-03-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR102577139B1 (ko) | 스마트 계약 기반 데이터 처리 방법, 기기 및 저장 매체 | |
CN103856569B (zh) | 一种同步域名系统资源信息的方法及设备 | |
CN110661658B (zh) | 一种区块链网络的节点管理方法、装置及计算机存储介质 | |
CN111291060B (zh) | 一种管理区块链节点的方法、装置及计算机可读介质 | |
CN110784495B (zh) | 基于区块链的大数据集群系统的发现与配置信息管理方法 | |
CN110602108B (zh) | 基于区块链网络的数据通信方法、装置、设备及存储介质 | |
CN110135194B (zh) | 一种基于区块链的工业互联网数字对象的管理方法 | |
CN110597918A (zh) | 一种账户管理方法、装置及计算机可读存储介质 | |
CN110266872B (zh) | 通讯录数据的管控方法、装置及云通讯录系统、计算机设备、计算机可读存储介质 | |
CN111698315B (zh) | 针对区块的数据处理方法、数据处理装置及计算机设备 | |
CN112468525B (zh) | 一种基于区块链的域名管理系统 | |
CN110309173B (zh) | 合约数据的记录方法、装置及区块链节点、存储介质 | |
CN110597673B (zh) | 存储系统的容灾方法、装置、设备及计算机可读存储介质 | |
US8117181B2 (en) | System for notification of group membership changes in directory service | |
CN117407437A (zh) | 一种基于区块链的数据处理方法、设备以及可读存储介质 | |
CN113010600B (zh) | 一种基于区块链的数据管理系统、方法、相关设备及介质 | |
CN113194159B (zh) | Dns权威数据管理方法及系统 | |
CN116095081A (zh) | 基于区块链系统的事件处理方法及装置、设备、介质 | |
CN116107801A (zh) | 交易处理方法及相关产品 | |
CN111104415A (zh) | 一种时区更新方法、装置、电子设备及存储介质 | |
CN112989404A (zh) | 基于区块链的日志管理方法及相关设备 | |
CN111211985B (zh) | 转发表项更新方法、装置及系统 | |
CN117640664B (zh) | 标识数据同步方法、系统、电子设备及存储介质 | |
CN114697985B (zh) | 无线运维系统注册方法、装置、电子设备及存储介质 | |
CN112822279B (zh) | 基于智能感知与可信存储的监测方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
E902 | Notification of reason for refusal | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant |