Encryption system, method, and program

Abstract

To cancel a content distribution using a key policy attribute based encryption after content distribution.SOLUTION: According to an aspect of the present disclosure, there is provided an encryption system including a first terminal on a transmission side and a second terminal on a reception side, in which the first terminal includes: a first encryption part configured to generate a first encryption text obtained by encrypting content using a common key encryption; a second encryption part configured to generate a second encryption text obtained by encrypting a common key of the common key encryption using a key policy attribute based encryption using identification information for identifying the content as attribute information; and a transmission part configured to transmit the first encryption text and the second encryption text to the second terminal. The second terminal includes: a first decryption part that decrypts the second encryption text using a secret key with a policy in which a decryption condition indicating that the content is not invalidated is embedded; and a second decryption part that decrypts the first encryption text using a common key obtained by decrypting the second encryption text.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] The present disclosure relates to cryptographic systems, methods, and programs. [Background technology]

[0002] An encryption method called Key-Policy Attribute-Based Encryption (KP-ABE) is known (see, for example, Non-Patent Document 1). Key-Policy Attribute-Based Encryption is an encryption method in which a decryption condition (policy) is embedded in a private key and attributes are embedded in ciphertext, and it can be said that it is an encryption method in which the party that encrypts (the sender) does not specify the party that decrypts (the receiver).

[0003] Key policy attribute-based encryption can be applied to content distribution control. In this case, for example, attributes that indicate the type of content are embedded in the ciphertext obtained by encrypting the content, and decryption conditions that indicate the attributes that the recipient can decrypt are embedded in the private key. In this case, the recipient's public key is used to encrypt the content, and the recipient's private key is used to decrypt the ciphertext. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] V. Goyal, O. Pandey, A. Sahai, and B. Waters, "Attribute-based encryption for fine-grained access control of encrypted data," CCS 2006, pp. 89-98, 2006. Summary of the Invention [Problem to be solved by the invention]

[0005] However, when key policy attribute-based encryption is applied to content distribution control, the sender cannot prevent the decryption of the ciphertext of the content after transmitting it, because the receiver's public key and private key are used for encryption and decryption, respectively, so the sender cannot cancel the distribution of the content after transmitting the ciphertext of the content.

[0006] The present disclosure has been made in consideration of the above points, and provides a technology that enables cancellation of content distribution after distribution in content distribution using key policy attribute-based encryption. [Means for solving the problem]

[0007] A cryptographic system according to one embodiment of the present disclosure is a cryptographic system including a first terminal on the transmitting side and a second terminal on the receiving side, wherein the first terminal has a first encryption unit that generates a first ciphertext by encrypting content using a symmetric key ciphertext, a second encryption unit that generates a second ciphertext by encrypting a symmetric key of the symmetric key ciphertext using key policy attribute-based encryption, with identification information that identifies the content as attribute information, and a transmission unit that transmits the first ciphertext and the second ciphertext to the second terminal, and the second terminal has a first decryption unit that decrypts the second ciphertext using a policy-attached private key in which a decryption condition indicating that the content has not been revoked is embedded, and a second decryption unit that decrypts the first ciphertext using a symmetric key obtained by decrypting the second ciphertext. [Effects of the Invention]

[0008] In content distribution using key policy attribute-based encryption, it is possible to cancel the distribution of content after it has been distributed. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram illustrating an example of the overall configuration of a cryptographic system according to a first embodiment; [Figure 2]FIG. 2 is a diagram illustrating an example of a functional configuration of a control key generation station according to the first embodiment. [Figure 3] FIG. 2 is a diagram illustrating an example of a functional configuration of a user terminal according to the first embodiment. [Figure 4] 10 is a flowchart showing an example of a setup process of a control key generation station according to the first embodiment. [Figure 5] 10 is a flowchart illustrating an example of a control key distribution process according to the first embodiment. [Figure 6] 10 is a flowchart illustrating an example of encryption processing according to the first embodiment. [Figure 7] 10 is a flowchart illustrating an example of a decoding process according to the first embodiment. [Figure 8] 10 is a flowchart illustrating an example of a content invalidation process according to the first embodiment. [Figure 9] FIG. 10 is a diagram illustrating an example of a functional configuration of a control key generation station according to the second embodiment. [Figure 10] FIG. 10 is a diagram illustrating an example of a functional configuration of a user terminal according to the second embodiment. [Figure 11] 10 is a flowchart illustrating an example of a control key distribution process according to the second embodiment. [Figure 12] 10 is a flowchart illustrating an example of a content validation process according to the second embodiment. [Figure 13] FIG. 10 is a diagram illustrating an example of the overall configuration of a cryptographic system according to a third embodiment. [Figure 14] FIG. 11 is a diagram illustrating an example of a functional configuration of a user terminal according to the third embodiment. [Figure 15] FIG. 11 is a diagram illustrating an example of the functional configuration of an attribute key generation station according to the third embodiment. [Figure 16] 13 is a flowchart illustrating an example of a setup process of an attribute key generation station according to the third embodiment. [Figure 17] 13 is a flowchart illustrating an example of an attribute key delivery process according to the third embodiment. [Figure 18]13 is a flowchart illustrating an example of encryption processing according to the third embodiment. [Figure 19] 13 is a flowchart illustrating an example of a decoding process according to the third embodiment. [Figure 20] FIG. 13 is a diagram illustrating an example of a functional configuration of a control key generation station according to a fourth embodiment. [Figure 21] 13 is a flowchart illustrating an example of a control key distribution process according to the fourth embodiment. [Figure 22] 13 is a flowchart illustrating an example of attribute key expiration processing according to the fourth embodiment. [Figure 23] FIG. 13 is a diagram illustrating an example of a functional configuration of a user terminal according to the fifth embodiment. [Figure 24] 13 is a flowchart illustrating an example of encryption processing according to the fifth embodiment. [Figure 25] 13 is a flowchart illustrating an example of a content invalidation process according to the fifth embodiment. [Figure 26] FIG. 13 is a diagram illustrating an example of a functional configuration of a control key generation station according to a sixth embodiment. [Figure 27] 13 is a flowchart illustrating an example of a content invalidation process according to the sixth embodiment. [Figure 28] FIG. 13 is a diagram illustrating an example of a functional configuration of a control key generation station according to the seventh embodiment. [Figure 29] FIG. 13 is a diagram illustrating an example of the functional configuration of a user terminal according to the seventh embodiment. [Figure 30] 13 is a flowchart illustrating an example of encryption processing according to the seventh embodiment. [Figure 31] 13 is a flowchart illustrating an example of a content invalidation process according to the seventh embodiment. [Figure 32] FIG. 2 illustrates an example of a hardware configuration of a computer. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, first to seventh embodiments of the present invention will be described in detail with reference to the drawings.

[0011] [Preparation] First, the encryption methods used in the first to seventh embodiments are prepared.

[0012] <Key Policy Attribute-Based Encryption> Key policy attribute-based encryption (KP-ABE) is an encryption method that embeds decryption conditions (policies) in the private key and attributes in the ciphertext. With key policy attribute-based encryption, decryption is possible only if the attributes embedded in the ciphertext satisfy the policies embedded in the private key.

[0013] Since a policy is expressed in the form of a conditional expression for an attribute, hereinafter, the policy will also be referred to as a "decryption condition" or simply as a "condition" when it is clear that the policy is a decryption condition.

[0014] Key policy attribute-based encryption consists of the following four algorithms (SetupKP, KeyGenKP, EncKP, DecKP).

[0015] SetupKP: The setup algorithm SetupKP takes security parameters as input and generates a secret key MSK KP and the public key PK KP and is output.

[0016] KeyGenKP: The key generation algorithm KeyGenKP uses the secret key MSK KP and the decryption condition are input, and a private key (private key with policy) is output.

[0017] EncKP: The encryption algorithm EncKP is used to encrypt the public key PK KP The encryption algorithm takes as input a message M to be encrypted and information about the attributes of the message M (hereinafter also referred to as "attribute information") and outputs a ciphertext (ciphertext with attributes).

[0018] DecKP: The decryption algorithm DecKP takes as input a policy-attached private key and an attribute-attached ciphertext, and outputs a message M as the decryption result if the attribute information embedded in the attribute-attached ciphertext satisfies the decryption conditions embedded in the policy-attached private key; otherwise, it outputs information indicating a decryption failure.

[0019] <Ciphertext Policy Attribute-Based Encryption> Ciphertext-Policy Attribute-Based Encryption (CP-ABE) is a counterpart of key-policy attribute-based encryption, and is an encryption method that embeds decryption conditions (policies) in the ciphertext and user attributes in the private key. With ciphertext-policy attribute-based encryption, decryption is possible only if the attributes embedded in the private key satisfy the policies embedded in the ciphertext.

[0020] Ciphertext policy attribute-based encryption consists of the following four algorithms (SetupCP, KeyGenCP, EncCP, DecCP).

[0021] SetupCP: The setup algorithm SetupCP takes security parameters as input and generates a secret key MSK CP and the public key PK CP and is output.

[0022] KeyGenCP: The key generation algorithm KeyGenCP uses the secret key MSK CP and the attribute information of user i are input, and attribute key SK is generated as user i's private key (private key with attributes). i The attribute key SK i may be called the "user private key" or the like.

[0023] EncCP: The encryption algorithm EncCP uses the public key PK CP It takes the message M to be encrypted and the decryption condition as input and outputs a ciphertext (ciphertext with a policy).

[0024] DecCP: The decryption algorithm DecCP uses the attribute key SK i and the policy-enhanced ciphertext as input, and i If the attribute information embedded in satisfies the decryption condition embedded in the ciphertext with policy, the message M is output as the decryption result; otherwise, information indicating a decryption failure is output.

[0025] <Common key encryption> A symmetric key cipher is an encryption method that uses the same key for encryption and decryption. Hereinafter, the symmetric key cipher is assumed to be AES (Advanced Encryption Standard). In this case, the encryption algorithm of AES is referred to as EncAES, and the decryption algorithm is referred to as DecAES. The encryption algorithm EncAES takes as input a symmetric key K and a message M to be encrypted, and outputs ciphertext. The decryption algorithm DecAES takes as input the symmetric key K and the ciphertext, and outputs the message M or information indicating a decryption failure as the decryption result. Note that assuming AES as the symmetric key cipher is just an example, and the following embodiments can be similarly applied to cases where a symmetric key cipher other than AES is used.

[0026] [First embodiment] A first embodiment will be described below. In the first embodiment, a key called a control key that is updated periodically or irregularly is introduced, and a cryptosystem 1 will be described in which content is encrypted using a common key K and the common key K can be decrypted using the control key only when the content has not been revoked. As a result, in the cryptosystem 1 according to the first embodiment, the recipient cannot obtain the common key K after the content has been revoked, and therefore cannot decrypt the content encrypted using the common key K. Therefore, the sender can cancel the distribution of the content by revoking the content even after it has been distributed.

[0027] <Example of overall configuration of cryptographic system 1 according to first embodiment> An example of the overall configuration of a cryptographic system 1 according to the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the overall configuration of the cryptographic system 1 according to the first embodiment.

