Key change management apparatus and key change management method

Information

  • Patent Grant
  • 9166781
  • Patent Number
    9,166,781
  • Date Filed
    Wednesday, June 26, 2013
    11 years ago
  • Date Issued
    Tuesday, October 20, 2015
    9 years ago
Abstract
According to one embodiment, an apparatus includes a permission/inhibition information storage which stores a permission/inhibition information file, a changer which changes a first encryption key of a first private key encrypted with the first public key to the second public key by using the first re-encryption key, a first storage which stores a second private key in a device private key temporary storage, a second storage which stores a second re-encryption key in a re-encryption key storage, a permission/inhibition information registration module which registers second permission/inhibition information in the permission/inhibition information file, and a transmitter which transmits the second private key in the re-encryption key storage to the second terminal.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2012-217913, filed Sep. 28, 2012, the entire contents of which are incorporated herein by reference.


FIELD

Embodiments described herein relate generally to a key change management apparatus and key change management method which perform encryption key change.


BACKGROUND

With the widespread use of mobile devices, there is an increasing need for the use of online storage services outside offices and homes.


In order to improve the security of content stored in an online storage, there is provided a technique of encrypting content in the online storage with a first public key and transmitting the content upon changing the encryption key from the first public key to a second public key allowing only a terminal from which a request has been received to decrypt the content.


When providing such an encryption service, it is sometimes necessary to use a special terminal to register, in a server which provides services, a new terminal which uses an online storage service. Therefore, there have been demands for a technique of registering a new terminal in a server from an arbitrary terminal which has already been registered.





BRIEF DESCRIPTION OF THE DRAWINGS

A general architecture that implements the various features of the embodiments will now be described with reference to the drawings. The drawings and the associated descriptions are provided to illustrate the embodiments and not to limit the scope of the invention.



FIG. 1 is an exemplary view schematically showing a file sharing system according to an embodiment.



FIG. 2 is an exemplary view schematically showing the arrangement of the file sharing system according to the embodiment.



FIG. 3 is an exemplary block diagram showing the arrangement of a key change management apparatus according to the embodiment.



FIG. 4 is an exemplary view showing the data structure of a re-encryption key database file.



FIG. 5 is an exemplary view showing the data structure of a key change permission/inhibition database file.



FIG. 6 is an exemplary view showing the data structure of a user private key database file.



FIG. 7 is an exemplary view showing the data structure of a device private key temporary registration database file.



FIG. 8 is an exemplary block diagram showing the arrangement of a terminal.



FIG. 9 is an exemplary view showing the data structure of a device private key database file.



FIG. 10 is an exemplary flowchart showing a procedure performed by a terminal A-1 and the key change management apparatus at the time of terminal addition processing.



FIG. 11 is an exemplary flowchart showing a procedure performed by a terminal A-2 and the key change management apparatus at the time of terminal addition processing.



FIG. 12 is an exemplary sequence chart for explaining a procedure for registering a new terminal.



FIG. 13 is an exemplary view showing a window displayed on the display screen of a terminal at the time of new terminal registration processing.



FIG. 14 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 15 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 16 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 17 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 18 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 19 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 20 is an exemplary view showing a window displayed on the display screen of the terminal at the time of new terminal registration processing.



FIG. 21 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 22 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 23 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 24 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 25 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 26 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 27 is an exemplary view showing a schematic representation of keys at the time of new terminal registration processing.



FIG. 28 is an exemplary block diagram used to explain new terminal registration processing.



FIG. 29 is an exemplary block diagram used to explain new terminal registration processing.



FIG. 30 is an exemplary block diagram used to explain new terminal registration processing.



FIG. 31 is an exemplary block diagram used to explain new terminal registration processing.



FIG. 32 is an exemplary block diagram used to explain new terminal registration processing.



FIG. 33 is an exemplary flowchart showing a procedure for terminal invalidation processing.



FIG. 34 is an exemplary view showing a device access management window displayed on the display screen of the management terminal at the time of terminal invalidation processing.



FIG. 35 is an exemplary block diagram used to explain terminal invalidation processing.



FIG. 36 is an exemplary flowchart showing a procedure for content acquisition processing.



FIG. 37 is an exemplary view showing a content window displayed on the display screen at the time of content acquisition.



FIG. 38 is an exemplary block diagram used to explain content acquisition processing.



FIG. 39 is an exemplary view schematically showing a case in which a terminal A-2 has issued a content acquisition request.



FIG. 40 is an exemplary flowchart showing a procedure for processing to be performed when a user private key is required.



FIG. 41 is an exemplary view schematically showing a case in which terminal A-2 has issued a request to acquire a user private key.





DETAILED DESCRIPTION

Various embodiments will be described hereinafter with reference to the accompanying drawings.


