KR102046424B1 - System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment - Google Patents

System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment Download PDF

Info

Publication number
KR102046424B1
KR102046424B1 KR1020190016464A KR20190016464A KR102046424B1 KR 102046424 B1 KR102046424 B1 KR 102046424B1 KR 1020190016464 A KR1020190016464 A KR 1020190016464A KR 20190016464 A KR20190016464 A KR 20190016464A KR 102046424 B1 KR102046424 B1 KR 102046424B1
Authority
KR
South Korea
Prior art keywords
cluster
key
node
internal
certificate
Prior art date
Application number
KR1020190016464A
Other languages
Korean (ko)
Other versions
KR102046424B9 (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 KR1020190016464A priority Critical patent/KR102046424B1/en
Application granted granted Critical
Publication of KR102046424B1 publication Critical patent/KR102046424B1/en
Priority to US16/698,439 priority patent/US11405198B2/en
Publication of KR102046424B9 publication Critical patent/KR102046424B9/en

Links

Images

Classifications

    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/321—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 a third party or a trusted authority
    • 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

According to an embodiment of the present invention, a transaction signing method performed in a key storage management system implemented by a computer comprises the steps of: configuring a cluster based on the node; and signing a transaction by generating a private key according to a BIP-32 protocol from an internal key of the cluster among a plurality of keys managed in a trusted execution environment of a node existing in the configured cluster.

Description

신뢰실행환경(Trusted Execution Environment)에서 관리되는 클러스터의 내부키로부터 BIP-32 프로토콜에 기초하여 트랜잭션을 서명하는 키 보관 관리 시스템 및 방법{SYSTEM AND METHOD FOR STORING AND MANAGING KEYS FOR SIGNING TRANSACTIONS BASED ON A BIP-32 PROTOCOL FROM AN INTERNAL KEY OF A CLUSTER MANAGED IN A TRUSTED EXECUTION ENVIRONMENT}SYSTEM AND METHOD FOR STORING AND MANAGING KEYS FOR SIGNING TRANSACTIONS BASED ON A BIP- 32 PROTOCOL FROM AN INTERNAL KEY OF A CLUSTER MANAGED IN A TRUSTED EXECUTION ENVIRONMENT}

아래의 설명은 신뢰실행환경(Trusted Execution Environment) 기반의 키 관리 솔루션에 관한 것으로, 신뢰실행환경을 기반으로 키를 편리하고 안전하게 관리하는 방법 및 시스템에 관한 것이다. The following description relates to a key management solution based on a trusted execution environment, and a method and system for conveniently and securely managing keys based on a trusted execution environment.

암호화폐란 지폐, 동전 등의 실물이 없고 온라인에서 거래되는 화폐를 말한다. 암호화폐는 각국 정부나 중앙은행이 발행하는 일반 화폐와 달리 처음 고안한 사람이 정한 규칙에 따라 가치가 매겨지며,　정부나 중앙은행에서 거래 내역을 관리하지 않고 블록체인 기술을 기반으로 유통되기 때문에 정부가 가치나 지급을 보장하지 않는다. 암호화폐는 블록에 데이터를 담아 체인 형태로 연결하여 수많은 컴퓨터에 동시에 이를 복제하여 저장하는 블록체인 기술에 기반한 분산형 시스템 방식으로 처리된다. 분산형 시스템에 참여하는 사람을 채굴자라고 하며, 이들은 블록체인 처리의 보상으로 코인 형태의 수수료를 받는다. 이러한 구조로 암호화폐가 유지되기 때문에 화폐 발행에 따른 생산비용이 전혀 들지 않고 이체비용 등 거래비용을 대폭 절감할 수 있다. 또한, 컴퓨터 하드디스크 등에 저장되기 때문에 보관비용이 들지 않고, 도난/분실의 우려가 없기 때문에 가치저장 수단으로서의 기능도 뛰어나다는 장점을 가지고 있다.Cryptocurrency is a currency that is traded online without any kind of bills and coins. Unlike general currency issued by governments or central banks, cryptocurrencies are valued according to the rules established by the original creator, and because they are distributed on the basis of blockchain technology without managing transaction details, Does not guarantee value or payment. Cryptocurrency is handled in a distributed system based on blockchain technology that stores data in blocks, connects them in a chain, and replicates and stores them simultaneously on numerous computers. Those who participate in a decentralized system are called miners, who receive a fee in the form of coins as a reward for blockchain processing. Since the cryptocurrency is maintained in this structure, it is possible to significantly reduce transaction costs such as transfer costs without any production costs associated with issuing money. In addition, since it is stored in a computer hard disk or the like, there is no storage cost, and there is no risk of theft / loss.

신뢰실행환경은 일반적인 실행환경과 격리되어 실행되는 코드의 무결성과 실행과정에서의 생성 및 저장된 데이터의 기밀성을 보장하는 안전한 실행환경을 뜻한다. 신뢰실행환경은 하드웨어와 소프트웨어의 장점만을 결합한 첨단 보안 기술로서, 별도의 하드웨어가 아니면서도 분리된 하드웨어 수준의 보안성을 제공한다. 이러한 신뢰실행환경 기반으로 키를 편리하고 안전하게 관리할 수 있는 솔루션이 개발될 필요가 있다. A trusted execution environment is a secure execution environment that ensures the integrity of code executed in isolation from the normal execution environment and the confidentiality of the data generated and stored in the execution process. Trusted Execution Environment is an advanced security technology that combines the advantages of hardware and software. It provides security at the level of separate hardware without separate hardware. Based on this trusted execution environment, a solution that can conveniently and securely manage keys needs to be developed.

참고자료: KR 10-2018-0102269, KR 10-2016-0113264, 비특허문헌 1(Steven Goldfeder and Arvind Narayan, "Securing Bitcoin wallets via a new DSA / ECDSA threshold signature scheme", 2015.), 비특허문헌 2(Image sources: Linseed Studio, Adi Kurniawan, Ema Dimitrova, aLf, Mister Pixel from Noun Project)References: KR 10-2018-0102269, KR 10-2016-0113264, Steven Goldfeder and Arvind Narayan, "Securing Bitcoin wallets via a new DSA / ECDSA threshold signature scheme", 2015. 2 (Image sources: Linseed Studio, Adi Kurniawan, Ema Dimitrova, aLf, Mister Pixel from Noun Project)

신뢰실행환경 기반으로 키를 편리하고 안전하게 관리하는 방법 및 시스템을 제공할 수 있다. 구체적으로, 키를 공유하는 클러스트를 구성하고 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 키를 생성하고 클러스터 내부의 다른 신뢰실행환경과 동기화시켜 관리하며, 관리되는 복수 개의 키 중 클러스터의 내부키(B 키)로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명하는 방법 및 시스템을 제공할 수 있다. Based on the trusted execution environment, it is possible to provide a method and system for conveniently and securely managing keys. Specifically, a cluster is configured to share a key, a key is generated in a trusted execution environment of a node that exists inside the cluster, synchronized with other trusted execution environments in the cluster, and managed. It is possible to provide a method and system for signing a transaction by generating a private key according to the BIP-32 protocol from an internal key (B key) of a cluster.

컴퓨터로 구현되는 키 보관 관리 시스템에서 수행되는 트랜잭션 서명 방법은, 노드를 기준으로 클러스터를 구성하는 단계; 및 상기 구성된 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 관리되는 복수 개의 키 중 상기 클러스터의 내부키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명하는 단계를 포함할 수 있다. Transaction signature method performed in a computer-implemented key storage management system, comprising: configuring a cluster on a node basis; And generating a private key according to the BIP-32 protocol from a plurality of keys managed in a trusted execution environment of a node existing in the configured cluster and signing a transaction according to the BIP-32 protocol. can do.

상기 트랜잭션을 서명하는 단계는, 클라우드 서버에서 클러스터의 익스터널 릴레이에게 서명하려는 키의 BIP-32 루트 공개키, 서명하려는 BIP-32 path, 서명하려는 데이터, 서명을 승인한 관리자의 인증 정보를 포함하는 서명이 요청되고, 상기 익스터널 릴레이와 별도의 통신 채널을 통하여 통신하는 클러스터 내부의 인터널 릴레이가 클러스터 내부의 노드를 이용하여 서명을 진행한 결과를 상기 익스터널 릴레이에게 전달함에 따라 상기 클라우드 서버에서 획득되는 단계를 포함할 수 있다. The signing of the transaction may include a BIP-32 root public key of a key to be signed to an external relay of a cluster, a BIP-32 path to be signed, data to be signed, and authentication information of an administrator who approved the signature at a cloud server. In the cloud server, as a signature is requested and the internal relay in the cluster communicating with the external relay through a separate communication channel transmits the result of the signature using the node in the cluster to the external relay, It may include the step of obtaining.