[0028] 1, the cryptographic system 1 according to the first embodiment includes, as entities, a control key generation station 10 and a plurality of user terminals 20. The entities are communicably connected via a communication network including, for example, the Internet.

[0029] The control key generation station 10 uses KP-ABE to generate a control key and its corresponding public key PK KP The control key generation station 10 is realized by, for example, a general-purpose server or a group of servers made up of such general-purpose servers.

[0030] The user terminal 20 is a terminal used by a user (i.e., a sender or a receiver) who performs encryption or decryption, or a terminal that is considered to be the user himself. That is, the user terminal 20 used by the sender or the user terminal 20 considered to be the sender creates a ciphertext by encrypting the content to be encrypted as a message M using AES, and also generates a public key PK KP The common key K is then encrypted using the control key. Meanwhile, the user terminal 20 used by the recipient or the user terminal 20 considered to be the recipient decrypts the common key K using the control key, and then decrypts the ciphertext of the content using the common key K. The user terminal 20 may be realized by, for example, a PC (personal computer), a smartphone, a tablet terminal, a wearable device, a game device, an in-vehicle device, or various IoT (Internet of Things) devices.

[0031] Hereinafter, as an example, the total number of user terminals 20 is set to n, and each user terminal 20 is referred to as a “user terminal 20 i ” (i=1, . . . , n). In the following, the user terminal 20 itself will be regarded as the user, and the user terminal 20 that performs encryption will also be referred to as the sender, and the user terminal 20 that performs decryption will also be referred to as the receiver.

[0032] It should be noted that the overall configuration of the encryption system 1 shown in Fig. 1 is an example and is not limited to this. For example, in the example shown in Fig. 1, a plurality of user terminals 20 exist under the control of one control key generation station 10, but there may be a plurality of control key generation stations 10, and a plurality of user terminals 20 may exist under the control of each control key generation station 10.

[0033] <Example of functional configuration of each entity included in the cryptographic system 1 according to the first embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the first embodiment will be described below.

[0034] <Example of functional configuration of control key generation station 10> An example of the functional configuration of the control key generation station 10 according to the first embodiment will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the first embodiment.

[0035] 2, the control key generation station 10 according to the first embodiment includes a communication unit 101, a KP attribute cipher setup unit 102, a control key generation unit 103, and a revoked content management unit 104. Each of these units is realized, for example, by processing executed by a processor such as a CPU (Central Processing Unit) by one or more programs installed in the control key generation station 10. The control key generation station 10 according to the first embodiment also includes a key storage unit 105 and a revoked content ID list storage unit 106. Each of these storage units is realized, for example, by a storage area of ​​a storage device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory.

[0036] The communication unit 101 receives data from other entities and transmits data to other entities.

[0037] The KP attribute encryption setup unit 102 executes the KP-ABE setup algorithm SetupKP to generate the secret key MSK KP and the public key PK KP and generate.

[0038] The control key generation unit 103 executes the KP-ABE key generation algorithm KeyGenKP to generate a policy-attached private key as a control key.

[0039] The invalid content management unit 104 manages the invalid content ID list stored in the invalid content ID list storage unit 106. That is, the invalid content management unit 104 adds content IDs to the invalid content ID list or deletes content IDs from the invalid content ID list. Here, the invalid content ID list is a list of content IDs of invalidated content. Furthermore, a content ID is identification information that uniquely identifies content at least under the control of the control key generation station 10. Any information can be used as the content ID as long as it can uniquely identify content at least under the control of the control key generation station 10. For example, information that combines the file name of the content and the distribution date and time of the content, or information that combines the name of a project or other name in which the content is used, the distribution date, and a sequential number assigned in the order of distribution can be used as the content ID. However, these are merely examples. For example, information containing some random number element may be used as the content ID, information that includes the URL (Uniform Resource Locator) of the content storage location may be used as the content ID, or the GUID of the content may be used as the content ID. Alternatively, information containing a hash value of the content may be used as the content ID, or information containing the sender's telephone number, email address, etc. may be used as the content ID.

[0040] Hereinafter, when a user of the user terminal 20 acting as a sender references either the content ID or the content and is able to identify the other, this is referred to as "guessable," and a guessable content ID is referred to as a "guessable content ID." In contrast, when a user of the user terminal 20 acting as a sender references either the content ID or the content and is unable to identify the other, this is referred to as "unguessable," and an unguessable content ID is referred to as an "unguessable content ID." An example of a guessable content ID is a content ID that combines the file name of the content and the distribution date and time of the content. On the other hand, an example of an unguessable content ID is a content ID that includes a random number element or a content ID that includes a hash value of the content. Referencing content includes referencing the content itself as well as the file name or meta information of the content. Hereinafter, in the first embodiment, it is primarily assumed that the content ID is guessable.

[0041] The key storage unit 105 stores the secret key MSK generated by the KP attribute encryption setup unit 102. KP and public key PK KP Remember.

[0042] The invalid content ID list storage unit 106 stores an invalid content ID list. Note that the invalid content ID list may include, in addition to the content IDs of invalidated contents, for example, a reference expiration date indicating the time limit for invalidating the content. In other words, the invalid content ID list may be a list having, as elements, information in a format such as (content ID, reference expiration date).

[0043] <<Example of functional configuration of user terminal 20>> An example of the functional configuration of the user terminal 20 according to the first embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the functional configuration of the user terminal 20 according to the first embodiment.

[0044] 3, the user terminal 20 according to the first embodiment includes a communication unit 201, a symmetric key generation unit 202, a symmetric key encryption unit 203, a KP attribute encryption unit 204, a control key management unit 205, a KP attribute decryption unit 206, a symmetric key decryption unit 207, and a revoked content ID designation unit 208. Each of these units is realized, for example, by processing executed by a processor such as a CPU by one or more programs installed in the user terminal 20. The user terminal 20 according to the first embodiment also includes a key storage unit 209 and a content storage unit 210. Each of these storage units is realized, for example, by a storage area of ​​a storage device such as an HDD, SSD, or flash memory.

[0045] The communication unit 201 receives data from other entities and transmits data to other entities.

[0046] When the user terminal 20 is the sender, the symmetric key generation unit 202 generates an AES symmetric key K. The symmetric key generation unit 202 may generate the symmetric key K using, for example, a random number.

[0047] When the user terminal 20 is the sender, the common key encryption unit 203 executes the AES encryption algorithm EncAES using the common key K generated by the common key generation unit 202, and generates a ciphertext C1 by encrypting the content to be encrypted as a message M.

[0048] When the user terminal 20 is the sender, the KP attribute encryption unit 204 executes the KP-ABE encryption algorithm EncKP using the content ID of the content encrypted by the common key encryption unit 203 as attribute information, and generates an attribute-attached ciphertext C2 by encrypting the AES common key K.

[0049] When the user terminal 20 is a recipient, the control key management unit 205 manages the control keys stored in the key storage unit 209. That is, when the control key management unit 205 receives a control key from the control key generation station 10, it overwrites and updates the control key stored in the key storage unit 209 with the control key.

[0050] When the user terminal 20 is the recipient, the KP attribute decryption unit 206 executes the decryption algorithm DecKP using the control key stored in the key storage unit 209 to decrypt the attribute-added ciphertext C2. As a result, the common key K or information indicating a decryption failure is obtained as the decryption result.

[0051] When the user terminal 20 is the recipient, the common key decryption unit 207 executes the AES decryption algorithm DecAES using the common key K obtained by the KP attribute decryption unit 206 to decrypt the ciphertext C1, thereby obtaining the content as the decryption result.

[0052] When the user terminal 20 is the sender, the invalidation content ID designation unit 208 accepts the designation of the content ID of the content to be invalidated (hereinafter also referred to as "content ID to be invalidated").

[0053] The key storage unit 209 stores various keys. For example, when the user terminal 20 is the sender, the key storage unit 209 of the user terminal 20 stores the common key K and the public key PK generated by the common key generation unit 202. KP On the other hand, for example, when the user terminal 20 is the recipient, the key storage unit 209 of this user terminal 20 stores the control key, the common key K obtained as a decryption result by the KP attribute decryption unit 206, and the like.

[0054] The content storage unit 210 stores content. For example, when the user terminal 20 is a sender, the content storage unit 210 of the user terminal 20 stores the content to be encrypted. On the other hand, when the user terminal 20 is a receiver, the content storage unit 210 of the user terminal 20 stores the content obtained as a result of decryption by the common key decryption unit 207.

[0055] When the user terminal 20 is the sender, the user terminal 20 does not need to have the units necessary for decryption (control key management unit 205, KP attribute decryption unit 206, and common key decryption unit 207). Similarly, when the user terminal 20 is the receiver, the user terminal 20 does not need to have the units necessary for encryption and content invalidation (common key generation unit 202, common key encryption unit 203, KP attribute encryption unit 204, and invalid content ID designation unit 208).

[0056] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the First Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the first embodiment.

[0057] <<Setup Process of Control Key Generation Station 10>> The setup process of the control key generation station 10 according to the first embodiment will be described with reference to Fig. 4. Fig. 4 is a flowchart showing an example of the setup process of the control key generation station 10 according to the first embodiment.

[0058] The KP attribute cipher setup unit 102 of the control key generation station 10 executes the setup algorithm SetupKP to generate the secret key MSK KP and the public key PK KP That is, the KP attribute encryption setup unit 102 generates (MSK KP ,PK KP )←SetupKP(1 λ ) to obtain the secret key MSK KP and the public key PK KPwhere λ is a security parameter.

[0059] The KP attribute cipher setup unit 102 of the control key generation station 10 uses the secret key MSK generated in step S101 above. KP and public key PK KP is stored in the key storage unit 105, and the public key PK KP is made public to other entities by any method (step S102).

[0060] <Control key distribution process> The control key distribution process according to the first embodiment will be described with reference to Fig. 5. Fig. 5 is a flowchart showing an example of the control key distribution process according to the first embodiment. Here, the control key distribution process described below is executed at predetermined time intervals (for example, every few hours, every day, every few days, or at irregular time intervals). That is, a new control key is generated at predetermined time intervals, and a ciphertext obtained by encrypting the control key is distributed to each user terminal 20. Hereinafter, the control key is referred to as CK, and the period for generating and distributing the control key CK is referred to as Δ. Note that steps S201 to S203 in Fig. 5 are processes executed by the control key generation station 10, and steps S204 to S205 are processes executed by each user terminal 20.

[0061] The control key generation unit 103 of the control key generation station 10 obtains the current date and time as the generation date and time of the control key CK (step S201). Note that the control key generation unit 103 may obtain the current date and time from a clock function provided in the control key generation station 10, or may obtain the current date and time from an NTP (Network Time Protocol) server or the like.

[0062] The control key generation unit 103 of the control key generation station 10 executes the key generation algorithm KeyGenKP using a condition indicating that the content ID has not been revoked, and generates a policy-attached secret key as a control key CK (step S202). That is, the control key generation unit 103 performs the following operation: CK←KeyGenKP(MSK KP , P1) to generate a control key CK. Here, P1 is a decryption condition (policy) that includes at least a condition indicating that the content ID is not invalid. For example, P1 may be a condition that "the content ID is not included in the invalid content ID list." 11 The condition "encryption date and time - α1 ≦ control key CK generation date and time ≦ ciphertext usage end date and time" is set as P 12 Then, P1=P 11 KatsP 12 etc. Note that condition P 11 corresponds to the condition indicating that the content ID has not been invalidated.