In general, according to one embodiment, a key change management apparatus includes a first storage, a changer, a second storage, a third storage, a storage controller, and a first transmitter. The first storage is configured to store first information indicating whether it is permitted to change an encryption key for encrypting a private key of a user from a public key of the user to a public key of a first device by using a first re-encryption key in accordance with a request from the first device, the first re-encryption key being generated by the first device based on a private key of the user and a public key of the first device. The changer is configured to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of the first device by using the first re-encryption key in accordance with the request from the first device when the first information indicates that it is permitted to change the encryption key for encrypting the private key from the public key of the user to the public key of the first device. The second storage is configured to store a private key of a second device transmitted from the first device wherein the first device generates the private key of the second device and a public key of the second device. The third storage is configured to store the first re-encryption key and a second re-encryption key, wherein the second re-encryption key is generated by the first device based on the private key of the user and the public key of the second device. The storage controller is configured to store, in the first storage, second information indicating whether it is permitted to change the encryption key for encrypting the private key of the user from the public key of the user to a public key of a second device by using the second re-encryption key in accordance with a request from the second device. The first transmitter is configured to transmit the private key of the second device in the second storage to the second device in accordance with a request from the second device.



FIG. 1 is a view schematically showing a file sharing system.


The file sharing system includes a cloud storage 10, a user private key storage module 103, a key change management apparatus 100, a terminal A-1_200A, and a terminal A-2_200B.


The cloud storage 10 stores content encrypted with user public keys. When a user A clicks an icon indicating content in a window (to be described later) displayed on terminal A-1_200A, the terminal transmits a data request to request for the return of the content to the key change management apparatus 100. The key change management apparatus 100 acquires the content encrypted with a user public key from the cloud storage 10.


The key change management apparatus 100 changes the encryption key of the content from the user public key pkU to a device public key pkDA1 of terminal A-1_200A by using a re-encryption key rkA1. The content whose encryption key has been changed is returned to terminal A-1_200A. Terminal A-1_200A decrypts the returned content with a device private key skDA1 of terminal A-1_200A.


Likewise, when the user A clicks an icon indicating content in a window (to be described later) displayed on terminal A-2_200B, terminal A-2_200B transmits a data request for the content to the key change management apparatus 100. The key change management apparatus 100 changes the encryption key of the content to the device public key pkDA2 of terminal A-2_200B. The content whose encryption key has been changed is returned to terminal A-2_200B. Terminal A-2_200B decrypts the returned content with a device private key skDA2 of terminal A-2_200B.


A terminal to which content is to be returned needs to be registered in the key change management apparatus 100 in advance. When registering a new terminal, a user private key is required to issue a re-encryption key. In general, a user private key is not stored in the terminal but is stored in the user private key storage module 103. A user private key skU is stored in the user private key storage module 103 while being encrypted with a user public key pkU.


Since terminals 200A and 200B each do not hold any key necessary to decrypt the user private key skU encrypted with the user public key pkU, it is not possible to acquire a key and register or a terminal unless the encryption key of the user private key skU is re-encrypted into a device public key.


Terminal addition processing, content return processing, and terminal invalidation processing will be sequentially described below.



FIG. 2 is a view schematically showing the arrangement of a file sharing system according to the embodiment.


As shown in FIG. 2, the file sharing system includes the cloud storage 10, a management terminal 20, the key change management apparatus 100, terminal A-1_200A, and terminal A-2_200B. The cloud storage 10 and the key change management apparatus 100 are connected to each other via a network. The management terminal 20, the key change management apparatus 100, terminal A-1_200A, and terminal A-2_200B are connected to each other via Internet 400. The management terminal 20 is the first terminal registered in the key change management apparatus 100.



FIG. 3 is a block diagram showing the arrangement of the key change management apparatus 100.


The key change management apparatus 100 includes a key change permission/inhibition information storage module 101, a re-encryption key storage module 102, the user private key storage module 103, a device private key temporary storage module 104, a terminal registration module 110, a key change permission/inhibition setting module 120, a key change determination module 130, a key change processing module 140, a user private key acquisition module 150, a device private key temporary registration module 160, and a device private key acquisition module 170.


The terminal registration module 110 includes a re-encryption key registration module 111 and a key change permission/inhibition information registration module 112. The re-encryption key registration module 111 registers a re-encryption key in a re-encryption key database file in the re-encryption key storage module 102. The key change permission/inhibition information registration module 112 registers a re-encryption key ID and key change permission/inhibition information indicating whether key change is permitted in a key change permission/inhibition database file in the key change permission/inhibition information storage module 101.



FIG. 4 is a view showing the data structure of a re-encryption key database file.


As shown in FIG. 4, user IDs, device IDs, and re-encryption keys are respectively associated with re-encryption key IDs.



FIG. 5 is a view showing the data structure of a key change permission/inhibition database file.


