Method and System for secure Applications using Blockchain.

Abstract

Electronic network include multiple users. Each user operates Wallet software application on his/her endpoint devices (special purpose, computer or smartphone). Each Wallet integrates with Cloud-based Identification-as-a-Service(s) (IDaaS) In context of present inventionIDaaS provides real-time, multi-factor, malware-resilient, context-sensitive Strong Identification-as-a-Service of the user and enables Cryptographic Keys Management of the Wallet. Each Wallet provides various Cryptographic functionalities. Each Wallet may be connected with multiple centralized Marketplace software applications, thus allowing these Cryptographic functionalities to interact with specific Marketplace software application. Each Wallet may be connected with multiple decentralized peer-to-peer software applications, thus allowing these Cryptographic functionalities to interact with specific peer-to-peer software application. These software applications may include Information Technology, Financial, Manufacturing, Retail, Insurance, Government, Healthcare and other verticals of Global Economy. The present invention prevents Bad Actors from using or attacking these applications. The present invention also enables Identification of participants of transactions recorded on Blockchain.

Claims

1. A method for securing Blockchain transactions by verified identities, including: a user, performing a real-time, multi-factor, strong identification vs. Cloud-based, Identification-as-a-Service; a wallet software application performing Cryptographic functionalities and linked to said Identification-as-a-Service; a software application, performing specific business activity and linked to said wallet application; a Blockchain ledger, performing storage of transactions and records and linked to said software application; a software link between Blockchain ledger and Cloud-based, Identification-as-a-Service database.

2. The method of claim 1 where the user operates said wallet application, whereby said wallet application generates a wallet Private Key; said wallet Public Address is paired with said Identification-as-a-Service username; said strong identification vs. Cloud-based Identification-as-a-Service returns an Identity String to said wallet application; thereby said wallet Private Key and said Identity String are used to calculate a Blockchain Private Key; thereby said Blockchain Private Key is used to sign a Blockchain transaction.

3. The method of claim 1 where said wallet application sends to said Identification-as-a-Service, the information, comprising of Blockchain public addresses of transaction-recipient, and the user-signing the transaction;

4. The method of claim 1 where said wallet application resides on dedicated hardware or PC or smartphone.

5. The method of claim 1 where said software application, performing specific business activity, is a centralized marketplace or a decentralized peer-to-peer.

6. The method of claim 3, where the information received by Identification-as-a-Service is used to link a Blockchain transaction to verified Identities.

7. The method of claim 1 where software business application is one of the group including Information Technology, Financial, Manufacturing, Retail, Insurance, Government, Healthcare or other verticals of Global Economy.

8. The method of claim 1 where software business application is used to store transactions or records into user-identifiable or anonymous Blockchain ledgers or both.

9. The method of claim 3 where said Identification-as-a-Service is used to validate the Blockchain public address of transaction-recipient.

10. The method of claim 1 where said Identification-as-a-Service stores users Identity information on traditional Database.

11. A system for linking Blockchain transactions to verified identities, comprising: a user, performing a real-time, multi-factor, strong identification vs. Cloud-based, Identification-as-a-Service; a wallet software application performing Cryptographic functionalities and linked to said Identification-as-a-Service; a software application, performing specific business activity and linked to said wallet application; a Blockchain ledger, performing storage of transactions and records and linked to said software application; a software link between Blockchain ledger and Cloud-based, Identification-as-a-Service database.

12. The system of claim 11 where the user operates said wallet application, whereby said wallet application generates a wallet Private Key; said wallet Public Address is paired with said Identification-as-a-Service username; said strong identification vs. Cloud-based Identification-as-a-Service returns an Identity String to said wallet application; thereby said wallet Private Key and said Identity String are used to calculate a Blockchain Private Key; thereby said Blockchain Private Key is used to sign a Blockchain transaction.

13. The system of claim 11 where said wallet application sends to said Identification-as-a-Service, the information, comprising of Blockchain public addresses of transaction-recipient, and the user-signing the transaction;

14. The system of claim 11 where said wallet application resides on dedicated hardware or PC or smartphone.