[0063] The above decryption condition P1 means that decryption is possible when the content ID included in the attribute information embedded in the attribute-added ciphertext C2 is not included in the invalid content ID list, and the generation date and time of the control key CK is included in the period from the generation date and time of the attribute-added ciphertext C2 (i.e., the encryption date and time of the attribute-added ciphertext C2) -α1 to the end date and time of use of the ciphertext. This makes it possible to control the ciphertexts that can be decrypted, and in addition to preventing the decryption of invalidated content, it is also possible to prevent decryption by someone who only possesses an old control key CK.

[0064] Note that the above decoding condition P1 includes the condition P 12 This condition P 12 may not be included in the decoding condition P1. 12 Instead, the condition P 13Here, the encryption date and time may be called the "ciphertext usage start date and time," and the two are assumed to be the same. α1 is a constant that takes into account the cycle at which the control key CK is generated and distributed, and is a value greater than or equal to 0 that satisfies α1+α2≦Δ between it and α2, which will be described later.

[0065] The communication unit 101 of the control key generation station 10 transmits the control key CK generated in step S202 above to each user terminal 20 (step S203). As a result, the control key CK is distributed to each user terminal 20. However, the communication unit 101 may transmit the control key CK only to the user terminal 20 that is to be the recipient, for example. Furthermore, when transmitting the control key CK, the communication unit 101 may encrypt the control key CK using any encryption method, or may use a secure communication path using SSL (Secure Sockets Layer) or the like.

[0066] The communication unit 201 of the user terminal 20 receives the control key CK transmitted from the control key generation station 10 (step S204).

[0067] The control key management unit 205 of the user terminal 20 stores the control key CK received in step S204 above in the key storage unit 209 (step S205). However, if the previously distributed control key CK is stored in the key storage unit 209, the control key management unit 205 overwrites the previously distributed control key CK with the control key CK received in step S204 above. As a result, the latest control key CK is stored in the key storage unit 209.

[0068] <Encryption process> The encryption process according to the first embodiment will be described with reference to FIG. 6. FIG. 6 is a flowchart showing an example of the encryption process according to the first embodiment. In the following, the recipient is the user terminal 20. i , the sender is a user terminal 20 j (j≠i), and the user terminal 20 jThe case where the encryption process is executed will be described.

[0069] User terminal 20 j The symmetric key generation unit 202 generates an AES symmetric key K (step S301). The symmetric key generation unit 202 may generate the symmetric key K using, for example, a random number.

[0070] User terminal 20 j The common key encryption unit 203 executes the encryption algorithm EncAES using the common key K generated in step S301 above, with the content to be encrypted as message M, to generate ciphertext C1 by encrypting the message M (step S302). That is, the common key encryption unit 203 generates ciphertext C1 by C1←EncAES(K,M).

[0071] User terminal 20 j The KP attribute encryption unit 204 executes the encryption algorithm EncKP using the content ID of the content to be encrypted, and generates attribute-attached ciphertext C2 by encrypting the common key K generated in step S301 (step S303). That is, the KP attribute encryption unit 204 performs the following operation: C2←EncKP(PK KP , K, att) to generate an attribute-attached ciphertext C2. Here, att is attribute information that includes at least the content ID of the content to be encrypted. Att may be, for example, att=content ID of the content to be encrypted || encryption date and time-α2|| end date and time of use of the attribute-attached ciphertext C2 (end date and time of use of the ciphertext). However, for example, att may be set to || encryption date and time-α2 or att=content ID of the content to be encrypted. || represents a logical sum, and the encryption date and time is the generation date and time of the attribute-attached ciphertext C2. Furthermore, the end date and time of use of the attribute-attached ciphertext C2 (end date and time of use of the ciphertext) may be set to, for example, the sender user terminal 20 j is set by

[0072] Note that, for example, by setting the maximum value that can be taken in implementation as the usage end date and time of the attribute-attached ciphertext C2, the usage end date and time of the attribute-attached ciphertext C2 (att=content ID of the content to be encrypted || encryption date and time-α2||) can be regarded as the same as the usage end date and time of the attribute-attached ciphertext C2 (att=content ID of the content to be encrypted || encryption date and time-α2). α2 is a constant that takes into account the cycle at which the control key CK is generated and distributed, and is a value greater than or equal to 0 that satisfies α1+α2≦Δ.

[0073] User terminal 20 j The communication unit 201 transmits the ciphertext C={C1, C2} to the user terminal 20. i (step S304).

[0074] <Decryption process> The decoding process according to the first embodiment will be described with reference to FIG. 7. FIG. 7 is a flowchart showing an example of the decoding process according to the first embodiment. i The case where the decoding process is performed will be described.

[0075] User terminal 20 i The communication unit 201 of the user terminal 20 j The encrypted text C={C1, C2} sent from the ciphertext server 100 is received (step S401).

[0076] User terminal 20 i The KP attribute decryption unit 206 executes the decryption algorithm DecKP using the control key CK stored in the key storage unit 209 to decrypt the attribute-attached ciphertext C2 (step S402). That is, the KP attribute decryption unit 206 executes DecKP(CK, C2). As a result, if the attribute information att embedded in the attribute-attached ciphertext C2 satisfies the decryption condition P1 embedded in the control key CK, the common key K is obtained as the decryption result. On the other hand, if the attribute information att embedded in the attribute-attached ciphertext C2 does not satisfy the decryption condition P1 embedded in the control key CK, information indicating a decryption failure is obtained as the decryption result.

[0077] For example, att = content ID of the content to be encrypted || encryption date and time - α2 || end date and time of use of attribute-attached ciphertext C2, P1 = P 11 KatsP 12 In this case, if the content ID of the content to be encrypted is not included in the invalid content ID list, and the generation date and time of the control key CK is included in the period from the generation date and time of the attribute-attached ciphertext C2 -α1 to the end date and time of use of the ciphertext, the common key K is obtained as the decryption result. Or, for example, if att=content ID of the content to be encrypted, P1=P 11 In this case, if the content ID of the content to be encrypted is not included in the invalid content ID list, the common key K is obtained as the decryption result. The following description will continue assuming that the common key K has been obtained. Note that if information indicating a decryption failure is obtained, the KP attribute decryption unit 206 ends the decryption process.

[0078] User terminal 20 i The common key decryption unit 207 executes the AES decryption algorithm DecAES using the common key K obtained in step S402 above to decrypt the ciphertext C1 (step S403). That is, the common key decryption unit 207 executes DecAES(K, C1). As a result, the message M, which is the content, is obtained as the decryption result.

[0079] <Content invalidation process> The content revocation process according to the first embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart showing an example of the content revocation process according to the first embodiment. Note that steps S501 and S502 in Fig. 8 are processes executed by the user terminal 20, and steps S503 and S504 are processes executed by the control key generation station 10.

[0080] The invalidation content ID designation unit 208 of the user terminal 20 accepts the designation of the content ID to be invalidated (step S501). Here, the user of the user terminal 20 may identify the content ID to be invalidated by, for example, remembering the content ID of the content to be invalidated or by referring to the content transmission history, and then designate the content ID.

[0081] The communication unit 201 of the user terminal 20 transmits a content invalidation request including the content ID specified in step S501 above to the control key generation station 10 (step S502). The content invalidation request may include a reference expiration date in addition to the content ID. In this case, the content ID and the reference expiration date are added to the invalid content ID list in step S504, which will be described later.

[0082] The communication unit 101 of the control key generation station 10 receives the content invalidation request transmitted from the user terminal 20 (step S503).

[0083] The invalid content management unit 104 of the control key generation station 10 adds the content ID included in the content invalidation request received in step S503 to the invalid content ID list (step S504). This prevents the decryption of the common key K for decrypting the content with that content ID, and as a result, prevents the decryption of that content, thereby realizing the cancellation of distribution of that content.

[0084] <Summary of the First Embodiment> As described above, in the encryption system 1 according to the first embodiment, the condition P "the content ID is not included in the invalid content ID list" is satisfied by using KP-ABE. 11The sender delivers to the receiver as a control key CK a secret key embedded with decryption conditions including at least the above. The sender also encrypts the content with a common key K and encrypts the common key K using KP-ABE with at least the content ID as attribute information. Therefore, if the sender invalidates the content, the receiver cannot decrypt the common key K needed to decrypt the content, and as a result, it becomes possible to cancel the distribution of the content.

[0085] In addition to the above, the encryption system 1 according to the first embodiment distributes the control key CK to the recipient at regular or irregular intervals Δ. Therefore, unlike a method of controlling content decryption by a server inquiry, such as DRM (Digital Rights Management), the recipient can decrypt the content even offline. Since the control key CK is common to all recipients under the control of the control key generation station 10, there is also the advantage that the cost (processing load, etc.) of distributing the control key CK to each recipient is not high. Furthermore, since the cost of distributing the control key CK to each recipient is not high, the interval Δ can be set to a small value (e.g., several hours), which enables content distribution cancellation to be controlled in a shorter time.

[0086] Here, the invalid content ID list corresponds to a blacklist containing the content IDs of content that is prohibited from being decrypted. Therefore, after the operation of the encryption system 1 according to this embodiment, the size of the invalid content ID list may become enormous. Therefore, for example, if the elements contained in the invalid content ID list are in the format of (content ID, reference expiration date), the invalid content management unit 104 may periodically or irregularly delete elements whose reference expiration date has passed from the invalid content ID list. This is expected to prevent the size of the invalid content ID list from becoming enormous.

[0087] [Second embodiment] A second embodiment will be described below. In the second embodiment, a case will be described in which a "valid content ID list" which is a whitelist containing the content IDs of content that is permitted to be decrypted is used instead of the invalid content ID list. This is expected to prevent the size of the valid content ID list from becoming enormous.

[0088] In the second embodiment, differences from the first embodiment will be mainly described, and a description of components that may be the same as those in the first embodiment will be omitted. That is, elements that are not particularly described in the second embodiment may be the same as those in the first embodiment.

[0089] <Example of functional configuration of each entity included in the cryptographic system 1 according to the second embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the second embodiment will be described below.

[0090] <Example of functional configuration of control key generation station 10> An example of the functional configuration of the control key generation station 10 according to the second embodiment will be described with reference to Fig. 9. Fig. 9 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the second embodiment.

[0091] 9, the control key generation station 10 according to the second embodiment has a valid content management unit 107 instead of the invalid content management unit 104 described in the first embodiment. The valid content management unit 107 is realized, for example, by a process in which one or more programs installed in the control key generation station 10 are executed by a processor such as a CPU. Furthermore, the control key generation station 10 according to the second embodiment has a valid content ID list storage unit 108 instead of the invalid content ID list storage unit 106 described in the first embodiment. The valid content ID list storage unit 108 is realized, for example, by a storage area of ​​a storage device such as an HDD, SSD, or flash memory.

