Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method for providing a registration service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computing device, is configured to perform a predetermined procedure when particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computing device, comprising steps of: (a) an intermediate server, when (i) a specific public key PubA corresponding to a user device of a specific user, (ii) an IdhashA which is a hash value of personal information of the specific user, and (iii) a VcertA which includes one or more validity conditions on the specific certificate, are acquired, performing or supporting another device to perform a process of creating the specific smart contract SC(VcertA) corresponding to the validity conditions, and a process of acquiring at least one specific Byte Code BC(SC(VcertA)) into which the specific smart contract is compiled; (b) the intermediate server, when the specific byte code is acquired, performing or supporting another device to perform a process of registering the specific public key PubA, the IdhashA and the specific byte code BC(SC(VcertA)) as information of the specific certificate with a private blockchain database, and a process of acquiring PrivTxidA as referential information of the specific certificate, which is a locator of the information of the specific certificate in the private blockchain database; (c) the intermediate server, when the PrivTxidA is acquired, performing or supporting another device to perform a process of setting a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) as an initial state, and a process of registering the PrivTxidA and the specific state S(SC(VcertA)) with State Database (SDB); and (d) the intermediate server, when one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, performing or supporting another device to perform (I) a process of acquiring a specific representative hash value or its processed value calculated by using a specific hash value and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the specific hash value is calculated by using the specific public key PubA, the IdhashA and the specific byte code BC(SC(VcertA)), and wherein the neighboring hash value includes (i) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, (ii) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (ii-1) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (ii-2) the states of the SDB are identifiable by PrivTxids which represent respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (ii-3) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (II) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a system for securely registering and managing digital certificates using smart contracts and blockchain technology. The problem addressed is ensuring the integrity and verifiability of certificate registration processes, particularly in environments requiring high security and transparency. The method involves creating a specific smart contract that enforces predefined validity conditions for a digital certificate. The smart contract is compiled into executable bytecode and registered in a private blockchain database along with a user's public key and hashed personal information. The registration process generates a transaction identifier (PrivTxid) that serves as a locator for the certificate data. The smart contract's initial state is then recorded in a separate State Database (SDB). To enhance security and traceability, the system periodically anchors data from the private blockchain to a public blockchain. When certain conditions are met, the system calculates a representative hash value using the certificate's public key, hashed personal data, and the smart contract's bytecode. This hash value is combined with neighboring hash values from other certificates and the SDB's state changes. The SDB tracks all variations of smart contract states, identifiable by their respective PrivTxids. The final representative hash or its processed form is then recorded in the public blockchain, ensuring tamper-proof verification of the certificate's registration and state history. This approach provides a decentralized and auditable method for managing certificate validity and integrity.
2. The method of claim 1 , further comprising a step of: (e) the intermediate server, when the specific public key PubA, the IdhashA and the specific byte code BC(SC(VcertA)) are registered with the private blockchain database, performing or supporting another device to perform a process of transmitting the PrivTxidA and a response indicating a registration to a certain server to thereby instruct the certain server to transmit a completion message indicating the registration of the specific certificate to the user device, wherein the completion message includes the PrivTxidA.
This invention relates to a system for securely registering and verifying digital certificates using a private blockchain database. The problem addressed is ensuring secure and verifiable registration of certificates while maintaining privacy and preventing unauthorized access. The system involves a user device, an intermediate server, and a private blockchain database. The user device generates a specific public key (PubA), a certificate (VcertA), and a hash of an identifier (IdhashA). The intermediate server receives these elements and a specific byte code (BC(SC(VcertA))) derived from the certificate. The server then registers these elements in the private blockchain database, creating a private transaction ID (PrivTxidA). Upon successful registration, the intermediate server or another device transmits the PrivTxidA and a registration response to a certain server, instructing it to send a completion message to the user device. This completion message confirms the registration and includes the PrivTxidA, allowing the user device to verify the registration status. The system ensures that only authorized parties can access the registration details while providing verifiable proof of registration to the user. The use of blockchain technology enhances security and immutability, preventing tampering with the registration records.
3. The method of claim 1 , wherein, at the step of (a), the intermediate server performs or supports another device to perform (a1) a process of confirming whether the specific public key PubA and its processed value are registered; and (a2) a process of transmitting, when the specific public key PubA and its processed value are registered, a message indicating that the specific public key PubA acquired from the user device is already registered.
This invention relates to a method for managing public keys in a secure communication system, particularly addressing the challenge of preventing duplicate registration of public keys to enhance security and efficiency. The method involves an intermediate server that verifies whether a specific public key (PubA) and its processed value are already registered in the system. If they are registered, the server transmits a message to the user device indicating that the public key is already registered, preventing redundant entries and potential security risks. The intermediate server may either perform this verification itself or delegate the task to another device. The processed value of the public key could be a hash or other derived form used for comparison. This ensures that only unique public keys are registered, maintaining the integrity of the system. The method is part of a broader system for secure communication, where public keys are used for authentication and encryption. By confirming registration status before proceeding, the system avoids conflicts and ensures reliable key management.
4. The method of claim 1 , wherein, the IdhashA is a hash value of the personal information including at least one of the specific user's name, birth date, contact information, and e-mail address.
This invention relates to a method for securely processing personal information by generating a hash value (IdhashA) from specific user data. The method addresses the challenge of protecting sensitive personal information while enabling its use in identification or verification processes. The personal information used to generate IdhashA includes at least one of the user's name, birth date, contact information, or email address. This hashed value serves as a unique identifier that can be used in place of raw personal data, reducing exposure of sensitive information. The method ensures that the original personal data is not directly stored or transmitted, enhancing privacy and security. The hash function applied to the personal information produces a fixed-length output, making it suitable for database indexing, authentication, or cross-referencing without revealing the underlying data. This approach is particularly useful in systems requiring user identification while minimizing privacy risks. The invention may be applied in identity verification, access control, or data management systems where personal information must be processed securely.
5. The method of claim 1 , wherein, the validity conditions VcertA of the specific certificate are based on at least part of (i) information on the specific user's characteristics, (ii) weather information at a time of using the specific certificate, (iii) date information at the time of using the specific certificate, (iv) information on at least one person allowed to use the specific certificate, and (v) information on a predetermined count of usage of the specific certificate.
This invention relates to a certificate validation system that dynamically determines the validity of a certificate based on multiple contextual factors. The system addresses the problem of static certificate validation, which lacks adaptability to real-world conditions, leading to security risks or unnecessary restrictions. The method involves evaluating a specific certificate's validity conditions (VcertA) by analyzing various inputs. These include user characteristics, such as identity or role, to ensure only authorized individuals can use the certificate. Weather information at the time of use is considered to restrict or permit access based on environmental conditions, such as allowing access only during clear weather for outdoor operations. Date information ensures the certificate is valid only within a specific timeframe. The system also checks against a predefined list of authorized users to prevent unauthorized access. Additionally, the certificate's usage count is tracked, allowing validation only up to a predetermined limit, preventing overuse or abuse. This dynamic validation approach enhances security and flexibility in certificate-based authentication systems.
6. The method of claim 1 , wherein, at the step of (d), the anchoring conditions include at least one of (i) a condition that a certain number of the specific hash value and the neighboring hash value are acquired or generated, (ii) a condition that a certain amount of time is elapsed, (iii) a condition that the n-th block is created in the private blockchain database, and (iv) a condition that has at least one of characteristics of services.
This invention relates to a method for managing data in a private blockchain system, addressing challenges in ensuring data integrity and consistency across distributed nodes. The method involves generating a specific hash value for a data block, storing it in a private blockchain database, and periodically anchoring the data to a public blockchain to enhance security and verifiability. The anchoring process is triggered by predefined conditions, which may include accumulating a certain number of specific and neighboring hash values, waiting for a specified time period, reaching a specific block number (e.g., the n-th block) in the private blockchain, or meeting service-specific characteristics. These conditions ensure that data is anchored at regular intervals or based on operational requirements, improving reliability and traceability. The method also involves verifying the anchored data against the public blockchain to confirm its integrity. This approach enhances the security and trustworthiness of private blockchain systems by leveraging the immutability and transparency of public blockchains while maintaining the efficiency and privacy of private blockchains.
7. The method of claim 6 , wherein the intermediate server records or supports another device to record an SDB header hash value in a block header of the n-th block when the n-th block is created in the private blockchain database, and wherein the SDB header hash value is a hash value calculated by using information on the states of the SDB or all the variations of the SDB.
This invention relates to blockchain technology, specifically methods for securing and verifying data in a private blockchain database (SDB). The problem addressed is ensuring the integrity and traceability of data states within a private blockchain, where data may be frequently updated or modified. The solution involves recording a hash value of the SDB header in the block header of a newly created block (the n-th block) within the private blockchain. This hash value, referred to as the SDB header hash value, is computed using information representing the current state of the SDB or all possible variations of the SDB. The intermediate server either records this hash value itself or supports another device in recording it. This mechanism ensures that any changes to the SDB are cryptographically verifiable, providing a tamper-evident record of the SDB's state at the time the block is created. The recorded hash value can later be used to validate the integrity of the SDB data, ensuring that it has not been altered since the block was created. This approach enhances the security and reliability of private blockchain systems by linking the blockchain's block headers to the state of the SDB, creating an auditable trail of data changes.
8. The method of claim 7 , wherein, at the step of (d), on condition that (i) a certificate representative hash value is generated from a Merkle tree whose leaf nodes include hash values calculated by using public keys, personal information hash values, and byte codes, and (ii) a message representative hash value is generated from a Merkle tree whose leaf nodes include hash values calculated by using (ii-1) message data which include approval information or their processed values corresponding to approvals of certificates, or revocation requesting information or their processed values corresponding to revocations of the certificates, the certificates being referred to by locators of transactions (ii-2) signature values of the message data, and (ii-3) the locators, and (iii) the certificate representative hash value and the message representative hash value are further recorded in the block header of the n-th block, the intermediate server registers or supports another device to register the SDB header hash value, the certificate representative hash value and the message representative transaction hash value or their processed values with the public blockchain database, wherein the public keys include the specific public key PubA and the associated public key, which are used as elements for calculating hash values recorded in the n-th block, wherein the personal information hash values include the IdhashA and the Idhash_OTHERS, which are used as elements for calculating hash values recorded in the n-th block, wherein the byte codes include the specific byte code BC(SC(VcertA)) and the associated byte code, which are used as elements for calculating hash values recorded in the n-th block, and wherein the locators include the PrivTxidA and the PrivTxids in the n-th block.
This invention relates to a blockchain-based system for securely managing certificates and approval/revocation transactions. The system addresses the challenge of verifying certificate authenticity and transaction integrity in a decentralized manner. The method involves generating two Merkle trees: one for certificates and another for messages. The certificate Merkle tree includes hash values derived from public keys (including a specific public key PubA and associated keys), personal information hashes (such as IdhashA and Idhash_OTHERS), and byte codes (including a specific byte code BC(SC(VcertA)) and associated codes). The message Merkle tree includes hash values derived from message data (containing approval or revocation information), signature values of the message data, and transaction locators (such as PrivTxidA and PrivTxids). The root hashes of these Merkle trees, along with a block header hash, are recorded in the n-th block of a public blockchain. An intermediate server or another device registers these hash values or their processed forms with the blockchain, ensuring tamper-proof verification of certificates and transactions. The system enhances security by linking certificates and transactions through cryptographic hashes, preventing unauthorized modifications.
9. The method of claim 7 , wherein, at the step of (d), on condition that a private representative hash value is generated from a Merkle tree whose leaf nodes include (i) hash values calculated by using public keys, personal information hash values, and byte codes, and (ii) hash values calculated by using (ii-1) message data which include approval information or their processed values corresponding to approvals of certificates, or revocation requesting information or their processed values corresponding to revocations of the certificates, certificates being referred to by locators of transactions (ii-2) signature values of the message data, and (ii-3) the locators, and (iii) the private representative hash value is further recorded in the block header of the n-th block, the intermediate server registers or supports another device to register the SDB header hash value, the private representative hash value or their processed values with the public blockchain database, wherein the public keys include the specific public key PubA and the associated public key, which are used as elements for calculating hash values recorded in the n-th block, wherein the personal information hash values include the IdhashA and the Idhash_OTHERS, which are used as elements for calculating hash values recorded in the n-th block, wherein the byte codes include the specific byte code BC(SC(VcertA)) and the associated byte code, which are used as elements for calculating hash values recorded in the n-th block, and wherein the locators include the PrivTxidA and the PrivTxids in the n-th block.
This invention relates to a method for securely registering data in a public blockchain database, particularly for managing certificates and their approvals or revocations. The method addresses the challenge of ensuring the integrity and authenticity of certificate-related transactions while maintaining privacy. The method involves generating a private representative hash value from a Merkle tree structure. The leaf nodes of this Merkle tree include hash values derived from public keys, personal information hash values, and byte codes. Additionally, the leaf nodes incorporate hash values calculated from message data containing approval or revocation information for certificates, along with their corresponding signature values and locators. These locators reference transactions within the blockchain. The private representative hash value is then recorded in the block header of the n-th block. An intermediate server or another device registers this hash value, or a processed version of it, with the public blockchain database. The public keys used include a specific public key (PubA) and an associated public key, while the personal information hash values include IdhashA and Idhash_OTHERS. The byte codes used are a specific byte code (BC(SC(VcertA))) and an associated byte code. The locators include PrivTxidA and PrivTxids from the n-th block. This approach ensures that certificate-related transactions are securely and verifiably recorded on the blockchain, while protecting sensitive personal information through hashing and selective disclosure.
10. The method of claim 1 , wherein, at the step of (d), the intermediate server performs or supports another device to perform (i) a process of creating at least one Merkle tree by allotting the specific hash value to its a leaf node, and (ii) a process of registering, when the anchoring conditions are satisfied, the specific representative hash value or its processed value calculated by using the specific hash value of a specific leaf node and at least one hash value allocated to at least one of other leaf nodes corresponding to the specific leaf node with the public blockchain database.
This invention relates to blockchain-based data anchoring systems, specifically addressing the need for secure and verifiable data storage by leveraging Merkle trees and public blockchain databases. The method involves an intermediate server that facilitates the creation of at least one Merkle tree, where a specific hash value is assigned to a leaf node within the tree. The server or another device then performs a process to register a representative hash value or its processed form with a public blockchain database when predefined anchoring conditions are met. The representative hash value is derived using the specific hash value of the target leaf node and at least one additional hash value from other leaf nodes linked to the target leaf node. This ensures data integrity and tamper-proof verification by anchoring the hash values in a decentralized blockchain network. The system enhances security by distributing the responsibility of data anchoring between the intermediate server and other devices, improving reliability and reducing single points of failure. The method is particularly useful in applications requiring immutable and transparent data records, such as supply chain tracking, digital identity verification, and financial transactions.
11. The method of claim 10 , wherein, when the Merkle tree is a first tree among two or more Merkle trees linked in chains, a hash value or its processed value of a message data, which includes text, numbers or symbols, is allocated to a first leaf node of the Merkle tree.
This invention relates to cryptographic data structures, specifically methods for organizing and verifying data in linked Merkle trees. The problem addressed involves efficiently managing and authenticating data across multiple interconnected Merkle trees, ensuring integrity and traceability of message data containing text, numbers, or symbols. The method involves using a Merkle tree structure where message data is hashed and assigned to a leaf node. When the Merkle tree is part of a chain of two or more linked trees, the hash value or a processed version of this hash is placed in the first leaf node of the tree. This approach allows for secure and verifiable data storage and retrieval, particularly in distributed systems where data integrity must be maintained across multiple trees. The linking of trees enables efficient verification of data consistency and provenance, reducing computational overhead while ensuring cryptographic security. The processed hash value may undergo additional transformations, such as further hashing or encoding, before being allocated to the leaf node. This ensures compatibility with different cryptographic protocols and enhances security. The method supports applications in blockchain, distributed ledgers, and other systems requiring tamper-proof data verification. By structuring data in this way, the invention facilitates scalable and efficient auditing of linked data structures while maintaining cryptographic guarantees.
12. The method of claim 10 , wherein, when the anchoring conditions are satisfied, (x1) the intermediate server calculates or supports another device to calculate an intermediate value by using (i) the specific hash value and (ii) a hash value allocated to a sibling node of the specific leaf node, and then allocates or supports another device to allocate a hash value of the intermediate value to a parent node of the specific leaf node, (x2) the intermediate server, when the parent node is a root node of the Merkle tree, registers or supports another device to register the hash value of the intermediate value with the public blockchain database as the specific representative hash value, and (x3) the intermediate server, when the parent node is not the root node, repeats or supports another device to repeat steps from (x1) to (x3) by regarding the hash value of the intermediate value as the specific hash value and regarding the parent node as the specific leaf node.
This invention relates to a method for updating a Merkle tree structure in a blockchain system, addressing the need for efficient and secure hash value propagation in distributed ledger technologies. The method involves an intermediate server that calculates or supports another device in calculating an intermediate hash value using a specific hash value from a leaf node and a hash value from a sibling node of that leaf. The intermediate hash value is then allocated to the parent node of the leaf node. If the parent node is the root node of the Merkle tree, the intermediate hash value is registered as a representative hash value in a public blockchain database. If the parent node is not the root, the process repeats iteratively, treating the intermediate hash value as the new specific hash value and the parent node as the new leaf node, until the root is reached. This ensures that changes in leaf nodes are reflected in the root hash value, maintaining the integrity and consistency of the Merkle tree structure. The method supports distributed computation, allowing other devices to perform calculations and registrations, enhancing scalability and fault tolerance in blockchain networks.
13. The method of claim 12 , wherein, when no hash value is allocated to the sibling node of the specific leaf node even though the anchoring conditions are satisfied, the intermediate server allocates or supports another device to allocate a certain hash value to the sibling node then performs or supports another device to perform the steps of (x1) to (x3).
This invention relates to a method for managing hash values in a distributed ledger or blockchain system, particularly addressing the issue of incomplete or missing hash allocations in a Merkle tree structure. The method ensures data integrity and consistency by handling cases where a sibling node of a specific leaf node lacks a hash value despite satisfying predefined anchoring conditions. When this occurs, an intermediate server or another device allocates a hash value to the sibling node. The system then performs three key steps: (x1) generating a hash value for the sibling node, (x2) storing the generated hash value in a distributed ledger, and (x3) updating the Merkle tree structure to reflect the new hash allocation. This process ensures that all nodes in the Merkle tree are properly anchored, maintaining the integrity of the data structure. The method is particularly useful in decentralized systems where multiple devices may contribute to ledger updates, ensuring that missing hash values do not compromise the security or reliability of the stored data. The solution automates the allocation and verification of hash values, reducing the risk of errors and improving the efficiency of distributed ledger operations.
14. The method of claim 1 , wherein, when the intermediate server stores the specific hash value and the at least one neighboring hash value in a first data structure and then stores and manages a second data structure identical in a form to the first data structure, the first data structure and the second data structure are connected in a form of a chain.
This invention relates to data storage and management systems, specifically for maintaining and organizing hash values in a secure and efficient manner. The problem addressed is the need for a robust system to store and manage hash values while ensuring data integrity and enabling efficient retrieval. The solution involves using multiple interconnected data structures to store and manage hash values, enhancing security and reliability. The method involves storing a specific hash value and at least one neighboring hash value in a first data structure. A second data structure, identical in form to the first, is then created and managed. These data structures are connected in a chain, forming a linked structure that improves data integrity and retrieval efficiency. The chained data structures allow for redundancy and fault tolerance, ensuring that if one data structure is compromised or lost, the other can be used to recover or verify the data. This approach is particularly useful in systems where data integrity and security are critical, such as blockchain, distributed ledgers, or secure databases. The chained data structures provide a mechanism for cross-verification and error detection, enhancing the overall reliability of the stored data.
15. The method of claim 14 , wherein, when the first data structure and the second data structure are Merkle trees, a root value of the first data structure or a hash value of the root value is allocated to a first leaf node of the second data structure.
This invention relates to data structures and cryptographic techniques for securely linking or verifying relationships between two data structures, particularly Merkle trees. The problem addressed is ensuring the integrity and authenticity of data when transferring or comparing information between different data structures, such as in blockchain systems, distributed ledgers, or other cryptographic applications. The method involves using a first data structure and a second data structure, where the second data structure is used to verify or reference the first. When both data structures are Merkle trees, a root value of the first Merkle tree or a hash of that root value is assigned to a leaf node of the second Merkle tree. This ensures that the second data structure cryptographically references the first, allowing for efficient verification of the relationship between them. The root value or its hash acts as a commitment to the entire first data structure, enabling tamper detection and proof of consistency. The method may also include generating a proof of inclusion for a specific data element within the first data structure, which can be verified using the second data structure. This is useful in scenarios where data integrity must be maintained across multiple systems or when auditing transactions in a blockchain. The approach leverages the properties of Merkle trees, such as efficient verification and compact proofs, to enhance security and scalability in distributed systems.
16. The method of claim 1 , wherein, when no information is acquired from the user device during the step of (a), (b), and (c), and then, at the step of (d), when the anchoring conditions are satisfied, the intermediate server performs or supports another device to perform a process of creating a Merkle tree by allotting a message data to first and second nodes, and a process of registering a root value of the Merkle tree or its processed value with the public blockchain database.
This invention relates to a method for securely registering data on a public blockchain when a user device fails to provide information. The method addresses the problem of ensuring data integrity and immutability in decentralized systems when direct user interaction is unavailable. The system involves an intermediate server that monitors user device activity and, when no information is acquired from the user device, proceeds to anchor data to a blockchain. The anchoring process includes creating a Merkle tree by assigning message data to first and second nodes, then registering the root value of the Merkle tree or a processed version of it with a public blockchain database. This ensures that the data is cryptographically verifiable and tamper-proof. The method supports either the intermediate server or another device to perform these steps, enhancing flexibility in deployment. The use of Merkle trees provides efficient data verification, while blockchain registration ensures long-term integrity. This approach is particularly useful in scenarios where user devices may be offline or unresponsive, ensuring that critical data is still securely recorded.
17. A method for providing an approval service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computing device, is configured to perform a predetermined procedure when particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computing device, comprising steps of: (a) an intermediate server, on condition that (i) a specific public key PubA corresponding to a user device of a specific user, (ii) an IdhashA which is a hash value of personal information of the specific user, and (iii) a specific byte code BC(SC(VcertA)) into which a specific smart contract SC(VcertA) corresponding to a VcertA which includes one or more validity conditions on the specific certificate is compiled, are recorded at a location indicated by a PrivTxidA which is a locator of a specific transaction registered with a private blockchain database, and that the PrivTxidA and a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) are registered with a State Database (SDB), performing or supporting another device to perform a process of acquiring an approval request of the specific certificate which is a message requesting an approval of the specific certificate based on the specific smart contract SC(VcertA); (b) the intermediate server, when the approval request of the specific certificate is acquired, performing or supporting another device to perform a process of transmitting the PrivTxidA and a Transaction ID (TI), which includes information on a subject of an approval, created in response to the approval request, to the user device, and a process of instructing the user device to sign the TI or its processed value TI′ with a specific private key PrivA corresponding to the specific public key PubA to thereby generate a signature value SigPrivA(TI or TI′); (c) the intermediate server, when the SigPrivA(TI or TI′) is acquired, performing or supporting another device to perform a process of validating the specific certificate by referring to (i) the SigPrivA(TI or TI′), (ii) the TI or its processed value TI′, and (iii) the PrivTxidA; (d) the intermediate server, when the specific certificate is determined as valid, performing or supporting another device to perform (i) a process of registering the SigPrivA(TI or TI′), the TI or its processed value TI′, and the PrivTxidA, as an approval data of the specific certificate with the private blockchain database, (ii) a process of executing the specific byte code BC(SC(VcertA)) on the computing device, and (iii) a process of updating a specific state S(SC(VcertA)) of the SDB to a new state S′(SC(VcertA)) by referring to a result acquired from the process (ii) of the step (d); and (e) the intermediate server, when one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, performing or supporting another device to perform (I) a process of acquiring a specific representative hash value or its processed value calculated by using a specific hash value, which is a hash value of the approval data, and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the neighboring hash value includes (i) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, (ii) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (ii-1) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (ii-2) the states of the SDB are identifiable by PrivTxids which represent respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (ii-3) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (II) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a method for providing an approval service for a specific certificate using a smart contract on a blockchain system. The method addresses the challenge of securely verifying and approving certificates while ensuring data integrity through blockchain consensus. The system involves a private blockchain database and a state database (SDB) that tracks the execution state of smart contracts. The method begins by recording a user's public key, hashed personal information, and compiled smart contract bytecode in a private blockchain transaction. The smart contract defines validity conditions for the certificate. An intermediate server acquires an approval request for the certificate and transmits a transaction ID (TI) to the user's device, instructing the user to sign it with their private key. The server validates the certificate by checking the signature, transaction data, and blockchain records. If valid, the approval data is registered in the private blockchain, the smart contract is executed, and the SDB is updated. When certain anchoring conditions are met, the system generates a representative hash value combining the approval data hash with neighboring hashes from associated transactions and SDB state changes. This representative hash is then recorded in a public blockchain, ensuring transparency and immutability. The method ensures secure certificate approval while maintaining privacy and verifiability through blockchain technology.
18. The method of claim 17 , before the step of (b), further comprising steps of: (b0′) the intermediate server, on condition that a first representative hash value, having been calculated by using a hash value of a former state of the SDB and its corresponding at least one neighboring hash value, is registered with the public blockchain database, and then when the approval request is acquired, performing or supporting another device to perform a process of determining whether a second representative hash value or its processed value corresponds to the first representative hash value or its processed value, wherein the second representative hash value is calculated by using a hash value of a current state of the SDB in the private blockchain database and the at least one neighboring hash value corresponding to the former state of the SDB, and wherein the former state of the SDB is a most recent state among a state at a time of registration of the specific certificate and at a time of latest approval thereof; and (b1′) the intermediate server, when the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value, performing or supporting another device to perform determining that an integrity of the SDB is compromised.
This invention relates to blockchain-based systems for verifying the integrity of a shared database (SDB) in a private blockchain network. The problem addressed is ensuring data integrity in private blockchains where tampering or unauthorized modifications could occur, particularly when validating approval requests for certificates or transactions. The method involves an intermediate server that checks the consistency of the SDB's state before processing approval requests. Before evaluating an approval request, the server first calculates a first representative hash value using a hash of the SDB's former state (the most recent state at the time of certificate registration or last approval) and its corresponding neighboring hash values. This first hash is registered on a public blockchain for verification. When an approval request is received, the server calculates a second representative hash value using the current state of the SDB and the neighboring hash values from the former state. The system then compares the second hash (or its processed form) with the first hash (or its processed form). If they do not match, the system determines that the SDB's integrity has been compromised, indicating potential tampering. This ensures that only valid, unaltered data is approved in the private blockchain. The method enhances security by leveraging public blockchain verification for private blockchain data integrity.
19. The method of claim 17 , before the step of (b), further comprising steps of: (b0) the intermediate server, on condition that a first representative hash value or its processed value, having been calculated by using (i) a hash value calculated by using the specific public key PubA, the IdhashA, and the specific byte code, and (ii) its corresponding at least one neighboring hash value, is registered with the public blockchain database, and then when the approval request is acquired, performing or supporting another device to perform a process of determining whether a second representative hash value or its processed value, which is calculated by using the specific public key PubA, the IdhashA, and the specific byte code, corresponds to the first representative hash value or its processed value; and (b1) the intermediate server, when the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value, performing or supporting another device to perform determining that an integrity of the specific certificate is compromised.
This invention relates to blockchain-based certificate verification systems, addressing the challenge of ensuring the integrity and authenticity of digital certificates. The method involves an intermediate server that verifies the consistency of hash values derived from certificate components before approving a request. Specifically, the server calculates a first representative hash value using a public key (PubA), an identifier hash (IdhashA), and specific byte code. This value, along with neighboring hash values, is registered on a public blockchain. When an approval request is received, the server or another device computes a second representative hash value using the same inputs. If the second value does not match the first, the system determines that the certificate's integrity is compromised. This process ensures tamper-proof verification by leveraging blockchain immutability and cryptographic hashing. The method enhances security by detecting unauthorized modifications to certificates before approval, preventing fraudulent use. The system supports decentralized verification, reducing reliance on centralized authorities while maintaining trust through blockchain transparency.
20. The method of claim 19 , wherein, at the step of (b0), (b0-1) the intermediate server performs or supports another device to perform a process of acquiring the specific public key PubA, the IdhashA, and the specific byte code from the private blockchain database by using the PrivTxidA, and a process of referring to a certain transaction ID related to the PrivTxidA; and (b0-2) the intermediate server acquires or supports another device to acquire an OP_RETURN message from the public blockchain database by using the certain transaction ID, and at the step of (b1), the intermediate server, when the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value included in the OP_RETURN message, performing or supporting another device to perform determining that the integrity of the specific certificate is compromised.
This invention relates to a method for verifying the integrity of a specific certificate using blockchain technology. The method involves an intermediate server that interacts with both a private blockchain database and a public blockchain database to ensure the authenticity and integrity of the certificate. The process begins with the intermediate server acquiring a specific public key, an identifier hash, and specific byte code from the private blockchain database using a private transaction identifier. The server then refers to a related transaction ID in the private blockchain. Using this transaction ID, the server retrieves an OP_RETURN message from the public blockchain database. The OP_RETURN message contains a first representative hash value derived from the certificate. The server then compares this hash value with a second representative hash value or its processed form, which is derived from the certificate being verified. If the second hash value does not match the first, the server determines that the certificate's integrity has been compromised. This method ensures that any tampering with the certificate can be detected by cross-referencing data stored in both private and public blockchains, enhancing security and trust in digital certificates.
21. The method of claim 20 , wherein, at the step of (b0-1), the intermediate server performs or supports another device to perform a process of identifying information on a Merkle tree and its leaf nodes related to the PrivTxidA and a process of referring to the certain transaction ID corresponding to the information on the Merkle tree.
This invention relates to blockchain-based transaction verification systems, specifically addressing the challenge of efficiently identifying and verifying transaction data within a decentralized ledger. The method involves an intermediate server that facilitates the verification of a transaction identifier (PrivTxidA) by interacting with a Merkle tree structure, which is commonly used in blockchain systems to ensure data integrity and efficient verification. The intermediate server performs or assists another device in executing two key processes. First, it identifies information stored within a Merkle tree and its associated leaf nodes that correspond to the transaction identifier (PrivTxidA). This involves traversing the Merkle tree to locate the specific branch and leaf node where the transaction data is recorded. Second, the server refers to a certain transaction ID that matches the identified Merkle tree information, ensuring that the transaction data is correctly linked to the blockchain. This process helps verify the authenticity and integrity of the transaction without requiring full blockchain download or extensive computational resources, improving efficiency in transaction validation. The method leverages Merkle tree properties to enable lightweight verification, reducing the computational overhead typically associated with blockchain transaction checks. This is particularly useful in environments where rapid verification is required, such as in decentralized applications or privacy-focused transaction systems. The intermediate server acts as a bridge between the transaction requester and the blockchain, streamlining the verification process while maintaining security and data integrity.
22. The method of claim 19 , wherein the second representative hash value is calculated by using (i) a second specific hash value which is a hash value of the specific public key PubA, the IdhashA, and the specific byte code, which are registered with the private blockchain database, and are located by the PrivTxidA within the private blockchain database, and (ii) its matching at least one neighboring hash value.
This invention relates to a method for calculating a second representative hash value in a private blockchain system. The method addresses the challenge of securely and efficiently verifying data integrity and authenticity within a private blockchain by leveraging specific hash values and neighboring hash values. The system involves a private blockchain database that stores cryptographic data, including public keys, identity hashes, and bytecode, each associated with a unique transaction identifier (PrivTxidA). The method calculates the second representative hash value by first computing a second specific hash value, which is derived from a specific public key (PubA), an identity hash (IdhashA), and specific bytecode, all of which are registered and retrievable within the private blockchain database using the transaction identifier (PrivTxidA). The second representative hash value is then determined by combining this second specific hash value with at least one neighboring hash value, ensuring data consistency and tamper resistance. This approach enhances the security and reliability of data verification in private blockchain environments by incorporating both direct and contextual hash references. The method is particularly useful in applications requiring high-assurance data integrity, such as financial transactions, supply chain tracking, and identity verification systems.
23. The method of claim 21 , wherein, the second representative hash value is calculated by using a second specific hash value and a hash value allocated to at least one other leaf node which matches a node of the second specific hash value in a Merkle tree.
This invention relates to cryptographic systems, specifically methods for efficiently verifying data integrity using Merkle trees. The problem addressed is the computational overhead and complexity in verifying data consistency in distributed or decentralized systems, such as blockchain networks, where multiple parties need to confirm the integrity of stored data without accessing the entire dataset. The method involves generating a second representative hash value for a subset of data in a Merkle tree structure. A Merkle tree is a binary tree where each leaf node contains a hash of a data block, and each non-leaf node contains a hash of its child nodes. The second representative hash value is derived by combining a second specific hash value (e.g., a hash of a particular data block) with the hash values of at least one other leaf node that shares a common ancestor node with the second specific hash value in the Merkle tree. This allows for efficient verification of data integrity by leveraging the hierarchical structure of the Merkle tree, reducing the need to recompute or transmit entire branches of the tree. The method ensures that only relevant hash values are used, minimizing computational and storage requirements while maintaining the security and integrity of the data verification process. This approach is particularly useful in scenarios where bandwidth or processing power is limited, such as in lightweight clients or resource-constrained environments. The technique can be applied in blockchain systems, distributed databases, or any system requiring secure and efficient data verification.
24. The method of claim 23 , wherein, (x1) the intermediate server calculates or supports another device to calculate an intermediate value by using (i) the second specific hash value and (ii) a hash value allocated to a sibling node of a specific leaf node where the second specific hash value is allocated, and then allocates or supports another device to allocate a hash value of the intermediate value to a parent node of the specific leaf node, (x2) the intermediate server, when the parent node is a root node of the Merkle tree, compares or supports another device to compare the hash value of the intermediate value, as the second representative hash value, with a value included in the OP_RETURN message, and (x3) the intermediate server, when the parent node is not the root node, repeats or supports another device to repeat the steps from (x1) to (x3) by regarding the hash value of the intermediate value as the second specific hash value and regarding the parent node as the specific leaf node.
This invention relates to a method for verifying data integrity in a blockchain system using a Merkle tree structure. The problem addressed is ensuring secure and efficient verification of data stored in a blockchain, particularly when validating transactions or data entries through cryptographic hashing. The method involves an intermediate server or another device calculating an intermediate value using a second specific hash value and a hash value from a sibling node of a specific leaf node in a Merkle tree. The hash value of this intermediate value is then allocated to the parent node of the specific leaf node. If the parent node is the root node, the hash value of the intermediate value serves as a second representative hash value, which is compared to a value included in an OP_RETURN message to verify consistency. If the parent node is not the root node, the process repeats iteratively, treating the hash value of the intermediate value as the new second specific hash value and the parent node as the new specific leaf node, until the root node is reached. This recursive approach ensures that the data integrity of the Merkle tree is maintained, allowing for efficient verification of blockchain transactions or data entries. The method supports distributed computation, enabling multiple devices to participate in the verification process.
25. The method of claim 17 , wherein, at the step of (c), (c1) the intermediate server confirms or supports another device to confirm whether a public key RegPubA corresponding to the user device, and the IdhashA are registered; (c2) the intermediate server, when the RegPubA and the IdhashA are determined as not registered, transmits or supports another device to transmit a message indicating that the public key RegPubA is not registered; (c3) the intermediate server, on condition that the RegPubA and the IdhashA are determined as registered, performs or supports another device to perform a process of transmitting a message indicating that the PubA is not authentic when the RegPubA is not identical to the PubA, and a process of determining that the PubA is valid when the RegPubA is identical to the PubA; and (c4) the intermediate server, when the public key PubA is determined as valid, determines or supports another device to determine whether the SigPrivA(TI or TI′) is legitimately signed.
This invention relates to a method for verifying the authenticity and validity of a public key and a digital signature in a secure communication system. The method addresses the problem of ensuring that a public key used in cryptographic operations is legitimate and properly registered, and that a digital signature associated with that key is valid. The method involves an intermediate server that acts as a verification authority. The server checks whether a public key (RegPubA) corresponding to a user device and an associated identifier (IdhashA) are registered in a trusted database. If they are not registered, the server transmits a message indicating the public key is not registered. If the public key and identifier are registered, the server compares the registered public key (RegPubA) with the public key (PubA) provided by the user device. If they do not match, the server transmits a message indicating the public key is not authentic. If they match, the server determines that the public key is valid. Once the public key is validated, the server checks whether a digital signature (SigPrivA) generated using a private key corresponding to the public key is legitimately signed. This ensures that the signature is cryptographically valid and has not been tampered with. The method supports secure communication by verifying the authenticity of keys and signatures, preventing unauthorized access or fraudulent activities.
26. The method of claim 25 , wherein, at the step of (c4), whether the SigPrivA(TI or TI′) is legitimately signed is determined by referring to the TI or its processed value TI′ and the public key PubA.
This invention relates to digital signature verification in a cryptographic system, specifically addressing the challenge of determining the legitimacy of a signed message or transaction identifier (TI) using a public key. The method involves verifying whether a signature (SigPrivA) associated with a transaction identifier (TI) or its processed form (TI′) is valid by cross-referencing the TI or TI′ with a corresponding public key (PubA). The verification process ensures that the signature was generated by the legitimate holder of the private key associated with PubA, thereby preventing unauthorized modifications or fraudulent transactions. The method may involve preprocessing the TI to generate TI′ before verification, ensuring robustness against tampering. This approach is particularly useful in secure communication, blockchain transactions, or digital authentication systems where integrity and authenticity are critical. The invention enhances security by providing a reliable mechanism to validate signatures, reducing the risk of forgery or unauthorized access. The method may be integrated into larger cryptographic protocols or systems requiring signature verification as part of their security framework.
27. The method of claim 17 , wherein, at the step of (c), the intermediate server performing or supporting another device to perform a process of determining whether a completion data of revocation of the specific certificate is registered, and a process of transmitting a message indicating that an approval of the specific certificate failed to the user device when the completion data of revocation is determined as registered.
This invention relates to certificate revocation management in a networked system, specifically addressing the need to verify and communicate the revocation status of digital certificates to ensure secure authentication and authorization. The method involves an intermediate server that facilitates the revocation process by checking whether a specific certificate has been revoked and notifying the user device accordingly. When a certificate revocation request is processed, the intermediate server determines if the revocation completion data for the certificate is registered in a revocation database. If the revocation is confirmed, the server transmits a message to the user device indicating that the approval of the certificate has failed due to its revoked status. This ensures that revoked certificates are not used for authentication, enhancing system security. The method may also involve supporting another device to perform these steps, allowing for distributed processing. The system prevents unauthorized access by promptly invalidating compromised or revoked certificates and notifying affected users. This approach is particularly useful in environments where timely revocation status verification is critical, such as financial transactions, secure communications, or access control systems.
28. The method of claim 17 , further comprising a step of: (f) the intermediate server, when the specific certificate is determined as valid, transmits or supports another device to transmit a message indicating that an approval of the specific certificate is completed to the user device.
This invention relates to a system for validating digital certificates in a networked environment. The problem addressed is ensuring secure and efficient certificate validation between devices, particularly in scenarios where an intermediate server facilitates the process. The system involves a user device requesting validation of a specific certificate, which is then checked by an intermediate server. If the certificate is determined to be valid, the intermediate server or another device transmits a message to the user device indicating that the approval process is complete. This ensures that the user device is promptly notified of the certificate's validity, enhancing security and reliability in digital transactions. The method may also include additional steps such as receiving the certificate request, verifying the certificate's authenticity, and generating a validation response. The intermediate server acts as a trusted intermediary, ensuring that only valid certificates are approved, thereby preventing unauthorized access or fraudulent activities. The system is particularly useful in environments where multiple devices interact, such as in IoT networks or cloud-based services, where secure communication is critical. The invention improves upon existing certificate validation methods by providing a streamlined and automated approval process, reducing the need for manual intervention and minimizing delays in certificate verification.
29. The method of claim 17 , wherein, the TI includes at least part of (i) a time of requesting the approval and (ii) at least one nonce generated randomly.
This invention relates to a method for enhancing security in approval-based systems, particularly in digital transactions or access control mechanisms. The problem addressed is the need for secure and verifiable approval processes to prevent unauthorized or fraudulent activities. The method involves generating a transaction identifier (TI) that includes both a timestamp of the approval request and at least one randomly generated nonce. The timestamp ensures that the approval request is time-bound, reducing the risk of replay attacks, while the nonce adds an additional layer of uniqueness to each transaction, preventing duplication or forgery. The TI is used to validate the authenticity and integrity of the approval request, ensuring that only legitimate and authorized transactions are processed. This approach improves security by making it difficult for attackers to manipulate or reuse approval requests, thereby protecting sensitive operations from unauthorized access or tampering. The method is applicable in various domains, including financial transactions, access control systems, and digital signatures, where secure approval mechanisms are critical.
30. The method of claim 17 , wherein, at the step of (b), the intermediate server performs or supports another device to perform a process of determining whether the PrivTxidA or its processed value acquired directly or indirectly from the user device is registered, and a process of transmitting a message indicating that an approval of the specific certificate failed to the user device when the PrivTxidA or its processed value is determined as not registered.
This invention relates to a method for managing certificate approval in a networked system involving user devices and an intermediate server. The problem addressed is ensuring secure and reliable certificate validation by verifying the registration status of a unique identifier (PrivTxidA) associated with a user device. The method involves the intermediate server or another device performing two key processes: first, determining whether the PrivTxidA or its processed value, acquired directly or indirectly from the user device, is registered in a system database. Second, if the PrivTxidA or its processed value is found to be unregistered, the intermediate server transmits a failure message to the user device, indicating that the approval of the specific certificate has been denied. This ensures that only registered identifiers are permitted to proceed with certificate validation, enhancing security by preventing unauthorized access. The method integrates with a broader system where the intermediate server facilitates communication between user devices and a certificate authority, ensuring that only properly authenticated devices receive approved certificates. The invention improves upon existing systems by adding an additional layer of verification before certificate issuance, reducing the risk of fraudulent or unauthorized certificate approvals.
31. A method for providing a revocation service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computing device, is configured to perform a predetermined procedure when particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computing device, comprising steps of: (a) an intermediate server, on condition that (i) a specific public key PubA corresponding to a user device of a specific user, (ii) an IdhashA which is a hash value of personal information of the specific user, and (iii) a specific byte code BC(SC(VcertA)) into which a specific smart contract SC(VcertA) corresponding to a VcertA which includes one or more validity conditions on the specific certificate is compiled, are recorded at a location indicated by a PrivTxidA which is a locator of a specific transaction registered with a private blockchain database, and that the PrivTxidA and a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) are registered with a State Database (SDB), performing or supporting another device to perform a process of acquiring a revocation request of the specific certificate which is a message requesting for a revocation of the specific certificate based on the specific smart contract SC(VcertA); (b) the intermediate server, when the revocation request of the specific certificate is acquired, performing or supporting another device to perform a process of transmitting the PrivTxidA and a Revocation Request (RR), which includes information on the revocation request, created in response to the revocation request, to the user device, and a process of instructing the user device to sign the RR or its processed value RR′ with a specific private key PrivA corresponding to the specific public key PubA to thereby generate a signature value SigPrivA(RR or RR′); (c) the intermediate server, when the SigPrivA(RR or RR′) is acquired, performing or supporting another device to perform a process of validating the specific certificate by referring to (i) the SigPrivA(RR or RR′), (ii) the RR or its processed value RR′, and (iii) the PrivTxidA; (d) the intermediate server, when the specific certificate is determined as valid, performing or supporting another device to perform (i) a process of registering the SigPrivA(RR or RR′), the RR or its processed value RR′, and the PrivTxidA, as a completion data of the revocation of the specific certificate with the private blockchain database; and (e) the intermediate server, when one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, performing or supporting another device to perform (I) a process of acquiring a specific representative hash value or its processed value calculated by using a specific hash value, which is a hash value of the completion data of the revocation, and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the neighboring hash value includes (i) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, (ii) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (ii-1) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (ii-2) the states of the SDB are identifiable by PrivTxids which represent respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (ii-3) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (II) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a method for revoking a specific certificate using a smart contract in a blockchain system. The method addresses the problem of securely and transparently managing certificate revocation in a decentralized manner, ensuring integrity and verifiability through blockchain consensus. The system involves an intermediate server that interacts with a user device and blockchain databases to execute the revocation process. The method begins by verifying that a user's public key, hashed personal information, and compiled smart contract bytecode are recorded in a private blockchain database. The smart contract defines validity conditions for the certificate. Upon receiving a revocation request, the intermediate server transmits the request to the user device, which signs it with the corresponding private key. The server then validates the certificate by checking the signature, revocation request, and blockchain transaction locator. If the certificate is valid, the server registers the signed revocation data in the private blockchain. When certain anchoring conditions are met, the system calculates a representative hash value using the revocation data and neighboring hash values from associated transactions and the state database. This hash value is then recorded in a public blockchain, ensuring transparency and immutability. The neighboring hash values include data from other users and smart contract states, providing a comprehensive audit trail. The method ensures secure, verifiable certificate revocation while maintaining privacy and integrity through blockchain technology.
32. The method of claim 31 , wherein, at the step of (c), the intermediate server performing or supporting another device to perform a process of determining whether the completion data of the revocation of the specific certificate is registered, and a process of transmitting a message to the user device indicating that the revocation of the specific certificate failed when the completion data of the revocation is determined as registered.
This invention relates to certificate revocation management in a networked system, specifically addressing the need to verify and communicate the status of certificate revocation requests. The system involves an intermediate server that facilitates the revocation of digital certificates, such as those used for authentication or encryption. The server checks whether the revocation process for a specific certificate has been completed by verifying the presence of completion data in a revocation registry. If the completion data is found, indicating the revocation was successful, the server proceeds accordingly. However, if the completion data is missing, the server transmits a failure notification to the user device, alerting them that the revocation did not succeed. This ensures users are promptly informed of any issues with their revocation requests, improving transparency and reliability in certificate management. The method may involve the intermediate server directly performing these checks or delegating them to another device, such as a certificate authority or a dedicated validation service. The system enhances security by preventing unauthorized use of revoked certificates and provides users with clear feedback on the status of their revocation requests.
33. The method of claim 31 , wherein, at the step of (b), the intermediate server performs or supports another device to perform a process of determining whether the PrivTxidA or its processed value acquired directly or indirectly from the user device is registered, and a process of transmitting a message to the user device indicating that the revocation of the specific certificate failed when the PrivTxidA or its processed value is determined as not registered.
This invention relates to certificate revocation systems, specifically addressing the challenge of verifying and communicating the status of a certificate revocation request. The system involves an intermediate server that facilitates the revocation of a specific certificate associated with a user device. The process includes acquiring a private transaction identifier (PrivTxidA) or its processed value from the user device. The intermediate server then determines whether this identifier or its processed value is registered in a relevant database. If the identifier is not registered, the server transmits a message to the user device indicating that the revocation of the specific certificate has failed. This ensures that only valid, registered identifiers trigger successful revocation, preventing unauthorized or erroneous revocation attempts. The system may also support another device to perform the verification process, enhancing flexibility and scalability. The invention improves the reliability and security of certificate revocation by ensuring proper validation before proceeding with the revocation process.
34. An intermediate server for providing a registration service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computer device, is configured to perform a predetermined procedure if particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computer device, comprising: a processor for performing or supporting another computer device to perform (i) a process of creating the specific smart contract SC(VcertA) corresponding to the validity conditions, wherein the VcertA includes one or more validity conditions on the specific certificate, and a process of acquiring at least one specific byte code BC(SC(VcertA)) into which the specific smart contract is compiled, (ii) a process of, if the specific byte code is acquired, registering a specific public key PubA corresponding to a user computer device of a specific user, an IdhashA, which is a hash value of personal information of the specific user, and the specific byte code BC(SC(VcertA)) as information of the specific certificate with a private blockchain database, and a process of acquiring PrivTxidA as referential information of the specific certificate, which is a locator of the information of the specific certificate in the private blockchain database, (iii) a process of, if the PrivTxidA is acquired, setting a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) as an initial state, and a process of registering the PrivTxidA and the specific state S(SC(VcertA)) with a State Database (SDB), and (iv) a process of, if one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, acquiring a specific representative hash value or its processed value calculated by using a specific hash value and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the specific hash value is calculated by using the specific public key PubA, the IdhashA and the specific byte code BC(SC(VcertA)), and wherein the neighboring hash value includes (iv-1) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, and (iv-2) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (iv-2-a) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (iv-2-b) the states of the SDB are identifiable by all PrivTxids which represent respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (iv-2-c) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (v) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a system for managing certificate registration using smart contracts and blockchain technology. The system addresses the need for secure, verifiable certificate registration by leveraging blockchain consensus mechanisms to ensure data integrity. The intermediate server creates a smart contract (SC(VcertA)) that defines validity conditions for a specific certificate. The smart contract is compiled into bytecode (BC(SC(VcertA))) and registered in a private blockchain database along with a user's public key (PubA), a hashed personal identifier (IdhashA), and the bytecode. The system generates a transaction identifier (PrivTxidA) as a reference to this certificate data. The smart contract's initial state (S(SC(VcertA))) is recorded in a State Database (SDB), which tracks changes in smart contract states. When certain anchoring conditions are met, the system calculates a representative hash value using the public key, IdhashA, and bytecode, along with neighboring hash values derived from other users' data and the SDB's state variations. These variations reflect differences between the SDB's state at the completion of the current block (n-th) and the previous block (n-1-th). The representative hash value is then recorded in a public blockchain database, ensuring tamper-proof verification of the certificate's registration. This approach enhances security and transparency in certificate management by combining private and public blockchain systems.
35. The intermediate server of claim 34 , wherein the processor further performs or supports the another computer device to perform (vi) a process of, if the specific public key PubA, the IdhashA and the specific byte code BC(SC(VcertA)) are registered with the private blockchain database, transmitting the PrivTxidA and a response indicating a registration to a certain server to thereby instruct the certain server to transmit a completion message to the user computer device indicating the registration of the specific certificate, wherein the completion message includes the PrivTxidA.
This invention relates to a system for managing digital certificates using a private blockchain database. The problem addressed is ensuring secure and verifiable registration of digital certificates while maintaining privacy and integrity of the data. The system involves an intermediate server that facilitates the registration process between a user computer device and a private blockchain database. The server receives a specific public key (PubA), an identifier hash (IdhashA), and a byte code (BC(SC(VcertA))) representing a digital certificate (VcertA) from the user device. The server checks if these elements are already registered in the private blockchain. If they are, the server transmits a private transaction ID (PrivTxidA) and a registration confirmation to another server, which then sends a completion message to the user device. This message includes the PrivTxidA, confirming the successful registration of the certificate. The system ensures that the user can verify the registration status while maintaining the privacy of the blockchain data. The intermediate server acts as a bridge, handling the communication between the user, the blockchain, and other servers to streamline the certificate registration process. The use of a private blockchain ensures that the certificate data is securely stored and tamper-proof, while the intermediate server simplifies the interaction for the end user.
36. The intermediate server of claim 34 , wherein the anchoring conditions include at least one of (i) a condition that a certain number of the specific hash value and the neighboring hash value are acquired or generated, (ii) a condition that a certain amount of time is elapsed, (iii) a condition that the n-th block is created in the private blockchain database, and (iv) a condition that has at least one of characteristics of services.
This invention relates to an intermediate server in a blockchain system, specifically addressing the challenge of securely anchoring data from a private blockchain to a public blockchain. The intermediate server monitors and manages the anchoring process based on predefined conditions to ensure data integrity and consistency between the two blockchains. The anchoring conditions include (i) acquiring or generating a certain number of specific hash values and neighboring hash values, (ii) waiting for a certain amount of time to elapse, (iii) reaching the creation of the n-th block in the private blockchain database, or (iv) meeting specific service characteristics. The server ensures that data from the private blockchain is securely and reliably transferred to the public blockchain, maintaining the immutability and transparency of the anchored data. This approach enhances the trustworthiness of the private blockchain by leveraging the public blockchain's decentralized verification mechanisms while preserving the privacy of the private blockchain. The system is particularly useful in applications requiring both private data management and public verification, such as supply chain tracking, financial transactions, and identity verification.
37. The intermediate server of claim 36 , wherein the processor records or supports the another computer device to record an SDB header hash value in a block header of the n-th block when the n-th block is created in the private blockchain database, and wherein the SDB header hash value is a hash value calculated by using information on the states of the SDB or all the variations of the SDB.
This invention relates to blockchain technology, specifically improving data integrity and traceability in private blockchain databases (SDBs). The problem addressed is ensuring that changes to the state of a private blockchain database are securely recorded and verifiable, preventing unauthorized modifications or inconsistencies. The invention involves an intermediate server that manages interactions between a private blockchain database and other computer devices. When a new block (the n-th block) is created in the private blockchain database, the server records or enables another computer device to record an SDB header hash value in the block header. This hash value is generated using information about the current state of the SDB or all possible variations of the SDB. By embedding this hash in the block header, the system ensures that any changes to the SDB state are cryptographically linked to the blockchain, making tampering detectable. The intermediate server also handles requests from other devices to access or modify the SDB, ensuring that all operations comply with predefined rules and that the blockchain remains consistent. The recorded hash values serve as a tamper-evident log, allowing for auditing and verification of the SDB's state over time. This approach enhances security and trust in private blockchain applications by providing a verifiable record of database state changes.
38. The intermediate server of claim 37 , wherein, at the process of (iv), on condition that (I) a certificate representative hash value is generated from a Merkle tree whose leaf nodes include hash values calculated by using public keys, personal information hash values, and byte codes, and (II) a message representative hash value is generated from a Merkle tree whose leaf nodes include hash values calculated by using (II-1) message data which include approval information or their processed values corresponding to approvals of certificates, or revocation requesting information or their processed values corresponding to revocations of the certificates, the certificates being referred to by locators of transactions, (II-2) signature values of the message data, and (II-3) the locators, and (III) the certificate representative hash value and the message representative hash value are further recorded in the block header of the n-th block, the processor registers or supports the another computer device to register the SDB header hash value, the certificate representative hash value and the message representative transaction hash value or their processed values with the public blockchain database, wherein the public keys include the specific public key PubA and the associated public key, which are used as elements for calculating hash values recorded in the n-th block, wherein the personal information hash values include the IdhashA and the Idhash_OTHERS, which are used as elements for calculating hash values recorded in the n-th block, wherein the byte codes include the specific byte code BC(SC(VcertA)) and the associated byte code, which are used as elements for calculating hash values recorded in the n-th block, and wherein the locators include the PrivTxidA and the PrivTxids in the n-th block.
This invention relates to a blockchain-based system for securely managing certificates and approval/revocation messages. The system addresses the challenge of verifying certificate authenticity and approval/revocation integrity in a decentralized manner. The intermediate server generates two Merkle trees: one for certificates and another for messages. The certificate Merkle tree includes hash values derived from public keys (e.g., PubA and associated public keys), personal information hashes (e.g., IdhashA and Idhash_OTHERS), and byte codes (e.g., BC(SC(VcertA)) and associated byte codes). The message Merkle tree includes hash values derived from message data (containing approval or revocation information), signature values of the message data, and transaction locators (e.g., PrivTxidA and PrivTxids). The root hashes of these Merkle trees, along with a block header hash (SDB header hash value), are recorded in the n-th block of a public blockchain. This ensures that certificate data and approval/revocation messages are cryptographically linked and verifiable. The system enhances transparency and security in certificate management by leveraging blockchain immutability.
39. The intermediate server of claim 37 , wherein, at the process of (iv), on condition that a private representative hash value is generated from a Merkle tree whose leaf nodes include (I) hash values calculated by using public keys, personal information hash values, and byte codes, and (II) hash values calculated by using (II-1) message data which include approval information or their processed values corresponding to approvals of certificates, or revocation requesting information or their processed values corresponding to revocations of the certificates, the certificates being referred to by locators of transactions (II-2) signature values of the message data, and (II-3) the locators, and (III) the private representative hash value is further recorded in the block header of the n-th block, the processor registers or supports the another computer device to register the SDB header hash value, the private representative hash value or their processed values with the public blockchain database, wherein the public keys include the specific public key PubA and the associated public key, which are used as elements for calculating hash values recorded in the n-th block, wherein the personal information hash values include the IdhashA and the Idhash_OTHERS, which are used as elements for calculating hash values recorded in the n-th block, wherein the byte codes include the specific byte code BC(SC(VcertA)) and the associated byte code, which are used as elements for calculating hash values recorded in the n-th block, and wherein the locators include the PrivTxidA and the PrivTxids in the n-th block.
This invention relates to a system for securely managing digital certificates using a public blockchain database. The system addresses the challenge of verifying certificate authenticity and integrity in a decentralized manner, ensuring transparency and tamper-proof record-keeping. The intermediate server processes certificate-related transactions by generating a private representative hash value from a Merkle tree. The Merkle tree's leaf nodes include hash values derived from public keys, personal information hash values, and byte codes. Additionally, the tree incorporates hash values calculated from message data containing approval or revocation information for certificates, along with their signatures and transaction locators. The private representative hash value is recorded in the block header of the n-th block. The system ensures that the private representative hash value, or its processed form, is registered with the public blockchain database. The public keys used include a specific public key (PubA) and an associated public key, while the personal information hash values include IdhashA and Idhash_OTHERS. The byte codes used are a specific byte code (BC(SC(VcertA))) and an associated byte code. The transaction locators include PrivTxidA and PrivTxids in the n-th block. This approach enhances the security and verifiability of certificate management by leveraging blockchain technology.
40. An intermediate server for providing an approval service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computer device, is configured to perform a predetermined procedure if particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computer device, comprising: a processor, on condition that (A) a specific public key PubA corresponding to a user computer device of a specific user, (B) an IdhashA which is a hash value of personal information of the specific user, (C) a specific byte code BC(SC(VcertA)) into which a specific smart contract SC(VcertA) corresponding to a VcertA which includes one or more validity conditions on the specific certificate is compiled, are recorded at a location indicated by a PrivTxidA which is a locator of a specific transaction registered with a private blockchain database, and that the PrivTxidA and a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) are registered with a State Database (SDB), and (D) an approval request of the specific certificate is acquired directly or indirectly, wherein the approval request is a message requesting an approval of the specific certificate based on the specific smart contract SC(VcertA), for performing or supporting another computer device to perform (i) a process of transmitting the PrivTxidA and a Transaction ID (TI), which includes information on a subject of an approval, created in response to the approval request, to the user computer device, and a process of instructing the user computer device to sign the TI or its processed value (TI′) with a specific private key PrivA corresponding to the specific public key PubA to thereby generate a signature value SigPrivA(TI or TI), (ii) a process of validating the specific certificate by referring to the SigPrivA(TI or TI′), the TI or its processed value TI′, and the PrivTxidA, (iii) if the specific certificate is determined as valid, (iii-1) a process of registering the SigPrivA(TI or TI′), the TI or its processed value TI′, and the PrivTxidA, as an approval data of the specific certificate with the private blockchain database, (iii-2) a process of executing the specific byte code BC(SC(VcertA)) on the computer device, and (iii-3) a process of updating a specific state S(SC(VcertA)) of the SDB to a new state S′(SC(VcertA)) by referring to a result acquired from the process (iii-2), and (iv) a process of, if one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, acquiring a specific representative hash value or its processed value calculated by using a specific hash value, which is a hash value of the approval data, and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the neighboring hash value includes (I) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, (II) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (II-1) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (II-2) the states of the SDB are identifiable by PrivTxids which represent all respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (II-3) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (v) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a system for approving certificates using smart contracts on private and public blockchains. The system addresses the need for secure, verifiable certificate approval processes, particularly in environments requiring privacy and integrity. The intermediate server facilitates approval of a certificate by executing a smart contract (SC(VcertA)) compiled into bytecode (BC(SC(VcertA))). The smart contract defines validity conditions for the certificate. The server ensures that the public key (PubA), hashed personal data (IdhashA), and the smart contract bytecode are recorded in a private blockchain transaction (PrivTxidA) and that the smart contract's state (S(SC(VcertA))) is stored in a State Database (SDB). When an approval request is received, the server transmits the transaction ID (TI) to the user's device, which signs it with a private key (PrivA) to generate a signature (SigPrivA(TI)). The server validates the certificate by checking the signature, TI, and PrivTxidA. If valid, the approval data (SigPrivA(TI), TI, PrivTxidA) is recorded in the private blockchain, the smart contract is executed, and the SDB state is updated. The system also ensures that approval data is anchored to a public blockchain by calculating a representative hash value from the approval data and neighboring hash values (including associated smart contracts and SDB variations). This hash is then registered in a public blockchain, ensuring transparency and immutability. The neighboring hash values include associated public keys, hashed personal data of other users, and variations of the SDB, which track state changes between blocks. This ensures a tamper-proof record of certificate approvals.
41. The intermediate server of claim 40 , wherein, before the process (i), the processor further performs or supports the another computer device to perform (i0′) a process of, on condition that a first representative hash value, having been calculated by using a hash value of a former state of the SDB and its corresponding at least one neighboring hash value, is registered with the public blockchain database, and then if the approval request is acquired, determining whether a second representative hash value or its processed value corresponds to the first representative hash value or its processed value, wherein the second representative hash value is calculated by using a hash value of a current state of the SDB in the private blockchain database and the at least one neighboring hash value corresponding to the former state of the SDB, and wherein the former state of the SDB is a most recent state among a state at a time of registration of the specific certificate and at a time of latest approval thereof, and (i1′) a process of determining that an integrity of the SDB is compromised if the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value.
This invention relates to a system for verifying the integrity of a private blockchain database (SDB) using a public blockchain database. The problem addressed is ensuring the consistency and trustworthiness of data in a private blockchain by leveraging the immutability of a public blockchain. The system includes an intermediate server that performs a verification process before approving a request. First, the server checks whether a first representative hash value, derived from a hash of a former state of the SDB and its corresponding neighboring hash values, is registered on the public blockchain. If an approval request is received, the server calculates a second representative hash value using a hash of the current state of the SDB and the neighboring hash values from the former state. The former state is the most recent state either at the time of certificate registration or the latest approval. The server then compares the second representative hash value (or its processed form) with the first representative hash value (or its processed form). If they do not match, the system determines that the integrity of the SDB has been compromised. This ensures that any unauthorized modifications to the private blockchain are detected by cross-referencing with the public blockchain's immutable records. The neighboring hash values provide additional context to verify the consistency of the SDB's state transitions.
42. The intermediate server of claim 40 , wherein, before the process (i), the processor further performs or supports the another computer device to perform (i0) a process of, on condition that a first representative hash value or its processed value, having been calculated by using (i) a hash value calculated by using the specific public key PubA, the IdhashA, and the specific byte code, and (ii) its corresponding at least one neighboring hash value, is registered with the public blockchain database, and then if the approval request is acquired, determining whether a second representative hash value or its processed value, which is calculated by using the specific public key PubA, the IdhashA, and the specific byte code, corresponds to the first representative hash value or its processed value, and (ii) a process of determining that an integrity of the specific certificate is compromised if the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value.
This invention relates to a system for verifying the integrity of digital certificates using blockchain technology. The problem addressed is ensuring that digital certificates, which are critical for secure communications and authentication, have not been tampered with or altered. The solution involves an intermediate server that performs a multi-step verification process before approving a certificate request. The system calculates a first representative hash value using a specific public key, an identifier hash (IdhashA), and the certificate's byte code. This value is registered on a public blockchain database. When an approval request is received, the system calculates a second representative hash value using the same inputs. The system then compares the second hash value to the first, registered value. If they do not match, the system determines that the certificate's integrity has been compromised. This verification process ensures that the certificate has not been altered since its initial registration on the blockchain, providing a tamper-evident mechanism for certificate validation. The use of blockchain ensures that the verification process is decentralized and resistant to tampering.
43. The intermediate server of claim 42 , wherein, at the process of (i0), the processor performs or supports the another computer device to perform (i0-1) a process of acquiring the specific public key PubA, the IdhashA, and the specific byte code from the private blockchain database by using the PrivTxidA, and a process of referring to a certain transaction ID related to the PrivTxidA, and (i0-2) a process of acquiring an OP_RETURN message from the public blockchain database by using the certain transaction ID, and at the process of (i1), if the second representative hash value or its processed value is determined as not corresponding to the first representative hash value or its processed value included in the OP_RETURN message, the processor performs or supports the another computer device to perform determining that the integrity of the specific certificate is compromised.
This invention relates to a system for verifying the integrity of a specific certificate using blockchain technology. The system involves an intermediate server that interacts with both a private blockchain database and a public blockchain database to ensure the authenticity and integrity of digital certificates. The problem addressed is the need for a secure and tamper-evident method to validate certificates, particularly in distributed or decentralized environments where trust must be established without relying on a single centralized authority. The intermediate server performs a verification process by first acquiring a specific public key (PubA), an identifier hash (IdhashA), and specific byte code from the private blockchain database using a private transaction ID (PrivTxidA). It then retrieves a transaction ID related to PrivTxidA and uses this to acquire an OP_RETURN message from the public blockchain database. The OP_RETURN message contains a first representative hash value derived from the certificate. The server then compares this hash value (or a processed version of it) with a second representative hash value (or its processed version) derived from the certificate in question. If the two values do not match, the server determines that the integrity of the certificate has been compromised, indicating potential tampering or unauthorized modifications. This dual-blockchain approach ensures that the verification process is both secure and resistant to manipulation.
44. The intermediate server of claim 40 , wherein, the processor further performs or supports the another computer device to perform (vi) a process of transmitting a message to the user computer device indicating that an approval of the certificate is completed if the specific certificate is determined as valid.
This invention relates to a system for managing digital certificates, specifically focusing on an intermediate server that facilitates certificate validation and approval processes. The system addresses the challenge of efficiently verifying and approving digital certificates in a distributed computing environment, ensuring secure and reliable authentication. The intermediate server includes a processor that performs or supports another computer device to execute several key functions. One such function involves transmitting a message to a user computer device indicating that the approval of a certificate is completed if the specific certificate is determined to be valid. This process ensures that users are promptly notified once their certificate has been successfully validated, streamlining the authentication workflow. The intermediate server also interacts with other components, such as a certificate authority (CA) or a validation service, to assess the validity of the certificate. The processor may generate a validation request, receive validation results, and process these results to determine whether the certificate meets the required security standards. If the certificate is valid, the server transmits a confirmation message to the user, while also supporting additional actions like logging the validation outcome or updating a certificate status database. This system enhances the efficiency and security of digital certificate management by automating validation and approval notifications, reducing manual intervention, and ensuring timely communication with users. The invention is particularly useful in environments where rapid and reliable certificate validation is critical, such as in enterprise networks, cloud computing, or secure communication systems.
45. An intermediate server for providing a revocation service of a specific certificate based on a specific smart contract, wherein the specific smart contract is at least one source code capable of being compiled into at least one specific byte code executable on at least one computer device, is configured to perform a predetermined procedure if particular conditions are satisfied at a time of execution and wherein integrity about a result of the execution is verified by a consensus outputted from the computer device, comprising: a processor, on condition that (A) a specific public key PubA corresponding to a user computer device of a specific user, (B) an IdhashA which is a hash value of personal information of the specific user, (C) a specific byte code BC(SC(VcertA)) into which a specific smart contract SC(VcertA) corresponding to a VcertA which includes one or more validity conditions on the specific certificate is compiled, are recorded at a location indicated by a PrivTxidA which is a locator of a specific transaction registered with a private blockchain database, and that the PrivTxidA and a specific state S(SC(VcertA)) of the specific smart contract SC(VcertA) are registered with a State Database (SDB), and (D) a revocation request of the specific certificate is acquired, wherein the revocation request is a message requesting for a revocation of the specific certificate based on the specific smart contract SC(VcertA), for performing or supporting another computer device to perform (i) a process of transmitting the PrivTxidA and a Revocation Request (RR), which includes information on the revocation request, created in response to the revocation request, to the user computer device, and a process of instructing the user computer device to sign the RR or its processed value RR′ with a specific private key PrivA corresponding to the specific public key PubA to thereby generate a signature value SigPrivA(RR or RR′), (ii) a process of validating the specific certificate by referring to the SigPrivA(RR or RR′), the RR or its processed value RR′, and the PrivTxidA, (iii) a process of, if the specific certificate is determined as valid, registering the SigPrivA(RR or RR′), the RR or its processed value RR′, and the PrivTxidA, as a completion data of the revocation of the specific certificate with the private blockchain database, and (iv) a process of, if one or more anchoring conditions for an n-th block of a blockchain in the private blockchain database are satisfied, acquiring a specific representative hash value or its processed value calculated by using a specific hash value, which is a hash value of the completion data of the revocation, and its corresponding at least one neighboring hash value to be recorded in the n-th block with the specific hash value, wherein the neighboring hash value includes at (iv-1) at least one first associated hash value calculated by using at least one associated public key, at least one Idhash_OTHERS which is a hash value of personal information of at least one of other users and at least one associated byte code into which at least one associated smart contract is compiled, (iv-2) at least one second associated hash value of the SDB or of all variations of the SDB, wherein (iv-2-a) all the variations of the SDB include all respective changes of all states of smart contracts, and correspond to a difference between states of the SDB at a time of completion of the n-th block and states of the SDB at a time of completion of an (n−1)-th block of the blockchain in the private blockchain database, (iv-2-b) the states of the SDB are identifiable by PrivTxids which represent respective location information of transactions and on where their corresponding transactions are recorded in the n-th block, and (iv-2-c) the SDB includes information on the specific state and at least one associated state of the associated smart contract, and (v) a process of registering the specific representative hash value or its processed value with a public blockchain database.
This invention relates to a system for revoking digital certificates using smart contracts on private and public blockchains. The system addresses the challenge of securely and transparently managing certificate revocation in decentralized environments. The intermediate server facilitates the revocation process by verifying user identity and ensuring the integrity of revocation transactions through blockchain consensus. The system requires a private blockchain database to store a user's public key, hashed personal information, and a compiled smart contract defining certificate validity conditions. When a revocation request is received, the server transmits the request to the user's device, which signs it with the corresponding private key. The server then validates the certificate by checking the signature, request data, and transaction locator. If valid, the revocation details are recorded in the private blockchain. To ensure long-term integrity, the system periodically anchors revocation data to a public blockchain. This involves calculating a representative hash value from the revocation data and neighboring hash values, including those from other users and the state database. The state database tracks smart contract states, with changes recorded as variations between consecutive blocks. The representative hash is then registered on the public blockchain, providing a tamper-evident record of the revocation. This approach enhances trust in certificate revocation by leveraging blockchain immutability and consensus mechanisms.
46. The intermediate server of claim 45 , wherein, at the process of (ii), the processor performs or supports the another computer device to perform a process of determining whether the completion data of the revocation of the specific certificate is registered, and a process of transmitting a message to the user computer device indicating that the revocation of the specific certificate failed if the completion data of the revocation is determined as registered.
This invention relates to certificate revocation management in a distributed computing environment, specifically addressing the need to verify and communicate the status of certificate revocation requests. The system involves an intermediate server that facilitates the revocation of digital certificates, such as those used in secure communications or authentication systems. The server processes revocation requests from user devices and interacts with other computer systems to confirm whether the revocation has been successfully completed. If the revocation data is already registered, indicating the certificate was previously revoked, the server transmits a failure notification to the user device. This ensures users are promptly informed of the revocation status, preventing redundant requests and improving system efficiency. The intermediate server may also support other devices in performing these verification and notification tasks, enhancing flexibility in distributed environments. The invention aims to streamline certificate management by reducing unnecessary processing and providing clear feedback to users.
47. The intermediate server of claim 45 , wherein, after the process of (iii), the processor performs or supports the another computer device to perform a process of determining whether the PrivTxidA or its processed value acquired directly or indirectly from the user computer device is registered, and a process of transmitting a message to the user computer device indicating that the revocation of the certificate failed if the PrivTxidA or its processed value is determined as not registered.
This invention relates to a system for managing digital certificates, specifically addressing the challenge of securely revoking certificates in a distributed network environment. The system includes an intermediate server that facilitates certificate revocation by interacting with user devices and other network components. The intermediate server receives a private transaction identifier (PrivTxidA) or its processed value from a user computer device, which is used to verify the legitimacy of the revocation request. After processing the request, the server determines whether the PrivTxidA or its processed value is registered in a trusted database. If the identifier is not registered, the server transmits a failure message to the user device, indicating that the certificate revocation process has failed. This ensures that only authorized and properly registered requests proceed, enhancing security and preventing unauthorized revocations. The system supports both direct and indirect acquisition of the identifier, allowing flexibility in how the user device provides the necessary authentication data. The intermediate server may also delegate certain processes to another computer device, enabling distributed processing and scalability. This approach improves the reliability and security of certificate revocation in networked systems.
Unknown
November 3, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.