상기 트랜잭션을 서명하는 단계는, 상기 클러스터의 인터널 릴레이가 상기 클러스터 내부의 노드에게 임의의 메시지에 대하여 클러스터의 제1 내부키를 이용하여 서명하려는 키의 BIP-32 루트 공개키와 8바이트 이내의 임의의 메시지를 포함한 서명을 요청하고, 상기 노드에서 서명을 진행한 결과를 상기 인터널 릴레이에게 반환하여 상기 클러스터의 내부에 보관된 키들을 감사(Audit)하는 단계를 포함할 수 있다. The signing of the transaction may include: within 8 bytes of the BIP-32 root public key of the key that the internal relay of the cluster intends to sign using the cluster's first internal key for any message to a node within the cluster. Requesting a signature including an arbitrary message, and returning the result of the signing at the node to the internal relay to audit the keys stored in the cluster.

상기 클러스터를 구성하는 단계는, 상기 노드의 신뢰실행환경에서 클러스터의 클러스터의 제1 내부키, 클러스터의 제2 내부키를 포함하는 복수 개의 키를 관리하는 단계를 포함하고, 상기 클러스터의 제1 내부키는, BIP-32 루트 시드(Root Seed)이고, 상기 클러스터의 제2 내부키는, 디바이스 인증을 위한 것일 수 있다.The configuring of the cluster may include managing a plurality of keys including a first internal key of a cluster of a cluster and a second internal key of the cluster in a trusted execution environment of the node, wherein the first internal of the cluster includes: The key may be a BIP-32 root seed, and the second internal key of the cluster may be for device authentication.

상기 클러스터를 구성하는 단계는, 각각의 노드에 운영사와 관리자를 검증하기 위한 인증서(CA)가 삽입되어 제공되고, 데이터센터에서 노드를 기준으로 클러스터를 구성하고, 상기 노드에 클러스터의 내부키의 생성을 요청함에 따라 클러스터의 제1 내부키가 생성되는 단계를 포함할 수 있다. In the configuring of the cluster, a certificate (CA) for verifying an operator and an administrator is inserted into each node, and the cluster is configured based on a node in a data center, and an internal key of the cluster is generated in the node. The request may include generating a first internal key of the cluster.

상기 클러스터를 구성하는 단계는, 상기 클러스터 내에 존재하는 모든 노드들에 대하여 클러스터의 제2 내부키를 생성하고, 상기 생성된 클러스터의 제2 내부키를 통하여 디바이스 인증서를 승인받아 저장하고, 상기 클러스터의 제1 내부키가 클러스터 내의 노드들과 동기화되어 키가 공유되고, 상기 클러스터에 속한 노드들이 클러스터의 인트라넷에 연결됨에 따라 노드가 브릿지 서버로 접속하여 상기 클러스터에 속한 키 정보와 상기 노드가 저장하고 있는 키 정보를 업데이트하는 단계를 포함할 수 있다. The configuring of the cluster may include generating a second internal key of the cluster for all nodes existing in the cluster, receiving and storing a device certificate through the generated second internal key of the cluster, and As the first internal key is synchronized with the nodes in the cluster, the key is shared, and as the nodes belonging to the cluster are connected to the intranet of the cluster, the node accesses the bridge server to store the key information belonging to the cluster and the node. Updating the key information.

상기 클러스터를 구성하는 단계는, 상기 노드가 상기 클러스터의 인트라넷에 연결됨에 따라 상기 노드가 브릿지 서버를 통하여 클러스터의 키 목록을 조회하고, 상기 키 목록 중 상기 노드에 존재하지 않는 키가 있을 경우, 상기 키를 보관하고 있는 상기 클러스터의 다른 노드에게 복제를 요청하고, 상기 다른 노드에서 상기 복제가 요청된 노드가 인증된 디바이스인지 확인한 후, 상기 키를 복제하되, 상기 노드가 상기 다른 노드에게 키 내보내기를 요구함에 따라 상기 노드의 인증서를 상기 다른 노드에게 전달하고, 상기 다른 노드에서 상기 노드의 인증서를 검증함에 따라 상기 인증서에 포함된 상기 노드의 공개키를 이용하여 상기 노드의 클러스터의 제1 내부키를 암호화하고, 상기 암호화된 클러스터의 제1 내부키를 상기 노드에게 전달하고, 상기 노드에서 상기 암호화된 클러스터의 제1 내부키를 복호화하여 저장하는 단계를 포함할 수 있다. In the configuring of the cluster, as the node is connected to the intranet of the cluster, the node inquires a list of keys of the cluster through a bridge server, and when there is a key that does not exist in the node of the key list, Request replication from the other node in the cluster that holds the key, verify that the node requested for replication in the other node is an authorized device, and then duplicate the key, wherein the node exports the key to the other node. Forward the certificate of the node to the other node as required, and as the other node verifies the node's certificate, using the public key of the node included in the certificate to obtain the first internal key of the cluster of the node. Encrypt, pass the first internal key of the encrypted cluster to the node, and And decrypting and storing the first internal key of the encrypted cluster at the node.

상기 키 보관 관리 시스템은, 복수의 클러스터로 구성되고, 상기 복수의 클러스터는, 복수 개의 노드(Node), 메타데이터 데이터베이스(Metadata Database), 인터널 릴레이(Internal Relay)를 포함하는 내부 컴포넌트들과 상기 인터널 릴레이와 통신하는 익스터널 릴레이(External Relay)로 구성되고, 상기 내부 컴포넌트들이 외부망과 분리된 상태로, 내부 컴포넌트 간 인트라넷으로 연결되고, 클러스터의 내부와 외부 사이에 인터넷 이외의 별도의 채널을 통해 온-디맨드(On-Demand)로 연결되고, 상기 클러스터의 익스터널 릴레이와 클라우드 서버 사이에 인터넷으로 연결될 수 있다. The key storage management system includes a plurality of clusters, and the plurality of clusters include internal components including a plurality of nodes, a metadata database, and an internal relay. It consists of an external relay that communicates with an internal relay, and the internal components are separated from the external network, connected to intranets between internal components, and a separate channel other than the Internet between the inside and outside of the cluster. An on-demand connection may be performed, and the Internet may be connected between an external relay of the cluster and a cloud server.

오프라인의 격리된 공간에서 개인키를 보관하여 해커의 공격에도 매우 안전하게 보호할 수 있다. 또한, 신뢰실행환경에 기반하여 프로그램 변조와 중요 데이터의 유출을 방지할 수 있도록 설계되어 주요 데이터가 외부로 나갈 때 암호화된 후, 다시 내부로 들어올 때만 복호화되도록 설계될 수 있다. 또한, 내부자의 위협까지 가정하여 안전하게 설계된 시스템으로 내부 관리자일지라도 승인되지 않은 절차로는 주요 정보에 접근할 수 없다. 또한, 주요 정보를 복수 개의 서버에 분산시켜 보관함으로써 일부 장치에서 고장이 발생하더라도 안전하게 데이터를 유지할 수 있다. 또한, 빈번하게 사용되지 않는 개인키 일지라도 잘 보관되고 있는지 여부를 주기적으로 점검할 수 있다. By keeping your private key in an off-line, isolated space, you can be very safe from hacker attacks. In addition, it is designed to prevent program tampering and leakage of important data based on the trusted execution environment, so that the main data can be designed to be encrypted only when it goes out and then decrypted only when it comes back inside. In addition, the system is designed safely assuming insider threats, and even internal managers cannot access important information through unauthorized procedures. In addition, by distributing and storing important information in a plurality of servers, it is possible to safely maintain data even if a failure occurs in some devices. In addition, it is possible to periodically check whether a private key is used well even if it is not used frequently.

도 1은 일 실시예에 따른 키 보관 관리 시스템의 커스터디 서비스를 위한 개괄적인 구조를 설명하기 위한 도면이다.
도 2는 일 실시예에 따른 키 보관 관리 시스템에서 클러스터의 구조를 설명하기 위한 도면이다.
도 3은 일 실시예에 따른 키 보관 관리 시스템의 소프트웨어 구조를 설명하기 위한 도면이다.
도 4는 일 실시예에 따른 키 보관 관리 시스템에서 관리되는 키를 설명하기 위한 도면이다.
도 5는 일 실시예에 따른 키 보관 관리 시스템의 인증서 구조를 설명하기 위한 도면이다.
도 6 내지 도 9는 일 실시예에 따른 키 보관 관리 시스템에서 키를 생성하고 분배하는 것을 설명하기 위한 도면이다.
도 10 및 도 11은 일 실시예에 따른 키 보관 관리 시스템에서 트랜잭션을 서명하고, 감사를 수행하는 것을 설명하기 위한 도면이다.
도 12는 일 실시예에 따른 키 보관 관리 시스템의 트랜잭션 방법을 설명하기 위한 흐름도이다. 1 is a view for explaining a general structure for a study service of the key storage management system according to an embodiment.
2 is a diagram illustrating a structure of a cluster in a key storage management system according to an exemplary embodiment.
3 is a diagram for describing a software structure of a key storage management system according to an exemplary embodiment.
4 is a diagram illustrating a key managed by a key storage management system according to an exemplary embodiment.
5 is a diagram illustrating a certificate structure of a key storage management system according to an exemplary embodiment.
6 to 9 are diagrams for describing generation and distribution of keys in a key storage management system according to an exemplary embodiment.
10 and 11 illustrate a method of signing a transaction and performing an audit in a key storage management system according to an exemplary embodiment.
12 is a flowchart illustrating a transaction method of a key storage management system according to an embodiment.