[0092] The valid content management unit 107 manages the valid content ID list stored in the valid content ID list storage unit 108. That is, the valid content management unit 107 adds content IDs to the valid content ID list and deletes content IDs from the valid content ID list. Here, the valid content ID list is a list of content IDs of validated content (i.e., content that is permitted to be decrypted). Note that, in the second embodiment as in the first embodiment, it is mainly assumed that content IDs are guessable.

[0093] The valid content ID list storage unit 108 stores a valid content ID list. Note that the valid content ID list may include, in addition to the content ID of the validated content, for example, the version of the content. In other words, the valid content ID list may be a list having, as elements, information in a format such as (content ID, version).

[0094] <<Example of functional configuration of user terminal 20>> An example of the functional configuration of the user terminal 20 according to the second embodiment will be described with reference to Fig. 10. Fig. 10 is a diagram showing an example of the functional configuration of the user terminal 20 according to the second embodiment.

[0095] 10, the user terminal 20 according to the second embodiment has an enabling content ID designation unit 211 instead of the disabling content ID designation unit 208 described in the first embodiment. The enabling content ID designation unit 211 is realized, for example, by a process in which one or more programs installed in the user terminal 20 are executed by a processor such as a CPU.

[0096] When the user terminal 20 is the sender, the validation content ID designation unit 211 accepts designation of the content ID of the content to be validated (hereinafter also referred to as "content ID to be validated").

[0097] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Second Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the second embodiment.

[0098] <Control key distribution process> The control key distribution process according to the second embodiment will be described with reference to Fig. 11. Fig. 11 is a flowchart showing an example of the control key distribution process according to the second embodiment. Here, the control key distribution process described below is executed at predetermined time intervals. Note that steps S601 to S603 in Fig. 11 are processes executed by the control key generation station 10, and steps S604 to S605 are processes executed by each user terminal 20.

[0099] The control key generation unit 103 of the control key generation station 10 acquires the current date and time as the generation date and time of the control key CK, similarly to step S201 in FIG. 5 (step S601).

[0100] The control key generation unit 103 of the control key generation station 10 executes the key generation algorithm KeyGenKP using the condition indicating that the content ID is validated, and generates a policy-attached secret key as a control key CK (step S602). That is, the control key generation unit 103 performs the following operation: CK←KeyGenKP(MSK KP , P1) to generate a control key CK. Here, P1 is a decryption condition (policy) that includes at least a condition indicating that the content ID is validated. For example, P1 may be a condition that "the content ID is included in the valid content ID list." 11 ', the condition "encryption date and time - α1 ≦ control key CK generation date and time ≦ ciphertext usage end date and time" is satisfied. 12 Then, P1=P 11 'KatsuP 12 etc. Note that condition P 11 ' corresponds to the condition indicating that the content ID is validated.

[0101] The above decryption condition P1 means that decryption is possible when the content ID included in the attribute information embedded in the attribute-added ciphertext C2 is included in the valid content ID list, and the generation date and time of the control key CK is included in the period from the generation date and time of the attribute-added ciphertext C2 -α1 to the end date and time of use of the ciphertext. This makes it possible to control the ciphertexts that can be decrypted, and in addition to preventing the decryption of invalid content, it is also possible to prevent decryption by someone who only possesses an old control key CK.

[0102] Note that the above decoding condition P1 includes the condition P 12 This condition P 12 may not be included in the decoding condition P1. 12 Instead, the condition P 13 may also be used.

[0103] Steps S603 to S605 in FIG. 11 may be similar to steps S203 to S205 in FIG. 5, respectively, and therefore a description thereof will be omitted.

[0104] <Content Activation Process> The content validation process according to the second embodiment will be described with reference to Fig. 12. Fig. 12 is a flowchart showing an example of the content validation process according to the second embodiment. Note that steps S701 and S702 in Fig. 12 are processes executed by the user terminal 20, and steps S703 and S704 are processes executed by the control key generation station 10.

[0105] The activation content ID designation unit 211 of the user terminal 20 accepts the designation of the content ID to be activated (step S701). Here, if the content has already been distributed, the user of the user terminal 20 may identify the content ID to be invalidated by, for example, remembering the content ID of the content to be activated or by referring to the content transmission history, and designate that content ID. On the other hand, if the content has not yet been distributed, the user may identify the content ID of the content to be distributed and designate that content ID.

[0106] The communication unit 201 of the user terminal 20 transmits a content validation request including the content ID specified in step S701 above to the control key generation station 10 (step S702). The content validation request may include a version in addition to the content ID. In this case, the content ID and version are added to the valid content ID list in step S704, which will be described later. However, if an element including the same content ID exists in the valid content ID list, that element is overwritten and updated with the content ID and version included in the content validation request.

[0107] The communication unit 101 of the control key generation station 10 receives the content validation request sent from the user terminal 20 (step S703).

[0108] The valid content management unit 107 of the control key generation station 10 adds the content ID included in the content validation request received in step S703 to the valid content ID list (step S704). This allows decryption of the common key K for decrypting the content with that content ID. This makes it possible to prevent decryption of the content until it is validated.

[0109] <Summary of the second embodiment> As described above, in the encryption system 1 according to the second embodiment, the condition P "the content ID is included in the valid content ID list" is satisfied by using KP-ABE. 11 A secret key embedded with decryption conditions that include at least ' is delivered to the recipient as a control key CK. This makes it possible to reduce the size of the valid content ID list, and is expected to prevent the list from becoming enormously large.

[0110] In addition to the above, in the encryption system 1 according to the second embodiment, since decryption of content is prevented until the content is validated, it is possible to, for example, validate content at any time after it has been distributed. Of course, it is also possible to distribute content after it has been validated.

[0111] Here, when it is desired to invalidate a content with a content ID included in the valid content ID list, for example, the user terminal 20 can transmit a content invalidation request including that content ID to the control key generation station 10 via the communication unit 101. As a result, in the control key generation station 10, the valid content management unit 107 deletes the content ID included in the content invalidation request from the valid content ID list.

[0112] [Third embodiment] A third embodiment will be described below. In the third embodiment, a case will be described in which the common key K is encrypted using CP-ABE and then further encrypted using KP-ABE. This allows only recipients who satisfy the decryption conditions embedded by CP-ABE to decrypt the common key K, making it possible to control the right to decrypt the common key K.

[0113] In the third embodiment, differences from the first embodiment will be mainly described, and a description of components that may be the same as those in the first embodiment will be omitted. That is, elements that are not particularly described in the third embodiment may be the same as those in the first embodiment.

[0114] <Example of overall configuration of cryptographic system 1 according to third embodiment> An example of the overall configuration of the cryptographic system 1 according to the third embodiment will be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the overall configuration of the cryptographic system 1 according to the third embodiment.

[0115] As shown in FIG. 13, the cryptographic system 1 according to the third embodiment further includes one or more attribute key generation authorities 30 as entities.

[0116] Hereinafter, the range for which the attribute key generation station 30 generates an attribute key will be referred to as a "domain," and an attribute key generation station 30 exists for each domain, with one or more user terminals 20 existing within each domain. For example, the example shown in Fig. 13 shows a case where two domains, domain D1 and domain D2, exist. Note that examples of domains include companies, organizations, prefectures, cities, towns, and villages, and some services (subscriber service, SNS (Social Networking Service), online game service, etc.).

[0117] The attribute key generation station 30 generates attribute keys and corresponding public keys PK using CP-ABE. CP In the following, the user terminal 20 i Attribute key of SK i The attribute key generation station 30 is realized by, for example, a general-purpose server or a group of servers made up of such general-purpose servers.

[0118] Note that the overall configuration of the cryptosystem 1 shown in Fig. 13 is an example and is not limited to this. For example, in the example shown in Fig. 13, two domains, domains D1 and D2, are illustrated, but the number of domains is not limited to two, and any number of domains greater than or equal to one may exist.

[0119] <Example of functional configuration of each entity included in the cryptographic system 1 according to the third embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the third embodiment will be described below.

[0120] <<Example of functional configuration of user terminal 20>> An example of the functional configuration of the user terminal 20 according to the third embodiment will be described with reference to Fig. 14. Fig. 14 is a diagram showing an example of the functional configuration of the user terminal 20 according to the third embodiment.

[0121] 14, the user terminal 20 according to the third embodiment has, in addition to the units described in the first embodiment, a CP attribute encryption unit 212, an attribute key management unit 213, and a CP attribute decryption unit 214. These units are realized, for example, by processing in which one or more programs installed in the user terminal 20 are executed by a processor such as a CPU.

[0122] When the user terminal 20 is the sender, the CP attribute encryption unit 212 executes the CP-ABE encryption algorithm EncCP using any decryption condition to generate a policy-attached ciphertext C2 by encrypting the AES common key K. The KP attribute encryption unit 204 executes the KP-ABE encryption algorithm EncKP using the content ID of the content to be encrypted as attribute information to generate an attribute-attached ciphertext C3 by further encrypting the policy-attached ciphertext C2.

[0123] The attribute key management unit 213 manages attribute keys when the user terminal 20 is a recipient. That is, the attribute key management unit 213 stores the attribute keys generated by the attribute key generation station 30 in the key storage unit 209.

[0124] When the user terminal 20 is the recipient, the CP attribute decryption unit 214 executes the decryption algorithm DecCP using the attribute key stored in the key storage unit 209, and decrypts the policy-attached ciphertext C2 decrypted by the KP attribute decryption unit 206. As a result, the AES common key K or information indicating a decryption failure is obtained as the decryption result.

[0125] When the user terminal 20 is a sender, the user terminal 20 does not have to have the units necessary for decryption and attribute key management (control key management unit 205, KP attribute decryption unit 206, common key decryption unit 207, attribute key management unit 213, and CP attribute decryption unit 214). Similarly, when the user terminal 20 is a receiver, the user terminal 20 does not have to have the units necessary for encryption and content revocation (common key generation unit 202, common key encryption unit 203, KP attribute encryption unit 204, revoked content ID designation unit 208, and CP attribute encryption unit 212).

[0126] <Example of functional configuration of attribute key generation station 30> An example of the functional configuration of the attribute key generation station 30 according to the third embodiment will be described with reference to Fig. 15. Fig. 15 is a diagram showing an example of the functional configuration of the attribute key generation station 30 according to the third embodiment.

[0127] 15, the attribute key generation authority 30 according to the third embodiment includes a communication unit 301, a CP attribute encryption setup unit 302, a CP attribute key generation unit 303, and an issued key management unit 304. Each of these units is realized, for example, by a processor such as a CPU executing one or more programs installed in the attribute key generation authority 30. The attribute key generation authority 30 according to the third embodiment also includes a key storage unit 305 and an issued key information storage unit 306. Each of these storage units is realized, for example, by a storage area of ​​a storage device such as an HDD, SSD, or flash memory.

[0128] The communication unit 301 receives data from other entities and transmits data to other entities.

[0129] The CP attribute encryption setup unit 302 executes the setup algorithm SetupCP of CP-ABE, and obtains the secret key MSK CP and the public key PK CP and generate.

