Methods and arrangements for allowing user devices to access secrets.

Abstract

The arrangement comprises a communication system and an account management system functionally coupled thereto. The account management system uses user-specific random salts (URT) as follows: SALT The account management system generates a first digital value called (URT) and sends it to the user device. The account management system uses at least the user's first public key (URT) received in the registration request. PK The system responds to the subsequent registration request (311) from the user device by generating a further registration request (312) including (312) and sending it to a trusted central arrangement. The subsequent registration response (316) from the trusted central arrangement includes the user's second public key (UAT). PK ) includes. The user device has at least the user's second public key (UAT). PK A further registration response (319) including ) is sent.

Description

[Technical Field]

[0001] This invention generally relates to the technology of security required when using digital services in communication between digital devices and their users. In particular, this invention relates to the provision of secure digital services that can be used by users in a highly flexible manner, even if the user does not have a user device as needed. [Background technology]

[0002] Security in digital communications encompasses several aspects, including confidentiality (only authorized parties can access the information), authentication (communicating parties must know for sure who they are communicating with), integrity (information fragments have not been improperly altered), and non-repudiation (a party cannot deny having transmitted a particular information fragment). All such aspects of security must ultimately be built upon a secret digital information fragment (usually simply called a secret). To provide sufficient security against attempts at decryption, the secret must be derived from randomness.

[0003] The primary application area of ​​digital services is digitally managed commercial transactions. Cash payments have already been largely replaced by card payments, which rely on user-specific digital information stored on smart cards, and mobile payments, where mobile digital devices provide both the means of storing digital information and the communication necessary to set up and execute transactions. However, there is still a need for secure, easy-to-apply, and scalable methods and arrangements for digitally managed transactions that are applicable to a wide range of commercial environments.

[0004] Similar to commercial applications, there are numerous applications in which service providers deliver other types of digital services to users over long-distance network communications, and these are subject to similar security and confidentiality requirements. Examples of such other digital services include, but are not limited to, public services provided by civil servants and government agencies, healthcare services, and membership services provided by non-profit private organizations.

[0005] Patent Document 1 discloses a method and arrangement that may be used to establish and maintain a user's digital identity. Patent Document 2 discloses a method and system that may be used to execute a transaction belonging to a multi-signature agreement. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] European Patent Application Publication No. 4231583 [Patent Document 2] U.S. Patent Application Publication No. 2022 / 0116214 [Overview of the project]

[0007] This summary is provided to introduce, in a simplified form, a selection of concepts that will be further described below in the detailed explanation. This summary is not intended to identify any important or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] The objective is to provide methods and arrangements for ensuring secure digital communication between parties in digitally managed transactions.

[0009] According to a first aspect, an arrangement is provided for setting up and maintaining user accounts. This arrangement includes a communication system configured to set up and maintain communication between a user device and at least one trusted central arrangement. Functionally coupled to the communication system is an account management system configured to generate a first digital value, hereafter referred to as a user-specific random salt, using a random number generator, and provide it to the communication system for further transmission to the user device. Subsequent registration requests from the user device include a second digital value, hereafter referred to as the user's first public key. The arrangement responds by generating and providing to the communication system a further registration request, including at least the user's first public key, for further transmission to the trusted central arrangement. The arrangement responds to a subsequent registration response from the trusted central arrangement, the registration response including a third digital value, hereafter referred to as the user's second public key, by generating and providing to the communication system a further registration response, including at least the user's second public key, for further transmission to the user device.

[0010] According to one embodiment, the account management system is configured to also include the user-specific random salt in the further registration response. This provides at least the advantage that the provided information can be used in a wide variety of ways later on, without requiring a specific user device for such use.

[0011] According to one embodiment, the account management system is configured to format the further registration response in the form of a graphically representable code. This provides the advantage of making the provided information particularly versatile.

[0012] According to one embodiment, the account management system is configured to maintain accounts for digital assets associated with the user device. The system may then respond to a transaction request received from the trusted central arrangement after the registration response by attempting to decrypt at least a portion of the transaction request with the user's first public key. Only if the decryption attempt is successful may the system execute the transaction requested in the transaction request on the digital asset account. This provides the benefit of at least additional security against attempts by unauthorized parties.

[0013] According to one embodiment, the account management system is configured to execute the transaction only if the transaction request is the first transaction request for which the decryption attempt using the user's first public key is successful. This provides the benefit of additional security against attempts by unauthorized parties.

[0014] According to one embodiment, the account management system is configured to attempt to decrypt at least a portion of the transaction request using the user's second public key. The transaction may be executed only if the decryption attempt using the user's second public key is successful. This provides the benefit of additional security against attempts by unauthorized parties.

[0015] A second aspect provides a method for setting up and maintaining user accounts. The method includes the steps of: generating a first digital value, hereafter referred to as a user-specific random salt, using a random number generator; and transmitting the user-specific random salt to a user device. The method includes the step of responding to a subsequent registration request from the user device, wherein the registration request includes a second digital value, hereafter referred to as the user's first public key, by generating a further registration request, which includes at least the user's first public key, and transmitting it to a trusted central arrangement. The method includes the step of responding to a subsequent registration response from the trusted central arrangement, wherein the registration response includes a third digital value, hereafter referred to as the user's second public key, by generating a further registration response, which includes at least the user's second public key, and transmitting it to the user device.

[0016] According to one embodiment, generating the further registration response includes including the user-specific random salt in the further registration response. This provides at least the advantage that the provided information can be used in a wide variety of ways later on, without requiring a specific user device for such use.

[0017] According to one embodiment, the method includes the step of formatting the further registration response in the form of a graphically representable code. This provides the benefit of at least additional security against attempts by unauthorized parties.

[0018] According to one embodiment, the method includes the step of maintaining an account for a digital asset associated with the user device. The method may then include the step of responding to a transaction request received from the trusted central arrangement after the registration response by attempting to decrypt at least a portion of the transaction request with the user's first public key. The method may also include the step of executing the transaction requested in the transaction request on the digital asset account only if the decryption attempt is successful. This provides the benefit of at least additional security against attempts by unauthorized parties.

[0019] According to one embodiment, the method includes the step of executing the transaction only if the transaction request is the first transaction request for which the decryption attempt using the user's first public key was successful. This provides the benefit of additional security against attempts by unauthorized parties.

