System and value exchange method

Abstract

In this system including a first device having a plurality of first values and a second device having a plurality of second values, the first device comprises a first storage unit and a first secure unit, and the second device comprises a second storage unit and a second secure unit. The first device transmits, to the second device, a first message suggesting an exchange of the plurality of first values and the plurality of second values. The second device deletes the plurality of second values from the second storage unit and transmits, to the first device, signatures for the plurality of second values as second deletion proofs, the signatures being generated by the second secure unit. The first device verifies the second deletion proofs, deletes the plurality of first values from the first storage unit, and transmits, to the second device, signatures for the plurality of first values as first deletion proofs, the signatures being generated by the first secure unit.

Description

System and value exchange method

[0001] The present invention relates to a technique for exchanging value between entities.

[0002] The Fair-Exchange (FE) protocol is a protocol for fair exchange of value between multiple entities. To maintain fairness, a trusted third party (TTP) is required, and the TTP will mediate in the event of a dispute between entities with different opinions. Among the FE protocols, the one that minimizes interaction with the TTP is called the Optimistic Fair-Exchange (OFE) protocol.

[0003] "Electronic Value Distribution Technology between Mobile Terminals," Masayuki Terada et al., NTT DoCoMo Technical Journal, Vol. 13, No. 3.

[0004] Existing methods resolve disputes using a transaction database managed by the TTP. However, in the event of a disaster or network failure, there is a good chance that the database will be inaccessible. Therefore, a method that can resolve disputes without accessing the database is desirable. In other words, a privacy-conscious OFE protocol is needed in which the TTP does not have a database and disputes are resolved with minimal interaction with the TTP. However, no such OFE protocol existed in the prior art.

[0005] On the other hand, there is also an existing method in which a message indicating that the value has been deleted is sent to the TTP (Non-Patent Document 1). However, the existing method does not specify how to use the proof that the value has been deleted, and does not take into consideration privacy, as information about the value to be exchanged is transmitted to the TTP.

[0006] In other words, with conventional technology, it has been difficult to exchange value safely while maintaining the privacy of the information about the value being exchanged.

[0007] The present invention has been made in consideration of the above points, and aims to provide a technology that enables safe exchange of value while maintaining privacy.

[0008] According to the disclosed technology, there is provided a system comprising a first device having a plurality of first values ​​and a second device having a plurality of second values, wherein the first device comprises a first storage unit and a first secure unit, and the second device comprises a second storage unit and a second secure unit, wherein the first device sends to the second device a first message proposing to exchange the plurality of first values ​​for the plurality of second values, the second device deletes the plurality of second values ​​from the second storage unit and transmits a signature for the plurality of second values ​​generated by the second secure unit to the first device as a second deletion evidence, and the first device verifies the second deletion evidence, deletes the plurality of first values ​​from the first storage unit, and transmits a signature for the plurality of first values ​​generated by the first secure unit to the second device as a first deletion evidence.

[0009] The disclosed technology provides a technology that enables secure exchange of value while maintaining privacy.

[0010] FIG. 1 is a configuration diagram of a system in an embodiment of the present invention. FIG. 2 is a diagram for explaining the operation of an SE. FIG. 3 is a diagram for explaining a basic protocol of the first embodiment. FIG. 4 is a diagram for explaining a Resolve protocol of the first embodiment. FIG. 5 is a diagram for explaining an Abort protocol of the first embodiment. FIG. 6 is a diagram for explaining a DB state. FIG. 7 is a diagram for explaining a basic protocol of a second embodiment. FIG. 8 is a diagram for explaining a basic protocol of the second embodiment. FIG. 9 is a diagram for explaining a Resolve protocol of the second embodiment. FIG. 10 is a diagram for explaining an example hardware configuration of a device.

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] In this embodiment, when considering value exchange using a smartphone or the like, it is desirable to be able to exchange multiple values ​​in a single transaction, and therefore an OFE protocol that allows multiple values ​​to be exchanged in a single transaction and does not require the issuance of deletion proofs all at once will be described. Below, a first embodiment (asymmetric authority) and a second embodiment (symmetric authority) will be described as more specific embodiments.

[0013] First Embodiment (First Embodiment: System Configuration Example) In this embodiment, a basic protocol, a Resolve protocol, and an Abort protocol will be described. An example configuration of a system in which these three protocols are executed is shown in Fig. 1. The basic protocol, the Resolve protocol, and the Abort protocol may be collectively referred to as the OFE protocol.

[0014] As shown in Fig. 1, the system includes a terminal 100A of a party A (which may be referred to as A), a terminal 100B of a party B (which may be referred to as B), and a TTP 200. The "terminal" may also be called an entity. The terminal is, for example, a smartphone.

[0015] Terminal 100A and terminal 100B exchange multiple values ​​that they each possess using a basic protocol. Party A and party B may commit fraud at their respective terminals. Fraud includes, for example, stopping the protocol midway or sending an unauthorized message.