[0130] When the communication unit 301 receives a key issuance request for an attribute key, the CP attribute key generation unit 303 executes the CP-ABE key generation algorithm KeyGenCP to generate an attribute key for the user terminal 20 that has made the key issuance request.

[0131] The issued key management unit 304 manages the issued key information stored in the issued key information storage unit 306. That is, when an attribute key is generated by the CP attribute key generation unit 303, the issued key management unit 304 stores the issued key information of the attribute key in the issued key information storage unit 306. Furthermore, the issued key management unit 304 periodically or non-periodically deletes the issued key information of attribute keys whose expiration dates have expired from the issued key information storage unit 306.

[0132] The key storage unit 305 stores the secret key MSK generated by the CP attribute encryption setup unit 302. CP and public key PK CP Remember.

[0133] The issued key information storage unit 306 stores issued key information. Here, the issued key information refers to information related to the attribute key generated by the CP attribute key generation unit 303 (i.e., the attribute key that has already been issued). The issued key information includes, for example, the key ID of the attribute key and the expiration date of the attribute key. In other words, the issued key information is information in a format such as (key ID, expiration date).

[0134] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Third Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the third embodiment.

[0135] <<Setup Process of Attribute Key Generation Station 30>> The setup process of the attribute key generation station 30 according to the third embodiment will be described with reference to Fig. 16. Fig. 16 is a flowchart showing an example of the setup process of the attribute key generation station 30 according to the third embodiment.

[0136] The CP attribute encryption setup unit 302 of the attribute key generation station 30 executes the setup algorithm SetupCP to generate the secret key MSK CP and the public key PK CP That is, the CP attribute cipher setup unit 302 generates (MSK CP ,PK CP )←SetupCP(1 μ ) to obtain the secret key MSK CP and the public key PK CP where μ is a security parameter.

[0137] The CP attribute encryption setup unit 302 of the attribute key generation station 30 uses the secret key MSK generated in step S801 above. CP and public key PK CP is stored in the key storage unit 305, and the public key PK CP is made public to other entities by any method (step S802).

[0138] In addition, the secret key MSK CP and public key PK CP It should be noted that the private key and public key of the attribute key generation authority 30 of the domain D1 are respectively MSK CP (1) and PK CP (2) The private key and public key of the attribute key generation station 30 of the domain D2 are respectively represented as MSK CP (2) and PK CP (2) In other words, in general, domain D n The private key and public key of the attribute key generation station 30 (n=1, . . . , N, where N is the number of domains) are respectively MSK CP (n) and PK CP (n) It is expressed as:

[0139] Attribute key delivery process The attribute key distribution process according to the third embodiment will be described with reference to Fig. 17. Fig. 17 is a flowchart showing an example of the attribute key distribution process according to the third embodiment. Note that steps S901 and S907 to S908 in Fig. 17 are processes executed by the user terminal 20, and steps S902 to S906 are processes executed by the attribute key generation station 30. In the following, it will be assumed that an attribute key generation station 30 existing in a certain domain distributes an attribute key to a certain user terminal 20 existing in the same domain. i Attribute key SK i The following describes the case where the above is generated and delivered.

[0140] User terminal 20 i The communication unit 201 transmits a key issuance request to the attribute key generation station 30 (step S901).

[0141] The communication unit 301 of the attribute key generation station 30 communicates with the user terminal 20 i The communication unit 301 of the attribute key generation station 30 receives the key issuance request transmitted from the user terminal 20 (step S902). i The authentication method is not limited to a specific authentication method, and any authentication method can be adopted. However, the communication unit 301 may, for example, authenticate the user terminal 20 using a user ID and a password. i The user terminal 20 may be authenticated, or a secure session may be established. i In addition, the communication unit 301 may authenticate the user terminal 20 by using, for example, a terminal identifier. i Alternatively, other authentication methods (for example, biometric authentication, mnemonic authentication, CAPTCHA authentication) may be used to authenticate the user terminal 20. i The communication unit 301 may also authenticate the user terminal 20 by a combination of a plurality of authentication methods. i may be authenticated.

[0142] The CP attribute key generation unit 303 of the attribute key generation station 30 generates a key ID that does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 306 (step S903). The CP attribute key generation unit 303 may use any method to generate a key ID that does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 306. For example, the CP attribute key generation unit 303 may generate a random value as the key ID that does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 306. In addition to this, for example, the CP attribute key generation unit 303 may generate a key ID that does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 306. i If a previously issued attribute key exists in the issued key information storage unit 306, the key ID may be generated by adding 1 to the key ID of that attribute key (however, this value does not overlap with the key ID included in the issued key information stored in the issued key information storage unit 306).

[0143] The CP attribute key generation unit 303 of the attribute key generation station 30 executes the key generation algorithm KeyGenCP and generates a CP attribute key from the user terminal 20. i Attribute key SK i That is, the CP attribute key generation unit 303 generates SK i ←KeyGenCP(MSK CP ,A i ) to generate the attribute key SK i where A i is the user terminal 20 i This is attribute information of A. i For example, the user terminal 20 i The attribute includes the key ID generated in step S903 and an expiration date. The attribute is not limited to a specific type, but typical examples include a personal ID, an email address, a telephone number, an organization, and a job title. However, these are just examples, and various attributes that can be used in existing attribute-based encryption can be used. The expiration date can be, for example, a date and time a predetermined time after the current date and time (a specific example is a date and time one year after the current date and time).

[0144] In addition, attribute information A iIn addition to the attribute, key ID, and expiration date, the attribute key SK may also include, for example, a generation. i Attribute information A i By including the generation in the attribute key, it is possible to make the attribute information different even for the same attribute, so that, for example, it is possible to issue a different attribute key in which the same attribute as the expired attribute key is embedded.

[0145] The issued key management unit 304 of the attribute key generation station 30 receives the attribute key SK i Attribute information A used to generate i The attribute key SK generated in step S904 is stored in the issued key information storage unit 306 using the key ID and expiration date included in the attribute key SK generated in step S904. i (i.e., the newly issued attribute key SK i ) has been registered.

[0146] The communication unit 301 of the attribute key generation station 30 transmits the attribute key SK generated in step S904 above. i user terminal 20 i (Step S906). The communication unit 301 transmits the attribute key SK by any secure method. i user terminal 20 i Just send it to .

[0147] User terminal 20 i The communication unit 201 receives the attribute key SK transmitted from the attribute key generation station 30. i is received (step S907).

[0148] User terminal 20 i The attribute key management unit 213 of the attribute key management unit 213 receives the attribute key SK in step S907. i is stored in the key storage unit 209 (step S908).

[0149] <Encryption process> The encryption process according to the third embodiment will be described with reference to FIG. 18. FIG. 18 is a flowchart showing an example of the encryption process according to the third embodiment. In the following, the recipient is the user terminal 20. i , the sender is a user terminal 20 j (j≠i), and the user terminal 20 j The case where the encryption process is executed will be described.

[0150] Steps S1001 and S1002 in FIG. 18 may be similar to steps S301 and S302 in FIG. 6, respectively, and therefore a description thereof will be omitted.

[0151] User terminal 20 j The CP attribute encryption unit 212 executes the encryption algorithm EncCP to generate a policy-attached ciphertext C2 by encrypting the common key K generated in step S1001 (step S1003). That is, the CP attribute encryption unit 212 performs the encryption algorithm EncCP to encrypt the common key K generated in step S1001. CP , K, P2) to generate a policy-attached ciphertext C2. Here, P2 is a decryption condition (policy) and may be any condition, but it is preferable that the condition include, for example, that the expiration date of the attribute key has not yet arrived. For example, it is possible to set P2=(expiration date of the attribute key>date and time of decryption+α) and (the organization to which the recipient belongs is ABC). α is a small value that takes into account the processing time required to decrypt the policy-attached ciphertext C2, and is set in advance. However, α=0 may also be used.

[0152] More generally, the above decryption condition P2 can be set as P2=P3, or P2=(expiration date of attribute key>date and time of decryption+α) and P3, where P3 is any condition related to the attribute.

[0153] User terminal 20 jThe KP attribute encryption unit 204 executes the encryption algorithm EncKP using the content ID of the content to be encrypted, and generates an attribute-attached ciphertext C3 by further encrypting the policy-attached ciphertext C2 generated in step S1003 (step S1004). That is, the KP attribute encryption unit 204 performs the encryption algorithm EncKP using the content ID of the content to be encrypted, and generates an attribute-attached ciphertext C3 by further encrypting the policy-attached ciphertext C2 generated in step S1003 (step S1004). KP , C2, att) to generate attributed ciphertext C3. Note that att may be the same as in step S303 in FIG.

[0154] User terminal 20 j The communication unit 201 transmits the ciphertext C={C1, C3} to the user terminal 20. i (step S1005).

[0155] <Decryption process> The decoding process according to the third embodiment will be described with reference to Fig. 19. Fig. 19 is a flowchart showing an example of the decoding process according to the third embodiment. i The case where the decoding process is performed will be described.

[0156] User terminal 20 i The communication unit 201 of the user terminal 20 j The encrypted text C={C1, C3} sent from the ciphertext server 100 is received (step S1101).

[0157] User terminal 20 iThe KP attribute decryption unit 206 executes the decryption algorithm DecKP using the control key CK stored in the key storage unit 209 to decrypt the attribute-attached ciphertext C3 (step S1102). That is, the KP attribute decryption unit 206 executes DecKP(CK, C3). As a result, if the attribute information att embedded in the attribute-attached ciphertext C3 satisfies the decryption condition P1 embedded in the control key CK, a policy-attached ciphertext C2 is obtained as the decryption result. On the other hand, if the attribute information att embedded in the attribute-attached ciphertext C3 does not satisfy the decryption condition P1 embedded in the control key CK, information indicating a decryption failure is obtained as the decryption result. The following description will be continued assuming that a policy-attached ciphertext C2 has been obtained. Note that if information indicating a decryption failure is obtained, the KP attribute decryption unit 206 terminates the decryption process.

[0158] User terminal 20 i The CP attribute decryption unit 214 uses the attribute key SK stored in the key storage unit 209. i In other words, the CP attribute decryption unit 214 executes the decryption algorithm DecCP using DecCP(SK i , C2) is executed. This results in the attribute key SK i Attribute information A embedded in i If the attribute key SK satisfies the decryption condition P2 embedded in the policy-attached ciphertext C2, the common key K is obtained as the decryption result. i Attribute information A embedded in i However, if the decryption condition P2 embedded in the policy-attached ciphertext C2 is not satisfied, information indicating a decryption failure is obtained as the decryption result.

[0159] For example, if P2 = (expiration date of attribute key > date and time of decryption + α) and P3, attribute information A i However, when the decryption condition P2 is satisfied, the common key K is obtained as the decryption result. iHowever, if the decryption condition P2 is not satisfied, information indicating a decryption failure is obtained as the decryption result. The following description will be continued assuming that the common key K has been obtained. Note that if information indicating a decryption failure is obtained, the CP attribute decryption unit 214 ends the decryption process.