[0020] According to one embodiment, the method includes the steps of attempting to decrypt at least a portion of the transaction request with the user's second public key, and executing the transaction only if the decryption attempt using the user's second public key is successful. This provides the benefit of additional security against attempts by unauthorized parties.

[0021] According to a third aspect, a computer program product is provided comprising one or more sets of machine-readable instructions that, when executed by one or more processors, cause an implementation of the method according to any of the features given above. [Brief explanation of the drawing]

[0022] [Figure 1] The steps of the method are shown at a very abstract level. [Figure 2] The steps of the method are shown at a very abstract level. [Figure 3]The steps of the method are shown below. [Figure 4] This example demonstrates how to generate a key from stored and memorized information. [Figure 5] Here is another example of generating a key from stored and memorized information. [Figure 6] The steps of the method are shown below. [Figure 7] The steps of the method are shown below. [Figure 8] The steps of the method are shown below. [Modes for carrying out the invention]

[0023] The following description refers to the accompanying drawings, which form part of this disclosure and illustrate, for illustrative purposes, specific embodiments in which this disclosure may be arranged. It should be understood that other embodiments may be utilized and structural or logical modifications may be implemented without departing from the scope of this disclosure. Therefore, the following detailed description should not be constrained, as the scope of this disclosure is defined by the accompanying claims.

[0024] For example, it should be understood that disclosures relating to a described method may also apply to a corresponding device or system configured to perform the method, and vice versa. For example, if a particular method step is described, the corresponding device may include a unit for performing the described method step, even if such a unit is not explicitly described or illustrated in the figures. On the other hand, if a particular device is described based on a functional unit, the corresponding method may include steps for performing the described function, even if such steps are not explicitly described or illustrated in the figures. Furthermore, it should be understood that features of the various exemplary embodiments described herein may be combined with each other unless otherwise specified.

[0025] In the following description, the terms “trusted central arrangement,” “service provider,” and “user device” are used. Of these terms, “trusted central arrangement” refers to an arrangement of computer devices or interconnected computer devices that together constitute a trusted computing environment. This means that the configuration and operation of the trusted central arrangement are known and verifiable by parties that the parties consider trustworthy. Examples of trusted central arrangements include, but are not limited to, computer systems of banks, government agencies, or professional commercial enterprises that provide this type of service to other companies. Other terms that may be used as alternatives or additions to “trusted central arrangement” include, at least, “trust provider,” “trusted environment,” “trusted server,” and “wallet provider.”

[0026] The concept of a service provider refers to a commercial operator, a non-commercial organization, a government agency, or any other party interested in establishing and maintaining long-term customer relationships with a large number of custom users. The term “customer” does not necessarily mean that the customer relationship must be intended to bring commercial benefits or other advantages to the service provider. As an example of the last point, residents of a city may be “customers” of the city administration.

[0027] A service provider's customers may be individual users, user groups, associations, corporations, public institutions, or any combination thereof. Often, a service provider may run its own computer devices (or an arrangement of interconnected computer devices) that together constitute a trusted computing environment. However, for the purposes of the following explanation, we will assume that the roles of the service provider and the trusted central arrangement can be separated. However, it is also possible for the same party to assume both roles. Even in such cases, from an administrative standpoint, it may be advantageous to implement the two roles using different computer devices within the trusted computing environment of the party in question.

[0028] A user device does not necessarily have to be a single device and / or not necessarily have to be used by a single human user, but the most exemplary examples of a user device as used herein are a user's smartphone, tablet, or laptop computer. As an example of the broader applicability of this term, a user device may also refer to a personal digital assistant (PDA) authorized by the actual user to perform operations on behalf of the user and for its benefit. Against the backlash against the outdated use of this term, in the sense used herein, a personal digital assistant may also refer to many types of implementations ranging from pure software to various embedded solutions involving both software and hardware, rather than (not necessarily) so-called PDA devices (i.e., specialized palm-sized tablet computers).

[0029] Generally speaking, a user device is a device to be used, among other things, for secure, cryptographically protected digital communication with one or more trusted central arrangements, or an arrangement of interconnected devices and / or software. The arrangement and operation of the user device as intended herein is not known or verifiable, as is the arrangement and operation of the trusted central arrangements, but for said digital communication (and services that depend on said digital communication), it may be assumed that the user device uses installed and / or downloadable application programs of known kinds.

[0030] A special case of a user device may be a merchant or a merchant's device. This special case will be described in more detail below. To also emphasize the possibility of non-commercial use of the present invention, "merchant" may also be a public servant employed by a government or urban administrative agency, etc.

[0031] Figure 1 illustrates the steps of the method at a very abstract level. The parties involved are a trust provider, a service provider, a merchant, and a user. For illustrative purposes, the service provider may be a bank, the merchant may be a shop owner, and the user may be an individual visiting a store to purchase a product. In the alternative example above, the service provider may be a government agency, and the user may be a citizen visiting a public official. In such cases, the specific embodiments described herein may be useful in enabling users who cannot carry and use smartphones, etc., or who do not intend to use them, to access public digital services.

[0032] Steps 101 and 102 in Figure 1 are preparatory steps for setting the conditions under which a user may make payments using a digital wallet and participate in the use of public services that utilize digital channels.

[0033] In step 101, the user approaches the service provider and registers as a user of the digital wallet and / or other types of digital services. In step 102, the user, service provider, and trust provider cooperate to ensure the secure use of the digital wallet and / or other types of digital services.

[0034] For the purposes of this explanation, a digital wallet is a cloud-based service that allows users to store some money (or other digital assets), for example, to make payments with the stored money, or to use the digital assets in other ways, without having to carry any direct physical representation of the money or assets. As can be seen from the diagram, a digital wallet corresponds to a physical wallet and / or any physical objects traditionally stored in a wallet, but the difference is that in order to use a digital wallet, the user must somehow establish a communication connection with the service provider.

[0035] Making payments using money (or some digital representation thereof) is a simple and easily understandable application of using a digital wallet, and is therefore used as an example below. However, it should be noted that the same concept is equally applicable to using other types of digital services, and is not limited to mere payments. As a further illustrative example, digital assets stored in a digital wallet may be an instruction for characteristics or rights acquired or granted to a user, such as a digital driver's license, i.e., a digitally protected certificate of the user's right to drive a particular type of vehicle. For this reason, the concept of “performing a transaction” should be understood in a broad sense to encompass all secure, user-initiated processing of digital data for secure maintenance and management, for which the party referred to here as the service provider is responsible.