As shown in FIG. 5, key change permission/inhibition information is associated with each re-encryption key ID. For example, “Y” is associated as key change permission/inhibition information with the re-encryption key ID “1”. For example, “N” is associated as key change permission/inhibition information with the re-encryption key ID “2”. For example, “N” is associated as key change permission/inhibition information with the re-encryption key ID “3”. “Y” indicates that key change is permitted. “N” indicates that key change is inhibited.


The key change permission/inhibition setting module 120 includes a key change permission/inhibition information registration module 121. Upon issuance of an instruction to invalidate a terminal, the key change permission/inhibition setting module 120 transmits the received terminal invalidation instruction to the key change permission/inhibition information registration module 121. The key change permission/inhibition information registration module 121 sets a key change permission/inhibition field corresponding to terminal information to be invalidated which is stored in the key change permission/inhibition information storage module 101 to a value indicating invalidation.


The key change determination module 130 includes a key change permission/inhibition information acquisition module 131 and a key change permission/inhibition determination module 132.


Upon accepting a content acquisition request from the user, a network communication module 105 transmits the content acquisition request to the key change determination module 130. The key change permission/inhibition information acquisition module 131 acquires key change permission/inhibition information for a terminal from the key change permission/inhibition information storage module 101 and transmits the key change permission/inhibition information to the key change permission/inhibition determination module 132. The key change permission/inhibition determination module 132 determines based on the key change permission/inhibition information whether key change permission/inhibition is valid or invalid. If the determination result indicates that key change permission/inhibition is valid, the key change permission/inhibition determination module 132 transmits the information to the key change processing module 140. If the determination result indicates that key change permission/inhibition is invalid, the key change permission/inhibition determination module 132 transmits an error to the user. In this case, key change processing is not executed.


The key change processing module 140 includes a re-encryption key acquisition module 141, an encrypted content acquisition module 142, a re-encryption processing module 143, and a re-encrypted content return module 144.


The re-encryption key acquisition module 141 acquires a re-encryption key from the re-encryption key storage module 102 and transmits the re-encryption key to the encrypted content acquisition module 142. The encrypted content acquisition module 142 acquires the encrypted content requested from the user from the cloud storage 10, and transmits the acquired encrypted content to the re-encryption processing module 143. The re-encryption processing module 143 executes encryption processing for the encrypted content acquired by the encrypted content acquisition module 142 by using the re-encryption key acquired by the re-encryption key acquisition module 141. The re-encryption processing module 143 transmits the resultant content to the re-encrypted content return module 144. The re-encrypted content return module 144 returns the encrypted content to the user via the network communication module 105.



FIG. 6 is a view showing the data structure of a user private key database file stored in the user private key storage module 103.


As shown in FIG. 6, user IDs and user private keys are associated with user private key IDs.


The user private key acquisition module 150 includes a user private key acquisition module 151. The user private key acquisition module 151 acquires a user private key and stores it in the user private key storage module 103.


The device private key temporary registration module 160 includes a device private key temporary registration module 161. The device private key temporary registration module 161 acquires a device private key and registers the acquired device private key in a private key temporary registration database file in the device private key temporary storage module 104.



FIG. 7 is a view showing the data structure of a device private key temporary registration database file.


Referring to FIG. 7, device IDs and device private keys are respectively associated with device private key IDs.


The device private key acquisition module 170 includes a device private key acquisition module 171 and a device private key return module 172. The device private key acquisition module 171 acquires a device private key from the device private key temporary storage module 104 and deletes the device private key from the device private key temporary storage module 104. The device private key return module 172 returns the device private key acquired by the device private key acquisition module 171.



FIG. 8 is a block diagram showing the arrangement of a terminal 200.


As shown in FIG. 8, the terminal includes a re-encryption key generation module 210 and a device private key registration module 220.


The re-encryption key generation module 210 is used to register a new terminal. The re-encryption key generation module 210 generates a pair of a device private key and a device public key for a terminal to be newly registered. A decryption processing module 211 decrypts, with the device private key, the user private key acquired from the file sharing system and encrypted with the device public key. A re-encryption key generation module 212 generates a re-encryption key for a terminal to be newly added by using the user private key and the device public key for the terminal to be newly registered. The re-encryption key generation module 210 uploads the generated device private key and the re-encryption key for the terminal to be newly added to the system.


The device private key registration module 220 is used to register the self-terminal. A device private key acquisition module 221 acquires a device private key from the file sharing system. A device private key registration module 222 registers a device private key database file in a device private key storage module 201.



FIG. 9 is a view showing the data arrangement of a device private key database file. As shown in FIG. 9, a device private key is registered in the device private key database file.


A procedure for registering a new terminal in the file sharing system will be described below. The following is a case in which terminal A-1_200A has already been registered in the file sharing system, and terminal A-2_200B is newly registered in the file sharing system.


(New Terminal Addition Processing)