[0160] User terminal 20 i 7, the common key decryption unit 207 executes the AES decryption algorithm DecAES using the common key K obtained in step S1103 above to decrypt the ciphertext C1 (step S1104). That is, the common key decryption unit 207 executes DecAES(K, C1). As a result, the message M, which is the content, is obtained as the decrypted result.

[0161] <Summary of the Third Embodiment> As described above, in the cryptographic system 1 according to the third embodiment, the common key K is encrypted using CP-ABE and then further encrypted using KP-ABE. This allows only recipients who satisfy the decryption conditions embedded by CP-ABE to decrypt the common key K, making it possible to control the right to decrypt the common key K (in other words, it becomes possible for the sender to specify the attributes of the recipients and grant the right to decrypt the common key K only to recipients who have specific attributes).

[0162] [Fourth embodiment] A fourth embodiment will be described below. In the fourth embodiment, a case will be described in which the control key CK is encrypted using CP-ABE and can be decrypted only when the attribute key has not expired. As a result, if the attribute key has expired due to leakage or the like, the control key CK cannot be obtained, and therefore the common key K cannot be obtained, thereby making it possible to improve security against leakage of the attribute key.

[0163] In the fourth embodiment, differences from the third embodiment will be mainly described, and a description of components that may be the same as those in the third embodiment will be omitted. That is, elements that are not particularly described in the fourth embodiment may be the same as those in the third embodiment.

[0164] <Example of functional configuration of each entity included in the cryptographic system 1 according to the fourth embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the fourth embodiment will be described below.

[0165] <Example of functional configuration of control key generation station 10> An example of the functional configuration of the control key generation station 10 according to the fourth embodiment will be described with reference to Fig. 20. Fig. 20 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the fourth embodiment.

[0166] 20, the control key generation station 10 according to the fourth embodiment has a CP attribute encryption unit 109 and a revocation key management unit 110 in addition to the units described in the first embodiment. The CP attribute encryption unit 109 and the revocation key management unit 110 are realized, for example, by a processor such as a CPU executing one or more programs installed in the control key generation station 10. Furthermore, the control key generation station 10 according to the fourth embodiment has a revocation key ID list storage unit 111 in addition to the units described in the first embodiment. The revocation key ID list storage unit 111 is realized, for example, by a storage area of ​​a storage device such as an HDD, an SSD, or a flash memory.

[0167] The CP attribute encryption unit 109 executes the encryption algorithm EncCP of CP-ABE using a condition indicating that the attribute key has not expired, and encrypts the control key CK to generate a policy-attached ciphertext C CK Generate.

[0168] The revoked key management unit 110 manages the revoked key ID list stored in the revoked key ID list storage unit 111. That is, the revoked key management unit 110 adds key IDs to the revoked key ID list or deletes key IDs from the revoked key ID list. Here, the revoked key ID list is a list of key IDs of revoked attribute keys (hereinafter also referred to as "revoked keys").

[0169] The revoked key ID list storage unit 111 stores a revoked key ID list. Note that the revoked key ID list may include, in addition to the key IDs of revoked attribute keys, for example, the expiration dates of the attribute keys. In other words, the revoked key ID list may be a list having information in a format such as (key ID, expiration date) as elements.

[0170] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Fourth Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the fourth embodiment.

[0171] <Control key distribution process> The control key distribution process according to the fourth embodiment will be described with reference to Fig. 21. Fig. 21 is a flowchart showing an example of the control key distribution process according to the fourth embodiment. Here, the following control key distribution process is executed at predetermined time intervals. Note that steps S1201 to S1204 in Fig. 21 are processes executed by the control key generation station 10, and steps S1205 to S1207 are processes executed by each user terminal 20.

[0172] Steps S1201 and S1202 in FIG. 21 may be similar to steps S201 and S202 in FIG. 5, respectively, and therefore a description thereof will be omitted.

[0173] The CP attribute encryption unit 109 of the control key generation station 10 executes the encryption algorithm EncCP of the CP-ABE using a condition indicating that the attribute key has not expired, and generates a policy-attached ciphertext CCK That is, the CP attribute encryption unit 109 generates C CK ←KeyGenCP(PK CP ,CK,P4) to generate the policy-encrypted ciphertext C CK Here, P4 is a decryption condition (policy) that indicates that the attribute key has not been revoked. For example, P4 = "The key ID of the attribute key is not included in the revoked key ID list." This generates a ciphertext C with a policy using an expired attribute key. CK Therefore, even if an attribute key is leaked, for example, by revoking the attribute key, a person who has illegally obtained the attribute key cannot obtain the control key CK. Since the control key CK is a private key with a policy required for decrypting the attribute-added ciphertext C3, a person who has illegally obtained the attribute key cannot decrypt the attribute-added ciphertext C3, and it can be said that security is ensured against leaks of the attribute key.

[0174] The communication unit 101 of the control key generation station 10 receives the policy-attached ciphertext C generated in step S1203 above. CK The communication unit 101 transmits the policy-attached ciphertext C to each user terminal 20 (step S1204). CK may be transmitted.

[0175] The communication unit 201 of the user terminal 20 receives the policy-attached ciphertext C transmitted from the control key generation station 10. CK is received (step S1205).

[0176] The CP attribute decryption unit 214 of the user terminal 20 executes the decryption algorithm DecCP using the attribute key stored in the key storage unit 209, and generates the policy-attached ciphertext C CK That is, the CP attribute decoding unit 214 decodes DecCP(SK,C CK ) is executed, where SK is the attribute key of the user terminal 20. As a result, the attribute information A embedded in the attribute key SK is encrypted as a ciphertext C CKIf the decryption condition P4 embedded in the attribute key SK is satisfied (i.e., the key ID of the attribute key SK is not included in the revoked key ID list), the control key CK is obtained as the decryption result. On the other hand, if the attribute information A embedded in the attribute key SK is CK If the decryption condition P4 embedded in the attribute key SK is not satisfied (i.e., if the key ID of the attribute key SK is included in the revoked key ID list), information indicating a decryption failure is obtained as the decryption result. In the following, the explanation will be continued assuming that a control key CK has been obtained. Note that if information indicating a decryption failure is obtained, the CP attribute decryption unit 214 ends the decryption process.

[0177] The control key management unit 205 of the user terminal 20 stores the control key CK obtained in the above step S1206 in the key storage unit 209 (step S1207).

[0178] Attribute key revocation process The attribute key revocation process according to the fourth embodiment will be described with reference to Fig. 22. Fig. 22 is a flowchart showing an example of the attribute key revocation process according to the fourth embodiment. In the following, an attribute key generation station 30 existing in a certain domain revoks a certain user terminal 20 existing in the same domain. i Attribute key SK i The case where the user terminal 20 is revoked will be described. i Steps S1302 and S1303 are processes executed by the attribute key generation station 30, and steps S1304 and S1305 are processes executed by the control key generation station 10.

[0179] User terminal 20 i The communication unit 201 transmits a key revocation request to the attribute key generation station 30 (step S1301). The key revocation request includes, for example, the key ID of the attribute key to be revoked (or information that can identify the key ID). Hereinafter, it is assumed that the key revocation request includes the key ID of the attribute key to be revoked.

[0180] The communication unit 301 of the attribute key generation station 30 communicates with the user terminal 20 i 17, the communication unit 301 receives the key revocation request transmitted from the user terminal 20 (step S1302). i The user may be authenticated by any authentication method, and the key revocation request may be received only if the authentication is successful.

[0181] The communication unit 301 of the attribute key generation station 30 obtains the key ID from the key revocation request received in step S1302 above, and then transmits a key revocation notice including the key ID to the control key generation station 10 (step S1303). At this time, the communication unit 301 may also obtain the expiration date from the issued key information including the key ID, and then transmit a key revocation notice including the key ID and the expiration date to the control key generation station 10.

[0182] The communication unit 101 of the control key generation station 10 receives the key expiration notification sent from the attribute key generation station 30 (step S1304).

[0183] The revoked key management unit 110 of the control key generation station 10 adds the key ID included in the key revocation notice received in step S1304 to the revoked key ID list (step S1305). This means that the key ID of the revoked attribute key is registered in the revoked key ID list. If the key revocation notice includes an expiration date, the revoked key management unit 110 may add the key ID and the expiration date to the revoked key ID list.

[0184] Of the issued key information stored in the issued key information storage unit 306, issued key information whose expiration date has passed is deleted periodically or non-periodically by the issued key management unit 304. That is, for example, the issued key management unit 304 periodically or non-periodically checks the expiration date of the issued key information stored in the issued key information storage unit 306, and deletes issued key information whose expiration date has passed.

[0185] <Summary of the Fourth Embodiment> As described above, in the cryptographic system 1 according to the fourth embodiment, the control key CK is encrypted using CP-ABE, and the control key CK can be decrypted only when the attribute key has not expired. This makes it impossible to obtain the control key CK if the attribute key has expired due to leakage, for example, and therefore makes it possible to improve security against leakage of the attribute key.

[0186] [Fifth embodiment] A fifth embodiment will be described below. In the fifth embodiment, it is assumed that the content ID is unguessable, and a case will be described in which the sender can identify the content ID from the transmitted meta information. As a result, since the content ID is unguessable, it is possible to prevent unauthorized attacks such as a third party guessing the content ID and then sending a content invalidation request including that content ID.

[0187] In the fifth embodiment, differences from the fourth embodiment will be mainly described, and a description of components that may be the same as those in the fourth embodiment will be omitted. That is, elements that are not particularly described in the fifth embodiment may be the same as those in the fourth embodiment.

[0188] <Example of functional configuration of each entity included in the cryptographic system 1 according to the fifth embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the fifth embodiment will be described below.

[0189] <<Example of functional configuration of user terminal 20>> An example of the functional configuration of the user terminal 20 according to the fifth embodiment will be described with reference to Fig. 23. Fig. 23 is a diagram showing an example of the functional configuration of the user terminal 20 according to the fifth embodiment.

[0190] 23, the user terminal 20 according to the fifth embodiment has a content identification information management unit 215 in addition to the units described in the third embodiment. The content identification information management unit 215 is realized, for example, by a process in which one or more programs installed in the user terminal 20 are executed by a processor such as a CPU. Furthermore, the user terminal 20 according to the fifth embodiment has a content identification information storage unit 216 in addition to the units described in the third embodiment. The content identification information storage unit 216 is realized, for example, by a storage area of ​​a storage device such as an HDD, SSD, or flash memory.

[0191] The content identification information management unit 215 manages the content identification information stored in the content identification information storage unit 216. That is, the content identification information management unit 215 creates content identification information and stores it in the content identification information storage unit 216, or deletes content identification information from the content identification information storage unit 216. Here, the content identification information is information for identifying an unguessable content ID, and is, for example, information that associates a content ID with meta information when content with that content ID is transmitted (hereinafter also referred to as "transmission meta information"). Examples of the transmission meta information include information such as the transmission date and time of the content, the transmission destination, the sender, the transmitting terminal ID, the path name, the size, the project name, and the format.

[0192] The content identification information storage unit 216 stores the content identification information. The content identification information is expressed in a format such as (content ID, transmission meta information), for example.