이하, 실시예를 첨부한 도면을 참조하여 상세히 설명한다.Hereinafter, exemplary embodiments will be described in detail with reference to the accompanying drawings.

도 1은 일 실시예에 따른 보관 관리 시스템의 커스터디 서비스를 위한 개괄적인 구조를 설명하기 위한 도면이다. 1 is a view for explaining a general structure for a study service of the storage management system according to an embodiment.

키 보관 관리 시스템(100)은 신뢰실행환경(Trusted Execution Environment)이 적용되는 커스터디 서비스를 위한 개괄적인 구조를 구성할 수 있다. 키 보관 관리 시스템(100)은 클러스터 단위로 커스터디 서비스를 위한 키 보관 관리가 이루어질 수 있다. 신뢰실행환경이 적용되는 커스터디 서비스는 복수 개의 클러스터(101, 102)와 클라우드 서버(110)로 구성될 수 있다. 클러스터의 내부 컴포넌트들은 외부망과 분리된 상태로, 내부 컴포넌트들끼리 인트라넷(121)으로 연결될 수 있다. 클러스터 내부와 외부 사이는 인터넷이 아닌 별도의 채널, 예를 들면, QR 코드 인쇄, 블루투스 등을 통해 온-디맨드(On-Demand)(122)로 필요할 때만 연결될 수 있다. 클러스터의 외부 컴퓨터와 클라우드 서버(110) 사이에 인터넷(123)이 연결될 수 있다. 이러한 구조는 인터넷이 연결되지 않기 때문에 안전한 콜드월렛의 장점을 반영하면서도, 콜드월렛이 가진 예를 들면, 사용 편의성, 응답 시간 등의 단점들을 보완할 수 있다. The key archive management system 100 may construct a general structure for the study service to which the Trusted Execution Environment is applied. The key storage management system 100 may perform key storage management for the study service on a cluster basis. The study service to which the trusted execution environment is applied may be composed of a plurality of clusters 101 and 102 and a cloud server 110. Internal components of the cluster may be separated from the external network, and internal components may be connected to the intranet 121. The interior and exterior of the cluster may only be connected when needed on an on-demand 122 via a separate channel, for example, QR code printing, Bluetooth, and the like, rather than the Internet. The internet 123 may be connected between the external computer of the cluster and the cloud server 110. Such a structure reflects the advantages of a secure cold wallet because it is not connected to the Internet, but can compensate for the disadvantages of the cold wallet, for example, ease of use and response time.

도 2는 일 실시예에 따른 키 보관 관리 시스템에서 클러스터의 구조를 설명하기 위한 도면이다. 2 is a diagram illustrating a structure of a cluster in a key storage management system according to an exemplary embodiment.

도 1에서 도시된 복수 개의 클러스터(101, 102) 중 하나의 클러스터(101)의 구조를 설명하기로 한다. 이때, 클러스터(101)는 신뢰실행환경 기반의 커스터디 서비스를 위한 TEEvault 클러스터일 수 있다. The structure of one cluster 101 of the plurality of clusters 101 and 102 shown in FIG. 1 will be described. In this case, the cluster 101 may be a TEEvault cluster for a custom service based on a trusted execution environment.

클러스터(101)는 노드(이하, '볼트(금고) 노드(Vault Node)'로 기재하기로 함)의 물리적 결함이나 장애에 대비하여 동일한 키 정보(예를 들며, B키)를 복수 개의 볼트 노드에 복제하여 저장하고 있는 볼트 노드의 집합을 의미한다. 이에, 클러스터 단위로 키를 저장하게 된다. 각각의 클러스터는 물리적으로 분리된 데이터센터에 배치되어 관리될 수 있다. The cluster 101 stores a plurality of vault nodes with the same key information (for example, B key) in preparation for a physical defect or failure of a node (hereinafter, referred to as a 'vault node'). A set of vault nodes that are duplicated and stored in. Thus, the key is stored in cluster units. Each cluster can be deployed and managed in a physically separate data center.

볼트 노드(201)는 독립된 하드웨어(CPU)를 기반으로 신뢰실행환경에서 안전하게 키를 생성 및 서명하는 기능을 수행할 수 있다. 클러스터(101)에서 생성된 키는 클러스터 내의 모든 볼트 노드들 간에 자동으로 동기화되어 저장될 수 있다. 볼트 노드(201)들은 신뢰실행환경을 기반으로 안전한 통신 채널을 확보하고 키 정보를 공유할 수 있다. 하나의 볼트 노드에 장애가 발생하더라도 다른 볼트 노드를 통해 동일한 기능을 제공할 수 있다. The vault node 201 may perform a function of securely generating and signing a key in a trusted execution environment based on independent hardware (CPU). The key generated in the cluster 101 may be automatically synchronized and stored between all the vault nodes in the cluster. The vault nodes 201 may secure a secure communication channel and share key information based on a trusted execution environment. If one vault node fails, the other can provide the same functionality through another vault node.

메타데이터 데이터베이스(203)는 키 정보 이외의 정보들을 관리하기 위하여 DBMS가 설치되어 있고, 볼트 노드에 요청된 내역과 수행한 결과의 기록을 메타데이터 형태로 저장할 수 있다. 이때, 중요 정보는 볼트 노드(201)에 저장될 수 있으며, 중요 정보 이외의 부가 정보, 예를 들면, 데이터의 저장 일자, 데이터의 소유, 서명 여부 등 메타데이터 데이터베이스(203)에 로그로 저장될 수 있다. The metadata database 203 is provided with a DBMS to manage information other than key information, and may store a record of the requested details and the performed results in the form of metadata in the vault node. In this case, the important information may be stored in the vault node 201 and may be stored as a log in the metadata database 203 such as additional information other than the important information, for example, a data storage date, ownership of the data, and whether the data is signed. Can be.

인터널 릴레이(Internal Relay)(202) 및 익스터널 릴레이(External Relay)(204)는 서버와 같은 컴퓨터 장치일 수 있다. 인터널 릴레이(Internal Relay)(202)는 클러스터 외부에서 요청된 작업을 처리하기 위한 인터페이스를 제공하고, 클러스터 내의 볼트 노드들을 관리하는 역할을 수행할 수 있다. 익스터널 릴레이(External Relay)(204)는 인터넷이 아닌 별도의 채널을 통해 클러스터에 키 생성과 서명을 요청할 수 있다. 실질적으로, 클러스터의 인터널 릴레이가 제공하는 인터페이스만을 통하여 기능이 수행될 수 있다. 이에 따라, 해커가 공격할 수 있는 지점이 최소한으로 줄어들게 된다.Internal relay 202 and external relay 204 may be computer devices such as servers. The internal relay 202 may provide an interface for processing the requested work outside the cluster and may manage the vault nodes in the cluster. The external relay 204 can request key generation and signing from the cluster through a separate channel rather than the Internet. In practice, the function may be performed only through an interface provided by the internal relay of the cluster. As a result, the number of hacker attacks can be reduced to a minimum.

도 3은 일 실시예에 따른 키 보관 관리 시스템의 소프트웨어 구조를 설명하기 위한 도면이다. 3 is a diagram for describing a software structure of a key storage management system according to an exemplary embodiment.

키 보관 관리 시스템은 신뢰실행환경 기반의 커스터디 서비스를 위한 소프트웨어를 제공할 수 있다. 신뢰실행환경 기반의 커스터디 서비스를 위한 소프트웨어는 신뢰실행환경 코어(TEE core)(302), 볼트 노드 서버(vault node server)(301) 및 브릿지 서버(bridge server)(303)로 구성될 수 있다. 도 3을 참고하면, 볼트 노드(201)에 신뢰실행환경 코어(TEE core)(302), 볼트 노드 서버(vault node server)(301)가 구성될 수 있고, 인터널 릴레이(202)에 브릿지 서버(303)가 구성될 수 있다. The key storage management system may provide software for the trust execution environment-based study service. The software for the trust execution environment-based study service may be composed of a trust execution environment core (TEE core) 302, a vault node server 301, and a bridge server 303. . Referring to FIG. 3, a trusted execution environment core (TEE core) 302 and a vault node server 301 may be configured at the vault node 201, and a bridge server at the internal relay 202. 303 may be configured.

