Cipherized Signature Appointment

Abstract

A computing system configured for federated wallets with cryptographically secure signature delegation is provided. The system receives a session public key corresponding to a decentralized application and a user. The system further receives an unsigned transaction from a blockchain. The unsigned transaction corresponds to the user. The system also provides a symmetric encryption key to the user's device for encrypting the user's private signing key, determines that the unsigned transaction is valid using the session public key, and transmits the unsigned transaction to the user's device based on the validity of the unsigned transaction.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 331,491, filed April 15, 2022, in the names of Jesús Alejandro Ca'rdenes Cabre', et al., and entitled "Cryptographic Signature Delegation." The above-referenced provisional application is incorporated herein by reference in its entirety. [Background technology]

[0002] Data security and encryption are fields of computer science concerned with protecting information from disclosure to other systems and ensuring that only the intended system can access the information. Data can be encrypted using various techniques, such as public / private key cryptography (e.g., quantum-resistant encryption schemes based on elliptic curve cryptography and lattice cryptography, among others), and can be decrypted by the intended recipient using shared public and private keys and / or other corresponding decryption techniques. Data transmissions are protected from decryption by other systems at least by lack of possession of those encryption information. Summary of the Invention [Means for solving the problem]

[0003] A system and method for a federated wallet with cryptographically secure signature delegation. The system receives first data representing a session public key and corresponding to a first decentralized application and a first user. The system receives second data representing an unsigned transaction of a blockchain and corresponding to the first user. The system uses the session public key and the second data to determine that the unsigned transaction is valid. The system receives third data representing a signed transaction, the signed transaction being associated with the first user. The system transmits third data to at least one device associated with the blockchain, the third data corresponding to the unsigned transaction signed by the private signing key. The present invention provides, for example, the following items. (Item 1) 1. A system comprising: at least one processor; at least one memory, the at least one memory containing instructions that, when executed by the at least one processor, cause the system to: receiving first data representing a session public key corresponding to a first distributed application and a first user; receiving second data representing an unsigned transaction of a blockchain and corresponding to the first user; determining that the unsigned transaction is valid using the session public key and the second data; and receiving third data representing a signed transaction, the signed transaction corresponding to the unsigned transaction signed by a private signing key associated with the first user; transmitting the third data to at least one device associated with the blockchain; at least one memory containing instructions to cause the A system comprising: (Item 2) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: determining an acceptance threshold corresponding to the second data prior to transmitting the third data; receiving fourth data corresponding to a second user, the fourth data representing authorization for the unsigned transaction; and determining a number of confirmations corresponding to the unsigned transaction based on at least the fourth data; and determining that the number of acknowledgements satisfies the acknowledgement threshold; Item 1. The system of item 1, including instructions to: (Item 3) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: determining, prior to transmitting the third data, an approval condition corresponding to the second data, the approval condition corresponding to an approver characteristic; receiving fourth data corresponding to a second user, the fourth data representing authorization for the unsigned transaction; and determining a first characteristic of the second user based on at least the fourth data; and determining that the first characteristic corresponds to the approver characteristic; 3. The system of claim 1 or 2, comprising instructions to: (Item 4) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: receiving a first request from a first device to access an account of the first user, the account corresponding to the blockchain; and determining first authentication data for the first user; generating a first token corresponding to a first browser of the first device based on first authentication data of the first user; transmitting the first token to the first device; 4. The system of claim 1, 2, or 3, including instructions to: (Item 5) 5. The system of claim 4, wherein the second data representing the unsigned transaction is received from the first device, and the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to store the second data in a database. (Item 6) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: receiving a second request from a second device to access an account of the first user; determining second authentication data for the first user; receiving a third request from the second device corresponding to the second data; Retrieving the second data from the database; transmitting the second data to the second device; including instructions to: 6. The system of claim 5, wherein the third data is received from the second device. (Item 7) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: generating a symmetric encryption key; sending the symmetric encryption key to the first device; transmitting the symmetric encryption key to the second device in response to receiving the third request from the second device; and 7. The system of claim 6, further comprising instructions to: (Item 8) The first request is generated from a first browser of the first device, and the at least one memory further comprises instructions that, when executed by the at least one processor, further provide the system with: generating a second token corresponding to a second browser on the first device based on first authentication data of the first user; transmitting the second token to the first device; receiving the third data and the second token from a second browser on the first device; receiving a public signature key corresponding to the private signature key; using the public signing key to determine that the third data corresponds to the first user; and 8. The system of claim 4, 5, 6, or 7, including instructions to: (Item 9) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: receiving fourth data from a database representing a second unsigned transaction of the blockchain corresponding to the first user; determining, using the session public key, that the second unsigned transaction is invalid; and generating notification data representing a notification corresponding to the second unsigned transaction; sending the notification data to a first device of the first user; 9. The system of claim 1, 2, 3, 4, 5, 6, 7, or 8, including instructions to cause (Item 10) The at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to: receiving fourth data from a database representing a second unsigned transaction of the blockchain corresponding to the first user; receiving fifth data representing a blocklist for the decentralized application; determining that the second unsigned transaction is invalid using the fifth data; and generating notification data representing a notification corresponding to the second unsigned transaction; sending the notification data to a first device of the first user; 10. The system of claim 1, 2, 3, 4, 5, 6, 7, 8, or 9, including instructions to: (Item 11) 1. A computer-implemented method comprising: transmitting, using a first device, first data representing a first authentication request for a first user of the first device; receiving a first token corresponding to a first authentication of the first user; generating a private signature key, the private signature key being seeded using the digital certificate; receiving first data representing a decentralized application and an unsigned transaction corresponding to the first user; determining second data representing a signed transaction corresponding to the unsigned transaction using the first data and the private signing key; transmitting the second data and the first token; 11. A computer-implemented method comprising: (Item 12) transmitting, using a second device, third data representing a second authentication request for the first user; receiving a second token corresponding to a second authentication of the first user; receiving the private signature key at the second device; further comprising Item 12. The computer-implemented method of item 11, wherein the second data is determined at the second device and the second data is transmitted from the second device. (Item 13) receiving a symmetric encryption key corresponding to the first user; determining an encrypted private signature key using the symmetric encryption key; removing the symmetric encryption key from the first device in response to determining the encrypted private signature key; receiving the symmetric encryption key after receiving the first data; decrypting the encrypted private signature key using the symmetric encryption key to determine the private signature key; Item 12. The computer-implemented method of item 11, further comprising: (Item 14) 1. A computer-implemented method comprising: receiving first data representing a session public key corresponding to a first distributed application and a first user; receiving second data representing an unsigned transaction of a blockchain and corresponding to the first user; determining that the unsigned transaction is valid using the session public key and the second data; and receiving third data representing a signed transaction, the signed transaction corresponding to the unsigned transaction signed by a private signing key associated with the first user; transmitting the third data to at least one device associated with the blockchain; 11. A computer-implemented method comprising: (Item 15) determining an acceptance threshold corresponding to the second data prior to transmitting the third data; receiving fourth data corresponding to a second user, the fourth data representing authorization for the unsigned transaction; and determining a number of confirmations corresponding to the unsigned transaction based on at least the fourth data; and determining that the number of acknowledgements satisfies the acknowledgement threshold; Item 15. The computer-implemented method of item 14, further comprising: [Brief explanation of the drawings]

