JP7721073B2 - Cryptographic system, terminal, and method - Google Patents

Description

Article 30, paragraph 2 of the Patent Act applies. Published at the 2021 Cryptography and Information Security Symposium from January 19, 2021 to January 22, 2021 (publication date: January 21, 2021).

The present invention relates to a cryptographic system, a terminal, and a method.

Identity-Based Encryption (IBE) technology is a type of public key encryption technology, and is an encryption method that allows users to specify their email address, name, IP (Internet Protocol) address, etc. as the public key (see, for example, Non-Patent Document 1).

A system that implements encryption and decryption using ID-based encryption technology consists of a private key generation center (PKG), a user (receiver) terminal, and a sender terminal, and performs the following process. First, the private key generation center generates public parameters and a master private key as system setup and makes the public parameters public to user terminals and sender terminals belonging to the system. The user terminal requests the private key generation center to generate a private key for a certain identifier ID. Upon receiving the identifier ID from the user terminal, the private key generation center generates a private key corresponding to that identifier ID from the identifier ID, public parameters, and master private key, and sends this private key to the user terminal. The sender terminal encrypts the message it wishes to send to the user terminal using the public parameters and the identifier ID of the user terminal, and then sends the ciphertext obtained by this encryption to the user terminal. The user terminal that receives the ciphertext decrypts it using the public parameters and the private key corresponding to its own identifier ID. This completes encryption and decryption.

In recent years, advances in cloud technology have increased the opportunities to access the same services from multiple devices. For example, with webmail services, the same email address can be used on a variety of devices, such as desktop PCs, tablet PCs, and smartphones.

Given this situation, similar scenarios must be considered in systems that implement encryption and decryption using ID-based encryption technology. Specifically, for example, a scenario must be considered in which a cloud service account is used as an identifier (ID), a private key corresponding to the user's identifier (ID) is stored and operated on multiple devices, and data encrypted using that identifier (ID) is decrypted and used on those devices. However, in this case, it is not guaranteed that the same device will continue to be used in the future; devices may be added or discarded. It is also possible that a user's account may be suspended or deleted. Therefore, for example, if a device is discarded, a mechanism is needed to prevent the private key used on other devices from being obtained from the discarded device. Furthermore, if a user's account is suspended or deleted, a mechanism is also needed to prevent data from being decrypted on any devices that have a private key corresponding to that account.

Ryuichi SAKAI, Masao KASAHARA, "ID based Cryptosystems with Pairing on Elliptic Curve"

However, with existing ID-based encryption technologies such as those described in Non-Patent Document 1, it is difficult to say that private keys can be properly deleted from devices when the devices are disposed of or when accounts are suspended or deleted.

With existing ID-based encryption technology, if there is a device that has a private key corresponding to an identifier ID, ciphertext encrypted with that identifier ID can be decrypted at any time. Therefore, for example, if a private key corresponding to an identifier ID is obtained from a discarded device, it would be possible to read messages encrypted with that identifier ID even after the device has been discarded.

One embodiment of the present invention has been made in light of the above points, and aims to realize ID-based encryption that can control whether a device can decrypt data.

To achieve the above object, one embodiment of the cryptographic system includes a private key generation center, one or more representative terminals, one or more child terminals used by the same user as the representative terminal, and one or more sending terminals, wherein the private key generation center has a setup unit that generates public parameters of hierarchical ID-based encryption and a master private key, and a first user private key generation unit that generates a user private key for the representative terminal using an identifier of the representative terminal, the master private key, and the public parameters, and the representative terminal is a device configured with an identifier of a child terminal used by the same user as the user who uses the representative terminal. The device has a storage unit that stores the list, a device private key generation unit that generates a device private key for decrypting ciphertext sent from the sending terminal using a user private key corresponding to its own identifier, a device update time that indicates the update time of the device list, and the public parameters, and a first transmission unit that transmits the device private key to a child terminal represented by an identifier included in the device list, and the sending terminal has an encryption unit that generates ciphertext by encrypting a message using the identifier of the representative terminal and the device update time, and a second transmission unit that transmits the ciphertext to the representative terminal or the child terminal.

It is possible to realize ID-based encryption that allows control over whether a device can decrypt data.

1 is a diagram illustrating an example of the overall configuration of a cryptographic system according to a first embodiment; FIG. 2 is a diagram illustrating an example of a functional configuration of a private key generation center. FIG. 2 is a diagram illustrating an example of a functional configuration of a representative terminal. FIG. 2 is a diagram illustrating an example of a functional configuration of a child terminal. 10 is a diagram illustrating an example of a functional configuration of a transmitting terminal. FIG. 10 is a diagram for explaining an example of key generation in Example 1-1. FIG. 10 is a diagram for explaining an example of key generation in Example 1-2. FIG. 10 is a diagram illustrating an example of the overall configuration of a cryptographic system according to a second embodiment. FIG. 2 illustrates an example of a functional configuration of an identifier issuing server. FIG. 10 is a diagram for explaining an example of key generation in Example 2-1. FIG. 10 is a diagram for explaining an example of key generation in Example 2-2. FIG. 2 illustrates an example of the hardware configuration of a computer.

The following describes a first and second embodiment of the present invention. In each of the following embodiments, we will assume a situation in which a user manages multiple devices that can decrypt ciphertext using ID-based encryption, and describe an encryption system 1 that can control the device so that if a device is discarded, decryption is not possible using the private key held by that device, or if the identifier ID expires, decryption is not possible on any device.

[Preparation]
Before describing each embodiment, a hierarchical identity-based encryption (HIBE) scheme will be described as a preparatory step.

It is assumed that user identifiers are given hierarchically, such as ID=(ID ₁ , ..., ID _t ), where t represents a hierarchy and ID _t is the identifier for the t-th hierarchy.

For two identifiers ID and ID', when ID = (ID ₁ , ..., ID _t-1 ) and ID' = (ID ₁ , ..., ID _t-1 , ID _t ), we write pa(ID) = ID'. Note that when t = 1, ID' refers to the PKG (that is, the 0th layer is the PKG).