[0016] In this embodiment, n values ​​vA １ , vA ２ , ..., vA ｎ and m values ​​vB held by the terminal 100B. １ , vB ２ , ..., vB ｍ and are exchanged.

[0017] The TTP 200 is a trusted third party. More specifically, the TTP 200 is a device (a computer such as a server) owned by a third party. The TTP 200 performs only legitimate operations, but retains information obtained during the operations (called a semi-honest TTP). The TTP 200 is also online only during arbitration.

[0018] As shown in FIG. 1, the terminal 100A includes an observer A (OA 110A) and a secure element A (SEA 120A).

[0019] The OA 110A is a functional unit realized by a value exchange application installed in the terminal 100A. The SEA 120A is a secure element installed in the terminal 100A. The SEA 120A accepts signature requests only from the OA 110A and assigns a signature to operations of the OA 110A.

[0020] The OA 110A also includes a DB 111A. The DB 111A is, for example, a nonvolatile memory. The DB 111A may also be called a storage unit. The OA 110A includes a volatile memory in addition to the DB 111A (nonvolatile memory).

[0021] The terminal 100B includes an observer B (OB110B) and a secure element B (SEB120B).

[0022] The OB 110B is a functional unit realized by a value exchange application installed in the terminal 100B. The SEB 120B is a secure element installed in the terminal 100B. The SEB 120B accepts a signature request only from the OB 110B and assigns a signature to an operation of the OB 110B.

[0023] The OB 110B also includes a DB 111B. The DB 111B is, for example, a nonvolatile memory. The DB 111B may also be called a storage unit. The OA 110B also includes a volatile memory in addition to the DB 111B (nonvolatile memory).

[0024] The value exchange applications of the terminals 100A and 100B described above are assumed to be applications for payment, authentication, etc. that run on the mobile TEE, such as Trustzone (registered trademark). However, the value exchange applications are not limited to applications for payment, authentication, etc. that run on the mobile TEE.

[0025] The communication method between the terminals 100 may be any communication method. For example, the communication method may be a wireless LAN, a short-range wireless communication, or any other communication method. In addition, the communication method between the terminal 100 and the TTP 200 may be any communication method, but in this embodiment, the communication method is assumed to be the Internet.

[0026] 1, the OA 110A and the SEA 120A are connected via an authenticated channel. Similarly, the OB 110B and the SEB 120B are connected via an authenticated channel. The authenticated channel is a channel where "eavesdropping: possible, tampering: impossible, and TTP eavesdropping: impossible."

[0027] The terminal 100A and the terminal 100B are connected via a normal channel, which is a channel where "eavesdropping: possible, tampering: possible, and TTP eavesdropping: impossible."

[0028] The TPP 200 and the terminals 100A and 100B are connected via a normal + TTP leak channel. The normal + TTP leak channel is a channel in which "eavesdropping: possible, tampering: possible, TTP eavesdropping: possible."

[0029] Note that the use of the above-described channels is merely an example, and the technology according to the present embodiment is not limited to the use of the above-described channels.

[0030] Here, the functions of the OA 110A and the SEA 120A will be described in more detail using the terminal 100A as an example. The same applies to the OB 110B and the SEB 120B in the terminal 100B.

[0031] First, the SEA 120A will be described. When the SEA 120A receives a signature request for a certain message from the OA 110A, it attaches a signature to the message and returns it to the OA 110A. In this embodiment, the message represents an operation performed by the OA 110A, and it is assumed that "if the SEA 120A signs a message m representing an operation on the OA 110A, then m is necessarily performed on the OA 110A."

[0032] 2, when "deletion of vA" is performed on the OA 110A at 16:30 on 1 / 18, the SEA 120A signs the message m ""1 / 18 16:30 vA deleted"". Note that if the deletion of vA has not actually been performed, no signature is issued.

[0033] During the execution of the protocol, the SEA 120A maintains the state of operation, i.e., even if the power is suddenly turned off, the state of the protocol can be maintained and resumed later.

[0034] Next, the OA 110A will be described. The OA 110A runs applications in an isolated space. The applications cannot be tampered with. The OA 110A can also verify the signatures added by the SEB 120B.

[0035] (First embodiment: overview of protocols) An overview of protocols executed in the above-described system will be described below. As described above, the protocols in this embodiment include a basic protocol, a Resolve protocol, and an Abort protocol.

[0036] The terminal 100A and the terminal 100B exchange multiple values ​​that they each possess using the basic protocol. During the execution of the protocol, the terminal 100A and the terminal 100B can each invoke the Resolve protocol and the Abort protocol only within their respective invocation periods.

[0037] If the Resolve protocol is invoked within the invocation period, the protocol is forcibly completed by the TTP 200. Also, if the Abort protocol is invoked within the invocation period, the protocol is forcibly stopped by the TTP 200, and each value is returned to its location before the start of the protocol.

