Content protection system

Abstract

To improve safety of a content without using a concentration system.SOLUTION: A connection device 200A receives a purchasing request notification containing a public key via a block chain network 100 from a connection device 200B, and transmits an encrypted content key obtained by encrypting the content key by using the public key to the connection device 200B via the block chain network 100. The connection device 200B transmits the purchasing request notification to the connection device 200A, and transmits transmission source information indicating a transfer destination of a content to the block chain network 100. Further, the connection device 200B is decoded by a secret key holding the encrypted content key from the connection device 200A. The block chain network 100 changes a holder indicated by holder management information to the transfer destination in the case where the encrypted content key is received.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a content protection system.

Background Art

[0002] Attention has been drawn to a technology called blockchain, which can store digital data handled by information devices in a distributed and extremely difficult-to-tamper-with format. Conventionally, blockchain has been utilized with fungible tokens, which are tokens representing monetary value such as virtual currency like Bitcoin. In recent years, however, things different from monetary value, such as non-fungible tokens (NFTs), have been represented. The number of tokens issued on a blockchain can have an upper limit set by the issuer, and the official holders of those tokens can be easily identified. For this reason, since it is possible to impart scarcity to digital data as well, blockchain has been attracting attention in fields such as art.

[0003] However, registering large-sized content such as moving image data and high-definition still image data on a blockchain is not practical from the perspective of usage costs and the like. For this reason, usually, large-sized content is stored in a place separate from the blockchain, and a URL indicating the storage destination of the data is registered in the NFT stored in the blockchain.

[0004] Currently, since many NFTs are used on public blockchains, anyone can refer to an NFT. Therefore, by referring to an NFT, anyone can access the content stored in a place separate from the blockchain, so there are problems with the confidentiality and security of the content.

[0005] In response to the above problems, Patent Document 1 discloses a technique of mounting an authentication function for determining whether a user who requests access to content is a legitimate user on a server that manages the content. In this technique, when the user who requests access is a legitimate user, access to the content is permitted.

Prior Art Documents

Patent Documents

[0006]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0007] However, in the technique described in Patent Document 1, since a centralized system having a server for managing content is adopted, an administrator for operating the server is required, resulting in a problem of high cost. In addition, because blockchain is originally intended to operate in a distributed environment and the use of distributed systems utilizing P2P technologies such as IPFS (Interplanetary File System) is becoming widespread, a mechanism that is not a centralized system that depends on a specific operator for content management is desired.

[0008] An object of the present disclosure is to provide a content protection system capable of improving the security of content without using a centralized system.

Means for Solving the Problems

[0009] A content protection system according to one aspect of the present disclosure includes a blockchain network composed of a plurality of computers and a plurality of connection devices connected to the blockchain network, and manages content encrypted in a form decryptable with a content decryption key and stored in a predetermined storage location. In the content protection system, a first connection device, which is one of the plurality of connection devices, holds the content decryption key, and receives, via the blockchain network, a usage request for using the content from a second connection device, which is a connection device different from the first connection device, the usage request including a public key corresponding to a secret key managed by the second connection device. The first connection device encrypts the content decryption key using the public key included in the usage request, and transmits the encrypted content decryption key to the second connection device via the blockchain network. The second connection device holds the secret key, transmits the usage request to the first connection device via the blockchain network, transmits user information indicating a user who grants the usage right of the content to the blockchain network, receives the encrypted content decryption key from the first connection device via the blockchain network, decrypts the encrypted content decryption key using the secret key to obtain the content decryption key. The blockchain network stores user management information indicating users who can use the content, and when receiving the encrypted content decryption key, changes the user indicated by the user management information to the user who has the usage right indicated by the user information.

Effect of the Invention

[0010] According to the present invention, it is possible to improve the security of content without using a centralized system.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Mode for Carrying Out the Invention

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. The present disclosure includes a technique in which a user having the right to use content can determine whether or not to access the content managed by a blockchain.

[0013] FIG. 1 is a diagram showing the overall configuration of a content protection system according to an embodiment of the present disclosure. The content protection system 1 shown in FIG. 1 is a system for managing content, and includes a blockchain network 100 composed of a plurality of nodes 101, a blockchain network connection device 200 and a content server 300 connected to the blockchain network 100, and a connection terminal 400 connected to the blockchain network connection device 200. The blockchain network 100 and the blockchain network connection device 200 constitute a blockchain system. The node 101 is a computer system such as a server. The connection terminal 400 is, for example, a PC or a smartphone.

[0014] A user 2 who uses the content protection system 1 uses the blockchain network 100 via the blockchain network connection device 200. The user 2 may directly use his / her own blockchain network connection device 200, or may use the blockchain network connection device 200 provided by a connection service provider such as a company via his / her own connection terminal 400. When directly using his / her own blockchain network connection device 200, the user 2 installs a predetermined program on a terminal device such as his / her own PC or smartphone, and uses the terminal device as the blockchain network connection device 200. The blockchain network connection device 200 of the connection service provider is constructed by one or more servers and provides a connection service to the blockchain network 100 to the user 2.

[0015] In response to a request from the blockchain network connection device 200, the blockchain network 100 issues and trades NFTs, which are tokens to be traded between users 2. In this embodiment, NFTs are issued in association with content such as image data (still image data and moving image data) or items used in games. The content corresponding to the NFT is not incorporated into the NFT but is stored in a content server 300, which is an external storage device. Since the NFT is associated with the content, the content may be the object of the transaction.

[0016] FIG. 2 is a diagram showing the configuration of the blockchain network connection device 200. As shown in FIG. 2, the blockchain network connection device 200 includes a memory 201, a CPU 202, a storage interface 203, a network interface 204, an input / output interface 205, and an auxiliary storage device 206, and each part is interconnected via a bus 207. In FIG. 2, the interface is denoted as I / F.

[0017] The memory 201 stores a program 211 that defines the operation of the CPU 202. The memory 201 also stores various pieces of information (not shown) used or generated by the program.

[0018] The CPU 202 is a processor that reads the program 211, which is a computer program stored in the memory 201, and executes the read program 211 to realize various functional units. In this embodiment, the CPU 202 realizes an encryption processing unit 500 (see FIG. 3) that executes the encryption processing required when requesting processing from the blockchain network 100.

[0019] The storage interface 203 connects the bus 207 and the auxiliary storage device 206. The input / output interface 205 connects to external devices (not shown) such as display and operation devices like a monitor and a keyboard. The network interface 204 connects to external devices such as the node 101 and the content server 300 via the blockchain network 100 or other networks.

[0020] The auxiliary storage device 206 is, for example, an SSD (Solid State Drive) or an HDD (Hard Disk Drive), and stores various information. For example, the auxiliary storage device 206 stores user management information 212 that manages by associating key information used in encryption processing and user information regarding the user. Since the auxiliary storage device 206 is often easily removable, it is desirable that the user management information 212 be stored encrypted.

[0021] Note that some of the CPU 202 etc. are provided with a tamper-resistant area which is a tamper-resistant region. In this case, the storage of the user management information 301 and the processing by the encryption processing unit 500 may be executed within the tamper-resistant area. Similarly, a tamper-resistant device which is an external device having tamper resistance such as a hardware wallet may be used. In this case, the tamper-resistant device is connected via, for example, the storage interface 203, the network interface 204, or the input / output interface 205, and executes the storage of the user management information 301 and the processing by the encryption processing unit 500.