15. The system of claim 11 where said software application, performing specific business activity, is a centralized marketplace or a decentralized peer-to-peer.

16. The system of claim 13, where the information received by Identification-as-a-Service is used to link a Blockchain transaction to verified Identities.

17. The system of claim 11 where software business application is one of the group including Information Technology, Financial, Manufacturing, Retail, Insurance, Government, Healthcare or other verticals of Global Economy.

18. The system of claim 11 where software business application is used to store transactions or records into user-identifiable or anonymous Blockchain ledgers, or both.

19. The system of claim 11 where said Identification-as-a-Service is used to validate the Blockchain public address of transaction-recipient.

20. The method of claim 11 where said Identification-as-a-Service stores users Identity information on traditional Database.

Description

BRIEF DESCRIPTION OF DRAWINGS

[0029] Various exemplary embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which we describe:

[0030] FIG. 1: Invention Summary for Centralized Marketplace.

[0031] FIG. 2: Invention Summary for Decentralized Application (Dapp) using Smart Contract.

[0032] FIG. 3 Crypto Currency exchangearchitecture.

[0033] FIG. 4 Wallet for Centralized Marketplaceinitialization.

[0034] FIG. 5 Wallet for Centralized Marketplaceexecution.

[0035] FIG. 6 Wallet for Decentralized Applicationinitialization.

[0036] FIG. 7 Wallet for Decentralized Applicationexecution.

[0037] FIG. 8 Trade Financingarchitecture.

[0038] FIG. 9 Trade FinancingContract ledger.

[0039] FIG. 10 Trade FinancingTransaction Ledger.

[0040] FIG. 11 Trade FinancingMarketplace/Legal/Escrow.

[0041] FIG. 12 IdentityBlockchain architecture.

[0042] FIG. 13 IdentityVerification Flowchart.

[0043] FIG. 14 Internet VotingArchitecture.

[0044] FIG. 15 Internet VotingUsing Wallet.

[0045] FIG. 16 Identity and Access ManagementArchitechture.

[0046] FIG. 17 Wallet functionalities.

SUMMARY OF INVENTION

[0047] Aforementioned use cases demonstrate the need for Secure Applications using Blockchain. The present invention can be summarized as following:

[0048] Electronic network include multiple users. Each user operates Wallet software application on his/her endpoint devices (special purpose, computer or smartphone). Each Wallet integrates with Cloud-based Identification-as-a-Service(s) (IDaaS)as described in greater details by U.S. patent applications Ser. Nos. 15/774,012, 14/905,829. In context of present inventionIDaaS provides real-time, multi-factor, malware-resilient, context-sensitive Strong Identificationas-a-Service of the user and enables Cryptographic Keys Management of the Wallet. Each Wallet provides various Cryptographic functionalities. Each Wallet is connected with multiple Marketplace software applications, thus allowing these Cryptographic functionalities to interact with specific Marketplace software application. Each Marketplace application connected either with one or with two Ledgers. These Ledgers are either user-identifiable Blockchain Ledger or anonymous Blockchain Ledger, or both. Marketplace applications include Financial, Manufacturing, Retail, Insurance, Government, Healthcare and other verticals of Global Economy. The present invention prevents Bad Actors from using or attacking these applications.

[0049] Referring to FIG. 1two users 10,20 are using their wallet applications 30,40 and IDaaS 50,60 to interact with Marketplace application 90, incorporating Anonymous and Identifiable Blockchain or Anonymous Blockchain and Traditional Database 70,80 or both.

[0050] As mentioned previouslycentralized marketplace application can be replaced with smart contract. FIG. 2 addresses this as following:

[0051] Referring to FIG. 2: User 91, uses his Crypto Wallet 93 and IDaaS 96 to sign a smart contract 92, executed over the Internet 94 and recorded on Blockchain 95. The records on Blockchain contain pseudonymous public address of the users. The audit 98 links public address to Identity using IDaaS. The same IDaaS is used to provide a Secure Key Management 97 for Crypto Wallet 93.

DETAILED DESCRIPTION OF THE INVENTION

Use Case #1: Cryptocurrency Exchange