[0038] During execution of the protocol, a push is made as a server push from the TTP 200. A terminal that receives the server push may return an acknowledgement to the TTP 200 as a receipt report.

[0039] Note that the communication between the terminal 100A and the terminal 100B may be face-to-face communication or non-face-to-face communication. Furthermore, in the present embodiment, as an example, a case where a protocol is executed between the terminal 100A and the terminal 100B is shown, but this is not limiting. The protocol according to the present embodiment may also be executed among three or more parties.

[0040] Furthermore, the entity that executes the protocol in this embodiment is not limited to a terminal that includes an SE. For example, a server that includes an HSM (Hardware Security Module) may execute the protocol in this embodiment.

[0041] Both the server and the terminal are examples of "entities." The SE and the HSM may be called a secure unit. The terminal 100A, the terminal 100B, and the TTP 200 may be called a first device, a second device, and a third device, respectively.

[0042] In this embodiment, the following execution environment is assumed to ensure the security of the protocol.

[0043] Notifications from TT200 are sent via server push or similar, and are received when the party (terminal) goes online. The nonce is generated within the secure element. After the protocol is completed, the observer deletes the deletion proof. If a certain amount of time passes without any interaction, a timeout occurs and the protocol ends.

[0044] The basic protocol, the Resolve protocol, and the Abort protocol will be described in detail below.

[0045] (First embodiment: Basic protocol) The basic protocol executed in the system shown in Fig. 1 will be described with reference to the sequence diagram shown in Fig. 3. In the following description, characters representing lists consisting of multiple elements are shown in bold in the drawings, but in the text of the specification, for convenience of description, characters representing lists consisting of multiple elements will be enclosed in {}.

[0046] As public information for executing the basic protocol, the user ID of the terminal 100A and the user ID of the terminal 100B are publicly disclosed as A and B, respectively, and the signature verification key (public key) is publicly disclosed as spk (each is securely shared). Ｐ is the signature verification key of P. Ｐ is P's private signing key.

[0047] For each value v, DelID ｖ =H(v, n1, H(n2)), DelSig ｖ =sign(DelID ｖ , ssk ＳＥ ) In other words, for each value held by the party (user P), ｖ =sign(DelID ｖ , ssk ＳＥＰ ) This is DelID ｖ Private key ssk for ＳＥＰ Each DelSig ｖ DelID is assigned to the secure element for each value. ｖ It is created by sending it and having it signed.

[0048] {DelID Ａ}=DelID ｖＡ１ , ..., DelID ｖＡｎ and {DelID Ｂ}=DelID ｖＢ１ , ..., DelID ｖＢｍ is.

[0049] {DelSigＡ} = DelSig Ａ１ , ..., DelSig Ａｎ and {DelSig Ｂ} = DelSig Ｂ１ , ..., DelSig Ｂｍ {DelSig Ａ} corresponds to the deletion proof of A, and {DelSig Ｂ} corresponds to B's deletion proof.

[0050] The transaction ID TID is TID=<DelID ｖＡ１ , ..., DelID ｖＡｎ , DelID ｖＢ１ , ..., DelID ｖＢｍ , vA, vB, A, B, n1, H(n2)>. That is, TID=<{DelID Ａ}, {DelID Ｂ}, vA, vB, A, B, n1, H(n2)>.

[0051] {vA} = vA １ , ..., vA ｎ , <{vA}>=<vA １ , ..., vA ｎ > and {vB} = vB １ , ..., vB ｍ , <{vB}>=<vB １ , ..., vB ｍ >It is.

[0052] Message m2 (acceptance of proposal) is, for example, m2:<TID, H(n2), DelSig ｖＢ１ , ..., DelSig ｖＢｍ , sign(<TID, H(n2), DelSig ｖＢ１ , ..., DelSig ｖＢｍ >, ssk Ｂ )>.

[0053] As shown in the figure, a resolvable section and an abstractable section are set.

[0054] In S1 (step 1) of FIG. 3, the OA 110A in the terminal 100A generates a random number n1.

[0055] In S2, OA 110A proposes a trade to OB 110B at terminal 100B by sending message m1:<<<{vA}>,<{vB}>,n1>. This message m1 proposes exchanging {vA} and {vB}.

[0056] The OB 110B confirms the transaction details in S3, generates a random number n2 in S4, and deletes {vB} from the DB 111B in S5.

[0057] In S6, the OB 110B ｖＢ１ The SEB 120B requests a signature by sending the DelSigv Ｂ１ This process returns the value vB １ ~vB ｍ This is performed for each of the following.

[0058] In S8, the OB 110B sends m2:<TID, H(n2), {DelSig Ｂ}, sign(<TID, {DelSig Ｂ}>, ssk Ｂ )> to accept the proposal. Ｂ is the private key held by the terminal 110B.