[0036] In step 103, the user performs the respective action by going to a merchant and purchasing goods, visiting a public official to use public digital services, or beginning to engage closely with some other type of contact or entity. While examples of merchants will be mentioned most frequently below, the general applicability of the method should be kept in mind.

[0037] Step 104 represents all actions taken by the parties to transfer an agreed amount (or other digital asset) from the user's digital wallet to the merchant. In the merchant example, in Step 104, payment is made and the user pays the merchant the price of the product, but there is no need to handle cash or any other representation of money carried by the user. In the non-purchase example, Step 104 represents all other steps in which the parties exchange digital information, leveraging the digital security provided by the aspects described herein. An important aspect of the present invention relates to how steps 103 and 104 proceed as simply as possible but securely in Steps 101 and 102, and how the following can be ensured: • Merchants and users do not need to have any prior information about each other. • If necessary, transactions can maintain anonymity, similar to purchasing goods with cash, although in some other applications, the core of the transaction may involve secure identification of the user. • Only the minimum requirements should be imposed on the hardware and software that users and merchants must access, and All parties are assured that the transaction did not compromise security, for example, that neither the user nor the merchant will acquire any persistent confidential information that could later be used in a way that harms each other's interests.

[0038] Figure 2 illustrates the steps of an alternative method at a very abstract level. In Figure 2, the parties involved are the trust provider, the service provider, and the user.

[0039] Steps 101 and 102 in Figure 2 are the same as the corresponding numbered steps in Figure 1. The difference from Figure 1 is that in Figure 2 there is no merchant or corresponding involved party. After performing step 102, the user suffers a loss, for example, if the mobile communication device used by the user to store all previously created digital secrets is lost or severely damaged. Step 201 represents all such actions taken by the parties shown in Figure 2 to restore the user's ability to use the digital wallet set up in steps 101 and 102. Involving a service provider in step 201 is not mandatory, but it is not excluded either.

[0040] The following explanation illustrates how the specific actions performed in steps 101 and 102 lay the foundation for the success of subsequent operations, as shown in both Figures 1 and 2.

[0041] Figure 3 illustrates specific actions performed by users, service providers, and trust providers, and the specific exchanges of information between them. In practice, these terms refer to devices, arrangements, etc., operated by the parties unless otherwise specified. Such devices, arrangements, etc., most advantageously consist of programmable electrical devices and their connections for communication. Each such device, arrangement, etc., may be functionally divided into more detailed parts; for example, an arrangement for setting up and maintaining user accounts within a service provider's domain may be considered to comprise a communication system configured to set up and maintain communication between user devices and at least one trusted central arrangement, and an account management system functionally coupled to the communication system. For brevity of reference, the short terms user (or user device), service provider, and trust provider will be used below.

[0042] Step 301 in Figure 3 is a preparation step in which the service provider generates several unique keys that will be used, for example, for secure digital communications over one or more PKI infrastructures.

[0043] In step 302, a protected communication channel is established between the service provider and the user. The protected communication channel may be, for example, a digital communication channel, where transport layer security or the TLS standard is used. As another example, an algorithm based on Quantum-Safe Cryptography (QSC) may be used. The above concept is under development at the time of writing this specification and may instead be rephrased as post-quantum cryptography (PQC) or post-quantum cryptography (QRC). As yet another example, step 302 may include bringing the user device close enough to the wireless communication means to exchange information over a short distance, for example, under the supervision of authorized personnel, in circumstances considered to be sufficiently secure, such as connecting it to a cable such as a shielded electrical cable or fiber optic cable. As yet another example, step 302 may include using an optical fiber as a quantum channel to establish an electrically controlled polarization system for the purpose of encoding and decoding secrets by a twin photon source. This optical fiber communication principle is used in quantum key transfer (QKD) and, therefore, cannot be deciphered by conventional methods, may also be used to transmit secret seeds or salts from a trusted computing environment, making it a suitable secure digital communication channel.

[0044] Step 303 is an optional step in which the service provider may receive a request from the user to initiate a sequence of subsequent steps. The request in step 303 is optional because the service provider may initiate the sequence of steps of its own operation in response to finding that the user device is close enough or that other favorable conditions for performing the sequence of steps have otherwise been generated. As an exemplary example, if the secure communication channel established in step 302 involves the user accessing the service provider's web page, the request in step 303 may be sent in response to clicking a link on the web page.

[0045] In step 304, the service provider uses a random number generator to generate a first digital value, or what is called a user-specific random salt. Hereinafter referred to as URT. SALT Use the following. For the optimal level of security, it is advantageous for the service provider to use a verified random number generator that can generate random numbers with maximum entropy. As of the time of writing this specification, the user-specific random salt URT generated in step 304 SALT From a security standpoint, a length of at least 256 bits is considered advantageous. Subsequent technological advancements may make it appropriate to use more complex, user-specific random salt values.

[0046] In step 305, the user-specific random salt URT SALTis provided to the service provider's communication system for further transmission to the user via the protected communication channel established in step 302. The generation of the transmission in step 305 may also include using other information elements, such as transmitting one or more public keys of the service provider to the user. This may also include digitally signing at least a portion of the intended transmission with the service provider's secret signing key, such that a user receiving the transmission later may verify that it originated from the service provider using the corresponding public key. The resulting transmission conveys at least the user-specific random salt URT SALT to the user, as shown as step 306 in FIG. 3.

[0047] In step 307, the user device extracts the user-specific random salt URT SALT from the received transmission. To base subsequent digital communication and operation security for secret information from two independent sources, the user provides a PIN (Personal Identification Number) code in step 308. As an alternative or addition to a PIN in the conventional sense (i.e., a relatively short string of numbers or other characters), the PIN code provided in step 308 may be a biometric identifier such as a fingerprint, an iris reading, a facial liveliness indicator, and / or a mathematical result derived therefrom, and / or any combination of the above. For brevity of notation, the PIN may be given the designated URT PIN and its generation may involve a SHA256 hash or other cryptographic operation, thus, for example, if the actual PIN is a conventional short string, URT PIN = SHA256(PIN).