FIG. 10 is a flowchart showing a procedure performed by terminal A-1_200A and the key change management apparatus 100.


Terminal A-1_200A issues a request to register a new terminal to the key change management apparatus 100. Terminal A-1_200A executes user private key acquisition processing between itself and the key change management apparatus 100 to acquire a user private key. Terminal A-1_200A executes the re-encryption key generation processing of generating a re-encryption key rkA2 for terminal A-2_200B. Re-encryption key registration processing is executed between terminal A-1_200A and the key change management apparatus 100 to register the re-encryption key rkA2 for terminal A-2_200B in the key change management apparatus 100. Device private key temporary registration processing is executed between terminal A-1_200A and the key change management apparatus 100 to temporarily register the device private key skDA2 of terminal A-2_200B in the key change management apparatus 100. The key change management apparatus 100 notifies terminal A-1_200A of the end of the processing.



FIG. 11 is a flowchart showing a procedure performed by terminal A-2_200B and the file sharing system.


Terminal A-2_200B requests for the key change management apparatus 100 for the device private key skDA2 of terminal A-2_200B. Terminal A-2_200B executes device private key acquisition processing between itself and the key change management apparatus 100 to acquire the device private key skDA2 of terminal A-2_200B. The key change management apparatus 100 executes device private key deletion processing to delete the device private key skDA2 of terminal A-2_200B. Terminal A-2_200B executes device private key registration processing to register the device private key skDA2 in the device private key database file in the device private key storage module 201. Terminal A-2_200B notifies the end of the processing.



FIG. 12 is a sequence chart for explaining a procedure for registering a new terminal. FIGS. 13, 14, 15, 16, 17, 18, 19, and 20 are views each showing a window displayed on the display screen of a terminal at the time of new terminal registration processing. FIGS. 21, 22, 23, 24, 25, 26, and 27 are views each showing a schematic representation of keys at the time of new terminal registration processing. FIGS. 28, 29, 30, 31, and 32 are block diagrams each used to explain new terminal registration processing. A procedure for the processing of adding a new terminal will be described in more detail with reference to FIGS. 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, and 32.


After inputting a password to a password input field 601 on the sign in window shown in FIG. 13 which is displayed on the display screen of terminal A-1_200A, the user operates a connection button 602 to transmit authentication information such as a mail address, password, and terminal ID from terminal A-1_200A to the key change management apparatus 100. If authentication succeeds based on the authentication information, terminal A-1_200A signs in to the key change management apparatus 100. Since terminal A-1_200A has already been registered, the mail address as one piece of the authentication information is displayed.



FIG. 14 shows the top window displayed on the display screen of terminal A-1_200A after signing in. Operating a setting button 612 in the top window will display a setting window.



FIG. 15 shows the setting window displayed on the display screen of terminal A-1_200A.


When the user operates a “device control” item 621 in the setting window, a device control window is displayed.



FIG. 16 shows the device control window displayed on the display screen of terminal A-1_200A.


When the user operates an “add terminal” button 631 in the device control window, a device addition window is displayed. First of all, when the user A operates the “add terminal” button by using terminal A-1_200A, terminal A-1_200A issues a request to return a user private key to the file sharing system.



FIG. 17 is a view showing the device addition window displayed on the display screen of terminal A-1_200A. The device addition window displays the message “A key is generated for a new device. Connect the new device to the file sharing system. The key will be automatically deleted a few hours later.”


When the user connects terminal A-2_200B to the Internet 400 and activates the file sharing application, terminal A-2_200B displays the account input window shown in FIG. 18 on the display screen. As shown FIG. 18, the account input window is provided with a mail address input field 651, a password input field 652, and a connection button 653. When the user operates the connection button 653 after inputting information to the mail address input field 651 and the password input field 652, terminal A-2_200B transmits the authentication information including the mail address, password, and terminal ID to the key change management apparatus 100.


The processing in steps B32 and B33 will be described with reference to the block diagram of FIG. 28.


The network communication module 105 receives the authentication information transmitted from terminal A-1_200A. The network communication module 105 transmits the authentication information to the key change determination module 130. The key change permission/inhibition information acquisition module 131 acquires key change permission/inhibition corresponding to the terminal ID of terminal A-1_200A from the key change permission/inhibition information storage module 101. The key change permission/inhibition determination module 132 determines, based on the key change permission/inhibition, whether encryption key change is permitted. Upon determining that encryption key change is permitted, the key change permission/inhibition determination module 132 notifies the user private key acquisition module 150 of the corresponding information. The user private key acquisition module 151 acquires a user private key corresponding to a user of terminal A-1_200A from the user private key storage module 103. The user private key acquisition module 151 transmits the user private key to the key change processing module 140. The re-encryption key acquisition module 141 acquires a re-encryption key corresponding to terminal A-1_200A from the re-encryption key storage module 102. As shown in FIG. 21, the re-encryption processing module 143 changes the encryption key of the user private key skU from the user public key pkU to a device public key pKDA1 of terminal A-1_200A by using a re-encryption key rkDA1. As shown in FIG. 22, the re-encrypted content return module 144 in the key change management apparatus 100 returns the user private key skU re-encrypted by changed to the device public key pKDA1 to terminal A-1_200A by using the network communication module 105.