[0059] The OA 110A checks (verifies) the signature of m2 in S9, and Ｂ} is confirmed (verified), and if the confirmation is successful, {vA} is deleted from DB 111A in S11.

[0060] In S12, the OA 110A ｖＡ１ The SEA 120A requests a signature by sending the DelSigv Ａ１ This process returns the value vA １ ~vA ｎ It is held at.

[0061] In S14, the OA 110A sends m3:<TID, {DelSig Ａ}, sign(<TID, {DelSig Ａ}>, ssk Ａ )> to confirm receipt.

[0062] OB 110B checks the signature of m3 in S15 and Ａ} is checked, and if the checks are successful, {vA} is stored in DB 111B in S17.

[0063] In S18, the OB 110B confirms the completion of the transaction by sending m4:n2 to the OA 110A.

[0064] In S19, the OA 110A determines whether TID=<{DelID Ａ}, {DelID Ｂ}, vA, vB, A, B, n1, H(n2)>. If the confirmation is successful, in S20, the OA 110A stores {vB} in the DB 111A.

[0065] (First embodiment: Resolve protocol) Next, the Resolve protocol will be described with reference to the sequence diagram of FIG. 4. The Resolve protocol is a protocol for forcibly completing a transaction. Here, an example will be described in which A makes a complaint to B (a complaint requesting that the transaction be completed). Note that, in response to a message m sent by party P, msig ｍ =sign(m,ssk ｐ ) However, the message signature itself is not included in the m to be signed.

[0066] In S101, the OA 110A sends to the TTP 200 mr1:<"resolve", TID, {DelSig Ａ}, m2, msig ｍｒ１ > to request completion of the transaction.

[0067] The TTP 200 checks the signature of mr1 in S102 and checks the signature of m2 in S103. In addition, the TTP 200 checks the signature of mr1 in S104. Ａ}, all deletion certificates corresponding to {DelSig Ａ}, and in S105, Ａ} signature is checked, and if the check is successful, the process proceeds to S106.

[0068] In S106, the TTP 200 sends the following to the OA 110A: mr2:<"allow resolve", TID, msig ｍｒ２ > to allow the transaction to be completed.

[0069] In S107, the OA 110A stores {vB} in the DB 111A. S107 is an operation that the TTP 200 forces on the OA 110A.

[0070] In addition, in S108, the TTP 200 transmits a Resolve notification as a server push to the terminal 100B. The Resolve notification is a notification indicating that the transaction has been completed.

[0071] (First embodiment: Abort protocol) Next, the Abort protocol will be described with reference to the sequence diagram in Fig. 5. The Abort protocol is a protocol for forcibly aborting a transaction. Here, an example will be described in which B makes a complaint to A (a complaint requesting that the transaction be aborted).

[0072] In S201, the OB 110B sends to the TTP 200, ma1:<“abort”, TID, {DelSig Ｂ}, sign(<"abort", TID, {DelSig Ｂ}>, ssk Ｂ ) to request the cancellation of the transaction.

[0073] The TTP 200 checks the signature of ma1 in S202, and checks the {DelID Ｂ}, all deletion certificates corresponding to {DelSig Ｂ}, and in S204, Ｂ} signature is checked, and if the check is successful, the process proceeds to S205.

[0074] In S205, the TTP 200 sends the following to the OB 110B: ma2:<“allow abort”, TID, sign(<“allow abort”, TID>, ssk ＴＴＰ ) > to allow the transaction to be cancelled.

[0075] In S206, the OB 110B stores {vB} in the DB 111B. S206 is an operation that the TTP 200 forces on the OB 1110B.

[0076] In addition, in S207, the TTP 200 transmits an Abort notification as a server push to the OA 110A. The Abort notification is a notification indicating that the transaction has been cancelled.

[0077] In S208, if {vA} has been deleted, the OA 110A stores {vA} in the DB 111A. S208 is an operation that the TTP 200 forces on the OA 110A.

[0078] (First embodiment: effects of the embodiment, etc.) By combining the three protocols described in the first embodiment, value can be exchanged fairly between multiple entities even offline. Furthermore, since each entity verifies each other's deletion proofs within the observer during a transaction, it is impossible to fraudulently increase value (such as by declaring that something has been deleted when it has not, and receiving value from the other party).

[0079] Furthermore, multiple values ​​can be exchanged in a single transaction on a single device. In addition, since deletion proofs are designed to be created for each value, values ​​can be treated uniformly in a single transaction even if their format or storage method is different. This is particularly effective when there is an app on a smartphone that aggregates multiple apps, and the issuer and storage location of value differ between each app. However, use cases are not limited to these cases.

[0080] Since each entity can invoke either the Resolve protocol or the Abort protocol, even if one of the entities is malicious or the transaction is halted midway due to a network failure, etc., the protocol can be terminated in a fair state (a state in which both parties have exchanged value, or a state before the value exchange). In other words, when the protocol is terminated, the state will be one of the two states (a) and (b) shown in Figure 6.