볼트 노드 서버(vault node server)(301)는 볼트 노드(201)의 REE(Rich Execution Environment: 일반실행환경)에서 실행되는 소프트웨어로 신뢰실행환경 코어(302)와 브릿지 서버(303) 사이에서 요청과 응답을 중계하는 역할과, 볼트 노드간의 백업 상태를 유지하는 역할을 수행할 수 있다. 이때, REE란 TEE가 아닌 실행환경에 대응되는 것으로, 일반적인 실행환경을 의미한다. The vault node server 301 is software that runs in the rich execution environment (REE) of the vault node 201 and requests and requests between the trusted execution core (302) and the bridge server (303). It can relay responses and maintain backup status between vault nodes. In this case, REE corresponds to an execution environment other than TEE, and means a general execution environment.

신뢰실행환경 코어(TEE core)(302)는 신뢰실행환경 내에서만 실행되는 소프트웨어로 제한적인 인터페이스를 통하여 외부로부터 요청을 받아 수행될 수 있다. 정해진 인터페이스를 통하지 않고서는 신뢰실행환경 코어(302)의 코드나 메모리에 접근할 수 없으므로 외부의 공격으로부터 안전하다. 신뢰실행환경 코어(302)는 다른 소프트웨어는 접근할 수 없는 자신만의 안전한 저장소(Secure Storage)를 생성하여 키와 같이 중요한 데이터를 저장하는데 사용할 수 있다. 기능적으로는 키를 생성하고 저장하는 키 관리부와 요청이 유효한 값인지 체크하는 검증부 등으로 구성될 수 있다. The trust execution environment core (TEE core) 302 may be performed by receiving a request from the outside through a limited interface with software running only in the trust execution environment. Since the code or the memory of the trusted execution environment core 302 cannot be accessed without a predetermined interface, it is safe from external attacks. Trusted execution environment core 302 can create its own Secure Storage that other software cannot access and use it to store sensitive data such as keys. Functionally, it may include a key management unit for generating and storing a key, and a verification unit for checking whether a request is a valid value.

브릿지 서버(bridge server)(303)는 인터널 릴레이(202)에 설치되는 소프트웨어로 볼트 노드(201)와 인터널 릴레이 서버 사이에서 요청과 응답을 중계하는 역할을 수행하며, 볼트 노드(201)를 관리하는 역할을 수행할 수 있다. 브릿지 서버(303)에는 gRPC 서버가 오픈되어 있어서 인터널 릴레이의 다른 소프트웨어에서 gRPC호출을 통해 볼트 노드(201)와 통신할 수 있다. gRPC 이외에 JSON-RPC, REST API 등의 방식으로도 통신할 수 있다.The bridge server 303 is software installed in the internal relay 202 and relays requests and responses between the vault node 201 and the internal relay server. It can play a role of management. The bridge server 303 has a gRPC server open so that other software of the internal relay can communicate with the vault node 201 through a gRPC call. In addition to gRPC, you can also communicate in JSON-RPC, REST API, and other ways.

또한, 키 보관 관리 시스템의 하드웨어 구조에 대하여 설명하기로 한다. 이하, 설명하는 하드웨어 구조는 예시일 뿐 이에 한정되는 것은 아니다. 실시예에 따른 키 보관 관리를 사용하기 위하여 요구되는 하드웨어는 TEE를 지원하는 컴퓨터 (TrustZone 지원 보드(이하, TZ 보드) 또는 Intel SGX 지원 컴퓨터), 서버 및 라우터를 포함할 수 있다. 해당 하드웨어로 구성된 각각의 클러스터는 물리적으로 분리된 공간, 예를 들면, 데이터 센터에 위치되도록 분산시키는 것이 권장된다. In addition, the hardware structure of the key storage management system will be described. Hereinafter, the hardware structure to be described is merely an example and the present invention is not limited thereto. The hardware required to use the key storage management according to the embodiment may include a computer that supports TEE (TrustZone support board (hereinafter referred to as TZ board) or an Intel SGX support computer), a server, and a router. It is recommended that each cluster of such hardware be distributed in physically separate spaces, for example data centers.

TZ 보드의 일반적인 요구 사항은 TrustZone 기능을 제공하는 ARM 보드여야 하고, REE는 리눅스 혹은 안드로이드 운영체제를 지원할 수 있다. TEE는 글로벌플랫폼(GlobalPlatform) API를 지원하는 TEE OS를 실행할 수 있어야 한다. The general requirement for a TZ board is an ARM board that provides TrustZone functionality, and REE can support Linux or Android operating systems. The TEE must be able to run a TEE OS that supports the GlobalPlatform API.

Intel SGX 지원 컴퓨터는 Intel SGX 기능이 있는 CPU를 탑재하여야 하고 해당 기능이 OS에서 지원되어야 한다. An Intel SGX-capable computer must have a CPU with Intel SGX capability and the feature to be supported by the OS.

서버는 인터널 릴레이의 역할을 수행할 수 있다. 서버는 익스터널 릴레이와 통신이 가능하기 위한 인터페이스(예를 들면, 블루투스 등)가 지원되어야 한다. 라우터는 클러스터의 요소들을 이더넷으로 연결하는 역할을 수행할 수 있다. 보안을 위하여 무선 기능을 제공하지 않거나 무선 기능을 비활성화할 수 있는 제품의 사용이 권장된다.The server can act as an internal relay. The server must support an interface (e.g. Bluetooth) to enable communication with the external relay. Routers can connect Ethernet elements in the cluster. For security reasons, it is recommended to use a product that does not provide wireless functionality or that can be disabled.

도 4는 일 실시예에 따른 키 보관 관리 시스템에서 관리되는 키를 설명하기 위한 도면이다. 4 is a diagram illustrating a key managed by a key storage management system according to an exemplary embodiment.

키 보관 관리 시스템은 키를 관리할 수 있다. 키 보관 관리 시스템은 D키, B키를 볼트 노드의 신뢰실행환경 영역에서 안전하게 관리할 수 있다. The key storage management system can manage keys. The key storage management system can securely manage D and B keys in the trusted execution environment area of the vault node.

D키(per vault node)는 볼트 노드간 통신에서 볼트 노드(디바이스)를 인증하기 위한 키이다. 볼트 노드를 클러스터에 포함시키기 전에 D키를 생성하고 커스터디 서비스 관리자에게 Device CA를 요청한다. D key (per vault node) is a key for authenticating the vault node (device) in the communication between the vault nodes. Before you include the vault node in the cluster, create a D-key and ask the Customization Service Administrator for the Device CA.

B키(per cluster)는 BIP-32 방식 암호화폐의 루트 시드이다. 볼트 노드를 데이터센터에 설치한 다음 생성되고, 클러스터의 내부 볼트 노드들 간에 B키를 백업하여 보관한다.The B key (per cluster) is the root seed of BIP-32 cryptocurrency. After the vault nodes are installed in the data center, they are created, and the B key is backed up and stored between the internal vault nodes in the cluster.

도 5는 일 실시예에 따른 키 보관 관리 시스템의 인증서 구조를 설명하기 위한 도면이다. 5 is a diagram illustrating a certificate structure of a key storage management system according to an exemplary embodiment.

CA 인증서는 다음과 같이 구성될 수 있다. CA(Certificate Authority)란 디지털 인증서를 발급하는 단위로서, 누구나 신뢰할 수 있는 객관적인 제3자로서 공개키가 특정 주체의 소유임을 증명하는 역할을 한다. 실시예에서는 볼트 노드가 유효한 장치인지 검증하기 위한 용도 또는 사용자를 인증하기 위하여 사용될 수 있다. 이때, CA는 커스터디 서비스 운영사에서 생성된다. The CA certificate may be configured as follows. Certificate Authority (CA) is a unit for issuing digital certificates. It is an objective third party that anyone can trust and serves to prove that a public key is owned by a specific subject. In embodiments, it may be used to verify that the vault node is a valid device or to authenticate a user. At this time, the CA is generated in the study service operator.