[0022] Figure 3 is a diagram showing the configuration of the encryption processing unit 500. The encryption processing unit 500 shown in Figure 3 has a decryption processing unit 510, a key random number generation unit 520, and a key management unit 530. The decryption processing unit 510 executes encryption processing and decryption processing of various information. The key random number generation unit 520 generates key information (such as public key encryption and symmetric key encryption) and random numbers used in encryption processing. The key management unit 530 manages the key information and random numbers generated by the key random number generation unit 520.

[0023] The node 101 and the connection terminal 400 have the same configuration as the blockchain network connection device 200. The program 211 stored in the memory 201 of the node 101 is a smart contract 102 that causes the CPU 202 to execute the process of issuing and registering / managing NFTs. The process performed by the smart contract 102 is usually performed by multiple nodes 101 working together. Information that the smart contract 102 constantly refers to is registered as a block in each node 101 that constitutes the blockchain network 100. EXAMPLES

[0024] 4 is an activity diagram for explaining an example of processing of the content protection system 1 according to the first embodiment of the present disclosure. In the following, the transferor user 2 who provides the content (more specifically, the NFT corresponding to the content) is referred to as user A, and the transferee user 2 who acquires the content, i.e., the usage right grantor who is granted the usage right of the content, is referred to as user B. In addition, the blockchain network connection device 200 used by user A is referred to as connection device 200A, and the blockchain network connection device 200 used by user B is referred to as connection device 200B.

[0025] User B may acquire the content for a fee or free of charge. User A may simply grant user B the right to use the content, or may transfer the content to user B by granting user B the right to use the content and deleting user A's right to use the content. In the following explanation, the case where content is transferred from user A to user B for a fee (i.e., when user B purchases content from user A) will be explained, but the process related to the transfer of money will be omitted. In addition, various information generated by the blockchain network connection device 200 is appropriately managed (storage, etc.) by the key management unit 530, but in the following explanation, the process of managing information in the blockchain network connection device 200 may be omitted.

[0026] First, user A, who is the content provider, sends the content prepared by generating it or the like to the connection device 200A. The key random number generation unit 520 of the encryption processing unit 500 of the connection device 200A generates the hash value of the content as the content verification hash value (step S2000). As will be described later, the content verification hash value is used by user B who has purchased the encrypted content to verify the validity of the content.

[0027] The key random number generation unit 520 generates a content encryption key, which is an encryption key for encrypting and protecting the content (step S2010). The encryption / decryption processing unit 510 encrypts the content using the content encryption key (step S2020). The encryption method for encrypting the content is not limited as long as it can protect the content, but here it is the symmetric key encryption method. That is, the content encryption key is common with the content decryption key for decrypting the content. Hereinafter, the content encryption key (content decryption key) may also be referred to as the content key. The content key is managed (for example, held) by the key management unit 530.

[0028] The encryption / decryption processing unit 510 stores the encrypted content, i.e., the encrypted content, in the content server 300, and sends a registration request for registering the content information related to the content to the smart contract 102 of the node 101 (step S2030). The registration request includes the content information. Also, the content information includes the hash value of the content and the reference destination information indicating the storage location of the content.

[0029] The smart contract 102 issues an NFT corresponding to the registration request and registers it on the blockchain (step S2100). In addition, when user A prepares the content by obtaining the content prepared by another user in the content protection system 1, since the NFT has already been issued, only the necessary information needs to be registered without newly issuing the NFT.

[0030] FIG. 5 is a diagram showing an example of the holder management information included in the NFT. The holder management information 600 shown in FIG. 5 is user management information indicating the holder of the content (that is, the user who can use the content), and has fields 601 to 604.

[0031] Field 601 stores the ID which is the token ID for identifying the NFT. The number of IDs can be set by the issuer who issues the NFT, and in FIG. 5, it is set to 100 as an example. Field 602 stores the holder information indicating the holder who holds the content. At the time of NFT registration, the holder is the content generator or its agent, etc., and at the time of transaction completion, it becomes the transferee of the content. The holder information is, here, the address of the public blockchain network held by an individual, but other information may be used as long as the holder can be uniquely identified.

[0032] Field 603 stores the hash value for content confirmation. If the hash value for content confirmation can be confirmed at other locations such as the content server 300, field 603 may not be necessary. Field 604 stores the reference destination information.

[0033] Note that when one or more contents are shared by multiple holders (when multiple NFTs are associated with the same content), etc., it is not necessary to store the hash value and the reference destination information for each ID. That is, the holder management information has a different configuration according to the content providing method, etc., and in some cases, it may have a separate table.

[0034] By registering the NFT including the holder management information as described above, other users can purchase the NFT.

[0035] Return to the description of FIG. 4. User B, who is the purchaser of the content, instructs the connection device 200B to prepare for purchasing the content. The key random number generation unit 520 of the connection device 200B generates a random number for locking as locking information for generating locking information for locking (access restricting) the content key (step S2200). Then, the key random number generation unit 520 generates a hash value of the random number for locking as locking information (step S2210). Note that the locking information is not limited to a random number, and may be other information such as a random character string.

[0036] In addition, the key random number generation unit 520 generates an authentication public key pair, which is a public key pair used for authentication processing for acquiring the content key (step S2220). Note that the public key pair includes a public key and a private key.

[0037] Since the locking information and the authentication public key pair are used for authentication processing for acquiring the content key, it is desirable that they are not collectively managed by one user management information 212, but are separately managed by different devices or on paper. The specific management method of the locking information and the authentication public key pair may be appropriately determined by User B in consideration of convenience and the like. Also, by providing the locking information and the authentication public key pair to others, the purchased content can be presented to others.

[0038] Thereafter, when purchasing the content, User B instructs the connection device 200B to purchase the content. The connection device 200B transmits a purchase request notification, which is a usage request for requesting the usage (transfer) of the content, to the smart contract 102 in response to the instruction (step S2230).

[0039] FIG. 6 is a diagram showing an example of a purchase request notification. The purchase request notification 700 shown in FIG. 6 has fields 701 to 707.

[0040] Field 701 stores destination information indicating the destination of the purchase request notification 700. In this embodiment, the destination information indicates the address of the smart contract 102 as the destination. Field 702 stores source information indicating the source of the purchase request notification 700. The source information indicates the address of user B, who is the sender (the address of the public blockchain held by user B). Field 703 stores the ID of the NFT corresponding to the content to be purchased.

[0041] Field 704 stores scheduled holder information indicating the scheduled holder who will be the owner of the content after purchase. If the scheduled holder is user B, who is the sender of the purchase request notification, the scheduled holder information indicates the address of user B. If the scheduled holder is user C, another user who will receive the content as a gift from user B, the scheduled holder information indicates the address of user C. However, if user C is not using the blockchain at the time of sending the purchase request notification 700, the address of user C does not exist. In this case, field 704 contains empty information, and for example, separate lock information and authentication information are used to confirm that the purchaser is legitimate. Also, the scheduled holder information may use the address of user B instead of the address of user C. In this case, user B needs to provide not only the lock information and the authentication public key pair but also the information used to generate the address of user B to user C. Note that the same method can be adopted when user B manages the purchased NFT using another address instead of presenting it to user C.