[0081] In particular, communication with the TTP 200 occurs only in the event of a dispute, and the TTP 200 only needs to verify the signature received for dispute resolution. Therefore, the basic protocol can be used with minimal communication even during network failures such as disasters. In addition, both the Resolve protocol and the Abort protocol can be used with minimal communication between the entity and the TTP 200.

[0082] When the Resolve protocol or the Abort protocol is executed, only the transaction ID and the corresponding deletion proof are passed to the TTP 200, and therefore the TTP 200 cannot obtain any information about the value exchanged between the entities.

[0083] Furthermore, by configuring the system so that a user who receives a server push returns an acknowledgement to the TTP 200, the TTP 200 can also check the arrival status of the server push, and it is possible to prevent the server push from accumulating on the server.

[0084] (First Embodiment: Use Case) The application of the protocol group according to this embodiment is not limited to a specific field, but examples of application include e-commerce, PvP payments, DvP payments, currency exchange, etc. Furthermore, multiple values ​​issued by different sources can be handled uniformly in a single transaction.

[0085] (First embodiment: Patterns when a network failure occurs) Hereinafter, patterns when a network failure occurs will be described.

[0086] (1) Patterns in which usable communication paths are limited (assuming a disaster, etc.) As patterns in which usable communication paths are limited, there are, for example, the following six patterns (1-1 to 1-6).

[0087] <1-1> Pattern 1-1 corresponds to a case where local communication is cut off, and communication is interrupted only between terminal 100A and terminal 100B. Only Resolve and Abort can be used, but in this pattern, communication does not even begin. Note that a case where communication is interrupted midway through the protocol corresponds to a timing anomaly pattern.

[0088] <1-2> Pattern 1-2 corresponds to a case where the power supply of the terminal 100A is lost in the middle of the protocol, and communication is interrupted between the terminal 100A and the terminal 100B, and between the terminal 100A and the TTP 200. The terminal 100B can only use Resolve and Abort, but communication does not start in the first place. A case where communication is interrupted in the middle of the protocol corresponds to a timing anomaly pattern.

[0089] <1-3> Pattern 1-3 corresponds to a case where the power supply of terminal 100B is lost in the middle of the protocol, and communication is interrupted between terminal 100A and terminal 100B, and between terminal 100B and TTP 200. Terminal 100A can only use Resolve and Abort, but communication does not start in the first place. A case where communication is interrupted in the middle of the protocol corresponds to a timing anomaly pattern.

[0090] <1-4> Pattern 1-4 corresponds to a case where the terminal 100A is out of internet communication, and is a pattern where communication is out only between the terminal 100A and the TTP 200. The terminal 100A cannot perform either Resolve or Abort, but is able to perform local transactions.

[0091] <1-5> Pattern 1-5 corresponds to a case where the terminal 100B is out of internet communication, and is a pattern where communication is out only between the terminal 100B and the TTP 200. The terminal 100B cannot perform either Resolve or Abort, but is able to perform local transactions.

[0092] <1-6> Pattern 1-6 corresponds to a case where the TTP 200 (server) is down, and communication is interrupted between both the terminal 100A and the TTP 200 and between the terminal 100B and the TTP 200.

[0093] (2) Timing-related abnormality patterns (assuming a poor communication environment) (3) Regarding Resolve / Abort The terminal 100A can only execute Resolve, and the terminal 100B can only execute Abort. However, the Abort section is the section from the deletion of {vB} to the reception of m3.

[0094] Second Embodiment Next, a second embodiment will be described. Matters that are the same between the first embodiment and the second embodiment may be omitted or briefly described.

[0095] Second Embodiment: System Configuration Example In this embodiment, the basic protocol and the Resolve protocol will be described. The configuration example and premise of the system in which these two protocols are executed are the same as those in the first embodiment, and are as described with reference to FIG.

[0096] (Second embodiment: Outline of protocol) An outline of the protocol executed in the above-described system will be described below. The protocol in this embodiment includes a basic protocol and a Resolve protocol.

[0097] The terminal 100A and the terminal 100B exchange the multiple values ​​that they each possess using the basic protocol. The terminal 100A and the terminal 100B can each invoke the Resolve protocol during execution of the protocol, but only during an invocation period.

[0098] If the Resolve protocol is invoked within the invocation period, the TTP 200 will forcibly complete the protocol.

[0099] During execution of the protocol, a push is made as a server push from the TTP 200. A terminal that receives the server push may return an acknowledgement to the TTP 200 as a receipt report.

[0100] Note that the communication between the terminal 100A and the terminal 100B may be face-to-face communication or non-face-to-face communication. Furthermore, in the present embodiment, as an example, a case where a protocol is executed between the terminal 100A and the terminal 100B is shown, but this is not limiting. The protocol according to the present embodiment may also be executed among three or more parties.