볼트 노드의 신뢰실행환경 영역에는 루트(Root) CA가 저장되어 있다. 이러한 루트 CA는 관리자(admin)과 볼트 노드(디바이스)를 인증하기 위한 용도로 사용될 수 있다. 인증서에는 서명이 가능한 개인키의 개념도 포함되어 있다. 인증서는 크게 CA 인증서와 엔드-유저(end-user) 인증서로 나뉠 수 있다. CA 인증서는 부서 단위로 관리가 되며 인증의 주체가 된다. The root CA is stored in the trusted execution environment area of the vault node. This root CA can be used to authenticate administrators and vault nodes (devices). The certificate also includes the concept of a signable private key. Certificates can be broadly divided into CA certificates and end-user certificates. CA certificates are managed by department and become the subject of certification.

Root CA는 운영사의 루트 인증서이며, Root of Trust로서 관리자 CA와 디바이스 CA를 인증하는데 사용될 수 있다.Root CA is the operator's root certificate and can be used to authenticate administrator CAs and device CAs as a root of trust.

Adimin CA는 관리자 관리 부서 인증서로서, 트랜잭션 서명을 담당하는 관리자를 인증하는데 사용될 수 있다.Adimin CA is an administrator management department certificate and can be used to authenticate the administrator responsible for signing transactions.

Device CA는 디바이스 관리 부서 인증서로서, 클러스터 관리 기관을 인증하는 클러스터 CA를 인증하는데 사용될 수 있다.Device CA is a device management department certificate and can be used to authenticate a cluster CA that authenticates a cluster management authority.

Cluster CA는 클러스터 관리 부서 인증서로서, 클러스터 내부의 볼트 노드를 인증하는데 사용될 수 있다. Cluster CA is a cluster administration certificate and can be used to authenticate vault nodes within a cluster.

엔드-유저 인증서는 다음과 같이 구성될 수 있다.The end-user certificate can be configured as follows.

Admin #n은 관리자 인증서로서, 각 관리자들이 소지하며 Admin CA가 발급해주어야 유효한 인증서가 된다. Admin 인증서로 서명된 트랜잭션 요청만 유효하다고 판단된다. Admin #n is an administrator certificate, which is owned by each administrator and must be issued by an Admin CA to be a valid certificate. Only transaction requests signed with an Admin certificate are considered valid.

Device #n은 볼트 노드 인증서로서, 각 볼트 노드가 가지고 있으며, Cluster CA가 발급해주어야 유효한 인증서가 된다. 볼트 노드간 통신할 때 인증서로 서명된 데이터는 신뢰할 수 있다.Device #n is a vault node certificate, which is owned by each vault node and must be issued by a cluster CA to be a valid certificate. When communicating between vault nodes, the data signed with the certificate can be trusted.

도 6 내지 도 9은 일 실시예에 따른 키 보관 관리 시스템에서 키를 생성하고 분배하는 것을 설명하기 위한 도면이다. 6 to 9 are diagrams for describing generating and distributing keys in a key storage management system according to an exemplary embodiment.

도 6을 참고하면, CA 인증서를 생성하는 것을 설명하기 위한 도면이다. 모든 볼트 노드에 운영사에서 생성된 소프트웨어로 전달한 CA가 삽입되어 제공될 수 있다. CA는 운영사에서 생성된 것이므로 운영상의 정책이 유효한 장치인지, 운영사에서 승인된 관리자인지 검증하는데 사용될 수 있다. Referring to FIG. 6, a diagram for describing generating a CA certificate. Every vault node can be delivered with an embedded CA delivered by software generated by the operator. Since the CA is generated by the operator, it can be used to verify that the operational policy is a valid device or an administrator authorized by the operator.

도 7를 참고하면, 클러스터의 내부키 B를 생성하는 것을 설명하기로 한다. 데이터센터에서 클러스터를 담당하는 관리자는 볼트 노드를 기준으로 i번째 클러스터를 구성할 수 있다. 먼저, 볼트 노드에 클러스터의 내부키 Bi 생성을 요청할 수 있다. 이때, D키의 생성과 B키의 생성 중 키 생성 순서는 상관없다. 클러스터의 내부키 Bi는 i번째 클러스터에서 볼트 노드들(디바이스)끼리 공유될 BIP-32 root seed를 의미한다.Referring to FIG. 7, the generation of an internal key B of a cluster will be described. The administrator in charge of the cluster in the data center can configure the i th cluster based on the vault nodes. First, it is possible to request the vault node to generate the internal key B i of the cluster. At this time, the order of key generation during generation of D key and generation of B key is irrelevant. The cluster's internal key B i is the BIP-32 root seed that will be shared among the vault nodes (devices) in the ith cluster.

도 8을 참고하면, 클러스터의 내부키 D를 생성하는 것을 설명하기로 한다. i번째 클러스터 내의 모든 볼트 노드들에 대하여 클러스터의 내부키 Di-j 를 생성할 수 있다. 클러스터의 내부키 Di-j는 i번째 클러스터의 j번째 볼트 노드가 가지고 있는 디바이스 고유의 키를 의미한다. 클러스터의 내부키 Di-j를 통해서 디바이스 인증서를 승인받고 저장하는 과정을 다음과 같다. Referring to FIG. 8, it will be described to generate the internal key D of the cluster. The internal key D ij of the cluster can be generated for all bolt nodes in the i th cluster. The internal key D ij of the cluster is a device-specific key held by the j-th vault node of the i-th cluster. The process of receiving and storing a device certificate through the internal key D ij of the cluster is as follows.

관리자가 볼트 노드 j에게 클러스터의 내부키 Di-j에 대한 CSR을 요청할 수 있다. CSR(Certificate Signing Request)이란 공개키 소유자가 CA에게 인증서 발급을 요청하는 형식으로, 인증서를 발급받을 공개키와 공개키 소유자에 대한 정보(도메인 등), 무결성 보호(전자 서명 등)를 포함한다. 볼트 노드 j가 클러스터의 내부키 Di-j에 대한 CSR을 생성하고 관리자에게 내보낼 수 있다. 관리자는 상기 CSR을 이용하여 Device CA에게 서명을 요구할 수 있다. Device CA는 상기 CSR을 검증하고 CSR을 서명하여 클러스터의 내부키 Di-j에 대한 인증서를 생성할 수 있다. 관리자는 상기 생성된 인증서를 볼트 노드 j에 저장할 수 있다. The administrator can ask the vault node j for a CSR for the cluster's internal key D ij . What is a certificate signing request (CSR) The public key holder requests the CA to issue a certificate. Information about the owner (domain, etc.), integrity protection (digital signature, etc.). Vault node j can generate a CSR for the cluster's internal key D ij and export it to the administrator. The administrator can request a signature from the Device CA using the CSR. The device CA may verify the CSR and sign the CSR to generate a certificate for the internal key D ij of the cluster. The administrator can store the generated certificate in the vault node j.

도 9를 참고하면, 클러스터의 B키를 복제하는 것을 설명하기로 한다. 앞서 설명한 바와 같이, 생성된 Bi키는 클러스터 내의 다른 볼트 노드들과 동기화되어 동일한 키를 공유하게 된다. i번째 클러스터에 속한 볼트 노드들이 클러스터의 인트라넷에 연결되면, 볼트 노드는 브릿지 서버로 접속하여 클러스터에 속한 키 정보와 상기 볼트 노드가 저장하고 있는 키 정보를 업데이트할 수 있다. 동기화 과정을 설명하기로 한다. Referring to Figure 9, it will be described to duplicate the B key of the cluster. As described above, the generated Bi key is synchronized with other vault nodes in the cluster to share the same key. When the vault nodes belonging to the i th cluster are connected to the intranet of the cluster, the vault node may connect to the bridge server to update key information belonging to the cluster and key information stored by the vault node. The synchronization process will be described.