[0004] Objects, aspects, features, and advantages of the embodiments disclosed herein will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings, in which like reference numbers identify similar or identical elements. Reference numbers introduced herein, associated with a figure, may be repeated in one or more subsequent figures without additional description herein to provide context for other features, and not all elements may be labeled on every figure. The drawings are not necessarily to scale, emphasis instead being placed on illustrating embodiments, principles, and concepts. The drawings are not intended to limit the scope of the claims included herewith.

[0005] [Figure 1A] FIG. 1A illustrates a system for federated wallets with cryptographically secure signature delegation according to some embodiments of the present disclosure.

[0006] [Figure 1B] FIG. 1B illustrates a device interfacing with a federated wallet with cryptographically secure signing delegation according to some embodiments of the present disclosure.

[0007] [Figure 2] FIG. 2 illustrates an exemplary process for single sign-on with a federated wallet, according to some embodiments.

[0008] [Figure 3] FIG. 3 illustrates an exemplary process for generating a private signature key, according to some embodiments.

[0009] [Figure 4] FIG. 4 illustrates an example process for creating a meta-transaction under a federated wallet, according to some embodiments.

[0010] [Figure 5] FIG. 5 illustrates an exemplary process for signing and executing a transaction with a federated wallet, according to some embodiments.

[0011] [Figure 6] FIG. 6 illustrates an exemplary process for group authorization to conduct a transaction with a federated wallet, according to some embodiments.

[0012] [Figure 7] FIG. 7 illustrates an exemplary user interface for the process of group authorization with a federated wallet, according to some embodiments.

[0013] [Figure 8] FIG. 8 illustrates components of a system according to an embodiment of the present disclosure.

[0014] [Figure 9] FIG. 9 illustrates a network according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0015] Detailed Description Web3 is the next generation of the World Wide Web, based on interconnected decentralized applications (dapps) and underpinned by a blockchain computing architecture. Web3 is based on a trustless system that uses incentives and economic mechanisms instead of relying on trusted third parties. Instead of large portions of the Internet being controlled or owned by a centralized entity, ownership in Web3 is distributed among builders and users, and is therefore decentralized. However, limitations may exist, such as users being limited to authenticating on one device at a time.

[0016] A dapp, such as Uniswap or Upland, is an application that launches or operates without a centralized entity to control it, but instead runs on a distributed computing platform such as a blockchain or other network of computers rather than relying on a single computer. A dapp may operate autonomously through the use of smart contracts. A smart contract may be a program stored on a blockchain and executed when certain predetermined conditions are met. A smart contract may automate agreement based on conditions without the need for an intermediary for agreement. Thus, participants in a smart contract are guaranteed the appropriate outcome as long as the conditions are met. In some embodiments, the blockchain may be an application programming interface (API), and transactions may correspond to interactions with the API.

[0017] Interactions with a blockchain may include queries, reads, and transactions. A transaction is an interaction that modifies the state of the blockchain. While some blockchain transactions may be monetary, such as cryptocurrency, blockchain transactions may encompass a wide range of uses for tracking immutable information. This may include the use of smart contracts for health records, supply chain monitoring, sending notifications, raising support tickets, or registering products.

[0018] Proposed are techniques and architectures that enable access to various authenticated and secured transactions (such as those involving blockchain) using a single sign-on. This approach may be referred to as a federated wallet. The federated wallet described herein corresponds to a data and computing configuration / approach that provides users with a decentralized system that is not tied to a user's specific device and allows users to transact with multiple dapps from a single sign-on. In addition, the federated wallet provides users with access to and signing queued meta transactions from any device to which the user is authenticated through a single sign-on (SSO) process. Finally, the federated wallet incorporates a federation of authenticators that, for some transactions, requires a minimum number of (possibly randomly selected) authenticators to approve and / or sign a transaction before or after the transaction is signed by the user for execution / submission. The systems and methods described herein may be applied to or compatible with quantum computing-resistant algorithms, such as the Stateless Post-Quantum Hash-Based Signature Scheme (SPHINCS+) or any other implementation of post-quantum signatures.

[0019] FIG. 1A illustrates a system for federated wallets with cryptographically secure signature delegation according to some embodiments of the present disclosure. The illustrated system 100 may include a network 170. The network 170 may include the Internet and / or any other wide or local area network, and may include wired, wireless, and / or cellular network hardware. A user device 110, which receives input from a user 105, may communicate with a federated wallet system 120 via the network 170. The device 110 and the federated wallet system 120 may communicate with a blockchain 160, such as a blockchain database, which may itself include multiple devices. The federated wallet system 120 may communicate with a message broker 125. The message broker may be a database or relay service used for queuing meta-transactions associated with the federated wallet system 120.

[0020] Blockchain 160 may maintain a public ledger of information using blockchain technology, as one skilled in the art would understand. Blockchain 160 may be an example of a distributed consensus mechanism. As a public ledger that is a source of consensus on content, the blockchain may be considered non-repudiable. A blockchain database may involve many different physical machines, each storing all or some portion of the blockchain data. A trusted authority, as part of blockchain 160, may determine the source of a message and determine the provider / attestor of a specific piece of information. Group signatures on blockchain 160 may be used to allow members of a specific group to attest to a specific fact without revealing the identities of the individual members.

[0021] Federated wallet system 120 may include different components, such as a federated wallet component as a front end and a custom user management (custom UM) component as a back end. The federated wallet component and the custom UM component may run on one computing system or may be on separate computing systems that comprise federated wallet system 120. Message broker 125 may be centralized, as part of federated wallet system 120, or decentralized, such as as part of a blockchain or third-party service. In some embodiments, the custom UM component may communicate with a database that stores identifications for Uniform Resource Locators (URLs) or dapps, such as allow lists or block lists that can be used to match acceptable URLs and dapps and block malicious (or unauthorized) URLs and dapps. User device 110 interfaces with one or more dapps (illustrated in FIG. 1A as dapp 115), generates transactions, and executes smart contracts.