[0052] This particular embodiment is described in FIG. 3. Referring to FIG. 3 two users are using their Wallets 100,110 linked to their IDaaS 140,150 to sell cryptocurrency via Cryptocurrency Exchange, denoted as Marketplace 160. The same users are using their Banks 120,130 to buy cryptocurrency via Cryptocurrency exchange, denoted as Escrow 170. Banks are responsible for the transaction legitimacy. The transaction is recorded on Blockchain 180.

[0053] This embodiment practical implementation consists of Crypto Currency and Fiat Currency Flows. Crypto Currency (for example Bitcoin (BTC)) flow:

Buyer finds Seller (address) offer to sell 1 BTC for $10,000 on the exchange.
Buyer transfers $10,100 to the Marketplace. Exchange posts buyer address to the seller, Seller authorizes (via Identification) the transfer to the seller. Transaction recorded on Blockchain. Exchange transfers $9900 to the Seller. Real Time BTC transfer: Seller (Public Address)MarketplaceBuyer (Public Address).
Fiat currency (for example $) flow:
Real-Time Fiat Currency Money Transfer: BuyerMarketplace (commission from both sides)Seller.

[0054] The usage of wallet for cryptocurrency exchange requires the solution of the problem of user's Blockchain Private Key. To this end the usage of wallet includes the following steps, removing a Blockchain Private Key Vulnerability:

Referring to FIG. 4Wallet initialization 200 includes the following Steps:

Step 1:

[0055] Online Identification vs. IDaaS 210 (over SSL). On success Identity String 220 is returned.

Step 2:

[0056] Disconnect from the Internet 230 (airplane mode). (Wallet, disconnected from the Internet, is called cold).

Step 3:

[0057] Enter mnemonic sequence (seed phrase) 240.

Step 4:

[0058] Generate Wallet Private Key1 using mnemonic sequence 250.

Step 5:

[0059] Using key 1 and Identity String generate key2 260.

Key2=Key2 (Key1, Identity String)

[0060] So that Blockchain Private Key 270 is given by:

Blockchain Private Key=Private Key (Key1, Key2)

Step 6:

[0061] Encrypt Key1 with Identity String.

Step 7:

[0062] Print Private Key with QR on paper 280.
Print seed phrase on paper. Store printed backup in Bank's vault.

Step 8:

Encrypt 290 Key1 by Identity String

Step 9:

[0063] End of initialization. Reconnect to the Internet 300.
The above scheme effectively resolves the problem of Blockchain Private Key security.

[0064] The only remaining vulnerability: Blockchain Private Key exists in Memory in split-seconds, while Wallet is online (hot). To take care of this vulnerability on Windows walletsone must limit the memory access rights as following: protect

the PROCESS_VM_READ and PROCESS_QUERY_INFORMATION rights (as described in references on How to Read and Write Other Process Memoryand Process Security and Access Rights).

[0065] Referring to FIG. 5: In order to Execute the Accepted Contract 310 (for example to sell cryptocurrency)the following steps must be performed using wallet:

Step 1:

[0066] Get the recipient Blockchain Pubic address 320. Online Identification (over SSL). Online Identification includes 340 entering 4 digit CODE 330 by the user , displayed in Bold on user's screen. On success Identity String is returned. 350

Step 2:

[0067] Disconnect from the Internet (airplane mode) 360.

Step 3:

[0068] Decrypt key1 with Identity String 370.

Step 4.

[0069] Using key 1 and Identity String generate key2 380.

Resulting in 390:

[0070] Blockchain Private Key=Private Key (key1, key2)

Step 5:

[0071] Copy/paste the recipient address. Sign Transaction 400. The address of the transaction (public key) must be matched with IDaaS CODE returned by IDaaS 450. Thus validating the recipient public address and preventing malware attack.

Step 6:

[0072] Destroy Private Key 410 and key1 420.

Step 7:

Reconnect to Internet 430.

Step 8 Post Transaction 440.