[0048] In step 309, these two information elements (URT SALT and URT PINFrom this, a hash or other digital cryptoproduct is calculated. The algorithm used to calculate the hash in step 309 is most preferably a validated one, such as the Argon2 algorithm. The calculation result is then used as is for the subsequent user's private key URT. SK It may also be used as follows. According to cryptographic abbreviations, URT SK =Argon2(URT PIN , URT SALT ) The "Argon2" portion may be replaced with any corresponding representation of another cryptographic operation used for the same purpose.

[0049] User's private key URT SK This can also be obtained from the result calculated through some further cryptographic algorithm.

[0050] In step 310, the user device uses the computed hash or several further cryptographic products derived therefrom to obtain a second digital value or the user's first public key URT. PK This generates something called [something]. An example of a mathematical method used in step 310 is the X25519 algorithm, URT PK =X25519(URT SK )=X25519(Argon2(URT PIN , URT SALT )). This is the result. Instead of the X25519 algorithm, you can also use some other suitable algorithm such as the Ed25519 algorithm. For further explanation of the method below, use a user-specific random salt URT. SALT , PIN code URT PIN If the algorithms used in steps 309 and 310, and the public-key cryptography or public-key signing algorithm used are known, then the user's private key URT SK Also, the user's first public key URT PK It is important to understand that this can be reproduced later.

[0051] In step 311, the user uses an appropriate channel, for example, a previously established secure communication channel, to provide at least the user's first public key URT PK Send a registration request including the following to the service provider. To add security, the user must include the private key URT in at least part of the registration request. SK Encrypting with is advantageous, and therefore the user's first public key URT PK By successfully decrypting the data, the service provider may verify that the registration request originated from a user and that it was not tampered with or modified by a malicious third party.

[0052] In response to receiving registration request 311, the service provider generates what is hereby referred to as a further registration request. The intended recipient of the further registration request is the trust provider, and the purpose of the further registration request is to have the trust provider create a digital wallet for the user. Alternatively, if a digital wallet has already been created for this user at some initial stage, the purpose of the further registration request is to have the trust provider modify, enhance, or refresh the previously created digital wallet using the latest information from the service provider.

[0053] As shown in step 312 of Figure 3, the generation of a further registration request by the service provider may involve adding attributes related to the current exchange of information with the user. In particular, the further registration request may include at least the user's first public key URT PK It should include. Further registration requests may also include a user identifier UID, which may be an identifier previously received by the service provider from the user, or an identifier generated by the service provider to identify this particular user. In step 312, the service provider's communication system sends the further registration request to the trust provider.

[0054] In step 314, the trust provider registers the customer relationship between the user and the service provider. In other words, the trust provider stores one or more sets of information that associate this user with this service provider and the attributes provided in the further registration request in step 312. To avoid primarily maintaining confidential information in plain text, the trust provider stores the stored information, for example, the user's first public key URT received in the further registration request. PK It is advantageous to encrypt the information and discard the plaintext copy. Most advantageously, a trust provider maintaining the user's digital wallet maintains them anonymously and refers to the encrypted and stored digital wallet using only a user identifier (UID) such as a hash UID (called H(UID)) or some mathematical derivative thereof. As a result, even the trust provider does not know the user's private key URT, which at this point is only owned by the user. SK Without it, you would not necessarily have access to the stored user-specific information (however, as mentioned above, this is the user-specific random salt URT SALT , PIN code URT PIN (and can be reproduced by knowing the appropriate algorithm). The purpose of such security measures is to prevent unwanted access to stored user-specific information by parties such as system administrators who must have broad access rights for their tasks and responsibilities. Government regulations may require official authorities to participate as members in at least certain types of transactions for legitimate and necessary purposes, such as preventing money laundering or other types of criminal activity.

[0055] In step 315, the trust provider sends the private key UAT. SK and public key UAT PK Generate another pair of keys including the user's second public key UAT. PK This is referred to here as the third digital value. (Private key UAT) SKThe user's second public key UAT remains the exclusive property of the trust provider, but in the transmission called the registration response in step 316 of Figure 3, the user's second public key UAT PK Send the following to the service provider: User's second public key UAT PK In Figure 3, this is abbreviated as "remote key" because it is generated at a distance from the user (at least in an organizational sense, physically, if not necessary). UAT is also sometimes called a (public) user access token, as its acronym suggests.

[0056] In steps 317 and 318, the service provider completes its part of establishing a customer relationship with the user. As underlined in step 317, the service provider is now ready to conduct a transaction, an example of which will be described in detail later in the text. Specifically, as underlined in step 318, the service provider uses the user's second public key UAT received from the trust provider in the registration response in step 316. PK It also remembers. Furthermore, for sending to the user, it also requires at least the user's second public key (UAT). PK Generate (and provide to its communication system) a further registration response 319 including the user's second public key UAT. PK Storing this information on the user device is shown as step 320 in Figure 3.

[0057] As a result of the actions and exchange of the above information, the service provider knows, among other things: • User's first public key URT PK If an encrypted information fragment that can be properly decrypted is obtained, that fragment must be generated by the user (or at least created with the user's consent), because only the user (or a party authenticated by the user's PIN code) can access the corresponding private key URT. SK Because it can be encrypted. • User's second public key UAT PKIf you obtain an encrypted information fragment that can be properly decrypted, that fragment must be generated by a trust provider, because only a trust provider can generate that fragment with the corresponding private key UAT. SK Because it can be encrypted.

[0058] In step 319, with respect to the additional registration response sent to the user, the service provider (or its account management system) shall, at least in relation to steps 304-309, the user-specific random salt URT SALT It may also be configured to include user-specific random salt URT. SALT We already know this because we received it in the initial response in step 306. However, user-specific random salt URT SALT and the user's second public key UAT PK The simultaneous occurrence of these two phenomena can be particularly useful in some cases.

[0059] As an example, Figure 4 shows a further registration response in step 319 or a user-specific random salt URT. SALT and the user's second public key UAT PK Other simultaneous occurrences are expected to be formatted in the form of a graphically representable code 401. Here, the expression "formatted in the form of" may mean an actual graphically represented code 401 such as a QR code (registered trademark), or some instance of digital information that can directly print a graphically represented code. From technologies such as QR codes (registered trademark), it is well known how, for example, a raw bit string can be directly converted into a tangible printed form of a graphically represented code. One possibility is that the further registration response in step 319 consists of actually printing a QR code (registered trademark) and handing it to the user. Another possibility is that the digital information contained in the further registration response makes it possible for the user to easily print it in the form of a QR code (registered trademark).

[0060] The use of QR Code® or other graphically representable codes is one example of such embodiments, and users may access (public) digital services even without the ability or willingness to use a smartphone or the like. Such users may carry one or more pre-printed QR Code® and use them in the manner described herein.

[0061] As shown in Figure 401, by using an appropriate reader device, anyone can obtain a user-specific random salt URT from the graphically representable code 401. SALT 402 and the user's second public key UAT PK 403 can be easily read. PIN code URT PIN If a 404 error is provided by the user, the user will not be able to access the private key URT. SK The same hash or other cryptographic operation 405 used initially to obtain the user's first public key URT may be used. PK You may use the same mathematical operation you initially used to obtain it.

[0062] Figure 5, similar to Figure 4, shows a further registration response in step 319 or a user-specific random salt URT. SALT and the user's second public key UAT PK Another example of a simultaneous occurrence is shown, formatted in the form of a graphically representable code 401. Again, the use of a QR code® or other graphically representable code is an example of the embodiments described above, which may allow a user to access (public) digital services even without the ability or willingness to use a smartphone or the like. Such a user may carry one or more pre-printed QR codes® and use them in the manner described herein.

[0063] In Figure 5, the private key URT is derived from a graphically representable code. SK It is assumed that this is not the case. Rather, hashing or other cryptographic operations are used to obtain the user's second public key UATPK Hash version of 403 H(UAT) PK You may obtain a PIN code (URT). PIN Whether or not 404 is used for hashing or other cryptographic operations 501 is optional. An important assumption regarding Figure 5 is that the trust provider responsible for maintaining the user's digital wallet is the user's second public key UAT PK Hash version of 403 H(UAT) PK The ability to link the user identifier to the user's identifier. The identifier may be the user identifier UID directly, or some distinct cryptographic derivative thereof, such as a hashed version H(UID). Such linking is shown in Figure 5 with reference number 503. As a result, the trust provider can link the user's second public key UAT PK Hash version H(UAT) PK When receiving a request that includes ), the trust provider can identify to the user the digital wallet to which the request should be associated.

[0064] Figure 6 schematically illustrates how these facts are utilized, corresponding to steps 103 and 104 in Figure 1 above and providing some further details. The actions in Figure 6 aim to enable a user to purchase a product (or conduct some equivalent transaction) without requiring any user device. Again, a merchant-related example is used, but the more general applicability of the method should be kept in mind.

[0065] In step 601, the user and merchant agree in advance to the purchase. For example, the merchant agrees to sell the product to the user at a certain price. In step 602, the merchant initiates the transaction by connecting to the trust provider using a digitally communicative cash register or corresponding device. Figure 6 shows that the parties corresponding to the trust provider in Figures 1, 2, and 3 perform two distinct functions called wallet and vault. Applying this principle, the merchant communicates with the wallet function in step 602. Essentially, the merchant tells the wallet that someone (whose identity has not yet been revealed to the wallet) is willing to pay the merchant the price agreed upon in step 601.

[0066] In step 603, the merchant uses an optical reader to read the QR code® presented by the user. For example, the user may have generated a QR code® printed on a piece of paper. In step 604, the merchant hands the user a small keypad, and the user punches a PIN code. If the concept of a PIN code involves several other user-specific aspects besides a short string of characters that the user memorizes, step 604 may also use other preferred means to enable the user to provide the merchant with the corresponding information. Here, the merchant's cash register is getting whatever it needs. Compared to Figure 4, the user-specific random salt URT from QR code® 401. SALT 402 and the user's second public key UAT PK Read 403 and enter the PIN code URT PIN The data was received directly from the user. The cryptographic algorithms required for steps such as 405 and 407 in Figure 4 or 501 in Figure 5 are pre-programmed in the merchant's cache register.

[0067] Step 605 in Figure 6 represents the communication and operations between the merchant's cash register and the trust provider's wallet and vault functions, which set up the user's digital wallet for the transaction. Since the user's money or other valuable digital assets are stored with the service provider (e.g., a bank, government authority, etc.), in step 606, the wallet and the service provider work together to authorize and execute the actual payment or to grant access to the otherwise stored digital assets. In step 607, the wallet returns a receipt to the merchant's cash register as proof of the executed transaction. As a result, the merchant knows that the agreed price has been paid, and in step 608, the merchant can deliver the product to the user.

[0068] Figure 7 is a more detailed representation of an example of communication and operation between four devices or arrangements designated as merchant, service provider, wallet, and vault in the process of implementing the method in Figure 6. Similar to Figure 3 above, abbreviated notation for communicating parties is used, but it is clear that each of these can be involved in both a device or arrangement and multiple connections for communication. Also, similar to Figure 3, the concepts of the user as a party, the merchant interacting with the service provider, the bank as a service provider, and the purchase of a product as a transaction should not be considered limiting, but rather as illustrative examples of the more general applicability of the process being described.

[0069] In step 701, the merchant begins generating a transaction request. Initially, the only information required is the merchant's identity and the monetary or other measure of the digital assets involved in the intended transaction.

[0070] The configuration request in step 702 simply makes the wallet aware that this type of transaction is intended, and the configuration response in step 703 confirms that the wallet is initially ready. For example, in step 702, a browser on the merchant's device may make a request to a specific URL of the trust provider, and in step 702, the trust provider may return a corresponding web page containing fields for entering values.

[0071] In step 704, the merchant receives the necessary inputs from the user. See, for example, steps 603 and 604 in Figure 6. In step 705, the merchant uses these inputs to compute one or more keys or other cryptographic products necessary for subsequent operations. In particular, if the principle in Figure 4 is applied, at this stage the merchant computes the secret key URT. SK It holds the user's public key URT. By knowing the mathematical operation shown in reference number 407 in Figure 4, the merchant can access the user's public key URT. PK It can also be obtained. Similarly, if the principle in Figure 5 is applied, at this stage the merchant can obtain the user's second public key UAT PK Hash version H(UAT) PK This will enable the generation of ).

[0072] In step 706, the merchant sends the actual transaction request to the wallet. Essentially, in step 706, the merchant requests that the agreed price be transferred from the user's ownership to the merchant's ownership. At least part of the transmission in step 706 is the private key URT SK It is encrypted. Advantageously, the transmission in step 706 uses the user's public key URT. PK or the user's second public key UAT PK Hash version H(UAT) PK This includes at least one of the following:

[0073] When the wallet receives transaction request 706, the encrypted portion is the user's first public key URTPK The wallet recognizes that it has been properly decrypted. Therefore, the wallet concludes that the transaction request in step 706 was sent by the user, if not directly, with the user's consent. Thus, this step may be called identifying user 707. If the principle of Figure 5 is applied, identifying the user in step 707 is the user's second public key UAT PK The received hashed version H(UAT) PK This may include linking the request received in step 706 to a user identifier such as a UID or H(UID). Here, the wallet can associate the request received in step 706 with a specific (hashed) user identifier UID, thereby associating it with a specific archive of user-specific information previously stored in encrypted form. In step 708, the wallet requests the vault to obtain the actual wallet information of the identified user.

[0074] One specific advantage of applying the principle shown in Figure 5 is the user's second public key UAT PK Hash version H(UAT) PK It should be noted that by linking the PIN to a user identifier, the trust provider can recognize who the user of the digital wallet they are trying to access is. This is true even if the request arises from an attempt using the user's incorrect PIN. If this is indeed the case, i.e., the PIN was incorrect, the trust provider must assume the request is not legitimate and reject it. After receiving a small number of such fraudulent requests, the trust provider may lock the user's access to their digital wallet, as an unauthorized party may have obtained the QR code and is attempting to guess the correct PIN. With a 4-digit PIN, there are only 10,000 possible values, so attempting a brute-force attack is relatively easy unless the party receiving the attempted request has the means to discard it and recognize and appropriately respond to an unusually large number of incorrect attempts.

[0075] Once the wallet information is retrieved from the vault, in step 709, the trust provider's wallet function formulates a further transaction request, and in step 710, the previously generated private key UAT SK Using this method, digitally sign it and, in step 711, send it to the service provider that maintains the account for the digital asset associated with the user device from which the UAT key and URT key were generated.

[0076] Before executing a requested transaction, the service provider should verify that everything is normal, i.e., that the user is aware of and has authorized the transaction. To ensure this, for example, the encrypted portion of the request should be verified using the user's first public key (URT). PK It may include a check to see if decryption was successful. In other words, the account management system of a service provider that maintains accounts for digital assets associated with the user device in question may use the user's first public key URT to decrypt at least a portion of the transaction request 711. PK The account management system may respond to the transaction request 710 received from the trust provider by attempting to decrypt it (following the previous registration response, see step 316 in Figure 3). If the attempted decryption in step 712 is successful, the account management system may execute the transaction 713 requested in the transaction request 711 on the account of the digital asset.

[0077] As can be seen from the above explanation, at this stage of the procedure, the user's private key URT SK This may also be revealed to another party, namely the merchant. To maintain security, the private key URT SK It may be desirable to make it disposable, that is, to make it valid or permissible only for single use. In practice, this is because the service provider's account management system, in step 711, the transaction request, in step 712, the user's first public key URT PKIt can be guaranteed by configuring to execute the transaction of step 713 only when it is the first transaction request regarding the success of the decryption attempt using the same. The subsequent transaction requests that succeed in decryption with the same public key URT PK are rejected. Similarly, the trust provider may accept only one transaction request for each previously generated public key URT PK and reject subsequent attempts. From the user's perspective, assuming the practice of using QR Code (registered trademark), this means that once the QR Code (registered trademark) is used, it can be discarded and a different QR Code (registered trademark) must be used for the next purchase.

[0078] Also, as an additional security feature, the service provider's account management system may be configured to attempt to decrypt at least a part of the transaction request 711 with the user's second public key UAT PK . The service provider may execute the transaction in step 713 only when the decryption attempt using the user's second public key UAT PK succeeds in step 711. In other words, (since the trust provider is the only provider holding the private key UAT SK ) execute only such transactions for which it can be guaranteed that the request came from the trust provider.

[0079] If the transaction succeeds in step 713, the service provider approves it by sending a receipt to the wallet in step 714. The wallet transfers the receipt to the merchant in step 715. To ensure that confidential information is not stored in plain text unnecessarily, the wallet may discard all such information in step 716 and then, when needed, the appropriate information is fetched again from the vault as in steps 708 and 709 above.

[0080] As already stated, monetary payments between two parties (user and merchant) are just one example of how this disclosure enables the secure use of digital services. The examples described above may be generalized by pointing out how a service provider can be any party responsible for maintaining and processing user-specific digital information in a manner that requires appropriate authorization. Such generalizations may be illustrated, for example, as follows:

[0081] Instead of a bank, we may assume that the service provider is a private medical station providing occupational health services to employees of a company that has signed a service contract. The user may be one of such employees, and the intended transaction includes scheduling an appointment with a doctor. Traditionally, if scheduling services were not yet digitized, the user would have to go to a reception desk, present a membership card issued by their employer to prove they were employed by the company that had signed the service contract, and only then would the receptionist agree to schedule the appointment. Applying this disclosure, instructions regarding the user's current employment would be stored in the user's digital wallet as a “digital membership card,” i.e., a digital certificate signed by the employing company.

[0082] In creating a reservation, the user may use any device to input, in some form or another, a "transaction request" (i.e., a request to schedule a reservation) and the same input information given in the form of a QR code (registered trademark) and a PIN code in the above example. Similar to steps 706 to 711, the transaction request is routed through the trust provider, which checks that the digital certificate is valid and transfers the thus checked and authorized transaction request to the scheduling system of the medical station. As explained above referring to step 712, after performing its own check and "executing the transaction", i.e., after scheduling the requested reservation as in step 713, the scheduling system of the medical station sends a confirmation "receipt" to the trust provider, which then transfers it to the device used by the user.

[0083] In the first half of the above description, (in step 313 of FIG. 3) how the trust provider recognizes the user's first public key URT PK and the fact that without the user's private key URT SK the trust provider may not be able to access its stored user-specific information in any way have been explained. On the other hand, as shown in FIG. 4, it is possible to derive the user's public key UAT PK and private key URT SK from the graphically representable code 401. The PIN (or more specifically, URT PIN ) is required to derive the latter. These facts may be utilized, if necessary, in direct communication between the user and the trust provider, especially in some specific situations.

[0084] For example, suppose a user loses or destroys a user device that was previously used as a user device in the manner described above. However, the user may still have access to a tangible instance of the graphically representable code. In a simple case, the user may have a hard copy of a pre-printed QR code® and / or some other form of stored digital information. The user may visit the trust provider's premises or obtain a new device, set up a communication connection that is properly secured by some other means, and present the pre-printed QR code® to the reader. Furthermore, the user may provide a PIN and, from the PIN, access the URT PIN This may be derived. After communicating the necessary digital information fragments to the trust provider, the trust provider will have access to all the requested information necessary to access its stored user-specific information, and any desired portion of such information will be restored and thus made available to the user who did not need to lose or damage the user device at all.

[0085] Figure 8 shows an example of restoring a user account in the situation described above. Here, it is assumed that the party referred to as the trust provider may have an arrangement such as that described in concurrently pending patent application number EP22157019.5, which is not publicly available at the time of writing this specification. In short, the arrangement may have the features of the functions referred to above as a trust provider or trusted central arrangement. Referring to Figure 3 above, the trust provider has at least The step of receiving a registration request of the type described in step 312, • Steps to register customer relationships, such as step 314, • Step 315 involves generating a (remote) key, The step of generating and sending a response of the type described in step 316, It is equipped with means for performing and configured to perform those steps.

[0086] Furthermore, the trust provider uses the first digital value or user-specific random salt URT in step 304 of Figure 3 above. SALT It is advantageous to have means for safely generating high-entropy random values, as well as means for generating them.

[0087] In Figure 8, two different functions of the trust provider are indicated by the two long vertical lines on the left. The function called "Vault" is similar to the function designated above in Figures 6 and 7. The other function can be characterized as a registration service. This distinction in functions is illustrative and should not be interpreted as limiting. In some cases, this type of registration service may be operated by a party other than the trust provider, for example, when a user wishes to continue using the service provider's services in a way that also requires the use of the trust provider's services.

[0088] Figure 8 assumes that a user who previously used a user device to participate in a method like the one in Figure 3 subsequently loses access to the user device. However, the user still has access to a previously obtained graphically represented (or representable) code, such as a QR code (registered trademark), or at least the corresponding digital information. From the graphically represented code, at least the user's so-called second public key UAT PK It is possible to derive the following. Furthermore, using a user-specific PIN, the key pair URT SK URT PK It is also possible to derive this. Furthermore, we assume that the user has acquired a new user device, such as a smartphone, that can be equipped with a digital camera.

[0089] In step 801, the user initiates the download of a suitable application program, simply called an app, to the new user device. Steps 802 and 803 represent the request for and download of the app to the user device. The parties involved in these communications are not critical and may be, for example, a commonly used app store.

[0090] In step 804, the new user device receives user input. Step 804 may include, for example, the user using the user device's digital camera to read a QR code (registered trademark), or using some other function of the user device to recognize the corresponding digital information. Furthermore, in step 804, the user provides the user device with a user-specific PIN by keying a string, enabling the device to read an iris or fingerprint, and / or by some other means. In step 805, the user device uses the app received in step 803, as described above with reference to Figure 4, to at least obtain the private key URT SK and the corresponding public key URT PK Calculate.

[0091] In step 806, the user sends a request to the registration service for the address of the function that should achieve the desired user account recovery. The request sent in step 806 is the second public key UAT PK Since it includes this, the registration service accepts this as sufficient proof that the user is authorized to contact the vault. This is shown in Figure 8 as identifying the user in step 807. In response, the registration service sends the user an address (such as a URL) in step 808. Steps 806, 807, and 808 are optional, as the user may already know the correct address of the vault from some other source.

[0092] In step 809, the user device sends a restore request to the vault using the address received in 808. The restore request in step 808 includes at least the user's second public key UAT PK This includes at least part of the recovery request, the user's private key URT SK It may be encrypted. For example, as explained earlier with respect to Figure 3, the vault has the means necessary to ensure that the received information fragment must originate from the user (or at least be created with the user's consent), because only the user (or the party to whom the user authorized the PIN code) can use the corresponding private key URT. SK This is because it can be encrypted. Furthermore, after receiving a request of the type shown in step 809, the vault has the means necessary to associate the request with a (hashed) user identifier UID, and as a result recognize and decrypt the user-specific information it previously stored in encrypted form.

[0093] In step 810, the vault recovers (i.e., decrypts) the information corresponding to what is referred to above as “the actual wallet information of the identified user” with respect to step 710 in Figure 7. In Figure 8, the corresponding information is called the user’s keystore. Regardless of the literal terminology used, step 810 can be described as the vault recovering sensitive user-specific information previously stored in the vault in an encrypted form.

[0094] Considering that certain graphically representable codes were "consumed" through use in recovery requests, the same private key URT SK It is also highly recommended to ensure that the same graphically representable code can no longer be used for anything else. This means that at least some of the core operations of the key generation action and code generation action described earlier should be repeated here. In step 811 of the embodiment in Figure 8, the vault generates a new private key UAT. SK and the new ("second") public key UAT PKGenerate another pair of keys including the new private key UAT, similar to step 315 in Figure 3. SK The vault remains exclusively owned. The user's new second public key UAT PK This, as well as the new user-specific random salt of the vault generated in step 812 in the embodiment of Figure 8, is sent to the user device in step 813.

[0095] Similar to step 319 in Figure 3, a new user-specific random salt URT SALT and the user's new second public key UAT PK The QR code may be formatted in the form of a graphically representable code. In other words, in this way, the user can reserve a new QR code for future use in place of the QR code that was "consumed" in a recovery request, for example. Step 814 represents all the actions that the user device can take after receiving such a graphically representable code, as shown in steps 307 onward in Figure 3 above. In particular, it is desirable to continue from the recovery process to steps such as those shown as steps 311-320 in Figure 3, because in this way the user's sensitive data stored in the vault is re-encrypted in a manner that requires permission from the user to be decrypted.

[0096] In the above description, some steps involve generating a cryptographic key from specific input data. Conventional algorithms known to be used for key generation include, but are not limited to, ECC (Elliptic Curve Cryptography) and DSA (Digital Signature Algorithm) algorithms. At the time of writing this specification, it can be assumed that development is moving towards more advanced, so-called quantum-secure key generation algorithms, such as the Kyber or Dilithium algorithms. The above description and examples are applicable regardless of which specific algorithm is used.

[0097] A common feature of quantum secure key generation algorithms is their ability to generate significantly larger key values ​​than conventional algorithms. On the other hand, at least some quantum secure key generation algorithms can simultaneously generate key pairs (consisting of a private key and a corresponding public key) in a so-called seeding operation using a seed value that may be smaller than the actual key value. If one or more cryptographic keys that would be generated using a quantum secure algorithm would be inconveniently large for transmission between devices, as described in some of the examples above, it is possible to instead rely on the ability of participating devices to transmit a seed value and seed the required key pairs. Methods applicable to such purposes are described in detail in concurrently pending patent application no. EP24160932.0, which has not yet been published as of the filing date of this application.

[0098] Any range or device value given herein may be extended or modified without loss of the desired effect. Furthermore, any embodiment may be combined with another embodiment unless expressly prohibited.

[0099] While the subject matter has been described in language specific to its structural features and / or functions, it should be understood that the subject matter as defined in the attached claims is not necessarily limited to the specific features or functions described above. Rather, the specific features and functions described above are disclosed as examples of implementing the claims, and other equivalent features and functions are intended to be within the scope of the claims.

[0100] It will be understood that the benefits and advantages described above may relate to one embodiment or to multiple embodiments. Embodiments are not limited to those that solve any or all of the problems described, or that have any or all of the benefits and advantages described. It will also be understood that a reference to "one" item may refer to one or more of those items.

[0101] The steps of the methods described herein may be performed in any suitable order or simultaneously, where appropriate. Furthermore, individual blocks may be removed from any of the methods without departing from the spirit and scope of the subject matter described herein. Any aspect of the embodiments described above can be combined with any aspect of any of the other embodiments described without losing the desired effect to form further embodiments. What has been described herein with respect to the methods is directly applicable to computer program products consisting of machine-readable instructions that, when executed by one or more processors, result in an implementation of the type of method described.

[0102] In this specification, the term “equipment” is used to mean including a specified method, block or element, but such blocks or elements do not constitute an exclusive list, and the method or apparatus may include additional blocks or elements.

[0103] The above description is given only as an example, and it will be understood that various modifications can be made by those skilled in the art. The above specification, examples, and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments are described above with some degree of specificity or by reference to one or more individual embodiments, those skilled in the art can make numerous modifications to the disclosed embodiments without departing from the spirit or scope of this specification.

Claims

1. An arrangement for setting up and maintaining user accounts, wherein the arrangement is: A communication system configured to set up and maintain communication between user devices and at least one trusted central arrangement, - An account management system functionally integrated with the aforementioned communication system, Equipped with, The aforementioned account management system is - For further transmission to the user device (306), a random number generator is used to generate a user-specific random salt (URT) below. ＳＡＬＴ The first digital value called (304) is generated and provided to the communication system, - Responding to a subsequent registration request (311) from the user device, wherein the registration request includes the user's first public key (URT) ＰＫ The second digital value called ) is included, for further transmission to the trusted central arrangement, at least the user's first public key (URT ＰＫ This is done by generating (312) a further registration request (312) including the above, and providing it to the communication system, - Responding to a subsequent registration response (316) from the trusted central arrangement, wherein the registration response (316) includes the user's second public key (UAT). ＰＫ This includes a third digital value called the user's second public key (UAT) for further transmission to the user device, at least the user's second public key (UAT). ＰＫ This is done by generating a further registration response (319) including the above and providing it to the communication system, An arrangement structured to perform [a certain action].

2. The account management system adds the user-specific random salt (URT) to the further registration response (319). ＳＡＬＴ The arrangement according to claim 1, configured to include ).

3. The arrangement according to claim 2, wherein the account management system is configured to format the further registration response (319) in the form of a graphically representable code (401).

4. The aforementioned account management system is - Maintaining and managing accounts for digital assets associated with the user device, - Responding to a transaction request (711) received from the trusted central arrangement after the registration response (316) by providing at least a portion of the transaction request (711) to the user's first public key (URT ＰＫ This is done by attempting to decrypt it using (712), - Only if the decryption attempt (712) is successful, the transaction requested in the transaction request (710) will be executed (713) on the account of the digital asset. The arrangement according to any one of claims 1 to 3, configured to perform the following:

5. The account management system determines that the transaction request (711) is the user's first public key (URT ＰＫ The arrangement according to claim 4, configured to execute the transaction (713) only if it is the first transaction request for which the decryption attempt (712) using ) has been successful.

6. The aforementioned account management system is ・ Attempting to decrypt at least a part of the transaction request (711) with the second public key (UAT ＰＫ ) of the user (712); - The user's second public key (UAT) ＰＫ The transaction (713) is executed only if the decryption attempt (712) using () is successful, The arrangement according to claim 4 or 5, configured to perform the following:

7. A method for setting up and maintaining user accounts, - Using a random number generator, a user-specific random salt (URT) is generated as follows. ＳＡＬＴ Step (304) to generate a first digital value called ) and the user-specific random salt (URT ＳＡＬＴ The steps include sending (306) a message to the user device, - A step of responding to a subsequent registration request (311) from the user device, wherein the registration request includes the user's first public key (URT) ＰＫ The step includes a second digital value called ), at least the user's first public key (URT Ｐ This is done by generating (313) a further registration request (312) including K) and sending it to a trusted central arrangement (313), - A step of responding to a subsequent registration response (316) from the trusted central arrangement, wherein the registration response (316) includes the user's second public key (UAT) ＰＫ The step includes a third digital value called ) and at least the user's second public key (UAT). ＰＫ This is done by generating a further registration response (319) including the above and sending it to the user device, Methods that include...

8. The step of generating the further registration response involves adding the user-specific random salt (URT) to the further registration response (319). ＳＡＬＴ The method according to claim 7, which also includes including ).

9. An arrangement of the method of claim 8, comprising the step of formatting the further registration response (319) in the form of a graphically representable code (401).

10. - A step of maintaining and managing accounts for digital assets associated with the user device, - The step of responding to a transaction request (711) received from the trusted central arrangement after the registration response (316) is performed by using at least a portion of the transaction request (711) as the user's first public key (URT ＰＫ This is done by the step (712) in which an attempt is made to decrypt using the method, - Step (713) to execute the transaction requested in the transaction request (710) on the account of the digital asset only if the decryption attempt (712) is successful, The method according to any one of claims 7 to 9, including

11. The transaction request (711) is the user's first public key (URT ＰＫ The method according to claim 10, further comprising the step of executing the transaction (713) only if it is the first transaction request for which the decryption attempt (712) using ) was successful.

12. - A step (712) in which at least a portion of the transaction request (711) is attempted to be decrypted with the user's second public key (UATPK), - The user's second public key (UAT) ＰＫ If the decryption attempt (712) using ) is successful, then the step (713) of executing the transaction, The method according to claim 10 or 11, including the method described in claim 10 or 11.

13. A computer program product comprising one or more sets of one or more machine-readable instructions, which, when executed by one or more processors, cause an implementation of the method described in any one of claims 7 to 12.

Images