In this case, the hierarchical ID-based encryption method consists of the following four algorithms (HIBE.Setup, HIBE.KeyGen, HIBE.Encrypt, HIBE.Decrypt).

(pp, msk)←HIBE.Setup(1 ^κ ): Using a bit string 1 ^κ corresponding to security parameter κ (that is, a κ-bit string of 1s) as input, generate and output public parameter pp and master private key msk.

sk _ID ←HIBE.KeyGen(pp, sk _pa(ID) , ID): Public parameters pp, private key sk _pa(ID) , and identifier ID are input, and a private key sk _ID corresponding to the identifier ID is generated and output. Note that when t = 1, sk _pa(ID) = msk.

C←HIBE.Encrypt(pp, ID, M): Takes public parameters pp, identifier ID, and plaintext M as input and generates and outputs ciphertext C.

M'←HIBE.Decrypt(pp, ID, sk _ID , C): Public parameters pp, identifier ID, secret key sk _ID , and ciphertext C are input, and plaintext M' is generated and output.

Furthermore, for any (pp, msk) ← HIBE.Setup(1 ^κ ), any plaintext M, any identifier ID, and a secret key sk _ID ← HIBE.KeyGen(pp, sk _pa(ID) , ID) corresponding to the identifier ID, M = HIBE.Decrypt(pp, ID, sk _ID , HIBE.Encrypt(pp, ID, M)).

An example of the above-mentioned hierarchical ID-based encryption method is the method described in Japanese Patent No. 5097102.

[First embodiment]
The first embodiment will be described below.

<Example of overall configuration of cryptographic system 1>
An example of the overall configuration of an encryption system 1 according to this embodiment is shown in Fig. 1. As shown in Fig. 1, the encryption system 1 according to this embodiment is composed of multiple entities connected to each other via a network 90 such as the Internet. The entities include a private key generation center 10, representative terminals _20i (i = 1, ..., n), child terminals 30i _,j (i = 1, ..., n, j = 1, ..., m_i), a time server 40, and a transmitting terminal 50.

The private key generation center 10 is a server that functions as a PKG. The representative terminal 20 _i is a device that has a private key corresponding to the identifier ID _i . The child terminals 30 _i,j are devices that have a private key corresponding to the same identifier ID _i as the representative terminal 20 _i . The representative terminal 20 _i and the child terminals 30 _i,j (j = 1, ..., m_i) constitute a user terminal group i that represents a device group of the same user. n represents the total number of representative terminals 20 _i , and m_i represents the total number of child terminals 30 i _,j that have a private key corresponding to the identifier ID _i .

Here, it is assumed that an identifier ID _i is assigned to the representative terminal 20 _i . Examples of the identifier ID _i include a telephone number, an email address, a My Number, an employee number, a user ID for a social media account, a serial number specific to the representative terminal 20 _i , an IP address, and a MAC (Media Access Control) address. However, these are just examples, and any information that can be uniquely identified among people, organizations, devices, etc. can be used as the identifier ID _i . Hereinafter, the identifier ID _i assigned to the representative terminal 20 _i will also be referred to as a user identifier ID _i .

It is also assumed that an identifier ID _i,j is assigned to the child terminal 30 _i,j . For example, if the child terminal 30 _i,j is a mobile phone, smartphone, or the like, the identifier ID _i,j may be an International Mobile Equipment Identity (IMEI) or a telephone number linked to a Subscriber Identity Module (SIM) card. However, these are merely examples, and any information that can identify the child terminal 30 _i,j can be used as the identifier ID _i,j . Hereinafter, the identifier ID i, _j assigned to the child terminal 30 i _,j will also be referred to as a device identifier ID _i,j .

The time server 40 is a server that distributes time information to other entities. As a result, the time information of each entity that makes up the encryption system 1 according to this embodiment is synchronized. This time information is used to identify or calculate the device update time τ and user update time T, as well as their update intervals Δτ and ΔT, which will be described later.

An example of a time server 40 is an NTP (Network Time Protocol) server, but it is not limited to this. Note that although only one time server 40 is shown in the example shown in Figure 1, there may be multiple time servers 40 as long as they are time-synchronized with each other.

The transmitting terminal 50 encrypts a message (plain text) using the user identifier ID _i and transmits it to the representative terminal 20 _i or the child terminal 30 _i,j . Note that either the representative terminal 20 _i (i=1, ..., n) or the child terminal 30 _i,j (i=1, ..., n j=1, ..., m_i) may function as the transmitting terminal 50.

<Example of functional configuration>
An example of the functional configuration of the private key generation center 10 is shown in Fig. 2. As shown in Fig. 2, the private key generation center 10 has a setup processing unit 101 and a user private key generation unit 102. Each of these units is realized, for example, by processing in which one or more programs installed in the private key generation center 10 are executed by a processor such as a CPU (Central Processing Unit). The private key generation center 10 also has a storage unit 103. The storage unit 103 is realized, for example, by a memory device such as an HDD (Hard Disk Drive), an SSD (Solid State Drive), a RAM (Random Access Memory), or a flash memory.

The setup processing unit 101 executes the HIBE.Setup algorithm to generate and output public parameters and a master private key. The user private key generation unit 102 executes the HIBE.KeyGen algorithm to generate and output a private key. The storage unit 103 stores various information (e.g., master private key, time information, public parameters, etc.).

An example of the functional configuration of the representative terminal _20i is shown in Fig. 3. As shown in Fig. 3, the representative terminal _20i has a device private key generation unit _201i , a decryption unit _202i , and a list update unit _203i . Each of these units is realized, for example, by a processor executing one or more programs installed in the representative terminal _20i . The representative terminal _20i also has a storage unit _204i . The storage unit _204i is realized, for example, by a memory device.