[0101] Furthermore, the entity that executes the protocol in this embodiment is not limited to a terminal that includes an SE. For example, a server that includes an HSM (Hardware Security Module) may execute the protocol in this embodiment.

[0102] Both the server and the terminal are examples of "entities." The SE and the HSM may be called a secure unit. The terminal 100A, the terminal 100B, and the TTP 200 may be called a first device, a second device, and a third device, respectively.

[0103] In this embodiment, the following execution environment is assumed to ensure the security of the protocol.

[0104] Notifications from TT200 are sent via server push or similar, and are received when the party (terminal) goes online. The nonce is generated within the secure element. After the protocol is completed, the observer deletes the deletion proof. If a certain amount of time passes without any interaction, a timeout occurs and the protocol ends.

[0105] The basic protocol and the Resolve protocol will be described in detail below.

[0106] (Second embodiment: Basic protocol) In the second embodiment, the basic protocol executed in the system shown in FIG. 1 will be described with reference to the sequence diagrams shown in FIGS. 7 and 8. The meanings of the characters are the same as in the first embodiment. Note that the characters used in the second embodiment are AgrSig, ｐ =sign(TID, ssk ｐ )

[0107] Furthermore, as shown in FIG. 8, a resolvable section is set.

[0108] 7, the OB 110B in the terminal 100B requests the SEB 120B to generate a random number. In S2, the SEB 120B generates a random number n2 and transmits n2 to the OB 110B.

[0109] In S4, the OB 110B transmits m0:H(n2) to the OA 110A of the terminal 100A. In S5, the OA 110A requests the SEA 120A to generate a random number. The SEA 120A generates a random number n1 in S6 and transmits n1 to the OA 110A in S7.

[0110] The above steps S1 to S7 are the preparation phase, during which information such as public keys and possessed values ​​is also shared.

[0111] In S8, the OA 110A sends m1:<<{vA}>,<{vB}>,n1,AgrSig to the OB 110B in the terminal 100B. Ａ >, a transaction proposal is made. This message m1 is a message proposing to exchange {vA} and {vB}.

[0112] The OB 110B confirms the transaction details in S9, and deletes {vB} from the DB 111B in S10. ｖＢ１ The SEB 120B requests a signature by sending the DelSigv Ｂ１ This process returns the value vB １ ~vB ｍ This is done in each of the following areas.

[0113] In S13 of FIG. 8, the OB 110B sends m2:<TID, {DelSig Ｂ}, AgrSig Ｂ , sign(<TID, {DelSig Ｂ}>, ssk Ｂ )> to accept the proposal.

[0114] The OA 110A checks (verifies) the signature of m2 in S14, and Ｂ} is confirmed (verified), and if the confirmation is successful, {vA} is deleted from DB 111A in S16.

[0115] In S17, the OA 110A ｖＡ１ The SEA 120A requests a signature by sending the DelSigv Ａ１ This process returns the value vA １ ~vA ｎ It is held at.

[0116] In S19, the OA 110A sends m3:<TID, {DelSig Ａ}, sign(<TID, {DelSig Ａ}>, ssk Ａ )> to confirm receipt.

[0117] OB 110B checks the signature of m3 in S20 and Ａ} is checked, and if the checks are successful, {vA} is stored in DB 111B in S22.

[0118] In S23, the OB 110B confirms the completion of the transaction by sending m4:n2 to the OA 110A.

[0119] In S24, the OA 110A determines whether TID=<{DelID Ａ}, {DelID Ｂ}, vA, vB, A, B, n1, H(n2)>. If the confirmation is successful, in S25, the OA 110A stores {vB} in the DB 111A.

[0120] (Second embodiment: Resolve protocol) Next, the Resolve protocol will be described with reference to the sequence diagram of FIG. 9. The Resolve protocol is a protocol for forcibly completing a transaction. Here, an example will be described in which A makes a complaint to B (a complaint requesting that the transaction be completed). Note that in the second embodiment, the Resolve protocol is symmetric between terminal 100A and terminal 100B. FIG. 9 shows the case of "a complaint from A to B" as an example, but by replacing A with B and B with A in FIG. 9, the procedure becomes that for "a complaint from B to A."

[0121] In S101, the OA 110A sends to the TTP 200 mr1:<"resolve", TID, {DelSig Ａ}, AgrSig Ｂ , msig ｍｒ１ > to request completion of the transaction.

[0122] The TTP 200 checks the signature of mr1 in S102, and checks the AgrSig Ｂ In S104, the TTP 200 checks the signature of {DelID Ａ}, all deletion certificates corresponding to {DelSig Ａ}, and in S105, Ａ} signature is checked, and if the check is successful, the process proceeds to S106.

[0123] In S106, the TTP 200 sends the following to the OA 110A: mr2:<“allow resolve”, TID, sign(<“allow resolve”, TID>, ssk ＴＴＰ )) to allow the transaction to be completed.