[0022] A user 105 may use a user device 110 to log in to the federated wallet system 120. The federated wallet system 120 may perform an authentication process, verify the user 105, and generate an SSO token, as described below with reference to FIG. 2. The user 105 may use the user device 110 to access a dapp 115, and the user device 110 may provide the SSO token to the dapp 115 for verification by the dapp 115.

[0023] As shown in FIGS. 1A and 1B, federated wallet system 120 may be configured to receive 130 a session public key corresponding to user 105 from dapp 115. Federated wallet system 120 may store the session public key and match transactions received from dapp 115. dapp 115 may provide an interface to user device 110. User 105 may generate transactions using the interface of dapp 115. Federated wallet system 120 may be configured to receive 132 an unsigned transaction corresponding to user 105 for blockchain 160 from dapp 115. Federated wallet system 120 may store the unsigned transaction with message broker 125.

[0024] User device 110 may request pending unsigned transactions for user 105 from federated wallet system 120, such as unsigned transactions stored in message broker 125. Federated wallet system 120 may determine (134) that one or more unsigned transactions are valid using the session public key. Federated wallet system 120 may send the validated unsigned transactions to user device 110. Additionally, if federated wallet system 120 determines that one or more of the unsigned transactions are invalid, federated wallet system 120 may send a notification to user device 110 identifying the invalid unsigned transactions.

[0025] User 105 may use user device 110 to sign the verified unsigned transaction using a private signing key associated with user 105 (and as described with reference to FIG. 5 ) and send the signed transaction to federated wallet system 120. Federated wallet system 120 may receive (136) one or more signed transactions from user device 110. Federated wallet system 120 may execute (138) the one or more signed transactions by committing the signed transaction to blockchain 160.

[0026] 1B illustrates a device interfacing with a federated wallet with cryptographically secure signature delegation according to some embodiments of the present disclosure. As described above with reference to FIG. 1A, user device 110 may authenticate and perform a transaction via federated wallet system 120. User device 110 may send an authentication request to federated wallet system 120 via a first browser to perform SSO for user 105 and user device 110 (140). As described below with reference to FIG. 2, user 105 may be authenticated through SSO, and user device 110 may receive an SSO token (142) that authenticates user 105 and user device 110.

[0027] User device 110 may generate 144 a private signature key based on the SSO token. User device 110 may receive a symmetric encryption key from federated wallet system 120 and encrypt the private signature key, as described below with reference to FIG. 3. User device 110 may destroy the symmetric encryption key after encrypting the private signature key.

[0028] A user 105 uses a user device 110 to access one or more dapps. 115 to generate unsigned transactions. Federated wallet system 120 may receive the unsigned transactions and store them in message broker 125. User device 110 may request pending unsigned transactions from federated wallet system 120. User device 110 may receive 146 one or more unsigned transactions corresponding to the user and one or more dapps 115.

[0029] User 105 may use user device 110 to sign one or more unsigned transactions using a private signing key (148). User device 110 may request and receive a symmetric encryption key from federated wallet system 120 and use the symmetric encryption key to decrypt the private signing key before signing the transaction. User device 110 sends one or more signed transactions and the SSO token to federated wallet system 120, which scrutinizes and executes the transactions on blockchain 160 (150).

[0030] 2 illustrates an exemplary process for single sign-on with a federated wallet, according to some embodiments. A user 105 may access their federated wallet using a web browser 205 on a computing device 110 (e.g., a desktop computer, laptop, mobile phone, tablet, etc.). The federated wallet may initiate the SSO process so that the authenticated user can access and be authenticated for multiple dapps for the session established by SSO.

[0031] User 105 may initiate an SSO request to federated wallet component 210 of federated wallet system 120 via browser 205. Browser 205 may send a request (225) to fetch a wallet for user 105 from federated wallet component 210 for display and interaction by browser 205. Federated wallet component 210 may redirect the request to the browser, directing browser 205 to SSO server 215 for authentication 230. Browser 205 may send a redirect (235) to SSO server 215. SSO server 215 may then send a request (240) back to browser 205, prompting user 105 regarding their SSO login, such as an email address.

[0032] The browser 205 may send (245) the SSO login provided by the user 105 to the SSO server 215. Based on receiving the SSO login information, the SSO server 215 redirects (250) a request to authenticate the user 105 back to the browser 205. The authentication request (250) includes instructions for the browser 205 to send (255) the authentication request to an authentication server 220, such as a third-party authenticator (e.g., KeyCloak). The authentication server 220 may be a third-party service that enforces authentication given the SSO identity provided. In some embodiments, strong end-user authentication may be achieved through biometric authentication or authenticated hardware. The authentication server 220 may create a Security Assertion Markup Language (SAML) assertion for the SSO server 215 and post it to an Assertion Consumer Service (ACS). The authentication server 220 may send (260) the ACS Uniform Resource Locator (URL) to the browser 205. The browser 205 may use the ACS URL to access the SAML assertion and post 265 the SAML assertion to the SSO server 215.

[0033] Having authenticated user 105, SSO server 215 sends (270) an instruction to browser 205 to provide authentication data to federated wallet component 210. After receiving the redirect instruction with the authentication data, browser 205 sends (275) a new request to fetch the federated wallet application corresponding to user 105 from federated wallet component 210. Once user 105 is authenticated, federated wallet component 210 may provide (280) a wallet interface for the federated wallet application to browser 205. Additionally, the federated wallet component may provide (280) an SSO token (e.g., a JavaScript Object Notation (JSON) Web Token (JWT) token) indicating authentication of the user's identity, which may be used to log in to services such as crypto wallets and other dapps. The SSO token may be information that identifies the user and the system sending the SSO token. The SSO token may be digitally signed so that the recipient of the SSO token can verify that the SSO token is from a trusted source and is therefore also authentic to the user information in the SSO token.

[0034] Through the SSO process and authentication, user 105 uses MetaMask by ConsenSys, Inc. TM or Coinbase TMThe user 105 may access a different wallet or crypto wallet, such as Coinbase Wallet by SSO Server 215. Once the SSO session is established, the user may open an additional browser window, such as by entering a URL, and direct the browser to the wallet. The user 105 may not be prompted to log in to the wallet based on the established SSO session and / or providing an SSO token. The wallet or service may validate the user 105 by providing an SSO token to the SSO server 215. In response to receiving the token, the SSO server 215 may provide a response indicating whether the provided token is valid.