The device private key generation unit _201i executes the HIBE.KeyGen algorithm to generate and output the private key of the child terminal 30i _,j (hereinafter, this private key will also be referred to as the device private key). The decryption unit _202i executes the HIBE.Decrypt algorithm to decrypt the ciphertext received from the transmitting terminal 50. The list update unit _203i updates the device list _Listi held by the representative terminal _20i . The device list _Listi is list-format data having the device identifier IDi, _j of the child terminal 30i _,j as an element. The storage unit _204i stores various information (e.g., its own user identifier _IDi , the private key corresponding to this user identifier _IDi , time information, public parameters, device list _Listi , etc.).

An example of the functional configuration of the child terminal 30i _,j is shown in Fig. 4. As shown in Fig. 4, the child terminal 30i _,j has a decoding unit 301i _,j . The decoding unit 301i _,j is realized, for example, by a process in which one or more programs installed in the child terminal 30i _,j are executed by a processor. The child terminal 30i _,j also has a storage unit 302i _,j . The storage unit 302i _,j is realized, for example, by a memory device.

The decryption unit 301 _i,j executes the HIBE.Decrypt algorithm to decrypt the ciphertext received from the transmitting terminal 50. The storage unit 302 _i,j stores various information (for example, its own device identifier ID _i,j , device private key, time information, public parameters, etc.).

An example of the functional configuration of the transmitting terminal 50 is shown in Figure 5. As shown in Figure 5, the transmitting terminal 50 has an encryption unit 501. The encryption unit 501 is realized, for example, by a process executed by a processor of one or more programs installed in the transmitting terminal 50. The transmitting terminal 50 also has a storage unit 502. The storage unit 502 is realized, for example, by a memory device.

The encryption unit 501 executes the HIBE.Encrypt algorithm to encrypt the message (plain text). The storage unit 502 stores various information (e.g., user identifier, time information, public parameters, etc.).

<Example 1-1>
In the following, an embodiment 1-1 will be described, which describes a case where, when a child terminal 30 _i,j of a user terminal group i is added or deleted, the decryption permission of the child terminal 30 _i,j is controlled.

In this embodiment, the representative terminal 20 _i updates the device list List _i (adds or deletes device identifiers ID _i,j ) at every update interval Δτ, generates a device private key, and distributes the device private key to the child terminal 30 _i, j having the device identifier ID _i,j included in the device list List _i that it manages. When generating the device private key, the device update time τ is used in addition to the user identifier ID _i . The device update time τ is based on the update interval Δτ. For example, if the update interval Δτ is one hour, the time is given as a character string such as τ = 2021032515 (15:00, March 25, 2021), and if the update interval Δτ is one day, the time is given as a character string such as τ = 2021032515 (15:00, March 25, 2021).

Furthermore, the sending terminal 50 encrypts the message (plaintext) using the device update time τ in addition to the user identifier ID _i . As a result, apart from the representative terminal 20 _i , only the child terminals ID _i,j having the device identifier ID _i,j included in the device list List _i at the device update time τ can decrypt the message. Therefore, for example, if a child terminal 30 _i,j is discarded and its device identifier ID _i,j is deleted from the device list List _i , it is possible to control the device private key held by that child terminal 30 _i,j so that the ciphertext cannot be decrypted thereafter.

The device update time τ is updated at every update interval Δτ as τ←τ+Δτ, and each time this update is performed, the device list List _i is updated and a device private key is generated. For example, if the update interval Δτ is one hour and the current device update time is τ=2021032515, the device update time τ is updated to τ=2021032516 when one hour has passed since the previous update. Similarly, if the update interval Δτ is one day and the current device update time is τ=20210325, the device update time τ is updated to τ=20210326 when one day has passed since the previous update.

The following describes the setup, user private key generation, device list update, device private key generation, encryption, and decryption processes in this embodiment. Note that the security parameter κ represents the security strength, and can be set to, for example, κ = 128 or κ = 256.

<<Setup in Example 1-1>>
The setup processing unit 101 of the private key generation center 10 executes (pp, msk)←HIBE.Setup(1 ^κ ) to generate and output the public parameters pp and the master private key msk. The public parameters pp are stored in the storage unit 103 and are distributed to other entities (representative terminal 20 _i , child terminals 30 _i,j , transmitting terminal 50, etc.). The master private key msk is stored in the storage unit 103 and managed in secret.

<<User Private Key Generation in Example 1-1>>
In response to a request from a representative terminal 20 _i , the user private key generation unit 102 of the private key generation center 10 generates a private key sk _{ID_i} corresponding to the user identifier ID _i of this representative terminal 20 _i and transmits it to the representative terminal 20 _i . When transmitting the private key sk _{ID_i} to the representative terminal 20 _i , it is desirable to establish a secure communication path using a technology such as TLS (Transport Layer Security). However, the method of transmitting the private key sk _{ID_i} is not limited to this.

Specifically, the user private key generation unit 102 of the private key generation center 10 executes sk _{ID_i} ←HIBE.KeyGen(pp, msk, ID _i ) in response to a request from the representative terminal 20 _i , and transmits this private key sk _{ID_i} to the representative terminal 20 _i . The private key sk _{ID_i} is stored in the storage unit 204 _i and managed in secret.

<Device List Update in Example 1-1>
When the device update time τ is updated, the list update unit 203 _i of the representative terminal 20 _i updates the device list List _i . Here, the list of device identifiers to be added to the device list List _i is defined _as AddDevi, and the list of device identifiers to be deleted _from the device list List _i is defined as DelDevi. Note that _AddDevi and _DelDevi are provided to the representative terminal 20 _i , and either or both of them may be empty lists.

At this time, the list update unit 203 _i of the representative terminal 20 _i updates the device list List _i by: List _i ←(List _i \DelDev _i ) ∪ AddDev _i The updated device list List _i is stored in the storage unit 204 _i .

<Device private key generation in Example 1-1>
When the device list List _i is updated, the device private key generation unit 201 _i of the representative terminal 20 _i generates a device private key dsk ID_i _, τ using the private key sk _{ID_i} corresponding to its own user identifier ID _i and the device update time τ, and transmits the device private key dsk ID_i _,τ to the child terminal 30 _i,j having the device identifier _{ID i,j} included in the device list List _i . Note that when transmitting the device private key dsk _{ID_i,τ} to the child terminal 30 _i,j , it is desirable to establish a secure communication path using technology such as TLS. However, the method of transmitting the device private key dsk _{ID_i,τ} is not limited to this.

Specifically, the device private key generation unit 201 _i of the representative terminal 20 _i creates a hierarchical identifier in the form ID _i,τ = (ID _i , τ), then executes dsk _{ID_i,τ} ←HIBE.KeyGen(pp,sk _{ID_i} , ID _i,τ ) and transmits the device private key dsk ID_i _,τ to the child terminal 30 _{i,j having the device identifier ID i,j included} in the device list List _i . Note that the device private key dsk _{ID_i,τ} is stored in the storage unit 204 _i of the representative terminal 20 _i , and is also stored in the storage unit 302 _{i,j of the child terminal 30 i ,j} that received the device private key dsk _{ID_i,τ} , and is managed in secret.

Encryption in Example 1-1
When transmitting the ciphertext of the message M to the representative terminal 20 _i or its child terminal 30 _{i, j} , the encryption unit 501 of the transmitting terminal 50 encrypts the message M using the user identifier ID _i and the device update time τ, and transmits the ciphertext to the representative terminal 20 _i or child terminal 30 _{i, j} .

Specifically, the encryption unit 501 of the sending terminal 50 creates a hierarchical identifier of the form ID _i,τ = (ID _i , τ), then executes C←HIBE.Encrypt(pp, ID _i,τ , M), and transmits the ciphertext C to the representative terminal 20 _i or the child terminal 30 _i,j .

<Decryption in Example 1-1>
When the representative terminal 20 _i receives the ciphertext C, the decryption unit 202 _i of the representative terminal 20 _i executes M←HIBE.Decrypt(pp, ID _{i, τ} , dsk _{ID_i, τ} , C) to decrypt the ciphertext C. The message M obtained by this decryption is stored in the memory unit 204 _i .

Similarly, when a child terminal 30i _,j receives the ciphertext C, the decryption unit 301i _,j of the child terminal 30i _,j executes M←HIBE.Decrypt(pp, IDi _,τ , dsk _{ID_i,τ} , C) to decrypt the ciphertext C. Note that this can only be executed by the child terminal 30i _, j that has the device private key dsk _{ID_i,τ} . The message M obtained by this decryption is stored in the storage unit 302i _,j .

Summary of Example 1-1
As described above, in this embodiment, a hierarchical identifier ID _i,τ = (ID _i ,τ) is created from the user identifier ID _i and the device update time τ, and then the device private key dsk _{ID_i, τ corresponding to this identifier ID i,τ} is distributed to the child terminal 30 _{i, j having the device identifier ID i,j} included in the device list List _i . Similarly, when encrypting a message M, an identifier ID _i,τ is created, and then a ciphertext C is created using this identifier ID _i,τ .

As a result, apart from the representative terminal 20 _i , only the child terminals 30 _{i, j having the device identifier ID i, j} included in the device list List i can decrypt the ciphertext C using the device private key dsk _{ID_i,τ} . Therefore, for example, if a certain child terminal 30 _i,j is discarded and its device identifier ID _i,j is deleted from the device list List _i , even if the device private key held by that child terminal 30 _i,j is leaked, it is possible to prevent a situation in which the ciphertext is decrypted using that device private key.

The relationship between identifiers and private keys during key generation in this embodiment is shown in Figure 6. As shown in Figure 6, the private key generation center 10 corresponds to the 0th layer, generates a private key sk _{ID_i} corresponding to the user identifier ID _i of the representative terminal 20 _i , and distributes it to the representative terminal 20 _i . The representative terminal 20 _i corresponds to the 1st layer, generates a private key sk _{ID_i,τ} corresponding to the identifier ID _i,τ = (ID _i ,τ), and distributes it to its own child terminals 30 _i,j (though child terminals 30 _i, j have device identifiers ID _i,j included in the device list List _i ). Each child terminal 30 _i,j corresponds to the 2nd layer.

<Example 1-2>
In the following, Example 1-2 will be described. In this example, in addition to Example 1-1, a case will be described in which, when a user identifier ID _i expires, control is performed so that decryption cannot be performed at the representative terminal 20 _i and all child terminals 30 _{i, j} included in a user terminal group i. Note that expiration of an identifier ID includes cases in which the identifier ID (or the account corresponding to the identifier ID) is suspended or deleted.

In this embodiment, when the private key generation center 10 generates a private key for the representative terminal _20i , it periodically generates a private key corresponding to the user identifier _IDi using not only the user identifier _IDi but also the user update time T. In this case, for example, if the user identifier _IDi is to be invalidated at a certain user update time T, generation of a private key corresponding to the user identifier _IDi is not performed after T+ΔT, where ΔT is the update interval for the user update time T. The user update time T is updated at each update interval ΔT as T←T+ΔT.

Furthermore, the sending terminal 50 encrypts the message (plain text) using the user update time T and the device update time τ in addition to the user identifier ID _i . This makes it possible to control so that if the user identifier ID _i is invalidated at a certain user update time T, the representative terminal 20 _i and all the child terminals 30 _i,j cannot decrypt the message after T + ΔT.

There is no particular dependency between the user update time T and the device update time τ, and they are independent of each other. For example, the update interval ΔT for the user update time T may be set to one year (e.g., T = 2021, ΔT = 1), and the update interval Δτ for the device update time τ may be set to one month (e.g., τ = 202103, Δτ = 1).

The following describes the setup, user private key generation, device list update, device private key generation, encryption, and decryption processes in this embodiment.

<<Setup in Example 1-2>>
The setup in this embodiment is the same as in embodiment 1-1, so the description thereof will be omitted.

