WO2016171271A1 - Système de base de données chiffrée et procédé de gestion de données chiffrées - Google Patents

Système de base de données chiffrée et procédé de gestion de données chiffrées Download PDF

Info

Publication number
WO2016171271A1
WO2016171271A1 PCT/JP2016/062826 JP2016062826W WO2016171271A1 WO 2016171271 A1 WO2016171271 A1 WO 2016171271A1 JP 2016062826 W JP2016062826 W JP 2016062826W WO 2016171271 A1 WO2016171271 A1 WO 2016171271A1
Authority
WO
WIPO (PCT)
Prior art keywords
encrypted
database
unit
data
sql
Prior art date
Application number
PCT/JP2016/062826
Other languages
English (en)
Japanese (ja)
Inventor
啓成 藤原
小島　剛
雅之 吉野
佐藤　嘉則
鈴木　貴之
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Publication of WO2016171271A1 publication Critical patent/WO2016171271A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules

Definitions

  • the present invention relates to a concealment database system that encrypts data and deposits it with others.
  • a concealment database system that makes it impossible to restore data on the cloud by having only the hospital side have the data concealment key and reduces the risk of data export on the cloud side. Is effective. Furthermore, it is effective to enable search and analysis without decrypting the data at the data center by using a searchable encryption technique or the like that enables search of the data as encrypted.
  • Patent Document 1 is a user system connected to a database system via a network, and stores means for managing key information for encryption and decryption, and data and / or metadata safety setting information To determine whether or not encryption is required for the storage unit and the database operation instruction, and if encryption is necessary, the database is selected after encryption is selected according to the data and / or metadata. When the database operation is performed by transmitting to the control means, and encryption is not required, the database operation instruction is transmitted to the database control means to execute the database operation, and the processing result transmitted from the database control means is received.
  • an application response means returns the response of the database operation instruction, the system comprising a safety setting means for setting the security information of the data stored in the database is disclosed.
  • Patent Document 2 discloses a searchable cryptographic processing system in which a DB server that deposits data, a registration client that deposits data in the DB server, and a search client that causes the DB server to retrieve data are linked via a network,
  • the registration client deposits the encrypted data to the server using a probabilistic encryption method with a mask using a hash value and a homomorphic function, and the search client uses a homomorphic function to encrypt the search query.
  • a system that uses probabilistic encryption with a mask causes the DB server to release the mask, and causes the DB server to output search queries and non-corresponding data as search results so that the frequency of appearance of the data corresponding to the search does not leak Is disclosed.
  • a database index function as one of the means of high-speed search of large-capacity data in a normal database.
  • the index function has a data structure corresponding to an index for a specific column, thereby enabling a high-speed search by narrowing down the search target range.
  • an ordinary database index function may not be effective in retrieving encrypted data. In that case, a large amount of data cannot be searched at high speed.
  • the prior art does not disclose means for enabling high-speed retrieval of a large amount of data in an encrypted database in which the normal index function is not effective.
  • the normal database index function may or may not be effective depending on the appearance frequency of the attribute value to be searched. For example, a certain database product automatically determines whether or not to use an index depending on whether or not the frequency of attribute values to be searched exceeds a certain ratio with respect to the number of attribute values of the attribute. However, if the data is encrypted so that the frequency distribution is not known, the cloud side cannot determine whether or not to use the index based on the frequency distribution.
  • the present invention has been made in consideration of the above points, and proposes a concealment database system that enables high-speed retrieval of a large amount of encrypted data.
  • a typical example of the invention disclosed in the present application is as follows. That is, a concealment database system configured by a center system in which encrypted data obtained by encrypting original data owned by a user system with an encryption key managed by a data owner is deposited, and the center system includes the depository data A function of retrieving the encrypted data without decrypting the original data into the original data, wherein the user system uses a plain SQL sentence for processing the encrypted data, and the encrypted data as the encrypted data.
  • a database wrapper unit that converts the encrypted SQL text received from the center system into a encrypted SQL sentence to be processed on the center system, and the center system stores the encrypted data
  • the encrypted deposit data table and the encrypted hash value obtained by encrypting the hash value of the original data are stored.
  • a ciphertext match comparison unit that determines a match with a query, and the database wrapper unit processes a plaintext SQL sentence for searching the encrypted data, and processes the encrypted data on the center system.
  • the encrypted data is converted to an encrypted SQL sentence and the encrypted SQL sentence received by the center system is executed, whereby the database control unit searches the hash table to limit the range of the encrypted data, and A sentence match comparison unit performs a match comparison indicated by the encrypted SQL sentence for the limited range of encrypted data, and The database control unit transmits the execution result of the encrypted SQL statement to the user system, and the database wrapper unit decrypts the execution result of the SQL statement received from the database control unit, and displays the search result of the encrypted data. Output.
  • FIG. 1 shows a hardware and software configuration of a concealment database system 1 according to the first embodiment of the present invention. It is a block diagram.
  • the concealment database system 1 encrypts the original data possessed by the user system side server 3 and deposits it in the cloud system side server 4. Further, the cloud system side server 4 has a search function and an analysis function for the deposited data. This is a system provided to the system-side server 3.
  • the concealment database system 1 includes a user terminal 2, a user system side server 3, and a cloud system side server 4, as shown in FIG.
  • the user terminal 2 and the user system side server 3 are connected via a user internal network 5 including a local area network in the user's office.
  • the user system side server 3 and the cloud system side server 4 include a user internal network 5, an external network 6 including a wide area network provided by the Internet or a carrier, and a local area network in a data center of a cloud provider. Connected via the internal network 7.
  • the user terminal 2 is a device such as a personal computer, a tablet terminal, or a smartphone used by an end user, and includes a display device, an input device, a nonvolatile storage device (magnetic disk drive, SSD), a memory, a CPU, a network interface, and the like. .
  • the user terminal 2 transmits the request input from the input device by the end user to the application unit 211 of the user system side server 3 in plain text, receives the result for the request, displays the result on the display device, Memorize the results in the fusogenic memory.
  • the user system side server 3 is a computer having a memory 210, a display device 220, an input device 230, a CPU 240, a network interface device (NIC) 250, a disk device 260, and the like.
  • the server 3 on the user system side generates a ciphertext SQL from the request for plaintext received from the user terminal 2, sends it to the cloud system side server 4, receives the result of the ciphertext for the SQL text, Decrypt and send the plaintext result to the user terminal 2.
  • the application unit 211 is configured by the CPU 240 reading an application program to the memory 210 via the disk device 260, the external storage medium, or the user internal network 5, and executing the application program read by the CPU 240.
  • the application unit 211 processes the plaintext request received from the user terminal 2, transmits a plaintext SQL sentence necessary in the course of processing to the database wrapper unit 212, and receives a plaintext result for the SQL sentence.
  • the database wrapper unit 212 is configured by the CPU 240 reading a program to the memory 210 via the disk device 260, an external medium, or the user internal network 5, and executing the program read by the CPU 240.
  • the database wrapper unit 212 converts the plain text SQL received from the application unit 211 into cipher text SQL using information in the secret index map table 262 of the disk device 260, and transmits the cipher text SQL to the database interface unit 213. Further, the result of the ciphertext for the SQL text is received from the database interface unit 213, decrypted into plaintext, and the plaintext result is transmitted to the application unit 211.
  • the database interface unit 213 is configured by the CPU 240 reading a program to the memory 210 via the disk device 260, an external medium, or the user internal network 5, and executing the program read by the CPU 240.
  • the database interface unit 213 transmits the SQL of the ciphertext received from the database wrapper unit 212 to the cloud system side server 4, receives the result of the ciphertext from the cloud system side server 4, and transmits it to the database wrapper unit 212.
  • the disk device 260 is composed of a nonvolatile storage device such as a hard disk drive or a solid state drive, and stores a main table 261 and a secret index map table 262.
  • the main table 261 stores plaintext information before depositing to the cloud system side server 4.
  • the secret index map table 262 stores related information for accessing the information in the encryption main table 361 on the cloud system server 4 at high speed.
  • the cloud system side server 4 includes a computer including a memory 310, a display device 320, an input device 330, a CPU 340, a network interface device (NIC) 350, a disk device 360, and the like. .
  • the cloud system side server 4 executes SQL of the ciphertext received from the user system side server 3 and transmits the obtained ciphertext execution result to the user system side server 3.
  • the database control unit 311 is configured by the CPU 340 reading the program to the memory 310 via the disk device 360, the external medium or the cloud internal network 7, and the CPU 340 executing the read program.
  • the database control unit 311 receives the ciphertext SQL from the user system side server 3, and uses the information in the hash table 362 and the function of the user definition function unit 312 to send the ciphertext SQL to the encryption main table 361. Then, the result of the obtained ciphertext is transmitted to the server 3 on the user system side.
  • the user-defined function unit 312 is configured by the CPU 340 reading the program to the memory 310 via the disk device 360, the external medium, or the cloud internal network 7, and the CPU 340 executing the read program.
  • the user-defined function unit 312 receives input information to the user-defined function from the database control unit 311, executes processing by the user-defined function that determines whether the original plaintexts of different ciphertexts match, and the processing result Is output to the database control unit 311.
  • the disk device 360 includes a nonvolatile storage device such as a hard disk drive or a solid state drive, and stores an encrypted main table 361 and a hash table 362.
  • the encrypted main table 361 encrypts and stores the main table 261.
  • the hash table 362 stores information for speeding up access to the encrypted main table 361.
  • FIG. 2 shows a logical configuration of the database wrapper unit 212.
  • the database wrapper unit 212 includes an encryption unit 2121, a search query generation unit 2122, a decryption unit 2124, a key management unit 2125, an SQL conversion unit 2126, and a secret index SQL conversion unit 2127.
  • the encryption unit 2121 receives the encryption key acquired from the plaintext and key management unit 2125, converts the input plaintext into ciphertext, and outputs the ciphertext.
  • the search query generation unit 2122 generates a search query necessary for a match search between the encrypted data stored in the encryption main table 361 and the search data. That is, the search query generation unit 2122 receives the plaintext search data and the encryption key and search key acquired from the key management unit 2125 as input, and identifies the encrypted data in the encryption main table 361 that matches the search data. An encrypted search query serving as input information is generated and an encrypted search query is output.
  • the hash value generation unit 2123 receives the hash length specifying the plaintext data and the number of types of hash values to be generated, acquires the plaintext hash value obtained by processing the plaintext data with the hash function, and outputs the plaintext hash value.
  • the decryption unit 2124 receives the encryption key acquired from the ciphertext and key management unit 2125, converts the input ciphertext into plaintext, and outputs the plaintext.
  • the key management unit 2125 manages key information used for encryption, decryption, and search query generation. That is, the key management unit 2125 stores the encryption key data and the search key data in the memory 210 and / or the disk device 260, and requests the key from the encryption unit 2121, the search query generation unit 2122, or the decryption unit 2124. In contrast, encryption key data or search key data is provided. Note that both encryption key data and search key data may be provided.
  • the SQL conversion unit 2126 creates SQL that performs processing only on the encrypted main table 361. That is, the SQL conversion unit 2126 receives the plain text SQL, replaces the search data with the encrypted search query, replaces the plain text data to be inserted or updated with the cipher text data, and replaces the match comparison text with the cipher text of the user definition function unit 312. An encrypted SQL statement replaced with a user-defined function call statement that calls the match comparison unit 3121 is generated. Then, the encrypted SQL sentence is transmitted to the database interface unit 213.
  • the secret index SQL conversion unit 2127 performs processing on the encryption main table 361 and the hash table 362. That is, the secret index SQL conversion unit 2127 receives plain text SQL, replaces the search data with an encrypted search query, and generates a hash value from the search data. Then, the generated hash value is replaced with an encrypted search query, the plaintext data to be inserted or updated is replaced with ciphertext data, and a plaintext hash value is generated from the plaintext data to be inserted or updated. Then, the generated plaintext hash value is replaced with a ciphertext hash value, and an encrypted SQL sentence that performs at least one of reference, insertion, update, and deletion on the hash table 362 and the encryption main table 361 is generated. Then, the encrypted SQL sentence is transmitted to the database interface unit 213.
  • FIG. 3 shows a logical configuration of the user-defined function unit 312.
  • the user definition function unit 312 includes a ciphertext match comparison unit 3121.
  • the ciphertext match comparison unit 3121 stores the search key data in the memory 310 and / or the disk device 360, receives the input of the encrypted search query and the ciphertext data from the database control unit 311, and encrypts using the search key
  • the encrypted search query is decrypted into a match search query that can be compared with the ciphertext data, and the match search query is compared with the encrypted data.
  • a value indicating the match for example, “1”
  • the value indicating the mismatch for example, "0" is output.
  • FIG. 4 shows a data structure of the main table 261 indicating plain text data before being encrypted and deposited.
  • the main table 261 is stored in the disk device 260 or the memory 210 of the user system side server 3.
  • the main table 261 may be stored in both the disk device 260 and the memory 210.
  • the table is hospital data
  • the schema name is “medical information”
  • the table name is “patient information”.
  • the main table 261 includes a “patient number” column that is a number that uniquely identifies a patient, a “name” column that is the name of the patient, and a “disease name” column that indicates the type of disease of the patient.
  • the record 2611 indicates that the name of the patient whose patient number is “0000001” is “Suzuki” and the disease name is “hypertension”.
  • the main table 261 stores 1 million records from patient numbers “0000001” to “1000000”.
  • FIG. 5 shows the data structure of the secret index map table 262 that stores information that associates the hash table 362 that speeds up the search with the map ID column of the encrypted main table 361.
  • the secret index map table 262 is stored in the disk device 260 or the memory 210 of the user system side server 3.
  • the secret index map table 262 may be stored in both the disk device 260 and the memory 210.
  • hospital data is assumed, and the secret index map table 262 indicates that the “schema name” column for classifying hospital table types includes “medical information” or “management information”. Show.
  • the “encrypted main table name” column indicating the name of each table indicates that a “patient information” table, a “drug information” table, a “medicine information” table, a “medical accounting” table, and the like exist.
  • the column “column name” indicates that the hash table 362 corresponding to the column exists, and that the encryption main table 361 includes a “map ID name” column indicating the relationship with the hash table 362.
  • the “map ID column name” column and the “hash table name” relate to the map ID column name such as the “MapID-1” column included in the encryption main table 361 and the hash table 362 such as the hash table 362 (HT1). Indicates.
  • the hash table 362 is not generated for a column whose search is not accelerated even if it is indexed. Specifically, it is not necessary to generate a column having a distribution of column attribute values in which the same attribute value occupies most.
  • the “column name” having the related map ID column and the hash table is “disease name”, and the related “map ID column name” is “ MapID-1 ”, indicating that the associated“ hash table name ”is“ HT1 ”.
  • FIG. 6 shows the data structure of the encrypted main table 361 for storing the ciphertext data of the main table 261 deposited by the cloud system side server 4.
  • the encryption main table 361 is stored in the disk device 360 or the memory 310 of the cloud system side server 4. Note that the encryption main table 361 may be stored in both the disk device 360 and the memory 310.
  • the encrypted main table 361 includes a “patient number” column, a “name” column, and a “disease name” column included in the main table 261. Furthermore, a record is configured by an “ID” column that is an identifier for uniquely specifying each record in the encryption main table 361 and a “MapID-1” column that is information related to the hash table (HT1) 362.
  • the encrypted patient number is “Enc (0000001)”
  • the encrypted name is “Enc (Kojima)”
  • the encrypted disease name is “Enc (hypertension)”
  • the identifier of the record Is “1” and the value of MapID-1 indicating the association with the hash table 362 is “1”.
  • “Enc ()” indicates that the plaintext data in “()” is a ciphertext encrypted by the encryption unit 2121.
  • the normal index function of the database control unit 311 is applied to the “ID” column and the “MapID-1” column.
  • FIG. 7 shows the data structure of the hash table 362 used for speeding up the search.
  • the hash table 362 is stored in the disk device 360 or the memory 310 of the cloud system side server 4.
  • the hash table 362 may be stored in the disk device 360 and the memory 310 of the cloud system side server 4.
  • the record of the hash table 362 includes the “MapID” column indicating the correspondence information with the “MapID-1” column of the encryption main table 361, and the plaintext hash value obtained by converting the plaintext data by the hash value generation unit 2123 into the encryption unit 2121. Is composed of an “encrypted hash value” column indicating an encrypted value.
  • the value of the “MapID” column is equal to the value of “MapID-1” of one or more records in the main table 261. Therefore, by designating “MapID”, the search range can be limited without searching all records in the encrypted main table 361.
  • FIG. 8 Flow of processing related to search of concealment database Using FIG. 8, FIG. 9 and FIG. 10, in the concealment database system 1, a concealment index search that is a search using the hash table 362 is performed. Details of a series of processing performed by the database wrapper unit 212 and the database control unit 311 will be described.
  • FIG. 8 is a flowchart showing a secret index search query generation process executed by the database wrapper unit 212 in the user system side server 3.
  • the secret index search query generation process starts when the database wrapper unit 212 receives a plain text search SQL from the application unit 211.
  • the SQL received by the database wrapper unit 212 at the start of the secret index search query generation process is the following plaintext search SQL (1).
  • Patient Information WHERE Disease Name Diabetes (1)
  • This search SQL searches a record whose schema name is “medical information” and whose table name is “patient information” and whose value of the “disease name” column is “diabetes”, and sets all the column values. It means that it is obtained as a search result (step 810).
  • the database wrapper unit 212 acquires “map ID column name” and “hash table name” of the search target column from the secret index map table 262. Specifically, the database wrapper unit 212 searches the secret index map table 262 using the combination of the schema name, the encryption main table name, and the column name that are to be searched by the plaintext search SQL as a key. The “map ID column name” and “hash table name” of the record having the same main table name and column name are acquired. For example, when the plain text search SQL is (1), from the record 2621 where the schema name is “medical information”, the encrypted main table name is “patient information”, and the column name is “disease name”. The map ID column name “MapID-1” and the hash table name “HT1” are acquired (step 830).
  • step 840 the database wrapper unit 212 determines whether or not the result of step 830 exists (step 840).
  • step 840 the database wrapper unit 212 performs a search SQL conversion process that does not use the hash table 362. Specifically, the database wrapper unit 212 replaces the plaintext SQL search target value with the encrypted search query generated in step 820, and further matches the WHERE clause match comparison statement with the ciphertext of the user definition function unit 312.
  • the ciphertext search SQL replaced with the format for calling the match comparison unit 3121 is output. For example, when the plaintext SQL is (1) and the encrypted search query is (2), the following ciphertext search SQL (3) is output (step 850).
  • Patient information WHERE Ciphertext match comparison unit (disease name, encrypted search query (diabetes)) (3)
  • step 840 the database wrapper unit 212 performs the secret index search SQL conversion (step 860-) from the hash value generation in order to perform a high-speed search using the hash table 362.
  • the ciphertext search SQL for which the processing of 880) is performed is output.
  • the database wrapper unit 212 inputs the hash value acquired in step 860 to the search query generation unit 2122, and uses the output as a hash table search query.
  • the database wrapper unit 212 first searches the hash table 362 to limit the search range, and then performs a secret index search SQL conversion that generates an SQL for searching the encrypted main table 361. Specifically, the encrypted search query obtained in step 820, the map ID column name and hash table name obtained in step 830, and the hash table search query obtained in step 870 are input, and the hash table 362 is hashed. The value of the “MapID” column of the corresponding record is acquired by searching with a table search query. Then, a record having a value that matches the encrypted search query from the record of the encrypted main table 361 having the value of the “MapID-1” column equal to the acquired value is converted into a ciphertext match comparison unit of the user definition function unit 312.
  • ciphertext search SQL is output (step 880).
  • the database wrapper unit 212 transmits the ciphertext search SQL output in step 850 or step 880 to the database interface unit 213. If the plaintext search SQL is (1), the result of step 840 exists, so the database wrapper unit 212 transmits the ciphertext search SQL (6) output in step 880 to the database interface unit 213 (step 890). ). As described above, the database wrapper unit 212 ends the secret index search query generation process (FIG. 8).
  • FIG. 9 is a flowchart showing a secret index search process executed by the database control unit 311 in the cloud system side server 4.
  • the secret index search process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • the SQL received by the database control unit 311 at the start of the secret index search process is the ciphertext search SQL (6).
  • the database control unit 311 identifies a hash table 362 and a hash table search query to be searched from the ciphertext search SQL, and the ciphertext match comparison unit 3121 of the user definition function unit 312 performs the hash table 362.
  • the record in which the “encrypted hash value” column value matches the hash table search query is specified, and the “MapID” column value of the specified record is acquired as MapID_hit.
  • the hash table 362 is the hash table 362 (HT1)
  • the hash table search query is “hash table search query (1012)” in (5).
  • the search query matches the encrypted hash value “Enc (1012)” of the record 3622 of the hash table 362 (HT 1), and MapID “2” of the record Is acquired as MapID_hit (step 910).
  • the database control unit 311 determines from the encryption main table 361 that the value of the map ID column corresponding to the hash table 362 has a value that matches MapID_hit and a value that matches the encryption search query.
  • the record group MapResult confirmed by the ciphertext match comparison unit 3121 of 312 is acquired. For example, when the ciphertext search SQL is (6), for example, the database control unit 311 determines that the value of the map ID column “MapID-1” from the encryption main table 361 is “2” acquired in step 910.
  • a record group having Enc (diabetes) that is a value of the “disease name” column that matches and the value of the encrypted search query (diabetes) is confirmed by the ciphertext match comparison unit 3121, and as a result, records 3613 and 3615 are recorded. Is acquired as MapResult (step 920).
  • the database control unit 311 transmits a record group obtained by removing the ID column and the map ID column from the Map Result to the database interface unit 213 of the user system side server 3 as a search result.
  • a record group excluding the “ID” column and the “MapID-1” column from the records 3613 and 3615 of the encryption main table 361 is used as the ciphertext search result. Transmit (step 930).
  • the secret index search process (FIG. 9) is completed.
  • FIG. 10 is a flowchart showing a search result decoding process executed by the database wrapper unit 212 in the user system side server 3.
  • the search result decryption process starts when the database wrapper unit 212 receives the ciphertext search result from the database interface unit 213.
  • the database wrapper unit 212 inputs the ciphertext search result to the decryption unit 2124, and obtains the plaintext search result as an output (step 1010). Finally, the database wrapper unit 212 transmits a plain text search result to the application unit 211 (step 1020). Thus, the search result decoding process (FIG. 10) is completed.
  • FIG. 11 is a flowchart showing a secret index insertion query generation process executed by the database wrapper unit 212 in the user system side server 3.
  • the secret index insertion query generation process starts when the database wrapper unit 212 receives the plain text insertion SQL from the application unit 211.
  • the SQL received by the database wrapper unit 212 at the start of the secret index insertion query generation process is the following plaintext insertion SQL (7).
  • INSERT INTO Medical information.Patient information patient number, name, disease name
  • VALUES 1000001, Kinoshita, gastroenteritis
  • the value of the “patient number” column is “1000001” and the value of the “name” column is “1000001” for the table whose schema name is “medical information” and whose table name is “patient information”.
  • the database wrapper unit 212 extracts the value to be inserted from the plain text insertion SQL, and encrypts it by the encryption unit 2121.
  • the plaintext insertion SQL is (7)
  • the values to be inserted are “1000001”, “Kinoshita”, and “Gastroenteritis”
  • the output ciphertexts obtained as a result of encryption by the encryption unit 2121 are respectively “Enc (1000001)”, “Enc (Kinoshita)”, and “Enc (gastroenteritis)” are obtained (step 1120).
  • the database wrapper unit 212 acquires “map ID column name” and “hash table name” related to the record to be inserted from the secret index map table 262. Specifically, the database wrapper unit 212 searches the secret index map table 262 using the combination of the schema name and encryption main table name to be inserted by the plaintext insertion SQL as a key, and the schema and encryption main table name. “Column name”, “map ID column name”, and “hash table name” are acquired from all records that match.
  • the column name “disease name”, map ID column name from the record 2621 whose schema name is “medical information” and whose encrypted main table name is “patient information” “MapID-1” and hash table name “HT1” are acquired (step 1130).
  • step 1140 the database wrapper unit 212 determines whether or not the result of step 1130 exists (step 1140).
  • the database wrapper unit 212 When the result of step 1140 does not exist (NO), the database wrapper unit 212 performs an insertion SQL conversion process that does not use the hash table 362. Specifically, the database wrapper unit 212 outputs the ciphertext insertion SQL in which the value to be inserted in the plaintext insertion SQL is replaced with the ciphertext value generated in step 1120. For example, when the plaintext SQL is (7), the ciphertext insertion SQL outputs the following ciphertext insertion SQL (8) (step 1150).
  • step 1140 the database wrapper unit 212 performs hash index generation to secret index insertion SQL conversion (steps 1160 to 1190) in order to perform insertion that is consistent with the hash table 362. ) To output ciphertext insertion SQL.
  • the database wrapper unit 212 inputs the value of the column related to the hash table 362 among the insertion target values to the hash value generation unit 2123, and acquires the output hash value. For example, when the plaintext insertion SQL is (7), the following hash value (9) is acquired (step 1160).
  • the database wrapper unit 212 inputs the hash value acquired in step 1160 to the search query generation unit 2122, and uses the output as a hash table search query.
  • hash table search query (0035) search query generation unit (encryption key, search key, “0035”) (10)
  • the database wrapper unit 212 inputs the hash value to the encryption unit 2121 and acquires the output encrypted hash value. For example, when the plaintext hash value is (8), the encrypted hash value is “Enc (0035)” (step 1180).
  • the database wrapper unit 212 searches the hash table 362 with a hash table search query. If the search does not match, after inserting a record that includes a new MapID and an encrypted hash value, the MapID of the record that matches the hash table search query is acquired, and the MapID and the value of the record of the ciphertext acquired in Step 1120
  • a secret index insertion SQL conversion is performed for inserting a record composed of an ID which is an identifier of a new record into the encryption main table 361. For example, when the plaintext SQL is (7), the following ciphertext insertion SQLs (11) and (12) are output (step 1190).
  • INSERT INTO hash table 362 MapID, encrypted hash value
  • INSERT INTO encryption main table 361 Principal number, name, disease name, ID, MapID-1) VALUES (Enc (1000001), Enc (Kinoshita), Enc (Gastroenteritis), New ID, (SELECT MapID FROM hash table 362 WHERE Encrypted match comparison unit (encrypted hash value, hash table search query (0035)) ); (12)
  • the database wrapper unit 212 transmits the ciphertext insertion SQL output in step 1150 or step 1190 to the database interface unit 213.
  • the database wrapper unit 212 converts the ciphertext insertion SQL (11) and (12) output in step 1190 to the database interface unit 213. (Step 1195).
  • the secret index insertion query generation process in FIG. 11 is completed.
  • FIG. 12 is a flowchart showing a secret index insertion process executed by the database control unit 311 in the cloud system side server 4.
  • the secret index insertion process starts when the database control unit 311 receives the ciphertext insertion SQL from the database interface unit 213.
  • the SQL received by the database control unit 311 at the start of the secret index insertion process is the ciphertext insertion SQL (11) and (12).
  • the database control unit 311 specifies a hash table, a hash table search query, and an encrypted hash value to be searched from the ciphertext search SQL. Then, the ciphertext match comparison unit 3121 of the user definition function unit 312 determines whether or not there is a record in which the value of the “encrypted hash value” column of the hash table 362 matches the hash table search query. (Step 1210).
  • step 1210 If it is determined in step 1210 that there is a record that matches the search query (YES), the database control unit 311 acquires the value of the MapID column of the record as MapID_hit (step 1220).
  • step 1210 determines whether there is no record that matches the search query. If it is determined in step 1210 that there is no record that matches the search query, the database control unit 311 generates a new MapID to MapID_hit, along with the encrypted hash value acquired from the search SQL, and the hash table 362. As a record (step 1230).
  • the database control unit 311 executes ciphertext insertion SQL, and inserts a record composed of the encrypted value, ID, and MapID_hit into the encrypted main table 361.
  • the database control unit 311 determines that the patient number is “Enc (1000001)”, the name is “Enc (Kinoshita)”, the disease name is “Enc (gastroenteritis)”, and the ID is “ A record having “1000001” and MapID-1 “10” is inserted into the encryption main table 361 (step 1240).
  • the database control unit 311 transmits the execution result of the insertion SQL to the database interface unit 213 of the user system side server 3 (step 1250).
  • the secret index insertion process (FIG. 12) is completed.
  • FIG. 13 is a flowchart showing a secret index update query generation process executed by the database wrapper unit 212 in the user system side server 3.
  • the secret index update query generation process starts when the database wrapper unit 212 receives a plaintext update SQL from the application unit 211.
  • the SQL received by the database wrapper unit 212 at the start of the secret index update query generation process is the following plaintext update SQL (13).
  • the database wrapper unit 212 extracts the value of the update source column from the plaintext update SQL (13), and acquires an encrypted search query used for matching search in the encrypted main table 361 using the search query generation unit 2122. To do. Specifically, the database wrapper unit 212 acquires an encryption key and a search key from the key management unit 2125, inputs the acquired key to the search query generation unit 2122, and obtains an encrypted search query as its output. For example, when the plaintext update SQL is (13), “encrypted search query (diabetes)” is obtained in the same manner as the encrypted search query (2) (step 1315).
  • the database wrapper unit 212 acquires “map ID column name” and “hash table name” of the update source column from the secret index map table 262. Specifically, the database wrapper unit 212 searches the secret index map table 262 using the combination of the schema name, the encrypted main table name, and the update source column name that are to be searched by the plaintext search SQL as a key. The “map ID column name” and “hash table name” of the record having the same name, encrypted main table name, and column name are acquired.
  • the schema name is “medical information”
  • the encrypted main table name is “patient information”
  • the record includes the update source column name “disease name”
  • the map ID column name “MapID-1” and the hash table name “HT1” are obtained from the information 2621 (step 1320).
  • step 1325 the database wrapper unit 212 determines whether or not the result of step 1320 exists (step 1325).
  • the database wrapper unit 212 performs a process of converting the update SQL without using the hash table 362. Specifically, the database wrapper unit 212 first transmits an SQL for obtaining an update target ID list, which is a list of IDs of records to be updated, from the encryption main table 361 to the database interface unit 213, and as a result An update target ID list is received. For example, when the plaintext update SQL is (13), the update target ID list is acquired by the following SQL (14) (step 1330). SELECT ID FROM medical information.patient information WHERE ciphertext match comparison part (disease name, encrypted search query (diabetes)) (14)
  • the database wrapper unit 212 acquires the number of update target IDs from the update ID list obtained in step 1330, and generates ciphertexts with updated values for the number of acquired update target IDs. For example, when the update SQL of the plaintext is (13), the number of update target IDs is “3” and “1000000”, so the ciphertext of the updated value is Enc (Angina) and Enc When using probabilistic encryption, these are different ciphertexts (step 1335).
  • the database wrapper unit 212 generates a ciphertext update SQL for updating the ciphertext of the two updated values obtained in step 1335 as the record values indicated by the respective update target IDs.
  • This update SQL is preferably described in one sentence SQL, but if the maximum length of the SQL sentence of the database control unit 311 is exceeded, a plurality of divided update SQLs may be generated.
  • the plaintext update SQL is (13)
  • the following update SQL (15) is output (step 1340).
  • UPDATE Medical information.Patient information SET "Disease name” CASE ID WHEN 3 THEN Enc WHEN 1000000 THEN Enc (angina) END WHERE Ciphertext match comparison unit (disease name, encrypted search query (diabetes)) (15)
  • step 1320 when the result of step 1320 exists (YES), the database wrapper unit 212 updates the encryption main table 361 and the hash table 362 to update the secret index update SQL conversion (steps 1345 to 1370).
  • the update SQL of the ciphertext that has been performed) is output.
  • the database wrapper unit 212 inputs the updated value to the hash value generation unit 2123 and acquires the output hash value. For example, when the plaintext update SQL is (13), the hash value (16) is acquired (step 1345).
  • the database wrapper unit 212 inputs the hash value acquired in step 1345 to the search query generation unit 2122, and uses the output as a hash table search query.
  • the database wrapper unit 212 inputs the hash value acquired in step 1345 to the encryption unit 2121 and acquires an encrypted hash value to be inserted into the hash table 362 as an output. For example, when the plaintext hash value (16) is “0500”, the encrypted hash value is “Enc (0500)” (step 1360).
  • the database wrapper unit 212 uses the hash table 362 to execute the secret index update target ID table acquisition SQL for acquiring the table of the ID column values of the record group to be updated, and to update the update target ID table. obtain. Specifically, the database wrapper unit 212 uses the encrypted search query for the update source value acquired in step 1315, the map ID column name and hash table name related to the update source column acquired in step 1320, and the update source. The hash table search query of the value of the value is input, the hash table 362 is searched, the search range of the encryption main table 361 is limited, the SQL for acquiring the update target ID table is executed, and the result is used as the update target ID table Output as.
  • the secret index update target ID table acquisition SQL generates the following ciphertext search SQL (18) and sends it to the database control unit 311 via the database interface unit 213.
  • the execution result is acquired as an update target ID table (step 1360).
  • the database wrapper unit 212 acquires the number of update target IDs from the update ID list obtained in step 1360, and generates a ciphertext list with updated values for the number of acquired update target IDs. For example, when the plaintext update SQL is (13), the number of update target IDs is two, “3” and “1000000”, as in step 1335. Therefore, the ciphertext list of updated values is Enc. (Angina pectoris) and Enc (angina pectoris). If probabilistic encryption is used, these are different ciphertexts (step 1365).
  • the database wrapper unit 212 receives plaintext update SQL, various information acquired in steps 1315, 1320, 1350, 1355, 1360, and 1365 as input, and updates ciphertext update SQL for the secret index. Output. Specifically, first, an encrypted match search is performed using the hash table search query of the updated value of the hash table 362. If there is no match, a record consisting of the encrypted hash value of the updated value and the new MapID value Is inserted into the hash table 362. Second, an SQL for acquiring the MapID of the updated value from the hash table 362 is generated. Third, in the encryption main table 361, for each record having the update target ID, an update SQL for replacing the ciphertext of the updated value is generated.
  • the plaintext update SQL is (13)
  • the first SQL is the following update SQL (19)
  • the second SQL is the following update SQL (20)
  • the third SQL is the following update SQL (21).
  • the ciphertext update SQL including these three SQL texts is output (step 1370).
  • INSERT INTO hash table 362 MapID, encrypted hash value
  • SELECT New MapID, encrypted hash value "Enc (0500)" FROM hash table 362 WHERE NOT EXIST SELECT * FROM hash table 362 WHERE Encryption match comparison part (encrypted hash value, hash table search query (0500) ) ) LIMIT 1; (19) SELECT MapID FROM hash table 362 WHERE Encryption match comparison unit (encrypted hash value, hash table search query (0500)) (20)
  • the database wrapper unit 212 transmits the ciphertext update SQL output in step 1340 or step 1370 to the database interface unit 213.
  • the database wrapper unit 212 converts the SQL (19), (20), and (21) of the ciphertext output from step 1370 to the database interface unit. It transmits to 213 (step 1375).
  • the database wrapper unit 212 ends the secret index update query generation process (FIG. 13).
  • FIG. 14 is a flowchart showing an update target ID list acquisition process executed by the database control unit 311 in the cloud system side server 4.
  • the update target ID list acquisition process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • step 1410 all the IDs of the records whose update target column values match the encrypted search query are acquired from the encrypted main table 361 (step 1410). Finally, the acquisition result is transmitted to the database interface unit 213 (step 1420), and the update target ID list acquisition process (FIG. 14) is terminated. For example, when the ciphertext search SQL is (14), the elements of the update target ID list are “3” and “1000000”.
  • FIG. 15 is a flowchart showing a secret index update target ID table acquisition process executed by the database control unit 311 in the cloud system side server 4.
  • the secret index update target ID table acquisition process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • the MapID of the record that matches the hash table search query is acquired from the hash table 362 (step 1510).
  • the ID of the record having the value of MapID-1 that matches the MapID acquired in step 1510 and the value of the “disease name” column that is the update source column matches the encrypted search query is stored in the encrypted main table 361.
  • the acquisition result is transmitted to the database interface unit 213 (1530), and the confidential index update target ID table acquisition process (FIG. 15) is terminated.
  • the update target ID table is a table storing “3” and “1000000” as values of the ID column.
  • FIG. 16 is a flowchart showing a secret index update process executed by the database control unit 311 in the cloud system side server 4.
  • the secret index update process starts when the database control unit 311 receives the ciphertext update SQL from the database interface unit 213.
  • the SQL received by the database control unit 311 at the start of the secret index update process is the ciphertext update SQL (19), (20), and (21).
  • the database control unit 311 acquires the hash table 362 and the hash table search query (0500) to be updated from the first SQL of the ciphertext update SQL (19).
  • the ciphertext match comparison unit 3121 of the user definition function unit 312 searches for a record in which the value of the “encrypted hash value” column of the hash table matches the hash table search query (0500) (step 1610). .
  • step 1610 the database control unit 311 acquires MapID from the matched record (step 1620).
  • step 1610 if the result of step 1610 does not exist, the database control unit 311 generates a new MapID, inserts it into the hash table 362 together with the encrypted hash value “Enc (0500)”, and acquires a new MapID (step 1630). .
  • the database control unit 311 replaces the updated ciphertext with the value of the update target column of the record having the update target ID of the encryption main table 361, and sets the value of the map ID column “MapID-1” to step 1620 or The value is replaced with the value of MapID acquired in step 1630 (step 1640).
  • the database control unit 311 deletes the record having the MapID that does not exist in the map ID column “MapID-1” of the encrypted main table 361 from the hash table 362 (Step 1650).
  • the database control unit 311 transmits the update result to the database interface unit 213 (1660).
  • the secret index update process (FIG. 16) is completed.
  • FIG. 17 is a flowchart showing a secret index deletion query generation process executed by the database wrapper unit 212 in the user system side server 3.
  • the secret index deletion query generation process starts when the database wrapper unit 212 receives a plaintext deletion SQL from the application unit 211.
  • the SQL received by the database wrapper unit 212 at the start of the secret index deletion query generation process is the plaintext deletion SQL (22) shown below.
  • Patient Information WHERE Disease Name Diabetes (22)
  • This deletion SQL means that all records whose “Disease Name” column value is “Diabetes” are deleted from the table whose schema name is “Medical Information” and whose table name is “Patient Information” (Steps). 1710).
  • the database wrapper unit 212 acquires “map ID column name” and “hash table name” of the search target column from the secret index map table 262. Specifically, the database wrapper unit 212 searches the secret index map table 262 using the combination of the schema name, the encryption main table name, and the column name that the plaintext deletion SQL is the target of the deletion condition, as a schema name. Then, the “map ID column name” and “hash table name” of the record whose encrypted main table name and column name match are acquired. For example, when the plain text search SQL is (22), from the record 2621 where the schema name is “medical information”, the encrypted main table name is “patient information”, and the column name is “disease name”. The map ID column name “MapID-1” and the hash table name “HT1” are acquired (step 1730).
  • step 1740 the database wrapper unit 212 determines whether or not the result of step 1730 exists (step 1740).
  • step 1740 the database wrapper unit 212 performs processing for converting the deletion SQL without using the hash table 362. Specifically, the database wrapper unit 212 replaces the value of the target column of the plaintext SQL deletion condition with the encrypted search query generated in step 1720, and further converts the match comparison sentence of the WHERE clause to the user-defined function unit.
  • the ciphertext deletion SQL replaced with the format for calling the ciphertext match comparison unit 3121 of 312 is output. For example, when the plaintext SQL is (22) and the encrypted search query is (2), the ciphertext deletion SQL is the following ciphertext SQL (23) (step 1750). DELETE FROM Medical information.Patient information WHERE Ciphertext match comparison unit (disease name, encrypted search query (diabetes)) (23)
  • step 1730 if the result of step 1730 exists (YES), the database wrapper unit 212 performs processing from hash value generation to secret index deletion SQL conversion (steps 1760 to 1780) in order to perform deletion using the hash table 362.
  • the deletion SQL of the ciphertext that has been performed is output.
  • the database wrapper unit 212 inputs the value of the target column of the deletion condition to the hash value generation unit 2123, and acquires the output hash value. For example, when the plaintext deletion SQL is (22), the hash value (4) is acquired (step 1760).
  • the database wrapper unit 212 inputs the hash value acquired in step 1760 to the search query generation unit 2122, and uses the output as a hash table search query. For example, if the hash value of the plaintext is (4), a hash table search query (5) is acquired (step 1770).
  • Hash table search query (1012) search query generator (encryption key, search key, "1012") (5)
  • the database wrapper unit 212 searches the hash table 362 by using the secret index SQL conversion unit 2127 to limit the search range, and then generates SQL for executing deletion from the encrypted main table 361.
  • Search SQL conversion for the secret index is performed.
  • the encrypted search query obtained in step 1720, the map ID column name and hash table name obtained in step 1730, and the hash table search query obtained in step 1770 are input, and the hash table 362 is used as the hash table.
  • the value of the “MapID” column of the corresponding record is obtained by searching with the search query, and matches the encrypted search query from the record of the encrypted main table 361 having the value of the “MapID-1” column equal to the value.
  • a record having a value is determined using the ciphertext match comparison unit 3121 of the user definition function unit 312. Then, an SQL for deleting the matched record from the encrypted main table 361 is generated. Further, an SQL for deleting a record including a MapID that does not exist in the map ID column “MapID-1” of the encrypted main table 361 is generated from the hash table 362. For example, if the plaintext deletion SQL is (22), the ciphertext deletion SQL including the two SQL texts (23) and (24) is output (step 1780). DELETE Medical information. Patient information FROM Medical information.
  • the database wrapper unit 212 transmits the ciphertext deletion SQL output in step 1750 or step 1780 to the database interface unit 213.
  • the database wrapper unit 212 transmits the ciphertext search SQL (24) and (25) output in step 1780 to the database interface unit 213. (Step 1790).
  • the database wrapper unit 212 ends the secret index deletion query generation process (FIG. 17).
  • FIG. 18 is a flowchart showing a secret index deletion process executed by the database control unit 311 in the cloud system side server 4.
  • the secret index deletion process starts when the database control unit 311 receives the ciphertext deletion SQL from the database interface unit 213.
  • the SQL received by the database control unit 311 at the start of the secret index deletion process is the ciphertext deletion SQL (24) and (25).
  • the database control unit 311 identifies the hash table 362 and the hash table search query that are subject to the deletion condition from the ciphertext deletion SQL, and the ciphertext match comparison unit 3121 of the user definition function unit 312 performs the hash table 362.
  • the record in which the “encrypted hash value” column value matches the hash table search query is identified, and the “MapID” column value of the record is acquired as MapID_hit.
  • the hash table 362 is the hash table 362 (HT1)
  • the hash table search query is “hash table search query (1012)”.
  • the encrypted hash value “Enc (1012)” of the record 3622 of the hash table 362 (HT 1) is matched, and MapID “2” of the record is acquired as MapID_hit. (Step 1810).
  • the database control unit 311 confirms that the value of the map ID column corresponding to the hash table 362 has a value that matches MapID_hit and a value that matches the encrypted search query, and the ciphertext match comparison unit of the user definition function unit 312.
  • the record group MapResult confirmed by 3121 is acquired from the encryption main table 361.
  • the database control unit 311 matches the value of the map ID column “MapID-1” with “2” acquired in step 910 and A group of records having Enc (diabetes) that is the value of the “disease name” column that matches the value of the generalized search query (diabetes) is confirmed by the ciphertext match comparison unit 3121, and as a result, the record 3613 and the record 3615 are set as MapResult. (Steps 1820 and 1830).
  • the database control unit 311 deletes the record included in MapResult from the encryption main table 361 (step 1840).
  • the database control unit 311 deletes a record including a MapID that does not exist in the map ID column “MapID-1” of the encrypted main table 361 from the hash table 362 (Step 1850).
  • the database control unit 311 transmits the result of the ciphertext deletion SQL to the database interface unit 213 (step 1860).
  • the secret index deletion process (FIG. 18) is completed.
  • FIG. 19 shows a hardware and software configuration of the concealment database system 1 according to the second embodiment of the present invention. It is a block diagram.
  • the concealment database system 1 encrypts the original data held by the user system side server 3 and deposits it in the cloud system side server 4.
  • the concealment database system 1 of the second embodiment is different from the first embodiment in that the MapID-1 column indicating the correspondence with the hash table 362B is removed instead of the encryption main table 361.
  • a mapping table 363 that has a main table 361B and that is encrypted and stored in order to conceal the correspondence between the encrypted main table 361B and the hash table 362B having different encrypted hash values.
  • the user terminal 2 of the second embodiment is the same as the user terminal 2 of the first embodiment.
  • the user system side server 3 of the second embodiment is the same as the user system side server 3 of the first embodiment.
  • the application unit 211 of the second embodiment is the same as the application unit 211 of the first embodiment.
  • the database wrapper unit 212 of the second embodiment is different from the first embodiment in that an index search query generation unit 2128, an ID encryption unit 2129, an index encryption unit 2120, and a mapping table rearrangement query generation unit 21200. It is to have. Each unit of the database wrapper unit 212 will be described later with reference to FIG. The rest is the same as the first embodiment.
  • the database interface unit 213 of the second embodiment is the same as the database interface unit 213 of the first embodiment.
  • the disk device 260 of the second embodiment is different from the first embodiment in that the secret index map table 262B having a “mapping table name” column instead of the “map ID column name” column of the secret index map table 262. It is to have. The rest is the same as the first embodiment.
  • the cloud system side server 4 of the second embodiment is the same as the cloud system side server 4 of the first embodiment.
  • the database control unit 311 of the second embodiment is different from the first embodiment in that the information of the mapping table 363 is added and used.
  • the rest is the same as the user-defined function unit 312 of the first embodiment.
  • the user-defined function unit 312 of the second embodiment is different from the first embodiment in that it includes an index match comparison unit 3122, an ID key acquisition unit 3123, an ID decryption unit 3124, and an ID encryption unit 3125. It is. Each unit of the user-defined function unit 312 will be described later with reference to FIG. The rest is the same as the user-defined function unit 312 of the first embodiment.
  • the disk device 360 of the second embodiment is different from the first embodiment in that it has an encrypted main table 361B instead of the encrypted main table 361, and has a hash table 362B instead of the hash table 362, Furthermore, the mapping table 363 is additionally provided. The rest is the same as the disk device 360 of the first embodiment.
  • FIG. 20 shows a logical configuration of the database wrapper unit 212 of the second embodiment.
  • the database wrapper unit 212 of the second embodiment is different from the first embodiment in that, in addition to the components shown in FIG. 2, an index search query generation unit 2128, an ID encryption unit 2129, an index encryption unit 2120 and a mapping table rearrangement query generation unit 21200. The rest is the same as the database wrapper unit 212 (FIG. 2) of the first embodiment.
  • the encryption unit 2121 of the second embodiment is the same as the encryption unit 2121 of the first embodiment.
  • the search query generation unit 2122 of the second embodiment is the same as the search query generation unit 2122 of the first embodiment.
  • the hash value generation unit 2123 of the second embodiment is the same as the hash value generation unit 2123 of the first embodiment.
  • the decoding unit 2124 of the second embodiment is the same as the decoding unit 2124 of the first embodiment.
  • the key management unit 2125 of the second embodiment differs from the first embodiment in that the key search unit 2128, the ID encryption unit 2129, and the index encryption unit 2120 request a key. Is to provide encryption key data or search key data. Note that encryption key data and search key data may be provided. The rest is the same as the key management unit 2125 of the first embodiment.
  • the SQL converter 2126 of the second embodiment is the same as the SQL converter 2126 of the first embodiment.
  • the difference between the secret index SQL conversion unit 2127 of the second embodiment and the secret index SQL conversion unit 2127 of the first embodiment is that the hash table 362B, the mapping table 363, and the encryption main table 361B are referred to.
  • An encrypted SQL sentence that performs at least one of insertion, update, and deletion is generated, and the encrypted SQL sentence is transmitted to the database interface unit 213.
  • the rest is the same as the secret index SQL conversion unit 2127 of the first embodiment.
  • the index search query generation unit 2128 of the second embodiment receives the index byte string output by the hash value generation unit 2123 and outputs an index hash table search query for searching the hash table 362B.
  • the ID encryption unit 2129 of the second embodiment encrypts the value of the ID column of the main table 261 stored in the mapping table 363. Specifically, the ID encryption unit 2129 acquires an ID key for encrypting the ID from the key management unit 2125, encrypts the plaintext ID using the acquired key, and outputs the result as the encryption ID. To do.
  • the index encryption unit 2120 of the second embodiment encrypts the identifier of the index. Specifically, the index encryption unit 2120 receives the ID key acquired from the key management unit 2125 and the plaintext hash value output from the hash value generation unit 2123 as input, and the encryption key acquired from the key management unit 2125. The hash value input by is encrypted, and the result is output as an encrypted hash value.
  • the mapping table rearrangement query generation unit 21200 of the second embodiment rearranges the order of each record in the mapping table 363 at random.
  • FIG. 21 shows a logical configuration of the user-defined function unit 312 of the second embodiment.
  • the user-defined function unit 312 of the second example differs from the user-defined function unit 312 (FIG. 3) of the first example in addition to the configuration of the first example, the index match comparison unit 3122, An ID key acquisition unit 3123, an ID decryption unit 3124, and an ID encryption unit 3125 are provided. The rest is the same as the user-defined function unit 312 of the first embodiment.
  • the ciphertext match comparison unit 3121 of the second embodiment is the same as the ciphertext match comparison unit 3121 of the first embodiment.
  • the index match comparison unit 3122 of the second embodiment stores the search key data in the memory 310 and / or the disk device 360. Also, an index match that allows an index hash table search query and an encrypted hash value to be input from the database control unit 311 and can be compared with the encrypted hash value using the search key. Convert to search query. Then, a match comparison between the index match search query and the encrypted hash value is performed. If they match, a value indicating a match (for example, “1”) is output, and if they do not match, a value indicating a mismatch (for example, “0”) is output. Is output.
  • the ID key acquisition unit 3123 of the second embodiment receives an index hash table search query and an encrypted hash value, converts a part of the encrypted hash value, and outputs an ID key.
  • the ID decryption unit 3124 of the second embodiment receives the encryption ID and the ID key, decrypts the encryption ID with the ID key, and outputs a plaintext ID.
  • the ID encryption unit 3125 of the second embodiment receives the plaintext ID and the ID key, encrypts the plaintext ID with the ID key, and outputs the encrypted ID.
  • FIG. 22 shows the data structure of the secret index map table 262B of the second embodiment.
  • the secret index map table 262B of the second embodiment is different from the secret index map table 262 (FIG. 5) of the first embodiment in that there is no “map ID column name” column and the mapping table 363 It has a “mapping table name” column indicating the relationship. The rest is the same as the secret index map table 262 (FIG. 5) of the first embodiment.
  • “column name” having a related mapping table and hash table is “disease name”, and related “mapping table name” is “MT1”.
  • the related “hash table name” is “HT1”.
  • FIG. 23 shows the data structure of the encryption main table 361B of the second embodiment.
  • the difference between the encryption main table 361B of the second embodiment and the encryption main table 361 (FIG. 6) of the first embodiment is that there is no “map ID column”. Due to this difference, the MapID corresponding to each record cannot be specified on the encryption main table 361B. The rest is the same as the encryption main table 361 (FIG. 6) of the first embodiment.
  • FIG. 24 shows the data structure of the mapping table 363 (MT1) of the second embodiment.
  • the mapping table 363 is stored in the disk device 360 or (and) the memory 310 of the cloud system side server 4, and conceals the correspondence between each record on the encryption main table 361B and “MapID” on the hash table 362B (HT1). And hold.
  • the mapping table 363 may be stored in both the disk device 360 and the memory 310.
  • the mapping table 363 forms a record by a “MID” column, an “encryption ID” column, and a “MapID” column indicating a value of “MapID”.
  • the “MID” column is an identifier that uniquely identifies a record on the mapping table.
  • the “encryption ID” column indicates an encryption ID obtained by encrypting the value of the “ID” column of the encryption main table 361B by the ID encryption unit 2129 or the ID encryption unit 3125.
  • the “MapID” column indicates the value of “MapID” in the hash table 362 corresponding to each record in the mapping table 363.
  • the record 3631 has an identifier “MID” column value that uniquely identifies the record as “101”, and is an encrypted value of the “ID” column value of the record in the corresponding encrypted main table 361B.
  • the value of the “encryption ID” column is “IEnc (1)”, and the value of the “MapID” column corresponding to the hash table 362 is “1”.
  • mapping table 363 conceals and holds the “MapID” value of the hash table 362 to which each record on the encrypted main table 361B corresponds.
  • “IEnc ()” indicates that the plaintext ID in “()” is an encryption ID encrypted by the ID encryption unit 2129 or the ID encryption unit 3125. Further, the normal index function of the database control unit 311 is applied to the “MID” column and the “MapID” column.
  • FIG. 25 shows the data structure of the hash table 362B used for speeding up the search.
  • the hash table 362B of the second embodiment is different from the hash table 362 (FIG. 7) of the first embodiment in that a record is constituted by a “MapID” column and an “encrypted hash value” column.
  • the “MapID” column indicates correspondence information with the mapping table 363.
  • the “encrypted hash value” indicates a value obtained by encrypting the hash value generated by the hash value generation unit 2123 and the bit string of the ID key pair by the secret index SQL conversion unit 2127.
  • the value of “MapID” corresponding to the value of the “MapID” column of the mapping table 363 is “1”, and the value of the corresponding “encrypted hash value” is “INEnc (ID_key — 1,0765)”. ".
  • the value of the “MapID” column is equal to the value of “MapID” of one or more records in the mapping table 363.
  • FIG. 26 is a flowchart showing a secret index search query generation process of the second embodiment.
  • the secret index search query generation process of the second embodiment is different from the secret index search query generation process of the first embodiment in that the “ID” column and the hash table of the encryption main table 361B using the mapping table 363 are used. This is to associate the “MapID” column of 362B.
  • This process starts when the database wrapper unit 212 receives a plain text search SQL from the application unit 211.
  • the SQL received by the database wrapper unit 212 is SQL (1) for plain text search. SELECT * FROM Medical information.
  • Patient information WHERE Disease name Diabetes (1)
  • This search SQL searches a record whose schema name is “medical information” and whose table name is “patient information” and whose value in the “disease name” column is “diabetes”, and finds all the records that match the conditions. This means that the column value is obtained as a search result (step 2510).
  • the database wrapper unit 212 first acquires the encryption key and the search key from the key management unit 2125, and inputs the acquired key to the search query generation unit 2122, as in step 820 of the first embodiment. , Get an encrypted search query as its output.
  • the plaintext SQL is (1)
  • the following execution formula (2) is obtained (step 2520).
  • Encrypted search query (diabetes) Search query generator (encryption key, search key, “diabetes”) (2)
  • the database wrapper unit 212 acquires “mapping table name” and “hash table name” of the search target column from the secret index map table 262, which is partially different from step 830 of the first embodiment. Specifically, the database wrapper unit 212 searches the secret index map table 262B using the combination of the schema name, the encryption main table name, and the column name to be searched by the plaintext search SQL as a key, and the schema name, encryption The “mapping table name” and “hash table name” of the record having the same main table name and column name are acquired. For example, when the plain text search SQL is (1), from the record 2621B in which the schema name is “medical information”, the encrypted main table name is “patient information”, and the column name is “disease name”. The mapping table name “MT1” and the hash table name “HT1” are acquired (step 2530).
  • the database wrapper unit 212 determines whether or not the result of step 2530 exists as in step 830 of FIG. 8 in the first embodiment (step 2540).
  • step 2540 When the result of step 2540 is “does not exist” (NO), the database wrapper unit 212 sets the search target value of the plaintext SQL in step 2520 as in step 850 of FIG. 8 in the first embodiment.
  • a ciphertext search SQL is output by replacing the generated ciphertext search query with the generated ciphertext match comparison unit 3121 of the user definition function unit 312.
  • the plaintext SQL is (1) and the encrypted search query is (2)
  • the ciphertext search SQL is the following ciphertext search SQL (3) (step 2550).
  • Patient information WHERE Ciphertext match comparison unit (disease name, encrypted search query (diabetes)) (3)
  • step 2540 if the result of step 2540 is “exists” (YES), the database wrapper unit 212 performs the search from the hash value to the secret index search SQL in order to perform a high-speed search using the hash table 362 and the mapping table 363.
  • a ciphertext search SQL subjected to the conversion (steps 2560 to 2580) processing is output.
  • the database wrapper unit 212 inputs the search target value to the hash value generation unit 2123 and acquires the output hash value, as in step 860 of FIG. 8 in the first embodiment.
  • the plaintext search SQL is (1)
  • the following hash value (4) is acquired (step 2560).
  • the database wrapper unit 212 is partly different from the step 870 of FIG. 8 in the first embodiment, and the hash value acquired in the step 2560 is used as the index search query generation unit 2128 in order to search the hash table 362B.
  • the output is used as an index hash table search query.
  • index (1012) Index search query generator (encryption key, search key, "1012") (5-2)
  • the database wrapper unit 212 is partially different from step 880 of FIG. 8 in the first embodiment, and after searching the hash table 362B to limit the search range, the encryption ID corresponding to the search range is set.
  • the encryption ID is identified from the mapping table 363, and the encrypted ID is decrypted to obtain the ID, and the secret index search SQL conversion is performed to generate the SQL for searching the record of the encrypted main table 361B corresponding to the ID.
  • the encrypted search query obtained in step 2520, the mapping table name and hash table name obtained in step 2530, and the index hash table search query obtained in step 2570 are input, and hash table 362B is indexed.
  • the value in the “MapID” column and the ID key of the corresponding record are acquired by searching with the hash table search query. Then, the encryption ID to be searched is specified from the record of the mapping table 363 having the value of the “MapID” column equal to the value, and the ID to be searched is acquired by decrypting the encryption ID with the ID key. Further, using the ciphertext match comparison unit 3121 of the user-defined function unit 312, a record having a value that matches the encrypted search query is determined from the records of the encryption main table 361B having the ID to be searched, and matches. Only a column existing in the main table 261 (other than the “ID” column) is selected from the record, and a ciphertext search SQL as a search result is generated and output.
  • the plaintext search SQL is (1)
  • the following ciphertext search SQL (6-2) is output (step 2580).
  • the database wrapper unit 212 transmits the ciphertext search SQL output in step 2550 or step 2880 to the database interface unit 213.
  • the database wrapper unit 212 transmits the ciphertext search SQL (6-2) output in step 2580 to the database interface unit 213 ( Step 2590).
  • the database wrapper unit 212 ends the secret index search query generation process (FIG. 26).
  • FIG. 27 is a flowchart showing the secret index search process of the second embodiment.
  • the secret index search process of the second embodiment is different from the secret index search process (FIG. 9) of the first embodiment in that the “ID” column and the hash table of the encryption main table 361B using the mapping table 363 are used. This is to associate the “MapID” column of 362B.
  • the secret index search process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • the ciphertext search SQL received by the database control unit 311 at the start of the secret index search process is SQL (6-2).
  • the database control unit 311 identifies a hash table 362B and an index hash table search query to be searched from the ciphertext search SQL, and the hash table 362B is searched by the index match comparison unit 3122 of the user definition function unit 312.
  • the record in which the value of the “encrypted hash value” column matches the hash table search query for the index is specified, and the value of the “MapID” column of the record is acquired as MapID_hit.
  • the ciphertext search SQL is (6-2)
  • the hash table is the hash table 362B (HT1)
  • the index hash table search query is “index hash table search query (5-2) ( 1012) ".
  • the index match comparison unit 3122 matches the encrypted hash value “INEc (ID_key_2, 1012)” of the record 3622B of the hash table 362B (HT1), and MapID “2” of the record is set as MapID_hit. Obtain (step 2610).
  • the database control unit 311 acquires, from the mapping table 363, a record group in which the value of the “MapID” column matches MapID_hit as HashResult. For example, when the ciphertext search SQL is (6-2), since MapID_hit is “2”, records 3632 and 3633 having a “MapID” value of 2 in the mapping table 363 are acquired as HashResult (step). 2620).
  • the database control unit 311 inputs the index hash table search query and the encrypted hash value hit in step 2610 to the ID key acquisition unit 3123 to acquire the ID key. Further, the ID key and the value of the “Encryption ID” column of the HashResult are input to the ID decryption unit 3124 to acquire an IDResult that is an ID group to be searched. For example, when the ciphertext search SQL is (6-2), the encrypted hash value “INEnc (ID_key_2, 0120)” hit in step 2610 is obtained, and the ID key “ID_key_2” is obtained from the ID key acquisition unit 3123. Get.
  • the ID ID “3, 4” is acquired by decrypting the encrypted ID “IEnc (3), IEnc (1000000)” of the HashResult (records 3632 and 3633 of the mapping table 363) acquired in step 3620 with the acquired ID key. (Step 2630).
  • the database control unit 311 indicates from the encryption main table 361B that the encrypted text of the user definition function unit 312 has a value in the “ID” column corresponding to IDResult and a value that matches the encrypted search query.
  • the record group MapResult confirmed by the match comparison unit 3121 is acquired. For example, when the ciphertext search SQL is (6-2), the database control unit 311 uses the ciphertext match comparison unit 3121 to set the value of the “ID” column to “3, 4” acquired in step 2630.
  • the database control unit 311 transmits a record group obtained by removing the “ID” column from the Map Result to the database interface unit 213 of the user system side server 3 as a search result.
  • a record group excluding the “ID” column is transmitted as a ciphertext search result from the records 3613B and 3615B of the encryption main table 361B (step 2650).
  • the secret index search process (FIG. 27) is completed.
  • the search result decoding process is the same as the search result decoding process (FIG. 10) of the first embodiment.
  • FIG. 28 is a flowchart illustrating a secret index insertion query generation process according to the second embodiment.
  • the secret index insertion query generation process of the second embodiment is different from the secret index insertion query generation process (FIG. 11) of the first embodiment in that an insertion process for the mapping table 363 is added.
  • the secret index insertion query generation process starts when the database wrapper unit 212 receives the plain text insertion SQL from the application unit 211.
  • the plaintext insertion SQL received by the database wrapper unit 212 at the start of the secret index insertion query generation process is the following plaintext insertion SQL (7), as in the first embodiment.
  • INSERT INTO Medical information.Patient information patient number, name, disease name
  • VALUES 1000001, Kinoshita, gastroenteritis
  • the value of the “patient number” column is “1000001” and the value of the “name” column is “1000001” for the table whose schema name is “medical information” and whose table name is “patient information”. This means that a record that is “Kinoshita” and the value of the “disease name” column is “gastroenteritis” is inserted (step 2710).
  • the database wrapper unit 212 takes out the value to be inserted from the plain text insertion SQL and encrypts it by the encryption unit 2121 as in step 1120 of FIG. 11 in the first embodiment.
  • the plaintext insertion SQL is (7)
  • the values to be inserted are “1000001”, “Kinoshita”, and “Gastroenteritis”
  • the encrypted text output as a result of encryption by the encryption unit 2121 is: “Enc (1000001)”, “Enc (Kinoshita)”, and “Enc (gastroenteritis)” are obtained (step 2720).
  • the database wrapper unit 212 acquires “mapping table name” and “hash table name” related to the record to be inserted from the secret index map table 262B as in step 1130 of FIG. Specifically, the database wrapper unit 212 searches the secret index map table 262B using the combination of the schema name and encryption main table name to be inserted by the plaintext insertion SQL as a key, and the schema and encryption main table name. “Column name”, “mapping table name”, and “hash table name” are acquired from all records that match. For example, when the plain text insertion SQL is (7), the column name “disease name”, mapping table name ”from the record 2621B in which the schema name is“ medical information ”and the encrypted main table name is“ patient information ”. MT1 "and hash table name” HT1 "are acquired (step 2730).
  • the database wrapper unit 212 determines whether or not the result of step 2730 exists as in step 1140 of FIG. 11 in the first embodiment (step 2740).
  • step 2740 If the result of step 2740 does not exist (NO), the database wrapper unit 212 generates the value to be inserted in the plaintext insertion SQL in step 2720 as in step 1150 of FIG. 11 in the first embodiment.
  • the ciphertext insertion SQL replaced with the text value is output.
  • the plaintext SQL is (7)
  • the following ciphertext insertion SQL (8) is output (step 2750).
  • step 2740 when the result of step 2740 exists (YES), the database wrapper unit 212 performs the insertion of the hash value from the hash value generation to the secret index insertion SQL conversion (steps 2760 to 2790) in order to perform the insertion that is consistent with the hash table 362B. ) To output ciphertext insertion SQL.
  • the database wrapper unit 212 inputs the column value related to the hash table 362B among the insertion target values to the hash value generation unit 2123 and outputs the same as in step 1160 of FIG. 11 in the first embodiment.
  • the database wrapper unit 212 inputs the hash value acquired in step 2760 to the index search query generation unit 2128 in order to search the hash table 362B.
  • the output is an index hash table search query.
  • Hash table search query for index (0035) Index search query generator (encryption key, search key, “0035”) (9-2)
  • the database wrapper unit 212 inputs the hash value (8) and the ID key acquired from the key management unit 2125 to the index encryption unit 2120, Get the output cryptographic hash value. For example, when the plaintext hash value is (8) and the ID key is “ID_key — 3”, the encrypted hash value is “INEc (ID_key — 3,0035)” (step 2780).
  • the database wrapper unit 212 searches the hash table 362B with an index hash table search query in the same manner as in step 1190 of FIG. 11 in the first embodiment, and if the search does not match, a new MapID and encrypted hash A record consisting of the value is inserted into the hash table 362B, and the MapID of the record that matches the hash table search query is acquired. From the MapID, the value of the ciphertext record acquired in step 2720 and the ID that is the identifier of the new record Insert the record to be configured into the encryption main table 361B, and finally insert the record composed of the encryption ID obtained by encrypting the ID of the new record by the ID encryption unit 3125 and the new Map ID into the mapping table 363. SQL Perform the conversion.
  • INSERT INTO hash table HT1 MapID, encrypted hash value
  • INSERT INTO encryption main table patient number, name, disease name, ID
  • VALUES Enc (1000001), Enc (Kinoshita), Enc (Gastroenteritis), New ID,
  • SELECT MapID FROM hash table HT1 WHERE encryption match comparison unit encrypted hash value, Hash table search query for index (0035)
  • (12-2) INSERT INTO mapping table MT1 (MapID, encrypted hash value) SELECT New MapID, encrypted hash value "INEnc (ID_key_3, 0035)" FROM hash table
  • the database wrapper unit 212 transmits the ciphertext insertion SQL output in step 2750 or step 2790 to the database interface unit 213 as in step 2795 of FIG. 11 in the first embodiment.
  • the database wrapper unit 212 causes the ciphertext insertion SQL (11-2), (12-2) and (13-2) is transmitted to the database interface unit 213 (step 2795).
  • the secret index insertion query generation process (FIG. 28) is thus completed.
  • FIG. 29 is a flowchart showing the secret index insertion process of the second embodiment.
  • the secret index insertion process of the second embodiment is different from the secret index insertion process (FIG. 12) of the first embodiment in that an insertion process for the mapping table 363 is added.
  • the secret index insertion process starts when the database control unit 311 receives the ciphertext insertion SQL from the database interface unit 213.
  • the ciphertext insertion SQL received by the database control unit 311 at the start of the secret index insertion processing is SQL (11-2), (12-2), and (13-2).
  • the database control unit 311 specifies the hash table 362B, index hash table search query, and encrypted hash value to be searched from the ciphertext search SQL, and the index matching comparison unit of the user-defined function unit 312.
  • step 2810 If there is a matching record in step 2810 (YES), the database control unit 311 acquires the value of the MapID column of the record as MapID_hit (step 2820). For example, when the insertion SQL is (11-2), MapID_hit is “10”.
  • the database control unit 311 determines whether there is no matching record in step 2810. If there is no matching record in step 2810, the database control unit 311 generates a new MapID to make MapID_hit, and inserts it into the hash table 362B as a record together with the encrypted hash value acquired from the search SQL (step 2830). ).
  • the database control unit 311 executes the ciphertext insertion SQL, and inserts a record composed of the encrypted value and ID into the encrypted main table 361B.
  • the database control unit 311 determines that the patient number is “Enc (1000001)”, the name is “Enc (Kinoshita)”, and the disease name is “Enc (gastroenteritis)”. "And a record with ID" 1000001 "are inserted into the encrypted main table 361B (step 2840).
  • the database control unit 311 inputs the index hash table search query and the encrypted hash value to the ID key acquisition unit 3123, and acquires the ID key as an output. For example, if the encrypted hash value is “INEnc (ID_key — 3,0035)” of (11-2), ID_key — 3 is acquired as an ID key (step 2850).
  • the database control unit 311 inputs the new ID and the ID key acquired in step 2850 to the ID encryption unit 3125, and acquires the encryption ID as an output. For example, when the new ID is “1000001”, the encryption ID is “IEnc (1000001)” (step 2860).
  • the database control unit 311 inserts a record consisting of the encryption ID acquired in step 2860 and the MapID_hit acquired in step 2820 or step 2830 into the mapping table 363.
  • a record including the encryption ID “IEnc (1000001)” and MapID_hit “10” is inserted into the mapping table 363.
  • the value of the “MID” column is assigned by the database control unit 311 using a normal automatic numbering function (step 2870).
  • the database control unit 311 transmits the execution result of the insertion SQL to the database interface unit 213 of the user system side server 3 (step 2880).
  • the secret index insertion process (FIG. 28) is completed.
  • FIG. 30 is a flowchart illustrating a secret index update query generation process executed by the database wrapper unit 212 of the user system side server 3 according to the second embodiment.
  • the secret index update query generation process starts when the database wrapper unit 212 receives a plaintext update SQL from the application unit 211.
  • the plaintext update SQL received by the database wrapper unit 212 at the start of the secret index update query generation process is the plaintext update SQL (13), as in the first embodiment.
  • the database wrapper unit 212 extracts the value of the update source column from the plaintext update SQL, and uses the search query generation unit 2122 to acquire the encrypted search query used for matching search in the encrypted main table 361B. Specifically, the database wrapper unit 212 acquires an encryption key and a search key from the key management unit 2125, inputs them to the search query generation unit 2122, and obtains an encrypted search query as its output. For example, as an example when the update SQL of the plaintext is (13), “encrypted search query (diabetes)” is obtained as in (2) (step 2910).
  • the database wrapper unit 212 acquires “mapping table name” and “hash table name” of the update source column from the secret index map table 262. Specifically, the database wrapper unit 212 searches the secret index map table 262B using the combination of the schema name, the encrypted main table name, and the update source column name that are to be searched by the plaintext search SQL as a key. The “mapping table name” and “hash table name” of the record having the same name, encrypted main table name, and column name are acquired.
  • the schema name is “medical information”
  • the encrypted main table name is “patient information”
  • the record includes the update source column name “disease name”
  • the mapping table name “MT1” and the hash table name “HT1” are acquired from 2621B (step 2915).
  • step 2920 the database wrapper unit 212 determines whether or not the result of step 2915 exists (step 2920).
  • step 2915 the database wrapper unit 212 is a list of IDs of records to be updated from the encryption main table 361B, as in step 1330 of FIG. 13 in the first embodiment.
  • SQL for obtaining the update target ID list is transmitted to the database interface unit 213, and as a result, the update target ID list is received.
  • the update target ID list is acquired by the following SQL (14) (step 2925). SELECT ID FROM Medical Information.
  • Patient Information WHERE Ciphertext Match Comparison Unit (Disease Name, Encrypted Search Query (Diabetes)) (14)
  • the database wrapper unit 212 acquires the number of update target IDs from the update ID list obtained in step 2925, and updates the number of update target IDs. Generate ciphertext with the value of. For example, when the update SQL of the plaintext is (13), the number of update target IDs is “3” and “1000000”, so the ciphertext of the updated value is Enc (Angina) and Enc (Angina pectoris). If probabilistic encryption is used, these are different ciphertexts (step 2930).
  • the database wrapper unit 212 updates the ciphertext of the two updated values obtained in step 1335 of FIG. 13 in the first embodiment as the values of the records indicated by the respective update target IDs.
  • the update SQL is generated.
  • the plaintext update SQL is (13)
  • the following ciphertext update SQL (15) is output (step 2935).
  • UPDATE Medical information.Patient information SET "Disease name” CASE ID WHEN 3 THEN Enc WHEN 1000000 THEN Enc (angina) END WHERE Ciphertext match comparison part (disease name, encrypted search query (diabetes)) (15)
  • step 2915 when the result of step 2915 exists (YES), the database wrapper unit 212 updates the encryption main table 361B, the hash table 362B, and the mapping table 363 from the hash value generation to the secret index update SQL conversion (The ciphertext update SQL for which steps 2940 to 2970) have been performed is output.
  • the database wrapper unit 212 inputs the updated value to the hash value generation unit 2123 and acquires the output hash value, similarly to step 1345 of FIG. 13 in the first embodiment.
  • the hash value (16) is acquired (step 2940).
  • the database wrapper unit 212 inputs the hash value acquired in step 2945 to the index search query generation unit 2128, and uses the output as the index hash table search query. For example, if the hash value of the plaintext is (16), the following hash table search query (17-2) is acquired (step 2945).
  • Hash table search query for index (0500) Index search query generator (encryption key, search key, “0500”) (17-2)
  • the database wrapper unit 212 inputs the hash value acquired in step 2940 and the ID key acquired from the key management unit 2125 to the index encryption unit 2120 and performs encryption for insertion into the hash table 362B as output.
  • Get hash value For example, when the plaintext hash value (16) is “0500” and the ID key is “ID_key — 4”, the encrypted hash value is “INEc (ID_key — 4,0500)” (step 2950).
  • the database wrapper unit 212 executes a secret index update target ID table acquisition SQL for acquiring a table of ID column values of the record group to be updated using the hash table 362B and the mapping table 363, and performs update target Get the ID table.
  • the database wrapper unit 212 uses the encrypted search query for the update source value acquired in step 2910, the mapping table name and hash table name related to the update source column acquired in step 2915, and the update source value.
  • the index hash table search query is input, the hash table 362B and the mapping table 363 are searched, the search range of the encryption main table 361B is limited, and the SQL for obtaining the update target ID table is executed. Output as update target ID table.
  • the ciphertext secret index update target ID table acquisition SQL (18-2) is generated and transmitted to the database control unit 311 via the database interface unit 213.
  • the execution result is acquired as an update target ID table (step 2955).
  • SELECT ID FROM encryption main table 361BX JOIN SELECT ID decryption part (@ID key, encryption ID) AS TempID FROM mapping table MT1 JOIN
  • the database wrapper unit 212 acquires the number of update target IDs from the update target ID table obtained in step 2955, and generates an updated value ciphertext list for that number.
  • the plaintext update SQL is (13)
  • the number of update target IDs is two, “3” and “1000000”, as in step 1335 of FIG. 13 in the first embodiment.
  • the ciphertext lists of the latter values are Enc (angina) and Enc (angina). If probabilistic encryption is used, these are different ciphertexts (step 2960).
  • the database wrapper unit 212 receives plaintext update SQL, various information acquired in Step 2910, Step 2915, Step 2945, Step 2950, Step 2955, and Step 2960 as input, and updates the ciphertext update SQL for the secret index. Output. Specifically, first, an index match search is performed on the hash table 362B with an index hash table search query of the updated value, and if the hash table 362B does not match, the encrypted hash value of the updated value and the new MapID value The SQL for inserting the record consisting of the above into the hash table 362B is generated. Second, SQL for acquiring the MapID of the updated value is generated from the hash table 362B.
  • an update SQL for replacing the ciphertext of the updated value is generated.
  • an SQL is generated that replaces the value of the “MapID” column of the record having the update target ID with the MapID obtained in the second SQL.
  • the plaintext update SQL is (13)
  • the first SQL is the following update SQL (19-2)
  • the second SQL is the following update SQL (20-2)
  • the third SQL is Is the update SQL (21-2)
  • the fourth SQL is the following update SQL (22-2) and (23-2).
  • a ciphertext update SQL composed of these four SQL texts is output (step 2965).
  • INSERT INTO hash table HT1 MapID, encrypted hash value
  • SELECT * FROM hash table HT1 WHERE index match comparison part Index hash table search query, encrypted hash value)
  • LIMIT 1 SELECT * FROM hash table HT1 WHERE index match comparison part ( Index hash table search query, encrypted hash value) ) LIMIT 1; (19-2) SELECT MapID FROM hash table HT1 WHERE index match comparison part ( Index hash table search query, encrypted hash value)) (20-2)
  • UPDATE Encryption main table X JOIN Update target ID table Y ON X.ID Y.ID SET X.
  • the database wrapper unit 212 transmits the ciphertext update SQL output in step 2935 or step 2965 to the database interface unit 213.
  • the database wrapper unit 212 outputs the encrypted SQL statements (19-2), (20-2), (21) output by the step. -2), (22-2) and (23-2) are transmitted to the database interface unit 213 (step 2970).
  • the database wrapper unit 212 ends the secret index update query generation process (FIG. 30).
  • FIG. 14 shows the flow of the update target ID list acquisition process executed by the database control unit 311 in the cloud system side server 4.
  • the database control unit 311 performs the same process as in FIG. Do.
  • the update target ID list acquisition process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • all IDs of records whose update target column values match the encrypted search query are acquired from the encrypted main table 361B (step 1410).
  • the acquisition result is transmitted to the database interface unit 213 (step 1420), and the process of FIG.
  • the ciphertext search SQL is (18-2)
  • the elements of the update target ID list are “3” and “1000000”.
  • FIG. 31 is a flowchart showing a secret index update target ID table acquisition process executed by the database control unit 311 in the cloud system side server 4 of the second embodiment.
  • the secret index update target ID table acquisition process starts when the database control unit 311 receives the ciphertext search SQL from the database interface unit 213.
  • the database control unit 311 acquires the MapID of a record that matches the index hash table search query from the hash table 362B (step 3010).
  • the database control unit 311 acquires a record group HashResult having a MapID that matches the MapID acquired in Step 3010 from the mapping table 363 (Step 3020).
  • the database control unit 311 inputs the encrypted hash value of the record of the hash table 362B matched in step 3010 and the index ash table search query to the ID key acquisition unit 3123, and acquires the ID key as an output.
  • the acquired ID key and HashResult encryption ID are input to the ID decryption unit 3124, and the ID group obtained as an output is defined as IDResult (3030).
  • the database control unit 311 has the ID included in the ID group included in the ID Result acquired in Step 3030 from the encryption main table 361B, and the value of the “disease name” column that is the update source column is the encrypted search query. Are acquired and stored as an update target ID table (step 3040). Finally, the database control unit 311 transmits the acquisition result to the database interface unit 213 (3050), and ends the confidential index update target ID table acquisition process (FIG. 31). For example, when the ciphertext search SQL is (18-2), the update target ID table is a table storing “3” and “1000000” as ID column values.
  • FIG. 32 is a flowchart showing a secret index update process executed by the database control unit 311 in the cloud system side server 4 of the second embodiment.
  • the secret index update process starts when the database control unit 311 receives the ciphertext update SQL from the database interface unit 213.
  • the update SQL of the ciphertext received by the database control unit 311 at the start of the secret index update process is SQL (19-2), (20-2), (21-2), (22-2), and (23 -2).
  • the database control unit 311 acquires the hash table 362B and index hash table search query to be updated from the first SQL of the ciphertext update SQL (19-2), and the user definition function unit 312
  • the index match comparison unit 3122 searches for a record in which the value of the “encrypted hash value” column of the hash table matches the index hash table search query (step 3110).
  • step 3110 If the result of step 3110 exists (YES), the database control unit 311 acquires MapID from the matched record, and sets the acquired MapID as MapID_New (step 3120).
  • step 3110 if the result of step 3110 does not exist, the database control unit 311 generates a new MapID, sets the generated MapID to MapID_new, and inserts it into the hash table 362B together with the encrypted hash value “INEnc (ID_key — 4,0500)”. (Step 3130).
  • the database control unit 311 updates the value of the update target column of the record for the record having the update target ID in the encryption main table 361B, and further selects an encryption ID that matches the ID of the record.
  • the value in the “MapID” column of the record of the mapping table 363 is MapID_New (step 3140).
  • the database control unit 311 deletes the record having the MapID that does not exist in the “MapID” column of the mapping table 363 from the hash table 362B (Step 3150).
  • the database control unit 311 transmits the update result to the database interface unit 213 (3160).
  • the secret index update process (FIG. 32) is completed.
  • FIG. 33 is a flowchart showing a secret index deletion query generation process executed by the database wrapper unit 212 in the user system side server 3 of the second embodiment.
  • the secret index deletion query generation process starts when the database wrapper unit 212 receives a plaintext deletion SQL from the application unit 211.
  • the plaintext deletion SQL received by the database wrapper unit 212 at the start of the secret index deletion query generation process is the following SQL (22).
  • the database wrapper unit 212 extracts the value of the target column of the deletion condition from the plaintext deletion SQL, acquires the encryption key and the search key from the key management unit 2125, and inputs them to the search query generation unit 2122. And an encrypted search query is obtained as its output.
  • the plaintext SQL is (21)
  • the encrypted search query is the following execution expression (2) (step 3220).
  • Encrypted search query (diabetes) search query generator (encryption key, search key, "diabetes") (2)
  • the database wrapper unit 212 acquires “mapping table name” and “hash table name” of the search target column from the secret index map table 262B. Specifically, the database wrapper unit 212 searches the secret index map table 262B using the combination of the schema name, encryption main table name, and column name that is the object of the deletion condition in the plaintext deletion SQL as a schema name. Then, the “mapping table name” and “hash table name” of the record whose encrypted main table name and column name match are acquired. For example, when the plain text search SQL is (22), from the record 2621 where the schema name is “medical information”, the encrypted main table name is “patient information”, and the column name is “disease name”. The mapping table name “MT1” and the hash table name “HT1” are acquired (step 3230).
  • step 3240 the database wrapper unit 212 determines whether or not the result of step 3230 exists (step 3240).
  • the database wrapper unit 212 performs a deletion SQL conversion process that does not use the hash table 362B. Specifically, the database wrapper unit 212 replaces the value of the target column of the plaintext SQL deletion condition with the encrypted search query generated in step 3220, and further converts the match comparison sentence of the WHERE clause to the user-defined function unit.
  • the ciphertext deletion SQL replaced with the format for calling the ciphertext match comparison unit 3121 of 312 is output. For example, when the plaintext SQL is (22) and the encrypted search query is (2), the ciphertext deletion SQL is the following ciphertext SQL (23) (step 3250). DELETE FROM Medical information.Patient information WHERE Ciphertext match comparison unit (disease name, encrypted search query (diabetes)) (23)
  • step 3230 if the result of step 3230 exists (YES), the database wrapper unit 212 performs processing from hash value generation to secret index deletion SQL conversion (steps 3260 to 3280) in order to perform deletion using the hash table 362B.
  • the deletion SQL of the ciphertext that has been performed is output.
  • the database wrapper unit 212 inputs the value of the target column of the deletion condition to the hash value generation unit 2123 and acquires the output hash value. For example, when the plaintext deletion SQL is (22), the hash value (4) is acquired (step 3260).
  • the database wrapper unit 212 inputs the hash value acquired in step 3260 to the index search query generation unit 2128, and uses the output as an index hash table search query. For example, if the hash value of the plaintext is (4), the following index hash table search query (5-2) is acquired (step 3770).
  • Index hash table search query (1012) index search query generation unit (encryption key, search key, “1012”) (5-2)
  • the database wrapper unit 212 uses the secret index SQL conversion unit 2127 to search the hash table 362B to limit the search range, and then generate an SQL for executing deletion from the encrypted main table 361B.
  • the search SQL conversion for the secret index is performed. Specifically, the encrypted search query obtained in step 3220, the mapping table name and hash table name obtained in step 3230, and the index hash table search query obtained in step 3770 are input, and hash table 362B is indexed.
  • the value of the “MapID” column of the corresponding record is obtained by searching with the hash table search query for the mapping, and the ID of the mapping table 363 having the value of the “MapID” column equal to that value is decrypted to obtain the ID , And a record having a value that matches the encrypted search query is determined from the records of the encrypted main table 361B having the ID by using the ciphertext match comparison unit 3121 of the user definition function unit 312. Is deleted from the encryption main table 361B. To generate the SQL that. Furthermore, an SQL for deleting a record including a MapID that does not exist in the map ID column “MapID” of the mapping table 363 is generated from the hash table 362B.
  • the database wrapper unit 212 transmits the ciphertext deletion SQL output in step 3250 or step 3280 to the database interface unit 213. If the plaintext deletion SQL is (22), the result of step 3240 exists, so the database wrapper unit 212 causes the ciphertext search SQL (24-2), (25-2), and (26) output by step 3280 to exist. -2) is transmitted to the database interface unit 213 (step 3290). As described above, the database wrapper unit 212 ends the secret index deletion query generation process (FIG. 32).
  • FIG. 34 is a flowchart showing a secret index deletion process executed by the database control unit 311 in the cloud system side server 4 of the second embodiment.
  • the secret index deletion process starts when the database control unit 311 receives the ciphertext deletion SQL from the database interface unit 213.
  • the ciphertext deletion SQL received by the database control unit 311 at the start of the secret index deletion processing is SQL (24-2) (25-2) and (26-2).
  • the database control unit 311 identifies the hash table 362B and the index hash table search query that are subject to the deletion condition from the ciphertext deletion SQL, and the hash match search unit 3122 of the user definition function unit 312 performs the hash search.
  • the record in which the value of the “encrypted hash value” column of the table 362B matches the hash table search query for the index is specified, and the value of the “MapID” column of the record is acquired as MapID_hit.
  • the hash table 362B is the hash table 362B, and as a result of the match comparison by the index match comparison unit 3122, Matches the encrypted hash value “INEnc (ID_key — 2, 1012)” of the record 3622B of the hash table 362B, and acquires MapID “2” of the record as MapID_hit (step 3310).
  • the database control unit 311 specifies a record group HashResult whose value in the “MapID” column matches MapID_hit from the mapping table 363. For example, when the ciphertext deletion SQL is (24-2) (25-2) and (26-2), the records 3632 and 3633 whose MapID_hit is “2” are HashResult (step 3320).
  • the database control unit 311 inputs the index hash table search query and the encrypted hash value of the record hit in step 3310 to the ID key acquisition unit 3123, acquires the ID key as an output, and acquires the ID key.
  • the key and the encryption ID of HashResult are input to the ID decryption unit 3124, and the ID group acquired as an output is defined as IDResult.
  • the IDResult is “3, 1000000” (step 3330).
  • the database control unit 311 deletes the record having the ID included in the IDResult and the value matching the encrypted search query from the encryption main table 361B, and further mapping with the encryption ID matching the record The record in the table 363 is deleted (step 3340).
  • the database control unit 311 deletes the record including the MapID that does not exist in the mapping table 363 from the hash table 362B (Step 3350).
  • the database control unit 311 transmits the ciphertext deletion SQL result to the database interface unit 213 (step 3360).
  • the secret index deletion process (FIG. 34) is completed.
  • FIG. 35 is a flowchart showing the mapping table rearrangement query generation process of the second embodiment.
  • the database wrapper unit 212 sets the mapping table 363 at the time of generating the mapping table 363 or at an arbitrary timing so that the order of the records in the mapping table 363 does not match the order of the IDs of the corresponding records in the encrypted main table 361B.
  • a rearrangement SQL for rearranging the records in a random order is generated (step 3410) and transmitted to the database control unit 311 (step 3420).
  • FIG. 36 is a flowchart showing the mapping table rearrangement process of the second embodiment.
  • the database control unit 311 Upon receiving the rearrangement SQL from the database wrapper unit 212, the database control unit 311 rearranges the records in the mapping table 363 at random (step 3510), and transmits the result to the database wrapper unit 212 (step 3520).
  • the hardware and software configuration of the concealment database system 1 according to the third embodiment of the present invention is the second embodiment.
  • the configuration is the same as that described in the example (FIG. 19).
  • the third embodiment differs from the second embodiment in that the frequency deviation of map IDs in the mapping table 363B is leveled and the appearance frequency is concealed.
  • FIG. 37 shows a logical configuration of the database wrapper unit 212 of the third embodiment.
  • the database wrapper unit 212 of the third embodiment is different from the second embodiment (FIG. 20) in that it has a map ID frequency distribution leveling query generation unit 21201 for leveling the appearance frequency of map IDs in the mapping table 363B. That is.
  • FIG. 38 shows the data structure of the mapping table 363B before the frequency distribution leveling of the third embodiment.
  • the difference between the mapping table 363B of the third embodiment and the mapping table 363 of the second embodiment (FIG. 24) is that a sample record is added to indicate the deviation in the frequency of MapID.
  • the frequency of MapID “1” is 2
  • the frequency of MapID “2” is 3
  • the frequencies of MapID “3” and “10” are 1.
  • the rest is the same as the second embodiment.
  • FIG. 39 shows the data structure of the mapping table 363C after frequency distribution leveling in the third embodiment.
  • the mapping table 363C after leveling differs from the mapping table 363B before leveling in that it includes a simulated record for leveling the frequency of MapID.
  • the simulated record has a value generated by a random number of bit strings of the same type as the encryption ID instead of the encryption ID. For example, in FIG. 39, as a result of adding simulated records 3631C to 3635C, the frequency of all MapIDs is 3.
  • the configuration of the information processing system according to the third embodiment other than FIGS. 37, 38 and 39 is the same as that of the second embodiment described in the section 2-1.
  • FIG. 40 is a flowchart showing map ID frequency distribution leveling query generation processing executed by the database wrapper unit 212 in the user system side server 3 of the third embodiment.
  • the map ID frequency distribution leveling query generation process starts when the database wrapper unit 212 receives a leveling request from the application unit 211 or the like.
  • the database wrapper unit 212 acquires the frequency for each value of the “MapID” column from the mapping table 363B before leveling. For example, in the mapping table 363B before leveling shown in FIG. 38, the frequency of MapID “1” is 2, the frequency of MapID “2” is 3, and the frequencies of MapID “3” and “10” are 1. is there.
  • the database wrapper unit 212 determines whether the frequency of each value of MapID is the same, and if it is the same (YES), ends the process.
  • the database wrapper unit 212 sets the maximum frequency among the frequencies acquired in step 3910 as Nmax.
  • Nmax is 3 which is the frequency of MapID “2” (step 3930).
  • the database wrapper unit 212 generates random numbers for each value of MapID other than the maximum frequency by the number of differences between Nmax and the frequency of each value, and maps a record composed of a pair of each value of the random number
  • a frequency distribution leveling SQL to be inserted into the table 363B is generated. For example, in the case of the mapping table 363B before leveling, SQL for inserting the simulation records 3631C to 3635C shown in FIG. 39 is generated (step 3940).
  • the database wrapper unit 212 transmits the frequency distribution leveling SQL generated in step 3940 to the database interface unit 213, and ends the map ID frequency distribution leveling query generation process (FIG. 40).
  • FIG. 41 is a flowchart showing map ID frequency distribution leveling processing executed by the database control unit 311 in the cloud system side server 4 of the third embodiment.
  • the database control unit 311 receives the frequency distribution leveling SQL from the database wrapper unit 212
  • the record specified in the SQL is inserted into the mapping table 363B (step 4010).
  • the insertion result is transmitted to the database wrapper (step 4020).
  • the appearance of MapID is obtained by leveling the distribution of the appearance frequency of MapID in the mapping table 363. Since the frequency is concealed, a safer search can be performed than in the second embodiment.
  • the database wrapper unit 212 processes the encrypted data on the cloud system side server 4 when receiving the plain text SQL text for searching the encrypted data.
  • the database control unit 311 searches the hash table by executing the received encrypted SQL sentence, and the encryption The range of the encrypted data is limited, the user-defined function unit 312 (ciphertext match comparison unit 3121) performs a match comparison indicated by the encrypted SQL statement on the limited range of encrypted data, and the database control unit 311 Since the execution result of the encrypted SQL statement is transmitted to the server 3 on the user system side, the encrypted large-capacity encryption In search of the main table 361, by reducing the record to be retrieved by searching the hash table 362 in advance, it can be retrieved at a high speed.
  • the user system side server 3 sends the SQL statement for processing the encrypted data from the user terminal 2 used by the data owner via the user internal network 5 of the equipment provided with the user system side server 3.
  • the user system side server 3 receives the SQL statement for processing the encrypted data and sends it to the cloud system side server 4 via the external network 6. Data can be retrieved at high speed.
  • the hash table 362 includes a map ID that is an identifier of each record of the encrypted main table 361 and the hash value, and the encrypted main table 361 is an identifier corresponding to the hash value stored in the hash table 362.
  • the database control unit 311 includes the map ID, the database control unit 311 searches the hash table 362 using the hash value as a keyword, acquires the map ID of the record having the matched hash value, and the encrypted main table 361 having the acquired map ID. Therefore, the search target can be narrowed down using the map ID recorded in the hash table 362.
  • the database control unit 311 associates the map ID of the encrypted main table 361 with the map ID of the hash table, and hashes the record including the map ID that does not exist in the encrypted main table 361 but exists in the hash table 362. Since the data is deleted from the table 362, unnecessary data can be deleted to speed up the search and reduce the resources used.
  • the database wrapper unit 212 generates a hash table search query for performing a match search between the hash value of the data to be searched and the encrypted hash value stored in the hash table 362, and the database control unit 311 Since the ciphertext match comparison unit 3121 makes a match determination between the hash table search query and the encrypted hash value, enlargement of the hash table 362 can be prevented.
  • the user system side server 3 has a secret index map table 262 that stores information indicating a relationship with a hash table that stores an encrypted hash value corresponding to the original data, and the database wrapper unit 212 includes a secret index map.
  • the SQL main statement 361 is searched without generating the SQL statement for searching the hash table 362. Since an SQL sentence is generated, even when an index based on a hash value cannot be used, a high-speed search can be performed.
  • the database wrapper unit 212 updates the encryption main table 361 with the encrypted data subjected to the stochastic encryption
  • the database wrapper unit 212 acquires all the identifiers of the update target records in the encryption main table 361, and acquires the identifier of the acquired identifier. Since the ciphertext of the updated data corresponding to the number is generated and the SQL text for updating the plurality of records corresponding to the number of the identifiers is generated, the search can be performed at high speed without reducing the strength of the cipher.
  • the database wrapper unit 212 has a plurality of SQLs having a length that does not exceed the restriction on the maximum length of the SQL sentence. Since a sentence is generated, a plurality of writing processes can be executed in parallel to speed up the process.
  • the encryption main table 361B does not include an identifier map ID corresponding to the encryption hash value stored in the hash table 362B, and the cloud system side server 4 stores an identifier corresponding to each record of the encryption main table 361B.
  • the database wrapper unit 212 includes a mapping table 363 including an encrypted encryption ID and a map ID that is an identifier corresponding to a hash value stored in the hash table 362 corresponding to the encryption ID.
  • the encryption ID of the mapping table corresponding to the map ID acquired from 362B is acquired, the acquired encryption ID is temporarily decrypted, and the search range of the encrypted data is determined by the identifier obtained by decrypting the encryption ID.
  • the encryption main table 361B To hide the correspondence between the over soil and map ID, it is possible to perform a more secure search.
  • the database wrapper unit 212 includes a mapping table rearrangement query generation unit that generates a query for rearranging the mapping table records
  • the database control unit 311 includes an SQL generated by the mapping table rearrangement query generation unit. Since the mapping table records are rearranged according to the sentence, the correspondence between the records in the encrypted main table 361B and the mapping table 363 is concealed so that the record order of the encrypted main table 361B and the mapping table 363 is not the same. And you can search more safely.
  • the database wrapper unit 212 acquires the map ID frequency of the mapping table, and generates a query for inserting a pseudo record for equalizing the acquired frequency into the mapping table.
  • the database control unit 311 has a query generation unit, and inserts the pseudo record into the mapping table in accordance with the SQL statement generated by the map ID frequency distribution leveling query generation unit, so the appearance frequency of the map ID in the mapping table 363 Can be leveled and the appearance frequency of map IDs can be concealed for safer search.
  • the present invention is not limited to the above-described embodiments, and includes various modifications and equivalent configurations within the scope of the appended claims.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment may be replaced with the configuration of another embodiment.
  • another configuration may be added, deleted, or replaced.
  • each of the above-described configurations, functions, processing units, processing means, etc. may be realized in hardware by designing a part or all of them, for example, with an integrated circuit, and the processor realizes each function. It may be realized by software by interpreting and executing the program to be executed.
  • Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, and an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, and a DVD.
  • a storage device such as a memory, a hard disk, and an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, and a DVD.
  • control lines and information lines indicate what is considered necessary for the explanation, and do not necessarily indicate all control lines and information lines necessary for mounting. In practice, it can be considered that almost all the components are connected to each other.
  • the present invention provides a customer with a function of depositing encrypted data with a key on the user system side to a cloud operator, and searching and analyzing a large amount of encrypted data deposited by the cloud operator while encrypting the data. It can be widely applied to information processing systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un système de base de données chiffrée dans laquelle : une unité d'enveloppement de base de données convertit une instruction SQL en texte en clair pour rechercher des données codées en une instruction SQL codée pour traiter les données codées sur le système central ; dans le système central, un organe de commande de base de données cherche dans une table de hachage et limite la portée des données codées par l'exécution de l'instruction SQL codée reçue ; une unité de comparaison de correspondance de texte codé effectue une comparaison de correspondance, spécifiée par l'instruction SQL codée, sur les données codées dont la portée a été limitée ; l'unité de commande de base de données transmet les résultats de l'exécution de l'instruction SQL codée à un système utilisateur ; et l'unité d'enveloppement de base de données décode les résultats de l'exécution de l'instruction SQL reçue et délivre en sortie les résultats de recherche des données codées.
