WO2020076234A1 - Appareil et procédé permettant de commander un accès à des données - Google Patents

Appareil et procédé permettant de commander un accès à des données Download PDF

Info

Publication number
WO2020076234A1
WO2020076234A1 PCT/SG2018/050513 SG2018050513W WO2020076234A1 WO 2020076234 A1 WO2020076234 A1 WO 2020076234A1 SG 2018050513 W SG2018050513 W SG 2018050513W WO 2020076234 A1 WO2020076234 A1 WO 2020076234A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
data
encrypted
data access
encrypted key
Prior art date
Application number
PCT/SG2018/050513
Other languages
English (en)
Inventor
Sang Nguyen
Quang Tran
Erman TJIPUTRA
Original Assignee
Aioz Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aioz Pte Ltd filed Critical Aioz Pte Ltd
Priority to PCT/SG2018/050513 priority Critical patent/WO2020076234A1/fr
Publication of WO2020076234A1 publication Critical patent/WO2020076234A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/062—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying encryption of the keys

Definitions

  • the present invention relates to an apparatus and a method for controlling data access to a data storage for storing data to be transferred between a sender and a recipient. More specifically, the invention relates to an apparatus and a method for performing a transaction between a sender and a recipient securely.
  • a blockchain is a continuously expanding list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp, and transaction data.
  • Blockchain technology has been widely used in cryptocurrencies such as Bitcoin, Ethereum and altcoins.
  • a smart contract is typically used to facilitate the performance of credible transactions without third parties.
  • the smart contract is a computer protocol intended to digitally facilitate, verify or enforce the negotiation or performance of a contract.
  • a smart contract may be entered between a buyer and a seller to exchange digital assets, wherein the buyer and the seller have agreed on payment methods together and have agreed to engage an independent third party to hold funds/coins in escrow for the transaction.
  • the smart contract between the buyer and the seller is written as code into the blockchain.
  • the smart contract is not tied to the identity of the buyer and the seller, but the transaction is stored publicly in the blockchain. If there is a triggering event, for instance, an expiration date of the smart contract or a strike price is matched, the contract executes itself according to the coded terms.
  • Regulators can use the blockchain to understand the activity in the market while maintaining the privacy of parties involved.
  • Figure 1 A shows a method for setting a secured communication path between a seller and a buyer to exchange data through an escrow agent according to an example of the present disclosure.
  • Figure 1 B is a continuation of Figure 1A, and shows a method for obtaining data stored in a data storage managed by the escrow agent according to an example of the present disclosure.
  • Figure 1 C is a flow chart indicating how a dispute can be managed by the escrow agent according to an example of the present disclosure.
  • Figure 2A shows a method for setting two independent secured communication paths between two sellers and a common buyer to exchange data through an escrow agent according to an example of the present disclosure.
  • Figure 2B is a continuation of Figure 2A, and illustrates how the buyer obtains respective data from the two sellers through the escrow agent according to an example of the present disclosure.
  • Figure 2C is a continuation of Figure 2B, and illustrates how the buyer obtains respective data from the two sellers through the escrow agent according to an example of the present disclosure.
  • Figure 3A shows a method for setting two independent secured communication paths between one common seller and two buyers to exchange data through an escrow agent according to an example of the present disclosure.
  • Figure 3B is a continuation of Figure 3A, and illustrates how the two buyers obtain respective data from the seller through the escrow agent according to an example of the present disclosure.
  • Figure 3C is a continuation of Figure 3B, and illustrates how the two buyers obtain respective data from the seller through the escrow agent according to an example of the present disclosure.
  • Figure 4 shows a schematic diagram of an apparatus, a device and a server apparatus used for authentication and/or authorization according to an example of the present disclosure.
  • Figure 5 shows a method of facilitating F I AT -cryptocurrency exchange according to an example of the state of the art.
  • asymmetric cryptography algorithm may be employed to authenticate a party of the smart contract, for instance, to prove ownership to a digital wallet address.
  • Asymmetric Encryption used for instance in Public-key Infrastructure (PKI) cryptography, is a cryptographic system that employs a key pair. The key-pair comprises a Public Key (P k ) that is disseminated widely, and a Private Key or a Secret Key (S k ) which is known only to one authorized party.
  • P k Public Key
  • S k Private Key or a Secret Key
  • the data or the digital asset is encrypted with a public key before sending the encrypted data to a party or an intended recipient through unsecured communications channels.
  • the party or intended recipient may access the data or digital asset after decrypting the encrypted data with a private key that corresponds to the public key that is used to encrypt the data.
  • An example of the present disclosure proposes a unique way of using such Asymmetric Encryption.
  • an escrow server creates one escrow account, for example, a blockchain-based wallet, to facilitate all of its exchanges.
  • a key to access the escrow account will be stored in one or more databases accessible by the escrow server.
  • the platform may be configured to facilitate secured digital currency exchanges or FIAT to digital currencies.
  • FIG. 5 illustrates how an existing platform facilitates an exchange of FIAT for cryptocurrency.
  • an exchange platform 510 that two persons, Alice and Bob, use as an escrow agent to facilitate their exchange of FIAT and cryptocurrency.
  • the platform 510 is configured to create a permanent Ethereum escrow wallet E to facilitate the exchanges between the two users, Alice and Bob.
  • a key K to access the wallet E is obtained from an Ethereum server 515 and stored in one or more databases that can be accessed by the platform 510.
  • the key K to access the wallet E is a part of a key pair that is generated by the platform 510, which can be known as an escrow wallet server.
  • the key K to access the wallet is a private key of the key pair that is generated by the platform 510.
  • the key K is configured as a password or passphrase to access the wallet, and one can simply access the wallet if he has the key K.
  • the Ethereum escrow wallet E can be used over and over again for many exchanges. As such, there would be a security issue if the key K is stolen. More details on the security issue would be discussed later.
  • Alice is a buyer 502 who intends to buy Ethereum (ETH) with US Dollars (USD), while Bob is a seller 506 who has ETH that he intends to sell for USD.
  • ETH Ethereum
  • USD US Dollars
  • Alice 502 lists an offer on an exchange web page provided by the platform 510.
  • the offer may specify the following:
  • An example of an offer 520 made by Alice 502 is as follow:
  • the client application associated with the platform 510 may also allow a seller to list his offer by specifying the following:
  • FIAT currency to sell (and in this example, USD) and an available amount for sale;
  • the exchange web page may be polled periodically or continuously to publish one or more available offers to the users of the platform 510.
  • the exchange web page may be configured to receive user inputs to bind the buyer 502 and the seller 506 to a smart contract (for initiating a F!AT- cryptocurrency exchange).
  • the seller 506, Bob may browse the exchange page and decides to make an exchange with the buyer 502, Alice.
  • Bob 506 clicks on an action available for the offer 520, for instance, a“SELL" button on the exchange web page to initiate an exchange request with the buyer 502.
  • the seller 506 is also prompted by the platform 510 to specify his DBS Bank Account, that is, the account that will receive USD from the buyer 502, Alice.
  • Other actions available for clicking may be viewing the details of the offer, cancelling an agreed exchange (after an exchange is entered), and the like.
  • the platform 510 Upon receipt of the exchange request, the platform 510 is configured to send a notification indicating the details of the escrow wallet E to Bob 506 for him to deposit his ETH. The platform 510 is also configured to send Alice 502 a notification indicating Bob’s deposited fund 525 in the escrow wallet E after the receipt of the deposited fund 525 and a request to Alice 502 to transfer the agreed FIAT amount (i.e. 1000 USD) to Bob’s DBS Bank Account.
  • the agreed FIAT amount i.e. 1000 USD
  • the platform 510 is configured to access the escrow account E with the stored key K to withdraw the ETH Fund 525 that Bob has deposited for transferring into Alice’s ETH Account A (i.e. receiving ETH Address Wallet: 0xA0feC4Fba93D92fCEFc5bDf7D089772cF79BQC0).
  • the existing exchanging platform for facilitating F I AT -cryptocurrency exchanges uses oniy one escrow account that holds all the funds received from one or more users (which may comprise users other than Alice 502 and Bob 506) of the platform, wherein the key K to access the one escrow account is stored in at least one database accessible by the platform.
  • This one escrow account e.g. escrow account E in Figure 5) is used to store a digital asset (e.g. ETH fund in Figure 5) to be transferred between the parties temporarily before the digital asset is transferred to a rightful owner of the exchange.
  • Such arrangement does not provide a high level of security for the digital asset entrusted by the one or more users.
  • the key e.g. Key K in Figure 5
  • the key may be stolen or duplicated and subsequently used to access the escrow account to obtain the digital assets stored therein.
  • Bitcoin Gold was seized control after a successful hashing attack, and lost nearly 18 million dollars.
  • the key (e.g. Key K in Figure 5) to access the escrow account is typically stored in plain text. Therefore, there is a need for enhanced security to such escrow servers to prevent theft of private keys, and in particular, to prevent access to the escrow accounts even if the one or more private keys are stolen.
  • An example of the present disclosure is an improvement to the security of a data storage managed by, for example, an escrow server (also known as escrow agent).
  • an escrow server also known as escrow agent.
  • a cryptocurrency application if a hacker manages to steal a private key of a global wallet (or permanent wallet) managed by the escrow agent successfully, the cryptocurrency in the wallet can be withdrawn and there is no way to reverse such transaction in a blockchain-based application.
  • a cloud storage application if a hacker or eavesdropper manages to access a user-defined password or a secured link to an intended recipient, the associated data from a cloud storage server could be leaked or accessed by unauthorised users.
  • the term“data storage’’ may be considered in one example of the present disclosure as an escrow account for storing data to be transferred between a first device and a second device.
  • the escrow account may be a cryptocurrency wallet that stores the public and private key created for the wallet or "address" which can be used to receive or spend the cryptocurrency.
  • the cryptocurrency wallet is configured to hold a private key that allows a user to access his/her cryptocurrency address.
  • the escrow account can also be identified by a QR code provided by a service provider, email address or mobile number that is associated with the escrow account. With the private key, a user can spend (or send) cryptocurrency. With the public key, a user can receive cryptocurrency in the wallet.
  • the cryptocurrency wallet may be a software wallet, hardware wallet or a paper wallet (wherein the paper wallet can be imported to a software at some point), and the software wallet may be a desktop wallet, a mobile wallet or an online wallet. Online wallets are generally more vulnerable to security threats.
  • the escrow account may be an allocated memory space in a cloud server storing sensitive data that are intended for selected recipients, for instance, a lease agreement, personal data.
  • the private key for accessing the escrow account is used interchangeably with the term“data access key”.
  • the blockchain-based wallet such as a Copay wallet, blockchain.info wallet, and the like is created to facilitate an exchange for each transaction (or data transfer), for instance, a FIAT - Cryptocurrency Exchange.
  • a smart contract between a sender and a recipient is entered prior to creating the blockchain-based wallet, wherein the smart contract specifies a predetermined service provider to act as an escrow agent for the transaction stipulated in the smart contract.
  • the blockchain-based wallet managed by the escrow agent may be generated by sending a request to a blockchain-based network.
  • the smart contract may be initiated by a sender, for instance, by listing an offer to sell to one or more users of the predetermined service provider. If there is a recipient who agrees to accept the offer made by the sender, a smart contract is entered between the sender and the recipient.
  • the sender may also provide an offer to sell that is only visible to a predetermined recipient, for example, through a chat conversation between the sender and the predetermined recipient.
  • a data access key (SK T ) of the obtained key-pair to access the wallet is configured to be stored in a memory temporarily.
  • the data access key SKT is encrypted with the sender’s public key (PK A ) to obtain a first encrypted private key, E PKA (SK t )
  • the data access key SKT is encrypted again with the recipient's public key (PK B ) to obtain a second encrypted private key, E PKB (SK T ) .
  • the first encrypted key E PKA (SK x ) and the second encrypted key E PKB (SK t ) are then stored in one or more databases accessible by the service provider. Thereafter, the data access key (SK T ) is removed permanently.
  • the blockchain-based wallet can only be accessed by the sender or the recipient because the first encrypted key and the second encrypted key can only be decrypted by using the respective paired private keys (i.e. SK A and SK B ) of the corresponding public keys of the sender and the recipient that are used to encrypt them (i.e. PK A and PK B ).
  • the respective private keys that are used to access the blockchain-based wallet, SK A and SK B are stored locally on a sender device and a recipient device registered with the service provider and owned by a respective sender or recipient.
  • the above-mentioned mechanism provides a high level of security because even if any of the one or more databases storing the encrypted keys is fully compromised and controlled by
  • the hackers will not be able to obtain a copy of the data access key to access the escrow wallet.
  • the sender (buyer) and the recipient (seller) also cannot access the digital asset stored in the wallet before an exchange is completed because the encrypted keys that are stored in the one or more databases (and only accessible by the escrow server) are not released to the parties of the smart contract.
  • the encrypted key is released only to one of the parties, either the sender or the recipient, when an exchange is confirmed to be performed in accordance to the conditions of the smart contract or when a dispute is investigated and resolved.
  • Transaction handling application to facilitate a smart contract for exchanging data or digital asset between a sender (or a seller) and a recipient (or a buyer), for instance, FIAT - Cryptocurrency exchange.
  • the transaction handling application is configured to generate a key-pair using an Asymmetric Cryptography algorithm, for example, an RSA (Rivest-Shamir-Adleman) algorithm.
  • the transaction handling application can be a mobile application, web-based application or a desktop application.
  • a user account can be created by a user by clicking on an activation link, by requesting a QR code or entering a hyperlink address through a web application. The user may also be prompted to register an email address or a user identifier to the escrow server.
  • Escrow Server for receiving the data or digital asset transferred from the sender, verifying payment of an agreed consideration from the recipient to the sender, and releasing the data or digital asset transferred from the sender to the recipient if there is no dispute between the sender and the recipient.
  • the escrow server may be a web server or an application server or the like.
  • the escrow server may comprise more than one servers working in tandem.
  • FIGS 1 A and 1 B show a data communication flow 100 between four apparatuses, namely, an first device 108, an escrow server 1 10, a storage server 1 15 and a second device 104.
  • the first device 108 or the second device 104 is a user mobile device, for example, a smartphone, a tablet personal computer, a laptop, and the like.
  • the escrow server 1 10 in the present example has access to one or more database, which is known herein as a wallet manager database.
  • the wallet manager database may be configured to store details of one or more smart contracts entered by users 102 and 106 that use the services provided by the escrow server.
  • the wallet manager database may also be configured to store one or more encrypted keys for accessing data or asset stored in corresponding one or more data storages created by the storage server 1 15 at the request(s) of the escrow server 1 10.
  • the escrow server 110 that Alice and Bob use as an escrow agent to facilitate their exchange of data or digital asset.
  • the escrow server 1 10 is configured to create an individual data storage 155 to facilitate each exchange between a recipient (or buyer) 102 and a sender (or seller) 106.
  • Each data access key used to access the respective data storage is obtained from the storage server 1 15 and encrypted before storing in the one or more wallet manager databases.
  • a buyer 102 Alice, intends to purchase a digital asset or data (for instance, e-store credits or a digital album or a digital book or cryptocurrency) with USD, while a seller 106, Bob, has the digital asset or data that Alice requires for USD.
  • a transaction handling application installed in her device 104
  • Alice 102 lists an offer 121 on an exchange web page provided by the server 1 10 at a step S120.
  • the offer 121 specifies the following:
  • ETH via DBS Bank Transfer Another example of the offer 121 may be in the form of “1 GB data usage for a day at USD20 via PayPal”.
  • the recipient 102 or the sender 106 may also provide an offer to sell that is only visible to a predetermined sender or a predetermined recipient respectively, for example, through a chat conversation between a sender and a recipient.
  • the transaction handling application installed in a seller’s device (or first device) 108 is configured to allow a seller to list his offer by specifying the following:
  • the Transaction handling application may be configured to allow a user to manage more than one transaction. Therefore, Alice 102 can be a buyer for a first transaction and a seller for a second transaction. Likewise, Bob 106 can be a seller for a first transaction and a buyer for a second transaction.
  • the exchange web page may be polled periodically or continuously to publish one or more available offers that is managed by the escrow server 110 to the users of the Transaction handling application.
  • the one or more available offers may be displayed through a web page or through an interactive menu of the Transaction handling application.
  • the exchange web page may be configured to receive user inputs to bind the buyer 102 and the seller 106 to a smart contract (for initiating an exchange).
  • the Transaction handling application installed in the Alice’s device 104 is configured to:
  • a transaction identifier may be assigned to a transaction to be performed between Alice 102 and a seller.
  • the Transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated first key-pair is then stored locally at the device 104 at a step S124.
  • the escrow server 1 10 may be configured to link the public key of the generated first key-pair with the transaction identifier.
  • the private key SK A of the generated first key-pair may be encrypted with a user-defined password known only to Alice 102 for enhanced security.
  • Alice 102 may choose to back up the first generated key-pair with cloud storage, but such option may be more vulnerable to security threats.
  • the seller 106 may browse the exchange page and decides to make an exchange with the buyer 102, Alice.
  • Bob 106 clicks on an action available for the offer 121 , for instance, a“SELL” button on the exchange web page to initiate an exchange request with the buyer 102 at a step S130.
  • Other actions available for clicking may be viewing the details of the offer, cancelling an agreed exchange (only available for the parties of the exchange), and the like.
  • the seller 106 may be prompted to select a payment mode from the list of payment modes the seller 106 is willing to accept, and provide details of the selected payment mode, for example details of a bank account to receive an agreed consideration (data or asset to be transferred from Alice 102 to Bob 106 as listed in the offer) from the buyer 102.
  • the Transaction handling application installed in the Bob’s device 108 is configured to:
  • the escrow server 1 10 may be configured to modify permissions and/or the details of an offer.
  • an offer may be disabled for further interaction with other users, other than the parties performing the transaction.
  • the escrow server 1 10 may be configured to create a new offer that list the remaining digital asset or data for acceptance by other users.
  • a second key-pair (SK B and PK B ) at Bob’s device 108 for the listed offer 121 initiated by Alice 102 using an Asymmetric Cryptography algorithm, such as the RSA encryption algorithm or Elliptic-curve cryptography, at a step S132.
  • the Transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated second key-pair is stored locally at the device 108 at a step S134.
  • the escrow server 1 10 may be configured to link the public key of the generated second key-pair with the transaction identifier associated with the listed offer 121 .
  • the private key SK B of the generated second key-pair may be encrypted with a user-defined password known only to Bob 106 for enhanced security.
  • Bob 106 may choose to back up the second generated key-pair with cloud storage, but such option may cause his private key to be vulnerable to security threats.
  • the escrow server 1 10 is configured to send a request 139 to the storage server 1 15 to create a disposable data storage (or escrow account) 155 for storing the data or digital asset to be transferred from Bob 106 to Alice 102 at a step S138.
  • the escrow server 1 10 also allows the seller 106 to be a party to initiate the exchange.
  • the storage server 1 15 is configured, at a step S140, to:
  • the storage server 115 may be configured to send the public address of the data storage 55 as identification information of the data storage 155 to the escrow server 110.
  • the key-pair is governed by the following mathematical equations:
  • E pub)ic key (M) indicates encryption of data M using a public key of the key-pair to obtain a resulting ciphertext (or encrypted data) C.
  • D seCret key (C) indicates decryption of encrypted data C using a secret key (or private key) of the key-pair to obtain the data M.
  • the escrow server 110 is configured to send a“Received” signal to the storage server 115 to indicate that the data access key SK T and/or the identification information of the data storage 155 (i.e. the public key PK T of the data access key-pair) are well-received by the escrow server 110.
  • the storage server 115 is configured to delete the generated data access key SK T upon receiving the“Received” signal sent by the escrow server 110.
  • the storage server 115 is configured to delete the generated data access key SK T only when the escrow server 110 sends a“Request” signal that is separate from the “Received” signal to instruct the storage server 115 to delete the generated data access key SK T .
  • the storage server 115 may be configured to send a confirmation signal to the escrow server 110 to notify that the data access key SK T has been deleted.
  • the storage server 115 is configured to delete the generated public key PK T upon receiving the“Received” signal sent by the escrow server 110.
  • the storage server 115 is configured to delete the public key PKT only when the escrow server 110 sends a“Completed” signal indicating the successful transfer of the data stored in the data storage 155 between a first device (e.g. Bob’s device 108) and a second device (e.g. Alice’s device 104).
  • the storage server 115 may be configured to send a confirmation signal to the escrow server 110 to notify that the public key PK T has been deleted.
  • the deletion of the data access key-pair (SK T and PK T ) at the storage server 115 upon receipt of instructions from the escrow server 110 ensures the highest level of security because the only copy of secret key SK T is stored at the user device.
  • the escrow server 110 stores the data access key SK T temporarily on Random Access Memory (RAM) allocated for the corresponding transaction identifier.
  • the escrow server 110 is configured, at a step S144 to:
  • E P K B (SK r ) indicates encryption of the data access key SK T using the public key PK B to obtain the first encrypted key BK.
  • E FKA (SK t ) indicates encryption of the data access key SK T using the public key PK A to obtain the second encrypted key AK.
  • the escrow server 1 10 is configured to employ zero-filing technique to effectively and completely wipe the data access key SK T from the allocated RAM.
  • the escrow server 1 10 is configured to replace memory space in a memory allocated to store the data access key with data not related to the data access key. In such arrangement, the specific addresses of the RAM used to store the data access key SK T may be stored by the escrow server 1 10 to facilitate post processing.
  • the escrow server 1 10 may be further configured to perform a check on the one or more wallet manager databases to ensure that there is indeed no presence of the data access key SK T, This means that the escrow server 1 10 is configured to store only the first encrypted key BK and/or the second encrypted key AK (and not the data access key SK T ) in the one or more wallet manager databases. It should be appreciated that the data access key SK T can be subsequently retrieved by decrypting the second encrypted key AK or the first encrypted key BK with the corresponding private key SK A of Alice 102 or private key SK B of Bob 106.
  • the encrypted data access keys AK and BK may be duplicated in one or more databases accessible by the escrow server.
  • a data storage for storing data to be transferred between two parties and managed by the escrow server 110 can be more secured. Even if the escrow server 1 10 is subjected to security threats from a hacker or an eavesdropper, he will not be able to access the disposable data storage 155 because the private keys are not stored at the escrow server 110. Note that users are not able to access the data storage 155 because they do not have access to the encrypted keys stored at the one or more wallet manager databases of the escrow server 110.
  • the escrow server 1 10 is configured to deliver one of the encrypted keys (i.e. AK or BK) to one of the parties of the exchange (either Alice 102 or Bob 106), when an exchange is confirmed to be performed properly (without dispute) or when a dispute process is completed. Specifically, when an exchange is confirmed to be performed successfully (without dispute), a notification is sent from the first device (e.g. seller’s device) to the escrow server 110 to enable sending of the second encrypted key to the second device (e.g. buyer’s device).
  • the first device e.g. seller’s device
  • the escrow server 110 to enable sending of the second encrypted key to the second device (e.g. buyer’s device).
  • a notification indicating not to send the second encrypted key to the second device is sent from the first device to the escrow server 1 10 and/or a notification indicating not to send the first encrypted key to the first device is sent from the second device to the escrow server 1 10. Details on when the encrypted keys are released will become apparent in the following paragraphs.
  • a disposable data storage used herein may be considered as a data storage that is only used for a particular exchange between a buyer and a seller.
  • the escrow server 110 is configured to not use the created data storage again after the particular exchange is completed.
  • a new disposable data storage 1 15 has to be created. This is in contrast to the previously mentioned existing exchange platform (such as the system illustrated in Figure 5), where there is only one permanent data storage that is used for all the exchange transactions between any buyer and any seller. Note that the disposable data storage 155 is not illustrated in Figure 1 A for simplicity.
  • the disposable data storage 155 may be configured to be deleted from the storage server 1 15 if it is determined that the data transferred from a seller’s device into the storage medium 155 has been transferred to a destination indicated by a buyer 102 and a predetermined time has lapsed from such determination.
  • the escrow server 110 may be configured to send a request to the storage server 1 15 to delete the disposable data storage 155 from the storage server 1 15 if it is determined that the data transferred from a seller’s device into the storage medium 155 has been transferred to a destination indicated by a buyer.
  • the escrow server 1 10 is configured to send a notification 147 indicating the details of the data storage 155 to Bob 106 at a step S146 for him to deposit his data or digital asset that he is transferring to Alice 102.
  • the public address of the data storage 155 can be sent to Bob 106, such as a receiving ETH Address wallet: 0x9ab517b68ce2dfbb9c6c095594e92eaa2a0ebf72.
  • an escrow account may, for example, be represented by an Ethereum address AD.
  • an Ethereum account may, for example, be represented by an Ethereum address AD.
  • the following key-pair may be generated for the Ethereum account: Public key: 040a191 e4ae5c0cf4126f41f28a337f52097fe99c5681995f6a4e08 d21 1 a2d2 e8
  • the public key is in an uncompressed format.
  • the uncompressed public key is 65 bytes long, consisting of a constant prefix (0X04), followed by two 256-bit integers called x and y (2 * 32 bytes).
  • the Ethereum address AD can be subsequently derived from the generated public key of the escrow account by any method easily envisaged to a skilled person. For instance, the prefix of the public key is dropped and a Keccak-256 hash algorithm is performed to output a string that is 32 bytes (or 64 characters) long. The Ethereum address AD is then obtained by taking the rightmost 20 bytes of the output string, and summarised with the following equation:
  • AD the rightmost 160-bit of (KEC(PK)) - Eqn. (5)
  • AD is an Ethereum address of a created Ethereum account
  • PK is the corresponding public key of the Ethereum account (without the prefix and in an uncompressed format)
  • KEC indicates the output string after Keccak-256 hashing of the public key of the Ethereum account.
  • the output string has a length of 64 characters or 32 bytes.
  • KEC(PK) 04e8cd0b787aef3de97b76fc794892d31 ad6c095c78933a883334560971 d6140
  • AD the rightmost 160-bit of (KEC(PK)) or
  • the Ethereum address AD is in a hexadecimal format (i.e. base 16 notation), which is often indicated explicitly by prepending“Ox” to the address. Since each byte of the address is represented by 2 hex characters, a prefixed address is 42 characters long.
  • An Ethereum address is a string of characters consisting of random digits and uppercase and lowercase letters. The uppercase letter ⁇ ”, uppercase letter “I” and lowercase letter ⁇ ” are rarely used to prevent visual ambiguity.
  • keccack-256 hashing algorithm is different from the FIPS-202 based standard (i.e. NIST SHA-3 standard). It may be possible in the future to obtain an Ethereum address after employing NIST SHA-3 hashing to the public key.
  • the process of deriving a public address for identifying a data storage from a corresponding public key of the data storage can be performed at the escrow server 110, the storage server 115 and/or by the Transaction handling application installed at the devices 104 and/or 108.
  • Bob 106 transfers the data 149 that Alice 104 wants to exchange into the data storage 155.
  • the escrow server 1 10 sends Alice 102, at a step S150, a notification indicating Bob’s transfer into the data storage 155 and a request for Alice 102 to transfer an agreed consideration 153 (i.e. data to be transferred from Alice 102 to Bob 106) to Bob 106 through a command 151.
  • Alice 102 then sends the agreed consideration 153 to Bob 106 with the payment details provided by Bob at a step S152.
  • the escrow server 110 may be configured to determine whether the data stored in the data storage 155 matches the data to be transferred between Alice 102 and Bob 106. In one example, the escrow server 110 may be configured to receive information from Bob 106 (such as evidence indicating the correct data has been transferred in the data storage 155) to enable sending a request to Alice 102 to send the agreed consideration to Bob 106. In another example, the storage server 1 15 may be configured to notify the escrow server 110 when the data 149 has been transferred into the data storage 155.
  • the escrow server 1 10 may be configured to determine, based on the received notification from the storage server 1 15, whether the data stored in the data storage matches the data to be transferred from Bob 106 To Alice 102. Hence, in one arrangement, the escrow server 1 10 may be configured to verify that the data or digital asset to be transferred from Bob 106 to Alice 102 and stored in the data storage 155 matches a condition of the smart contract entered by Alice 102 and Bob 106.
  • the escrow server 110 verifies the amount of cryptocurrency deposited in the data storage (or escrow account) 155 is correct.
  • the escrow server 110 is configured to determine the amount of cryptocurrency to be transferred from the seller 106 to the buyer 102 (assuming the seller 106 is exchanging cryptocurrency for FIAT -currency). If the amount of cryptocurrency deposited into the data storage 155 is less than the determined amount, the escrow server 110 may be configured to notify the seller 106 to ensure the correct amount is deposited in the data storage 155.
  • the escrow server 110 may be configured to send to the seller 106 a notification including identification information of another escrow account for storing the amount of cryptocurrency to be transferred to the buyer 102. This will ensure that none of the parties of the exchange can gain access to a data storage managed by the escrow server 110.
  • the escrow server 1 10 may be configured to send the respective encrypted key to the Bob 106 to obtain the data access key (i.e. SK T ) for retrieving all the cryptocurrency he has deposited in the earlier escrow account.
  • the escrow server 1 10 may be configured to perform the following steps to determine whether the amount of ETH transferred into the data storage 155 is correct:
  • API Application Programming Interface
  • the escrow server determines whether the amount of ETH that Bob deposited is correct based on the balance reflected on the Ethereum’s ledger and the retrieved transaction history of the escrow account.
  • This notification 157 is also an indication that Bob 106 has received the agreed consideration from Alice 102 and that he verified that the agreed consideration matches his expectation (e.g. full payment) at a step S154.
  • Bob 106 is expected to use the Transaction handling application, specify the transaction in question and click on a 'Money Received’ button to send the notification 157 to the escrow server 110.
  • the escrow server 110 may be further configured to record a time stamp when an exchange agreement (or a smart contract) is entered, a time stamp when the sender (or the seller) 106 transfers the data to the data storage 155, a time stamp when the recipient (or buyer) 102 sends the agreed consideration to the seller and a time stamp when the buyer 102 notifies the escrow server 1 10 about the receipt of the agreed consideration.
  • time stamps may be used to determine validity of the smart contract and/or used during a settlement of a dispute between a seller and a buyer.
  • the escrow server 110 is configured to release the second encrypted key A K to Alice 102 at a step 156 through a command 159 to Alice’s device 104.
  • the buyer 102, Alice can then use her private key SK A that is stored locally at her device 104 to decrypt the received second encrypted key, AK, to obtain the key, SK T , to access the data or digital asset stored in the data storage 155 at a step S158.
  • D SKA indicates decryption of the second encrypted key AK using the private key SK A to obtain the data access key SK T .
  • the obtained data access key SK T is then used to access the data or digital asset that Bob 106 has transferred into the data storage 155 at a step S160.
  • the data storage 155 can be identified by identification information of the data storage 155 provided to Alice.
  • the transferred data 163 from Bob 106 can subsequently be transferred to any account or device designated by Alice 102 or downloaded to her device 104 by sending a command 161.
  • the escrow server 110 is not configured to store the data access key SK T , the escrow server 110 is still able to grant access of the data storage 155 to either Alice 102 or Bob 104. This is because the escrow server 1 10 is configured to store AK and BK, which are encrypted versions of the original data access key SK T .
  • Allowing access to the data storage 155 is performed by delivering one of the relevant encrypted keys, which is either SK A or SK B , to the respective user, who is either Alice 102 or Bob 104. This is a simple yet secured way of storing individual keys at the one or more wallet manager databases.
  • Figures 1A and 1 B illustrate a scenario where the exchange between Alice 102 and Bob 106 succeed.
  • the escrow server 1 10 is configured to assist Alice or Bob in the dispute settlement.
  • the escrow server 1 10 is configured to deliver the corresponding encrypted key, AK or BK, to a winner of the dispute settlement. For instance, if Bob 106 is the winner of the dispute, the escrow server 1 10 is configured to deliver the first encrypted key, BK, to Bob 106.
  • the escrow server 1 10 is configured to deliver the second encrypted key, AK, to Alice 102.
  • the escrow server 1 10 may be configured to withhold the first encrypted key BK and the second encrypted key AK if a dispute is initiated by Alice 102 or Bob 106. For instance, if the data to be transferred from Bob 106 to Alice 102 is determined to be incorrect, the second encrypted key AK is not sent to Alice 102 and the first encrypted key BK is not sent to Bob 106.
  • the escrow server 1 10 may determine if a predetermined duration from an onset of the creation of the data storage has lapsed.
  • the escrow server 110 may send a reminder to the sender 106 to transfer the data to be transferred to the buyer 102 or terminate the smart contract between the buyer 102 and the seller 106 so that a new party can accept the listed offer 121.
  • the escrow server 1 10 may be configured to receive a first notification from the first device 108 indicating not to send the second encrypted key to the second device 104; send a second notification to the second device 104 to notify about the first notification; obtain from the second device 104 information to enable sending the second encrypted key to the second device 104; and receive a user instruction to send the second encrypted key to the second device 104 after obtaining the information to enable sending the second encrypted key from the second device 104.
  • the escrow server 1 10 may be configured to send the first encrypted key to the first device 108 if the information to enable sending the second encrypted key to the second device 104 cannot be obtained from the second device 104 within a predetermined time.
  • Alice 102 does not send any money to Bob 106 (No at S170);
  • Alice 106 does not send the correct amount of money to Bob 106 (Yes at S170, but No at
  • Alice 102 genuinely sends the correct amount of money to Bob 106 (Yes at S174), but Bob
  • 106 is a cheater and wishes to trick the escrow server 1 10 to release the first encrypted key
  • the escrow server 110 will inform the buyer 102 of the irregularity report received from the sender 106.
  • the irregularity report acts as a first notification from the device 108 to instruct the escrow server 110 not to send the second encrypted key AK to the device 104.
  • the escrow server may be configured to:
  • An example of information to enable sending the second encrypted key AK to the device 104 is a confirmation (for example, payment of proof) indicating the agreed consideration 153 has been sent to the sender 106 at a step S172.
  • the escrow server 1 10 is configured to determine, based on the obtained information to enable sending of the second encrypted key to the second device 104, whether access to the data storage 155 should be granted to the sender 106 or the recipient 102. Specifically, the escrow server 1 10 is configured to allow the sender 106 access to the data storage 155 by releasing the first encrypted key BK to the seller 106, if the confirmation cannot be obtained from the buyer 102. In one example, the escrow server 110 is configured to verify with a trusted party, for instance, with the banks, payment agent, the authenticity of the confirmation received from the buyer 102 before granting the buyer 102 or the sender 106 access to the data storage.
  • a trusted party for instance, with the banks, payment agent
  • the escrow server 1 10 is configured to send the second encrypted key to the buyer’s device 104 upon receiving a user instruction after obtaining the information to enable sending of the second encrypted key to the buyer’s device 104.
  • authentication can be done by a bank processing officer, and in such example, the release of the second encrypted key is initiated by the approval of the bank processing officer (e.g. clicking on a predetermined user input, sending a message, for example, via Short Messaging Service (SMS) to a predetermined number, or entering a one-time- password and the like).
  • SMS Short Messaging Service
  • Alice 102 is requested to provide a proof of payment at a step S180. If Alice 102 is not able to produce the proof of payment at step S180, the escrow server 1 10 is configured to grant Bob 106 access to the data storage 155 by releasing the first encrypted key BK to Bob 106 at a step S186. Bob can then decrypt the first encrypted key BK with his private key SK B to obtain the data access key SK T to access the data storage 155 to retrieve the ETH fund he has deposited in step S148.
  • the escrow server 110 may be configured to check if the proof of payment sent by the Alice 102 is authentic and/or the amount to be transferred to Bob 106 is correct. The proof of payment may be verified with a trusted party, for instance, with the banks, payment agent, to determine if the proof of payment is authentic at a step S182. For instance, if the proof of payment is determined to be authentic at step S182 (i.e. Alice 102 is not a cheater), the escrow server 110 is configured to allow Alice 102 access to the data storage 155 by releasing the second encrypted key AK to the Alice 102 at a step S190. Alice can then decrypt the second encrypted key AK with her private key SK A to obtain the data access key SK T to access the data storage 155 to withdraw the ETH fund that Bob 106 has transferred in step S148.
  • a trusted party for instance, with the banks, payment agent
  • the proof of payment submitted by Alice 102 may be determined through an image processing process at the escrow server 1 10 to verify the amount transmitted to the seller 106 and/or the bank account details of the seller 106.
  • the escrow server 110 may also send a request to an independent financial institution, such as the bank, to verify that the transaction listed on the proof of payment is successful.
  • a user instruction may be received using the Transaction Handling application to send the second encrypted key to the second device 104 after obtaining the information to enable sending the second encrypted key from the second device 104.
  • the escrow server 1 10 may be configured to determine from the information obtained from the second device 104 whether to send the second encrypted key to the second device 104, for instance, through fuzzy logics, deep-learning algorithms and the like.
  • the escrow server 110 will release the first encrypted key BK to Bob 106 at step S186.
  • Bob can then decrypt the first encrypted key BK with his private key SK B to obtain the data access key SK T to access the data storage 155 to retrieve the ETH fund he has deposited in step S148.
  • the Escrow server 110 will release the second encrypted key AK to Alice 102 and as a result, the ETH fund deposited by Bob 106 can be obtained by Alice 102 at a step S188. Note that such limitations are the same as with the conventional exchange platforms.
  • the buyer 102 can also initiate a dispute (not illustrated in Figure 1 C). If the irregularity report is received at the escrow server 1 10 indicating that the buyer 102 has not received the second encrypted key AK (despite the agreed consideration 153 has been sent to the seller 106), the escrow server 1 10 may be configured to obtain from the buyer 102 a confirmation (for example, payment of proof) indicating the agreed consideration 153 has been sent to the sender 106 at a step S172. Subsequently, steps S182 to S190 are repeated to determine whether the second encrypted key AK can be sent to the buyer 102. The escrow server may be configured to issue a notification to inform the seller 106 that the buyer 102 has raised a dispute.
  • a confirmation for example, payment of proof
  • the escrow server 1 10 is configured to allow Alice 102 access to the data storage 155 by releasing the second encrypted key AK to Alice 102 at a step S178 (and indicated as S156 in Figure 1 B).
  • the escrow server can provide a high level of availability of the encrypted keys.
  • a decentralised and distributed system is employed to serve a large number of users and transactions.
  • servers of a distributed system such as the escrow server 1 10) to be overloaded and be malfunctioning. Therefore, having encrypted keys in more than one escrow server and/or more than one wallet manager database can provide some relief to such problem.
  • the replication across the plurality of wallet manager database enables encrypted keys to be able to be delivered from many sources (or any of the escrow servers). This will allow the encrypted keys to be easily available to relevant parties (such as a sender or a recipient), even in the case a part of the platform managed by the escrow server 1 10 is unavailable.
  • Replicating the encrypted keys (e.g. AK or BK of Figures 1A and 1 B) to more than one escrow server and/or one wallet manager databases also offer a faster delivery mechanism of the respective encrypted keys to the sellers or the buyers.
  • the escrow server 1 10 may be configured to release the first encrypted key or the second encrypted key from one of the one or more escrow servers that has access to more than one wallet manager databases that is geographically closer to the respective seller’s device (first device) or the buyer's device (second device).
  • replicating the encrypted keys e.g. AK or BK of Figures 1A and 1 B
  • replicating the encrypted keys is also desirable for system robustness.
  • recovery of these encrypted keys from a back-up server or an uncompromised server is possible.
  • the above-mentioned escrow server 1 10 may be configured to support one buyer - multiple sellers and one seller - multiple buyers application. Essentially, one buyer-to-many sellers and many sellers-to-one buyer exchange can be represented by a plurality of one-to-one exchanges. In such applications, the escrow server 1 10 is configured to manage multiple escrow accounts (or disposable data storages) to complete the plurality of exchanges.
  • escrow accounts or disposable data storages
  • FIG. 2A A detailed discussion of a one buyer-two sellers application involving an escrow server 210 is illustrated with reference to Figures 2A to 2C. Although in the example of Figures 2A to 2C, a FIAT- cryptocurrency exchange is discussed, it should be appreciated that the escrow server 210 may be configured to facilitate secured digital currency exchanges, FIAT to digital currencies, transfer of sensitive data or other applications readily deduced by those skilled in the art.
  • Figures 2A to 2C show a data communication flow between five apparatuses, namely, a buyer device 204, an escrow server 210, a storage server 215, a first seller device 208 and a second seller device 214.
  • the buyer device 204 or the first seller device 208 or the second seller device 214 may be a user mobile device, for example, a smartphone, a tablet personal computer, a laptop, and the like.
  • the user devices are each installed with a Transaction handling application for a smart contract involving exchange of data or digital asset between a sender (or a seller) and a recipient (or a buyer), for instance, FIAT - Cryptocurrency exchange.
  • the Transaction handling application is configured to generate a key-pair using an Asymmetric Cryptography algorithm, for example, an RSA (Rivest-Shamir-Adleman) algorithm.
  • the Transaction handling application can be a mobile application, web-based application or a desktop application.
  • the escrow server 210 in the present example has access to one or more database, which is known herein as a wallet manager database.
  • the wallet manager database may be configured to store details of one or more smart contracts entered by users 202, 206 and 212 that use the services provided by the escrow server 210.
  • the wallet manager database may also be configured to store one or more encrypted keys to access data or digital asset stored in corresponding one or more data storages created by the storage server 215.
  • the escrow server 210 that Alice 202, Bob 206 and Charlie 212 used as an escrow to facilitate their exchange of data or digital asset.
  • the escrow server 210 is configured to create an individual data storage to facilitate each exchange between a recipient (or buyer) 202 and each of the respective senders (or sellers) 206 and 212.
  • Each data access key used to access the respective data storage is obtained from a storage server 215 and encrypted before storing in the one or more wallet manager databases.
  • Alice 202 is a common buyer in this FIAT-cryptocurrency flow between the three users 202, 206 and 212.
  • Bob 206 and Charlie 212 are two sellers exchanging cryptocurrency (and in this example is ETH) with Alice who is willing to buy with FIAT (and in this example is USD)
  • Alice 202 lists an offer 221 on an exchange web page provided by the escrow server 210 that specifies the following:
  • This offer indicates that Alice wants to buy 2 units of Ethereum (ETH) at an exchange rate of 1 ETH: USD 1000, and she will pay the seller via DBS Bank Transfer.
  • the buyer 202, the sender 206 or the sender 212 may also provide an offer to sell or buy that is only visible to a predetermined sender or a predetermined recipient respectively, for example, through a chat conversation between a sender and a recipient (not illustrated in Figures).
  • the exchange web page may be polled periodically or continuously to publish one or more available offers that is managed by the escrow server 210 to the users of the Transaction handling application.
  • the one or more available offers may be displayed through a web page or through an interactive menu of the Transaction handling application.
  • the exchange web page may be configured to receive user inputs to bind each buyer and each seller with a smart contract (for initiating an exchange).
  • a smart contract may become effective once a condition set by a user is reached (e.g. bidding price is matched).
  • the Transaction handling application installed in the Alice’s device 204 is configured to:
  • a transaction identifier may be assigned to a transaction to be performed between Alice 202 and one seller.
  • SK A and PK A Generate a first key-pair (SK A and PK A ) at Alice’s device 204 for the listed offer 221 initiated by Alice 202 using an Asymmetric Cryptography algorithm, such as the RSA encryption algorithm or Elliptic-curve cryptography, at a step (2).
  • the Transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated first key-pair SK A and PK A is then stored locally at the device 204.
  • the escrow server 110 may be configured to link the public key PK A of the generated first key-pair with the transaction identifier.
  • the private key SK A of the generated first key-pair may be encrypted with a user-defined password known only to Alice 202 for enhanced security.
  • Alice 202 may choose to back up the first generated key-pair SK A and PK A with cloud storage, but such option may expose the private key SK A to security threats.
  • Bob 206 and Charlie 212 may browse the exchange page and indicate that they would like to make an exchange with Alice 202.
  • Bob’s acceptance may occur at a different time from Charlie’s acceptance.
  • Bob 206 and/or Charlie 212 may click on a button“TO SELL” that is provided proximate to the listed offer 221.
  • Other actions available for selection may be viewing the details of the offer, cancelling an agreed exchange (once the seller/buyer accepts the offer), and the like.
  • Bob 206 and Charlie has only one ETH each for exchange, but their total amount of ETH matches the amount indicated in Alice’s listed offer 221 . Therefore, the escrow server 210 may arrange a three-party exchange between Alice 202, Bob 206 and Charlie 212.
  • an offer can be initiated by any of the users: Alice 202, Bob 206 or Charlie 212.
  • the escrow server 210 may be configured to determine if there is a single user that matches the listed offer. For instance, in the present example illustrated by Figure 2A, if the buyer 202 has tasked the escrow server 210 to proceed with the exchange if the specified conditions in the offer 221 are matched, the escrow server 210 may be configured to arrange an exchange between Alice and a seller who can sell 2 ETH to Alice in a single transaction.
  • the escrow server 210 may be configured to perform the exchange between Alice and any seller who is willing to perform an exchange with Alice (e.g. browsing the exchange page and sending an acceptance command to the escrow server 210, as in the present example illustrated by Figure 2A.
  • the Transaction handling application installed in the Bob’s device 208 is configured to:
  • the escrow server 210 may be configured to modify permissions and/or the details of an offer.
  • an offer may be disabled for further interaction with other users, other than the buyer or the seller who is performing the exchange.
  • the escrow server 210 may be configured to list a new offer indicating the remaining digital asset or data for acceptance by other users.
  • - Generate a second key-pair (SK B and PK B ) at Bob’s device 208 for the listed offer 221 using an Asymmetric Cryptography algorithm, such as the RSA encryption algorithm or Elliptic- curve cryptography at a step (3).
  • the Transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated second key-pair is stored locally at the device 208.
  • the escrow server 210 may be configured to link the public key of the generated second key-pair with the transaction identifier associated with the listed offer 221.
  • the private key SK B of the generated second key-pair may be encrypted with a user-defined password known only to Bob 206 for enhanced security.
  • Bob 106 may choose to back up the second generated key-pair with cloud storage, but such option may be vulnerable to security threats.
  • Bob 206 may be prompted to provide details of a payment mode indicated in the listed offer at the time of accepting the listed offer 221 , for example details of a bank account to receive an agreed consideration (i.e. USD) from Alice 202.
  • the escrow server 210 is configured to send a request 239 to the storage server 215 to create a disposable data storage (or escrow account) 155 for storing data or digital asset to be transferred from Bob 206 to Alice 202 at a step 4a.
  • the storage server 215 Upon receiving the request 239, the storage server 215 is configured to:
  • a public address of the data storage 155 can be derived from the public key RK p and sent to the escrow server 210 as identification information of the data storage 155.
  • the escrow server 210 stores the first data access key SK Ti temporarily on Random Access Memory (RAM) allocated for the corresponding transaction identifier (or exchange).
  • the escrow server 210 is configured to:
  • Erk B indicates encryption of the first data access key SK Ti using the public key PK B to obtain the first encrypted key BK.
  • E PKA (SK r1 ) indicates encryption of the data access key SK Ti using the public key PK A to obtain the second encrypted key AK B .
  • the escrow server 210 is configured to employ zero-filing technique to effectively and completely wipe the first data access key SK Ti from the allocated RAM.
  • the escrow server 210 is configured to replace memory space in a memory allocated to store the data access key with data not related to the first data access key SK Ti .
  • the specific addresses of the RAM used to store the first data access key SK T1 may be stored by the escrow server 210 to facilitate post processing (e.g. deletion of first data access key).
  • the escrow server 210 is configured to set up an exchange between Alice 202 and Charlie 212 in a similar fashion as how it sets up an exchange between Alice 202 and Bob 206.
  • Charlie browses the exchange web page and accepts Alice’s offer for instance, by clicking on a“TO SELL” button to indicate that he wishes to sell 1 ETH to Alice 202.
  • Charlie 212 may be prompted to provide details of a payment mode indicated in the listed offer, for example, details of a bank account to receive an agreed consideration (i.e. USD) from Alice 202.
  • an agreed consideration i.e. USD
  • Charlie specifies details of his DBS Bank Account for receiving USD from Alice.
  • the Transaction handling application installed in the Charlie’s device 214 is configured to:
  • the escrow server 210 may be configured to modify permissions and/or the details of an offer.
  • an offer may be disabled for further interaction with other users, other than the buyer and the seller who are performing the exchange.
  • the escrow server 210 may be configured to list a new offer on the remaining digital asset or data for acceptance by other users.
  • SK C and PK C Generate a third key-pair (SK C and PK C ) at Charlie’s device 214 for the listed offer 221 using an Asymmetric Cryptography algorithm, such as the RSA encryption algorithm or Elliptic- curve cryptography at a step (6).
  • the Transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated second key-pair is stored locally at the device 214.
  • the escrow server 210 may be configured to link the public key of the generated second key-pair with the second transaction identifier associated with the listed offer 221 .
  • the private key SK C of the generated second key-pair may be encrypted with a user-defined password known only to Charlie 212 for enhanced security. Charlie 212 may choose to back up the second generated key-pair with cloud storage, but such option will expose Charlie’s private key SK C to security threats.
  • the escrow server 210 is configured to send a request 249 to the storage server 215 to create a disposable data storage (or escrow account) 255 for storing data or digital asset to be transferred from Charlie 212 to Alice 202 at a step 7a.
  • the storage server 215 Upon receiving the request 249, the storage server 215 is configured to:
  • the escrow server 210 obtains the second data access key SK T2 from the storage server 215 at a step 7(b), the escrow server 210 stores the second data access key SK T2 temporarily on Random Access Memory (RAM) allocated for the corresponding transaction identifier.
  • the escrow server 1 10 is configured to:
  • E PKC indicates encryption of the second data access key SK T2 using the public key PK C to obtain the third encrypted key CK.
  • E PKA (SK T2 ) indicates encryption of the second data access key SK T2 using the public key PK A to obtain the fourth encrypted key AK C .
  • the escrow server 210 is configured to employ zero-filing technique to effectively and completely wipe the second data access key SK T2 from the allocated RAM.
  • the escrow server 210 is configured to replace memory space in a memory allocated to store the data access key SK T2 with data not related to the second data access key SK T2 . In such arrangement, the specific addresses of the RAM used to store the second data access key SK T2 may be stored by the escrow server
  • the escrow server 210 is configured to store two encrypted versions (AK B and BK) of a data access key to access a data storage 155 and is configured to store two encrypted versions (AK C and CK) of a second data access key to access a data storage 255, wherein AK B and BK are associated with the first transaction of 1 ETH between Alice 202 and Bob 206, and AK C and CK are associated with the second transaction of 1 ETH between Alice 202 and Charlie 212.
  • step 8(a) may be performed before step 8(b) and/or step 5(a) may be performed before step 5(b). This means that the order of encrypting the data access key SK Ti and/or second data access key SK T2 with the respective public keys can vary.
  • the escrow server 210 may further be configured to perform a check on the one or more wallet manager databases to ensure that there is indeed no presence of the original data access keys SK T1 and SK T2 .
  • the data access key SK T1 can be subsequently retrieved by decrypting the first encrypted key BK with the corresponding private key SK B of Bob 206 or decrypting the second encrypted key AK B with the corresponding private key SK A of Alice 202
  • the second data access key SK T2 can be subsequently retrieved by decrypting the third encrypted key CK with the corresponding private key SK C of Charlie 212 or decrypting the fourth encrypted key AK C with the corresponding private key SK A of Alice 202.
  • the encrypted data access keys AK B , AK C , BK and/or CK may be duplicated in one or more databases accessible by the escrow server 210.
  • the escrow server 210 is configured to send a notification indicating the details of the data storage 155 to Bob 206 for him to deposit the 1 ETH that he is transferring to Alice 202 and a notification indicating the details of the data storage 255 to Charlie 212 for him to deposit the 1 ETH that he is transferring to Alice 202.
  • two different receiving ETH Address wallets are sent to Bob 206 and Charlie 212 respectively. Note that the transfer from Bob 206 to the data storage 155 and the transfer from Charlie to the data storage 255 can take place about the same time or at two distinct time frames.
  • the escrow server 110 Before requesting Alice 202 to send an agreed consideration to Bob 206 so as to enable sending of an encrypted key to Alice 202 for accessing the data storage 155, the escrow server 110 may be configured to determine whether the data stored in the data storage 155 matches the data to be transferred between Alice and Bob. Likewise, before requesting Alice 202 to send an agreed consideration to Charlie 212 in order to enable sending of another encrypted key to Alice 202 for accessing the data storage 255, the escrow server 1 10 may be configured to determine whether the data stored in the data storage 255 matches the data to be transferred between Alice and Charlie.
  • the storage server 215 may be configured to notify the escrow server 210 when ETH has been deposited into the data storage 155 and/or data storage 255 at a step 9(a) and a step (10) respectively.
  • the escrow server 210 may be configured to verify, based on the notification, that the amount of cryptocurrency deposited in the data storage 155 and/or 255 matches the amount indicated in the offer.
  • the escrow server 210 may be configured to communicate with the storage server 155 and/or 255 to retrieve transactions performed in connection to the data storages 155 and/or 255 (i.e. transactions that involve data into and/or out of the data storages 155 and/or 255).
  • the retrieved transaction history can be used to determine whether data Bob 206 or Charlie 212 has deposited into the respective data storages matches the data to be transferred from Bob 206 or Charlie 212 (and listed in the respective offer).
  • the escrow server 210 may be configured to notify the respective seller (i.e. Bob 206 or Charlie 212) and request the respective seller to deposit more ETH into the respective data storages 155 or 255 to match the amount Alice 202 agreed to change with Bob 206 or Charlie 212. This means that if the amount deposited in the data storage does not match the data to be transferred, the escrow server will not proceed with the exchange.
  • the escrow server 210 may be configured to send their respective encrypted keys BK and CK to obtain the respective data access keys SK Tj or SK T2 to Bob 206 or Charlie 212 to withdraw the deposited amount in the respective data storage 155 or 255.
  • the escrow server 210 may be configured to send a notification to Bob 206 or Charlie 212 correspondingly, wherein the notification includes identification information of another data storage for storing the data to be transferred from Bob 206 (or Charlie 212).
  • the escrow server 210 is configured to request the storage server 215 to create a new data storage to perform the exchange of data between Alice 202 and Bob 206 (or Charlie 212).
  • the escrow server 210 sends Alice 202 through a command at a step 9(b) a notification indicating Bob's transfer of data (in this example, ETH) into the data storage 155 and a request for Alice 202 to transfer an agreed consideration (in this example, in USD) to Bob 206.
  • Alice 202 then sends at a step (12) the agreed consideration to the Bob 206 with the payment details provided by Bob 206.
  • Bob 206 receives the agreed consideration, he is required to send a confirmation request 260 to the escrow server 210 to indicate that he has received the agreed consideration at a step (13).
  • the confirmation request 260 is example of a notification to the escrow server 210 from the seller’s device to send the second encrypted key AK B to the buyer’s device.
  • Bob 206 is expected to use the Transaction handling application, specify the transaction in question and click on a 'Money Received' button to notify the escrow server 210 that he received the correct consideration from Alice 202.
  • the escrow server 210 sends Alice 202 through a command, at a step (11 ), a notification indicating Charlie’s transfer into the data storage 155 and a request for Alice 202 to transfer an agreed consideration to Charlie 212.
  • Alice 202 then sends the agreed consideration at a step (17) to the Charlie 212 with the payment details provided by Charlie 212.
  • Charlie 212 receives the agreed consideration, he is required to send a confirmation request 262 to the escrow server 210 to indicate that he has received the agreed consideration at a step (18).
  • the confirmation request 262 is example of a notification to the escrow server 210 from the seller’s device to send the fourth encrypted key AK C to the buyer’s device.
  • Charlie 212 is expected to use the Transaction handling application, specify the transaction in question and click on a 'Money Received' button to notify the escrow server 210 that he received the correct consideration from Alice 202.
  • the escrow server is configured to send the second encrypted key AK B to Alice 202 at a step (14) to Alice’s device 204.
  • the buyer 202, Alice can then use her private key SK A that is stored locally at her device 204 to decrypt the received second encrypted key, AK B , at a step (15) to obtain the first data access key, SK T1 , for accessing the ETH fund stored in the data storage 155.
  • D$K A (AK b ) indicates decryption of the second encrypted key AK B using the private key SK A to obtain the first data access key SK Ti .
  • the obtained first data access key SK T1 is then used at a step (16) to access the data or digital asset (in this example, 1 ETH) stored in the data storage 155 that Bob 206 has transferred.
  • the data storage 155 can be identified by identification information of the data storage 155 provided to Alice 202.
  • Bob’s 1 ETH can subsequently be transferred to any account or device designated by Alice 202 or downloaded to her device 204 by inputting a dedicated command.
  • the escrow server 210 is configured to send the fourth encrypted key AK C to Alice 202 at a step (19) to Alice’s device 204.
  • the buyer 202, Alice can then use her private key SK A that is stored locally at her device 204 to decrypt the received fourth encrypted key, AK C , to obtain the second data access key, SK T2 , for accessing the ETH fund stored in the data storage 255 at a step (20).
  • D SKA indicates decryption of the fourth encrypted key AK C using the private key SK A to obtain the second data access key SK T2 .
  • the obtained second data access key SK T2 is then used at a step (21 ) to access the data or digital asset (in this example, 1 ETH) stored in the data storage 255 that Charlie 212 has transferred.
  • the data storage 255 can be identified by identification information of the data storage 255 provided to Alice 202. Charlie’s 1 ETH can subsequently be transferred to any account or device designated by Alice 202 or downloaded to her device 204 by inputting a dedicated command.
  • the release of the fourth encrypted key AK C to Alice 202 is performed before the release of the second encrypted key AK B to Alice 202, it should be appreciated the release of the fourth encrypted key AK C to Alice 202 can be done at substantially the same time or before the release of the second encrypted key AK B to Alice 202. in other words, the progress of a first transaction is independent of the progress of a second transaction in a three party exchange.
  • a dispute resolution process as discussed in Figure 1 C may be initiated (i.e. no release of encrypted key to any parties until the dispute is settled).
  • the exchange between Alice 202 and Charlie 212 will continue without consideration of the progress of the exchange transaction between Alice 202 and Bob 206.
  • Alice is able to receive the fourth encrypted key AK C and decrypt it with Alice’s own private key SK A to obtain the second data access key SK T2 used to access the data or digital asset stored in the data storage 255.
  • FIG. 3A to 3C A detailed discussion of a one seller-two buyers application is illustrated with reference to Figures 3A to 3C. Although in the example of Figures 3A to 3C, a FIAT-cryptocurrency exchange is discussed, it should appreciated that the escrow server 210 may be configured to facilitate secured digital currency exchanges, FIAT to digital currencies, transfer of sensitive data or other applications readily deduced by those skilled in the art.
  • the same reference numerals used in Figures 2A to 2C are also used in Figures 3A to 3C to refer to the same element.
  • Figures 3A to 3C show a data communication flow between five apparatuses, namely, a seller device 204, an escrow server 210, a storage server 215, a first buyer device 208 and a second buyer device 214.
  • the seller device 204, the first buyer device 208 or the second buyer device 214 may be a user mobile device, for example, a smartphone, a tablet personal computer, a laptop, and the like.
  • the devices are each installed with a Transaction handling application for a smart contract involving exchange of data or digital asset between a sender (or a seller) and a recipient (or a buyer), for instance, FIAT - Cryptocurrency exchange.
  • the transaction handling application may be configured to generate a key-pair using an Asymmetric Cryptography algorithm, for example, an RSA algorithm at a seller device and/or a buyer device.
  • the transaction handling application can be a mobile application, web-based application or a desktop application.
  • the escrow server 210 in the present example has access to one or more wallet manager databases.
  • the wallet manager database may be configured to store details of one or more smart contracts entered by users 202, 206 and 212 that use the services provided by the escrow server 210.
  • the wallet manager database may also be configured to store one or more encrypted keys for accessing data or asset stored in corresponding one or more data storages.
  • a data storage is created by the storage server 215 whenever there is an exchange scheduled between a buyer and seller.
  • the escrow server 210 that Alice 202, Bob 206 and Charlie 212 use as an escrow agent to facilitate their exchange of data or digital asset.
  • Alice 202 is a common seller in this F I AT -cryptocu rrency flow between the three users 202, 206 and 212.
  • Bob 206 and Charlie 212 are two buyers who are willing to buy Alice’s cryptocurrency (and in this example is ETH) with FIAT currency (and in this example is USD).
  • the escrow server 210 is configured to create an individual data storage to facilitate each exchange between a sender (or seller) i.e. Alice 202 and each of the respective recipients (or buyers) i.e. Bob 206 and Charlie 212.
  • Each data access key used to access the respective data storage is obtained from a storage server 215 and encrypted before storing in the one or more wallet manager databases.
  • Bob 206 lists an offer 31 1 on an exchange web page provided by the escrow server 210 that specifies the following:
  • This offer indicates that Bob 206 is willing to buy 1 unit of Ethereum (ETH) at an exchange rate of 1 ETH: USD1 000, and he will pay the seller via DBS Bank Transfer.
  • the seller 202, the buyer 206 or the buyer 212 may also provide an offer to sell or buy that is only visible to a predetermined seller or a predetermined buyer respectively, for example, through a chat conversation between a buyer (sender) and a buyer (recipient) using the Transaction handling application (not illustrated in Figures).
  • the exchange web page may be polled periodically or continuously to publish one or more available offers managed by the escrow server 210 to all users of the transaction handling application.
  • the one or more available offers may be displayed through a web page or through an interactive menu of the Transaction handling application.
  • the exchange web page may be configured to receive user inputs to bind each buyer and each seller to a smart contract (for initiating an exchange).
  • the transaction handling application installed in the Bob’s device 208 is configured to:
  • a first transaction identifier may be assigned to a transaction to be performed between Bob 206 and a seller.
  • the transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated first key-pair SK B and PK B is then stored locally at the seller device 204.
  • the escrow server 210 may be configured to link the generated public key (PK B ) of the first key-pair with the assigned first transaction identifier.
  • the private key SK B of the generated first key-pair may be encrypted with a user-defined password known only to Bob 206 for enhanced security.
  • Bob 206 may choose to back up the first generated key-pair SK B and PK B with cloud storage, but such option is likely to cause Bob 206 to be vulnerable to security threats.
  • Charlie 212 may also list a separate offer 321 on the exchange page provided by the escrow server 210 that specifies:
  • the offer 321 can be listed by Charlie 212 at about the same time as the offer 31 1 is being listed by Bob 206 or at a different instance, which can be before or after the offer 31 1 is being listed by Bob 206.
  • the offer listed by Charlie 212 may be different from the offer listed by Bob 206. For instance, Charlie may only be willing to buy 1 unit of Ethereum at an exchange rate of 1 ETH: USD 980.
  • the transaction handling application installed in the Charlie’s device 214 is configured to:
  • a second transaction identifier may be assigned to a transaction to be performed between Charlie 212 and one seller (in this example, the seller is Alice 202).
  • the transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated second key-pair SK C and PK C is then stored locally at the device 214.
  • the escrow server 210 may be configured to link the public key (PK C ) of the generated second key-pair with the second transaction identifier.
  • the private key SK C of the generated second key-pair may be encrypted with a user-defined password known only to Charlie 212 for enhanced security.
  • Charlie 212 may choose to back up the second generated key-pair SK C and PK C with cloud storage. - Send an instruction 327 to the escrow server 210 to associate the public key PK C of the generated second key-pair SK C and PK C with the offer 321 listed by Charlie 212. It should be appreciated that the private key SK C of the generated second key-pair SK C and PK C is stored locally on Charlie’s device 214 and never shared to the escrow server 210.
  • Alice 202 also lists an offer to sell 2 ETH on the exchange page provided by the escrow server 210 by specifying:
  • the transaction handling application installed in the Alice’s device 204 is configured to:
  • a third key-pair (SK A and PK A ) at Alice’s device 204 for Alice’s offer using an Asymmetric Cryptography algorithm, such as the RSA encryption algorithm or Elliptic-curve cryptography.
  • the transaction handling application may call APIs to generate a SSH key pair locally.
  • the generated third key-pair SK A and PK A is then stored locally at the device 204.
  • the private key SK A of the generated third key-pair may be encrypted with a user-defined password known only to Alice 202 for enhanced security.
  • Alice 202 may choose to back up the third generated key-pair SK A and PK A with cloud storage.
  • the escrow server 210 may be configured to prompt the user to select whether the escrow server 210 is tasked to pair suitable parties (seller and buyer) for the offer automatically.
  • suitable parties such as, for example, Alice 202, Bob 206 and Charlie 212
  • the escrow server 210 has arranged a first exchange transaction between Alice 202 and Bob 206, and a second exchange transaction between Alice 202 and Charlie 212.
  • any buyer who browses the exchange page provided by the Transaction handing application can transact with Alice 202. For instance, a buyer can click on a button“TO BUY” that is provided proximate to the Alice’s listed offer.
  • Alice 202 did not list her offer on the exchange page she can also browse the exchange page provided by the Transaction handling application to select a buyer that she wishes to perform an exchange with. For instance, Alice 202 may click on a button“TO SELL” that is provided proximate to buyer’s listed offer. Other actions available for selection may be viewing the details of the offer, cancelling an agreed exchange (after Alice accepts the offer), and the like. This means that Alice 202 has the option to select her buyers, and the escrow server 210 is configured to facilitate such exchange.
  • Alice 202 can browse the exchange page and click“SELL” button (or“EXCHANGE”) on Bob's offer and/or Charlie's offer. In this arrangement, Alice 202 has to determine an appropriate party or a list of parties to complete a data transfer request (e.g. offer 321 ) she requires. This would cost Alice 202 time for searching suitable sellers as she has to determine whether the data to be transferred between her device and another device is unable to complete a data transfer request made by Alice 202 manually.
  • “SELL” button or“EXCHANGE”
  • Alice 202 has to determine an appropriate party or a list of parties to complete a data transfer request (e.g. offer 321 ) she requires. This would cost Alice 202 time for searching suitable sellers as she has to determine whether the data to be transferred between her device and another device is unable to complete a data transfer request made by Alice 202 manually.
  • Alice 202 can list an order (e.g. offer 321 ) for the escrow server 210 to complete a data transfer request for her.
  • the escrow server 210 is configured to determine whether the data to be transferred between a first device (e.g. Alice’s device 204) and a second device (e.g. Bob's device 208) is able to complete the data transfer request (e.g. offer 321 ) made by the first device. If the escrow server 210 determines that the data to be transferred between the first device and the second device is unable to complete the data transfer request, the escrow server 210 is configured to schedule transfer of data between a third device (e.g.
  • the escrow server 210 is configured to automatically link Alice’s order with Bob’s offer and Charlie's offer. Such arrangement provides a better user experience.
  • the escrow server 210 is configured to determine the following within a predetermined time duration:
  • the escrow server 210 is configured to arrange three-party exchanges between Alice 202, Bob 206 and Charlie 212.
  • the escrow server 210 is configured to subsequently associate Alice 202 as the seller associated with the first transaction identifier and the second transaction identifier.
  • an offer can be initiated by any of the users: Alice 202, Bob 206 and Charlie 212.
  • the escrow server 210 may be configured to determine if there is a single user that matches the listed offer. For instance, in the present example illustrated by Figure 3A, if there is a user who can buy 2 ETH from Alice 202 (i.e. in a single transaction), the escrow server 210 may be configured to prioritize such exchange between Alice 202 and a buyer who is willing to buy 2 ETH. In another example that there is another user who can sell 1 ETH to Bob 206 (i.e.
  • the escrow server may be configured to arrange an exchange between Bob 206 and a seller who has 1 ETH for exchange.
  • the escrow server 210 may be configured to perform the offer listed by the user by managing a plurality of exchanges (according to the example illustrated by Figure 2A to 2C and the example illustrated by Figures 3A to 3C).
  • the escrow server 210 may be arranged to perform the exchange between Alice 202 and Bob 206 first before finding the next suitable buyer (i.e. Charlie 212). It should be appreciated that escrow server 210 may determine Charlie 212 as a suitable buyer before determining Bob 206 as a suitable buyer. In such an arrangement, the escrow server 210 is configured to determine a balance amount of a listed offer and update the wallet manager database in a manner so as to u date a desired amount of data or digital asset in the listed offer to the balance amount.
  • the escrow server 210 may be configured to check if a user lists his offer earlier than another user suitable to perform the exchange. As an example, if both Bob 206 and Charlie 212 list an offer to“BUY 2 ETH”, and if the server 210 determines that Charlie 212 posted the offer earlier than Bob 206, the server 210 is configured to match or link Charlie 212 (instead of Bob 206) to Alice 202 who wants to“SELL 2 ETH”. This means that the escrow server 210 is configured to match a buyer to a seller and/or vice versa by way of a“first-in-first out” concept.
  • the escrow server 210 may be configured to determine a priority level between two users who are able to match the same condition of a listed offer. For instance, in order for the escrow server 210 to prioritize Bob 206 before Charlie 212, Bob 206 may pay a higher premium to the escrow server 210 than Charlie 212 or Bob 206 may have more good reviews from other users or that Bob 206 has performed more exchanges with the escrow server 210.
  • the Transaction handling application installed in Alice’s device 204 is configured to send a command to the escrow server 210 to associate the listed offer 31 1 (and/or the first transaction identifier) with the details of Alice 202 and to update the status of the listed offer 311 accordingly.
  • a command may also be sent from the transaction handing application installed in Bob’s device 208 to the escrow server 210 to associate Alice’s offer with the details of Bob 206. For instance, if a listed offer is accepted, the escrow server 210 may be configured to modify permissions and/or the details of an offer.
  • an offer may be disabled temporarily and changed after negotiation between users who may or may not be the buyer or the seller performing the exchange.
  • the escrow server 210 may be configured to list a new offer on the remaining digital asset or data for acceptance by other users.
  • the escrow server 210 is configured to send a request 339 to the storage server 215 to create a disposable data storage (or escrow account) E B for storing data or digital asset to be transferred from Alice 202 to Bob 206 at a step (6a).
  • the storage server 215 Upon receiving the request 339, the storage server 215 is configured to:
  • a public address of the data storage E B can be derived from the public key PK T1 and sent to the escrow server 210 as identification information of the data storage E B, For instance, keccak-256 hashing algorithm may be performed to the uncompressed public key PK Ti (without a prefix) to obtain a resultant string. The rightmost 160-bit (or 40 characters) of the resultant string is then retrieved as the public address of the data storage E B .
  • the escrow server 210 stores the first data access key SK Ti temporarily on Random Access Memory (RAM) allocated for the corresponding first transaction identifier.
  • the escrow server 110 is also configured to:
  • E PKA (SK t1 ) indicates encryption of the first data access key SK T1 using the public key PK A to obtain the first encrypted key A K B .
  • E PKg (SK T1 ) indicates encryption of the first data access key SK T1 using the public key PK B to obtain the second encrypted key BK.
  • the escrow server 210 is configured to e ploy zero-filing technique to effectively and completely wipe the data access key SK T1 from the allocated RAM. In another example, the escrow server 210 is configured to replace memory space in a memory allocated to store the data access key SK T1 with data not related to the data access key SK Ti .
  • the specific addresses of the RAM used to store the data access key SK T1 may be stored by the escrow server 210 to facilitate post processing Similar to the aforementioned discussion on how the escrow server 210 facilitates an exchange between Alice 202 and Bob 206, the escrow server 210 is also configured to send a request 349 to the storage server 215 to create a disposable data storage (or escrow account) E c for storing data or digital asset to be transferred from Alice 202 (i.e. from Alice’s device 204) to Charlie 212 (i.e. Charlie’s device 214) at a step (8a).
  • a disposable data storage (or escrow account) E c for storing data or digital asset to be transferred from Alice 202 (i.e. from Alice’s device 204) to Charlie 212 (i.e. Charlie’s device 214) at a step (8a).
  • the storage server 215 Upon receiving the request 349, the storage server 215 is configured to:
  • a public address of the data storage Ec can be derived from the public key PK T2 and sent to the escrow server 210 as identification information of the data storage E c .
  • keccak-256 hashing algorithm may be performed to the uncompressed public key PK T2 (without a prefix) to obtain a resultant string.
  • the rightmost 160-bit (or 40 characters) of the resultant string is then retrieved as the public address of the data storage E c .
  • the escrow server 210 is configured to obtain the second data access key SK T2 from the storage server E c at a step 8b and store it temporarily on Random Access Memory (RAM) allocated for the corresponding second transaction identifier. Subsequently, the escrow server 1 10 is configured to:
  • E PKA indicates encryption of the second data access key SK T2 using the public key PK A to obtain the third encrypted key A K c .
  • E PKC indicates encryption of the second data access key SK T2 using the public key PK C to obtain the third encrypted key CK.
  • the escrow server 210 is configured to employ zero-filing technique to effectively and completely wipe the second data access key SK T2 from the allocated RAM.
  • the escrow server 210 is configured to replace memory space in a memory allocated to store the data access key SK T2 with data not related to the second data access key SK T2 .
  • the specific addresses of the RAM used to store the second data access key SK T2 may be stored by the escrow server 210 to facilitate post processing.
  • the escrow server 210 is configured to:
  • AK B and BK are associated with the first transaction relating to an exchange of 1 ETH between Alice 202 and Bob 206;
  • the escrow server 210 may be configured further to perform a check on the one or more wallet manager databases to ensure that there is indeed no presence of the original data access keys SK J I and/or SKT 2, It should be appreciated that the first data access key SK T1 can be subsequently retrieved by decrypting the first encrypted key AK B with the corresponding private key SK A of Alice 202 or decrypting the second encrypted key BK with the corresponding private key SK B of Bob 206.
  • the second data access key SK T2 can also be subsequently retrieved by decrypting the third encrypted key AK C with the corresponding private key SK A of Alice 202 or decrypting the fourth encrypted key CK with the corresponding private key SK C of Charlie 212.
  • the encrypted data access keys AK b , BK, AK C , and/or CK may be duplicated in one or more databases accessible by the escrow server 210.
  • the escrow server 210 is configured to send a notification indicating the details of the data storage E B to Alice 202 for her to deposit the 1 ETH she is transferring to Bob 206 at step (10).
  • the data storage E B can be identified by identification information of the data storage E B provided to Alice 202.
  • the escrow server 210 is configured to send a notification indicating the details of the data storage E c to Alice 202 for her to deposit the 1 ETH she is transferring to Charlie 212 at a step (12).
  • the data storage E c can be identified by identification information of the data storage Ec provided to Alice 202.
  • two different ETH Address wallets are sent to Alice 202 for respective data transfers to Bob 206 and Charlie 212.
  • the data transfer from Alice 202 to the data storage 155 and the data storage 255 can take place about the same time or at two distinct time frames.
  • the escrow server 210 may be configured to request notification from the storage server 215 when data or digital asset has been deposited into the data storage E B and/or data storage E c, (in this example, escrow account)
  • the escrow server 210 can determine, based on such notification, whether the amount of data or digital asset (in this example, cryptocurrency) deposited in the data storage E B and/or E c is correct.
  • the escrow server 210 may be configured to communicate with the storage server E B and/or E c to retrieve transactions performed in connection to the data storages E B and/or E c (i.e. transactions that involve data into and/or out of the data storages E B and/or E c ).
  • the retrieved transaction history can be used to determine whether Alice 202 has deposited into the respective data storages E B and/or E c matches the agreed data to be transferred to Bob 206 or Charlie 212.
  • the escrow server 210 notifies the respective seller (i.e. Alice 202) of the discrepancy and request her to deposit more cryptocurrency into the escrow account E B or E c respectively to match the amount she agreed to change with Bob 206 or Charlie 212. This means that if the amount deposited in the escrow account does not match the amount to be transferred, the escrow server will not proceed with the exchange
  • the escrow server 210 may be configured to send a corresponding encrypted key AK B or AK C to Alice 202 to obtain the respective data access key SKn or SK T2 to withdraw the deposited amount in the respective data storage 155 or 255.
  • the escrow server 210 may be configured to send a notification to Alice 202, wherein the notification includes identification information of another data storage for storing the data to be transferred to Bob 206 (or Charlie 212).
  • the escrow server 210 is configured to request for a new data storage to be created by the storage server 215 in order for Alice to deposit the correct amount she agrees to exchange to perform the exchange of data between Alice 202 and Bob 206 (or Charlie 212).
  • a new data storage has to be used to ensure that Alice 202, Bob 206 and/or Charlie 212 cannot access the respective data storage before an exchange is completed.
  • Such arrangement is desirable because the correct amount is being deposited in the data storage before the buyer transfers an agreed consideration (in this example,
  • the escrow server 210 is configured to send Bob 206 at a step (11 ) a notification indicating data transfer from Alice’s device 204 into the data storage E B and a request for Bob 206 to transfer an agreed consideration to Alice 202.
  • This notification that is sent to Bob s device 208 can be in the form of push, SMS, email or the like.
  • Bob 206 Upon receipt of such notification, Bob 206 sends the agreed consideration (i.e. USD 1000) to Alice 202 at step (14) using the payment details provided by Alice 202.
  • Alice 202 When Alice 202 receives the agreed consideration from Bob 206, she is required to send a confirmation request 360 at a step (15) using the T ransaction handling application to the escrow server 210 so that the escrow server 210 is notified of the payment received by the buyer 202.
  • a seller’s notification on correct payment received from the buyer is an example of notification received by the escrow server 210 to send the corresponding encrypted key to buyer’s device.
  • Alice 202 can make use of the Transaction handling application, specify the transaction (exchange) in question and click on a 'Money Received' button to notify the escrow server 210 that she received the correct consideration from Bob 206.
  • the escrow server 210 is configured to release the second encrypted key BK to Bob 206 at a step (16) through a command 362 to Bob’s device 208.
  • Bob 206 can then use his private key SK B that is stored locally at his device 208 to decrypt the received second encrypted key, BK, at a step (17) to obtain the first data access key, SK T1 , to access the ETH fund stored in the data storage 155 at a step (18).
  • D SKB (BK) indicates decryption of the second encrypted key BK using the private key SK B to obtain the first data access key SK Ti .
  • the obtained first data access key SK T1 (after successful decryption) is then used to access the data or digital asset (in this example, 1 ETH) stored in the data storage E B that Alice 202 has transferred at the step (10).
  • the data storage E e can be identified by identification information of the data storage 155 provided to Alice 202.
  • 1 ETH can subsequently be transferred to any account or device designated by Bob 206 or downloaded to his device 208 by inputting a dedicated command.
  • the escrow server 210 sends Charlie 212 at a step (13) a notification indicating data transfer from Alice’s device 204 into the data storage E c and a request for Charlie 212 to transfer an agreed consideration (i.e. USD 1000) to Alice 202.
  • This notification that is sent to Charlie’s device 214 can be in the form of push, SMS, email or the like.
  • Charlie 212 sends the agreed consideration to Alice 202 at a step (19) using the payment details provided by Alice 202.
  • Alice 202 When Alice 202 receives the agreed consideration from Charlie 212, she is required to send a confirmation request 364 at a step (20) using the Transaction Handling application to the escrow server 210 so that the escrow server 210 is notified of the payment received by the buyer.
  • a seller’s notification on correct payment received from the buyer is an example of notification received by the escrow server 210 to send the corresponding encrypted key to buyer’s device.
  • Alice 202 can make use of the Transaction handling application to specify the transaction in question and click on a 'Money Received' button to notify the escrow server 210 that she has received the correct consideration from Charlie 212.
  • the escrow server 210 is configured to send the fourth encrypted key CK to Charlie 212 at a step (21 ) through a command 366 to the Charlie’s device 214.
  • Charlie 212 can then use his private key SK C that is stored locally at his device 214 to decrypt the received fourth encrypted key, CK, at a step (22) to obtain the second data access key, SK T 2, to access the ETH fund stored in the data storage E c .
  • D SK (CK) indicates decryption of the fourth encrypted key CK using the private key SK C to obtain the second data access key SK T 2-
  • the obtained second data access key SK T2 is then used at a step (23) to access the data or digital asset (in this example, 1 ETH) stored in the data storage 255 that Alice 202 has transferred.
  • the data storage E c can be identified by identification information of the data storage E c provided to Charlie 212.
  • Charlie’s 1 ETH can subsequently be transferred to any account or device designated by Charlie 212 or downloaded to his device 214 at a step (23) by inputting a dedicated command.
  • the release of the second encrypted key BK to Bob 206 is performed before the release of the fourth encrypted key CK to Charlie 212
  • the release of the fourth encrypted key CK to Charlie 212 can be done at substantially the same time or before the release of the second encrypted key BK to Bob 206.
  • the progress of a first transaction is independent of the progress of a second transaction in a three-party exchange.
  • a dispute resolution process as discussed in Figure 1 C may be initiated (i.e. no release of encrypted key to any parties until the dispute is resolved).
  • the exchange between Alice 202 and Charlie 212 will continue without consideration of the progress of the exchange transaction between Alice 202 and Bob 206.
  • Charlie 212 is able to receive the fourth encrypted key CK and decrypt it with Charlie’s own private key SK C to obtain the second data access key SK T 2 used to access the data or digital asset stored in the data storage E c .
  • cross-chain cryptocurrency exchanges are exchanges of tokens or coins that belong to two different networks (for example, Bitcoin and Ethereum).
  • Same-chain cryptocurrency are exchanges of user defined tokens or user defined coins that belong to a common blockchain-based network.
  • the escrow server is configured to request for the storage server to create two data storages: a first data storage for storing Bob’s ETH, and a second data storage for storing Alice's BTC.
  • the first data storage may be created by a first data storage server
  • the second data storage is created by a second data storage server.
  • the escrow server has to create their escrow accounts on both the Ethereum network and the Bitcoin Network. Details relating to how key-pairs for each device and/or each data storage are generated and used for controlling data access have been discussed earlier and are omitted for the present example. The manner of generation and data access control apply.
  • the secret key of a first data access key-pair generated for the first data storage is encrypted with the public key of Bob's device to obtain a first encrypted key (BK1 ).
  • the secret key of the generated first data access key-pair is then encrypted again with the public key of Alice’s device to obtain a second encrypted key (AK1 ).
  • a secret key of a second data access key-pair generated for second data storage is encrypted with the public key of Bob's device to obtain a third encrypted key (BK2).
  • the secret key of the generated second data access key-pair is then encrypted again with the public key of Alice’s device to obtain a fourth encrypted key (AK2).
  • the escrow server when there are no dispute between Alice and Bob, the escrow server is configured to:
  • a dispute resolution process as discussed in the description for Figure 1 C may be initiated. For instance, if Alice has not deposited her BTC into the second data storage within a predetermined time for the exchange to be performed, the escrow server is configured to send the first encrypted key BK1 to Bob for him to retrieve the ETH he has deposited in the first data storage.
  • Company A As another example in the application of same-chain cryptocurrency exchange, there may be two companies, Company A and Company B, who would like to issue their own tokens on a blockchain network (for instance, Ethereum network, EOS network, or NEO network) that allows for a private permissioned blockchain to digitalize a reward system (i.e. a loyalty program).
  • a blockchain network for instance, Ethereum network, EOS network, or NEO network
  • Company A may begin its digitalised reward system by writing an Ethereum Smart Contract and subsequently deploying the Ethereum Smart Contract on the Ethereum network to issue its own tokens under ERC-20 Token Standard, or ERC-721 Token Standard or the like. These tokens issued by Company A may be labelled as ATK tokens. Note that_ATK tokens are user-defined tokens and are different from ETH token, which is the native token of the Ethereum network. Likewise, Company B may also implement an independent Ethereum Smart Contract and deploys the Ethereum Smart Contract on the Ethereum network to issue its own ERC-20 tokens, and labelled them as the BTK tokens.
  • company A and the company B possess their own digital currencies, i.e. the ATK tokens and the BTK tokens respectively, these companies are able to reward to their loyal customers with their own tokens. For instance, customers of the company A and/or customers of the company B can accumulate the ATK tokens and the BTK tokens respectively, when buying items or using the services offered by the respective companies.
  • the ATK tokens and/or the BTK tokens can be redeemed for physical rewards such as merchandise, discounts, and coupons.
  • Steve may have accumulated a substantial amount of ATK tokens, which can be used to change for merchandise in Company A.
  • Steve may prefer a merchandise form Company B, and thus he can exchange his ATK token for BTK tokens through the escrow server.
  • Such arrangement may be desirable to consumers and/or business owners because consumers can continue to frequent Company A or Company B, while providing the flexibility to use ATK tokens or BTK tokens for merchandise in the other Company B or Company A.
  • Company B can acquire Steve as a new customer because of the flexibility to exchange ATK for BTK.
  • ERC-20 token can be applied to various business schemes of different sectors, for example, an airline’s mileage plan where passengers will receive ECR-20 tokens as mileage points for upgrades to business-class or exchange to other available ERC-20 tokens that a passenger desires.
  • the escrow server may be configured to facilitate the exchange of such user-defined tokens, for example, between ATK tokens and BTK tokens.
  • two data storages are created - a first data storage for storing ATK tokens and a second data storage for storing BTK tokens.
  • the secret key of a first data access key-pair generated for the first data storage is encrypted with the public key of Steve’s device to obtain a first encrypted key (AK3).
  • the secret key of the generated first data access key-pair is then encrypted again with the public key of Bob’s device to obtain a second encrypted key (BK3).
  • a secret key of a second data access key-pair generated for second data storage is encrypted with the public key of Steve’s device to obtain a third encrypted key (AK4).
  • the secret key of the generated second data access key-pair is then encrypted again with the public key of Bob’s device to obtain a fourth encrypted key (BK4).
  • the escrow server is configured to send the second encrypted key BK3 to Bob for him to withdraw the ATK tokens from the first data storage; and send the third encrypted key AK4 to Steve for him to withdraw the BTK tokens from the second data storage.
  • a dispute resolution process as discussed in Figure 1 C may be initiated. For instance, if Bob has not deposited his BTK tokens into the second data storage within a predetermined time for the exchange to be performed, the escrow server is configured to send the first encrypted key AK3 to Steve for him to retrieve the ATK tokens he has deposited in the first data storage.
  • an individual escrow account is created for each transaction or each exchange. This arrangement isolates one transaction (or exchange) from another. In such arrangement, even if one escrow account is compromised, data loss can be mitigated.
  • the data access key that is created by the storage server is deleted permanently from memory after encryption is performed. This means that the encrypted data access key can only be decrypted by a rightful owner.
  • the encrypted data access key may be duplicated in one or more databases accessible by the escrow server. Note that the sending of an encrypted key to a party of the transaction is determined by the escrow server. Such encryption arrangement allows secured data transfer between two parties and safeguard the interest of the two parties.
  • the user devices 104 and 108 in Figures 1 A and 1 B as well as the user devices 204, 208, 214 in Figures 2A to 2C, 3A to 3C may be a computing or mobile device 400 schematically shown in Figure 4.
  • the system architecture of the second computing or mobile device 434 can be the same as that of the computing device 400 and vice versa and not limited to what is described herein.
  • the escrow servers (such as server 1 10 in Figures 1A and 1 B, server 210 in Figures 2A to 2C and Figures 3A to 3C), storage servers (such as server 1 15 in Figures 1A and 1 B, server 215 in Figures 2A to 2C and Figures 3A to 3C) and/or other servers (such as third party servers that creates key-pairs on behalf of escrow server at the user devices) as disclosed herein may also be a server apparatus 450 shown in Figure 4. There may be provided software, such as one or more computer programs being executed within the server apparatus 450 to carry out the operations of the respective servers as well.
  • the server apparatus 450 may be a single server as illustrated schematically in Figure 4, or have functionality performed by the server apparatus 450 distributed across multiple server components.
  • the server apparatus 450 may comprise a number of individual components including, but not limited to, microprocessor 456, a memory 458 (e.g. a volatile memory such as a Random Access Memory (RAM)) for the loading of executable instructions 460, the executable instructions defining the functionality the server apparatus 450 carries out under control of the processor 456.
  • the server apparatus 450 also comprises a network module 452 allowing the server to communicate over the communications network 412 (for example the internet).
  • User interface 462 is provided for user interaction and may comprise, for example, conventional computing peripheral devices such as display monitors, computer keyboards and the like.
  • the server apparatus 450 may also comprises a database 454. It should also be appreciated that the database 454 may not be local to the server apparatus 450.
  • the database 454 may be a cloud database.
  • the computing device 400 can comprise a processing unit 402 for processing the one or more computer programs.
  • the processing unit 402 is connected to input/output devices such as a computer mouse 436, keyboard/keypad 404, a display 408, headphones or microphones 426, a video camera 440 and the like via Input/Output (I/O) interfaces 424.
  • the processing unit 402 may include a processor 418, a Random Access Memory (RAM) 420 and a Read Only Memory (ROM) 422.
  • the components of the processing unit 402 typically communicate via an interconnected bus 428 and in a manner known to the person skilled in the relevant art.
  • the processing unit 402 may be connected to the network 412, for instance, the Internet, via a suitable transceiver device 414 (i.e. a network interface) or a suitable wireless transceiver 432, to enable access to e.g. the Internet or other network systems such as a wired Local Area Network (LAN) or Wide Area Network (WAN).
  • the processing unit 402 of the computing device 400 may also be connected to one or more external wireless communication enabled electronic devices 434 or the server 450 through the respective communication links 480, 482, 484 via the suitable wireless transceiver device 432, e.g. a Wi-Fi transceiver, Bluetooth module, Mobile telecommunication transceiver suitable for Global System for Mobile Communication (GSM), 3G, 3.5G, 4G telecommunication systems, or the like.
  • GSM Global System for Mobile Communication
  • the second computing or mobile device 434 may be, for example, smart phones, tablet devices, and other handheld devices.
  • the one or more second computing or mobile device 434 may be able to communicate through other communications network, such as, wired network, mobile telecommunication networks, but these are omitted from Figure 4 for the sake of clarity.
  • the computing or mobile device 400 may have the system architecture of the second computing or mobile device 434.
  • the second computing or mobile device 434 may comprise a number of individual components including, but not limited to, microprocessor 476, a memory 448 (e.g. a volatile memory such as a RAM) for the loading of executable instructions 470, the executable instructions defining the functionality the second computing or mobile device 434 carries out under control of the processor 476.
  • the second computing or mobile device 434 also comprises a network module 472 allowing the second computing or mobile device 434 to communicate over the communications network 412.
  • User interface 492 provided for user interaction and control may be in the form of a touch panel display and presence of a keypad as is prevalent in many smart phone and other handheld devices.
  • the second computing or mobile device 434 may comprise a finger print scanner, iris scanner, camera used for face recognition and the like.
  • the second computing or mobile device 434 may comprise a card reader for insertion of an external storage card (e.g. a FIPS-140-2 certified MicroSD card).
  • the external storage card may be used to store at least one private key generated by a transaction handling application as discussed herein and installed at the second computing or mobile device 434.
  • the second computing or mobile device 434 may also comprise a database 474. It should also be appreciated that the database 474 may not be local to the second computing or mobile device 434.
  • the database 474 may be a cloud database.
  • the second computing or mobile device 434 may include a number of other Input/Output (I/O) interfaces as well but they may be for connection with headphones or microphones 494, Subscriber identity module (SIM) card 496, flash memory card 498, USB based device 499, and the like, which are more for mobile device usage.
  • the software and one or more computer programs may include, for example, an client application such as a banking application, a web application (e.g. Safari, Chrome) and a transaction handling application as discussed herein, and may further include one or more software applications for e.g. instant messaging platform, audio/video playback, internet accessibility, operating the computing or mobile device 400 (i.e.
  • the software and one or more computer programs may be supplied to the user of the computing or mobile device 400 or the second computing or mobile device 434 encoded on a data storage medium such as a CD-ROM, on a flash memory carrier or a Hard Disk Drive, and are to be read using a corresponding data storage medium drive of for instance, a data storage device 430 in Figure 4.
  • a data storage medium such as a CD-ROM, on a flash memory carrier or a Hard Disk Drive
  • Such application programs may also be downloaded from the network 412.
  • the application programs are read and controlled in its execution by the processor 418 or microprocessor 476.
  • Intermediate storage of program data may be accomplished using RAM 420 or 448.
  • the computer programs may be stored on any machine or computer readable medium that may be non-transitory in nature.
  • the computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer or mobile device.
  • the machine or computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the Wireless LAN (WLAN) system.
  • WLAN Wireless LAN
  • the computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus (e.g. 104, 108, 204, 208 and 214 in the respective Figures) that implements the steps of the computing methods in examples herein described.
  • examples of the present disclosure may have the following features.
  • a method for controlling data access comprising obtaining a data access key to gain access to a data storage for storing data to be transferred between a first device and a second device (e.g. S142 of Figure 1A, step 4b of Figure 2A, step 6b of Figure 3B ); storing the obtained data access key in a memory; obtaining a first public key associated with the first device (e.g. S126 of Figure 1A, step 2 of Figure 2A, step 5 of Figure 3A, if the first device is 104 or 204); obtaining a second public key associated with the second device (e.g.
  • step 12(b) of Figure 1A, step 5(b) of Figure 2A, step 7(b) of Figure 3B correspondingly wherein the data access key is accessible by decrypting the second encrypted key using a corresponding second private key of the second public key (e.g. step 17 of Figure 3C); and removing the data access key from the memory permanently (e.g. S144, step 12c of Figure 1A, step 5c of Figure 2A, step 7c of Figure 3B ).
  • the first device and/or second device can initiate a data transfer request and/or accept the data transfer request.
  • a device can be a device that transfers the data to be transferred into the data storage in one data transfer request and a device that obtains the data to be transferred from the data storage) in another data transfer request.
  • the first public key and the corresponding first private key may be created at the first device (S122 of Figure 1 A, step 2 of Figure 2A, step 5 of Figure 3A), and the second public key and the corresponding private key may be created at the second device (S132 of Figure 1 A, step 3 of Figure 2A, step 2 of Figure 3A).
  • the method may comprise receiving a notification (e.g. 157 of Figure 1A, 260 of Figure 2C) from the first device to enable sending of the second encrypted key to the second device (S154 of Figure 1A, step 13 of Figure 2C, step 15 of Figure 3C, if the first device is 108 in Figure 1A, 208 in Figure 2C, 204 in Figure 3C respectively); and sending the second encrypted key to the second device (S156 of Figure 1 A, step 14 of Figure 2C, step 16 of Figure 3C, if the first device is 104 in Figure 1A, 204 in Figure 2C, 208 in Figure 3C respectively).
  • a notification e.g. 157 of Figure 1A, 260 of Figure 2C
  • the data stored in the data storage may be in a form of cryptocurrency (e.g. ethereum, bitcoin, user-defined crypto-token and the like) and the data storage is in a form of an escrow account, and the method may further comprise receiving the notification from the first device to enable sending of the second encrypted key to the second device after a confirmation of electronic transfer of a predetermined amount of FIAT currency (e.g. USD, EUR, SGD) is received at the first device.
  • a predetermined amount of FIAT currency e.g. USD, EUR, SGD
  • This method may co prise determining amount of cryptocurrency to be transferred from the first device to the second device; determining whether the cryptocurrency stored in the escrow account by the first device is more than the determined cryptocurrency; and if the cryptocurrency stored in the data storage is more than the determined cryptocurrency, the method may comprise sending to the first device a notification including identification information of another escrow account for storing the amount of cryptocurrency to be transferred from the first device to the second device, and sending the first encrypted key to the first device to obtain the data access key for retrieving all the cryptocurrency stored in the escrow account.
  • this method may comprise sending to the first device a notification to inform the first device to top up the cryptocurrency stored in the escrow account to match the determined cryptocurrency.
  • the method may comprise sending identification information of the data storage to the first device so that the first device is able to store into the data storage the data to be transferred to the second device (e.g. S146 of Figure 1A).
  • the method may comprise obtaining identification information of the data storage from a public key (PK T of Figure 1 A) of the data storage.
  • the first private key is stored only at the first device and the second private key is stored only at the second device (e.g.S124, S134 of Figure 1A, steps 2 and 3 of Figure 2A, steps 2 and 5 of Figure 3A).
  • the step of removing the data access key from the memory permanently may comprise replacing memory space in the memory allocated to store the data access key with data not related to the data access key.
  • the step of removing the data access key from the memory permanently is performed by zero-filing technique.
  • the method may comprise storing duplicate copies of the first encrypted key and/or the second encrypted key in a plurality of databases.
  • the method may comprise sending the first encrypted key or the second encrypted key from one of the plurality of databases that is geographically closer to the respective first device or the second device.
  • the method may comprise determining data to be transferred from the first device to the second device; determining whether the data stored in the data storage by the first device matches the determined data; and if the data stored in the data storage does not match the determined data, the method may comprise sending a notification to the first device to inform that the data stored in the data storage cannot be transferred to the second device.
  • the method may comprise receiving a first notification from the first device indicating not to send the second encrypted key to the second device (e.g. S172 of Figure 1 C, if the first device is 108); sending a second notification to the second device (e.g. 104 correspondingly) to notify about the first notification; obtaining from the second device information to enable sending the second encrypted key to the second device (e.g. S172 of Figure 1 C); and determining from the information obtained from the second device whether to send the second encrypted key to the second device (e.g. S182, S184 of Figure 1 C).
  • a first notification from the first device indicating not to send the second encrypted key to the second device (e.g. S172 of Figure 1 C, if the first device is 108); sending a second notification to the second device (e.g. 104 correspondingly) to notify about the first notification; obtaining from the second device information to enable sending the second encrypted key to the second device (e.g. S172 of Figure 1 C); and determining from the information obtained from the second device whether
  • the method may comprise receiving a first notification from the first device indicating not to send the second encrypted key to the second device (e.g. S172 of Figure 1 C, if the first device is 108); sending a second notification to the second device (e.g. 104 correspondingly) to notify about the first notification; obtaining from the second device information to enable sending the second encrypted key to the second device ; and receiving a user instruction to send the second encrypted key to the second device after obtaining the information to enable sending the second encrypted key from the second device.
  • a first notification from the first device indicating not to send the second encrypted key to the second device (e.g. S172 of Figure 1 C, if the first device is 108); sending a second notification to the second device (e.g. 104 correspondingly) to notify about the first notification; obtaining from the second device information to enable sending the second encrypted key to the second device ; and receiving a user instruction to send the second encrypted key to the second device after obtaining the information to enable sending the second encrypted key from the second device.
  • the method may comprise sending the first encrypted key to the first device if the information to enable sending the second encrypted key to the second device cannot be obtained from the second device within a predetermined time (S186 of Figure 1 C, if first device is 108).
  • the method may comprise verifying with a trusted party authenticity of the information obtained from the second device before sending the second encrypted key to the second device.
  • the trusted party may be a bank or a payment agent that performs the electronic transfer of the FIAT currency.
  • the method may comprise determining whether the data to be transferred between the first device and the second device is unable to complete a data transfer request made by the first device and if the data is determined to be unable to complete the data transfer request, the method may further comprise scheduling transfer of data between a third device and the first device to enable completion of the data transfer request (e.g. step 7a of Figure 2B, step 8a of Figure 3B); obtaining a second data access key (e.g. SK ⁇ in Figures 2B and 3B) to gain access to a second data storage for storing data to be transferred between the first device and the third device (e.g.
  • a second data access key e.g. SK ⁇ in Figures 2B and 3B
  • step 8b of Figure 2B, step 9b of Figure 3B wherein the second data access key is accessible by decrypting the fourth encrypted key using a corresponding third private key (e.g. SK C of Figure 3A) of the third public key(e.g. step 22 of Figure 3C); and removing the second data access key from the memory permanently (e.g. step 8c of Figure 2B, step 9c of Figure 3B).
  • a corresponding third private key e.g. SK C of Figure 3A
  • the third public key e.g. step 22 of Figure 3C
  • the step of removing the second data access key from the memory permanently includes replacing memory space allocated in the memory to store the second data access key with data not related to the second data access key.
  • the step of removing the data access key from the memory permanently is performed by zero-filing technique.
  • the method may comprise storing duplicate copies of the third encrypted key and/or the fourth encrypted key in a plurality of databases.
  • the method may comprise receiving a notification indicating that the data to be transferred between the first device and the second device that is stored in the data storage has been retrieved; and removing the first encrypted key and the second encrypted key permanently from the plurality of databases upon receipt of the notification indicating that the data stored in the data storage has been retrieved.
  • the method may comprise sending a request to a server for generating the data access key to send a notification that indicates the retrieval of the data stored in the data storage,
  • an apparatus for controlling data access, the apparatus comprising a memory (e.g. 458 of Figure 4); and a processor (e.g. 456 of Figure 4) configured to execute instructions (e.g. 460 of Figure 4) in the memory to operate the apparatus to obtain a data access key (e.g. SK T of Figure 1A, SK T1 of Figures 2A and 3B) to gain access to a data storage (e.g. 155 of Figures 1 B and 2B, E B of Figures 3B and 3C) for storing data to be transferred between a first device (e.g.
  • a data access key e.g. SK T of Figure 1A, SK T1 of Figures 2A and 3B
  • a data storage e.g. 155 of Figures 1 B and 2B, E B of Figures 3B and 3C
  • PK A if the first device is 104 or 204 or PK B , if the first device is 108 or 208
  • a corresponding second private key e.g. SK B or SK A , if the second public key is PK B or PK A respectively
  • the first device and/or second device can initiate a data transfer request and/or accept the data transfer request.
  • a device can be a seller’s device (i.e. transferring the data to be transferred into the data storage) in one data transfer request and a buyer’s device (i.e. obtaining the data to be transferred from the data storage) in another data transfer request.
  • the first public key and the corresponding first private key may be created at the first device, and the second public key and the corresponding private key may be created at the second device.
  • the apparatus may be configured to receive a notification (e.g. 157 of Figure 1A, 260 of Figure 2C, 360 of Figure 3C) from the first device (e.g. 108 of Figures 1A and 1 B, 208 of Figures 2A to 2C, 204 of Figures 3A to 3C correspondingly) to enable sending of the second encrypted key (e.g. A K of Figure 1A. AK B of Figure 2C, BK of Figure 3C) to the second device (e.g. 104 of Figure 1A and 1 B, 204 of Figures 2A to 2C, 208 of Figures 3A to 3C correspondingly); and to send the second encrypted key to the second device.
  • a notification e.g. 157 of Figure 1A, 260 of Figure 2C, 360 of Figure 3C
  • the first device e.g. 108 of Figures 1A and 1 B, 208 of Figures 2A to 2C, 204 of Figures 3A to 3C correspondingly
  • the second encrypted key e.
  • the data stored in the data storage may be in a form of cryptocurrency (e.g. ethereum, bitcoin, user-defined crypto-token), and the apparatus may be configured to receive the notification from the first device to enable sending of the second encrypted key to the second device after a confirmation of electronic transfer of a predetermined amount of FIAT currency (e.g. USD, EUR) is received at the first device.
  • cryptocurrency e.g. ethereum, bitcoin, user-defined crypto-token
  • FIAT currency e.g. USD, EUR
  • the apparatus may be configured to determine amount of cryptocurrency to be transferred from the first device to the second device and to determine whether the cryptocurrency stored in the escrow account by the first device is more than the determined cryptocurrency. If the cryptocurrency stored in the data storage is more than the determined cryptocurrency, the apparatus may be configured to send to the first device a notification including identification information of another escrow account for storing the amount of cryptocurrency to be transferred from the first device to the second device, and to send the first encrypted key to the first device to obtain the data access key for retrieving all the cryptocurrency stored in the escrow account. If the cryptocurrency stored in the escrow account by the first device is determined to be less than the determined cryptocurrency, the apparatus may be configured to send to the first device a notification to inform the first device to top up the cryptocurrency stored in the escrow account to match the determined cryptocurrency.
  • the apparatus may be configured to send identification information (e.g. 147 of Figure 1 A) of the data storage to the first device so that the first device is able to store into the data storage the data to be transferred to the second device.
  • the identification information of the data storage (155 of Figure 1 B, 155 or E B of Figure 2A) may be obtained based on a public key (e.g. PK T of Figure 1A, PK T1 of Figure 2A correspondingly) of the data storage.
  • the first private key may be stored only at the first device and the second private key may be stored only at the second device.
  • the data access key may be removed from the memory permanently by replacing memory space in the memory allocated to store the data access key with data not related to the data access key.
  • the data access key may be removed from the memory permanently by performing zero-filing technique.
  • Duplicate copies of the first encrypted key and/or the second encrypted key may be stored in a plurality of databases.
  • the first encrypted key or the second encrypted key may be sent from one of the plurality of databases that is geographically closer to the first device or the second device.
  • the apparatus may be configured to determine data to be transferred from the first device to the second device; determine whether the data stored in the data storage by the first device matches the determined data to be transferred between the first device and the second device; and if the data stored in the data storage does not match the determined data, send a notification to the first device to inform that the data stored in the data storage cannot be transferred to the second device
  • the apparatus may be configured to receive a first notification from the first device indicating not to send the second encrypted key to the second device; send a second notification to the second device to notify about the first notification; obtain from the second device information to enable sending of the second encrypted key to the second device; and determine from the information obtained from the second device whether to send the second encrypted key to the second device.
  • the apparatus may be configured to receive a first notification from the first device indicating not to send the second encrypted key to the second device; send a second notification to the second device to notify about the first notification; obtain from the second device information to enable sending of the second encrypted key to the second device; and receive a user instruction to send the second encrypted key to the second device after obtaining the information to enable sending the second encrypted key from the second device.
  • the apparatus may be configured to send the first encrypted key (e.g. BK of Figures 1A and 2A) to the first device (e.g. 108 of Figures 1A and 1 B, 208 of Figures 2A to 2C correspondingly) if the information to enable sending the second encrypted key (e.g. A K of Figure 1A. AK B of Figure 2C) to the second device (e.g. 104 of Figure 1A and 1 B, 204 of Figures 2A to 2C correspondingly) cannot be obtained from the second device within a predetermined time.
  • the first encrypted key e.g. BK of Figures 1A and 2A
  • the first device e.g. 108 of Figures 1A and 1 B, 208 of Figures 2A to 2C correspondingly
  • the second encrypted key e.g. A K of Figure 1A. AK B of Figure 2C
  • the apparatus may be configured to verify with a trusted party the authenticity of information obtained from the second device before sending the second encrypted key to the second device.
  • the trusted party may be a bank or a payment agent that performs the electronic transfer of the FIAT currency.
  • the apparatus may be configured to: determine whether the data to be transferred between the first device (e.g. 204 of Figures 2A to 2C, 3A to 3C) and the second device (e.g. 208 of Figures 2A to 2C, 3A to 3C, if the first device is 204) is unable to co plete a data transfer request made by the first device if the data is determined to be unable to complete the data transfer request, the apparatus is configured to: schedule transfer of data between a third device (e.g. 214 of Figures 2A to 2C, 3A to 3C) and the first device to enable completion of the data transfer request; obtain a second data access key (e.g.
  • SK T2 of Figures 2B, 2C, 3B and 3C to gain access to a second data storage (e.g. 255 of Figure 2B, E c of Figures 3B and 3C) for storing data to be transferred between the first device and the third device; store the obtained second data access key (e.g. SK T2 of Figures 2B, 2C, 3B and 3C) in the memory; obtain a third public key (e.g. PK C of Figures 2B, 3A) associated with the third device; encrypt the second data access key with the first public key (e.g. PK A of Figures 2B, 3B, if the first device is 204) to form a third encrypted key (e.g.
  • a third public key e.g. PK C of Figures 2B, 3A
  • AK C of Figures 2B, 3B wherein the second data access key is accessible by decrypting the third encrypted key using the corresponding first private key (e.g. SK A , if the first public key is PK A ) of the first public key; encrypt the second data access key with the third public key to form a fourth encrypted key(e.g. CK of Figures 2B, 3B), wherein the second data access key is accessible by decrypting the fourth encrypted key using a corresponding third private key (e.g. SK C of Figures 2B, 3A) of the third public key; and remove the second data access key from the memory permanently.
  • the corresponding first private key e.g. SK A , if the first public key is PK A
  • a fourth encrypted key e.g. CK of Figures 2B, 3B
  • the second data access key is accessible by decrypting the fourth encrypted key using a corresponding third private key (e.g. SK C of Figures 2B, 3A) of the third
  • the apparatus may be configured to remove the second data access key from the memory permanently by replacing memory space allocated in the memory to store the second data access key with data not related to the second data access key.
  • Duplicate copies of the third encrypted key and/or the fourth encrypted key may be stored in the plurality of servers.
  • the apparatus may be configured to: receive a notification indicating that the data to be transferred between the first device and the second device that is stored in the data storage has been retrieved; and remove the first encrypted key and the second encrypted key permanently from the plurality of databases upon receipt of the notification indicating that the data stored in the data storage has been retrieved.
  • the apparatus may be configured to send a request to a server for generating the data access key associated with the data storage to send a notification that indicates the retrieval of the data stored in the data storage.
  • the apparatus may be configured to send a request to the server for generating the data access key to delete a copy of the first public key and a copy of first private key
  • an escrow server present in an example of the present disclosure may be configured to send a request signal to a storage server to delete a data access key and/or a public key of a data access key-pair generated for a data storage.
  • the request signal sent by the escrow server may be a network data packet that indicates the data access key and/or the public key is well-received by the escrow server.
  • the storage server may also be configured to send a confirmation signal to the escrow server to notify that the data access key and/or the public key has been deleted by the storage server..

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un appareil et un procédé permettant de commander un accès à des données, le procédé comprenant l'obtention d'une clé d'accès à des données afin d'accéder à un stockage de données pour stocker des données à transférer entre un premier dispositif et un second dispositif; le stockage de la clé d'accès à des données obtenue dans une mémoire; l'obtention d'une première clé publique associée au premier dispositif; l'obtention d'une seconde clé publique associée au second dispositif; le chiffrement de la clé d'accès à des données avec la première clé publique afin de former une première clé chiffrée; le chiffrement de la clé d'accès à des données avec la seconde clé publique afin de former une seconde clé chiffrée; et la suppression de la clé d'accès à des données de la mémoire de façon permanente. La clé d'accès à des données est accessible par déchiffrement de la première ou de la seconde clé chiffrée à l'aide d'une première ou d'une seconde clé privée correspondante de la première ou de la seconde clé publique respective.
PCT/SG2018/050513 2018-10-12 2018-10-12 Appareil et procédé permettant de commander un accès à des données WO2020076234A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SG2018/050513 WO2020076234A1 (fr) 2018-10-12 2018-10-12 Appareil et procédé permettant de commander un accès à des données

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2018/050513 WO2020076234A1 (fr) 2018-10-12 2018-10-12 Appareil et procédé permettant de commander un accès à des données

Publications (1)

Publication Number Publication Date
WO2020076234A1 true WO2020076234A1 (fr) 2020-04-16

Family

ID=70164734

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2018/050513 WO2020076234A1 (fr) 2018-10-12 2018-10-12 Appareil et procédé permettant de commander un accès à des données

Country Status (1)

Country Link
WO (1) WO2020076234A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111737747A (zh) * 2020-06-24 2020-10-02 深圳前海微众银行股份有限公司 数据库保密方法、装置、设备及计算机存储介质
CN113821828A (zh) * 2021-11-22 2021-12-21 武汉龙津科技有限公司 一种数据隐私保护方法、装置、设备和存储介质
WO2023023821A1 (fr) * 2021-08-25 2023-03-02 Ric B Richardson Procédé d'entiercement de transaction à l'aide de portefeuilles à chaîne de blocs
CN111737747B (zh) * 2020-06-24 2024-05-31 深圳前海微众银行股份有限公司 数据库保密方法、装置、设备及计算机存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090106561A1 (en) * 2007-10-16 2009-04-23 Buffalo Inc. Data management apparatus and data management method
CN102377564A (zh) * 2011-11-15 2012-03-14 华为技术有限公司 私钥的加密方法及装置
JP2012138729A (ja) * 2010-12-27 2012-07-19 Kddi Corp データ処理装置、プログラム、およびデータ処理システム
US9037868B2 (en) * 2009-06-11 2015-05-19 Safend Ltd. System and method for protecting information and related encryption keys
US9904788B2 (en) * 2012-08-08 2018-02-27 Amazon Technologies, Inc. Redundant key management

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090106561A1 (en) * 2007-10-16 2009-04-23 Buffalo Inc. Data management apparatus and data management method
US9037868B2 (en) * 2009-06-11 2015-05-19 Safend Ltd. System and method for protecting information and related encryption keys
JP2012138729A (ja) * 2010-12-27 2012-07-19 Kddi Corp データ処理装置、プログラム、およびデータ処理システム
CN102377564A (zh) * 2011-11-15 2012-03-14 华为技术有限公司 私钥的加密方法及装置
US9904788B2 (en) * 2012-08-08 2018-02-27 Amazon Technologies, Inc. Redundant key management

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111737747A (zh) * 2020-06-24 2020-10-02 深圳前海微众银行股份有限公司 数据库保密方法、装置、设备及计算机存储介质
CN111737747B (zh) * 2020-06-24 2024-05-31 深圳前海微众银行股份有限公司 数据库保密方法、装置、设备及计算机存储介质
WO2023023821A1 (fr) * 2021-08-25 2023-03-02 Ric B Richardson Procédé d'entiercement de transaction à l'aide de portefeuilles à chaîne de blocs
CN113821828A (zh) * 2021-11-22 2021-12-21 武汉龙津科技有限公司 一种数据隐私保护方法、装置、设备和存储介质

Similar Documents

Publication Publication Date Title
JP7351591B2 (ja) Ｎ個のうちｍ個の鍵を使用して顧客ウォレットを復元するマルチ承認システム
US10673632B2 (en) Method for managing a trusted identity
KR102322646B1 (ko) 블록체인 내의 스마트 계약에 기초하여 거래 활동의 민감한 데이터를 보호하기 위한 방법 및 디바이스
CN111062716B (zh) 生成区块链签名数据的方法及装置、区块链交易发起系统
US11880828B2 (en) Data protection system and method
KR102205654B1 (ko) 분산 환경에서의 신원 인증 방법
US20200134586A1 (en) Anonymity and traceability of digital property transactions on a distributed transaction consensus network
US20180349894A1 (en) System of hardware and software to prevent disclosure of personally identifiable information, preserve anonymity and perform settlement of transactions between parties using created and stored secure credentials
JP2008501176A (ja) プライバシーを保護する情報配布システム
US20230360040A1 (en) Quantum-safe payment system
KR101923943B1 (ko) 보안이 강화된 암호화폐 송금 시스템 및 방법
US20180300717A1 (en) Cryptographically secure token exchange
KR102163274B1 (ko) 블록체인을 활용한 개인정보 보호 시스템
KR20190132054A (ko) 블록체인 기반 스마트 컨트랙트를 이용한 암호화폐 거래 플랫폼 제공 방법
WO2020076234A1 (fr) Appareil et procédé permettant de commander un accès à des données
JP2018085681A (ja) 強化されたセキュリティを有する取引相互監視システム
US20220286291A1 (en) Secure environment for cryptographic key generation
CA3179201A1 (fr) Systemes et procedes destines a etre utilises pour separer des blocs de donnees vers un stockage distribue
US20220138760A1 (en) Dynamic Ledger Address Masking
KR102475434B1 (ko) 암호화폐 보안 방법 및 시스템
KR20200134187A (ko) 분산 환경에서의 신원 인증 방법
TW202101267A (zh) 帳戶資料處理方法及帳戶資料處理系統
Meister et al. Password-less key recovery via multi-factor multi-party authentication
Austria Dea 2 uth: A Decentralized Authentication and Authorization Scheme for Secure Private Data Transfer
JP2020043465A (ja) 仮想通貨を用いた仮想通貨取引システムに用いられる、コンピュータを機能させるプログラムが記録させたコンピュータ読み取り可能な記録媒体

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18936507

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18936507

Country of ref document: EP

Kind code of ref document: A1