[0193] When the user terminal 20 is a sender, the user terminal 20 does not have to have the units necessary for decryption and attribute key management (control key management unit 205, KP attribute decryption unit 206, common key decryption unit 207, attribute key management unit 213, and CP attribute decryption unit 214). Similarly, when the user terminal 20 is a receiver, the user terminal 20 does not have to have the units necessary for encryption and content revocation (common key generation unit 202, common key encryption unit 203, KP attribute encryption unit 204, revoked content ID designation unit 208, CP attribute encryption unit 212, and content identification information management unit 215).

[0194] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Fifth Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the fifth embodiment.

[0195] <Encryption process> The encryption process according to the fifth embodiment will be described with reference to FIG. 24. FIG. 24 is a flowchart showing an example of the encryption process according to the fifth embodiment. In the following, the recipient is the user terminal 20. i , the sender is a user terminal 20 j (j≠i), and the user terminal 20 j The case where the encryption process is executed will be described.

[0196] Steps S1401 to S1405 in FIG. 24 may be similar to steps S1001 to S1005 in FIG. 18, respectively, and therefore a description thereof will be omitted.

[0197] User terminal 20 j The content identification information management unit 215 creates content identification information that includes the content ID of the content to be encrypted and the transmission meta information of that content (step S1406).

[0198] User terminal 20 jThe content identification information management unit 215 stores the content identification information created in step S1406 in the content identification information storage unit 216 (step S1407).

[0199] <Content invalidation process> The content revocation process according to the fifth embodiment will be described with reference to Fig. 25. Fig. 25 is a flowchart showing an example of the content revocation process according to the fifth embodiment. Note that steps S1501 and S1502 in Fig. 25 are processes executed by the user terminal 20, and steps S1503 and S1504 are processes executed by the control key generation station 10.

[0200] The invalidation content ID designation unit 208 of the user terminal 20 accepts designation of a content ID to be invalidated from among the content IDs included in the content identification information (step S1501). Here, the user of the user terminal 20 may identify the content ID to be invalidated by, for example, referring to the transmission meta information included in each piece of content identification information, and designate that content ID.

[0201] Steps S1502 to S1504 in FIG. 25 may be similar to steps S502 to S504 in FIG. 8, respectively, and therefore a description thereof will be omitted.

[0202] <Summary of the Fifth Embodiment> As described above, the encryption system 1 according to the fifth embodiment creates and stores content identification information that includes an unguessable content ID and transmission meta information. This allows the sender to identify the content ID when invalidating content, even if the content ID is unguessable. Furthermore, because the content ID is unguessable, it is possible to prevent fraudulent attacks such as a third party guessing the content ID and then sending a content invalidation request that includes that content ID.

[0203] [Sixth embodiment] A sixth embodiment will be described below. In the sixth embodiment, a case where authentication is required when invalidating content will be described. As a result, even if a content ID can be guessed, authentication is required when invalidating content with that content ID, making it possible to prevent unauthorized invalidation of content by a third party.

[0204] In the sixth embodiment, differences from the fourth embodiment will be mainly described, and a description of components that may be the same as those in the fourth embodiment will be omitted. That is, elements that are not particularly described in the sixth embodiment may be the same as those in the fourth embodiment.

[0205] <Example of functional configuration of each entity included in the cryptographic system 1 according to the sixth embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the sixth embodiment will be described below.

[0206] <Example of functional configuration of control key generation station 10> An example of the functional configuration of the control key generation station 10 according to the sixth embodiment will be described with reference to Fig. 26. Fig. 26 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the sixth embodiment.

[0207] 26, the control key generation station 10 according to the sixth embodiment has, in addition to the units described in the fourth embodiment, an authentication unit 112. The authentication unit 112 is realized, for example, by a process in which one or more programs installed in the control key generation station 10 are executed by a processor such as a CPU.

[0208] When the authentication unit 112 receives an authentication request via the communication unit 101, it authenticates the user terminal 20 that has made the authentication request.

[0209] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Sixth Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the sixth embodiment.

[0210] <Content invalidation process> The content revocation process according to the sixth embodiment will be described with reference to Fig. 27. Fig. 27 is a flowchart showing an example of the content revocation process according to the sixth embodiment. Note that step S1601 and steps S1605 to S1607 in Fig. 27 are processes executed by the user terminal 20, and steps S1602 to S1604 and steps S1608 to S1609 are processes executed by the control key generation station 10.

[0211] The communication unit 201 of the user terminal 20 transmits an authentication request to the control key generation station 10 (step S1601).

[0212] The communication unit 101 of the control key generation station 10 receives the authentication request sent from the user terminal 20 (step S1602).

[0213] The authentication unit 112 of the control key generation station 10 authenticates the user terminal 20 that has requested the authentication request received in step S1602 (step S1603). Here, the authentication unit 112 may authenticate the user terminal 20 using any authentication method. For example, the user terminal 20 may be authenticated using a user ID and password, or may be authenticated using some kind of authentication federation, or may be authenticated using a message that proves authority using a certificate or attribute encryption (e.g., a signature using a private key, a challenge response, etc.). When authentication federation is used, the authentication federation may be performed by, for example, an authentication server or the like installed for each domain to which the user terminal 20 belongs.

[0214] The communication unit 101 of the control key generation station 10 transmits an authentication response including the authentication result in the above step S1603 to the user terminal 20 (step S1604). Hereinafter, the explanation will be continued assuming that the authentication response includes information indicating successful authentication as the authentication result in the above step S1603.

[0215] The communication unit 201 of the user terminal 20 receives the authentication response transmitted from the control key generation station 10 (step S1605).

[0216] Steps S1606 to S1609 in FIG. 27 may be similar to steps S501 to S504 in FIG. 8, respectively, and therefore a description thereof will be omitted.

[0217] <Summary of the Sixth Embodiment> As described above, in the encryption system 1 according to the sixth embodiment, the user terminal 20 is authenticated when invalidating content. This prevents anyone who fails authentication from invalidating content, making it possible to prevent unauthorized invalidation of content with a content ID even if the content ID is guessable. Furthermore, because authentication is performed when invalidating content, it is also possible to deal with DoS (Denial of Service) attacks such as sending a large number of content invalidation requests.

[0218] [Seventh embodiment] The seventh embodiment will be described below. In the seventh embodiment, a content ID is generated when transmitting content, and further, when revoking content, the control key generation station 10 confirms the validity of the content ID to be revoked. This makes it possible to prevent content from being revoked by a content revocation request for an invalid content ID, for example.

[0219] In the seventh embodiment, differences from the fifth embodiment will be mainly described, and a description of components that may be the same as those in the fifth embodiment will be omitted. That is, elements that are not particularly described in the seventh embodiment may be the same as those in the fifth embodiment.

[0220] <Example of functional configuration of each entity included in the cryptographic system 1 according to the seventh embodiment> An example of the functional configuration of each entity included in the cryptographic system 1 according to the seventh embodiment will be described below.

[0221] <Example of functional configuration of control key generation station 10> An example of the functional configuration of the control key generation station 10 according to the seventh embodiment will be described with reference to Fig. 28. Fig. 28 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the seventh embodiment.

[0222] 28, the control key generation station 10 according to the seventh embodiment has, in addition to the units described in the fourth embodiment, a content ID confirmation unit 113. The content ID confirmation unit 113 is realized, for example, by a process in which one or more programs installed in the control key generation station 10 are executed by a processor such as a CPU.

[0223] The content ID confirmation unit 113 confirms the validity of the content ID included in the content invalidation request received by the communication unit 101 .

[0224] <<Example of functional configuration of user terminal 20>> An example of the functional configuration of the user terminal 20 according to the seventh embodiment will be described with reference to Fig. 29. Fig. 29 is a diagram showing an example of the functional configuration of the user terminal 20 according to the seventh embodiment.

[0225] 29, the user terminal 20 according to the seventh embodiment has, in addition to the units described in the fifth embodiment, a content ID generation unit 217. The content ID generation unit 217 is realized by a process in which one or more programs installed in the user terminal 20 are executed by a processor such as a CPU.

[0226] When transmitting content, content ID generation unit 217 generates a content ID for that content. Note that the content ID generated by content ID generation unit 217 may be a guessable content ID or an unguessable content ID, but the following description will be given assuming that an unguessable content ID is generated.

[0227] When the user terminal 20 is a sender, the user terminal 20 does not have to have the units necessary for decryption and attribute key management (control key management unit 205, KP attribute decryption unit 206, common key decryption unit 207, attribute key management unit 213, and CP attribute decryption unit 214). Similarly, when the user terminal 20 is a receiver, the user terminal 20 does not have to have the units necessary for encryption and content revocation (common key generation unit 202, common key encryption unit 203, KP attribute encryption unit 204, revoked content ID designation unit 208, CP attribute encryption unit 212, content identification information management unit 215, and content ID generation unit 217).

[0228] <Processing Executed by Each Entity Included in the Cryptographic System 1 According to the Seventh Embodiment> The following describes the processing executed by each entity included in the cryptographic system 1 according to the seventh embodiment.

[0229] <Encryption process> The encryption process according to the seventh embodiment will be described with reference to Fig. 30. Fig. 30 is a flowchart showing an example of the encryption process according to the seventh embodiment. In the following, the recipient is the user terminal 20. i , the sender is a user terminal 20 j (j≠i), and the user terminal 20 jThe case where the encryption process is executed will be described.

[0230] Steps S1701 and S1702 in FIG. 30 may be similar to steps S1401 and S1402 in FIG. 24, respectively, and therefore a description thereof will be omitted.

[0231] User terminal 20 j The content ID generation unit 217 generates a content ID for the content encrypted in step S1702 (step S1703). The content ID generation unit 217 may generate the content ID using, for example, any one of the following content ID generation methods 1 to 3.

[0232] · Content ID generation method 1 A hash value of the ciphertext C1 is calculated using a predetermined hash function, and the hash value is generated as a content ID.

[0233] Content ID generation method 2 A content ID is generated based on a private key issued to a user or user group by the control key generation station 10 (this private key may be a private key for any existing public key cryptography including attribute-based cryptography). For example, a hash value of the ciphertext C1 is calculated using a predetermined hash function, and then "private key + hash value" is generated as the content ID. Note that the private key + hash value may be, for example, a bit value obtained by concatenating the bit value of the private key and the bit value of the hash value, or may be a value calculated using a predetermined algorithm that uses the private key and hash value as input.

[0234] Content ID generation method 3 A hash value of the ciphertext C1 is calculated using a predetermined hash function, and then the hash value and predetermined check information (e.g., a check digit, information unique to the control key generation station 10, or some unique pattern information) are used to generate "hash value + check information" as a content ID. Note that the hash value + check information may be, for example, a bit value obtained by concatenating the bit value of the hash value and the bit value of the check information, or may be a value calculated using a predetermined algorithm that inputs the hash value and the check information.

[0235] Steps S1704 to S1706 in FIG. 30 may be similar to steps S1403 to S1405 in FIG. 24, respectively, and therefore a description thereof will be omitted.

[0236] User terminal 20 j The content identification information management unit 215 creates content identification information including the content ID generated in step S1703 and the transmission meta information of the content with that content ID (step S1707).