The processing in steps B34 to B36 will be described with reference to the flowchart of FIG. 29.


The decryption processing module 211 decrypts the user private key skU re-encrypted by the device public key pKDA1 by using a device private key sKDA1 of terminal A-1_200A, as shown in FIG. 23. The re-encryption key generation module 212 generates a device private key skDA2 and a device public key pkDA2 for terminal A-2_200B, as shown in FIG. 24. As shown in FIG. 25, the re-encryption key generation module 212 generates a re-encryption key rkA2 for terminal A-2_200B by using the user private key skU and the device public key pkDA2.


The processing in steps B37 to B40 will be described with reference to the block diagram of FIG. 30. As shown in FIG. 26, terminal A-1_200A transmits authentication information and the device private key skDA2 and the re-encryption key rkA2 for terminal A-2_200B to the key change management apparatus 100, and issues a request to register the device private key skDA2 and the re-encryption key rkA2. The network communication module 105 transmits the re-encryption key rkA2 to the terminal registration module 110, and transmits the device private key skDA2 to the device private key temporary registration module 160. The re-encryption key registration module 111 registers the re-encryption key rkA2 in a re-encryption key database file in the re-encryption key storage module 102. The key change permission/inhibition information registration module 112 registers information indicating that terminal A-2_200B can perform key change in a key change permission/inhibition database file in the key change permission/inhibition information storage module 101.


The device private key temporary registration module 161 registers the device private key skDA2 of terminal A-2_200B in a device private key temporary storage database file in the device private key temporary storage module 104. The key change management apparatus 100 notifies terminal A-1_200A of the completion of the processing. Terminal A-1_200A displays a message indicating the completion of the processing on the display screen.


Subsequently, processing is performed between terminal A-2_200B and the key change management apparatus 100.


Terminal A-2_200B transmits the authentication information including the mail address, password, and terminal ID input to the account input window shown in FIG. 18 to the key change management apparatus 100. If authentication succeeds based on the mail address and the password, terminal A-2_200B displays the initialization window shown in FIG. 19 on the display screen because the terminal ID is not registered in a key change permission/inhibition file in the key change permission/inhibition information storage module 101. This initialization window displays the messages “This terminal is not permitted to be connected.” and “Give approval from the file sharing application initialized on another of your devices.” When the user operates a YES button 661, terminal A-2_200B displays the device name input window shown in FIG. 20 on the display screen, if a device private key corresponding to terminal A-2_200B is registered in a device private key temporary storage database file in the device private key temporary storage module 104 and a re-encryption key database file in the re-encryption key storage module 102.


The processing in steps B41 to B43 will be described with reference to the block diagram of FIG. 31.


The device name input window displays a device number input field and a transmission button. When the user operates the transmission button after inputting a device name to the device name input field, terminal A-2_200B transmits the device name to the key change management apparatus 100, and transmits a request to acquire a device private key to the key change management apparatus 100.


The device private key acquisition module 171 acquires the device private key associated with the device ID of terminal A-2_200B registered in a device private key temporary storage database file in the device private key temporary storage module 104. As shown in FIG. 27, the device private key return module 172 returns the device private key skDA2 to terminal A-2_200B.


The processing in step B44 will be described with reference to the block diagram of FIG. 32.


The device private key acquisition module 221 of terminal A-2_200B acquires the returned device private key skDA2. The device private key registration module 222 of terminal A-2_200B registers the device private key skDA2 of terminal A-2_200B in a device private key database file in the device private key storage module 201.


The device private key registration module 220 of terminal A-2_200B notifies the key change management apparatus 100 of the completion of the processing. The device private key acquisition module 170 of the key change management apparatus 100 deletes the device private key of terminal A-2_200B from the device private key temporary storage database file in the device private key temporary storage module 104. Terminal A-2_200B displays a message indicating the completion of the processing on the display screen.


With the above processing, the terminal addition processing is terminated.


(Terminal Invalidation Processing)


A procedure for invalidating a terminal will be described next.



FIG. 33 is a flowchart showing a procedure for terminal invalidation processing. The following is a case in which, for example, the user has lost terminal A-2_200B, and terminal A-1_200A invalidates terminal A-2_200B. FIG. 34 is a view showing a device access management window displayed on the display screen of the management terminal 20 at the time of terminal invalidation processing. FIG. 35 is a block diagram used to explain terminal invalidation processing. Note that terminal invalidation processing is executed between the management terminal 20 and the key change management apparatus 100.


