Method and system for single-purpose public keys for public ledgers

Abstract

A method at a computing device in a public ledger cryptographic system, the method comprising: creating a destination string defining transaction parameters for an account within the public ledger cryptographic system; using the destination string to create a private key and an associated public key for an account within the public ledger cryptographic system; and providing the destination string for use in verifying a transaction from the account within the public ledger cryptographic system.

Description

Technical Field

[0001] The present disclosure relates to public ledgers including blockchains, and in particular to transaction security for public ledgers. Background Art

[0002] Banking is often based on a ledger system. A ledger is a record of transactions between accounts. A public ledger makes the ledger public in the sense that all transactions are available to the public. Furthermore, a public ledger system is pseudonymous if the account number is traceable but does not identify an individual by name. As used herein, pseudonymous means that while transactions associated with an account number can be traced, the account number itself does not necessarily have to be associated with a specific person.

[0003] Public ledger cryptocurrencies are digital currencies that use cryptography to sign transactions. In such a system, account numbers can be public keys, and transactions can include digital signatures. Public ledgers can be used by cryptocurrency recipients to confirm that the account holder has sufficient funds in the account before entering into a transaction. This can help avoid double spending by cryptocurrency senders.

[0004] In a public ledger cryptographic system, each account holder typically has a private key, which is used to sign transactions. The private key is typically stored in a module called a digital wallet on a computing device. However, a thief could hack into the device storing the digital wallet and extract the account holder's private signing key. The thief could then transfer the account holder's funds to other accounts.

[0005] An honest receiver does not want to receive stolen funds. In cryptocurrency, each receiver should first check the public ledger to see if the sender has sufficient funds. Checking the public ledger provides an honest receiver with a limited chance to resist some forms of theft and fraud. Specifically, checking the public ledger can allow an honest receiver to trace back where the funds have been flowing. An honest receiver may be able to detect that the cryptocurrency in question has followed a suspicious path. For example, if the funds come from an account that has reported its funds stolen, an honest receiver may refuse to receive the funds and may report the attempted transaction to the authorities.

[0006] However, there are significant problems with this approach. Specifically, an honest recipient cannot avoid receiving funds until the true owner of the funds has detected the stolen digital wallet. Furthermore, an honest recipient cannot verify whether the stranger is the legitimate owner of the funds. Therefore, there are almost no defenses against, for example, fraud-based schemes. This lack of defense undermines the credibility of the entire public ledger. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present disclosure will be better understood with reference to the accompanying drawings, in which:

[0008] Figure 1 is a block diagram of an example computing system that may be used for public ledger encrypted transactions;

[0009] Figure 2 is a process diagram illustrating a process for creating a public key and a private key associated with a message in an elliptic curve digital signature algorithm;

[0010] Figure 3 is a process diagram illustrating a process for verifying that a message is bound to a public key;

[0011] Figure 4 is a process diagram illustrating a general process for creating public and private keys associated with a message;

[0012] Figure 5 is a process diagram illustrating a process for verifying that a message is bound to a public key;

[0013] Figure 6 is a data flow diagram illustrating the use of a destination string to audit transactions in a public ledger cryptographic system; and

[0014] Figure 7 is a block diagram of a simplified computing device that can be used with the methods and systems herein, according to one embodiment. DETAILED DESCRIPTION

[0015] The present disclosure provides a method at a computing device in a public ledger cryptographic system, the method comprising: creating a destination string that defines transaction parameters for an account within the public ledger cryptographic system; using the destination string to create a private key and an associated public key for an account within the public ledger cryptographic system; and providing the destination string for use in verifying a transaction from an account within the public ledger cryptographic system.

[0016] The present disclosure also provides a computing device in a public ledger cryptographic system, the computing device comprising: a processor; and a communication subsystem, wherein the computing device is configured to: create a destination string, the destination string defining transaction parameters for an account within the public ledger cryptographic system; use the destination string to create a private key and an associated public key for an account within the public ledger cryptographic system; and provide the destination string for verifying transactions from an account within the public ledger cryptographic system.

[0017] The present disclosure further provides a computer-readable medium for storing instruction codes, which, when executed by a processor of a computing device in a public ledger cryptographic system, cause the computing device to: create a destination string, the destination string defining transaction parameters for an account within the public ledger cryptographic system; use the destination string to create a private key and an associated public key for an account within the public ledger cryptographic system; and provide the destination string for use in verifying transactions from an account within the public ledger cryptographic system.