[0073] Identity String is a Large Random number known to IDaaS, but unknown to User. Identity String is a shared secret with Wallet app. Wallet Private Key is a Large Random number known to User but unknown to IDaaS. Wallet Private Key and Identity String are used to calculate Blockchain Private and Public Keys as generally known in Public-key cryptography.

[0074] FIGS. 4 and 5 describe the wallet that can be used for Centralized marketplace. For Smart Contractsan alternative embodiment is advantageous: for example Smart Contract may be utilized using Web integration with wallet, such as Metamask Browser-based Wallet.

[0075] Referring to FIG. 6: to create a new wallet on a personal Device (dedicated hardware, PC or smartphone) 445:

The user creates a random mnemonic and chooses password. This results in Wallet Private Key generation 450. This in turn results in Public Key and Public Address 455 generation. The Wallet sends 470 the Public Address 455 together with IDaaS Username 460. This results in pairing IDaaS username with Public Address 480. By pairing Public Address with IDaaS username- phishing of password/mnemonic will be futile, since the Public Address is protected by external Identification-as-a-Service (IDaaS).

[0076] Subsequent usage of the wallet on the same Device 485 includes:

Entering Mnemonic or password 490. This will results in retrieval of all account addresses (public/private key pairs). The Wallet sends all Public Addresses 495 together with IDaaS Username 500. If 515 IDaaS is already paired with all Public Addresses then wallet will continue its initialization 518. If user has created a new account (public address) then it will be added 516. The user may add new account (public address) after login. In this case she/he must log-in again 517.

[0077] It should be noted that seed phrase (mnemonic) is enough to recover all accounts. The seed phrase is sufficient to regenerate all keys. A hierarchical deterministic wallet (HD wallet) like MetaMask can generate an unlimited number of accounts (public/private key pairs) from a single seed phrase. With an HD wallet, its possible to support multiple accounts, and even multiple crypto currencies, and all the user has to record is a single seed phrase.

[0078] In continuation of FIG. 6, step 518 and Referring to FIG. 7:

The user entering into Buy or Send cryptocurrency 522, needs to enter a recipient address. Then both his account address and recipient address are sent to IDaaS 524. If his account is paired with IDaaS- he performs smartphone multi-factor authentication with ACODE derived from recipient address 528 (as described in greater detail in U.S. patent applications Ser. Nos. 5/774,012, 14/905,829). This ensures that transaction-recipient address is not modified by malware 539. IDaaS username is found from Account Address 530 (since they are paired 526) and user's Identity String is returned to the Wallet. Since the Identity String is a random number, its addition to Wallet Private Key is also a random number, to be chosen as Blockchain Private Key of the user 534. Subsequently Blockchain Public Key and Address is calculated 536. This Public Address will become a new Account Address 537. After transaction is signed-Blockchain Private Key is flushed from memory 538.

Use Case #2: Trade Finance