[0124] In S107, the OA 110A stores {vB} in the DB 111A. In addition, in S108, the TTP 200 sends a Resolve notification to the OA 110B as a server push. The Resolve notification is a notification indicating that the transaction has been completed.

[0125] In S109, the OB 110B checks whether vB has been deleted from the DB 111B, and if not, deletes {vB} from the DB 111B. In S110, the OB 110B stores {vA} in the DB 111B. S107, S109, and S110 are operations forced by the TTP 200.

[0126] (Second embodiment: effects of the embodiment, etc.) By combining the two protocols described in the second embodiment, value can be exchanged fairly between multiple entities even offline. Furthermore, since each entity verifies each other's deletion proofs within the observer during a transaction, it is impossible to fraudulently increase value (such as by declaring that something has been deleted when it has not, and receiving value from the other party).

[0127] Furthermore, multiple values ​​can be exchanged in a single transaction on a single device. In addition, since deletion proofs are designed to be created for each value, values ​​can be treated uniformly in a single transaction even if their format or storage method is different. This is particularly effective when there is an app on a smartphone that aggregates multiple apps, and the issuer and storage location of value differ between each app. However, use cases are not limited to these cases.

[0128] Since each entity can invoke the Resolve protocol, even if one of the entities is malicious or the transaction is halted midway due to a network failure, etc., the protocol can be terminated in a fair state (a state in which both parties have exchanged value, or a state before the value exchange). In other words, when the protocol is terminated, the state will be one of the two states (a) and (b) shown in Figure 6.

[0129] In particular, communication with the TTP 200 occurs only in the event of a dispute, and the TTP 200 only needs to verify the signature received for dispute resolution. Therefore, the basic protocol can be used with minimal communication even during network failures such as disasters. In addition, the Resolve protocol can be used with only minimal communication between the entity and the TTP 200.

[0130] When the Resolve protocol is executed, only the transaction ID and the corresponding deletion proof are passed to the TTP 200, and therefore the TTP 200 cannot obtain any information about the value exchanged between the entities.

[0131] Furthermore, unlike the existing method disclosed in Non-Patent Document 1, the technology according to the second embodiment allows both the transaction proposer and the transaction recipient to execute Resolve, which allows both entities to have the option of completing the transaction.

[0132] Furthermore, by configuring the system so that a user who receives a server push returns an acknowledgement to the TTP 200, the TTP 200 can also check the arrival status of the server push, and it is possible to prevent the server push from accumulating on the server.

[0133] (Second embodiment: Use cases) As with the first embodiment, the application of the protocol group according to this embodiment is not limited to a specific field, but examples of application include e-commerce, PvP payments, DvP payments, currency exchange, etc. Furthermore, multiple values ​​issued by different sources can be handled uniformly in a single transaction.

[0134] (Second embodiment: Patterns when a network failure occurs) Hereinafter, patterns when a network failure occurs will be described.

[0135] (1) Patterns in which usable communication paths are limited (assuming a disaster, etc.) As patterns in which usable communication paths are limited, there are, for example, the following six patterns (1-1 to 1-6).

[0136] <1-1> Pattern 1-1 corresponds to a case where local communication is cut off, and communication is interrupted only between terminal 100A and terminal 100B. Only Resolve can be used, but in this pattern, communication does not even begin. Note that a case where communication is interrupted midway through a protocol corresponds to a timing anomaly pattern.

[0137] <1-2> Pattern 1-2 corresponds to a case where the power supply of the terminal 100A is turned off in the middle of the protocol, and communication is interrupted between the terminal 100A and the terminal 100B, and between the terminal 100A and the TTP 200. The terminal 100B can only use Resolve, but communication does not start in the first place. A case where communication is interrupted in the middle of the protocol corresponds to a timing anomaly pattern.

[0138] <1-3> Pattern 1-3 corresponds to a case where the power supply of terminal 100B is lost in the middle of the protocol, and communication is interrupted between terminal 100A and terminal 100B, and between terminal 100B and TTP 200. Terminal 100A can only use Resolve, but communication does not start in the first place. A case where communication is interrupted in the middle of the protocol corresponds to a timing anomaly pattern.

[0139] <1-4> Pattern 1-4 corresponds to a case where the terminal 100A is out of internet communication, and is a pattern where communication is out only between the terminal 100A and the TTP 200. The terminal 100A cannot perform Resolve, but is able to perform local transactions.

[0140] <1-5> Pattern 1-5 corresponds to a case where the terminal 100B is out of internet communication, and is a pattern where communication is out only between the terminal 100B and the TTP 200. The terminal 100B cannot perform Resolve, but is able to perform local transactions.

[0141] <1-6> Pattern 1-6 corresponds to a case where the TTP 200 (server) is down, and communication is interrupted between both the terminal 100A and the TTP 200 and between the terminal 100B and the TTP 200.

[0142] (2) Timing-Based Abnormal Patterns (Assuming a Bad Communication Environment) (3) Regarding Resolve Both terminal 100A and terminal 100B can perform Resolve from the time the deletion certificate is sent until the value is received.

[0143] (First and Second Embodiments: Hardware Configuration Examples) Any of the devices (terminals 100A / 100B, TTP 200) described in the first and second embodiments can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0144] That is, the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and memory built into a computer. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0145] Fig. 10 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 10 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0146] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0147] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0148] The following additional notes are provided regarding the above-described embodiments.

[0149] <Additional Notes> (Additional Note 1) A system comprising a first device having a plurality of first values ​​and a second device having a plurality of second values, wherein the first device comprises a first storage unit and a first secure unit, and the second device comprises a second storage unit and a second secure unit, wherein the first device sends to the second device a first message proposing to exchange the plurality of first values ​​for the plurality of second values, the second device deletes the plurality of second values ​​from the second storage unit, and transmits a signature for the plurality of second values ​​generated by the second secure unit to the first device as a second deletion proof, and the first device verifies the second deletion proof, deletes the plurality of first values ​​from the first storage unit, and transmits a signature for the plurality of first values ​​generated by the first secure unit to the second device as a first deletion proof. (Supplementary Item 2) The system according to Supplementary Item 1, wherein the first device sends a message to a third device requesting completion of the transaction with the second device, the message including the first deletion proof, the third device verifies the first deletion proof, sends a message to the first device permitting completion of the transaction, and sends a notification to the second device indicating that the transaction has been completed, and the first device stores the plurality of second values ​​in the first storage unit. (Supplementary Item 3) The system according to Supplementary Item 1, wherein the second device sends a message to a third device requesting cancellation of the transaction with the first device, the message including the second deletion proof, the third device verifies the second deletion proof, sends a message to the second device permitting cancellation of the transaction, and sends a notification to the first device indicating that the transaction has been cancelled, the second device stores the plurality of second values ​​in the second storage unit, and the first device stores the plurality of first values ​​in the first storage unit.(Supplementary Paragraph 4) A value exchange method in a system comprising a first device having a plurality of first values ​​and a second device having a plurality of second values, wherein the first device comprises a first storage unit and a first secure unit, and the second device comprises a second storage unit and a second secure unit, the first device sending a first message to the second device proposing to exchange the plurality of first values ​​for the plurality of second values, the second device deleting the plurality of second values ​​from the second storage unit and transmitting a signature for the plurality of second values ​​generated by the second secure unit to the first device as a second deletion proof, the first device verifying the second deletion proof, deleting the plurality of first values ​​from the first storage unit, and transmitting a signature for the plurality of first values ​​generated by the first secure unit to the second device as a first deletion proof.

[0150] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0151] 100A, 100B Terminal 110A OA 110B OB 111A, 111B DB 120A SEA 120B SEB 200 TTP 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A system comprising a first device having a plurality of first values ​​and a second device having a plurality of second values, wherein the first device has a first storage unit and a first secure unit, and the second device has a second storage unit and a second secure unit, wherein the first device sends a first message to the second device proposing to exchange the plurality of first values ​​for the plurality of second values, the second device deletes the plurality of second values ​​from the second storage unit and sends a signature for the plurality of second values ​​generated by the second secure unit to the first device as a second deletion evidence, and the first device verifies the second deletion evidence, deletes the plurality of first values ​​from the first storage unit, and sends a signature for the plurality of first values ​​generated by the first secure unit to the second device as a first deletion evidence.

2. The system described in claim 1, wherein the first device sends a message to a third device requesting completion of the transaction with the second device, the message including the first deletion proof; the third device verifies the first deletion proof, sends a message to the first device authorizing completion of the transaction, and sends a notification to the second device indicating that the transaction has been completed; and the first device stores the plurality of second values ​​in the first storage unit.

3. The system described in claim 1, wherein the second device sends a message to the third device requesting the cancellation of the transaction with the first device, the message including the second deletion proof; the third device verifies the second deletion proof, sends a message to the second device authorizing the cancellation of the transaction, and sends a notification to the first device indicating that the transaction has been canceled; the second device stores the plurality of second values ​​in the second storage unit; and the first device stores the plurality of first values ​​in the first storage unit.

4. A value exchange method in a system comprising a first device having a plurality of first values ​​and a second device having a plurality of second values, wherein the first device comprises a first storage unit and a first secure unit, and the second device comprises a second storage unit and a second secure unit, the first device sending a first message to the second device proposing to exchange the plurality of first values ​​for the plurality of second values, the second device deleting the plurality of second values ​​from the second storage unit and transmitting a signature for the plurality of second values ​​generated by the second secure unit to the first device as a second deletion proof, and the first device verifying the second deletion proof, deleting the plurality of first values ​​from the first storage unit, and transmitting a signature for the plurality of first values ​​generated by the first secure unit to the second device as a first deletion proof.

Images