[0042] Field 705 stores lock information. Field 706 stores authentication information for authenticating user B. In this embodiment, the authentication information is the public key included in the authentication public key pair.

[0043] Field 707 stores a sender signature indicating an electronic signature generated based on the information stored in fields 701 to 706. The sender signature is information for proving the legitimacy of the sender of the purchase request notification 700. Usually, an electronic signature is attached to a request for a blockchain. However, in the case of a request that only refers to information, since no data update occurs, an electronic signature is often not attached.

[0044] Return to the description of FIG. 4. When the smart contract 102 receives a purchase request notification, it confirms the legitimacy of the purchase request notification based on the electronic signature of the purchase request notification. If the legitimacy is confirmed, the smart contract 102 registers the holder management information regarding the intended holder based on the purchase request notification. Then, the smart contract 102 sends a wish receipt notification indicating that it has received the purchase request notification to the connection device 200A of user A, who is the content provider (step S2110). Note that instead of the smart contract 102 directly sending the notification, the connection device 200A may periodically check the blockchain log and obtain the wish receipt notification when it detects that the smart contract 102 has received the purchase request notification.

[0045] FIG. 7 is a diagram showing an example of the holder management information. The holder management information 800 shown in FIG. 7 has fields 801 to 805.

[0046] Field 801 stores the ID included in the purchase request notification (the ID of the NFT corresponding to the content for which purchase is desired in the purchase request notification). Field 802 stores the intended holder information included in the purchase request notification. Field 803 stores the lock information included in the purchase request notification. Field 804 stores the authentication information included in the purchase request notification. Field 805 stores the encrypted content key. However, at the time of step 2110, the encrypted content key is not stored in field 805.

[0047] Return to the description of FIG. 4. When the decryption processing unit 510 of the blockchain network connection device 200 of User A receives a desired reception notification, it generates an encrypted content key obtained by encrypting the content key using the public key, which is the authentication information included in the desired reception notification (step S2040). Note that the decryption processing unit 510 may obtain the authentication information by referring to the scheduled holder management information 800. In this case, the desired reception notification may not include the authentication information.

[0048] Subsequently, the decryption processing unit 510 transmits a permission notification indicating permission to purchase the content to the smart contract 102 (step S2050). The permission notification includes the encrypted content key.

[0049] When the smart contract 102 receives the permission notification, it registers the encrypted content key included in the permission notification in the scheduled holder management information and transitions to a state where the change of the content holder is possible, that is, a state where the purchase of the content is possible (step S2120). Further, the smart contract 102 transmits a holder change possible notification indicating that the change of the content holder has become possible to the connection device 200B (step S2130). Here, the availability of content purchase is indicated by the presence or absence of registration of the encrypted content key, but a flag indicating the availability of content purchase may be explicitly included in the scheduled holder management information.

[0050] When the key random number generation unit 520 of the blockchain network connection device 200 of user B receives a holder changeable notification, it generates authentication information for obtaining a content key for decrypting the purchased content and changing the holder information (step S2240). Specifically, the decryption processing unit 510 generates, as authentication information, information obtained by encrypting referenceable information that can be referenced by the smart contract 102 using the private key of the authentication public key pair. The referenceable information is, for example, the address of the smart contract 102, or a constant or character string that can be referenced from the outside defined in the smart contract 102. Also, the authentication information may be information obtained by encrypting the hash value of the referenceable information. That is, the generation of the authentication information is performed by the same process as the generation of an electronic signature.

[0051] The decryption processing unit 510 transmits to the smart contract 102 a holder change request that requests the acquisition of a content key and the change of holder information (step S2250). The holder change request includes authentication information and a lock random number. The lock random number is used as unlock information for unlocking the content key.

[0052] FIG. 8 is a diagram showing an example of a holder change request. The holder change request 900 shown in FIG. 8 has fields 901 to 906.

[0053] Field 901 stores destination information indicating the destination of the holder change request 900. In this embodiment, this destination information indicates the address of the smart contract 102 as the destination. Field 902 stores source information indicating the source of the holder change request 900. The source information indicates the address of user B who is the sender. Field 903 stores the ID of the NFT corresponding to the content to be purchased.

[0054] Field 904 stores the lock random number which is unlock information. Field 905 stores the authentication information. Field 906 stores a source signature indicating an electronic signature generated based on the information stored in fields 901 to 905.

[0055] Note that the sender identified by the source information stored in field 902 and the source name stored in field 906 is the transferee of the content, that is, the subsequent holder (prospective holder). Therefore, when user B presents the content to user C, the sender of the holder change request 900 is user C. For this reason, user C, who has received the content as a present, changes the holder to user C by sending a holder change request using a blockchain network connection device 200 different from user B's connection device 200B. For this reason, at this point in time, user C needs to hold a public blockchain address.

[0056] Returning to the description of FIG. 4, when the smart contract 102 receives a holder change request, it confirms the validity of the holder change request based on the holder change request (step S2140). Specifically, the smart contract 102 acquires, as target information, information (record) having the ID included in the holder change request from the prospective holder management information, and based on the target information, performs the following three confirmation processes.

[0057] In the first confirmation process, the smart contract 102 confirms whether the prospective holder information included in the target information matches the source information included in the holder change request. Note that when user B presents the content to a user who does not have an address (an addressless user), since the target information does not include prospective holder information, the first confirmation process is skipped.

[0058] In the second confirmation process, the smart contract 102 generates a hash value of the unlock information included in the holder change request, and confirms whether the hash value matches the lock information included in the target information. Note that since the original value cannot be obtained from the hash value, users other than those who know the random number for locking cannot succeed in the second confirmation process. Also, the hash value may be calculated from a predetermined range in the random number for locking so as to be resistant to attacks such as brute force.

[0059] In the third verification process, the smart contract 102 verifies the validity of the holder change request by using the authentication information included in the holder change request. Since this authentication information is generated in the same way as the electronic signature generation process, the validity of the holder change request can be verified by the same process as the electronic signature verification process. That is, the smart contract 102 decrypts the authentication information included in the holder change request by using the public key, which is the authentication information included in the future holder management information, and checks whether the decrypted information matches the original referenceable information.

[0060] If all three verification processes are successful, the smart contract 102 determines that the holder change request is a legitimate request. Note that the order in which the three verification processes are executed is not particularly limited. Also, if any of the three verification processes fails, the smart contract 102 discards the holder change request and ends the process. At this time, the smart contract 102 may notify the outside that the verification process has failed, such as by sending an error message to the sender of the holder change request or outputting an error log.

[0061] If the holder change request is a legitimate request, the smart contract 102 updates the holder information in the holder management information with the future holder information in the future holder management information (step S2150).

[0062] Then, the smart contract 102 transmits the encrypted content key included in the scheduled holder management information to the blockchain network connection device 200 of user B, who is the sender of the holder change request. The decryption processing unit 510 of the blockchain network connection device 200 decrypts the encrypted content key using the private key of the public key pair for authentication to obtain the content key (step S2260), and ends the process. Thereby, user B can obtain the encrypted content from the content storage location by referring to the holder management information, and obtain the content by decrypting the encrypted content with the content key. Whether the obtained content is the correct content can be confirmed by whether the hash value of the obtained content matches the content confirmation hash value stored in the holder management information.

[0063] Through the above process, it becomes possible to safely send and receive the content key using the blockchain without involving others, so that the content can be utilized safely. In the above example, user A generated and provided the content, but user B who purchased the content may also provide the content to others. In this case, there is no need to change the content key. In this case, the processes of steps S2000 to S2030 may not be performed. However, if the content key is not changed, user A can still use the content even after user B purchases the content. Naturally, user B may change the content key. Also, user B may change the storage location of the content.

[0064] In addition, the sales format of the content is not particularly limited. For example, it may be an auction format or a lottery format, etc., and the content may also be distributed for free. Also, the sale of the content may be carried out by another smart contract or an external program such as an external application program. In this case, for example, a purchase request notice is sent to a sales device in which the external program is implemented, and when the purchaser confirms, a purchase request notice is sent from the sales device to the smart contract 102. In this case, the source information and source signature of the purchase request notice are not the address and signature of the user who wishes to make a purchase, but the address of the sales device and the corresponding signature.

[0065] Also, in the above example, both the authentication public key pair and the hash value of the lock random number were used for User B to obtain the NFT and the content key. However, only one of these may be used, or neither of them may be used. However, if the authentication public key pair is not generated, a separate mechanism for safely obtaining the content key is required. For example, since the blockchain network connection device 200 manages the public key pair for electronic signature attached to a request notice for requesting a process (transaction) to the blockchain, the content key can be safely transmitted and received using that public key pair instead of the authentication public key pair.

[0066] When at least one of the authentication public key pair and the hash value of the lock random number is not used, since it is not necessary to manage them in the holder management information for those who are scheduled to hold them, the amount of data held in the blockchain can be reduced. Even when these are not used, security can be improved by limiting the users who have the right to access or update the holder management information and the holder-scheduled management information to the content holders and those scheduled to hold the content.

[0067] Also, in the above example, User B managed the encrypted content key obtained in step S2260. However, the encrypted content key may be held by the smart contract 102 and obtained by User B as needed. In this case, the holder schedule management information is retained even after the content is purchased. However, in the holder schedule information, a value indicating the current holder is stored, or information indicating the current holder is stored in another field. Also, information for managing the content key separately from the holder schedule management information may be held by the smart contract 102.

[0068] Also, since the lock random number is notified to the smart contract 102 as unlock information for the holder change request in step S2250, it is shared across the entire blockchain. Therefore, when User B, who purchased the content, provides the content to others, it is necessary to generate a new lock random number. Also, when updating the authentication information, the update method is appropriately set so that the same value can be referenced by the blockchain network connection device 200 and the smart contract 102. The key acquisition request in these cases is, for example, the holder change request with a new lock value and authentication information update information added. Also, for key acquisition, only one of the public key pair and the hash value that is the lock information may be used, or both may not be used.

[0069] As described above, according to this embodiment, the connection device 200A receives a purchase request notification including a public key from the connection device 200B via the blockchain network 100, and encrypts the content key using the public key, and then transmits the encrypted content key to the connection device 200B via the blockchain network 100. The connection device 200B transmits a purchase request notification to the connection device 200A and transmits source information indicating the transfer destination of the content to the blockchain network 100. Further, the connection device 200B decrypts the encrypted content key received from the connection device 200A using the private key. When the blockchain network 100 receives the encrypted content key, it changes the holder indicated in the holder management information to the transfer destination. As a result, while encrypting the content key and transferring it to the transfer destination, the holder can be changed in the blockchain network 100, so that it is possible to improve the security of the content without using a centralized system.

[0070] Also, in this embodiment, the connection device 200B transmits a purchase request notification including a hash value of a locking random number, and when it receives a holder change possible notification, it transmits the locking random number to the blockchain network 100. When the blockchain network 100 receives the encrypted content key, it transmits a holder change possible notification to the connection device 200B, and then, when the hash value of the locking random number from the connection device 200B matches the hash value of the purchase request notification, it changes the holder and transmits the encrypted content key to the connection device 200B. As a result, it is possible to further improve the security of the content.

[0071] Also, in this embodiment, the connection device 200B transmits authentication information obtained by encrypting referenceable information that can be referenced in the blockchain network 100 using the private key to the blockchain network 100. When the information obtained by decrypting the authentication information with the public key in the blockchain network 100 matches the referenceable information, it changes the holder and transmits the encrypted content key to the connection device 200B. As a result, it is possible to further improve the security of the content.

[0072] Further, in this embodiment, source information indicating a transferee may be transmitted from a connection device different from the connection device 200B that transmits the purchase wish notification. As a result, by the user of the connection device 200B that transmits the purchase wish notification passing a public key pair or the like to a third party, it becomes possible to present the content to the third party.

Example

[0073] In this embodiment, an example of transmitting and receiving a content key using a key replacement encryption method capable of key replacement will be described. Hereinafter, a key replacement encryption method using a public key encryption method will be given as an example.

[0074] In this key replacement encryption method, a common parameter g, which is a parameter that can be commonly referred to by each user (each blockchain network connection device 200), is defined. Also, let the private key generated by the connection device 200A of user A be s_A, the public key be h_A, the private key generated by the connection device 200B of user B (or the connection terminal 400 if user B performs key management by himself / herself) be s_B, and the public key be h_B. The public key is defined by the private key and the common parameter g. For example, the public key h_A of user A is h_A = g^s_A. The operator ^ indicates exponentiation. Note that the common parameter g is stored in advance in a place that can be referred to by the smart contract 102, the blockchain network connection device 200, and the like.

[0075] Also, when the data to be encrypted is M, the encrypted data obtained by encrypting the data M with the key X is denoted as ENC(X,M). Also, an encrypted text C = (Y, ENC(X,M)) including the encrypted data ENC(X,M) and a replacement key Y that can be replaced with the encryption key to decrypt the encrypted data ENC(X,M) is defined. In this embodiment, the encrypted text C of the connection device 200A of user A is denoted as encrypted text C_A, the encrypted text C of the connection device 200B of user B is denoted as encrypted text C_B, and the encrypted text C_A is C_A = (h_A^r, ENC(g^r,M)). Here, r is a random number, and the operator ^ indicates exponentiation.

[0076] The decryption process of the ciphertext C_A is carried out by deriving the encryption key g^r from the re-key h_A^r included in the ciphertext C_A. Specifically, using the private key s_A of user A, the re-key h_A^r is transformed as "(h_A^r)^(1 / s_A)=(g^(s_A*r))^(1 / s_A)=g^r", so that the private key g^r that encrypted the ciphertext C_A can be obtained. Therefore, using the decryption process DEC, the message M can be restored to plaintext as DEC(g^r,(ENC(g^r,M))=M.

[0077] Also, for key re-keying from user A to user B, the parameter (s_B / s_A) generated from the private key is used. When the parameter (s_B / s_A) is exponentiated to the re-key h_A^r included in the ciphertext C_A, it can be transformed as (h_A^r)^(s_B / s_A)=g^(s_A*r*(s_B / s_A))=g^(r*s_B)=h_B^r, and the ciphertext of user A can be converted into the ciphertext C_B=(h_B^r,ENC(g^r,M)) of user B. Therefore, by safely using the parameter s_B / s_A, it is possible to realize key re-keying from user A to user B while suppressing data leakage. Also, in Example 1 using the public key method, there is an upper limit to the size of the data to be encrypted, but in this example, since any encryption method can be used for content encryption, it is possible to eliminate the upper limit on the size of the data to be encrypted.

[0078] FIG. 9 and FIG. 10 are diagrams for explaining the processing of the content protection system 1 according to Example 2. Specifically, FIG. 9 is a flowchart for explaining the processing related to the connection device 200A of user A, and FIG. 10 is an activity diagram for explaining the processing related to the connection device 200B of user B and the smart contract 102.

[0079] User A, who is the content provider, sends the prepared content to the connection device 200A. The key random number generation unit 520 of the encryption processing unit 500 of the connection device 200A generates the hash value of the content as the content verification hash value (step S3000). The key random number generation unit 520 generates a content key (step S3010). The decryption processing unit 510 encrypts the content using the content key (step S3020).

[0080] Subsequently, the key random number generation unit 520 generates a key encryption random number r for encrypting the content key (step S3030), and uses the key encryption random number r and the common parameter g to generate a key encryption key (key decryption key) g^r, which is the key for encrypting and decrypting the content key (step S3040). Then, the decryption processing unit 510 generates an encrypted content key by encrypting the content key using the key encryption key g^r (step S3050). Here, the content key is K, and the encrypted content key is ENC(g^r, K). Note that an encrypted content key may be obtained by encrypting the content key with predetermined information added thereto.

[0081] Next, the key random number generation unit 520 generates a secret key s_A using a random number or the like (step S3060), and uses the secret key s_A and the common parameter g to generate a public key h_A = g^s_A (step S3070). The secret key s_A and the public key h_A form a public key pair for key substitution for the key encryption key g^r. Also, the key random number generation unit 520 generates key substitution information h_A^r for substituting the key encryption key g^r using the public key h_A and the key encryption random number r (step S3080), and further generates the auxiliary information R_A*s_A of user A used for key substitution using the secret key s_A and the auxiliary information random number R_A (step S3090). Then, the key random number generation unit 520 generates a substitution key (h_A^r)^(1 / (R_A*s_A)) for substituting the key encryption key g^r based on the key substitution key information h_A^r and the auxiliary information R_A*s_A (step S3100).

[0082] Note that for key replacement, information s_B / s_A based on the private keys of User A and User B is used. However, if the private keys are simply transmitted between User A and B, their own private keys will be leaked to others. In this embodiment, in order to prevent the leakage of the private key, information obtained by calculating (specifically, multiplying) the private key s_A of User A by the random number R_A for auxiliary information is generated as the auxiliary information R_A*s_A. Also, the execution order of the processes in steps S3000 to S3100 is not limited as long as the dependency relationships of the respective processes can be maintained.

[0083] After that, the key random number generation unit 520 stores the encrypted content in the content server 300 and transmits a registration request for registering content information regarding the content to the smart contract 102 of the node 101. The content information in this embodiment includes the encrypted content key and the replacement key.

[0084] Moving on to the description of FIG. 10. The smart contract 102 issues an NFT corresponding to the registration request and registers it on the blockchain (step S3200).

[0085] FIG. 11 is a diagram showing an example of the holder management information included in the NFT of this embodiment. The holder management information 600A shown in FIG. 11 has fields 605 and 606 in addition to the fields 601 to 604 of the holder management information of Embodiment 1 shown in FIG. 5. Field 605 stores the replacement key, and field 606 stores the encrypted content ciphertext.

[0086] Returning to the description of FIG. 10. In the connection device 200B of User B, who is the purchaser, similar to Embodiment 1, the key random number generation unit 520 generates a random number for locking (step S3330), and further generates a hash value of the random number for locking as the lock information (step S3340).

[0087] Also, the key random number generation unit 520 generates an authentication public key pair for obtaining the content key. Here, it is described that the authentication public key pair is shared with the public key pair used for updating the replacement key, but these public key pairs may be generated separately.

[0088] Specifically, similar to the connection device 200A of user A, the key random number generation unit 520 generates a secret key s_B using a random number or the like (step S3300), and generates a public key h_B = g^s_B using the secret key s_B and the common parameter g (step S3310). Further, the key random number generation unit 520 generates the auxiliary information R_B*s_B of user B using the secret key s_B and the random number R_B for auxiliary information (step S3320).

[0089] After that, when purchasing content, user B instructs the connection device 200B to purchase the content. The connection device 200B transmits a purchase request notification to the smart contract 102 in response to the instruction (step S3350).

[0090] FIG. 12 is a diagram showing an example of the purchase request notification of this embodiment. The purchase request notification 700A shown in FIG. 12 has a field 708 in addition to the fields 701 to 707 of the purchase request notification 700 of the first embodiment shown in FIG. 6. The field 708 stores auxiliary information.

[0091] Returning to the description of FIG. 10. When the smart contract 102 receives a purchase request notification, it confirms the validity of the purchase request notification based on the digital signature of the purchase request notification. If the validity is confirmed, the smart contract 102 registers the scheduled holder management information based on the purchase request notification (step S3210).

[0092] FIG. 13 is a diagram showing an example of the scheduled holder management information of this embodiment. The scheduled holder management information 800A shown in FIG. 13 has the fields 801 to 804 of the scheduled holder management information 800 of the first embodiment, and instead of the field 805, it has fields 806 and 807. The field 806 stores the auxiliary information of the scheduled holder (user B) included in the purchase request notification, and the field 807 stores the replacement key of the scheduled holder. Note that the replacement key of the scheduled holder is not registered in step S3210.

[0093] Return to the description of FIG. 10. The smart contract 102 generates an updated replacement key by updating the replacement key of User A included in the holder management information based on the auxiliary information of User B, and transmits a purchase request notice including the updated replacement key to the connection device 200A of User A (step S3220). Specifically, the updated replacement key is information obtained by raising the replacement key of User A to the power of the auxiliary information of User B. That is, the updated replacement key is ((h_A^r)^(1 / (R_A*s_A)))^(R_B*s_B)=(h_A^r)^((R_B*s_B) / (R_A*s_A)).

[0094] Move to the description of FIG. 9. When receiving the purchase request notice, the decryption processing unit 510 of the connection device 200A replaces the updated replacement key included in the purchase request notice with the updated replacement key of User B (step S3120).

[0095] Specifically, the decryption processing unit 510 raises the updated replacement key to the power of the random number R_A for auxiliary information generated in step S3090. That is, the decryption processing unit 510 calculates ((h_A^r)^((R_B*s_B) / (R_A*s_A)))^R_A. When calculating this, ((h_A^r)^((R_B*s_B) / (R_A*s_A)))^R_A =(h_A^r)^((R_B*s_B) / s_A) =(g^s_A)^r*((R_B*s_B) / s_A) =g^(s_A*r*((R_B*s_B) / s_A) =g^(r*R_B*s_B) =(g^s_B)^(r*R_B) =(h_B^r)^R_B and it can be replaced from the key of User A to the key of User B.

[0096] The decryption processing unit 510 notifies the smart contract 102 of a purchase permission notice including the replaced key of User B (step S3130).

[0097] Return to the description of FIG. 10. When the smart contract 102 receives the purchase permission notice, it stores the key of the replaced user B included in the purchase permission notice as the replacement key of the holder in the holder management information. Then, the smart contract 102 completes the purchase process and sends a holder change possible notice indicating that the change of the holder of the content is possible to the connection device 200B of the user B (step S3230).

[0098] When the decryption processing unit 510 of the connection device 200B of the user B receives the holder change possible notice, it generates authentication information in the same manner as in the first embodiment (step S3360), and sends a holder change request to the smart contract 102 requesting to obtain the replacement key that can be decrypted with the auxiliary information random number R_B and the secret key s_B (step S3370).

[0099] When the smart contract 102 receives the holder change request, it checks whether the holder change request is a legitimate request in the same manner as in the first embodiment (step S3240). If the holder change request is a legitimate request, it updates the holder information in the holder management information with the holder information in the prospective holder management information (step S3250).

[0100] Then, the smart contract 102 sends the replacement key of the prospective holder included in the prospective holder management information and the encrypted content key included in the holder management information to the connection device 200B of the user B, which is the transmission source of the holder change request. The decryption processing unit 510 of the connection device 200B receives the replacement key and the encrypted content key, and decrypts the encrypted content key based on the replacement key to obtain the content key (step S3380). Thereby, it becomes possible to decrypt the encrypted content.

[0101] The method for obtaining the content key can be obtained by performing the following calculation using the replacement key of the prospective holder and the auxiliary information R_B*s_B held in the connection device 200B. That is, the key of the user B is (((h_B^r)^R_B)^(1 / (R_B*s_B)) =((g^(s_B*r))^R_B)^(1 / (R_B*s_B)) =g^((s_B*r*R_B) / (R_B*s_B) =g^r It can be transformed into this, and the key g^r used for content encryption set by user A can be obtained. As a result, the encrypted content can be decrypted.

[0102] Through the above processing, it becomes possible to perform key replacement via the smart contract 102, and it becomes possible to safely use the content even in a distributed environment. Note that in this embodiment as well, the same modification examples as in Embodiment 1 are possible. For example, the content sales method may be implemented by an external program. Also, only one of the lock information and the authentication information may be used, or neither of them may be used.

[0103] Also, in this embodiment, the auxiliary information used for key replacement is registered in the smart contract 102. However, instead of notifying the auxiliary information in step S3350, the blockchain network connection device 200 may read the replacement key registered in the smart contract 102, and have user B perform calculations using the replacement information and notify the calculation result. In this case, since it is not necessary to hold the auxiliary information in the holder-to-be management information, the process of step S3210 may not be necessary, and the updated replacement key information is set in the purchase request notification instead of the replacement information.

[0104] Also, similar to Embodiment 1, the content purchased by user B can be sold using the method described with reference to FIGS. 9 and 10. At that time, if the content encryption key is not changed, the processes of steps S3000 to S3050 may not be performed. Also, if the public key pair is not changed, the processes of steps S3060 to S3090 may not be performed, and it is sufficient that the replacement key (h_B^r)^(1 / (R_B*s_B)) generated in step S3100 is registered in step S3110. Similarly, when changing the storage location of the content, the changed storage location is notified to and registered in the smart contract 102.

[0105] Also, the fact that the content owner does not register the replacement key may indicate that "the target content is not for sale", or the content owner may be able to explicitly register whether it can be sold. In this case, the replacement key may be automatically registered when the owner is changed, or a parameter that can be converted from (h_A^r)^(1 / (R_A*s_A)) to (h_B^r)^(1 / (R_B*s_B)) may be registered using a purchase request notification. In the latter case, for example, in step S3320, the blockchain network connection device 200 of user B generates two values of R_B*s_B and (R_B^2)*s_B as auxiliary information, obtains the replacement key (h_A^r)^(1 / (R_A*s_A)) registered in the smart contract 102, and calculates (h_A^r)^((R_B*s_B) / (R_A*s_A)). The blockchain network connection device 200 notifies (R_B^2)*s_B as auxiliary information to the smart contract 102 in step S3350. The smart contract 102 transmits the updated replacement key (h_A^r)^((R_B*s_B) / (R_A*s_A)) to the blockchain network connection device 200 of user A (step S3220), and the blockchain network connection device 200 multiplies the replacement key by (R_A) to perform key replacement (step S3120), and notifies the resulting (h_B^r)^R_B to the smart contract 102 (step S3130). The smart contract 102 performs a power calculation by applying the auxiliary information notified from user B to the notified replaced key. As a result, the replaced key can be transformed into (h_B^r)^R_B^(1 / ((R_B^2)*s_B))=(h_B^r)^(1 / (R_B*s_B)). As a result, it can be replaced with the replacement key of user B when the content purchase is confirmed. Since the information held by the blockchain network connection device 200 of user B is used for this key, the content encryption key g^r can be obtained from this key.

[0106] Also, if both (R_B * s_B) and (R_B^2) * s_B are disclosed, it becomes possible to calculate the random number R_B. Therefore, in the above example, these are not both notified to the smart contract 102. This is because if the random number R_B is calculated, the secret key s_B of user B may leak from the replacement key (h_B^r)^(1 / (R_B * s_B)) of user B.

[0107] When generating a replacement key updated by the smart contract 102, it becomes possible to prevent the leakage of the secret key s_B by the blockchain network connection device 200 of user B generating two types of random numbers. Specifically, the blockchain network connection device 200 generates two random numbers R_B1 and R_B2 in step S3320, generates a value R_B1 * s_B for updating the replacement key, and a value R_B2 / ((R_B1^2) * s_B) for further updating the key after replacement to the replacement key of user B, and transmits them to the smart contract 102 in step S3350. The smart contract 102 registers the R_B2 / ((R_B1^2) * s_B) for updating in step S3210, updates and transmits the replacement key of user A using R_B * s_B. Since the replacement key is (h_B^r)^(R_B1 * R_B2) by the blockchain network connection device 200 of user A, this is converted to (h_B^r)^((R_B1 * R_B2) * ((R_B2 / ((R_B1^2) * s_B))) = (h_B^r)^(R_B^2 / (R_B1 * s_B)).

[0108] When user C who purchased content from user B sells the content, the same can be done. However, if the same random number is used multiple times, there may be a problem with the encryption strength. Therefore, it is desirable to generate random numbers as appropriate.

[0109] As described above, also in this embodiment, while encrypting the content key and transferring it to the transferee, the holder can be changed in the blockchain network 100, so it becomes possible to improve the security of the content without using a centralized system.

Example

[0110] In this embodiment, a method for synthesizing a random number and a content encryption key will be described. Since the processing flow is similar to that of Embodiment 1, it will be described with reference to FIG. 4.

[0111] First, the processes of steps S2000 to S2030 are executed in the same manner as in Embodiment 1. However, in step S2010, the key random number generation unit 520 generates a random number R_A together with the content key, and synthesizes the random number R_A with the content key to generate a content key with replacement information. In this embodiment, exclusive OR (XOR) is used for the synthesis. That is, if the content encryption key is K_C, the information generated by the synthesis is R_A XOR K_C. Also, the blockchain network connection device 200 of user A has a receiving public key pair for securely receiving the information notified from the purchaser of the content. The receiving public key pair is the same information as the authentication information possessed by the blockchain network connection device 200 of user B, and the public key included in the receiving public key pair is notified to the smart contract 102 by a registration request.

[0112] The smart contract 102 registers an NFT in response to the registration request (step S2100).

[0113] FIG. 14 is a diagram showing an example of the holder management information included in the NFT. The holder management information 600B shown in FIG. 14 has fields 607 and 608 in addition to the fields 601 to 604 of the holder management information of Embodiment 1 shown in FIG. 5. Field 607 stores the public key of the content holder, and field 608 stores the content encryption key with replacement information.

[0114] Returning to the description of FIG. 4, thereafter, similar processes to steps S2200 to S2230 are performed by the connection device 200B of user B who is the purchaser of the content, and a purchase request notification is sent to the smart contract 102.

[0115] However, the connection device 200B further generates key replacement information for key replacement and notifies the smart contract 102 using the purchase request notification. Specifically, the connection device 200B generates a random number R_B to be used as an encryption key for user B, separate from the lock random number generated in step S2200. Then, the blockchain network connection device 200 generates an encrypted random number ENC_A(R_B) obtained by encrypting the random number R_B using the public key of the holder included in the record of the NFT to be purchased in the holder management information managed by the smart contract 102 as replacement information. The purchase request notification in this embodiment is the same as the purchase request notification 700A in Embodiment 2 shown in FIG. 12, but the encrypted random number ENC_A(R_B) is stored in field 708.

[0116] When the smart contract 102 receives the purchase request notification, it registers the scheduled holder management information and sends a wish receipt notification to the connection device 200A of user A in the same manner as in Embodiment 1 (step S2110). The scheduled holder management information in this embodiment is the same as the scheduled holder management information 800A in Embodiment 2 shown in FIG. 13, but the encrypted random number ENC_A(R_B) is stored in field 806.

[0117] When the decryption processing unit 510 of the connection device 200A of user A receives the wish receipt notification, in Embodiment 1, it encrypts the content encryption key with the public key generated by user B, but in this embodiment, instead of encrypting the content encryption key, it executes the following processing. That is, the decryption processing unit 510 refers to the scheduled holder management information 800A, obtains the encrypted random number ENC_A(R_B) which is the key replacement information, decrypts the encrypted random number ENC_A(R_B) with the private key included in the above receiving public key pair to obtain the random number R_B. The decryption processing unit 510 generates information obtained by synthesizing the obtained random number R_B and the above random number R_A as a replacement key. In this embodiment, since exclusive OR XOR is used for synthesis, the replacement key is R_B XOR R_A. The decryption processing unit 510 sends a permission notification including the replacement key to the smart contract 102 (steps S2040 - S2050).

[0118] When the smart contract 102 receives the permission notice, it registers the replacement key included in the permission notice in the holder-to-be management information (step S2120), and transmits a holder change possible notice to the blockchain network connection device 200 of user B (step S2130).

[0119] Thereafter, similar to Example 1, the processes of steps S2240, S2250, S2140, S2150, and S2260 are executed. However, in the process of step S2150 for updating the holder management information, the smart contract 102 generates a key for user B and registers it in the holder management information. Specifically, the smart contract 102 synthesizes the content encryption key with replacement information included in the holder management information and the replacement key for the holder-to-be registered in the holder-to-be management information in step S2240, and registers it as the key for user B. That is, the smart contract 102 derives and registers (R_A XOR K_C) XOR (R_B XOR R_A) = R_B XOR K_C as the key for user B. By synthesizing the replacement keys in this way, a key that does not include the random number R_A can be generated. Also, only the user who knows the random number R_B can obtain the content encryption key K_C. That is, only user B or the user to whom the random number R_B is provided by user B can obtain the content encryption key K_C. Therefore, in this embodiment, even when the random number is combined with the encryption key, the key replacement can be performed safely.

[0120] Note that in this embodiment as well, the same modifications as in Examples 1 and 2 are possible. For example, the content sales method may be implemented by an external program. Also, only one of the lock information and the authentication information may be used, or neither of them may be used.

[0121] Also, in Example 2, the parameters necessary for key replacement were combined with random numbers, and in Example 3, they were encrypted with the public key of the holder. These processes may be executed by entrusting a reliable third-party device. This third-party device may provide services constantly or may provide services only for a necessary period using cloud services or the like. For example, the connection device 200B of user B sends a purchase request notice to a third-party device instead of the smart contract 102 (see steps S2230 and S3350). At that time, in Example 2, the connection device 200B sends the private key S_B, and in Example 3, it sends the random number R_B to the third-party device. Further, as a purchase request notice, connection destination information of the third-party device and the like are notified to the smart contract 102. The smart contract 102 notifies the notified connection destination information to user A. The connection device 200A of user A sends the necessary information to the connection destination of the third-party device in the same manner as user B. Specifically, the connection device 200A sends the private key s_A in Example 2 and the random number R_A in Example 3. The third-party device generates s_B / s_A in Example 2 and R_A XOR R_B in Example 3 and returns it to the connection device 200A of user A. The connection device 200A receives the information, user A receives it, and notifies the parameters generated by the third-party device as a purchase permission notice (steps S2050 and S3130).

[0122] If user A cannot trust the services provided by the third-party device, user A may reject the purchase request or may notify user B of another reliable third-party device and have the purchase request notice resent. Also, user A may register the services that user A permits to use in the smart contract 102. Further, the third-party device may directly access the smart contract 102. In this case, since the processes performed by the connection devices of users A and B are transferred to the third-party device, the third-party device requires a basic function to connect to the blockchain network 100.

[0123] In addition, if there is a service that entrusts the key management necessary for connecting to the blockchain network 100, it is also conceivable to transfer the key management and approval process to the service side from the initial secret key management. If the generation of key replacement parameters can be transferred to a reliable third party in this way, the replacement auxiliary information in the second embodiment becomes unnecessary, and the replacement key of user A will be registered as "h_A^r" and the normal public key. In this case, the replacement auxiliary information may be managed by the service side.

[0124] In addition, in each of the above embodiments, the example of changing the NFT holder to the purchaser has been described. However, the usage permission of the content may be managed using NFT. Also, when multiple people use one content, the content encryption key is shared among multiple people. At this time, if the content encryption key is leaked, there is a risk that the security of the content cannot be ensured. In this case, it is necessary to encrypt the content with another content key and provide it to the holder and other users. Regarding this, it is possible to efficiently respond by retaining the authentication information of the holder and the auxiliary information for key replacement. The method will be described below.

[0125] The connection device 200A of user A that has detected the leakage of the content key generates a new encrypted content by newly generating a content key and encrypting the content, and replaces it with the already stored encrypted content. In addition, the connection device 200A encrypts the content key using the public key of the holder registered as authentication information (the public key for the signature of the holder if authentication information is not used) and stores it in the holder management information. Also, in the second or third embodiment, if the auxiliary information or key replacement information is registered, the replacement keys for each user generated using the registered information may be registered in the holder management information.

[0126] Also, in each embodiment, the prospective purchaser sent a purchase request notice to the holder, the holder permitted the purchase, and then the intended holder changed the holder. This was due to conforming to the current NFT transactions. However, it is not limited to this procedure, and the holder may change the holder of the holder management information. In this case, there is no holder update process in FIGS. 4 and 10, and the holder update process is executed in steps S2120 and S3230, respectively. In this case, when referring from User B, the lock information and authentication information are used by referring to the intended holder management information.

[0127] Also, in each embodiment, the content was assumed to be off-chain outside the blockchain, but the content may be on-chain on the blockchain. Also, only a part of the content may be encrypted so that the purchaser can purchase after confirming the content, or the content may be encrypted after a certain period from when it is registered.

[0128] Also, in each embodiment, lock information and authentication information etc. were used for sending and receiving the content key, but these pieces of information may also be used when accessing the content server 300. For example, when a content user accesses the content server 300, the content server 300 refers to at least one of the lock information and authentication information recorded in the smart contract 102 to determine whether access to the content is permitted. Note that when both the lock information and authentication information are not registered, the content server 300 may determine whether access to the content is permitted using the public key used for generating the blockchain network address. In this case, it becomes possible to restrict access to the content to the holder in the content server 300.

[0129] The above-described embodiments of the present disclosure are examples for explaining the present disclosure, and are not intended to limit the scope of the present disclosure only to those embodiments. A person skilled in the art can implement the present disclosure in various other ways without departing from the scope of the present disclosure.

Explanation of Reference Numerals

[0130] 100: Blockchain network 101: Node 200, 200A, 200B: Blockchain network connection device 300: Content server 400: Connected terminal

Claims

1. A content protection system having a blockchain network composed of a plurality of computers and a plurality of connection devices connected to the blockchain network, and managing content encrypted in a form decodable with a content decryption key and stored in a predetermined storage location, comprising: A first connection device, which is any one of the plurality of connection devices, holds the content decryption key, receives, via the blockchain network, a usage request for using the content from a second connection device, which is a connection device different from the first connection device, the usage request including a public key corresponding to a secret key managed by the second connection device, sends, via the blockchain network, an encrypted content decryption key obtained by encrypting the content decryption key using the public key included in the usage request to the second connection device, The second connection device, holds the secret key, sends the usage request to the first connection device via the blockchain network, sends user information indicating a usage right granter who grants the usage right of the content to the blockchain network, receives, via the blockchain network, the encrypted content decryption key from the first connection device, decrypts the encrypted content decryption key using the secret key to obtain the content decryption key, The blockchain network, stores user management information indicating users who can use the content, When receiving the encrypted content decryption key, adds the usage right granter indicated by the user information to the users indicated by the user management information. A content protection system.

2. The second connection device, sends the usage request including a hash value of predetermined lock information, When receiving a changeable notification from the blockchain network indicating that addition of the user who can use the content is possible, sends the lock information to the blockchain network, The blockchain network, stores the hash value included in the usage request as lock information, When receiving the encrypted content decryption key, sends the changeable notification to the second connection device. The content protection system according to claim 1, which receives the lock information, adds an authorization granter to the available user when the hash value of the lock information matches the lock information, and transmits the encrypted content decryption key to the second connection device.

3. The second connection device When receiving the changeable notification, transmits authentication information obtained by encrypting referenceable information that can be referred to in the blockchain network using the secret key to the blockchain network. The blockchain network The content protection system according to claim 2, which receives the authentication information, adds an authorization granter to the available user when information obtained by decrypting the authentication information with the public key included in the usage request matches the referenceable information, and transmits the encrypted content decryption key to the second connection device.

4. The user information indicates the blockchain network address of the second connection device that transmits the user information. The content protection system according to claim 1, wherein the second connection device that transmits the usage request is different from the second connection device that transmits the user information.

5. The blockchain network transfers the content from the holder to the authorization granter by deleting the holder who is the user corresponding to the first connection device from the available users indicated in the user management information. The content protection system according to claim 1.

6. The blockchain network holds the hash value of the content. The content protection system according to claim 1.

7. The storage location of the content is a storage device installed outside the blockchain network. The content protection system according to claim 1.

8. A content protection system having a blockchain network composed of a plurality of computers and a plurality of connection devices connected to the blockchain network, and managing content encrypted in a form decryptable with a content decryption key and stored in a predetermined storage location, A first connection device that is any one of the plurality of connection devices Registers an encrypted content decryption key obtained by encrypting the content decryption key and a replacement key for replacing the key decryption key for decrypting the content decryption key in the blockchain network. Receive, from the blockchain network, a usage request for using the content, the usage request including a first updated replacement key obtained by updating the replacement key, Send, to the blockchain network, a second updated replacement key obtained by updating the first updated replacement key included in the usage request based on first auxiliary information for assisting the replacement of the key decryption key, A second connection device different from the first connection device, Send, to the blockchain network, the usage request including second auxiliary information for assisting the replacement of the key decryption key, Send, to the blockchain network, user information indicating a usage right grantor who grants the usage right of the content, Receive, from the blockchain network, the second updated replacement key and the encrypted content decryption key, replace the key decryption key with the second updated replacement key based on the second auxiliary information, and decrypt the encrypted content decryption key using the key decryption key to obtain the content decryption key, The blockchain network, Store user management information indicating a user who can use the content, When receiving the usage request from the second connection device, send, to the first connection device, the usage request including a first updated replacement key obtained by updating the replacement key registered from the first connection device based on the second auxiliary information included in the usage request, When receiving the second updated replacement key from the first connection device, add the usage right grantor indicated by the user information to the user who can use indicated by the user management information, and send the second updated replacement key and the encrypted content decryption key registered from the first connection device to the second connection device, a content protection system.

9. A content protection system having a blockchain network composed of a plurality of computers and a plurality of connection devices connected to the blockchain network, and managing content encrypted in a form decryptable with a content decryption key and stored in a predetermined storage location, A first connection device which is any one of the plurality of connection devices, Register, in the blockchain network, a content key with first replacement information obtained by combining a first random number with the content decryption key and a public key, A usage request for requesting the use of the content, which is from a second connection device different from the first connection device, and includes an encrypted random number obtained by encrypting a second random number with the public key, is received via the blockchain network. The encrypted random number included in the usage request is decrypted with the private key corresponding to the public key to obtain the second random number, and a replacement key obtained by combining the second random number and the first random number is transmitted to the blockchain network. The second connection device: Holds the second random number. Transmits the usage request to the first connection device via the blockchain network. Transmits user information indicating a usage right granter who grants the usage right of the content to the blockchain network. Receives a content key with second replacement information obtained by combining the encrypted content decryption key with the second random number from the blockchain network, and obtains the content decryption key from the content key with second replacement information based on the second random number. The blockchain network: Stores user management information indicating users who can use the content. When receiving the replacement key, adds the usage right granter indicated by the user information to the users who can use indicated by the user management information, and generates a content key with second replacement information based on the replacement key from the content key with replacement information registered from the first connection device, and transmits it to the second connection device. A content protection system.

Images