[0079] This particular embodiment is described in FIG. 8. Referring to FIG. 8the solution for Trade Finance involves single or multiple Identification-as-a-Service(s) (IDaaS) serving various Bank users through their wallets. Each User may interact with Centralized Marketplace 550 software application through their wallet application 500,510. Each IDaaS 520,550 may interact with Legal 560 application and each Bank 540,550 may interact with Escrow 570 application. Marketplace 550 & Legal 560 & Escrow 570 control the access to Contract Ledger 580. The Contract being offered by the Seller (or user who proposed it).The Contract Ledger is identifiable (not anonymous) by design. So that all parties (Seller and Buyer(s) may be identified by Legal app. After record is recorded into Identifiable Contract ledger, it may be executed as transaction in anonymous Transaction ledger 590. This solution may use fiat currency trading through traditional banks.

[0080] The Marketplace can be any Activity where users (buyers and sellers) meet and their transaction require recording. Separation of different Activities to different Marketplaces and thus different Blockchains improves their throughput (see more on What is Blockchain Bloat?).The presented architecture allows performing any type of activity in secure, cost-effective, legally accountable manner, while preserving the Privacy of various participants.

[0081] Trade Financing Contracts may be in any one of the following Stages:

1. Offered by Seller (for example offering to sell the particular House for Specific Amount).
2. Accepted by Buyer (if approved by Marketplace/Legal/Escrow). There may be multiple Buyers (for example each buying an apartment in the House)
3. Executed by Seller (if Seller transferred the ownership of this House to the Buyer.

[0082] Contract Ledger of FIG. 8 is used for the storage of the Contracts prior to their execution. The steps, required from Seller and Buyer, to process from Stage 1 to Stage 2 are shown in FIG. 9. The functionalities of Offering Contract by Seller and Accepting Contract by Buyer or Buyers are implemented in user's Wallet application. Identity String is a shared secret with Wallet app., i.e. a Large Random number (known by IDaaS, but unknown to User). It is used to generate asymmetric Private-Public Key Pair (see reference on Public-key cryptography). Blockchain Private Key is used to post a contract on ledger. Seller offers a contract 610, his Identity verified 620, resulting in Wallet receiving Identity String 630, thus calculating Blockchain Private Key 640, that is used to sign a contract 690 to be posted on the Blockchain ledger 700. Buyer willing to accept the contract 650, his Identity verified 660, resulting in Identity string received 670, thus calculating Blockchain Private Key 680 and finally Contract acceptance 710 to be recorded on Blockchain Ledger 700.

[0083] Alongside with Posting Transaction Record to Transaction ledgerthe wallet will automatically confirm to Marketplace that the Contract is executed. There could be multiple Marketplaces for different types of Records, Goods, Properties, Commodities, Investments, Currencies, etc. Each Wallet may facilitate their Buying, Selling and Registry, allowing secure flow of Data.

[0084] Referring to FIG. 10 -the steps, required from Seller to process from Stage 2 to Stage 3, are shown as following: If contract is legally approved 711the Seller receives Blockchain Public Key of the Buyer(s) 712, seller's Identity is verified 713, resulting in his Wallet receiving Identity string 714 and generating Blockchain Private Key 715, thus signing the transaction with Buyer(s) and 716 and posting it Transaction Blockchain Ledger 717. The latter being anonymous (pseudonymous).

[0085] The stages 1 to 2 to 3 of Trade Financing Contracts require Marketplace/Legal/Escrow approval. Referring to FIG. 11: Marketplace, Legal and Escrow applications are fully integrated. Following validating legal identities 720, contracts are approved 730, buyer sends his fiat currency funds through his Bank to Escrow 740. Following that Marketplace provides Buyer's public addresses to the seller 750. The seller executes transaction with buyer(s). Escrow transfer funds to the seller 760.

[0086] Alternatively one can use cryptocurrency peer-to-peer trading through Smart Contracts, where legal and escrow functionalities are programmatically enforced. Furthermore Contract/Identifiable ledger 580 of FIG. 8 may be replaced by traditional database where Blockchain public address is linked to real Identities.

Use Case #3: Identity Management

[0087] Often we need to present our Identity, but always we need to preserve our Identity. Bad actors may try to steal it (Identity Theft) or use it fraudulently (Identity Fraud). They may even create completely Fake Identity (Synthetic Identity Theft).

On the other hand, while we present our Identitywe should limit the presentation to bare minimum: to get a drink in the Bar you only need to present your age, but to vote you need present your National Identity Card. To open a Bank Accountyou will need to present multiple credentials. Blockchain is ideally suited to store our Identity Attributes, because they cannot be altered without authorization. But storing these attributes in decentralized public Blockchain does not provide a mechanism for preventing Bad Actors getting advantage. We need to prevent from Bad Actors to access this Identity Blockchain altogether.

[0088] This particular embodiment is described in FIG. 12. Referring to FIG. 12 shows a Marketplace (denoted as Identity Hub, possibly operated by Governmental authority or International authority) that is used to verify User's identity (if exists in Identity ledger), write User's identity (if do not exists in Identity ledger or append Identity attributes if provided by the User). Governmental authority may use independent tools to verify various Identity attributes. Users use their wallets 800,810 and their Identification services 820,830 to read, write or append their Identity attributes, using Identity hub 790 on Identity Blockchain Ledger 840. The data on Blockchain ledger is encrypted by Identity Hub. Identity Public Key may be received by Wallet application after Strong Identification vs. IDaaS. This is described in further detail in FIG. 13.

[0089] Referring to FIG. 13in order to perform Identity Verification 850 with user's walletone must specify which Identity attributes 860 he/she wants to present. This is done using CODE selection 870. Then user engages with IDaaS and enters the same CODE 880. Each CODE has specific meaning 900. The usage of CODE with IDaaS is described in greater detail in U.S. application Ser. No. 14/905,829.

Use Case #4: Internet Voting

[0090] This particular embodiment is described in FIG. 14. We want to prevent from Bad Actors to influence the Vote and tinker with the Vote results. Referring to FIG. 14, were Marketplace app. is denoted by Voting Hub 900 and Identity Hub 910. User 920 Posts his vote, signed by his Private Key, and generated using IDaaS 930. Voting Hub receives his Blockchain Public Key. This Key is checked vs. Identity Ledger 950if eligible to votethen Vote is posted in Anonymous Vote Ledger 940. The law requires this ledger to be private and available for audit by the Voter himself.

[0091] Referring to FIG. 15, the usage is Wallet of FIG. 14 is as following: User starts voting application 955 by voting selection 960, so that CODE is generated from voting selection 965. Identification is done using this CODE 970. Returned Identity String 975 to Wallet and Matching of Voting Selection with CODE 980 is followed by Private Key signing 985 and posting the vote 990.

Use Case #5: Identity and Access Management (IAM)

[0092] This particular embodiment is described in FIG. 16. Centralized systems lack the necessary flexibility to allow Extended Enterprises to serve the ever-growing IT needs of their employees, partners and customers. Referring to FIG. 16

Blockchain 1050 provides decentralized IAM for Extended Enterprise, (serving employees, partners and customers). Each IT resource in Extended Enterprise will be listed in IT Directory. Each resource in IT directory will be managed by its IT admin 1090. To get access to the resourcethe user must be authorized by the IT admin
The authorization will be recorded on Blockchain 1050. Once authorizedthe user will get access to the resource, if identified successfully 1095. The access will be recorded on Blockchain 1100.

[0093] The user requesting access 1000 will open Distributed application (Dapp) 1010 using a wallet and Identification service 1030. To request access with Admin Public Address he will sign the transaction 1040 to be recorded on Blockchain 1050. The message to Admin will be sent 1060. If this is the first request 1070 then user's true Identity will be audited vs Identification service 1080. If this user has access rights (proper authorization) he will gain access 1090,1095. If this is not first a request 1070then proper authorization is already exist and he will gain access 1090,1095.

[0094] Summarizing Use Cases 1-5, each user must have a Wallet application that is capable of aforementioned multiple functionalities. These functionalities are shown in FIG. 17. These functionalities are generally dependent on successful identification vs. IDaaS.

[0095] While the foregoing written description of the invention enables one of ordinary kill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope and spirit of the invention as claimed.

Patent Literature

[0096] 1. U.S. patent application Ser. No. 15/774,012 Method and system for protecting and utilizing Internet Identity using smartphone
2. U.S. patent application Ser. No. 14/905,829 Secure Transaction and Access using insecure device

3. US 2016/0342994 A1, Method and System for Fraud Control of Blockchain-based Transactions

[0097] 4. US 2015/0244690A1, Generalized entity network translation
5. U.S. patent application 62/613,422 Method and System for scalable, anonymous, and Secured Marketplace using Blockchain,

Non-Patent Literature

[0098] 1. Blockchain https:en.wikipedia.org/wiki/Blockchain
2. How to Read and Write Other Process Memory http://nullprogram.com/blog/2016/09/03

3. Process Security and Access Rights

[0099] https://msdn.mmicrosoft.com/en/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
4. What is Blockchain Bloat? https://themerkle.com/what-is-Blockchain-bloat/
5. Public-key cryptography https://en.wikipedia.org/wiki/Public-key cryptography

6. Metamask-Browser-Based Etherium Crypto Wallet.

[0100] https://metamask.io
7. A hierarchical deterministic wallet (HD wallet)
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki