Encryption system, terminal, method, and program
Patent Information
- Application Number
- JP2023141289
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-08-31
- Publication Date
- 2025-03-13
AI Technical Summary
【0007】 暗号文ポリシー属性ベース暗号の秘密鍵の漏洩に関して高い安全性を持つ暗号技術が提供される。
Smart Images

Figure 2025034723000001_ABST
Abstract
Description
[Technical field]
[0001] The present disclosure relates to an encryption system, a terminal, a method, and a program. [Background technology]
[0002] Ciphertext-Policy Attribute-Based Encryption (CP-ABE) is known as an encryption method that allows complex decryption control (for example, Non-Patent Document 1, etc.). In ciphertext-policy attribute-based encryption, it is possible to control decryption by embedding a decryption condition (policy) in the ciphertext and a user attribute in the private key. [Prior art documents] [Non-patent literature]
[0003] [Non-Patent Document 1] Tsuyoshi Ohtake, Kazuto Ogawa, "Attribute-Based Encryption with Low Processing Load", NHK STRL R&D, September 2018, Report 2, No.171. Summary of the Invention [Problem to be solved by the invention]
[0004] However, conventional ciphertext policy attribute-based encryption may not be sufficiently secure against the leakage of a private key. For example, if a private key is leaked, it is not possible to prevent data encrypted before the leak from being decrypted with that private key.
[0005] The present disclosure has been made in consideration of the above points, and provides an encryption technique that has high security against leakage of a private key of ciphertext policy attribute-based encryption. [Means for solving the problem]
[0006] An encryption system according to one aspect of the present disclosure is an encryption system including a first terminal on the transmitting side and a second terminal on the receiving side, the first terminal having a first encryption unit configured to generate a first policy-attached ciphertext by encrypting transmission data using ciphertext policy attribute-based encryption, a second encryption unit configured to generate an attribute-attached ciphertext by encrypting the first policy-attached ciphertext using key policy attribute-based encryption, and a first transmission unit configured to transmit the attribute-attached ciphertext to the second terminal, the second terminal using a user private key of the ciphertext policy attribute-based encryption to detect whether the user private key has expired. the second policy-attached ciphertext having an embedded policy indicating that the user private key is not a valid ciphertext or that the user private key is valid, the second policy-attached ciphertext being obtained by encrypting a control key for decrypting the attribute-attached ciphertext by the ciphertext policy attribute-based encryption; a second decryption unit which decrypts the attribute-attached ciphertext by using the control key obtained by decrypting the second policy-attached ciphertext; and a third decryption unit which decrypts the first policy-attached ciphertext obtained by decrypting the attribute-attached ciphertext by using the user private key to obtain the transmission data. Effect of the Invention
[0007] An encryption technique that has high security against leakage of the private key of the ciphertext policy attribute-based encryption is provided. [Brief description of the drawings]
[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of an overall configuration of a cryptographic system according to a first embodiment. [Diagram 2] 2 is a diagram illustrating an example of a functional configuration of a control key generation station according to the first embodiment. FIG. [Diagram 3] FIG. 2 is a diagram illustrating an example of a functional configuration of an attribute key generation station according to the first embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of a functional configuration of a user terminal according to the first embodiment. [Diagram 5]10 is a flowchart showing an example of a setup process of a control key generation station according to the first embodiment. [Figure 6] 10 is a flowchart illustrating an example of a setup process of an attribute key generation station according to the first embodiment. [Figure 7] 13 is a flowchart illustrating an example of an attribute key generation process according to the first embodiment. [Figure 8] 11 is a flowchart illustrating an example of a control key generation process according to the first embodiment. [Figure 9] 10 is a flowchart illustrating an example of an encryption process according to the first embodiment. [Figure 10] 11 is a flowchart illustrating an example of a decoding process according to the first embodiment. [Figure 11] 11 is a flowchart illustrating an example of a revocation process according to the first embodiment. [Figure 12] FIG. 11 is a diagram illustrating an example of a functional configuration of a control key generation station according to the second embodiment. [Figure 13] 13 is a flowchart illustrating an example of an attribute key generation process according to the second embodiment. [Figure 14] 13 is a flowchart illustrating an example of a control key generation process according to the second embodiment. [Figure 15] 13 is a flowchart illustrating an example of a revocation process according to the second embodiment. [Figure 16] FIG. 13 is a diagram illustrating an example of a functional configuration of a control key generation station according to the third embodiment. [Figure 17] FIG. 13 is a diagram illustrating an example of a functional configuration of a user terminal according to the third embodiment. [Figure 18] 13 is a flowchart illustrating an example of a setup process of a control key generation station according to the third embodiment. [Figure 19] 13 is a flowchart illustrating an example of encryption processing according to the third embodiment. [Figure 20] 13 is a flowchart illustrating an example of a decoding process according to the third embodiment. [Figure 21]FIG. 2 illustrates an example of a hardware configuration of a computer. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0009] Hereinafter, first to third embodiments of the present invention will be described.
[0010] [Preparation] First, the encryption method used in the first to third embodiments is prepared.
[0011] <Ciphertext Policy Attribute-Based Encryption> Ciphertext policy attribute-based encryption (CP-ABE) 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 when the attributes embedded in the private key satisfy the policies embedded in the ciphertext. For this reason, ciphertext policy attribute-based encryption is an encryption method in which the party that encrypts (hereinafter also referred to as the "sender") specifies the party that decrypts (hereinafter also referred to as the "receiver").
[0012] Since the policy is expressed in the form of a conditional expression for an attribute, etc., in the following, the policy is also referred to as a "decryption condition" or simply as a "condition" when it is clear that the policy is a decryption condition.
[0013] Ciphertext policy attribute-based encryption consists of the following four algorithms (SetupCP, KeyGenCP, EncCP, DecCP).
[0014] SetupCP: The setup algorithm SetupCP takes security parameters as input and CP and the public key PK CP and output.
[0015] KeyGenCP: The key generation algorithm KeyGenCP uses the secret key MSK CPand information about the attributes of user i (hereinafter also referred to as "attribute information") are input, and an attribute key SK is generated as a private key (private key with attributes) of user i. i The attribute key SK i may be referred to as the "user private key" or simply as the "private key."
[0016] EncCP: The encryption algorithm EncCP uses the public key PK CP It takes the message T to be encrypted and the decryption condition as input and outputs a ciphertext (ciphertext with a policy).
[0017] 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 T is output as the decryption result; otherwise, information indicating a decryption failure is output.
[0018] <Key Policy Attribute-Based Encryption> Key-Policy Attribute-Based Encryption (KP-ABE) is the counterpart of ciphertext policy attribute-based encryption, and is an encryption method in which the decryption condition (policy) is embedded in the private key and the attributes are embedded in the ciphertext. With key policy attribute-based encryption, decryption is possible only when the attributes embedded in the ciphertext satisfy the policy embedded in the private key. For this reason, key policy attribute-based encryption can be said to be an encryption method in which the party encrypting (the sender) does not specify the party decrypting (the receiver).
[0019] Key policy attribute-based encryption consists of the following four algorithms (SetupKP, KeyGenKP, EncKP, DecKP).
[0020] SetupKP: The setup algorithm SetupKP takes security parameters as input and KP and the public key PK KP and output.
[0021] KeyGenKP: The key generation algorithm KeyGenKP uses the secret key MSK KP It takes the decryption condition and the secret key (secret key with policy) as input.
[0022] EncKP: The encryption algorithm EncKP is KP It takes the message T to be encrypted and attribute information of message T as input and outputs a ciphertext (ciphertext with attributes).
[0023] DecKP: The decryption algorithm DecKP takes as input a policy-attached private key and an attribute-attached ciphertext, and outputs a message T 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; if not, it outputs information indicating a decryption failure.
[0024] <Public key cryptography> Public key cryptography is an encryption method that uses different keys for encryption and decryption, and allows the key used for encryption to be made public. In the following, public key cryptography is assumed to be any public key cryptography other than attribute-based cryptography. Public key cryptography is composed of the following three algorithms (SetupPK, EncPK, DecPK). Examples of public key cryptography include RSA.
[0025] SetupPK: The setup algorithm SetupPK takes security parameters as input and generates a secret key SK PK and the public key PK PK and output.
[0026] EncPK: The encryption algorithm EncPK is a public key PK PK It takes as input the message T to be encrypted and outputs the ciphertext.
[0027] DecPK: The decryption algorithm DecPK uses the private key SK PKIt takes the message T and the ciphertext as input, and outputs the message T or information indicating a decryption failure as the decryption result.
[0028] <Common key encryption> A common key cipher is an encryption method that uses the same key for encryption and decryption. In the following, AES (Advanced Encryption Standard) is assumed as the common key cipher. In this case, the encryption algorithm of AES is EncAES, and the decryption algorithm is DecAES. The encryption algorithm EncAES takes a common key K and a message T to be encrypted as input, and outputs a ciphertext. The decryption algorithm DecAES takes a common key K and a ciphertext as input, and outputs the message T or information indicating a decryption failure as a decryption result. Note that assuming AES as the common key cipher is just one example, and each of the following embodiments can be similarly applied to a case where a common key cipher other than AES is used.
[0029] [First embodiment] The first embodiment will be described below. In the first embodiment, a key called a control key is introduced using KP-ABE, and a public key PK corresponding to an attribute key is generated. CP and the public key PK corresponding to the control key KP This section describes an encryption system 1 that can doubly encrypt an AES common key K by the above and obtain a control key only when the attribute key has not expired. As a result, in the encryption system 1 according to the first embodiment, if the attribute key has expired due to leakage or the like, the control key cannot be obtained, and therefore the common key K cannot be obtained, making it impossible to decrypt even data that was encrypted before the attribute key was leaked.
[0030] <Example of Overall Configuration of Cryptosystem 1 According to First Embodiment> An example of the overall configuration of a cryptographic system 1 according to a 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.
[0031] 1, the cryptographic system 1 according to the first embodiment includes, as entities, one or more control key generation authorities 10, one or more attribute key generation authorities 20, and a plurality of user terminals 30. The entities are communicatively connected to each other via a communication network including, for example, the Internet.
[0032] Hereinafter, the scope for which the attribute key generation authority 20 generates an attribute key will be referred to as a "domain", an attribute key generation authority 20 exists for each domain, and one or more user terminals 30 exist within each domain. For example, the example shown in Fig. 1 shows a case where there are two domains, domain D1 and domain D2. Note that examples of domains include companies, organizations, prefectures, cities, wards, towns, and villages, and some kind of service (subscription telephone service, SNS (Social Networking Service), online game service, etc.).
[0033] 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.
[0034] The attribute key generation authority 20 uses CP-ABE to generate attribute keys and their corresponding public keys PK CP The attribute key generation station 20 is realized by, for example, a general-purpose server or a server group made up of such general-purpose servers.
[0035] The user terminal 30 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 / herself. That is, the user terminal 30 used by the sender or the user terminal 30 considered to be the sender creates a ciphertext by encrypting the message M to be encrypted using AES, and also generates a public key PK CP and P.K. KPThe common key K is doubly encrypted using the control key and attribute key. Meanwhile, the user terminal 30 used by the recipient or the user terminal 30 considered to be the recipient decrypts the common key K using the control key and its own attribute key, and then decrypts the ciphertext using the common key K. The user terminal 30 is realized by, for example, a PC (personal computer), a smartphone, a tablet terminal, a wearable device, a game device, an in-vehicle device, various IoTs (Internet of Things), etc.
[0036] In the following, as an example, the total number of user terminals 30 is set to n, and each user terminal 30 is referred to as a “user terminal 30 i " (i=1, . . . , n). In addition, the user terminal 30 i Attribute key of SK i Furthermore, in the following description, the user terminal 30 itself will be regarded as a user, and the user terminal 30 that performs encryption will also be referred to as a sender, and the user terminal 30 that performs decryption will also be referred to as a receiver.
[0037] Note that the overall configuration of the cryptosystem 1 shown in Fig. 1 is an example and is not limited to this. For example, in the example shown in Fig. 1, 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 be present.
[0038] <Functional configuration example 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.
[0039] <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.
[0040] 2, the control key generation station 10 according to the first embodiment includes a communication unit 101, a KP attribute encryption setup unit 102, a control key generation unit 103, a CP attribute encryption unit 104, and a revocation key management unit 105. Each of these units is realized, for example, by a process executed by a processor such as a CPU (Central Processing Unit) of one or more programs installed in the control key generation station 10. Furthermore, the control key generation station 10 according to the first embodiment includes a key storage unit 106 and a revocation key information storage unit 107. Each of these storage units is realized, for example, by a storage area of a storage device such as a HDD (Hard Disk Drive), an SSD (Solid State Drive), or a flash memory.
[0041] The communication unit 101 receives data from other entities and transmits data to other entities.
[0042] The KP attribute encryption setup unit 102 executes the setup algorithm SetupKP of KP-ABE to obtain the secret key MSK KP and the public key PK KP and generate.
[0043] The control key generation unit 103 executes the key generation algorithm KeyGenKP of KP-ABE to generate a private key with a policy as a control key.
[0044] The CP attribute encryption unit 104 executes the encryption algorithm EncCP of CP-ABE to generate a ciphertext (policy-attached ciphertext) by encrypting the control key.
[0045] The revoked key management unit 105 manages the revoked key information stored in the revoked key information storage unit 107. That is, the revoked key management unit 105, for example, registers new revoked key information in the revoked key information storage unit 107 and deletes revoked key information stored in the revoked key information storage unit 107.
[0046] The key storage unit 106 stores the secret key MSK generated by the KP attribute encryption setup unit 102. KP and the public key PK KP and the public key PK used by the CP attribute encryption unit 104 CP and remember.
[0047] The revoked key information storage unit 107 stores revoked key information. Here, the revoked key information is information related to an expired attribute key. The revoked key information includes, for example, the key ID of the expired attribute key and the expiration date of the attribute key. That is, the revoked key information is expressed in a format such as (key ID, expiration date).
[0048] <Functional configuration example of the attribute key generation station 20> An example of the functional configuration of the attribute key generation station 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 attribute key generation station 20 according to the first embodiment.
[0049] 3, the attribute key generation authority 20 according to the first embodiment includes a communication unit 201, a CP attribute encryption setup unit 202, an authentication unit 203, a CP attribute key generation unit 204, and an issued key management unit 205. Each of these units is realized, for example, by a process in which one or more programs installed in the attribute key generation authority 20 are executed by a processor such as a CPU. The attribute key generation authority 20 according to the first embodiment also includes a key storage unit 206 and an issued key information storage unit 207. 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.
[0050] The communication unit 201 receives data from other entities and transmits data to other entities.
[0051] The CP attribute encryption setup unit 202 executes the setup algorithm SetupCP of CP-ABE and obtains the secret key MSK CP and the public key PK CP and generate.
[0052] When the communication unit 201 receives a key issuance request for an attribute key, the authentication unit 203 authenticates the user terminal 30 that has made the key issuance request. When the communication unit 201 receives a key revocation request for an attribute key, the authentication unit 203 authenticates the user terminal 30 that has made the key revocation request.
[0053] When the authentication unit 203 authenticates the user terminal 30 that has made the key issuance request, the CP attribute key generation unit 204 executes the key generation algorithm KeyGenCP of CP-ABE to generate an attribute key for that user terminal 30 .
[0054] The issued key management unit 205 manages the issued key information stored in the issued key information storage unit 207. That is, when an attribute key is generated by the CP attribute key generation unit 204, the issued key management unit 205 registers the issued key information of the attribute key in the issued key information storage unit 207. In addition, the issued key management unit 205 deletes the issued key information of attribute keys whose expiration date has passed from the issued key information storage unit 207 periodically or non-periodically.
[0055] The key storage unit 206 stores the secret key MSK generated by the CP attribute encryption setup unit 202. CP and the public key PK CP Memorize.
[0056] The issued key information storage unit 207 stores issued key information. Here, the issued key information refers to information on the attribute key generated by the CP attribute key generation unit 204 (i.e., the issued attribute key). The issued key information includes, for example, the key ID of the attribute key and the expiration date of the attribute key. That is, the issued key information is expressed in a format such as (key ID, expiration date).
[0057] <Functional configuration example of user terminal 30> An example of the functional configuration of the user terminal 30 according to the first embodiment will be described with reference to Fig. 4. Fig. 4 is a diagram showing an example of the functional configuration of the user terminal 30 according to the first embodiment.
[0058] 4, the user terminal 30 according to the first embodiment includes a communication unit 301, a common key generation unit 302, a common key encryption unit 303, a CP attribute encryption unit 304, a KP attribute encryption unit 305, a KP attribute decryption unit 306, a CP attribute decryption unit 307, and a common key decryption unit 308. Each of these units is realized, for example, by a process executed by a processor such as a CPU by one or more programs installed in the user terminal 30. The user terminal 30 according to the first embodiment also includes a key storage unit 309 and a message storage unit 310. Each of these storage units is realized, for example, by a storage area of a storage device such as an HDD, an SSD, or a flash memory.
[0059] The communication unit 301 receives data from other entities and transmits data to other entities.
[0060] When the user terminal 30 is the sender, the symmetric key generation unit 302 generates an AES symmetric key K. The symmetric key generation unit 302 may generate the symmetric key K using, for example, a random number.
[0061] When the user terminal 30 is the sender, the common key encryption unit 303 executes the AES encryption algorithm EncAES using the common key K generated by the common key generation unit 302, and generates a ciphertext C1 by encrypting the message M to be encrypted.
[0062] If the user terminal 30 is the sender, the CP attribute encryption unit 304 executes the encryption algorithm EncCP of CP-ABE to generate a policy-attached ciphertext C2 by encrypting the common key K of AES.
[0063] If the user terminal 30 is the sender, the KP attribute encryption unit 305 executes the KP-ABE encryption algorithm EncKP and generates an attribute-attached ciphertext C3 by further encrypting the policy-attached ciphertext C2 generated by the CP attribute encryption unit 304.
[0064] If the user terminal 30 is the recipient, the KP attribute decryption unit 306 executes the decryption algorithm DecKP to decrypt the attribute-attached ciphertext C3, thereby obtaining the policy-attached ciphertext C2 or information indicating a decryption failure as the decryption result.
[0065] When the user terminal 30 is the recipient, the CP attribute decryption unit 307 executes the decryption algorithm DecCP to decrypt the policy-attached ciphertext C2 obtained by the decryption of the KP attribute decryption unit 306. As a result, the AES common key K or information indicating a decryption failure is obtained as the decryption result.
[0066] When the user terminal 30 is the recipient, the common key decryption unit 308 executes the AES decryption algorithm DecAES using the common key K obtained by the decryption by the CP attribute decryption unit 307 to decrypt the ciphertext C1. As a result, a message M is obtained as the decryption result.
[0067] The key storage unit 309 stores various keys. For example, when the user terminal 30 is a sender, the key storage unit 309 of the user terminal 30 stores the common key K and the public key PK generated by the common key generation unit 302. CP , public key PK KP On the other hand, for example, when the user terminal 30 is the recipient, the key storage unit 309 of this user terminal 30 stores the control key, the common key K obtained as a result of decryption by the CP attribute decryption unit 307, and the attribute key.
[0068] The message storage unit 310 stores the message M. For example, when the user terminal 30 is a sender, the message storage unit 310 of the user terminal 30 stores the message M to be encrypted. On the other hand, when the user terminal 30 is a receiver, the message storage unit 310 of the user terminal 30 stores the message M obtained as a result of decryption by the common key decryption unit 308.
[0069] When the user terminal 30 is the sender, the user terminal 30 does not need to have each unit required for decryption (KP attribute decryption unit 306, CP attribute decryption unit 307, and common key decryption unit 308). Similarly, when the user terminal 30 is the receiver, the user terminal 30 does not need to have each unit required for encryption (common key generation unit 302, common key encryption unit 303, CP attribute encryption unit 304, and KP attribute encryption unit 305).
[0070] <Processing Executed by Each Entity Included in the Cryptosystem 1 According to the First Embodiment> The following describes the processes executed by each entity (the control key generation authority 10, the attribute key generation authority 20, the user terminal 30 acting as the sender, and the user terminal 30 acting as the receiver) included in the cryptographic system 1 according to the first embodiment.
[0071] <<Setup process of the 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. 5. Fig. 5 is a flowchart showing an example of the setup process of the control key generation station 10 according to the first embodiment.
[0072] The KP attribute encryption setup unit 102 of the control key generation station 10 executes the setup algorithm SetupKP to obtain 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 KP where λ is a security parameter.
[0073] 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 the public key PK KP is stored in the key storage unit 106, and the public key PKKP is made public to other entities by any method (step S102).
[0074] <Setup process of attribute key generation station 20> The setup process of the attribute key generation authority 20 according to the first embodiment will be described with reference to Fig. 6. Fig. 6 is a flowchart showing an example of the setup process of the attribute key generation authority 20 according to the first embodiment. The setup process executed by the attribute key generation authority 20 of a certain domain will be described below.
[0075] The CP attribute encryption setup unit 202 of the attribute key generation station 20 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 202 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.
[0076] The CP attribute encryption setup unit 202 of the attribute key generation station 20 uses the secret key MSK generated in step S201 above. CP and the public key PK CP is stored in the key storage unit 206, and the public key PK CP is made public to other entities by any method (step S202).
[0077] In addition, the secret key MSK CP and the public key PK CP Note that, differs for each domain. Therefore, more strictly speaking, for example, the private key and the public key of the attribute key generation authority 20 of the domain D1 are respectively MSK CP (1) and P.K. CP (2) The private key and the public key of the attribute key generation authority 20 of the domain D2 are represented as MSK CP(2) and P.K. CP (2) In other words, in general, domain D n The private key and public key of the attribute key generation authority 20 of (n=1, . . . , N, N is the number of domains) are MSK CP (n) and P.K. CP (n) This is expressed as:
[0078] ≪Attribute key generation process≫ The attribute key generation process according to the first embodiment will be described with reference to FIG. 7. FIG. 7 is a flowchart showing an example of the attribute key generation process according to the first embodiment. In the following, i It is assumed that a key issuance request is sent from to the attribute key generation authority 20.
[0079] The communication unit 201 of the attribute key generation station 20 communicates with the user terminal 30. i The key issuing request sent from the key issuing unit 102 is received (step S301).
[0080] The authentication unit 203 of the attribute key generation station 20 authenticates the user terminal 30 that is the request source of the key issuance request received in step S301. i The authentication method is not limited to a specific method, and the authentication unit 203 authenticates the user terminal 30 by any authentication method. i For example, the authentication unit 203 authenticates the user terminal 30 using a user ID and a password. i The user terminal 30 may be authenticated, or a secure session may be established. i Alternatively, for example, the authentication unit 203 may authenticate the user terminal 30 by using a terminal identifier. i Alternatively, the user terminal 30 may be authenticated by other authentication methods (e.g., biometric authentication, mnemonic authentication, CAPTCHA authentication). i The authentication unit 203 may authenticate the user terminal 30 by a combination of a plurality of authentication methods. i Hereinafter, the user terminal 30 iThe explanation will be continued assuming that the authentication of the user terminal 30 is successful. i If the authentication fails, the authentication unit 203 ends the attribute key generation process.
[0081] The CP attribute key generation unit 204 of the attribute key generation station 20 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 207 (step S303). The CP attribute key generation unit 204 may use any method to generate a key ID value that does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 207. For example, the CP attribute key generation unit 204 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 207. In addition to this, for example, the CP attribute key generation unit 204 may generate a key ID based on the user terminal 30 i If a previously issued attribute key exists in the issued key information storage unit 207, the key ID may be generated by adding 1 to the key ID of that attribute key (however, this value does not overlap with any key ID included in the issued key information stored in the issued key information storage unit 207).
[0082] The CP attribute key generation unit 204 of the attribute key generation station 20 executes the key generation algorithm KeyGenCP and generates a CP attribute key for the user terminal 30. i Attribute key SK i That is, the CP attribute key generating unit 204 generates SK i ←KeyGenCP(MSK CP ,A i ) to obtain the attribute key SK i where A i is a user terminal 30 i This is attribute information of A. i For example, the user terminal 30 iThe attribute includes the attribute of the key ID generated in step S303, the key ID generated in step S303, and the 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 affiliated organization, and a job title. However, these are merely examples, and the attribute may be any of various attributes that can be used in existing attribute-based encryption. The expiration date may 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).
[0083] In addition, attribute information A i In addition to the attribute, key ID, and expiration date, the attribute key SK may also include, for example, a generation. i This is the number of times that the attribute information A has been issued. i By including the generation, it is possible to make the attribute information different even for the same attribute. For example, it is possible to issue a different attribute key in which the same attribute as the expired attribute key is embedded.
[0084] The issued key management unit 205 of the attribute key generation authority 20 issues the attribute key SK i Attribute information A used to generate i The attribute key SK generated in step S304 is stored in the issued key information storage unit 207 using the key ID and expiration date included in the attribute key SK generated in step S304 (step S305). i (That is, the newly issued attribute key SK i ) issued key information has been registered.
[0085] The communication unit 201 of the attribute key generation station 20 transmits the attribute key SK generated in step S304 above. i The user terminal 30 i (Step S306). Note that the communication unit 201 transmits the attribute key SK i The user terminal 30 i This allows the user terminal 30 i The attribute key SKi is saved.
[0086] <Control key generation process> The control key generation process according to the first embodiment will be described with reference to Fig. 8. Fig. 8 is a flowchart showing an example of the control key generation process according to the first embodiment. Here, the control key generation process described below is executed at predetermined time intervals (e.g., every day or every few days). 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 30. Hereinafter, the period for generating and distributing the control key is defined as Δ.
[0087] The control key generation unit 103 of the control key generation station 10 acquires the current date and time (step S401). Note that the control key generation unit 103 may acquire the current date and time from a clock function included in the control key generation station 10, or may acquire the current date and time from an NTP server or the like.
[0088] The control key generation unit 103 of the control key generation station 10 executes the key generation algorithm KeyGenKP to generate a policy-attached private key as a control key CK (step S402). KP , P1), where P1 is a decryption condition (policy), such as "encryption date and time-α1≦generation date and time of control key CK≦end date and time of use of ciphertext". This decryption condition indicates that decryption is possible when the generation of the control key CK is included in the period from the date and time when the attribute-attached ciphertext C3 was generated (i.e., encryption date and time of the attribute-attached ciphertext C3)-α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 for example, makes it possible to prevent decryption by someone who only has an old control key CK. That is, for example, if an attribute key SK becomes unavailable due to leakage, etc., iWhen the control key CK is revoked, it is possible to prevent decryption by a person who only possesses the control key CK generated and distributed before the revocation. Note that the decryption condition P1 may be, for example, "encryption date and time-α1≦generation date and time of the control key CK" without including the end date and time of use of the ciphertext. Here, the encryption date and time may be called the "start date and time of use of the ciphertext", and the two are assumed to match. Also, α1 is a constant that takes into account the period in which the control key CK is generated and distributed, and is a value equal to or greater than 0 that satisfies α1+α2≦Δ with α2, which will be described later.
[0089] The CP attribute encryption unit 104 of the control key generation station 10 executes the encryption algorithm EncCP to encrypt the control key CK, and generates a policy-attached ciphertext C CK That is, the CP attribute encryption unit 104 generates C CK ←KeyGenCP(PK CP , CK,P2) to obtain the ciphertext C CK Here, P2 is a decryption condition (policy) and is a condition indicating that the attribute key has not expired. For example, P2 = "The key ID of the attribute key is a key ID other than the key ID included in the revoked key information stored in the revoked key information storage unit 107" or the like. As a result, a ciphertext C CK Therefore, for example, even if an attribute key is leaked, a person who illegally obtains the attribute key cannot obtain the control key CK by revoking the attribute key. Since the control key CK is a private key with a policy required for decrypting the attribute-added ciphertext C3, a person who illegally obtains the attribute key cannot decrypt the attribute-added ciphertext C3, and it can be said that security against leakage of the attribute key is ensured.
[0090] The communication unit 101 of the control key generation station 10 receives the policy-attached ciphertext C CK The control key CK is encrypted and stored in the key storage unit 309 of each user terminal 30. CKThe communication unit 101 stores the policy-attached ciphertext C CK may be transmitted.
[0091] <Encryption process> The encryption process according to the first embodiment will be described with reference to FIG. 9. FIG. 9 is a flowchart showing an example of the encryption process according to the first embodiment. In the following, the recipient is the user terminal 30. i , the sender is a user terminal 30 j (j ≠ i), the user terminal 30 j The case where the encryption process is executed will be described.
[0092] User terminal 30 j The shared key generation unit 302 generates a shared key K of AES (step S501). For example, the shared key generation unit 302 may generate a random number as the shared key K.
[0093] User terminal 30 j The common key encryption unit 303 executes the encryption algorithm EncAES using the common key K generated in step S501 above, and generates a ciphertext C1 by encrypting the message M to be encrypted (step S502). That is, the common key encryption unit 303 generates the ciphertext C1 by C1←EncAES(K,M).
[0094] User terminal 30 j The CP attribute encryption unit 304 executes the encryption algorithm EncCP to generate a policy-attached ciphertext C2 by encrypting the common key K generated in step S501 (step S503). That is, the CP attribute encryption unit 304 encrypts C2←EncCP(PK CP, M, P3) to generate a policy-attached ciphertext C2. Here, P3 is a decryption condition (policy), and may be any condition including, for example, that the expiration date of the attribute key has not arrived. For example, P3=(expiration date of the attribute key>date and time of decryption+α) and (the organization to which the recipient belongs is ABC), etc. α 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.
[0095] More generally, the above decryption condition P3 can be set to P3=(expiration date of attribute key>date and time of decryption+α) and P4, where P4 is an arbitrary condition related to the attribute.
[0096] User terminal 30 j The KP attribute encryption unit 305 executes the encryption algorithm EncKP to generate an attribute-attached ciphertext C3 by encrypting the policy-attached ciphertext C2 generated in step S503 (step S504). That is, the KP attribute encryption unit 305 encrypts C3←EncKP(PK KP , C2, att) to generate an attribute-attached ciphertext C3. Here, att is an attribute, and may be, for example, att=encryption date and time-α2, or att=encryption date and time-α2|| end date and time of use of the attribute-attached ciphertext C3 (end date and time of use of the ciphertext), etc. || represents a logical sum, and the encryption date and time is the generation date and time of the attribute-attached ciphertext C3. In addition, the end date and time of use of the attribute-attached ciphertext C3 (end date and time of use of the ciphertext) may be, for example, j It should be noted 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 C3, att=encryption date and time-α2 and att=encryption date and time-α2|| usage end date and time of the attribute-attached ciphertext C3 can be regarded as the same. Also, α2 is a constant that takes into consideration the cycle at which the control key CK is generated and distributed, and is a value equal to or greater than 0 that satisfies α1+α2≦Δ.
[0097] User terminal 30 j The communication unit 301 transmits the ciphertext C=(C1, C3) to the user terminal 30 i(step S505).
[0098] <Decryption process> The decoding process according to the first embodiment will be described with reference to FIG. 10. FIG. 10 is a flowchart showing an example of the decoding process according to the first embodiment. i A case where the decryption process is performed will be described.
[0099] User terminal 30 i The communication unit 301 of the user terminal 30 j The encrypted text C=(C1, C3) transmitted from the ciphertext server 100 is received (step S601).
[0100] User terminal 30 i The communication unit 301 of the control key generation station 10 receives the policy-attached ciphertext C CK (Step S602). i The key storage unit 309 stores the ciphertext C CK Note that the policy-encrypted ciphertext C CK If the request has already been received and stored, this step may not be performed.
[0101] User terminal 30 i The CP attribute decryption unit 307 executes the decryption algorithm DecCP to decrypt the ciphertext C CK (That is, the control key CK encrypted by CP-ABE) is decrypted (step S603). i ,C CK ) to obtain the attribute key SK i The attributes embedded in the policy-enhanced ciphertext C CK If the decryption condition P2 embedded in the attribute key SK is satisfied (i.e., iIn the case where the key ID of KP-ABE is a key ID other than the key ID included in the revoked key information stored in the revoked key information storage unit 107), a control key CK, which is a secret key with an attribute of KP-ABE, is obtained as the decryption result. i The attributes embedded in the policy-enhanced ciphertext C CK If the decryption condition P2 embedded in the attribute key SK is not satisfied (i.e., i If the key ID is not a key ID other than the key ID included in the revoked key information stored in the revoked key information storage unit 107), 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 is obtained. Note that when information indicating a decryption failure is obtained, the CP attribute decryption unit 307 ends the decryption process.
[0102] User terminal 30 i The KP attribute decryption unit 306 executes the decryption algorithm DecKP to decrypt the attribute-attached ciphertext C3 (step S604). That is, the KP attribute decryption unit 306 executes DecKP(CK, C3). As a result, if the attribute att embedded in the attribute-attached ciphertext C3 satisfies the decryption condition P1 embedded in the control key CK, the policy-attached ciphertext C2 is obtained as the decryption result. That is, for example, if att=encryption date and time-α2, P1=encryption date and time-α1≦generation date and time of the control key CK≦end date and time of use of the ciphertext, the policy-attached ciphertext C2 is obtained as the decryption result when the generation date and time of the control key CK is included in the period from the encryption date and time-α1 of the attribute-attached ciphertext C3 to the end date and time of use of the ciphertext. Or, for example, if att=encryption date and time-α2, P1=encryption date and time-α1≦generation date and time of the control key CK, the policy-attached ciphertext C2 is obtained as the decryption result when the generation date and time of the control key CK is after the encryption date and time-α1 of the attribute-attached ciphertext C3. On the other hand, if the attribute 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. In the following, the explanation will be continued assuming that the policy-attached ciphertext C2 has been obtained. Note that when information indicating a decryption failure is obtained, the KP attribute decryption unit 306 ends the decryption process.
[0103] User terminal 30 i The CP attribute decryption unit 307 executes the decryption algorithm DecCP to decrypt the ciphertext C2 with policy (step S605). i , C2) is executed. This results in the attribute key SK i If the attribute embedded in satisfies the decryption condition P3 embedded in the policy-encrypted ciphertext C2 (i.e., if the attribute key SK i The expiration date of the attribute key SK is greater than the decryption date and time + α. i If the attribute of SK satisfies condition P4), the common key K is obtained as the decryption result. i does not satisfy the decryption condition P3 embedded in the policy-encrypted ciphertext C2 (i.e., the attribute key SK i If the expiry date of attribute key SK does not exceed the decryption date and time + α, or i If the attribute of the CP attribute does not satisfy condition P4), information indicating a decryption failure is obtained as the decryption result. In the following, the explanation will be continued assuming that the common key K is obtained. Note that, if information indicating a decryption failure is obtained, the CP attribute decryption unit 307 ends the decryption process.
[0104] User terminal 30 i The common key decryption unit 308 executes the AES decryption algorithm DecAES using the common key K obtained in step S605 above to decrypt the ciphertext C1 (step S606). That is, the common key decryption unit 308 executes DecAES(K, C1). As a result, the message M is obtained as the decryption result.
[0105] <Expiration Processing> The revocation process according to the first embodiment will be described with reference to FIG. 11. FIG. 11 is a flowchart showing an example of the revocation process according to the first embodiment. In the following, i11 is a process executed by the attribute key generation station 20, and steps S704 and S705 are a process executed by the control key generation station 10.
[0106] The communication unit 201 of the attribute key generation station 20 communicates with the user terminal 30. i The key revocation request sent from the attribute key server 100 is received (step S701). Note that the key revocation request includes, for example, the key ID of the attribute key to be revoked (or information capable of identifying the key ID). Hereinafter, it is assumed that the key revocation request includes the key ID of the attribute key to be revoked.
[0107] The authentication unit 203 of the attribute key generation station 20 authenticates the user terminal 30 that is the request source of the key revocation request received in step S701. i (Step S702). Note that the authentication unit 203 authenticates the user terminal 30 by, for example, the same authentication method as in Step S302 in FIG. i You need to authenticate.
[0108] The communication unit 201 of the attribute key generation authority 20 obtains the issued key information of the key ID included in the key revocation request from the issued key information storage unit 207, and then transmits a key revocation notification including the key ID and expiration date of the issued key information to the control key generation authority 10 (step S703).
[0109] The communication unit 101 of the control key generation station 10 receives the key expiration notification sent from the attribute key generation station 20 (step S704).
[0110] The revoked key management unit 105 of the control key generation station 10 stores the revoked key information of the key ID and the expiration date included in the key revocation notification received in the above step S704 in the revoked key information storage unit 107 (step S705). This means that the revoked key information for the revoked attribute key is registered.
[0111] Among the issued key information stored in issued key information storage unit 207, issued key information whose expiration date has passed is deleted periodically or non-periodically by issued key management unit 205. That is, for example, issued key management unit 205 periodically or non-periodically checks the expiration date of issued key information stored in issued key information storage unit 207, and deletes issued key information whose expiration date has passed.
[0112] Similarly, revoked key information stored in revoked key information storage unit 107 that has expired is deleted periodically or non-periodically by revoked key management unit 105. That is, for example, revoked key management unit 105 checks the expiration date of revoked key information stored in revoked key information storage unit 107 periodically or non-periodically, and deletes revoked key information whose expiration date has expired.
[0113] <Summary of the First Embodiment> As described above, in the encryption system 1 according to the first embodiment, the secret key of KP-ABE is used as the control key CK, and the control key CK is encrypted by CP-ABE using the decryption condition indicating that "the attribute key has not expired" and distributed to each recipient. In addition, the sender side encrypts the common key K by CP-ABE, and then further encrypts it by KP-ABE. Therefore, in order for the recipient to obtain the common key K, the control key CK is required in addition to the attribute key. Therefore, if an attribute key is leaked, the attribute key can be revoked, so that a third party who has obtained the leaked attribute key cannot obtain the control key CK. This prevents the common key K from being leaked, and achieves high security against the leakage of the attribute key.
[0114] In addition to the above, the encryption system 1 according to the first embodiment distributes ciphertexts obtained by encrypting the control key CK by CP-ABE to the recipients at predetermined time intervals (e.g., every day or every few days). Therefore, unlike a method of confirming the right to decrypt by a server inquiry, such as DRM (Digital Rights Management), the recipients can decrypt even offline. Note that the control key CK is common to all recipients, so there is also the advantage that the cost (processing load, etc.) required to distribute the ciphertext of the control key CK to each recipient is not high.
[0115] In addition to the above, the cryptographic system 1 according to the first embodiment has the advantage that it is not necessary to authenticate each recipient when distributing the ciphertext of the control key CK, since the ciphertext of the control key CK can be decrypted only if the attribute key has not expired.
[0116] [Second embodiment] The second embodiment will be described below. In the first embodiment, the decryption condition when encrypting the control key CK is P2="the key ID of the attribute key is a key ID other than the key ID included in the revocation key information stored in the revocation key information storage unit 107" or the like, but some attribute-based cryptography cannot specify a condition to exclude something such as "B other than A". Therefore, in the second embodiment, a case will be described where a decryptable key ID is specified as the decryption condition when encrypting the control key CK.
[0117] In the second embodiment, differences from the first embodiment will be mainly described, and explanations of components that may be the same as those in the first embodiment will be omitted. In other words, elements that are not particularly described in the second embodiment may be the same as those in the first embodiment.
[0118] <Functional configuration example 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.
[0119] <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. 12. Fig. 12 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the second embodiment.
[0120] 12, the control key generation station 10 according to the second embodiment includes a communication unit 101, a KP attribute encryption setup unit 102, a control key generation unit 103, a CP attribute encryption unit 104, and a valid key management unit 108. Each of these units 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 includes a key storage unit 106 and a valid key information storage unit 109. 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.
[0121] The valid key management unit 108 manages the valid key information stored in the valid key information storage unit 109. That is, the valid key management unit 108, for example, registers new valid key information in the valid key information storage unit 109 and deletes valid key information stored in the valid key information storage unit 109.
[0122] The valid key information storage unit 109 stores valid key information. Here, the valid key information refers to information on a valid attribute key (i.e., an attribute key that has not expired). The valid key information includes, for example, the key ID of a valid attribute key and the expiration date of the attribute key. That is, the valid key information is expressed in a format such as (key ID, expiration date).
[0123] <Processing Executed by Each Entity Included in the Cryptosystem 1 According to the Second Embodiment> The following describes the processes executed by each entity (the control key generation authority 10, the attribute key generation authority 20, the user terminal 30 acting as the sender, and the user terminal 30 acting as the receiver) included in the cryptographic system 1 according to the second embodiment.
[0124] ≪Attribute key generation process≫ The attribute key generation process according to the second embodiment will be described with reference to FIG. 13. FIG. 13 is a flowchart showing an example of the attribute key generation process according to the second embodiment. In the following, i 13 is a process executed by the attribute key generation station 20, and steps S808 and S809 are a process executed by the control key generation station 10.
[0125] The processing in steps S801 to S806 may be similar to the processing in steps S301 to S306 in FIG. 7, and therefore the description thereof will be omitted.
[0126] The communication unit 201 of the attribute key generation authority 20 transmits a key issue notification including the key ID and expiration date of the issued key information registered in step S805 to the control key generation authority 10 (step S807).
[0127] The communication unit 101 of the control key generation authority 10 receives the key issuance notification sent from the attribute key generation authority 20 (step S808).
[0128] The valid key management unit 108 of the control key generation station 10 stores the valid key information of the key ID and the expiration date included in the key issuance notification received in the above step S808 in the valid key information storage unit 109 (step S809). This means that the valid key information regarding the valid attribute key is registered.
[0129] If there is an attribute key to be revoked in step S808, the communication unit 101 may transmit a key revocation notification including at least the key ID of the attribute key to be revoked to the control key generation station 10. As a result, in the control key generation station 10, the valid key management unit 108 deletes the valid key information of the key ID included in the key revocation notification from the valid key information storage unit 109.
[0130] Furthermore, if there is an attribute key whose expiration date is to be shortened in step S808, the communication unit 101 may transmit an expiration date shortening notification including the key ID of the attribute key to be shortened and the shortened expiration date to the control key generation station 10. As a result, in the control key generation station 10, the valid key management unit 108 updates the expiration date of the valid key information of the key ID included in the expiration date shortening notification to the shortened expiration date.
[0131] <Control key generation process> The control key generation process according to the second embodiment will be described with reference to Fig. 14. Fig. 14 is a flowchart showing an example of the control key generation process according to the second embodiment. Here, the control key generation process described below is executed at predetermined time intervals (for example, every day or every few days). 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 30.
[0132] The processing in steps S901 and S902 may be similar to the processing in steps S401 and S402 in FIG. 8, and therefore a description thereof will be omitted.
[0133] The CP attribute encryption unit 104 of the control key generation station 10 executes the encryption algorithm EncCP to encrypt the control key CK, and generates a policy-attached ciphertext C CK That is, the CP attribute encryption unit 104 generates C CK ←KeyGenCP(PK CP , CK,P2) to obtain the ciphertext C CKHere, P2 is a decryption condition (policy) and is a condition indicating that the attribute key is valid. For example, P2="the key ID of the attribute key matches any one of the key IDs included in the valid key information stored in the valid key information storage unit 109" or the like. As a result, even when using CP-ABE in which a decryption condition that excludes something such as "B other than A" cannot be specified, the policy-attached ciphertext C using the attribute key that expired in step S603 of FIG. 10 can be generated as in the first embodiment. CK In step S603 of FIG. 10, the attribute key SK i The attributes embedded in the policy-enhanced ciphertext C CK If the decryption condition P2 embedded in the attribute key SK is satisfied (i.e., i If the key ID of the attribute key SK matches any of the key IDs included in the valid key information stored in the valid key information storage unit 109), the control key CK is obtained as the decryption result. i The attributes embedded in the policy-enhanced ciphertext C CK If the decryption condition P2 embedded in the attribute key SK is not satisfied (i.e., i If the key ID does not match any of the key IDs included in the valid key information stored in the valid key information storage unit 109), information indicating a decryption failure is obtained as the decryption result.
[0134] The communication unit 101 of the control key generation station 10 transmits the policy-attached ciphertext C generated in the above step S903 in the same manner as in step S404 of FIG. CK to each user terminal 30 (step S904).
[0135] <Expiration Processing> The revocation process according to the second embodiment will be described with reference to FIG. 15. FIG. 15 is a flowchart showing an example of the revocation process according to the second embodiment. In the following, i15 is a process executed by the attribute key generation authority 20, and steps S1004 and S1005 are a process executed by the control key generation authority 10.
[0136] The processing in steps S1001 and S1002 may be similar to the processing in steps S701 and S702 in FIG. 11, and therefore the description thereof will be omitted.
[0137] The communication unit 201 of the attribute key generation station 20 transmits a key revocation notification including the key ID of the key revocation request to the control key generation station 10 (step S1003). The key revocation notification may include an expiration date. This expiration date may be the expiration date included in the issued key information of the key ID, or may be an expiration date that is a shortened version of the expiration date included in the issued key information of the key ID. At this time, the extent to which the shortened expiration date is to be shortened from the original expiration date is determined by, for example, the user terminal 30. i This may be specified in the key revocation request from the server or may be predetermined.
[0138] The communication unit 101 of the control key generation station 10 receives the key expiration notification transmitted from the attribute key generation station 20, similarly to step S704 in FIG. 11 (step S1004).
[0139] The valid key management unit 108 of the control key generation station 10 deletes the valid key information of the key ID included in the key expiry notice received in step S1004 from the valid key information storage unit 109 (step S1005). This deletes the valid key information for the expired attribute key. However, if the shortened expiration date is included in the key expiry notice, the valid key management unit 108 updates the expiration date included in the valid key information to the shortened expiration date without deleting the valid key information of the key ID included in the key expiry notice.
[0140] Furthermore, among the valid key information stored in the valid key information storage unit 109, valid key information whose expiration date has passed is deleted periodically or non-periodically by the valid key management unit 108. That is, for example, the valid key management unit 108 periodically or non-periodically checks the expiration date of the valid key information stored in the valid key information storage unit 109, and deletes valid key information whose expiration date has passed.
[0141] <Summary of the second embodiment> As described above, in the encryption system 1 according to the second embodiment, the private key of KP-ABE is used as the control key CK, and the control key CK is encrypted by CP-ABE using a decryption condition indicating that "the attribute key is valid" and distributed to each recipient. This makes it possible to use CP-ABE when encrypting the control key CK, which does not allow specification of a condition that excludes something, such as "B other than A".
[0142] [Third embodiment] The third embodiment will be described below. In the first and second embodiments, a secret key of KP-ABE is used as the control key CK, but in the third embodiment, a case will be described in which a secret key of any public key cryptography other than attribute-based cryptography is used as the control key CK.
[0143] In the third embodiment, differences from the first embodiment will be mainly described, and explanations 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.
[0144] <Functional configuration example 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.
[0145] <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 third embodiment will be described with reference to Fig. 16. Fig. 16 is a diagram showing an example of the functional configuration of the control key generation station 10 according to the third embodiment.
[0146] As shown in Fig. 16, the control key generation station 10 according to the third embodiment includes a communication unit 101, a public key encryption setup unit 110, a public key decryption unit 111, a revocation key management unit 105, and an authentication unit 112. Each of these units 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. In addition, the control key generation station 10 according to the third embodiment includes a key storage unit 106 and a revocation key information storage unit 107. Each of these storage units is realized, for example, by a storage area of a storage device such as an HDD, an SSD, or a flash memory.
[0147] The public key cryptography setup unit 110 executes a public key cryptography setup algorithm SetupPK and obtains a private key SK PK and the public key PK PK and generate.
[0148] The public key decryption unit 111 executes the decryption algorithm DecPK of the public key encryption, and decrypts the ciphertext C3 included in the decryption request received from the user terminal 30.
[0149] When a decryption request is received by the communication unit 101, the authentication unit 112 authenticates the user terminal 30 that has sent the decryption request.
[0150] When the authentication unit 112 authenticates the user terminal 30, the revoked key management unit 105 judges whether or not revoked key information related to the attribute key of the user terminal 30 is stored in the revoked key information storage unit 107. This confirms whether or not the attribute key has been revoked, and the ciphertext C3 is decrypted by the public key decryption unit 111 only if the attribute key has not been revoked.
[0151] The key storage unit 106 stores the secret key SK generated by the public key cryptography setup unit 110.PK and the public key PK PK Remember.
[0152] <Functional configuration example of user terminal 30> An example of the functional configuration of the user terminal 30 according to the third embodiment will be described with reference to Fig. 17. Fig. 17 is a diagram showing an example of the functional configuration of the user terminal 30 according to the third embodiment.
[0153] 17, the user terminal 30 according to the third embodiment includes a communication unit 301, a common key generation unit 302, a common key encryption unit 303, a CP attribute encryption unit 304, a public key encryption unit 311, a CP attribute decryption unit 307, and a common key decryption unit 308. Each of these units is realized, for example, by a process executed by a processor such as a CPU by one or more programs installed in the user terminal 30. The user terminal 30 according to the third embodiment also includes a key storage unit 309 and a message storage unit 310. Each of these storage units is realized, for example, by a storage area of a storage device such as an HDD, an SSD, or a flash memory.
[0154] If the user terminal 30 is the sender, the public key encryption unit 311 executes the encryption algorithm EncPK of the public key cryptography, and generates ciphertext C3 by further encrypting the policy-attached ciphertext C2 generated by the CP attribute encryption unit 304.
[0155] If the user terminal 30 is the recipient, the CP attribute decryption unit 307 executes the decryption algorithm DecCP and decrypts the ciphertext C2 with the policy returned from the control key generation station 10 in response to the decryption request.
[0156] The key storage unit 309 stores various keys. For example, when the user terminal 30 is a sender, the key storage unit 309 of the user terminal 30 stores the common key K and the public key PK generated by the common key generation unit 302. CP , public key PK PKOn the other hand, for example, when the user terminal 30 is the recipient, the key storage unit 309 of this user terminal 30 stores the common key K and the attribute key obtained as a result of decryption by the CP attribute decryption unit 307.
[0157] When the user terminal 30 is a sender, the user terminal 30 does not need to have each unit required for decryption (the CP attribute decryption unit 307 and the common key decryption unit 308). Similarly, when the user terminal 30 is a receiver, the user terminal 30 does not need to have each unit required for encryption (the common key generation unit 302, the common key encryption unit 303, the CP attribute encryption unit 304, and the public key encryption unit 311).
[0158] <Processing Executed by Each Entity Included in the Cryptosystem 1 According to the Third Embodiment> Hereinafter, a process executed by each entity (the control key generation authority 10, the attribute key generation authority 20, the user terminal 30 acting as the sender, and the user terminal 30 acting as the receiver) included in the cryptosystem 1 according to the third embodiment will be described. Note that in the third embodiment, the private key SK PK corresponds to the control key CK, and therefore, unlike the first and second embodiments, a control key generation process is not executed.
[0159] <<Setup process of the control key generation station 10>> The setup process of the control key generation station 10 according to the third embodiment will be described with reference to Fig. 18. Fig. 18 is a flowchart showing an example of the setup process of the control key generation station according to the third embodiment.
[0160] The public key cryptography setup unit 110 of the control key generation station 10 executes the public key cryptography setup algorithm SetupPK and obtains the private key SK PK and the public key PK PK That is, the public key cryptography setup unit 110 generates (SK PK ,PK PK )←SetupPK(1 ν ) to obtain the secret key SKPK and the public key PK PK where v is a security parameter.
[0161] The public key cryptography setup unit 110 of the control key generation station 10 uses the private key SK generated in step S1101 above. PK is the control key CK, and the control key CK=SK PK and the public key PK PK is stored in the key storage unit 106, and the public key PK PK is made public to other entities by any method (step S1102).
[0162] <Encryption process> The encryption process according to the third embodiment will be described with reference to FIG. 19. FIG. 19 is a flowchart showing an example of the encryption process according to the third embodiment. In the following, the recipient is the user terminal 30. i , the sender is a user terminal 30 j (j ≠ i), the user terminal 30 j The case where the encryption process is executed will be described.
[0163] The processing in steps S1201 to S1203 may be similar to the processing in steps S501 to S503 in FIG. 9, and therefore the description thereof will be omitted.
[0164] User terminal 30 j The public key encryption unit 311 executes the encryption algorithm EncPK to generate ciphertext C3 by encrypting the policy-attached ciphertext C2 generated in step S1203 (step S1204). That is, the public key encryption unit 311 encrypts C3←EncPK(PK PK , C2) to generate ciphertext C3.
[0165] User terminal 30 j The communication unit 301 transmits the ciphertext C=(C1, C3) to the user terminal 30 in the same manner as in step S505 of FIG. i (step S1205).
[0166] <Decryption process> The decoding process according to the third embodiment will be described with reference to FIG. 20. FIG. 20 is a flowchart showing an example of the decoding process according to the third embodiment. i 20. Note that steps S1301 to S1302 and steps S1308 to S1310 in FIG. 20 are performed by the user terminal 30. i and steps S1303 to S1307 are processes executed by the control key generation station 10.
[0167] User terminal 30 i The communication unit 301 of the user terminal 30, similarly to step S601 of FIG. j The encrypted text C=(C1, C3) transmitted from the first node is received (step S1301).
[0168] User terminal 30 i The communication unit 301 transmits a decryption request including the ciphertext C3 to the control key generation station 10 (step S1302).
[0169] The communication unit 101 of the control key generation station 10 communicates with the user terminal 30 i The decryption request transmitted from the server 10 is received (step S1303).
[0170] The authentication unit 112 of the control key generation station 10 authenticates the user terminal 30 that is the request source of the decryption request received in step S1303. i The authentication method is not limited to a specific method, and the authentication unit 112 authenticates the user terminal 30 by any authentication method. i For example, the authentication unit 112 authenticates the user terminal 30 using a user ID and a password. i The user terminal 30 may be authenticated, or a secure session may be established. i The user terminal 30 may be authenticated by other methods. i Hereinafter, the user terminal 30 iThe following description will be given assuming that the authentication of the user terminal 30 has been successful. i If the authentication fails, the authentication unit 112 ends the decryption process.
[0171] The revoked key management unit 105 of the control key generation station 10 i Attribute key SK i It is determined whether the revoked key information related to the user terminal 30 is stored in the revoked key information storage unit 107 (step S1305). i Attribute key SK i When revocation information regarding the attribute key SK is stored in the revocation information storage unit 107, i is revoked, otherwise its attribute key SK i is verified to have not been revoked.
[0172] The revoked key management unit 105 is a user terminal 30 i Attribute key SK i For example, if the control key generation station 10 holds the user ID and the key ID in association with each other, the revoked key management unit 105 acquires or identifies the key ID of the user terminal 30 that has been successfully authenticated in step S1304. i Similarly, for example, if the attribute key generation station 20 holds a user ID and a key ID in association with each other, the revoked key management unit 105 may identify the key ID from the user terminal 30 that has been successfully authenticated in step S1304. i Alternatively, the user may send a key ID acquisition request including the user ID to the attribute key generation authority 20 and obtain the key ID as a response.
[0173] Hereinafter, in step S1305 above, the user terminal 30 i Attribute key SK i The explanation will continue assuming that it has been confirmed that the attribute key SK has not been revoked. i If it is confirmed that the revoked key has been revoked, the revoked key management unit 105 ends the decryption process.
[0174] The public key decryption unit 111 of the control key generation station 10 executes the decryption algorithm DecPK to decrypt the ciphertext C3 included in the decryption request received in the above step S1303 (step S1306). That is, the public key decryption unit 111 executes DecPK(CK, C3). As a result, if the decryption is successful, the ciphertext C2 with the policy is obtained as the decryption result.
[0175] The communication unit 101 of the control key generation station 10 transmits the policy-attached ciphertext C2 obtained in step S1306 to the user terminal 30. i (step S1307).
[0176] User terminal 30 i The communication unit 301 receives the policy-attached ciphertext C2 transmitted from the control key generation station 10 (step S1308).
[0177] The processing in steps S1309 to S1310 may be similar to the processing in steps S605 to S606 in FIG. 10, and therefore a description thereof will be omitted.
[0178] <Summary of the third embodiment> As described above, in the cryptosystem 1 according to the third embodiment, the secret key of any public key cryptography other than attribute-based cryptography can be used as the control key CK. Therefore, compared to the first embodiment, there are disadvantages such as the need for authentication and a large processing load on the control key generation station 10 side, but there is an advantage that a flexible system configuration is possible because any public key cryptography can be used.
[0179] [Example of hardware configuration for each entity] Each entity (the control key generation authority 10, the attribute key generation authority 20, and the user terminal 30) included in the cryptographic system 1 according to the above-described first to third embodiments can be realized, for example, by the hardware configuration of a computer 500 shown in Fig. 21. Fig. 21 is a diagram showing an example of the hardware configuration of the computer 500.
[0180] 21 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.
[0181] 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.
[0182] 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.
[0183] 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, various types of arithmetic devices such as a CPU.
[0184] 21 is an example, and the hardware configuration of the computer 500 is not limited thereto. For example, the computer 500 may have multiple auxiliary storage devices 507 and multiple processors 508, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.
[0185] [Variations] Modifications of the above first to third embodiments will now be described.
[0186] Variation 1 In the first to third embodiments, the control key generation station 10 exists in common for each domain, but the control key generation station 10 may exist for each domain. In this case, each control key generation station 10 transmits a policy-attached ciphertext C CK In addition, the user terminal 30 as the sender transmits the public key PK of the control key generation station 10 in the same domain as the domain to which the user terminal 30 as the receiver belongs. KP Generate attributed ciphertext C3 using
[0187] For example, the control key generation authority 10 may be realized by a multi-tenant server, and a control key generation authority 10 may exist for each tenant. In this case, it can be considered as the same as the case where a control key generation authority 10 exists for each domain.
[0188] Variation 2 In the first and second embodiments, a policy-attached ciphertext C CK The control key generation station 10 transmits the policy-attached ciphertext C to each user terminal 30 at a predetermined time interval. For example, in response to a control key acquisition request from each user terminal 30, the control key generation station 10 transmits the policy-attached ciphertext C CKAt this time, the control key generation station 10 authenticates the user terminal 30 that has made the control key acquisition request, and only if the authentication is successful, returns the policy-attached ciphertext C CK You may reply with:
[0189] Variation 3 In the first and second embodiments, when encrypting the common key K, it is encrypted by the CP attribute encryption unit 304 and then encrypted by the KP attribute encryption unit 305, but this encryption order may be reversed. That is, when encrypting the common key K, it may be encrypted by the KP attribute encryption unit 305 and then encrypted by the CP attribute encryption unit 304. In this case, however, the policy-attached ciphertext encrypted by the CP attribute encryption unit 304 can be decrypted by the recipient's attribute key (including the case where the attribute key has been leaked), so the security level decreases. For this reason, when encrypting the common key K, it is preferable to encrypt it by the CP attribute encryption unit 304 and then encrypted by the KP attribute encryption unit 305.
[0190] Variation 4 In the first and second embodiments, when encrypting the common key K, the common key K is encrypted by the CP attribute encryption unit 304 and then encrypted by the KP attribute encryption unit 305. However, the encryption by the CP attribute encryption unit 304 and the encryption by the KP attribute encryption unit 305 may be executed in parallel by utilizing secret sharing. For example, the common key generation unit 302 may generate another random number R in addition to the common key K, and the result X of the exclusive OR of the common key K and the random number R may be encrypted by either the CP attribute encryption unit 304 or the KP attribute encryption unit 305, while the common key K may be encrypted by the other. This can be expected to reduce the encryption time by 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 only an example, and X may be calculated by some kind of calculation from the common key K and the random number R.
[0191] Variation 5 In the first to third embodiments, the case where the user terminal 30 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. 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 common key cryptography may be implemented by an API or as a function provided by an external server.
[0192] Variation 6 In the first to third embodiments, the sender transmits the ciphertext C1 obtained by encrypting the message M with the common key K and the ciphertext C3 obtained by doubly encrypting the common key K to the recipient, but it is not necessary to use the common key cipher if, for example, the message M, which is the data to be transmitted, is so small that it does not need to be encrypted with the common key cipher. In this case, the sender may transmit the ciphertext C3 obtained by doubly encrypting the message M instead of the common key K from the sender to the recipient.
[0193] [supplement] In the above first to third embodiments, for convenience of explanation, the user terminal 30 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 30 (i.e., the user of the user terminal 30).
[0194] The present invention is not limited to the above-described embodiments specifically disclosed, and various modifications, changes, combinations with known technologies, etc. are possible without departing from the scope of the claims. [Explanation of symbols]
[0195] 1. Cryptographic Systems 10 Control Key Generation Authority 20 Attribute key generation authority 30 User terminals 101 Communications Department 102 KP attribute encryption setup part 103 Control Key Generation Unit 104 CP attribute encryption section 105 Revocation Key Management Unit 106 Key storage unit 107 Revocation key information storage unit 108 Effective Key Management Unit 109 Valid key information storage unit 110 Public Key Cryptography Setup Section 111 Public key decryption unit 112 Authentication Department 201 Communications Department 202 CP attribute encryption setup part 203 Authentication Department 204 CP attribute key generation section 205 Issued Key Management Department 206 Key storage unit 207 Issued key information storage unit 301 Communications Department 302 Common key generation unit 303 Common key encryption section 304 CP attribute encryption section 305 KP attribute encryption section 306 KP Attribute Decoding Unit 307 CP Attribute Decoding Unit 308 Common key decryption unit 309 Key storage unit 310 Message storage unit 311 Public Key Cryptography 312 Public Key Decryption Unit 500 Computers 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. An encryption system including a first terminal on the sending side and a second terminal on the receiving side, The first terminal comprises: a first encryption unit that generates a first policy-attached ciphertext by encrypting transmission data using ciphertext policy attribute-based encryption; a second encryption unit that generates an attribute-attached ciphertext by encrypting the first policy-attached ciphertext using key policy attribute-based encryption; a first transmission unit that transmits the attribute-added ciphertext to the second terminal; The second terminal comprises: a first decryption unit that decrypts, by using a user private key of the ciphertext policy attribute-based encryption, a second policy-attached ciphertext in which a policy indicating that the user private key has not expired or that the user private key is valid is embedded, the second policy-attached ciphertext being obtained by encrypting a control key for decrypting the attribute-attached ciphertext by the ciphertext policy attribute-based encryption; a second decryption unit that decrypts the attribute-attached ciphertext by using a control key obtained by decrypting the second policy-attached ciphertext; a third decryption unit that uses the user private key to decrypt a first policy-attached ciphertext obtained by decrypting the attribute-attached ciphertext, and acquires the transmission data.
2. The cryptographic system further includes a control key generation station; The control key generation station comprises: a control key generation unit that generates a secret key of the key policy attribute-based encryption as the control key; a third encryption unit that generates the second policy-attached ciphertext by encrypting the control key by the ciphertext policy attribute-based encryption using a policy that indicates that the user private key has not expired or that the user private key is valid; The cryptosystem according to claim 1 , further comprising: a second transmitting unit configured to transmit the second policy-attached ciphertext to the second terminal.
3. The control key generation station comprises: a revoked key information storage unit that stores revoked key information including at least a key ID of a revoked user private key; 3. The cryptographic system of claim 2, wherein the policy indicating that the user private key has not been revoked is a condition indicating that a key ID of a user private key used to decrypt the second policy-attached ciphertext is a key ID other than a key ID included in the revoked key information stored in the revoked key information storage unit.
4. The control key generation station comprises: a valid key information storage unit that stores valid key information including at least a key ID of a valid user private key; 3. The cryptographic system of claim 2, wherein the policy indicating that the user private key is valid is a condition indicating that a key ID of a user private key used to decrypt the second policy-attached ciphertext matches any of the key IDs included in the valid key information stored in the valid key information storage unit.
5. The first encryption unit encrypting the transmission data by the ciphertext policy attribute-based encryption using a policy that is a condition related to an attribute of a user of the second terminal and a condition indicating that the expiration date of the user private key has not yet passed; The third decoding unit 5. The cryptographic system according to claim 1, further comprising: a cryptographic device that decrypts the first policy-attached encrypted text and obtains the transmission data if an attribute related to a user of the second terminal satisfies a condition related to the attribute and if the current date and time has not passed the expiration date.
6. The second encryption unit encrypting the first policy-attached ciphertext with the encryption date and time of the attribute-attached ciphertext as an attribute; The second decoding unit 6. The cryptographic system according to claim 5, wherein the first policy-attached ciphertext is decrypted from the attribute-attached ciphertext by using the control key having an embedded policy indicating that the generation date and time of the control key is at least after the encryption date and time, when the generation date and time of the control key is at least after the encryption date and time embedded in the attribute-attached ciphertext.
7. A terminal communicably connected to a first terminal that transmits a ciphertext doubly encrypted by ciphertext policy attribute-based encryption and key policy attribute-based encryption, and a second terminal that is a receiving side between the first terminal and the first terminal, a control key generation unit that generates a secret key of the key policy attribute-based encryption as a control key; an encryption unit that generates a policy-attached ciphertext by encrypting the control key by the ciphertext policy attribute-based encryption using a policy that indicates that a user private key of the second terminal generated by the ciphertext policy attribute-based encryption has not expired or that the user private key is valid; a transmitter that transmits the policy-attached ciphertext to the second terminal; A terminal having the above configuration.
8. A terminal which is a receiver between another terminal and the terminal which transmits a ciphertext which is doubly encrypted by the ciphertext policy attribute-based encryption and the key policy attribute-based encryption, a first decryption unit that uses a user private key of the ciphertext policy attribute-based encryption to decrypt a policy-attached ciphertext having an embedded policy indicating that the user private key has not expired or is valid, the policy-attached ciphertext being obtained by encrypting a control key for decrypting the ciphertext encrypted by the key policy attribute-based encryption, using the ciphertext policy attribute-based encryption; a second decryption unit that decrypts the ciphertext by using a control key obtained by decrypting the ciphertext with the policy; a third decryption unit that further decrypts the ciphertext obtained by decrypting the ciphertext by using the user private key; A terminal having the above configuration.
9. A method for use in an encryption system including a first transmitting terminal and a second receiving terminal, comprising: The first terminal, a first encryption step of generating a first policy-attached ciphertext by encrypting the transmission data using ciphertext policy attribute-based encryption; a second encryption step of generating an attribute-attached ciphertext by encrypting the first policy-attached ciphertext using key policy attribute-based encryption; a first transmission step of transmitting the attribute-added ciphertext to the second terminal; The second terminal, a first decryption step of decrypting, by using a user private key of the ciphertext policy attribute-based encryption, a second policy-attached ciphertext in which a policy indicating that the user private key has not expired or that the user private key is valid is embedded, the second policy-attached ciphertext being obtained by encrypting a control key for decrypting the attribute-attached ciphertext by the ciphertext policy attribute-based encryption; a second decryption step of decrypting the attribute-attached ciphertext by using a control key obtained by decrypting the second policy-attached ciphertext; a third decryption step of decrypting a first policy-attached ciphertext obtained by decrypting the attribute-attached ciphertext using the user private key to obtain the transmission data.
10. A program for causing a computer to function as the first terminal or the second terminal included in the encryption system according to claim 1.
Citation Information
Patent Citations
Cryptographically secure cross-domain information sharing
US20170093817A1