When the user operates a “device access management” button 632 in the device control window shown in FIG. 16, the display screen of the management terminal 20 displays the device access management window shown in FIG. 34. When the user operates a portion corresponding to the device name “terminal A-2_200B”, a deletion button 681 is displayed on the left side of the device name “terminal A-2_200B”. When the user operates the deletion button 681, the management terminal 20 transmits the authentication information of the management terminal 20 and a request to invalidate terminal A-2_200B as an invalidation request code for terminal A-2_200B to the key change management apparatus 100. The network communication module 105 transmits the invalidation request code to the key change permission/inhibition setting module 120. The key change permission/inhibition information registration module 121 makes the re-encryption key ID corresponding to the device ID and user ID in a key change permission/inhibition database file in the key change permission/inhibition information storage module 101 indicate the inhibition of key change. With the above processing, terminal A-2_200B is invalidated.


(Content Acquisition Processing)


A procedure for the processing of acquiring content from the file sharing system will be described next.



FIG. 36 is a flowchart showing a procedure for content acquisition processing. FIG. 37 is a view showing a content window displayed on the display screen at the time of content acquisition. FIG. 38 is a block diagram used to explain content acquisition processing.


When the user operates a home button 611 in the window shown in FIG. 14, the content window shown in FIG. 37 is displayed. As shown in FIG. 37, when the user operates an icon corresponding to content, the terminal issues a request to acquire the content to the key change management apparatus 100. The key change permission/inhibition information acquisition module 131 acquires a key change permission/inhibition database file from the key change permission/inhibition information storage module 101. The key change permission/inhibition determination module 132 determines whether the key change permission/inhibition associated with the re-encryption key ID corresponding to the device ID and the user ID indicates permission of key change. Upon determining that the key change permission/inhibition does not indicate permission of key change, the key change permission/inhibition determination module 132 notifies the terminal of an error.


Upon determining that the key change permission/inhibition indicates permission of key change, the key change permission/inhibition determination module 132 notifies the re-encryption key acquisition module 141 of permission of key change. The re-encryption key acquisition module 141 acquires a re-encryption key corresponding to the device ID and the user ID from a re-encryption key database file in the re-encryption key storage module 102. The encrypted content acquisition module 142 acquires content encrypted with the user public key from the cloud storage. The re-encryption processing module 143 changes the encryption key for the content to a device public key by using the re-encryption key. The re-encrypted content return module 144 returns the content whose encryption key has been changed to the terminal. The terminal decrypts the content by using the device private key.


If the finder of terminal A-2_200B issues a request for content to the key change management apparatus 100 after the invalidation of terminal A-2_200B, since the system has invalidated key change for terminal A-2_200B, the content is not re-encrypted, and an error is returned to terminal A-2_200B, as shown in FIG. 39. Terminal A-2_200B cannot refer to the content.


(User Private Key Request Processing)


A procedure for processing in a case in which a terminal issues a request for a user private key to the key change management apparatus 100 will be described. FIG. 40 is a flowchart showing a procedure for processing to be performed when a user private key is required.


The key change permission/inhibition determination module 132 determines whether key change permission/inhibition associated with a re-encryption key ID corresponding to a device ID and a user ID indicates the permission of key change. Upon determining that the key change permission/inhibition indicates inhibition of key change, the key change permission/inhibition determination module 132 notifies the terminal of an error.


Upon determining that the key change permission/inhibition indicates permission of key change, the key change permission/inhibition determination module 132 notifies the terminal of permission of key change. The re-encryption key acquisition module 141 acquires a re-encryption key corresponding to the device ID and the user ID from a re-encryption key database file in the re-encryption key storage module 102. The encrypted content acquisition module 142 acquires a user private key encrypted with the user public key from the user private key storage module 103. The re-encryption processing module 143 changes the encryption key of the user private key to the device public key by using the re-encryption key. The re-encrypted content return module 144 returns the user private key whose encryption key has been changed to the terminal. The terminal decrypts the user private key by using the device private key.


If the finder of terminal A-2_200B issues a terminal addition request after invalidation of terminal A-2_200B, the user private key skU is not re-encrypted, and an error is returned to terminal A-2_200B, as shown in FIG. 41. Terminal A-2_200B cannot acquire the user private key skU. Therefore, it is not possible to add any terminal from terminal A-2_200B.