PCT/JP2016/062826 2015-04-22 2016-04-22 Système de base de données chiffrée et procédé de gestion de données chiffrées WO2016171271A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-087303 2015-04-22
JP2015087303A JP6449093B2 (ja) 2015-04-22 2015-04-22 秘匿化データベースシステム及び秘匿化データ管理方法

Publications (1)

Publication Number Publication Date
WO2016171271A1 true WO2016171271A1 (fr) 2016-10-27

Family

ID=57144518

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/062826 WO2016171271A1 (fr) 2015-04-22 2016-04-22 Système de base de données chiffrée et procédé de gestion de données chiffrées

Country Status (2)

Country Link
JP (1) JP6449093B2 (fr)
WO (1) WO2016171271A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6351890B1 (ja) * 2017-05-18 2018-07-04 三菱電機株式会社 検索装置、秘匿検索システム及び検索プログラム
WO2018154581A1 (fr) * 2017-02-22 2018-08-30 Kindite Ltd. Chiffrement d'enregistrements de données et traitement d'enregistrements chiffrés sans dévoiler un texte clair
CN110008448A (zh) * 2019-04-02 2019-07-12 中国工商银行股份有限公司 将SQL代码自动转换为Java代码的方法和装置
CN113050878A (zh) * 2019-12-27 2021-06-29 北京兆易创新科技股份有限公司 一种开卡划分块的方法和装置
CN115694921A (zh) * 2022-10-12 2023-02-03 浪潮卓数大数据产业发展有限公司 一种数据存储方法、设备及介质

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101979320B1 (ko) * 2017-05-18 2019-05-16 뱅크웨어글로벌 주식회사 메타정보 및 엔터프라이즈 프레임웍을 이용한 암호화 ｓｑｌ문 자동 생성 시스템 및 방법
US10846423B2 (en) * 2017-08-11 2020-11-24 Palo Alto Research Center Incorporated System and architecture for analytics on encrypted databases
KR101881856B1 (ko) * 2017-08-31 2018-08-24 주식회사 스파이스웨어 클라우드 네트워크 환경에서 데이터 암호화 및 복호화 처리 방법
US10728022B2 (en) * 2017-12-28 2020-07-28 Fujitsu Limited Secure hash operations in a trusted execution environment
JPWO2020158842A1 (fr) * 2019-02-01 2020-08-06
JP7249248B2 (ja) * 2019-08-30 2023-03-30 株式会社日立製作所 秘匿情報処理システム及び秘匿情報処理方法
JP7381893B2 (ja) 2020-04-14 2023-11-16 富士通株式会社 検索方法、検索プログラム、および秘密情報検索システム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11143780A (ja) * 1997-11-05 1999-05-28 Hitachi Ltd データベースにおける秘密情報管理方法およびデータベースの秘密情報管理装置
JP2012084084A (ja) * 2010-10-14 2012-04-26 Fujitsu Ltd 連携装置、連携元装置、連携先装置、連携プログラム、および連携方法
JP2012248940A (ja) * 2011-05-25 2012-12-13 Mitsubishi Electric Corp データ生成装置、データ生成方法、データ生成プログラム及びデータベースシステム
JP2014098990A (ja) * 2012-11-13 2014-05-29 Fujitsu Ltd 検索処理方法、データ生成方法及び情報処理装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11143780A (ja) * 1997-11-05 1999-05-28 Hitachi Ltd データベースにおける秘密情報管理方法およびデータベースの秘密情報管理装置
JP2012084084A (ja) * 2010-10-14 2012-04-26 Fujitsu Ltd 連携装置、連携元装置、連携先装置、連携プログラム、および連携方法
JP2012248940A (ja) * 2011-05-25 2012-12-13 Mitsubishi Electric Corp データ生成装置、データ生成方法、データ生成プログラム及びデータベースシステム
JP2014098990A (ja) * 2012-11-13 2014-05-29 Fujitsu Ltd 検索処理方法、データ生成方法及び情報処理装置

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018154581A1 (fr) * 2017-02-22 2018-08-30 Kindite Ltd. Chiffrement d'enregistrements de données et traitement d'enregistrements chiffrés sans dévoiler un texte clair
US11361099B2 (en) 2017-02-22 2022-06-14 Ringcentral, Inc. Encrypting data records and processing encrypted records without exposing plaintext
US11366921B2 (en) 2017-02-22 2022-06-21 Ringcentral, Inc. Encrypting data records and processing encrypted records without exposing plaintext
JP6351890B1 (ja) * 2017-05-18 2018-07-04 三菱電機株式会社 検索装置、秘匿検索システム及び検索プログラム
CN110008448A (zh) * 2019-04-02 2019-07-12 中国工商银行股份有限公司 将SQL代码自动转换为Java代码的方法和装置
CN110008448B (zh) * 2019-04-02 2023-10-17 中国工商银行股份有限公司 将SQL代码自动转换为Java代码的方法和装置
CN113050878A (zh) * 2019-12-27 2021-06-29 北京兆易创新科技股份有限公司 一种开卡划分块的方法和装置
CN115694921A (zh) * 2022-10-12 2023-02-03 浪潮卓数大数据产业发展有限公司 一种数据存储方法、设备及介质
CN115694921B (zh) * 2022-10-12 2024-05-28 浪潮卓数大数据产业发展有限公司 一种数据存储方法、设备及介质