[0035] FIG. 3 illustrates an exemplary process for generating a private signing key, according to some embodiments. After authenticating a user using the SSO process for a federated wallet, as described with reference to FIG. 2, a private signing key may be generated for the user to sign transactions, as described below with reference to FIG. 5. As described with reference to operation 280, the wallet component 210 may provide an SSO token 315 corresponding to the current authenticated SSO session for the user 105. The SSO token may be stored 315 by the browser 205 (e.g., saved in a memory location corresponding to the browser). The token (e.g., a JWT token) may correspond to the established session (e.g., a period starting at the time of authentication) and the user identification (e.g., an email address used during SSO).

[0036] The user 105 may then request (320) a symmetric encryption key to encrypt their private signature key. The browser 205 may send the request (320) for the symmetric encryption key to the custom UM component 305 of the federated wallet system 120. The request (320) may include the SSO token. The custom UM component 305 may receive the request and / or token and validate the user 105 based on the SSO token. Using the SSO token as a match for the user 105 and the corresponding user identity, the custom UM component 305 may generate (325) a symmetric encryption key (e.g., Advanced Encryption Standard (AES)) or secret and assign the symmetric encryption key to the user identity. In some implementations, the custom UM component 305 may send (330) the symmetric encryption key to a key management service (KMS) 310, which stores the symmetric encryption key. A service such as the KMS 310 may conform to a standard or set of rules for securing and managing encryption keys and / or other types of secrets.

[0037] The symmetric encryption key may be a rotationally symmetric encryption key. On a timely basis (e.g., weekly, monthly, etc.), the custom UM component 305 may generate a new symmetric encryption key. Data encrypted with the previous symmetric encryption key (e.g., a signature key) may be decrypted using the previous symmetric encryption key and then re-encrypted with the new symmetric encryption key. In some embodiments, the symmetric encryption key itself is also encrypted with threshold encryption. Threshold encryption may require a minimum number of secrets (e.g., "t-out-of-N") from other users to decrypt the symmetric encryption key so that the symmetric encryption key can then be used to decrypt it.

[0038] The custom UM component 305 may return (335) the symmetric encryption keys to the computing device 110 for receipt by the browser 205. By storing the symmetric encryption keys in the KMS, the request (320) and return (335) of the symmetric encryption keys may occur at a later point in time. For example, the day after the generation (325) and storage (330) of the symmetric encryption keys, the user may perform the SSO process, described with reference to FIG. 2, and then request their symmetric encryption keys from the KMS 310 via the custom UM component 305.

[0039] The browser 205 may generate (340) a private signing key for the user 105 (e.g., session key initialization). The private signing key may be seeded using a digital certificate (e.g., a public key infrastructure (PKI) digital certificate). The private signing key may be seeded using data or a digital certificate stored on an integrated circuit chip (e.g., a common access card (CAC)). The private signing key may be used to sign blockchain transactions. The user 105 may have a secret recovery phrase (SRP) corresponding to a specific cryptographic wallet. The SRP may be 12 words that seed the user's digital identity and can be used to generate keys that grant access to the user's wallet. The SRP may be used to create and restore specific wallets. The private signing key is what allows the user to access or "unlock" their account on the blockchain. To prevent the private signing key from being exposed, the private signing key is encrypted (345) using a symmetric encryption key. The private signature key could potentially be stolen if it were left in plaintext (e.g., decrypted). The encrypted private signature key is then stored (350) in memory of the device corresponding to browser 205. The encrypted private signature key may then be decrypted and accessed when required to complete a transaction, as described below with reference to FIG.

[0040] Through authentication of user 105 by the SSO process and receipt of a session token corresponding to the SSO session, user 105 is validated to connect to multiple dapps simultaneously, using a separate browser window for each dapp. Previously, without the federated wallet component 210 and an established SSO session, a user might be required to reinitialize their private signing key for each session established from a dapp connection.

[0041] In some embodiments, the symmetric encryption key and private signing key need not be generated; instead, users may use another mechanism, such as their Common Access Card (CAC), such as those used by U.S. government agencies, including the Department of Defense. A CAC may be a smart card containing an encrypted private signing key that users can use to access their blockchain account and sign transactions.

[0042] 4 illustrates an exemplary process for creating a meta-transaction under a federated wallet, according to some embodiments. Based on establishing a session through the SSO process and receiving one or more session tokens as described above, the user 105 may be verified for the device 110 and initiate a session with one or more dapps. The user 105 may open a second browser 405 and type in a URL for a particular dapp 115 (e.g., Uniswap®). As illustrated in FIG. 4, the second browser 405 may request to log in (420) to the dapp 115 and provide the session token to authenticate itself.

[0043] The dapp 115 may generate a session public key and a corresponding session private key and use them to register the user 105 (425). The session public key corresponds to the user 105 and the dapp 115 and may be used as a type of identifier for the session that the user 105 establishes with the dapp 115 and corresponds to the user's wallet. The dapp 115 may send the session public key to the custom UM component 305 (430). The custom UM component 305 may store the session public key (435).

[0044] The custom UM component 305 may use the session public key to verify that messages (e.g., transactions) received from the dapp 115 corresponding to the user 105 are valid requests and prevent any attempts to hijack the session. For example, a malicious dapp may send messages to a user who has never used the malicious dapp. If the recipient of the messages from the malicious dapp accidentally or inadvertently responds to one of the messages, the custom UM component 305 may prevent any actions corresponding to the messages from the malicious dapp from proceeding because the custom UM component 305 did not store the session public key corresponding to the malicious dapp and the user 105.

[0045] Additionally, the custom UM component 305 may store a dapp allow list and a block list corresponding to a particular user 105. For example, the user 105 may mistype a URL for a particular dapp, such as typing "example-dapp" instead of "example-dapp." The mistyped URL may be directed toward a malicious dapp that disguises the dapp intended by the user 105. The user 105 may unknowingly generate messages and meta-transactions using the malicious dapp. However, the messages may be intercepted by the custom UM component 305, and the URL of the malicious dapp may be compared to the allow list and / or block list. The custom UM component 305 may prevent any further actions corresponding to the malicious dapp from proceeding.

[0046] In some embodiments, the custom UM component 305 may provide the dapp 115 with confirmation (440) that the session public key has been stored, and the dapp 115 may proceed with the session for the user 105. The dapp 115 may then provide (445) a user interface (e.g., code for rendering a graphical user interface) to the second browser 405.

[0047] A user 105 may perform various functions and actions provided by a dapp 115. Specifically, a user 105 may generate a meta transaction (450). A meta transaction may contain all or some of the same information as a blockchain transaction; however, the meta transaction is not signed by the user 105, such as with a private signing key. A user 105 may wish to batch a set of meta transactions to be all signed and submitted to the blockchain at the same time.