[0237] User terminal 20 j The content identification information management unit 215 stores the content identification information created in step S1707 in the content identification information storage unit 216 (step S1708).

[0238] <Content invalidation process> The content revocation process according to the seventh embodiment will be described with reference to Fig. 31. Fig. 31 is a flowchart showing an example of the content revocation process according to the seventh embodiment. Note that steps S1801 to S1802 in Fig. 31 are processes executed by the user terminal 20, and steps S1803 to S1805 are processes executed by the control key generation station 10.

[0239] Steps S1801 to S1803 in FIG. 31 may be similar to steps S1501 to S1503 in FIG. 25, respectively, and therefore a description thereof will be omitted.

[0240] The content ID confirmation unit 113 of the control key generation station 10 confirms the validity of the content ID included in the content invalidation request received in step S1803 (step S1804).

[0241] For example, if the content ID is generated by the above content ID generation method 1, the content ID checking unit 113 checks whether the content ID is the same as any content ID included in the invalid content ID list.

[0242] Furthermore, for example, if the content ID is generated by the above-described content ID generation method 2, the content ID verification unit 113 verifies the validity of the private key included in the content ID. That is, the content ID verification unit 113 verifies whether the private key is one issued by the control key generation station 10.

[0243] Furthermore, for example, if the content ID is generated by the above content ID generation method 3, content ID confirmation unit 113 confirms whether the check information included in the content ID is correct.

[0244] In the following, the description will be continued assuming that the validity of the content ID has been confirmed. If the validity of the content ID has not been confirmed, content ID confirmation unit 113 ends the content invalidation process.

[0245] The revoked content management unit 104 of the control key generation station 10 adds the content ID included in the content revocation request received in step S1803 to the revoked content ID list (step S1805).

[0246] <Summary of the Seventh Embodiment> As described above, the cryptographic system 1 according to the seventh embodiment checks the validity of the content ID to be invalidated when invalidating content. This prevents content from being invalidated by a content invalidation request for an invalid content ID, for example, if the content ID was generated by the above-described content ID generation method 2 or 3. On the other hand, if the content ID was generated by the above-described content ID generation method 1, it prevents content from being invalidated twice.

[0247] [Example of hardware configuration for each entity] Each entity (control key generation station 10, user terminal 20, attribute key generation station 30) included in the cryptographic system 1 according to each of the above embodiments can be realized, for example, by the hardware configuration of a computer 500 shown in Fig. 32. Fig. 32 is a diagram showing an example of the hardware configuration of the computer 500.

[0248] 32 includes an input device 501, a display device 502, an external I / F 503, a communication I / F 504, a RAM (Random Access Memory) 505, a ROM (Read Only Memory) 506, an auxiliary storage device 507, and a processor 508. Each of these pieces of hardware is connected to each other via a bus 509 so as to be able to communicate with each other.

[0249] The input device 501 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 502 is, for example, a display, a display panel, etc. Note that the computer 500 does not necessarily have to have at least one of the input device 501 and the display device 502, for example.

[0250] The external I / F 503 is an interface with an external device such as a recording medium 503a. Examples of the recording medium 503a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0251] The communication I / F 504 is an interface for connecting the computer 500 to a communication network. The RAM 505 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 506 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 507 is a non-volatile storage device such as an HDD, SSD, or flash memory. The processor 508 is, for example, a CPU or other type of computing device.

[0252] 32 is an example, and the hardware configuration of the computer 500 is not limited to this. For example, the computer 500 may have multiple auxiliary storage devices 507 or multiple processors 508, may not have some of the hardware shown in the figure, or may have various types of hardware other than the hardware shown in the figure.

[0253] [Variations] Modifications of the above embodiments will now be described.

[0254] Variation 1 For example, in the third embodiment and the like, the control key generation station 10 exists in common for each domain, but a control key generation station 10 may exist for each domain. In this case, each control key generation station 10 delivers a control key CK to each user terminal 20 in the same domain as itself. Furthermore, the user terminal 20 that is the sender delivers the public key PK of the control key generation station 10 in the same domain as the domain to which the user terminal 20 that is the receiver belongs. KPExecute the KP-ABE encryption algorithm EncKP using

[0255] For example, the control key generation station 10 may be realized by a multi-tenant server, and a control key generation station 10 may exist for each tenant. In this case, it can be considered as if a control key generation station 10 exists for each domain.

[0256] Variation 2 In each of the above embodiments, the control key generation station 10 delivers the control key CK to each user terminal 20 at predetermined time intervals, but for example, the control key generation station 10 may return the control key CK to the requesting user terminal 20 in response to a control key acquisition request from each user terminal 20. In addition, at this time, the control key generation station 10 may authenticate the user terminal 20 that has made the control key acquisition request, and return the control key CK only if the authentication is successful.

[0257] Variation 3 For example, in the third embodiment and the like, when encrypting the common key K, it is encrypted using CP-ABE and then encrypted using KP-ABE, but this encryption order may be reversed. That is, when encrypting the common key K, it may be encrypted using KP-ABE and then encrypted using CP-ABE. In this case, however, the ciphertext encrypted using CP-ABE can be decrypted using the recipient's attribute key (including when the attribute key has been leaked), so the security level is reduced. For this reason, when encrypting the common key K, it is preferable to encrypt it using CP-ABE and then encrypted using KP-ABE.

[0258] Variation 4 For example, in the third embodiment and the like, when encrypting the common key K, encryption is performed using CP-ABE and then KP-ABE. However, encryption using CP-ABE and encryption using KP-ABE may be performed in parallel using secret sharing. For example, a random number R may be generated in addition to the common key K, and the result X of calculating the exclusive OR of the common key K and the random number R may be encrypted using either CP-ABE or KP-ABE, while the common key K may be encrypted using the other. This can be expected to reduce encryption time through parallel calculation, for example. Note that in this modification, the exclusive OR of the common key K and the random number R is calculated, but this is just an example, and X may be calculated using some other operation from the common key K and the random number R.

[0259] Variation 5 In each of the above embodiments, the case where the user terminal 20 serving as the receiver or sender has the encryption function and the decryption function has been described. However, for example, the encryption function and the decryption function may be realized by an API (Application Programming Interface) or the like, or may be realized as a function provided by an external server. That is, for example, in the above third embodiment, each user terminal 20 i is its own attribute key SK i The encryption and decryption processes of cryptographic methods such as CP-ABE, KP-ABE, public key cryptography, and symmetric key cryptography may be implemented by an API or as a function provided by an external server.

[0260] Variation 6 In the above third embodiment and the like, a ciphertext C1 obtained by encrypting a message M with a common key K and a ciphertext C3 obtained by doubly encrypting the common key K are transmitted from the sender to the receiver, but there is no need to use a common key cipher if, for example, the message M, which is the data to be transmitted, is small enough that it does not need to be encrypted with a common key cipher. In this case, the sender can transmit a ciphertext C3 obtained by doubly encrypting the message M instead of the common key K from the sender to the receiver.

[0261] Variation 7 In each of the above embodiments, the user terminal 20 serving as the recipient holds only the latest control key CK, but for example, in addition to the latest control key CK, it may also hold past control keys CK. For example, it may hold control keys CK for a predetermined period in the past, or control keys CK for a predetermined number of generations in the past.

[0262] [supplement] In each of the above embodiments, for the sake of convenience, the user terminal 20 itself is considered to be the user, and the user attributes and authentication are described; however, these attributes and authentication may also be the attributes and authentication of the user who uses the user terminal 20 (i.e., the user of the user terminal 20).

[0263] The present invention is not limited to the above-described embodiments specifically disclosed, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims. [Explanation of symbols]

[0264] 1. Cryptographic Systems 10 Control Key Generation Station 20 User terminal 30 Attribute Key Generation Authority 101 Communications Department 102 KP attribute encryption setup part 103 Control Key Generation Unit 104 Invalid Content Management Department 105 Key storage unit 106 Invalid content ID list storage unit 107 Effective Content Management Department 108 Valid content ID list storage unit 109 CP attribute encryption section 110 Revocation Key Management Unit 111 Revocation key ID list storage unit 112 Authentication Department 113 Content ID Verification Unit 201 Communications Department 202 Common key generation unit 203 Common key encryption section 204 KP attribute encryption section 205 Control Key Management Unit 206 KP attribute decoding unit 207 Common key decryption unit 208 Invalidation content ID specification section 209 Key storage unit 210 Content storage unit 211 Activation content ID specification section 212 CP attribute encryption section 213 Attribute key management section 214 CP attribute decoding unit 215 Content Specific Information Management Department 216 Content specific information storage unit 217 Content ID Generation Unit 301 Communications Department 302 CP attribute encryption setup part 303 CP attribute key generation unit 304 Issued Key Management Unit 305 Key storage unit 306 Issued key information storage unit 501 Input Device 502 Display device 503 External I / F 503a Recording media 504 Communication I / F 505 RAM 506 ROM 507 Auxiliary storage 508 processor 509 Bus

Claims

1. 1. A cryptographic system including a first terminal at the sending end and a second terminal at the receiving end, The first terminal a first encryption unit that generates a first ciphertext by encrypting the content using a common key cipher; a second encryption unit that generates a second ciphertext by encrypting a common key of the common key encryption by key policy attribute-based encryption using identification information that identifies the content as attribute information; a transmitter that transmits the first ciphertext and the second ciphertext to the second terminal; The second terminal a first decryption unit that decrypts the second ciphertext using a policy-attached private key in which a decryption condition indicating that the content has not been revoked is embedded; and a second decryption unit that decrypts the first ciphertext using a common key obtained by decrypting the second ciphertext, Cryptographic system.

2. the cryptographic system further includes a key generation authority; The key generation station a key generation unit that generates the policy-attached private key in which the decryption condition is embedded by the key policy attribute-based encryption; a key delivery unit that delivers the policy-attached private key to the second terminal; The decoding conditions include: The cryptographic system of claim 1 , further comprising a condition that indicates that the identification information identifying the content is not included in a list of identification information identifying revoked content.

3. The first terminal a third encryption unit configured to generate a third ciphertext by further encrypting the second ciphertext using ciphertext policy attribute-based encryption, The transmission unit transmitting the first ciphertext and the third ciphertext to the second terminal; The second terminal The cryptographic system according to claim 1 , further comprising a third decryption unit that decrypts the third ciphertext using an attribute-attached private key of the ciphertext policy attribute-based encryption.

4. 1. A method for use in an encryption system including a first transmitting terminal and a second receiving terminal, the method comprising: The first terminal a first encryption step of generating a first ciphertext by encrypting the content using a common key cipher; a second encryption step of generating a second ciphertext by encrypting a symmetric key of the symmetric key encryption by key policy attribute-based encryption using identification information that identifies the content as attribute information; a transmission step of transmitting the first ciphertext and the second ciphertext to the second terminal; The second terminal a first decryption step of decrypting the second ciphertext using a policy-attached private key having embedded therein a decryption condition indicating that the content has not been revoked; a second decryption step of decrypting the first ciphertext using the common key obtained by decrypting the second ciphertext; method.

5. A program that causes a computer to function as the first terminal or the second terminal included in the encryption system according to claim 1.

Images