볼트 노드가 클러스터의 인트라넷에 연결될 수 있다. 볼트 노드는 브릿지 서버를 통하여 클러스터의 키 목록을 조회할 수 있다. 키 목록 중 볼트 노드 자신에게 존재하지 않는 키가 있을 경우, 키를 보관하고 있는 클러스터 내의 다른 볼트 노드에게 복제를 요청할 수 있다. 키를 보관하고 있는 다른 볼트 노드는 볼트 노드의 요청이 인증된 디바이스로부터 왔는지 여부를 확인한 후, 키를 복제해줄 수 있다. 이때, 키의 복제는 인증서에 기반한 디바이스 인증을 통하여 진행될 수 있다. 예를 들면, 볼트 노드(Vault Node B)는 다른 볼트 노드(Vault Node A)에게 키 내보내기를 요구하면서, 볼트 노드의 인증서를 다른 볼트 노드에게 전송할 수 있다. 다른 볼트 노드는 볼트 노드로부터 전달받은 인증서를 검증한 뒤, 인증서에 포함된 볼트 노드의 공개키를 이용하여 Bi키를 암호화하고, 암호화된Bi키를 볼트 노드에게 전달할 수 있다. 볼트 노드는 암호화된 Bi키를 수신하여 복호화한 뒤 저장할 수 있다. 디바이스가 인증된 디바이스임을 인증하는 주체는 Device CA이므로, Device CA에 키 관리 서명에 대한 철저한 지침이 필요하다. 클러스터 내의 다른 볼트 노드에서 볼트 노드로 키를 복사하는 과정을 구체적으로 설명하기로 한다.The vault node can be connected to the intranet of the cluster. The vault node can query the cluster's key list via the bridge server. If there is a key in the list of keys that does not exist on the vault node itself, you can request replication from another vault node in the cluster that holds the key. The other vault node holding the key can check whether the vault node's request is from an authorized device and then duplicate the key. In this case, the key may be replicated through device authentication based on a certificate. For example, Vault Node B may send a vault node's certificate to another vault node, requiring the vault node A to export a key. Other bolts node may pass after verifying the certificate received from the bolt node, encrypts the key using the public key B i of the bolt node included in the certificate, and the encrypted key to the bolt B i node. The vault node can receive, decrypt, and store the encrypted Bi key. Since the device CA is a device CA that authenticates the device as an authenticated device, the device CA needs strict guidance on key management signatures. The process of copying a key from another vault node in the cluster to the vault node will be described in detail.

도 10를 참고하면, B키로 트랜잭션을 서명하는 것을 설명하기로 한다. 하나의 클러스터가 B키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명할 수 있다. Referring to FIG. 10, signing a transaction with a B key will be described. A cluster can sign a transaction by generating a private key from the B key according to the BIP-32 protocol.

클라우드 서버에서 하나의 클러스터의 익스터널 릴레이에게 서명을 요청할 수 있다. 이때, 서명하려는 키의 BIP-32 root public key(BIP-32 에서 'm'에 해당하는 키의 공개키), 서명하려는 BIP-32 path, 서명하려는 데이터(예를 들면, 트랜잭션 해시 등), 서명을 승인한 관리자의 인증 정보(요청 내용과 연관된 인증 정보를 제시)를 포함하는 데이터가 포함된 서명을 요청할 수 있다.The cloud server can request a signature from an external relay in a cluster. At this time, the BIP-32 root public key of the key to be signed (the public key of the key corresponding to 'm' in BIP-32), the BIP-32 path to be signed, the data to be signed (for example, the transaction hash), and the signature. A signature may be requested that includes data including authentication information (presenting authentication information associated with the request) of the administrator who has approved the request.

클라우드 서버에서 익스터널 릴레이와 인터널 릴레이에게 요청을 전달함에 따라 인터널 릴레이가 볼트 노드를 이용하여 서명을 진행하고, 서명을 진행한 결과를 받아 익스터널 릴레이에게 전달함으로써 최종적으로 클라우드 서버가 획득할 수 있다. 서명을 진행한 결과는 상기 데이터를 BIP-32 path 키로 서명한 secp256k1 ECDSA signature(r, s, v 값)이 포함될 수 있다.As the cloud server forwards the request to the external relay and the internal relay, the internal relay signs the vault using the vault node, receives the result of the signature, and forwards the result to the external relay so that the cloud server finally obtains the request. Can be. The result of the signing may include a secp256k1 ECDSA signature (r, s, v values) which signed the data with a BIP-32 path key.

도 11을 참고하면, 볼트 노드의 신뢰실행환경 내부에 보관된 키들이 잘 보관되고 있는지 여부를 확인하는 감사(Audit)를 수행할 수 있다. 임의의 메시지를 서명하였을 때, 서명이 잘 되는지의 여부를 통해 판단될 수 있다. 감사를 위하여 서명하는 메시지는 8바이트 이내로 제한될 수 있다. B키로 감사하는 과정을 설명하기로 한다. 인터널 릴레이는 볼트 노드에게 임의의 메시지에 대하여 B 키를 이용한 서명을 요청할 수 있다. 이때, 서명하려는 키의 BIP-32 root public key (BIP-32 에서 'm' 에 해당하는 키의 public key)와 8바이트 이내의 임의의 메시지를 포함하는 데이터에 대한 서명을 요청할 수 있다. 비인가된 사용자가 감사 기능을 이용하여 유효한 트랜잭션을 서명하는 것을 방지하기 위하여 메시지의 크기는 8바이트 이내로 제한될 수 있다. 볼트 노드는 서명을 진행하고, 서명을 진행한 결과를 인터널 릴레이에게 반환할 수 있다. 서명을 진행한 결과에는 메시지를 BIP-32 root public key로 서명한 secp256k1 ECDSA signature가 포함될 수 있다. Referring to FIG. 11, an audit may be performed to check whether keys stored in a trusted execution environment of a vault node are well stored. When any message is signed, it can be determined by whether the signature is good. Messages signed for auditing can be limited to 8 bytes. We will explain the process of auditing with the B key. The internal relay can request the vault node to sign any message using the B key. At this time, a signature may be requested for data including a BIP-32 root public key of the key to be signed (the public key of the key corresponding to 'm' in BIP-32) and any message within 8 bytes. The size of the message can be limited to within 8 bytes to prevent unauthorized users from signing valid transactions using the audit function. The vault node can sign and return the result of the signing to the internal relay. The result of the signature may include the secp256k1 ECDSA signature that signed the message with the BIP-32 root public key.

도 12는 일 실시예에 따른 키 보관 관리 시스템의 트랜잭션 방법을 설명하기 위한 흐름도이다. 12 is a flowchart illustrating a transaction method of a key storage management system according to an embodiment.

단계(1210)에서 키 보관 관리 시스템은 노드를 기준으로 클러스터를 구성할 수 있다. 키 보관 관리 시스템은 노드의 신뢰실행환경에서 클러스터의 클러스터의 제1 내부키, 클러스터의 제2 내부키를 포함하는 복수 개의 키를 관리할 수 있다. 이때, 클러스터의 제1 내부키는, BIP-32 루트 시드(Root Seed)이고, 클러스터의 제2 내부키는, 디바이스 인증을 위한 것일 수 있다. 키 보관 관리 시스템은 각각의 노드에 운영사와 관리자를 검증하기 위한 인증서(CA)가 삽입되어 제공되고, 데이터센터에서 각각의 노드를 기준으로 클러스터를 구성하고, 노드에 클러스터의 내부키의 생성을 요청함에 따라 클러스터의 제1 내부키가 생성될 수 있다. 키 보관 관리 시스템은 클러스터 내에 존재하는 모든 노드들에 대하여 클러스터의 제2 내부키를 생성하고, 생성된 클러스터의 제2 내부키를 통하여 디바이스 인증서를 승인받아 저장하고, 클러스터의 제1 내부키가 클러스터 내의 노드들과 동기화되어 키가 공유되고, 클러스터에 속한 노드들이 클러스터의 인트라넷에 연결됨에 따라 노드가 브릿지 서버로 접속하여 클러스터에 속한 키 정보와 노드가 저장하고 있는 키 정보를 업데이트할 수 있다. 키 보관 관리 시스템은 노드가 클러스터의 인트라넷에 연결됨에 따라 노드가 브릿지 서버를 통하여 클러스터의 키 목록을 조회하고, 키 목록 중 상기 노드에 존재하지 않는 키가 있을 경우, 키를 보관하고 있는 클러스터의 다른 노드에게 복제를 요청하고, 다른 노드에서 상기 복제가 요청된 노드가 인증된 디바이스인지 확인한 후, 키를 복제하되, 노드가 다른 노드에게 키 내보내기를 요구함에 따라 노드의 인증서를 다른 노드에게 전달하고, 다른 노드에서 노드의 인증서를 검증함에 따라 인증서에 포함된 노드의 공개키를 이용하여 노드의 클러스터의 제1 내부키를 암호화하고, 암호화된 클러스터의 제1 내부키를 노드에게 전달하고, 노드에서 암호화된 클러스터의 제1 내부키를 복호화하여 저장할 수 있다. In operation 1210, the key storage management system may configure a cluster based on the node. The key storage management system may manage a plurality of keys including the first internal key of the cluster and the second internal key of the cluster in the trusted execution environment of the node. In this case, the first internal key of the cluster may be a BIP-32 root seed, and the second internal key of the cluster may be for device authentication. The key storage management system is provided with a certificate (CA) inserted in each node to verify the operator and the administrator, and forms a cluster based on each node in the data center, and requests the node to generate an internal key of the cluster. As a result, the first internal key of the cluster may be generated. The key storage management system generates a second internal key of the cluster for all nodes existing in the cluster, receives and stores a device certificate through the generated second internal key of the cluster, and the first internal key of the cluster is a cluster. As the nodes are synchronized with the nodes in the key and the nodes are shared, and the nodes in the cluster are connected to the intranet of the cluster, the nodes can connect to the bridge server to update the key information in the cluster and the key information stored in the node. As the node is connected to the intranet of the cluster, the key archiving system looks up the cluster's key list through the bridge server, and if there is a key in the key list that does not exist on the node, the other key in the cluster holds the key. After requesting the node to replicate, verifying that the node requested to be replicated by the other node is an authorized device, and duplicating the key, passing the node's certificate to the other node as the node requires exporting the key to another node, As the other node verifies the node's certificate, encrypts the node's first internal key using the node's public key included in the certificate, passes the encrypted cluster's first internal key to the node, and encrypts the node. The first internal key of the cluster may be decrypted and stored.