As described above, the key change management apparatus includes a first storage, a changer, a second storage, a third storage, a storage controller, and a first transmitter. The first storage is configured to store first information indicating whether it is permitted to change an encryption key for encrypting a private key of a user from a public key of the user to a public key of a first device by using a first re-encryption key in accordance with a request from the first device, the first re-encryption key being generated by the first device based on a private key of the user and a public key of the first device. The changer is configured to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of the first device by using the first re-encryption key in accordance with the request from the first device when the first information indicates that it is permitted to change the encryption key for encrypting the private key from the public key of the user to the public key of the first device. The second storage is configured to store a private key of a second device transmitted from the first device wherein the first device generates the private key of the second device and a public key of the second device. The third storage is configured to store the first re-encryption key and a second re-encryption key, wherein the second re-encryption key is generated by the first device based on the private key of the user and the public key of the second device. The storage controller is configured to store, in the first storage, second information indicating whether it is permitted to change the encryption key for encrypting the private key of the user from the public key of the user to a public key of a second device by using the second re-encryption key in accordance with a request from the second device. The first transmitter is configured to transmit the private key of the second device in the second storage to the second device in accordance with a request from the second device. Thus, it is possible to register or add a new terminal (the second terminal) from an arbitrary terminal (the first terminal) which has already been registered.


According to this embodiment, a user private key for issuing a re-encryption key is encrypted with a user public key and held on the server side. Since a user private key required for decryption does not exist in any terminal, it is not possible to acquire a key unless the key change management apparatus performs re-encryption.


According to the embodiments, the user can validate/invalidate his/her own terminal on a “terminal” basis. This makes it possible to implement flexible terminal management, for example, inhibiting a lost terminal from only accessing the key change management apparatus 100 while permitting the use of other terminals. Inhibiting the use of a re-encryption key can invalidate the acquisition of a user private key from a lost terminal. Since no valid user private key is left on a terminal, it is not possible to perform terminal addition. This improve the security.


The new terminal addition processing, terminal invalidation processing, content acquisition processing, and user private key request processing, and the like in the embodiments can be implemented by computer programs. It is therefore possible to easily achieve the same effects as those of the embodiments by only installing the computer programs in a general computer via a computer-readable storage medium storing the computer programs and executing them.


The various modules of the systems described herein can be implemented as software applications, hardware and/or software modules, or components on one or more computers, such as servers. While the various modules are illustrated separately, they may share some or all of the same underlying logic or code.


While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel embodiments described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the embodiments described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.