[0048] The user 105 may submit a meta transaction (455) via the second browser 405. The dapp 115 may sign the meta transaction using a session private key and send the session-signed meta transaction to the message broker 125 (460). The session private key represents the session established for the user 105 and the dapp 115 and corresponds to the session public key. In some embodiments, the meta transaction may be encrypted using the session key. In some embodiments, a queue of meta transactions for one or more users may be stored in the message broker 125. In other embodiments, the queue may be stored in a database associated with the custom UM component 305 and / or the federated wallet component 210. The meta transaction may be stored in the queue based on the session public key and / or the dapp session identifier and the user identifier. The meta transaction stored in the message broker 125 may be encrypted, such as with a session key, to prevent others from accessing and understanding the contents of the pending meta transaction. In some embodiments, the dapp 115 may communicate directly with the message broker 125, preventing the dapp 115 from communicating directly with the wallet and thus preventing potentially malicious dapps from accessing the user's wallet. The message broker 125 may provide a confirmation (465) to the dapp 115, viewable via the second browser 405, that the meta transaction has been added to the message broker 125's queue.

[0049] 4 may be performed for one or more meta-transactions corresponding to one or more dapps. The meta-transactions may be stored (e.g., queued) by message broker 125 corresponding to user 105, based on a user identification or an SSO token (e.g., an identifier corresponding to the SSO token), etc.

[0050] 5 illustrates an exemplary process for signing and executing a transaction with a federated wallet according to some embodiments. Once user 105 has signed and is ready to execute one or more pending meta-transactions queued in message broker 125, user 105 may request (510) to view the pending meta-transactions from federated wallet component 210 via browser 205 of user device 110. Federated wallet component 210 may retrieve (515) the pending meta-transactions corresponding to user 105 from message broker 125. In some embodiments, browser 205 may be a third browser on user device 110. User 105 may be authenticated via the third browser using the SSO process described with reference to FIG. 2.

[0051] The federated wallet component 210 may receive the pending meta transaction from the message broker 125 and review the meta transaction for validity (520). The federated wallet component 210 may use one or more public session keys corresponding to the dapp session initiated by the user 105, such as a session key, generated in operation 425 and stored by the federated wallet component 210 in operation 435. The public session key may identify the user 105 and the dapp 115 and is generated based on the user 105 being authorized through an SSO process. The session public key is thus an indication of the validity of the meta transaction corresponding to both the dapp 115 and the user 105. As described with reference to operation 460, the meta transaction submitted to the message broker 125 is signed with the session private key. The federated wallet component 210 may then verify the meta transaction using the corresponding session public key. Scrutiny (520) to verify the meta transaction may prevent the signing and possible submission of fraudulent transactions. For example, if a malicious dapp generates a fraudulent meta transaction for user 105 and adds the fraudulent meta transaction to message broker 125, when federated wallet component 210 scrutinizes (520) the fraudulent meta transaction, the federated wallet component 210 may determine that the fraudulent meta transaction is not signed with a private session key that corresponds to at least one of the public session keys stored by federated wallet component 210 and that corresponds to user 105. Additionally, federated wallet component 210 may scrutinize transactions that may correspond to the fraudulent dapp.The federated wallet system may maintain a database of fraudulent or malicious dapps and use the database to identify fraudulent meta-transactions.

[0052] Once federated wallet component 210 has reviewed the queued meta transactions from message broker 125 and determined a valid meta transaction based at least on the public session key, federated wallet component 210 may present the pending meta transactions to user 105 via browser 205 (525). User 105 may select one or more of the pending meta transactions and sign them with a private signing key (530). The encrypted private signing key stored in operation 350 may be decrypted using a symmetric encryption key. In some embodiments, device 110 may receive the symmetric encryption key from KMS 310 or from KMS 310 via federated wallet component 210. Federated wallet component 210 may receive one or more signed transactions and verify the transactions using a public signing key corresponding to the private signing key of user 105 and / or an SSO token as previously established in operation 315 (535).

[0053] Message broker 125, combined with federated wallet component 210 (e.g., a federated wallet), enables display of pending meta transactions across multiple devices (e.g., laptops, tablets, mobile phones, etc.). For example, if user 105 utilizes a second device different from device 110, user 105 may access the federated wallet on the second device after performing the SSO process described with reference to FIG. 2. The federated wallet displayed on the second device may present the same pending meta transactions for user 105.