[0018] According to the present disclosure, the terms in Table 1 will be used.

[0019]

[0020] Table 1 Terminology

[0021] As provided in Table 1, a public ledger is a publicly visible ledger. An example of a public ledger cryptocurrency is a currency that uses blockchain technology to authenticate the public ledger. This process essentially decentralizes the authority of the public ledger.

[0022] According to an embodiment of the present disclosure, a public account cryptographic system is described. The public account can be used for cryptocurrency, for example. The cryptocurrency used with the embodiments of this document can be, for example, a general currency. However, the present disclosure is not limited to a general currency, and any suitable cryptocurrency can be used.

[0023] Cryptocurrencies can be used in a variety of computing environments. Figure 1 An example computing environment is shown.

[0024] exist Figure 1 In an embodiment of the present invention, the computing device 110 belongs to a user who has funds on a public ledger. In this regard, the computing device 110 may include a processor 112 and a communication subsystem 114, wherein the processor and the communication subsystem cooperate to perform the methods described herein.

[0025] The computing device 110 may further include a memory 116, which may be used to store data or programmable logic. The programmable logic may be executed by the processor 112. In other embodiments, the programmable logic may be provided to the computing device 110 via the communication subsystem 114.

[0026] exist Figure 1 In a computing system of , computing device 110 includes a digital wallet 118, which can store private keys for funds within a public ledger. Specifically, a public key for a user of computing device 110 associated with a private key stored in digital wallet 118 can allow funds to be used with the public ledger. The private key is stored in digital wallet 118, which provides storage of such private keys for security.

[0027] The digital wallet 118 may be any data structure or logical structure used to store private keys and associated data. In some embodiments, the digital wallet 118 is implemented in software and hardware, or may be implemented in specially designed hardware that stores information that allows an individual to conduct e-commerce transactions. In some embodiments, the digital wallet may be provided using a dedicated hardware device such as a hardware security module. In other embodiments, the digital wallet 118 may include a memory dedicated to the digital wallet and may be internal or external to the computing device 110.

[0028] Computing device 110 may communicate, for example, via network 120 .

[0029] In some embodiments, computing device 110 may communicate with certificate authority 130, which may be used to generate and authenticate certificates for the computing device (including, in some cases, certificates for a public ledger).

[0030] Additionally, network 120 may be used for computing device 110 to communicate with a public ledger or blockchain 140 , which may be stored on multiple computers and, in some cases, may be distributed.

[0031] Additionally, in some embodiments, network 120 may be used to communicate with a receiving entity, such as vendor 150. Vendor 150 may include a computing device configured to perform embodiments herein, including communicating with computing device 110 and public ledger / blockchain 140 and verification as described below.

[0032] The vendor 150 may be providing goods or services in exchange for the cryptocurrency associated with the digital wallet 118 .

[0033] However, in some embodiments, computing device 110 may be close to vendor 150 , and in such cases, direct communication between computing device 110 and vendor 150 may be possible.

[0034] As mentioned above, fraud detection is possible to some extent due to the nature of the public ledger. For example, suspicious transactions may be detected from suspicious activity. For example, large transactions, bursts of transactions, purchases from suspicious vendors, or purchases at unusual locations may serve as indicators of fraudulent transactions. The credit card industry already uses such measures to block suspicious credit card transactions, or to request additional information before allowing a suspicious transaction to move forward.

[0035] In currency, the suggested response to a suspected theft of a private key from a digital wallet is to first create a new account with a new public key, and then transfer the remaining funds (if any) to the new account. However, by this time it may be too late, and the attacker may have already transferred the funds to another account.

[0036] The currency itself does not provide any means of publishing a report of theft. There is currently no mechanism within the public ledger to mark stolen currency. However, this can be done outside the public ledger mechanism (such as on social media), for example by contacting government authorities. Once such a report has been made, the path of the stolen funds through the ledger can be traced.

[0037] In a public ledger, honest vendors can check for suspicious transactions or use theft reports to detect fraudulent transactions. Honest vendors can therefore refuse to enter new transactions that they believe may involve stolen funds or be fraudulent in other ways. Honest vendors can even review or trace back past transactions to measure the percentage of suspicious or fraudulent funds in an account.