<<User Private Key Generation in Example 1-2>>
In response to a request from a representative terminal _20i , the user private key generation unit 102 of the private key generation center 10 generates a private key sk _{ID_i,} T corresponding to a concatenated character string ID _i ∥T of the user identifier ID _i of this representative terminal _20i and the user update time T, and transmits the private key sk ID_i, _T to the representative terminal 20i. Note that when transmitting the private key sk _{ID_i,T} to the representative terminal _20i , it is desirable to establish a secure communication path using a technology such as TLS. However, the method of transmitting the private key sk _{ID_i,T} is not limited to this.

Specifically, in response to a request from the representative terminal _20i , the user private key generation unit 102 of the private key generation center 10 executes sk _{ID_i,T} ←HIBE.KeyGen(pp, msk, ID _i ∥T) and transmits this private key sk _{ID_i,T} to the representative terminal _20i . The private key sk _{ID_i,T} is stored in the storage unit _204i and managed in secret.

As described above, when a user identifier ID _i′ is to be invalidated at a certain user update time T, the user private key generation unit 102 of the private key generation center 10 will not generate a private key sk _{ID_i′,T′} corresponding to the user identifier ID _i′ at a user update time T′ after T+ΔT.

<Device List Update in Example 1-2>
The device list update in this embodiment is the same as in embodiment 1-1, and therefore the description thereof will be omitted.

<Device private key generation in Example 1-2>
When the device list List _i is updated, the device private key generation unit 201 _i of the representative terminal 20 _i generates a device private key dsk ID_i,T,τ using the private key sk _{ID_i,T} corresponding to the concatenated string ID _i ∥T and the device update time τ, and transmits the device private key dsk ID_i _,T,τ to the child terminal 30 _{i,j having} the device identifier _{ID i,j} included in the device list List _i . Note that when transmitting the device private key dsk _{ID_i,T,τ} to the child terminal 30 _i,j , it is desirable to establish a secure communication path using technology such as TLS. However, the method of transmitting the device private key dsk _{ID_i,T,τ} is not limited to this.

Specifically, the device private key generation unit 201 _i of the representative terminal 20 _i creates a hierarchical identifier in the form ID _i,T,τ = (ID _i ∥T,τ), then executes dsk _{ID_i,T,τ} ←HIBE.KeyGen(pp,sk _{ID_i,T} , ID _i,T,τ ) and transmits the device private key dsk _{ID_i,T,τ} to the child terminal 30 _i,j having the device identifier ID _i,j included in the device list List _i . The device private key dsk _{ID_i,T,τ} is stored in the storage unit 204 _i of the representative terminal 20 _i , and is also stored in the storage unit 302 _{i,j of the child terminal 30 i,j that} received the device private key dsk _{ID_i,T,τ} , and is managed in secret.

Encryption in Example 1-2
When transmitting the ciphertext of the message M to the representative terminal 20 _i or its child terminal 30 _{i, j} , the encryption unit 501 of the transmitting terminal 50 encrypts the message M using the user identifier ID _i , the user update time T, and the device update time τ, and transmits the ciphertext to the representative terminal 20 _i or child terminal 30 _{i, j} .

Specifically, the encryption unit 501 of the sending terminal 50 creates a hierarchical identifier in the form of ID _i,T,τ = (ID _i ∥T,τ), then executes C←HIBE.Encrypt(pp,ID _i,T,τ ,M) and transmits the ciphertext C to the representative terminal 20 _i or the child terminal 30 _i,j .

Decryption in Example 1-2
When the representative terminal 20 _i receives the ciphertext C, the decryption unit 202 _i of the representative terminal 20 _i executes M←HIBE.Decrypt(pp, ID _{i, T, τ} , dsk _{ID_i, T, τ} , C) to decrypt the ciphertext C. The message M obtained by this decryption is stored in the memory unit 204 _i .

Similarly, when a child terminal 30i _,j receives the ciphertext C, the decryption unit 301i _,j of the child terminal 30i _,j executes M←HIBE.Decrypt(pp,IDi _,T,τ ,dsk _{ID_i,T,τ} ,C) to decrypt the ciphertext C. Note that this can only be executed by the child terminal 30i _,j that has the device private key dsk _{ID_i,T,τ} . The message M obtained by this decryption is stored in the memory unit 302i _,j .

Summary of Example 1-2
As described above, in this embodiment, a private key sk _{ID_i,} T corresponding to a concatenated character string ID _i ∥T of a user identifier ID _i and a user update time T is generated, and this private key sk _{ID_i,T} is distributed to the representative terminal 20 _i . When generating a device private key dsk _{ID_i,T,τ} , a hierarchical identifier ID _i,T,τ = (ID _i ∥T,τ) is created, and this identifier ID _i,T,τ is used to generate the device private key dsk _{ID_i,T,τ} . Similarly, when encrypting a message M, an identifier ID _i,T,τ is created, and then a ciphertext C is generated using this identifier ID _i,τ .

This makes it possible to generate a device private key dsk _{ID_i,T,τ} that depends not only on the device update time τ but also on the user update time T. Therefore, for example, when a user identifier ID _i' at a certain user update time T is to be invalidated, generation of a private key sk _{ID_i',} T' corresponding to that user identifier ID _i' may be avoided at user update times T' after T+ΔT. According to this embodiment, for example, if a user identifier ID _i' is invalidated at user update time T, it is possible to prevent the representative terminal 20 _i' and its child terminals 30 _i',j from decrypting at subsequent user update times T' (≧T+ΔT). Furthermore, even if the device private key dsk _{ID_i',T} is leaked, it is possible to prevent decryption at the user update time T' (≧T+ΔT).