단계(1220)에서 키 보관 관리 시스템은 구성된 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 관리되는 복수 개의 키 중 클러스터의 내부키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명할 수 있다. 키 보관 관리 시스템은 클라우드 서버에서 클러스터의 익스터널 릴레이에게 서명하려는 키의 BIP-32 루트 공개키, 서명하려는 BIP-32 path, 서명하려는 데이터, 서명을 승인한 관리자의 인증 정보를 포함하는 서명이 요청되고, 익스터널 릴레이와 별도의 통신 채널을 통하여 통신하는 클러스터 내부의 인터널 릴레이가 클러스터 내부의 노드를 이용하여 서명을 진행한 결과를 익스터널 릴레이에게 전달함에 따라 클라우드 서버에서 획득될 수 있다. 키 보관 관리 시스템은 클러스터의 인터널 릴레이가 클러스터 내부의 노드에게 임의의 메시지에 대하여 클러스터의 제1 내부키를 이용하여 서명하려는 키의 BIP-32 루트 공개키와 8바이트 이내의 임의의 메시지를 포함한 서명을 요청하고, 노드에서 서명을 진행한 결과를 인터널 릴레이에게 반환하여 클러스터의 내부에 보관된 키들을 감사(Audit)할 수 있다.In step 1220, the key archiving management system generates a private key according to the BIP-32 protocol from a cluster's internal key among a plurality of keys managed in a trusted execution environment of a node existing inside the configured cluster. You can sign a transaction. The key archive management system requests a signature from the cloud server that contains the BIP-32 root public key of the key that you want to sign, the BIP-32 path that you want to sign, the data you want to sign, and the administrator's certificate that approved the signature. In addition, the internal relay communicating with the external relay through a separate communication channel may be obtained from the cloud server as the internal relay communicates the result of the signature to the external relay. The key archiving system includes the BIP-32 root public key of the key and any message within 8 bytes of which the internal relay of the cluster wants to sign to the nodes within the cluster using the cluster's first internal key for any message. You can audit the keys stored inside the cluster by requesting a signature and returning the result of signing at the node to the internal relay.

이상에서 설명된 장치는 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). Can be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. It can be embodied in. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like.

이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the claims that follow.

Claims (8)

컴퓨터로 구현되는 키 보관 관리 시스템에서 수행되는 트랜잭션 서명 방법에 있어서,
노드를 기준으로 클러스터를 구성하는 단계; 및
상기 구성된 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 관리되는 복수 개의 키 중 상기 클러스터의 내부키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명하는 단계
를 포함하고,
상기 트랜잭션을 서명하는 단계는,
클라우드 서버에서 클러스터의 익스터널 릴레이에게 서명하려는 키의 BIP-32 루트 공개키, 서명하려는 BIP-32 path, 서명하려는 데이터, 서명을 승인한 관리자의 인증 정보를 포함하는 서명이 요청되고, 상기 익스터널 릴레이와 별도의 통신 채널을 통하여 통신하는 클러스터 내부의 인터널 릴레이가 클러스터 내부의 노드를 이용하여 서명을 진행한 결과를 상기 익스터널 릴레이에게 전달함에 따라 상기 클라우드 서버에서 획득되는 단계
를 포함하는 트랜잭션 서명 방법. In the transaction signature method performed in a computer-implemented key storage management system,
Configuring a cluster based on the node; And
Signing a transaction by generating a private key according to the BIP-32 protocol from an internal key of the cluster among a plurality of keys managed in a trusted execution environment of a node existing in the configured cluster
Including,
Signing the transaction,
In the cloud server, the external relay of the cluster is requested a signature including the BIP-32 root public key of the key to be signed, the BIP-32 path to be signed, the data to be signed, and the authentication information of the administrator who approved the signature. Acquiring at the cloud server as an internal relay in a cluster communicating with a relay through a separate communication channel transmits a result of signing using a node in the cluster to the external relay.
Transaction signature method comprising a. 삭제delete 제1항에 있어서,
상기 트랜잭션을 서명하는 단계는,
상기 클러스터의 인터널 릴레이가 상기 클러스터 내부의 노드에게 임의의 메시지에 대하여 클러스터의 제1 내부키를 이용하여 서명하려는 키의 BIP-32 루트 공개키와 8바이트 이내의 임의의 메시지를 포함한 서명을 요청하고, 상기 노드에서 서명을 진행한 결과를 상기 인터널 릴레이에게 반환하여 상기 클러스터의 내부에 보관된 키들을 감사(Audit)하는 단계
를 포함하는 트랜잭션 서명 방법. The method of claim 1,
Signing the transaction,
The internal relay of the cluster requests a node within the cluster to sign a random message including a BIP-32 root public key of the key to be signed using the cluster's first internal key and any message within 8 bytes. Auditing the keys stored in the cluster by returning the result of the signing in the node to the internal relay.
Transaction signature method comprising a. 제1항에 있어서,
상기 클러스터를 구성하는 단계는,
상기 노드의 신뢰실행환경에서 클러스터의 클러스터의 제1 내부키, 클러스터의 제2 내부키를 포함하는 복수 개의 키를 관리하는 단계
를 포함하고,
상기 클러스터의 제1 내부키는, BIP-32 루트 시드(Root Seed)이고,
상기 클러스터의 제2 내부키는, 디바이스 인증을 위한 것인, 트랜잭션 서명 방법. The method of claim 1,
The step of configuring the cluster,
Managing a plurality of keys including a first internal key of a cluster and a second internal key of a cluster in a trusted execution environment of the node
Including,
The first internal key of the cluster is a BIP-32 root seed,
And the second internal key of the cluster is for device authentication. 컴퓨터로 구현되는 키 보관 관리 시스템에서 수행되는 트랜잭션 서명 방법에 있어서,
노드를 기준으로 클러스터를 구성하는 단계; 및
상기 구성된 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 관리되는 복수 개의 키 중 상기 클러스터의 내부키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명하는 단계
를 포함하고,
상기 클러스터를 구성하는 단계는,
노드에 운영사와 관리자를 검증하기 위한 인증서(CA)가 삽입되어 제공되고, 데이터센터에서 상기 인증서가 삽입된 노드를 기준으로 클러스터를 구성하고, 상기 인증서가 삽입된 노드에 클러스터의 내부키의 생성을 요청함에 따라 클러스터의 제1 내부키가 생성되는 단계
를 포함하는 트랜잭션 서명 방법. In the transaction signature method performed in a computer-implemented key storage management system,
Configuring a cluster based on the node; And
Signing a transaction by generating a private key according to the BIP-32 protocol from an internal key of the cluster among a plurality of keys managed in a trusted execution environment of a node existing in the configured cluster
Including,
The step of configuring the cluster,
Certificates (CAs) for verifying operators and administrators are inserted into the nodes, and a cluster is formed based on the node in which the certificate is inserted in the data center, and generation of the internal key of the cluster is performed on the node where the certificate is inserted. Generating a first internal key of the cluster as requested
Transaction signature method comprising a. 제5항에 있어서,
상기 클러스터를 구성하는 단계는,
상기 클러스터 내에 존재하는 모든 노드들에 대하여 클러스터의 제2 내부키를 생성하고, 상기 생성된 클러스터의 제2 내부키를 통하여 디바이스 인증서를 승인받아 저장하고,
상기 클러스터의 제1 내부키가 클러스터 내의 노드들과 동기화되어 키가 공유되고, 상기 클러스터에 속한 노드들이 클러스터의 인트라넷에 연결됨에 따라 상기 인증서가 삽입된 노드가 브릿지 서버로 접속하여 상기 클러스터에 속한 키 정보와 상기 인증서가 삽입된 노드가 저장하고 있는 키 정보를 업데이트하는 단계
를 포함하는 트랜잭션 서명 방법.The method of claim 5,
The step of configuring the cluster,
Generate a second internal key of the cluster for all nodes existing in the cluster, receive and store a device certificate through the generated second internal key of the cluster,
As the first internal key of the cluster is synchronized with the nodes in the cluster, the key is shared, and as the nodes belonging to the cluster are connected to the intranet of the cluster, the node into which the certificate is inserted is connected to the bridge server, and the key belongs to the cluster. Updating the information and the key information stored in the node into which the certificate is inserted.
Transaction signature method comprising a. 제6항에 있어서,
상기 클러스터를 구성하는 단계는,
상기 인증서가 삽입된 노드가 상기 클러스터의 인트라넷에 연결됨에 따라 상기 인증서가 삽입된 노드가 브릿지 서버를 통하여 클러스터의 키 목록을 조회하고, 상기 조회된 키 목록 중 상기 인증서가 삽입된 노드에 존재하지 않는 키가 있을 경우, 상기 존재하지 않는 키를 보관하고 있는 상기 클러스터의 다른 노드에게 복제를 요청하고, 상기 다른 노드에서 상기 복제를 요청한 노드가 인증된 디바이스인지 확인한 후, 상기 존재하지 않는 키를 복제하되, 상기 인증서가 삽입된 노드가 상기 다른 노드에게 키 내보내기를 요구함에 따라 상기 인증서가 삽입된 노드의 인증서를 상기 다른 노드에게 전달하고, 상기 다른 노드에서 상기 인증서가 삽입된 노드의 인증서를 검증함에 따라 상기 인증서에 포함된 상기 인증서가 삽입된 노드의 공개키를 이용하여 상기 인증서가 삽입된 노드의 클러스터의 제1 내부키를 암호화하고, 상기 암호화된 클러스터의 제1 내부키를 상기 인증서가 삽입된 노드에게 전달하고, 상기 인증서가 삽입된 노드에서 상기 암호화된 클러스터의 제1 내부키를 복호화하여 저장하는 단계
를 포함하는 트랜잭션 서명 방법.The method of claim 6,
The step of configuring the cluster,
As the node into which the certificate is inserted is connected to the intranet of the cluster, the node into which the certificate is inserted inquires the cluster's key list through the bridge server, and the node in which the certificate is inserted does not exist in the node in which the certificate is inserted. If there is a key, request replication to another node in the cluster that holds the nonexistent key, verify that the node requesting the replication from the other node is an authorized device, and then duplicate the nonexistent key. And as the node inserted with the certificate requests the other node to export the key, transfer the certificate of the node in which the certificate is inserted to the other node, and verify the certificate of the node in which the certificate is inserted in the other node. By using the public key of the node in which the certificate included in the certificate is inserted Encrypting the first internal key of the cluster of the node where the certificate is inserted, transferring the first internal key of the encrypted cluster to the node where the certificate is inserted, and generating the first internal key of the encrypted cluster at the node where the certificate is inserted. 1 Decrypting and storing the internal key
Transaction signature method comprising a. 컴퓨터로 구현되는 키 보관 관리 시스템에서 수행되는 트랜잭션 서명 방법에 있어서,
노드를 기준으로 클러스터를 구성하는 단계; 및
상기 구성된 클러스터의 내부에 존재하는 노드의 신뢰실행환경(Trusted Execution Environment)에서 관리되는 복수 개의 키 중 상기 클러스터의 내부키로부터 BIP-32 프로토콜에 따라 개인키를 생성하여 트랜잭션을 서명하는 단계
를 포함하고,
상기 키 보관 관리 시스템은,
복수의 클러스터로 구성되고,
상기 복수의 클러스터는, 복수 개의 노드(Node), 메타데이터 데이터베이스(Metadata Database), 인터널 릴레이(Internal Relay)를 포함하는 내부 컴포넌트들과 상기 인터널 릴레이와 통신하는 익스터널 릴레이(External Relay)로 구성되고,
상기 내부 컴포넌트들이 외부망과 분리된 상태로, 내부 컴포넌트 간 인트라넷으로 연결되고, 클러스터의 내부와 외부 사이에 인터넷 이외의 별도의 채널을 통해 온-디맨드(On-Demand)로 연결되고, 상기 클러스터의 익스터널 릴레이와 클라우드 서버 사이에 인터넷으로 연결되는
트랜잭션 서명 방법.In the transaction signature method performed in a computer-implemented key storage management system,
Configuring a cluster based on the node; And
Signing a transaction by generating a private key according to the BIP-32 protocol from an internal key of the cluster among a plurality of keys managed in a trusted execution environment of a node existing in the configured cluster
Including,
The key storage management system,
Consists of multiple clusters,
The plurality of clusters may include internal components including a plurality of nodes, a metadata database, and an internal relay, and an external relay communicating with the internal relay. Composed,
The internal components are separated from the external network, connected to an intranet between internal components, and connected on-demand through a separate channel other than the Internet between the inside and outside of the cluster, Internet connection between external relay and cloud server
Transaction signature method.
KR1020190016464A 2019-02-13 2019-02-13 System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment KR102046424B1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020190016464A KR102046424B1 (en) 2019-02-13 2019-02-13 System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment
US16/698,439 US11405198B2 (en) 2019-02-13 2019-11-27 System and method for storing and managing keys for signing transactions using key of cluster managed in trusted execution environment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020190016464A KR102046424B1 (en) 2019-02-13 2019-02-13 System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment

Publications (2)

Publication Number Publication Date
KR102046424B1 true KR102046424B1 (en) 2019-11-19
KR102046424B9 KR102046424B9 (en) 2022-07-18

Family

ID=68771033

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020190016464A KR102046424B1 (en) 2019-02-13 2019-02-13 System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment

Country Status (1)

Country Link
KR (1) KR102046424B1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111143168A (en) * 2019-12-25 2020-05-12 曙光信息产业(北京)有限公司 Monitoring management method and system for cluster service

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1811731A1 (en) * 2004-10-27 2007-07-25 Ionos Co., Ltd. Data amount monitoring control system of channels
KR101776172B1 (en) * 2017-02-14 2017-09-07 주식회사 유니온플레이스 Internet of things device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1811731A1 (en) * 2004-10-27 2007-07-25 Ionos Co., Ltd. Data amount monitoring control system of channels
KR101776172B1 (en) * 2017-02-14 2017-09-07 주식회사 유니온플레이스 Internet of things device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FRITSCHE RICARDO VIEIRA, RECOMMENDATOINS FOR IMPLEMENTING A BITCOIN WALLET USING SMART CARD, UFSC(UNIVERSIDADE FEDERAL DE SANTA CATARINA) (2018)* *
Steven Goldfeder 외 6명, Securing Bitcoin wallets via a new DSA/ECDSA threshold signature scheme (2015)* *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111143168A (en) * 2019-12-25 2020-05-12 曙光信息产业(北京)有限公司 Monitoring management method and system for cluster service
CN111143168B (en) * 2019-12-25 2023-08-15 曙光信息产业(北京)有限公司 Monitoring management method and system for cluster service

Also Published As

Publication number Publication date
KR102046424B9 (en) 2022-07-18

Similar Documents

Publication Publication Date Title
CN110546636B (en) Confidentiality in federated blockchain networks
US11636216B2 (en) System and methods for tamper proof interaction recording and timestamping
CN110268691B (en) Federated blockchain networks with verified blockchain and consensus protocols
JP3640339B2 (en) System for retrieving electronic data file and method for maintaining the same
CA2256934C (en) System for electronic repository of data enforcing access control on data retrieval
US8997198B1 (en) Techniques for securing a centralized metadata distributed filesystem
US8788815B1 (en) System and method for controlling access to decrypted data
US11405198B2 (en) System and method for storing and managing keys for signing transactions using key of cluster managed in trusted execution environment
US20190050598A1 (en) Secure data storage
US11121876B2 (en) Distributed access control
US11626998B2 (en) Validated payload execution
US11861027B2 (en) Enhanced securing of data at rest
US20220237311A1 (en) Enhanced Securing and Secured Processing of Data at Rest
KR102046424B1 (en) System and method for storing and managing keys for signing transactions based on a bip-32 protocol from an internal key of a cluster managed in a trusted execution environment
CN109690550B (en) Digital Asset Architecture
US9641325B1 (en) Server systems for distributed cryptographic protocols
KR102664379B1 (en) A decentralized data sharing system and Collusion-Resistant Multi-Authority Attribute-Based Encryption Scheme based on a Blockchain
US11893577B2 (en) Cryptographic key storage system and method
KR102046425B1 (en) System and method for storing and managing keys for signing transactions based on a threshold signature scheme using a key of a cluster managed in a trusted execution environment
US12014361B2 (en) Systems and methods for improved hot wallet security
WO2024072708A1 (en) Methods for controlling access to shared configuration in a role-based, multi-admin centralized or distributed system and devices thereof

Legal Events

Date Code Title Description
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
G170 Re-publication after modification of scope of protection [patent]