[0038] As a first step in a thief's efforts to circumvent fraud detection systems, the thief might transfer a large amount of the victim's funds into his or her own account. The thief would then attempt to spend the money before the victim files a theft report, which would mark the funds in the thief's account as stolen. Fraud detection systems can therefore be designed to be suspicious of premature spending of funds after a large transfer.

[0039] The thief may also attempt to make many small transfers to multiple accounts in a short period of time. This type of activity may again be flagged as suspicious.

[0040] In cases of high-value theft or fraud, authorities may attempt to physically arrest the person spending the funds, for example by offering to conduct a private transaction with the thief.

[0041] However, in all of these cases, prior knowledge of the transaction is required, and in some cases, knowledge that funds were stolen.

[0042] Thus, according to embodiments of the present disclosure described below, a concept entitled "Generate Proof" may be used with a public key to provide a "Purpose String" for transaction verification.

[0043] Generating a proof allows a message to be bound to a public key. The public key can then be verified against the message to ensure that the public key is associated with the message. This is described, for example, in U.S. Patent No. 9,240,884 issued to Brown on January 19, 2016.

[0044] Specifically, a generation proof is used to generate a public key with an attached message. Typically, with a generation proof, a message is bound to the public key when the public key is generated. Anyone can verify the binding of the message to the public key.

[0045] Furthermore, the binding is unique in that it is impossible to bind two different messages to a public key. Even a malicious entity that generates private and public keys cannot create two different messages bound to the same public key.

[0046] A public key with a generation proof message can be used like any public key and has no other restrictions other than being bound to a single generation proof message. For example, a generation proof public key can be used for digital signatures and for key exchange, or for any other kind of public key cryptography.

[0047] In the above, when referring to binding, the generation proof allows binding each public key to a message. However, this does not mean a one-to-one binding. A message can be bound to many different public keys.

[0048] As explained below, the generated proof can be authenticated or unauthenticated.

[0049] In an unauthenticated proof of generation, the bound message is not authenticated. Specifically, there is nothing to prevent someone from creating another public key bound to the same message.

[0050] In an authenticated proof of generation, the bound message is authenticated in some way. For example, the bound message may contain a digital signature of a certificate authority or some other trusted party. For example, for implicit certificates as described in the Standard for Efficient Cryptography 4 (SEC 4), the proof of generation is authenticated due to the involvement of a certificate authority.

[0051] If used with an embodiment of the present disclosure, the public key can be reconstructed from an implicit certificate. In addition, anyone can create an implicit certificate, and the public key can be reconstructed from the implicit certificate. However, the only way that some people may know the private key for the reconstructed public key is if they participate in the creation of a public key / private key pair with a certificate authority. Therefore, in order for the implicit certificate to provide comprehensive security including the generation of proofs, the owner of the reconstructed public key must prove in some way that he has the corresponding private key. The possession proof is usually confirmed by signing a message or decrypting a ciphertext. In the context of the generation of proofs, the generation of proofs is not completed until the possession proof is provided. Until the possession proof, security is considered implicit. This means that even before the possession proof is received, it is usually relatively safe to use an implicit certificate, because if the implicit certificate is forged, it will be useless using an unknown private key. Specifically, at some point in the transaction, it will be necessary to use the private key as a possession proof, and therefore the implicit certificate can be used before the possession proof, because the forged certificate will eventually be detected.

[0052] In the context of public ledger cryptocurrencies, one of the main ways public keys are used is to verify signatures, which provides proof of possession. Therefore, according to the embodiments described below, the stage of implicit security will not be bypassed because proof of possession can still be used with the methods and systems described herein.

[0053] For example, now refer to Figure 2 , Figure 2 A method for generating public and private keys using a message m in an Elliptic Curve Digital Signature Algorithm (ECDSA) is shown.

[0054] Figure 2 The process starts at block 210 and proceeds to block 212 where a message is selected. As will be appreciated by those skilled in the art, the message can be anything. Specifically, according to the embodiments described below, the message can be a purpose string indicating the purpose of the cryptocurrency account.

[0055] The process then proceeds to block 214 where a message digest e is calculated by using a hash function on the message m. In this case, the function hash is a cryptographic hash function that provides an integer result.

[0056] At block 216, the communicant may then compute the private key from the message digest e using the formula d = {sk - e) / r mod n. In this case, s is an integer in the interval [0, n - 1] and is preferably random. The value k is a randomly selected integer in the interval [0, n - 1]. The value n is the size of the field for the cipher. The value r is an integer value corresponding to the elliptic curve point R, where R is referred to as the signing short-term public key and k is referred to as the short-term private key.