The relationship between identifiers and private keys during key generation in this embodiment is shown in Figure 7. As shown in Figure 7, the private key generation center 10 corresponds to the 0th layer, generates a private key sk _{ID_i,T} corresponding to the user identifier ID _i and user update time T of the representative terminal 20 _i , and distributes it to the representative terminal 20 _i . The representative terminal 20 _i corresponds to the 1st layer, generates a private key sk _{ID_i,T, τ corresponding to the identifier ID i,T,τ} = (ID _i ∥T,τ), and distributes it to its own child terminals 30 _i,j (though child terminals 30 _i, j have device identifiers ID _i,j included in the device list List _i ). Each child terminal 30 _i,j corresponds to the 2nd layer.

[Second embodiment]
The second embodiment will be described below. In this embodiment, a case where an identifier issuing server 60 that issues a user identifier ID _i is provided will be described. Note that the description of the same components as those in the first embodiment will be omitted.

<Example of overall configuration of cryptographic system 1>
An example of the overall configuration of the cryptographic system 1 according to this embodiment is shown in Fig. 8. As shown in Fig. 8, the cryptographic system 1 according to this embodiment further includes an identifier issuing server 60 as an entity.

The identifier issuing server 60 is a server owned by a service provider that provides applications such as cloud services. The identifier issuing server 60 uses its own private key and a user identifier ID _i that it manages to generate a private key for the representative terminal 20 _i that has the user ID identifier ID _i .

Here, it is assumed that an identifier ID _S is assigned to the identifier issuing server 60. Examples of the identifier ID _S include a telephone number, an email address, a My Number, a serial number specific to the identifier issuing server 60, an IP address, and a MAC address. However, these are just examples, and any information that can be uniquely identified within a device or the like can be used as the identifier ID _S.

It should be noted that it is not necessary for all user identifiers ID _i (i = 1, ..., n) to be managed by the identifier issuing server 60; for example, only some of the user identifiers ID _i (for example, user identifiers ID _i for i = 1, ..., _n1 ) may be managed by the identifier issuing server 60. Also, although only one identifier issuing server 60 is shown in the example shown in Fig. 8, there may be multiple identifier issuing servers 60. For example, there may be an identifier issuing server 60A that manages user identifiers ID _i for cloud service A and an identifier issuing server 60B that manages user identifiers ID _i for cloud service B.

<Example of functional configuration>
An example of the functional configuration of the identifier issuing server 60 is shown in Fig. 9. As shown in Fig. 9, the identifier issuing server 60 has a user private key generation unit 601. The user private key generation unit 601 is realized, for example, by a process in which one or more programs installed in the identifier issuing server 60 are executed by a processor. The identifier issuing server 60 also has a storage unit 602. The storage unit 602 is realized, for example, by a memory device.