Claims
  • 1. A key change management apparatus comprising: a first storage configured to store a first information indicating whether a changer is permitted to change an encryption key for encrypting a private key of a user from a public key of the user to a public key of a first device by using a first re-encryption key in accordance with a request from the first device, wherein the first device generates the first re-encryption key based on a private key of the user and a public key of the first device and transmits the first re-encryption key to the key change management apparatus;the changer configured to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of the first device by using the first re-encryption key in accordance with the request from the first device when the first information indicates that the changer is permitted to change the encryption key for encrypting the private key from the public key of the user to the public key of the first device;a second storage configured to store a private key of a second device, wherein the first device generates the private key of the second device and a public key of the second device and transmits the private key of the second device to the key change management apparatus;a third storage configured to store the first re-encryption key and a second re-encryption key, wherein the first device generates the second re-encryption key based on the private key of the user and the public key of the second device and transmits the second re-encryption key to the key change management apparatus;a storage controller configured to store, in the first storage, second information indicating whether the changer is permitted to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of a second device by using the second re-encryption key in accordance with a request from the second device; anda first transmitter configured to transmit the private key of the second device in the second storage to the second device in accordance with a request from the second device.
  • 2. The apparatus of claim 1, further comprising a deletion module configured to delete the private key of the second device in the second storage.
  • 3. The apparatus of claim 2, further comprising: a first determination module configured to determine, based on the first information or second information, whether the changer is permitted to change the encryption key of the private key of the user, when the first device or the second device issues a request to transmit content that is encrypted by the encryption key; anda second transmission module configured to transmit, to the first device or the second device, the content whose encryption key is changed by the change module to the public key of the first device or the public key of the second device by using the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 4. The apparatus of claim 2, further comprising: a second determination module configured to determine, based on the first information or the second information, whether the changer is permitted to change the encryption key of the private key of the user;a third transmission module configured to transmit, to the first device or and the second device, the private key of the user whose encryption key is changed by the change module to the public key of the first device or the public key of the second device by using the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 5. The apparatus of claim 1, further comprising a second changer configured to change the first information or the second information in accordance with a request from a management terminal.
  • 6. A key change management method comprising: storing, in a first storage, first information indicating whether a changer is permitted to change an encryption key for encrypting a private key of a user from a public key of the user to a public key of a first device by using a first re-encryption key;changing the encryption key for encrypting the first private key of the user from a public key of the user to the public key of the first device by using the first re-encryption key, in accordance with a request from the first device when the first information indicates that the changer is permitted to change the encryption key for encrypting the private key, wherein the first device generates the first re-encryption key based on a private key of the user and a public key of the first device and transmits the first re-encryption key to the key change management apparatus;storing, in a second storage, a private key of a second device, wherein the first device generates the private key of the second device and a public key of the second device and transmits the private key of the second device to the key change management apparatus;storing, in a third storage, a second re-encryption key, wherein the first device generates the second re-encryption key based on the private key of the user and the public key of the second device;transmitting the second re-encryption key to the key change management apparatus;storing, in the first storage, second information indicating whether the changer is permitted to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of the second device by using the second re-encryption key in accordance with a request from the second device; andtransmitting the private key of the second device stored in the second storage to the second device in accordance with a request from the second device.
  • 7. The method of claim 6, further comprising deleting the private key of the second device stored in the second storage.
  • 8. The method of claim 7, further comprising: determining, based on the first information or second information, whether it is permitted to change an encryption key, when one of the first terminal and the second terminal issues a request to transmit content; andtransmitting, to one of the first device or the second device, the content whose encryption key is changed to one of the public key of the first device or the public key of the second device by using one of the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 9. The method of claim 7, further comprising: determining, based on the first information or second information, whether the changer is permitted to change the encryption key of the private key of the user, when one of the first device or the second device issues a request to transmit the private key of the user; andtransmitting, to one of the first device or the second device, the private key of the user whose encryption key is changed to one of the public key of the first device or the public key of the second device by using one of the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 10. The method of claim 6, further comprising: changing the first information in accordance with a request from a management device; andchanging the second information in accordance with a request from the management device.
  • 11. A computer-readable, non-transitory storage medium configured to store a computer program which is executable by a computer, the computer program controlling the computer to execute functions of: storing, in a first storage, first information indicating whether a changer is permitted to change an encryption key for encrypting a private key of a user from a public key of the user to a public key of a first device by using a first re-encryption key;changing an encryption key for encrypting the first private key of the user from the public key of the user to the public key of the first device by using the first re-encryption key, in accordance with a request from the first device, wherein the first device generates the first re-encryption key based on a private key of the user and a public key of the first device and transmits the first re-encryption key to the key change management apparatus;storing, in a second storage, a private key of a second device, wherein the first device generates the private key of the second device and a public key of the second device and transmits the private key of the second device to the key change management apparatus;storing, in a third storage, a second re-encryption key, wherein the first device generates the second re-encryption key based on the private key of the user and the public key of the second device;transmitting the second re-encryption key to the key change management apparatus;storing, in the first storage, second information indicating whether the changer is permitted to change the encryption key for encrypting the private key of the user from the public key of the user to the public key of a second device by using the second re-encryption key in accordance with a request from the second device; andtransmitting the private key of the second device stored in the second storage to the second device in accordance with a request from the second device.
  • 12. The medium of claim 11, wherein the computer program further controls the computer to execute functions of deleting the private key of the second device stored in the second storage.
  • 13. The medium of claim 12, wherein the computer program further controls the computer to execute functions of: determining, based on the first information or second information, whether it is permitted to change an encryption key, when one of the first terminal and the second terminal issues a request to transmit content; andtransmitting, to one of the first device or the second device, the content whose encryption key is changed to one of the public key of the first device or the public key of the second device by using one of the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 14. The medium of claim 12, wherein the computer program further controls the computer to execute functions of: determining, based on the first information or second information, whether the changer is permitted to change the encryption key of the private key of the user, when one of the first device or the second device issues a request to transmit the private key of the user; andtransmitting, to one of the first device or the second device, the private key of the user whose encryption key is changed to one of the public key of the first device or the public key of the second device by using one of the first re-encryption key or the second re-encryption key, when the first information or the second information indicates that the changer is permitted to change the encryption key.
  • 15. The medium of claim 11, wherein the computer program further controls the computer to execute functions of: changing the first information in accordance with request from a management device; andchanging the second information in accordance with a request from the management device.
Priority Claims (1)
Number Date Country Kind
2012-217913 Sep 2012 JP national
US Referenced Citations (9)
Number Name Date Kind
6792113 Ansell et al. Sep 2004 B1
7603563 Ansell et al. Oct 2009 B2
20050033974 Ansell et al. Feb 2005 A1
20060161750 Perkins et al. Jul 2006 A1
20060236405 Terauchi et al. Oct 2006 A1
20080294908 Yamaguchi et al. Nov 2008 A1
20090063861 Chu Mar 2009 A1
20140050318 Hayashi et al. Feb 2014 A1
20140161251 Yoshida et al. Jun 2014 A1
Foreign Referenced Citations (7)
Number Date Country
2003-518351 Jun 2003 JP
2004-312717 Nov 2004 JP
2005-303370 Oct 2005 JP
2006-301887 Nov 2006 JP
2012-044577 Mar 2012 JP
WO 2006011527 Feb 2006 WO
WO 2012111713 Aug 2012 WO
Non-Patent Literature Citations (1)
Entry
Japanese Patent Application No. 2012-217913, Office Action, mailed Jan. 6, 2015, (with English Translation).
Related Publications (1)
Number Date Country
20140095878 A1 Apr 2014 US