[0057] Figure 2 The process then proceeds to block 218 where the public key Q is calculated using the formula Q=dG, where G is a point of order n on the elliptic curve.

[0058] In this way, the public key Q and the private key d are associated with the message m. Such public and private keys can then be used in a public ledger cryptography system.

[0059] Upon receiving the public key, the computing device can verify that the public key was generated based on the message m. Figure 3 .exist Figure 3 In the embodiment of , the process starts at block 310 and proceeds to block 312 where the authentication computing device receives the public key Q and the message m.

[0060] The process then proceeds to block 314. At block 314, the verifier first computes the elliptic curve point R' = (1 / s mod n)(eG + rQ) as part of the ECDSA verification process.

[0061] The verifier also needs to know how the signature short-term public key R is converted to an integer value r. This may involve knowing a salt value A and a hash function or other function used to compute r. For example, if r = Flash(A||R||A||R||...||A||R), then r' can be calculated as r' = Flash(A||R'||A||R'||---1|A||R').

[0062] The verifier may then compare r' and r at block 316, and if the two match, this indicates that the public key was generated using message m.

[0063] The process then continues to block 320 and ends.

[0064] In another embodiment, if Figure 4 As shown, a more general method is provided without using elliptic curve cryptography. Specifically, Figure 4 The process of starts at block 410 and proceeds to block 412 where an integer value k is selected. The value k is an integer in the range [0, n-1].

[0065] The process then proceeds to block 414 where a seed public key R is generated using the formula R = kG, where G is again an nth order point on the curve.

[0066] From block 414, at block 416, the message digest f is calculated as f=SHA-1{m,R).

[0067] From block 416, the process proceeds to block 418 where a private key d = kf is calculated.

[0068] The process then proceeds to block 420 where the public key Q = fR is calculated.

[0069] The process then proceeds to block 430 and ends.

[0070] Such public and private keys can then be used in a public ledger cryptography system.

[0071] Validators can use Figure 5 The process is used to verify whether the public key is bound to the message m. Specifically, Figure 5 The process begins at block 510 and proceeds to block 512 where the verifier receives a hash index triplet (m, R, Q).

[0072] The process then proceeds to block 514 where a message digest I = SHA-1 (m, R) is calculated.

[0073] The process then proceeds to block 516 where a value T is calculated as T = fR.

[0074] The process proceeds to block 518 where the verifier may check that Q = T. If so, the public key is bound to the message.

[0075] The process then proceeds to block 520 and ends.

[0076] Utilizing this concept, the following embodiments include a "purpose string" that is used as part of a message to generate a public key. Specifically, the purpose string identifies the purpose of an account within a public ledger.

[0077] In some cases, an honest recipient of funds can request the destination string from the alleged account holder. In other cases, the destination string can be provided voluntarily by the alleged account holder. In other cases, the destination string can be provided through a public database or through the ledger itself.

[0078] An honest recipient will then attempt to honor the purpose string, as well as attempt to ensure that the account is only used for the specified purpose.

[0079] This can deter or prevent a thief who has stolen the private keys to an account from using the funds for the wrong purposes.

[0080] Therefore, the purpose string is used as a prevention against fraud and is set when the account is created, before any fraud occurs.

[0081] Therefore, according to an embodiment of the present disclosure, a generated proof is used to provide a purpose for an account. The purpose can then be verified during transactions on the public ledger.

[0082] As mentioned above, in the generation proof, once the public key is generated, it is bound to a unique message. The binding can be verified by anyone. In all other respects, the public key is normal and as used in cryptocurrency, it can be used to generate digital signatures for any number of messages.

[0083] Therefore, according to embodiments herein, the message to which the public key is bound is reassigned as a destination string.

[0084] The destination string can contain any data. The specific content of the destination string will be discussed below.

[0085] In the embodiments herein, a process is provided on how to use a destination string in the context of cryptocurrency. When the so-called public key owner Alice uses her public key with another honest party Bob, the other party Bob can request to see the destination string. Alice can then provide the destination string, and Bob can check the destination string. Bob honors the destination string, ensuring that the transaction complies with the details contained in the destination string.

[0086] If the alleged party Alice fails to supply the destination string, or the alleged Alice or the nature of the transaction does not match the destination string in some way, Bob can refuse to enter into the transaction. In such a refusal of the transaction, Alice cannot obtain any goods or services from Bob.

[0087] If an adversary, Eva, has stolen Alice's private key and is attempting to fraudulently impersonate Alice, Bob may have thwarted Eva's attempt to profit from the theft of Alice's private key.

[0088] A key property of the destination string is that each public key can have at most one destination string. This property is a consequence of the proof generation method described above. It is infeasible to generate the same public key using two different destination strings.

[0089] This article explains several properties of the destination string. Specifically:

[0090] The destination string does not reveal the private key.

[0091] The public key does not reveal the destination string.

[0092] The destination string does not need to be secret.

[0093] The destination string can be kept private between Alice and Bob if desired.

[0094] The destination string may be kept public, such as in a public database, perhaps integrated into a public ledger.

[0095] The public key can be used without a purpose string.

[0096] A dishonest recipient of a destination string may choose to ignore its purpose, or not request a destination string at all.

[0097] The destination string (if derived from an unauthenticated proof-of-generation method) can be common to many different public keys, thus not establishing the uniqueness of the public key.

[0098] • The purpose string does provide a way to identify a unique purpose for a given public key.

[0099] In cryptocurrency, an honest public key owner can create his public key using an honest purpose string. An honest recipient can request a purpose string as needed and only accept a transaction with the public key if the transaction matches what is in the purpose string.

[0100] Therefore, now refer to Figure 6 .exist Figure 6 In an embodiment of the present invention, a client computing device 610 having a digital wallet associated with a public ledger cryptocurrency may attempt to purchase a good or service from a vendor 612.

[0101] In this regard, the client computing device 610 may attempt a transaction using a public ledger, as shown by message 620 between the client and the supplier 612. The message 620 may be sent, for example, over a network, or may be based on short-range communications between the client computing device 610 and the computing devices of the supplier 612.

[0102] As shown at block 622, the vendor 612 may then verify that the customer associated with the computing device 610 has sufficient funds. The verification at block 622 may query the ledger to ensure that sufficient funds are associated with the customer 610.

[0103] Assuming sufficient funds are available, the computing device of vendor 612 may then request a purpose string for the account, as indicated by message 630 . Figure 4 Message 630 in the embodiment of is sent to client computing device 610.

[0104] In alternative embodiments, the computing device of the supplier 612 may request the destination string from a ledger, rather than requesting the destination string from the client computing device 610. In other embodiments, the computing device of the supplier 612 may request the destination string from other databases that may contain such destination strings.

[0105] In response to the request for the destination string in message 630, the destination string may be provided to the computing device of provider 612 in message 632. Figure 6 In the embodiment of FIG. 6 , message 632 originates from client computing device 610. However, if the request for destination string message 630 is directed to a different computing device, message 632 may come from the different computing device.

[0106] As shown at block 640, the computing device of the supplier 612 may then verify the public key associated with the customer. Verification may be performed, for example, according to the above Figure 3 or Figure 5 This ensures that the public key is associated with the destination string provided in message 632.

[0107] If the public key is verified to be associated with the destination string, the computing device of vendor 612 may attempt to verify the transaction at block 650. Verifying the transaction means that the transaction falls within the boundaries of the destination string.

[0108] The vendor may then allow or deny the transaction, as shown in message 660. In some embodiments, the allowing or denying may be done automatically at the computing device. In other embodiments, the allowing or denying may be based on information presented at the computing device, based on user input to the computing device.

[0109] As will be appreciated by those skilled in the art, if the public key is not associated with the destination string provided in message 632, message 660 may be sent immediately after block 640 to deny the transaction.

[0110] As indicated above with respect to block 650, the transaction may be authenticated against the destination string. There are various options for such authentication.

[0111] In the first option, various transaction restrictions can be placed in the purpose string. For example, in one embodiment, the purpose string can contain information that limits the transaction types allowed by the account.

[0112] For example, when setting up an account, the account holder can limit the maximum amount or value of a single transfer. The holder can also limit the total number of transfers within a given period (such as per day).

[0113] An honest recipient can therefore check the destination string and comply with these restrictions at block 650. Specifically, the computing device of supplier 612 can refer to the public ledger to see how many transactions have occurred from such an account, and see if the current transaction will exceed the transaction limit within the destination string.

[0114] In other cases, the computing device of the provider 612 may verify that the proposed transfer amount is less than the value in the destination string.

[0115] In some cases, the destination string may have a specific format that will support parsing of the destination string by a computing device associated with vendor 612, thereby enabling the computing device to perform validation at block 640. In other cases, natural language processing may be used to find restrictions within the destination string.

[0116] Purpose strings can therefore provide a way to add transaction restrictions to public ledger cryptocurrencies.

[0117] The purpose string can also be used to restrict the types of items that the funds can be used to purchase. For example, the funds may be limited to being used to purchase groceries. Such restrictions make it less efficient for the thief to process the stolen funds because the stolen funds will have to be traded for items that are more difficult to resell, are larger in size, and have a short shelf life, thus quickly losing value.

[0118] Again, the type of goods or services for which transactions are restricted may have standardized text to allow parsing of such destination strings in some cases. In other cases, natural language processing may be utilized.

[0119] In another example, the purpose string may allow the transaction only if the account holder is physically present and not online.

[0120] In other cases, the purpose string may limit transactions during a specific time window. For example, transactions may be limited to between 7 a.m. and 9 p.m. Eastern Standard Time. Thus, if an attempt is made to purchase an item from a vendor outside of the specified time window, the transaction may be rejected.

[0121] In another embodiment, the purpose string may contain geographic boundaries within which the transaction may occur. Thus, funds may only be used within such a geographic region (such as a city, province, state, or country).

[0122] In other cases, the transaction may need to be performed in a public place. Thus, a positioning system associated with the computing device of the vendor 612 can determine whether the device is in a public space or a private space and allow or deny the transaction accordingly.

[0123] Other options are possible.

[0124] Furthermore, in some cases, the purpose string may be limited to only one of the above purposes. In other cases, the purpose string may contain multiple restrictions. Thus, the purpose string may indicate that a transaction limit of $1000 per transaction can only occur between 7am and 9pm Eastern Standard Time. The number or type of purposes is not limited to the purpose string.

[0125] In another embodiment, the destination string may contain an identifier for the customer. Specifically, in this embodiment, the destination string includes data that can be used to identify the real account holder. The data can be in a form that allows an honest recipient to verify the identity.

[0126] Although in many cryptocurrencies, account holders are pseudonymous, or even anonymous, the destination string with an identifier partially restores the pseudonymous property. The impairment of pseudonymity has some disadvantages, such as weaker privacy, which can be compensated by the defense or inhibition of digital wallet theft.

[0127] For example, in one case, the purpose string may provide the name of the real account holder in text form. In this case, the honest supplier may have some way to verify the name of the person trying to perform the transaction. In some cases, the supplier may know the account holder, for example, through a pre-existing relationship. In other cases, the honest recipient or supplier may request to see other authenticated forms of proof of identity, such as a driver's license or passport. The honest recipient may check the name on the official document to see if it matches the name in the purpose string. The strength of the proof of identity is related to the strength of the official document or the existing relationship.

[0128] In yet another embodiment, the destination string may be data that provides biometric data, such as an image of the real account holder. In this case, the honest recipient may compare the image in the destination string with an image of the alleged account holder. This may be particularly useful when completing transactions in person or using a webcam, for example.

[0129] In other embodiments, in addition to images, other identification and difficult-to-forge information may be used. This may include, for example, biometric data such as fingerprints, voice patterns, etc.

[0130] Similarly, the destination string may contain an image of the account holder's driver's license. This may include an image of the actual account holder, the holder's handwritten signature, and other information. This information can then be matched against the actual driver's license as well as a direct image of the alleged account holder and the alleged account holder's signature.

[0131] In yet another embodiment, if the destination string is authenticated by a certificate authority, it may be suitable for online transactions. For example, the underlying method of generating proof may be an implicit certificate, or the destination may contain a message similar to a traditional public key certificate. As always, the certificate authority verifies the identity of the real account holder at account creation. However, in the event that the thief has stolen the private key, the purely digital information normally used for identity verification may have been compromised. To address this threat, in an online setting, one may be able to simulate a retail environment, such as providing a video connection between an honest recipient and the alleged account holder. In this video connection, the honest recipient can use the various image-based methods described above to attempt to verify identity.

[0132] Honest recipients may verify entities to varying degrees. In some cases, the scrutiny of the alleged account holder may be proportional to the risk level of the transaction.

[0133] Therefore, according to the above embodiment, one or more purpose strings can be embedded in the message used to generate the public key. The use of such a purpose string can then allow the recipient to screen the transaction before allowing the transaction to proceed.

[0134] Those skilled in the art will appreciate that the use of a destination string in generating public and private keys associated with public ledger cryptography does not restrict other cryptographic functions for such keys or the ledger. For example, the use of a certificate authority to check whether a key belongs to the owner is not altered by the use of a destination string. Similarly, public key infrastructure (PKI) functions for key exchange are not affected by the use of a destination string.

[0135] The module and user equipment and device for executing the above method can be any electronic device or network node. Such computing device or network node can include any type of computing device, including but not limited to mobile devices such as smart phones or cellular phones. Examples can also include fixed or mobile user equipment, such as Internet of Things (IoT) devices, endpoints, home automation devices, medical equipment in hospitals or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or devices for vehicles, fixed electronic devices, etc. Vehicles include motor vehicles (e.g., cars, cars, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aerial vehicle systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, spacecraft, space capsules, space stations, satellites, etc.), watercraft (e.g., ships, ships, hovercraft, submarines, etc.), rail vehicles (e.g., trains and trams, etc.) and any combination of the above, whether currently existing or other types of vehicles that appear later.

[0136] For example, the computing device may be associated with the owner of a public ledger account or with the recipient of a transaction. Figure 7 A simplified diagram of a computing device is shown.

[0137] exist Figure 7 In the embodiment, the device 710 includes a processor 720 and a communication subsystem 730, wherein the processor 720 and the communication subsystem 730 cooperate to perform the method of the above embodiment. In some embodiments, the communication subsystem 720 may include, for example, multiple subsystems for different radio technologies.

[0138] Processor 720 is configured to execute programmable logic, which may be stored on device 710 along with data and may be used to execute programmable logic. Figure 7 In the example of , memory 740 is shown. Memory 740 can be any tangible, non-transitory computer-readable storage medium. The computer-readable storage medium can be a tangible or transient / non-transitory medium, such as an optical (e.g., CD, DVD, etc.) medium, a magnetic medium (e.g., a tape), a flash drive, a hard drive, or other memory known in the art.

[0139] As an alternative or in addition to memory 740 , device 710 may access data or programmable logic from an external storage medium, such as through communications subsystem 730 .

[0140] The communication subsystem 730 allows the device 710 to communicate with other devices or network elements, and may vary based on the type of communication being performed. In addition, the communication subsystem 730 may include a variety of communication technologies, including any wired or wireless communication technology.

[0141] In one embodiment, communication between the various elements of device 710 may be through internal bus 760. However, other forms of communication are possible.

[0142] The embodiments described herein are examples of structures, systems or methods with elements corresponding to the elements of the technology of the present application. This written description can enable those skilled in the art to manufacture and use embodiments with alternative elements corresponding equally to the elements of the technology of the present application. Therefore, the intended scope of the technology of the present application includes other structures, systems or methods that are not different from the technology of the present application as described herein, and further includes other structures, systems or methods that are not substantially different from the technology of the present application as described herein.

[0143] Although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a continuous order, or that all of the operations shown be performed to achieve the desired result. In some cases, multitasking and parallel processing may be employed. In addition, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a signal software product or packaged as multiple software products.

[0144] In addition, the techniques, systems, subsystems, and methods described and illustrated in a discrete or separate manner in various implementations may be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating electrically, mechanically, or otherwise, through some interface, device, or intermediate component. Other examples of changes, substitutions, and alterations may be determined and made by those skilled in the art.

[0145] Although the above detailed description has shown, described and pointed out the basic novel features of the present disclosure as applied to various implementations, it will be understood that various omissions, substitutions and changes in the form and details of the illustrated system may be made by those skilled in the art. In addition, the order of the method steps is not implied by the order in which they appear in the claims.

[0146] When messages are sent to or from electronic devices, such operations may not be immediate or directly from a server. They can be delivered synchronously or asynchronously from a server or other computing system infrastructure supporting the device / method / system described herein. The aforementioned steps may include synchronous / asynchronous communications to / from the device / infrastructure in whole or in part. In addition, communications from electronic devices can be to one or more endpoints on a network. These endpoints can be served by servers, distributed computing systems, streaming processors, etc. Content delivery networks (CDNs) can also provide communications to electronic devices. For example, in addition to typical server responses, a server can also provide or indicate data for a content delivery network (CDN) to wait for the electronic device to download at a later time, such as subsequent activities of the electronic device. Therefore, data can be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) that is part of or separate from the system.