The user private key generation unit 601 executes the HIBE.KeyGen algorithm to generate and output a private key. The storage unit 602 stores various information (e.g., the user's own identifier ID _S , the private key corresponding to this user identifier ID _S , the user identifier ID _i managed by the user, time information, public parameters, etc.).

<Example 2-1>
In the following, an embodiment 2-1 will be described, which describes a case where, when a child terminal 30 _i,j of a user terminal group i is added or deleted, the decryption permission of the child terminal 30 _i,j is controlled.

The following describes the setup, user private key generation, device list update, device private key generation, encryption, and decryption processes in this embodiment.

<<Setup in Example 2-1>>
The setup in this embodiment is the same as in embodiment 1-1, so the description thereof will be omitted.

<<User Private Key Generation in Example 2-1>>
In response to a request from the identifier issuing server 60, the user private key generation unit 102 of the private key generation center 10 generates a private key sk _{ID_S} corresponding to the identifier ID _S of this identifier issuing server 60 and transmits it to the identifier issuing server 60. When transmitting the private key sk _{ID_S} to the identifier issuing server 60, it is desirable to establish a secure communication path using technology such as TLS. However, the method of transmitting the private key sk _{ID_S} is not limited to this.

Specifically, in response to a request from the identifier issuing server 60, the user private key generation unit 102 of the private key generation center 10 executes sk _{ID_S} ←HIBE.KeyGen(pp, msk, ID _S ) and transmits this private key sk _{ID_S} to the identifier issuing server 60. The private key sk _{ID_S} is stored in the storage unit 602 and managed in secret.

Next, the user private key generation unit 601 of the identifier issuing server 60 generates a private key sk _{ID_i} corresponding to the identifier ID _S and the user identifier ID _i managed by the identifier issuing server 60 itself, and transmits the private key sk _{ID_i} to the representative terminal 20 _i having the user identifier ID _i . Note that when transmitting the private key sk ID_i to the representative terminal 20 _i , it is desirable to establish a secure communication path using a technology such as TLS. However, the method of transmitting the private key sk _{ID_i} is not limited to this.

Specifically, the user private key generation unit 601 of the identifier issuing server 60 executes sk _{ID_i} ←HIBE.KeyGen(pp, sk _{ID_S} , (ID _S , ID _i )) and transmits this private key sk _{ID_i} to the representative terminal 20 _i . The private key sk _{ID_i} is stored in the storage unit 204 and managed in secret.

<Device List Update in Example 2-1>
The device list update in this embodiment is the same as in embodiment 1-1, and therefore the description thereof will be omitted.

<Device private key generation in Example 2-1>
The generation of the device private key in this embodiment is almost the same as in embodiment 1-1, but a hierarchical identifier of the form ID _i,τ = (ID _S , ID _i ,τ) is created first, and then the device private key dsk _{ID_i,τ} is generated. As the other points are the same as in embodiment 1-1, the description thereof will be omitted.

Encryption in Example 2-1
The encryption in this embodiment is almost the same as that in embodiment 1-1, but a hierarchical identifier of the form ID _{i, τ} = (ID _S , ID _i , τ) is created before generating the ciphertext C. Other points are the same as those in embodiment 1-1, and therefore the description thereof will be omitted.

Decryption in Example 2-1
Decryption in this embodiment is almost the same as in embodiment 1-1, but a hierarchical identifier of the form ID _{i, τ} = (ID _S , ID _i , τ) is created before decrypting the ciphertext C. Other points are the same as in embodiment 1-1, so a description thereof will be omitted.

Summary of Example 2-1
As described above, in this embodiment, there is an identifier issuing server 60 that manages the user identifier ID _i , and this identifier issuing server 60 generates the secret key sk _{ID_i} .

The relationship between the identifier and the private key during key generation in this embodiment is shown in Figure 10. As shown in Figure 10, the private key generation center 10 corresponds to the 0th layer, and generates a private key sk _{ID_S} corresponding to the identifier ID _S of the identifier issuing server 60 and distributes it to the identifier issuing server 60. The identifier issuing server 60 corresponds to the 1st layer, and generates a private key sk ID_i corresponding to the identifier ID _S of the identifier issuing server 60 and the user identifier ID _i of the representative terminal 20 _i and distributes it to the representative terminal 20 _i . The representative terminal 20 _i corresponds to the 2nd layer, and generates a private key sk _{ID_i ,τ} corresponding to the identifier ID _i,τ = (ID _S , ID _i , τ) and distributes it to its own child terminals 30 _i,j (however, the child terminals 30 _{i, j have the device identifier ID i,j} included in the device list List _i) . Each child terminal 30 _i,j corresponds to the 3rd layer.

<Example 2-2>
In the following, Example 2-2 will be described. In this example, in addition to Example 2-1, a case will be described in which, when a user identifier ID _i has expired, control is performed so that decryption cannot be performed at the representative terminal 20 _i and all child terminals 30 _{i, j} included in the user terminal group i.

The following describes the setup, user private key generation, device list update, device private key generation, encryption, and decryption processes in this embodiment.

<<Setup in Example 2-2>>
The setup in this embodiment is the same as in embodiment 2-1, so the description thereof will be omitted.

<<User Private Key Generation in Example 2-2>>
In response to a request from the identifier issuing server 60, the user private key generation unit 102 of the private key generation center 10 generates a private key sk _{ID_S} corresponding to the identifier ID _S of this identifier issuing server 60 and transmits it to the identifier issuing server 60. When transmitting the private key sk _{ID_S} to the identifier issuing server 60, it is desirable to establish a secure communication path using technology such as TLS. However, the method of transmitting the private key sk _{ID_S} is not limited to this.

Specifically, in response to a request from the identifier issuing server 60, the user private key generation unit 102 of the private key generation center 10 executes sk _{ID_S} ←HIBE.KeyGen(pp, msk, ID _S ) and transmits this private key sk _{ID_S} to the identifier issuing server 60. The private key sk _{ID_S} is stored in the storage unit 602 and managed in secret.

Next, the user private key generation unit 601 of the identifier issuing server 60 generates a private key sk ID_i,T corresponding to the identifier ID _S and a concatenated character string ID _{i ∥T of the user identifier ID i and} user update time T managed by the identifier issuing server 60, and transmits the private key sk _{ID_i,T} to the representative terminal 20 _i having the user identifier ID _i . Note that when transmitting the private key sk _{ID_i,T} to the representative terminal 20 _i , it is desirable to establish a secure communication path using a technology such as TLS. However, the method of transmitting the private key sk _{ID_i,T} is not limited to this.

Specifically, the user private key generation unit 601 of the identifier issuing server 60 executes sk _{ID_i,T} ←HIBE.KeyGen(pp, sk _{ID_S} , (ID _S , ID _i ∥T)) and transmits this private key sk _{ID_i,T} to the representative terminal 20 _i . The private key sk _{ID_i,T} is stored in the storage unit 204 and managed in secret.

When a user identifier ID _i′ is to be invalidated at a certain user update time T, the user private key generation unit 102 of the private key generation center 10 will not generate a private key sk _{ID_i′,T} ′ corresponding to the user identifier ID _i′ at a user update time T′ after T+ΔT.

<Device List Update in Example 2-2>
The device list update in this embodiment is the same as in embodiment 2-1, and therefore a description thereof will be omitted.

<Device private key generation in Example 2-2>
The device private key generation in this embodiment is almost the same as in embodiment 1-2, but a hierarchical identifier of the form ID _i,T,τ = (ID _S , ID _i ∥T,τ) is created, and then the device private key dsk _{ID_i,T,τ} is generated. As other points are the same as in embodiment 1-2, their explanation will be omitted.

Encryption in Example 2-2
The encryption in this embodiment is almost the same as in embodiment 1-2, but a hierarchical identifier of the form ID _i,T,τ = (ID _S , ID _i ∥T,τ) is created before generating the ciphertext C. As other points are the same as in embodiment 1-2, the description thereof will be omitted.

Decryption in Example 2-2
Decryption in this embodiment is almost the same as in embodiment 1-2, but a hierarchical identifier of the form ID _i,T,τ = (ID _S , ID _i ∥T,τ) is created before decrypting the ciphertext C. Other points are the same as in embodiment 1-2, so a description thereof will be omitted.

Summary of Example 2-2
As described above, in this embodiment, there is an identifier issuing server 60 that manages the user identifier ID _i , and this identifier issuing server 60 generates the private key sk _{ID_i,T} . This enables the identifier issuing server 60 to control whether or not decryption is permitted when the user identifier ID _i expires.

The relationship between the identifier and the private key during key generation in this embodiment is shown in Figure 11. As shown in Figure 11, the private key generation center 10 corresponds to the 0th layer, and generates a private key sk _{ID_S} corresponding to the identifier ID _S of the identifier issuing server 60 and distributes it to the identifier issuing server 60. The identifier issuing server 60 corresponds to the 1st layer, and generates a private key sk _{ID_i,T} corresponding to (ID _S , ID _i ∥T) and distributes it to the representative terminal 20 _i . The representative terminal 20 _i corresponds to the 2nd layer, and generates a private key sk _{ID_i,T,} τ corresponding to the identifier ID _i,T,τ = (ID _S , ID _i ∥T,τ) and distributes it to its own child terminal 30 _i,j (however, the child terminal 30 _i, j has the device identifier ID _i,j included in the device list List _i ). Each child terminal 30 _i,j corresponds to the 3rd layer.

<Hardware configuration>
The private key generation center 10, representative terminal 20 _i , child terminal 30 _i,j , time server 40, transmitting terminal 50, and identifier issuing server 60 in each of the above embodiments can be realized, for example, by the hardware configuration of a computer 900 shown in FIG. 12.

The computer 900 shown in FIG. 12 has an input device 901, a display device 902, an external I/F 903, a communication I/F 904, a processor 905, and a memory device 906. Each of these pieces of hardware is communicatively connected via a bus 907.

The input device 901 is, for example, a keyboard, mouse, touch panel, various physical buttons, etc. The display device 902 is, for example, a display, display panel, etc. However, the computer 900 does not necessarily have to have at least one of the input device 901 and the display device 902.

The external I/F 903 is an interface with external devices such as a recording medium 903a. Examples of recording media 903a 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.

The communication I/F 904 is an interface for connecting to a communication network such as the Internet. The processor 905 is, for example, a computing device such as a CPU. The memory device 906 is, for example, a storage device such as an HDD, SSD, flash memory, RAM, or ROM (Read Only Memory).

Note that the hardware configuration of the computer 900 shown in FIG. 12 is an example, and the computer may, for example, have multiple processors 905, multiple memory devices 906, or various other hardware components in addition to the hardware shown.

The present invention is not limited to the specifically disclosed embodiments above, and various modifications, alterations, and combinations with known technologies are possible without departing from the scope of the claims.

1: encryption system, 10: private key generation center (PKG), 20 _i : representative terminal, 30 _i,j : child terminal, 40: time server, 50: transmitting terminal, 60: identifier issuing server, 90: network, 101: setup processing unit, 102: user private key generation unit, 103: storage unit, 201 _i : device private key generation unit, 202 _i : decryption unit, 203 _i : list update unit, 204 _i : storage unit, 301 _i,j : decryption unit, 302 _i,j : Storage unit, 501: Encryption unit, 502: Storage unit, 601: User private key generation unit, 602: Storage unit, 900: Computer, 901: Input device, 902: Display device, 903: External I/F, 903a: Recording medium, 904: External I/F, 905: Processor, 906: Memory device, 907: Bus

Claims (7)

An encryption system including a private key generation center, one or more representative terminals, one or more slave terminals used by the same user as the representative terminal, and one or more transmitting terminals,
The private key generation center
a setup unit that generates public parameters of the hierarchical ID-based encryption and a master private key;
a first user private key generation unit that generates a user private key of the representative terminal using an identifier of the representative terminal, the master private key, and the public parameters;
The representative terminal is
a storage unit that stores a device list configured with identifiers of child terminals used by the same user as the user who uses the device;
a device private key generation unit that generates a device private key for decrypting an encrypted text transmitted from the transmitting terminal, using a user private key corresponding to its own identifier, a device update time indicating an update time of the device list, and the public parameters;
a first transmission unit that transmits the device private key to a child terminal represented by an identifier included in the device list,
The transmitting terminal
an encryption unit that generates a ciphertext by encrypting a message using the identifier of the representative terminal and the device update time;
a second transmission unit that transmits the ciphertext to the representative terminal or the child terminal;
A cryptosystem having: The first user private key generation unit
generating a user private key for the representative terminal using an identifier of the representative terminal, a user update time indicating an update time of the identifier of the representative terminal, the master private key, and the public parameters;
The device private key generation unit
generating the device private key using a user private key corresponding to its own identifier, the user update time, the device update time, and the public parameters;
The encryption unit
The cryptosystem according to claim 1 , wherein the ciphertext is generated using an identifier of the representative terminal, the user update time, and the device update time. The representative terminal is
3. The encryption system according to claim 1, further comprising an update unit that updates the device list at each device update time. The encryption system of claim 3, wherein updating the device list includes adding an identifier of a child terminal to the device list and deleting an identifier of a child terminal from the device list. the encryption system includes an identifier issuing server that issues and manages identifiers of the representative terminals,
The identifier issuing server
5. The cryptographic system according to claim 1, further comprising a second private key generation unit that generates a user private key of the representative terminal using the user's own user private key generated by the private key generation center, an identifier of a representative terminal managed by the user, and the public parameters. A terminal communicably connected to a secret key generation center that generates a user secret key by hierarchical ID-based encryption, one or more slave terminals used by the same user, and a transmitting terminal,
a storage unit that stores a device list configured with identifiers of the child terminals;
a device private key generation unit that generates a device private key for decrypting a ciphertext transmitted from the transmitting terminal, using a user private key corresponding to its own identifier, which is generated by the private key generation center, a device update time indicating an update time of the device list, and public parameters generated by the private key generation center;
a transmitter that transmits the device private key to a child terminal represented by an identifier included in the device list;
A terminal having: A method for use in an encryption system including a private key generation center, one or more representative terminals, one or more slave terminals used by the same user as the representative terminal, and one or more transmitting terminals, comprising:
The private key generation center
a setup procedure for generating public parameters and a master private key for hierarchical identity-based encryption;
executing a first user private key generation procedure for generating a user private key of the representative terminal using an identifier of the representative terminal, the master private key, and the public parameters;
The representative terminal
a storage step of storing, in a storage unit, a device list configured with identifiers of child terminals used by the same user as the user who uses the device itself;
a device private key generation step of generating a device private key for decrypting an encrypted text transmitted from the transmitting terminal, using a user private key corresponding to its own identifier, a device update time indicating an update time of the device list, and the public parameters;
a first transmission step of transmitting the device private key to a child terminal represented by an identifier included in the device list;
The transmitting terminal:
an encryption procedure for generating a ciphertext by encrypting a message using the identifier of the representative terminal and the device update time;
a second transmission procedure of transmitting the ciphertext to the representative terminal or the child terminal;
How to do it.