Also Published As

Publication number Publication date
JP6449093B2 (ja) 2019-01-09
JP2016206918A (ja) 2016-12-08

Similar Documents

Publication Publication Date Title
JP6449093B2 (ja) 秘匿化データベースシステム及び秘匿化データ管理方法
US11726993B1 (en) Systems and methods for cryptographically-secure queries using filters generated by multiple parties
US11709948B1 (en) Systems and methods for generation of secure indexes for cryptographically-secure queries
US7519835B2 (en) Encrypted table indexes and searching encrypted tables
US9235725B2 (en) Client computer for querying a database stored on a server via a network
US8533489B2 (en) Searchable symmetric encryption with dynamic updating
US10685132B1 (en) Methods and apparatus for encrypted indexing and searching encrypted data
EP3356988A1 (fr) Procédé et système de chiffrement symétrique vérifiable et consultable
CN112800088A (zh) 基于双向安全索引的数据库密文检索系统及方法
US7930560B2 (en) Personal information management system, personal information management program, and personal information protecting method
US11256662B2 (en) Distributed ledger system
CN101587479A (zh) 面向数据库管理系统内核的数据加解密系统及其方法
CN103607405A (zh) 一种面向云存储的密文搜索认证方法
US9946720B1 (en) Searching data files using a key map
WO2013084957A1 (fr) Dispositif de base de données de recherche codée, procédé permettant d'ajouter et de supprimer des données pour une recherche codée, et programme d'ajout/de suppression
EP3296980B1 (fr) Système de base de données et procédé de traitement de base de données
CN115455463A (zh) 一种基于同态加密的隐匿sql查询方法
US20210182314A1 (en) Systems and methods for on-chain / off-chain storage using a cryptographic blockchain
Li et al. Forward and backward secure searchable encryption scheme supporting conjunctive queries over bipartite graphs
Almarwani et al. Release-aware encryption adjustment query processing for document database
Demertzis Improving Efficiency, Expressiveness and Security of Searchable Encryption
JPWO2016002198A1 (ja) 検索補助データ格納装置、検索装置、追加装置、削除装置、検索依頼装置、追加依頼装置、削除依頼装置、データ検索システム、データ検索方法、および、コンピュータプログラム
EP4154147A1 (fr) Serveur de stockage de données et dispositifs clients pour stockage sécurisé de données
Jammalamadaka et al. A middleware approach for building secure network drives over untrusted internet data storage
CN116089976A (zh) 关系型数据库的管理方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16783292

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16783292

Country of ref document: EP

Kind code of ref document: A1