[0054] In some embodiments, the SSO token may be used by the custom UM component 305 to determine the signing and submission permissions of the user 105. For example, if the user 105 is part of an organization and is generating a transaction on behalf of the organization, the SSO token (as provided by the organization's SSO) may indicate the permissions for the user 105. The SSO token may indicate that the user 105 does not have permission to submit the transaction based on job title / role, etc.

[0055] In some embodiments, submitting a transaction as indicated by an SSO token may require agreement or a minimum number of approvals (e.g., t-out-of-n). As described below with reference to FIG. 6, approvals may be required from one or more other users. The federated wallet component 210 may verify (540) that the number of approvals for the transaction meets or exceeds an approval threshold. The federated wallet component 210 may prevent the transaction submission from proceeding until the required number of approvals has been received.

[0056] After verifying (535) the SSO token and, if required, verifying (540) group authorization, the federated wallet component 210 may submit (545) the transaction to the blockchain 160. In some embodiments, the blockchain 160 may be a smart account for an organization or the like, and the transaction submission corresponds to the execution of a smart contract. In some embodiments, the blockchain 160 may be an API, and the transaction submission corresponds to a submission to or interaction with the API. The blockchain 160 may provide (550) confirmation of the transaction submission to the federated wallet component 210. The federated wallet component 210 may then present (555) the submission confirmation to the user 105 via the browser 205.

[0057] In some embodiments, user 105 may access federated wallet component 210 and request a pending meta transaction using a second device and a browser on the second device. User 105 may be authenticated using an SSO process similar to the SSO process described with reference to FIG. 2 for the second device. The second device may receive at least one SSO token corresponding to at least one browser on the second device (and similar to operation 280) based on authentication of user 105 on the second device. In some embodiments, the second device may then receive the pending meta transaction and be used to sign the pending meta transaction with the user's private signing key, as described with reference to the operations of FIG. 5.

[0058] FIG. 6 illustrates an exemplary process for group authorization to conduct a transaction with a federated wallet, according to some embodiments. As shown with operation 540 in FIG. 5, the federated wallet component 210 may, in some embodiments, confirm group consent to submit the transaction. The federated wallet component 210 may determine 610 that a particular signed transaction, such as the signed transaction received in operation 530, requires group authorization, where the group may be one or more users other than the signing user 105. Determining that a transaction requires group authorization may be based on factors such as the type of transaction, the signing user, characteristics of the signing user, the signing user's title or role, cross-organizational policies, etc. In some embodiments, providing authorization may provide an indication (e.g., approve or disapprove) through a software application or communication, as shown in action review interface 725 of FIG. 7. In some embodiments, providing authorization may require a signature (e.g., a private signing key) from one or more approvers. Similar to the action 530 of user 105 signing the meta transaction using their private signing key, the transaction may be ready for submission to blockchain 160 only once the necessary approvers have also signed the transaction with their private signing keys.

[0059] The federated wallet component 210 may identify (615) a set of approvers for the transaction. The set of approvers for the transaction may be a general group, such as a designated group or committee within an organization, or may be a set of specific users / members depending on factors such as the type of transaction or the parties involved in the transaction (e.g., user 105, recipient, etc.). The set of approvers may be based on characteristics of the approvers, such as title or role within the organization, age, skills, certifications, etc. For example, a transaction may require one approval by a person with the characteristic of holding the manager title, and thus any individual who is a manager with respect to the organization, rather than a specific person.

[0060] The set of approvers may be identified as part of the smart contract 640. The smart contract 640 may be stored and executed as part of the blockchain 160, which may or may not be the same blockchain that receives the transaction submission as described with reference to FIG. 5. The smart contract 640 may be a program that is stored on the blockchain 160 and executed when certain predetermined conditions are met. For example, the smart contract 640 may include a condition that at least three approvals are required for the smart contract 640 to execute (e.g., allow the transaction submission to proceed). In another example, the smart contract 640 may include a requirement that approvals be received from a specific set of approvers (e.g., a first approver 605a and a second approver 605b).

[0061] The federated wallet component 210 may request approval for the transaction (620a-620n) from one or more approvers 605a-605n identified as the set of approvers for the transaction. The approvers 605a-605n may receive notifications via the federated wallet 210 that are displayed in the individual approvers' browsers or wallet applications. The notifications may include information about the transaction and the requesting signer (e.g., user 105). The individual approvers 605a-605n may send responses to the approval requests (625a-625n) back to the federated wallet component 210. The responses may indicate whether a particular approver approves or denies the submission of the transaction.

[0062] The federated wallet component 210 may determine an approval threshold. The approval threshold may indicate the minimum number of approvals required for a transaction to be submitted. Similar to determining the set of approvers, the approval threshold may be a general threshold or a threshold determined based on factors such as the type of transaction or the characteristics of the user 105. The federated wallet component 210 may determine (630) whether the number of received responses 625a-625n indicating approval for the transaction meets and / or exceeds the approval threshold. The group approval process may have a time limit (e.g., 1 hour, 12 hours, etc.) for receiving responses. If the number of responses indicating approval received within the time limit does not meet the approval threshold, the transaction may be rejected. The federated wallet component 210 may provide a notification (635) to the signer (e.g., user 105) indicating whether the transaction was approved for submission, such as via a wallet displayed by the browser 205. If federated wallet component 210 determines 630 that the number of responses indicating approval meets or exceeds the approval threshold, federated wallet component 210 may provide a notification indicating the transaction is approved and then proceed to submit the transaction to blockchain 160 545. If federated wallet component 210 determines 630 that the number of responses indicating approval does not meet the approval threshold (e.g., the number of denials prevents the approval threshold from being met or a time limit expires before the approval threshold is met), federated wallet component 210 may provide a notification indicating that the transaction was not approved. Based on a denial determination, the signing and submission process described with reference to FIG. 5 may then terminate, and federated wallet component 210 may not submit the transaction.

[0063] 7 illustrates an exemplary user interface for the process of group approval with a federated wallet, according to some embodiments. As described with reference to FIG. 6, transaction submission using a federated wallet may include a requirement to receive group approval before proceeding.

[0064] An administrator for a federated wallet, such as a federated wallet for an organization, may access an administration interface 705 to set user permissions and define authorization groups for vetting of actions (e.g., transactions). The administration interface 705 may include specifying the types of actions that a particular user 105 has permission to perform. Additionally, the administration interface 705 may include identifying members of authorization groups, determining the types of actions for which approval is requested from the authorization group, and determining the approval threshold.

[0065] In some embodiments, an administrator may revoke or completely revoke signing capabilities from a user 105, such as if the user is no longer employed by the organization. The public signing key corresponding to the user's private signing key may be added to a block list. The federated wallet component 210 may then identify any transactions signed with the user's private signing key using the public signing key to be blocked.

[0066] Users 105 may view queued and pending meta transaction dashboard 710 in their browser 205, similar to operation 525 of Figure 5. Pending meta transaction dashboard 710 may present sanitized pending meta transactions to users 105, where sanitization may include obfuscating, removing, and / or formatting the data to prepare the data (e.g., transactions) before it is transferred from a secret network (e.g., internal to an organization using a federated wallet) to an unclassified network (e.g., blockchain 160).

[0067] As described above, a federated wallet may provide for a user to access the federated wallet from multiple devices. A user 105 may review a sanitized meta transaction on a pending meta transaction dashboard 710 from a first device (e.g., a desktop computer) and then request submission of the pending transaction from a second device (e.g., a mobile phone). The user 105 may request submission of the pending transaction, and the federated wallet may perform a permission check 715 on behalf of the user 105, such as based on permissions specified by an administrator using the management interface 705.

[0068] The federated wallet may determine that the user 105 does not have permission to submit the requested transaction. An approver from the approval group may receive an approval request notification 720. The approval request notification 720 may indicate that the requested action (e.g., transaction submission) has been denied based on the permission check 715. The approval request notification 720 may include a review button 721 for the approver to select and review the requested action. Upon selecting the review button 721, the approver may be presented with an action review interface 725. The action review interface 725 may include information about the requested action, such as the parties involved, the assets of the transaction, and the requester (e.g., the user 105). Additionally, the action review interface 725 may include a deny button 726 and an approve button 727 for the approver to select and provide their approval or denial for the requested action. The federated wallet may log the approver's response on the blockchain 160 as an immutable, auditable record that does not require manual record-keeping.

[0069] The requester (e.g., user 105) may receive notification (e.g., email, wallet notification, etc.) that the requested action has been approved (or denied), and the approval results 730 may be displayed on the wallet dashboard. After approval, members of the approval group may be notified that the action has been approved (or denied) and the requested action has been completed.

[0070] FIG. 8 is a block diagram illustrating a computing environment including a server 800, which may be the federated wallet system 120 and / or the blockchain 160. The server 800 may include one or more physical devices and / or one or more virtual devices, such as virtual systems, running within a cloud server or similar environment. The server 800 may include one or more input / output device interfaces 802 and a controller / processor 804. The server 800 may further include a storage device 806 and a memory 808. A bus 810 may enable the input / output device interface 802, the controller / processor 804, the storage device 806, and the memory 808 to communicate with each other; the components may alternatively or additionally be directly connected to each other or connected via different buses.

[0071] Various components may be connected through input / output device interface 802. For example, input / output device interface 802 may be used to connect to network 170. Further components may include a keyboard, a mouse, a display, a touchscreen, a microphone, a speaker, and any other type of user input / output device. Further components may include a USB drive, a removable hard drive, or any other type of removable storage device.

[0072] The controller / processor 804 may process data and computer-readable instructions and may include a general-purpose central processing unit, an application-specific processor such as a graphics processor, a digital signal processor, an application-specific integrated circuit, a microcontroller, or any other type of controller or processor. The memory 808 may include volatile random-access memory (RAM), non-volatile read-only memory (ROM), non-volatile magnetoresistive RAM (MRAM), and / or other types of memory. The storage device 806 may be used to store data and controller / processor-executable instructions on one or more non-volatile storage devices, such as magnetic storage devices, optical storage devices, solid-state storage devices, etc.

[0073] Computer instructions for operating server 800 and its various components may be executed by controller / processor 804, using memory 808 as temporary "working" storage during runtime. The computer instructions may be stored in a non-transitory manner in memory 808, storage device 806, and / or an external device. Alternatively, some or all of the executable instructions may be embodied in hardware or firmware on a separate device in addition to, or instead of, software.

[0074] 9 illustrates several devices 110 communicating with federated wallet system 120 using network 170. The devices 110 may include a smartphone 902, a laptop computer 904, a tablet computer 906, and / or a desktop computer 908. These devices 110 may be used to remotely access federated wallet system 120 and perform any of the operations described herein.

[0075] The details of this specification may also be understood in light of the following notes.

[0076] 1. A system comprising: at least one processor; and at least one memory containing instructions that, when executed by the at least one processor, cause the system to receive first data representing a session public key corresponding to a first decentralized application and a first user; receive second data representing an unsigned transaction on a blockchain and corresponding to the first user; determine, using the session public key and the second data, that the unsigned transaction is valid; receive third data representing a signed transaction, the signed transaction corresponding to the unsigned transaction signed by a private signing key associated with the first user, and send the third data to at least one device associated with the blockchain.

[0077] 2. The system of Appendix 1, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to determine an approval threshold corresponding to the second data, prior to sending the third data; receive fourth data representing approvals for the unsigned transaction and corresponding to the second user; determine a number of approvals corresponding to the unsigned transaction based on at least the fourth data; and determine that the number of approvals satisfies the approval threshold.

[0078] 3. The system of claim 1 or 2, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to determine, prior to sending the third data, an approval condition corresponding to the second data, wherein the approval condition corresponds to an approver characteristic and represents approval for the unsigned transaction, receive fourth data corresponding to the second user, determine a first characteristic of the second user based on at least the fourth data, and determine that the first characteristic corresponds to the approver characteristic.

[0079] 4. The system of claim 1, 2, or 3, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to receive a first request from a first device to access an account of a first user, the account corresponding to a blockchain, determine first authentication data for the first user, generate a first token corresponding to a first browser on the first device based on the first authentication data of the first user, and send the first token to the first device.

[0080] 5. The system of Appendix 4, wherein second data representing the unsigned transaction is received from the first device, and the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to store the second data in a database.

[0081] 6. The system of Appendix 5, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to receive a second request from the second device, access the account of the first user, determine second authentication data for the first user, receive a third request from the second device corresponding to the second data, retrieve the second data from the database, and send the second data to the second device, wherein the third data is received from the second device.

[0082] 7. The system of Appendix 6, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to generate a symmetric encryption key, cause the first device to transmit the symmetric encryption key, and, in response to receiving a third request from the second device, cause the second device to transmit the symmetric encryption key.

[0083] 8. The system of Appendix 4, 5, 6, or 7, wherein the first request is generated from a first browser on the first device, and the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to generate a second token corresponding to a second browser on the first device based on first authentication data of the first user, send the second token to the first device, receive third data and the second token from the second browser on the first device, receive a public signing key corresponding to the private signing key, and use the public signing key to determine that the third data corresponds to the first user.

[0084] 9. The system of Claim 1, 2, 3, 4, 5, 6, 7, or 8, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to receive, from the database, fourth data representing a second unsigned transaction on the blockchain corresponding to the first user; determine, using the session public key, that the second unsigned transaction is invalid; generate notification data representing a notification corresponding to the second unsigned transaction; and send the notification data to the first device of the first user.

[0085] 10. The system of Appendix 1, 2, 3, 4, 5, 6, 7, 8, or 9, wherein the at least one memory further includes instructions that, when executed by the at least one processor, further cause the system to receive, from the database, fourth data representing a second unsigned transaction on the blockchain corresponding to the first user; receive fifth data representing a blocklist for the decentralized application; determine using the fifth data that the second unsigned transaction is invalid; generate notification data representing a notification corresponding to the second unsigned transaction; and send the notification data to the first device of the first user.

[0086] 11. A computer-implemented method, comprising: using a first device, transmitting first data representing a first authentication request for a first user of the first device; receiving a first token corresponding to the first authentication of the first user; generating a private signing key, the private signing key being seeded using a digital certificate; receiving first data representing an unsigned transaction corresponding to the decentralized application and the first user; determining second data representing a signed transaction corresponding to the unsigned transaction using the first data and the private signing key; and transmitting the second data and the first token.

[0087] 12. The computer-implemented method of claim 11, further including: using the second device, transmitting third data representing a second authentication request for the first user; receiving a second token corresponding to the second authentication of the first user; and receiving a private signing key at the second device; determining the second data at the second device; and transmitting the second data from the second device.

[0088] 13. The computer-implemented method of claim 11 or 12, further including receiving a symmetric encryption key corresponding to the first user; using the symmetric encryption key to determine an encrypted private signature key; and in response to determining the encrypted private signature key, removing the symmetric encryption key from the first device; receiving the symmetric encryption key after receiving the first data; and using the symmetric encryption key to decrypt the encrypted private signature key and determine the private signature key.

[0089] 14. A computer-implemented method, comprising: receiving first data representing a session public key corresponding to a first decentralized application and a first user; receiving second data representing an unsigned transaction of a blockchain and corresponding to the first user; determining that the unsigned transaction is valid using the session public key and the second data; receiving third data representing a signed transaction, wherein the signed transaction corresponds to the unsigned transaction signed by a private signing key associated with the first user; and sending the third data to at least one device associated with the blockchain.

[0090] 15. The computer-implemented method of claim 14, further including, prior to sending the third data, determining an approval threshold corresponding to the second data; receiving fourth data representing approvals for the unsigned transaction and corresponding to the second user; determining a number of approvals corresponding to the unsigned transaction based on at least the fourth data; and determining that the number of approvals satisfies the approval threshold.

[0091] 16. The computer-implemented method of claim 14 or 15, further comprising: prior to sending the third data, determining an approval condition corresponding to the second data, the approval condition corresponding to an approver characteristic, representing approval for the unsigned transaction; receiving fourth data corresponding to the second user; and determining a first characteristic of the second user based on at least the fourth data; and determining that the first characteristic corresponds to the approver characteristic.

[0092] 17. The computer-implemented method of claim 14, 15, or 16, further including: receiving a first request from a first device to access an account of a first user, the account corresponding to a blockchain; determining first authentication data of the first user; generating a first token based on the first authentication data of the first user; and transmitting the first token to the first device.

[0093] 18. The computer-implemented method of claim 17, further including generating a symmetric encryption key, transmitting the symmetric encryption key to the first device, and transmitting the symmetric encryption key to the second device in response to receiving a third request from the second device corresponding to the second data.

[0094] 19. The computer-implemented method of claim 14, 15, 16, 17, or 18, further including receiving fourth data from the database, the fourth data representing a second unsigned transaction on the blockchain corresponding to the first user; determining, using the session public key, that the second unsigned transaction is invalid; generating notification data representing a notification corresponding to the second unsigned transaction; and sending the notification data to the first device of the first user.

[0095] 20. The computer-implemented method of claim 14, 15, 16, 17, 18, or 19, further including receiving, from the database, fourth data representing a second unsigned transaction on the blockchain corresponding to the first user; receiving fifth data representing a blocklist for the decentralized application; determining using the fifth data that the second unsigned transaction is invalid; generating notification data representing a notification corresponding to the second unsigned transaction; and sending the notification data to the first device of the first user.

[0096] The above-described aspects of the present disclosure are meant to be illustrative. They are chosen to illustrate the principles and applications of the present disclosure and are not intended to be exhaustive or to limit the present disclosure. Many modifications and variations of the disclosed aspects will be apparent to those skilled in the art. Those skilled in the computer and data processing arts will recognize that the components and process steps described herein may be interchanged with other components or steps or combinations of components or steps and still achieve the benefits and advantages of the present disclosure. Moreover, it will be apparent to those skilled in the art that the present disclosure may be practiced without some or all of the specific details and steps disclosed herein.

[0097] Aspects of the disclosed system may be implemented as a computer method or as an article of manufacture, such as a memory device or non-transitory computer-readable storage medium. The computer-readable storage medium may be read by a computer and may comprise instructions to cause a computer or other device to perform the processes described in this disclosure. The computer-readable storage medium may be implemented by volatile computer memory, non-volatile computer memory, a hard drive, a solid-state memory, a flash drive, a removable disk, and / or other medium. Additionally, components of one or more of the modules and engines may be implemented in firmware or hardware.

[0098] In particular, conditional language used herein, such as "can," "could," "might," "may," "e.g.," and the like, is intended to generally convey that certain embodiments include certain features, elements, and / or steps, while other embodiments do not, unless specifically stated otherwise or understood otherwise within the context as used. Thus, such conditional language is not intended to generally imply that features, elements, and / or steps are in any way required for one or more embodiments, or that one or more embodiments necessarily include logic for determining whether those features, elements, and / or steps are to be included or performed in any particular embodiment, with or without other input or prompting. The terms "comprising," "including," "having," and the like, are synonymous and used inclusively in a non-limiting manner and do not exclude additional elements, features, acts, operations, etc. Also, the term "or," when used to connect, for example, a list of elements, is used in its inclusive sense (and not in its exclusive sense), so that the term "or" means one, some, or all of the elements in the list.

[0099] Disjunctive language such as the phrase "at least one of X, Y, Z," unless specifically stated otherwise, is understood with context as generally used to indicate that an item, term, etc. may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language should not generally be intended to imply that an embodiment requires the presence of at least one of X, at least one of Y, or at least one of Z, respectively. As used within this disclosure, the term "a" or "one" may include one or more items unless specifically stated otherwise. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless specifically stated otherwise.

Claims

1. A computer implementation method, Using the first device, transmit first data representing a first authentication request for the first user of the first device. Receiving the symmetric encryption key corresponding to the first user described above, Receiving a first token corresponding to the first authentication of the first user, Generating a private signing key, Using the aforementioned symmetric encryption key and the aforementioned private signing key, the encrypted private signing key is determined, Receiving first data representing an unsigned transaction corresponding to a distributed application and the first user, Using the aforementioned symmetric encryption key, the encrypted private signing key is decrypted, and the private signing key is determined. Using the first data and the private signing key, determine a second piece of data representing the signed transaction corresponding to the unsigned transaction. Transmitting the second data and the first token Computer implementation methods, including those mentioned above.

2. Using a second device, transmit third data representing a second authentication request for the first user, Receiving a second token corresponding to the second authentication of the first user, The second device receives the private signing key and The computer implementation method according to claim 1, further comprising:

3. In response to determining the encrypted private signing key, the symmetric encryption key is removed from the first device, After receiving the first data, the symmetric encryption key is received. The computer implementation method according to claim 1, further comprising:

4. The computer implementation method according to claim 1, wherein the private signing key is generated using the first token.

5. The computer implementation method according to claim 1, wherein the private signing key is seeded using a digital certificate.

6. A user device, At least one processor, A memory containing an instruction, wherein the instruction is executed by the at least one processor. Transmitting first data representing a first authentication request for a first user of the user device, Receiving the symmetric encryption key corresponding to the first user described above, Receiving a first token corresponding to the first authentication of the first user, Generating a private signing key, Using the aforementioned symmetric encryption key and the aforementioned private signing key, the encrypted private signing key is determined, Receiving first data representing an unsigned transaction corresponding to a distributed application and the first user, Using the aforementioned symmetric encryption key, the encrypted private signing key is decrypted, and the private signing key is determined. Using the first data and the private signing key, determine a second piece of data representing the signed transaction corresponding to the unsigned transaction. Transmitting the second data and the first token A user device that causes the aforementioned system to perform this action.

7. The at least one memory is When executed by the aforementioned at least one processor, In response to determining the encrypted private signing key, the symmetric encryption key is removed from the user device. After receiving the first data, the symmetric encryption key is received. The user device according to claim 6, further comprising an instruction to cause the system to perform the above.

8. The user device according to claim 6, wherein the private signing key is generated using the first token.

9. The user device according to claim 6, wherein the private signing key is seeded using a digital certificate.

Images