[0147] In general, the storage medium may include any or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium, including tape; optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system that may have multiple nodes. Such one or more computer-readable or machine-readable storage media are considered to be part of an article of manufacture (or article of manufacture). An article of manufacture or article of manufacture may refer to any manufactured single component or multiple components. One or more storage media may be located in the machine that runs the machine-readable instructions, or may be located at a remote site, from which the machine-readable instructions may be downloaded over a network for execution.

[0148] In the foregoing description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations to the details discussed above. The appended claims are intended to cover these modifications and variations.

Claims

1. A method at a computing device in a public ledger cryptographic system, the method comprising: Creating a destination string, the destination string defining transaction parameters for an account within the public ledger cryptographic system; Using the destination string to create a private key and an associated public key for the account within the public ledger cryptographic system, wherein the public key is uniquely bound to the destination string; receiving a request for the destination string from a recipient of a transaction from the account within the public ledger cryptographic system; as well as The destination string is provided to the recipient of the transaction for verification of proof of generation of the public key during the transaction, wherein the verification of proof of generation of the public key includes proof that the public key was generated based on the destination string.

2. The method of claim 1, wherein the purpose string defines at least one parameter selected from the group consisting of: transaction value restrictions, transaction frequency restrictions, transaction geographic restrictions, transaction time period restrictions, transaction location restrictions, restrictions on the location of the account holder of the account within the public ledger cryptographic system relative to the recipient during the transaction, and restrictions on the goods or services allowed in the transaction.

3. The method of claim 1 , wherein the destination string provides an identifier for an account holder of the account within the public ledger cryptographic system. The method of claim 3 , wherein the identifier is biometric data for the account holder. The method of claim 3 , wherein the identifier is the name of the account holder.

6. The method of claim 3, wherein the identifier is an image of a document for the account holder. The method of claim 1 , wherein the providing is performed upon account creation utilizing a network element.

8. The method of claim 7, wherein the network element is associated with the public ledger cryptographic system.

9. A computing device in a public ledger cryptographic system, the computing device comprising: processor; as well as Communication subsystem, The computing device is configured to: Creating a destination string, the destination string defining transaction parameters for an account within the public ledger cryptographic system; Using the destination string to create a private key and an associated public key for the account within the public ledger cryptographic system, wherein the public key is uniquely bound to the destination string; receiving a request for the destination string from a recipient of a transaction from the account within the public ledger cryptographic system; as well as The destination string is provided to the recipient of the transaction for verification of proof of generation of the public key during the transaction, wherein the verification of proof of generation of the public key includes proof that the public key was generated based on the destination string.

10. The computing device of claim 9, wherein the purpose string defines at least one parameter selected from the group consisting of: transaction value restrictions, transaction frequency restrictions, transaction geographic restrictions, transaction time period restrictions, transaction location restrictions, restrictions on the location of an account holder of the account within the public ledger cryptographic system relative to a recipient during the transaction, and restrictions on goods or services permitted in a transaction.

11. The computing device of claim 9, wherein the destination string provides an identifier for an account holder of the account within the public ledger cryptographic system.

12. The computing device of claim 11, wherein the identifier is biometric data for the account holder.

13. The computing device of claim 11, wherein the identifier is a name of the account holder.

14. The computing device of claim 11, wherein the identifier is an image of a document for the account holder.

15. The computing device of claim 9, wherein the computing device is configured to provide upon account creation with a network element.

16. The computing device of claim 15, wherein the network element is associated with the public ledger cryptographic system.

17. A computer-readable medium for storing instruction codes, which, when executed by a processor of a computing device in a public ledger cryptographic system, cause the computing device to: Creating a destination string, the destination string defining transaction parameters for an account within the public ledger cryptographic system; Using the destination string to create a private key and an associated public key for the account within the public ledger cryptographic system, wherein the public key is uniquely bound to the destination string; receiving a request for the destination string from a recipient of a transaction from the account within the public ledger cryptographic system; as well as The destination string is provided to the recipient of the transaction for verification of proof of generation of the public key during the transaction, wherein the verification of proof of generation of the public key includes proof that the public key was generated based on the destination string.

Images