Patent Publication Number: US-2021176065-A1

Title: Storage system and data protection method for storage system

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application claims priority from Japanese application JP 2019-219834, filed on Dec. 4, 2019, the contents of which is hereby incorporated by reference into this application. 
     BACKGROUND 
     The present invention relates to a storage system capable of authenticating encrypted data and a data protection method for the storage system. 
     NVMe over Fabrics is a protocol that extends NVMe (Non Volatile Memory express) transactions to a network. 
     In order to protect, by using NVMe over Fabrics, data to be stored in a storage node from a storage controller, it is necessary to encrypt data passing a network (hereinafter, will be referred to as communication data encryption) in addition to the encryption of data to be stored in the storage node (hereinafter, will be referred to as stored data encryption). 
     In this case, for sharing encryption between the storage controller and the storage node, two methods are available as follows: 
     In the first method, data is encrypted by the storage controller according to communication data encryption, the encrypted data is transmitted from the storage controller to the storage node via the network, the data encrypted according to communication data encryption is decrypted by the storage node, and the decrypted data is stored after being encrypted by the storage controller according to stored data encryption. 
     In the second method, data is encrypted by the storage controller according to stored data encryption, the encrypted data is encrypted by the storage controller according to communication data encryption, the encrypted data having undergone the double encryption of stored data encryption and communication data encryption is transmitted from the storage controller to the storage node via the network, and the encrypted data having undergone the double encryption is subjected to communication data decryption by the storage node, so that the data subjected to single encryption according to stored data encryption is stored. 
     Japanese Patent Application Publication No. 2006-304215 discloses a method in which an encryption unit on a PC encrypts input data with a public key and generates hash data from the data of input data, and the encrypted data is stored on a server over the network. A decryption unit on a PC gets the encrypted data over the network from the server and decrypts the encrypted data using a private key, generates hash data from the decrypted data, and confirms whether the hash data is correct or not, so that the correctness of key data is confirmed. 
     SUMMARY 
     In the first encryption, however, it is necessary to perform communication data decryption and stored data encryption in the storage node, resulting in a heavy load to the storage node. In the second encryption, it is necessary to perform stored data encryption and communication data encryption in the storage controller, resulting in a heavy load to the storage controller. 
     Furthermore, Japanese Patent Application Publication No. 2006-304215 discloses that hash data is used to confirm, at a writing source, the correctness of key data used for encryption, but does not disclose a method for authenticating encrypted data at a writing destination. 
     The present invention has been devised in view of the circumstances. An object of the present invention is to provide a storage system and a data protection method for the storage system, by which data storage and safe communications are ensured while reducing the load of encryption. 
     In order to attain the object, a storage system according to a first aspect includes a controller to which an authentication key is allocated, and a node, wherein the controller is configured to generate encrypted data in which the data is encrypted using a data encryption key, generate an authentication code based on the encrypted data using the authentication key, and transmit the encrypted data and the authentication code to the node, the node is configured to receive the encrypted data and the authentication code that are transmitted from the controller, store the encrypted data and the authentication code, and transmit the encrypted data and the authentication code that are stored to the controller, and the controller is further configured to receive the encrypted data and the authentication code that are transmitted from the node, and decrypt the encrypted data based on a verification result of the authentication code transmitted from the node. 
     According to the present invention, data storage and safe communications are ensured while reducing the load of encryption. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to a first embodiment is applied; 
         FIG. 2  indicates an example of a mapping table used for the storage controller of  FIG. 1 ; 
         FIG. 3  indicates an example of a data-encryption-key management table used for the storage controller of  FIG. 1 ; 
         FIG. 4  indicates an example of an authentication-key correspondence table used for the storage controller of  FIG. 1 ; 
         FIG. 5  indicates another example of the authentication-key correspondence table used for the storage controller of  FIG. 1 ; 
         FIG. 6  indicates an example of an authentication code table used for the storage controller of  FIG. 1 ; 
         FIG. 7  is a flowchart indicating the writing of the storage controller of  FIG. 1 ; 
         FIG. 8  is a flowchart indicating the writing of the storage nodes of  FIG. 1 ; 
         FIG. 9  is a flowchart indicating the reading of the storage controller of  FIG. 1 ; 
         FIG. 10  is a flowchart indicating the reading of the storage nodes of  FIG. 1 ; 
         FIG. 11  indicates an example of information exchanged between the storage controller and the storage nodes of  FIG. 1 ; 
         FIG. 12  is a flowchart indicating the writing of a storage controller according to a second embodiment; 
         FIG. 13  is a flowchart indicating the reading of the storage controller according to the second embodiment; 
         FIG. 14  is a flowchart indicating the writing of the storage nodes according to the second embodiment; 
         FIG. 15  indicates a method of confirming whether a sequence number is a previously used number; 
         FIG. 16  is a flowchart indicating the reading of storage nodes according to the second embodiment; 
         FIG. 17  is a flowchart indicating the reading of a storage controller according to a third embodiment; 
         FIG. 18  is a flowchart indicating the reading of a storage controller according to a fourth embodiment; 
         FIG. 19  is a flowchart indicating the reading of a storage controller according to a fifth embodiment; 
         FIG. 20  is a flowchart indicating the reading of storage nodes according to a sixth embodiment; 
         FIG. 21  is a flowchart indicating the reading of a storage controller according to the sixth embodiment; 
         FIG. 22  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to a seventh embodiment is applied; 
         FIG. 23  is a block diagram illustrating the configurations of storage controllers and storage nodes to which an encryption apparatus according to an eighth embodiment is applied; 
         FIG. 24  is a block diagram illustrating the configurations of hosts and storage nodes to which an encryption apparatus according to a ninth embodiment is applied; 
         FIG. 25  is a block diagram illustrating the configurations of storage controllers and storage nodes to which an encryption apparatus according to a tenth embodiment is applied; 
         FIG. 26  is a block diagram illustrating the configurations of a storage controller and a storage to which an encryption apparatus according to an eleventh embodiment is applied; and 
         FIG. 27  is a block diagram illustrating a hardware configuration example of the storage controller of  FIG. 1 . 
     
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
     Embodiments will be described below with reference to the accompanying drawings. The following embodiments do not limit the invention described in the claims and all elements and combinations thereof in the embodiments are not always necessary for the solutions of the invention. 
       FIG. 1  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to embodiment 1 is applied. 
     In  FIG. 1 , a host  11  is coupled to a storage controller  13  via a communication network  12 . The storage controller  13  is coupled to storage nodes  15 A and  15 B via a communication network  14 . Data can be transferred between the storage controller  13  and the storage nodes  15 A and  15 B over a network according to such as NVMe over Fabrics. 
     The storage controller  13  provides logical volumes L 1  to L 4  for the host  11  via the communication network  12 . The host  11  writes data to those logical volumes on the storage controller  13  which subsequently writes the data in capacities provided by the storage nodes  15 A and  15 B and read data from the storage controller  13  whose physical capacities are provided by the storage nodes  15 A and  15 B. The storage nodes  15 A and  15 B provide physical capacities for the storage controller  13  via the communication network  14 . 
     At this point, the logical volumes L 1  to L 4  on the storage controller  13  can be provided so as to correspond, on a one-to-one basis, to the volumes D 1  to D 4  of the storage nodes  15 A and  15 B, respectively. The volumes D 1  to D 4  are, for example, physical storage devices such as a hard disk device or an SSD (Solid State Drive). The volumes indicated in the storage nodes  15 A and  15 B may be logical volumes or physical medium units. 
     The storage controller  13  publishes the logical volumes L 1  to L 4  to the host  11 . An OS (Operating System) on the host  11  mounts the logical volumes L 1  to L 4  and performs IO of data. 
     For the logical volumes L 1  to L 4  specified from the host  11 , the storage controller  13  transfers data, which is inputted by the IO from the host  11 , between the storage nodes  15 A and  15 B and then writes or reads the data to or from the volumes D 1  to D 4  on the storage nodes  15 A and  15 B, the volumes D 1  to D 4  being provided for the respective logical volumes L 1  to L 4 . 
     In this configuration, the storage system including the storage controller  13  and the storage nodes  15 A and  15 B is provided with an encryption apparatus in order to protect storage data to be stored in the storage nodes  15 A and  15 B while protecting communication data transmitted and received between the storage controller  13  and the storage nodes  15 A and  15 B. In the encryption, the storage controller  13  performs encryption  16 A, decryption  16 B, and authentication code processing  17 , and the storage nodes  15 A and  15 B perform authentication code processing  18 A and  18 B and storage  19 A and  19 B. 
     In order to perform the encryption  16 A and the decryption  16 B, a data encryption key (hereinafter, will be also referred to as a DEK) is allocated to the storage controller  13 . In order to perform authentication code processing  17 ,  18 A, and  18 B, authentication keys (hereinafter, will be also referred to as AKs) are allocated to the storage controller  13  and the storage nodes  15 A and  15 B. At this point, the authentication keys may be allocated to the respective storage nodes  15 A and  15 B or the respective volumes D 1  to D 4 . 
     In the encryption  16 A, encrypted data is generated using the data encryption key. In the authentication code processing  17 ,  18 A, and  18 B, authentication codes are generated using the authentication keys based on the encrypted data and the authentication codes are verified. In the decryption  16 B, the encrypted data is decrypted based on the verification result of the authentication keys. In the storage  19 A and  19 B, the encrypted data is stored based on the verification result of the authentication keys. 
     In writing, for example, when receiving a data writing request for the logical volume L 1  from the host  11 , the storage controller  13  performs the encryption  16 A on data and generates encrypted data using the data encryption key allocated to the logical volume L 1 . Moreover, the storage controller  13  performs the authentication code processing  17  and generates the authentication code based on the encrypted data using the authentication key allocated to the storage node  15 A. The storage controller  13  then specifies the volume D 1 , which corresponds to the logical volume L 1 , from a mapping table  21  of  FIG. 2 , transmits the encrypted data and the authentication code for the volume D 1  to the storage node  15 A via the communication network  14 , and writes the encrypted data and the authentication code in the storage node  15 A. 
     When receiving the encrypted data and the authentication code from the storage controller  13 , the storage node  15 A performs the authentication code processing  18 A and verifies the received authentication code. When the authentication code is successfully verified, the storage node  15 A performs the storage  19 A and stores the encrypted data and the authentication code in the volume D 1 . 
     In reading, for example, when receiving a data reading request for the logical volume L 1  from the host  11 , the storage controller  13  specifies the volume D 1  corresponding to the logical volume L 1  from the mapping table  21  of  FIG. 2  and transmits a data reading request for the volume D 1  to the storage node  15 A. In response to the data reading request for the volume D 1 , the storage controller  15 A extracts the corresponding encrypted data and authentication code from the volume D 1  and transmits the encrypted data and the authentication code to the storage controller  13  via the communication network  14 . 
     When receiving the encrypted data and the authentication code from the storage node  15 A, the storage controller  13  performs the authentication code processing  17  and verifies the received authentication code. When the authentication code is successfully verified, the storage controller  13  performs the decryption  16 B and decrypts the encrypted data using the data encryption key allocated to the logical volume L 1  and sends the decrypted data to the host  11 . 
     The encryption of data transmitted from the storage controller  13  ensures the confidentiality of stored data in the storage nodes  15 A and  15 B, and the verification of the authentication code transmitted or received with encrypted data allows the checking of tampering and masquerade during data communications without implementing a communication-data encryption scheme, e.g., TLS. This eliminates the need for the encryption of communication data and the decryption of communication data in the storage controller  13  and the storage nodes  15 A and  15 B in order to protect data transferred between the storage controller  13  and the storage nodes  15 A and  15 B, thereby reducing a load for the encryption of the storage controller  13  and the storage nodes  15 A and  15 B. 
     For example, the storage controller  13  encrypts data by using a storage-data encryption scheme, e.g., AES-XTS 256 defined by IEEE P1619, and then generates a checksum for the encrypted data. From the checksum, the storage controller  13  generates the authentication code using the authentication key shared in advance with the storage nodes  15 A and  15 B. The storage controller  13  transmits the authentication code with the encrypted data to the storage nodes  15 A and  15 B. 
     The storage nodes  15 A and  15 B having received the authentication code and the encrypted data generate checksums from the encrypted data, generate the authentication codes using the authentication key shared in advance with the storage controller  13 , and verify whether the authentication codes agree with the authentication code received from the storage controller  13 . When the authentication codes are successfully verified, the storage nodes  15 A and  15 B can authenticate a transmission source and confirm the integrity of the received data. The data is encrypted according to the storage data encryption scheme during communications, so that the confidentiality is ensured. 
     Moreover, the storage nodes  15 A and  15 B store data only when the authentication code is successfully verified. This can also guarantee confidentiality and integrity when data is stored, thereby rejecting unauthorized writing from another external host or storage controller. 
       FIG. 2  indicates an example of the mapping table used for the storage controller of  FIG. 1 . 
     In  FIG. 2 , the mapping table  21  indicates the correspondence between the volume of the storage controller  13  and the volumes of the storage nodes  15 A and  15 B in  FIG. 1 . 
     In the mapping table  21 , the entries of #, Storage Controller#, Storage Controller Dev#, Storage Node#, and Storage Node Dev# are stored. # denotes an entry number. Storage Controller# denotes identification information on the storage controller. Storage Controller Dev# denotes identification information on logical volumes provided from the storage controller. Storage Node# denotes identification information on the storage nodes. Storage Node Dev# denotes identification information on volumes provided from the storage nodes. 
     The mapping table  21  of  FIG. 2  indicates an example in which the storage controller  13  of  FIG. 1  is provided with Storage Controller#=1, the logical volumes L 1  to L 4  are provided with Storage Controller Dev#1 to 4, respectively, the storage nodes  15 A and  15 B are provided with Storage Node#=1, 2, respectively, the volumes D 1  and D 2  of the storage node  15 A are provided with Storage Node Dev#=1, 2, respectively, and the volumes D 3  and D 4  of the storage node  15 B are provided with Storage Node Dev#=1, 2, respectively. 
     In this case, referring to the mapping table  21 , the storage controller  13  can determine that the logical volumes L 1  and L 2  of the storage controller  13  are mapped at the respective volumes D 1  and D 2  of the storage node  15 A and the logical volumes L 3  and L 4  of the storage controller  13  are mapped at the respective volumes D 3  and D 4  of the storage node  15 B. Thus, if the logical volume L 1  is specified as a reading or writing target from the host  11 , the storage controller  13  can actually read or write data in the volume D 1  of the storage controller  13  with reference to the mapping table  21 . 
       FIG. 3  indicates an example of a data-encryption-key management table used for the storage controller of  FIG. 1 . 
     In  FIG. 3 , a data-encryption-key management table  22  manages data encryption keys used for generating encrypted data. 
     In the data-encryption-key management table  22 , the entries of #, Storage Controller Dev#, and DEK are stored. # denotes an entry number. Storage Controller Dev# denotes identification information on logical volumes provided from the storage controller. DEK denotes identification information on data encryption keys. 
     The data-encryption-key management table  22  of  FIG. 3  indicates an example in which the logical volumes L 1  to L 4  of  FIG. 1  are provided with Storage Controller Dev# 1  to  4 , respectively, and the logical volumes L 1  to L 4  are provided with data encryption keys DEK 1  to DEK 4 , respectively. 
     In this case, the storage controller  13  can generate different data encryption keys for the respective logical volumes L 1  to L 4  with reference to the data-encryption-key management table  22 . The storage controller  13  may generate data encryption keys at the time of initialization or configuration change or may cause an external key management server (hereinafter will be also referred to as KMS) to generate data encryption keys and receive the data encryption keys from the key management server. 
       FIG. 4  indicates an example of an authentication-key correspondence table used for the storage controller of  FIG. 1 . 
     In  FIG. 4 , an authentication-key correspondence table  23  manages authentication keys used for generating authentication codes.  FIG. 4  indicates an example in which the authentication keys are allocated in units of storage nodes. 
     In the authentication-key correspondence table  23 , the entries of #, Storage Node#, and Authentication Key are stored. # denotes an entry number. Storage Node# denotes identification information on the storage nodes. Authentication Key denotes identification information on authentication keys. 
     In the case of multiple storage controllers having redundant configurations, an authentication key is shared among the storage controllers. At this point, the storage controllers with the shared authentication key can write data in the storage nodes. Each of the storage nodes manages the authentication key to be used. 
     The authentication key may be manually set for the storage controller  13  and the storage nodes  15 A and  15 B from a management UI (User Interface), may be derived from a manually set secret key, or may be shared by a key sharing algorithm, e.g., Diffie Hellman. 
     Furthermore, authentication keys may be created by an external KMS, and the storage controller  13  and the storage nodes  15 A and  15 B may receive necessary authentication keys from the KMS. At this point, access control is performed in compliance with protocols such as KMIP (Key Management Interoperability Protocol) such that only the storage controller  13  or the storage nodes  15 A and  15 B that belong to the correspondence can acquire the corresponding authentication key. 
     For example, the storage controller  13  instructs the KMS to create a required number of authentication keys, acquires the UUIDs of the authentication keys with the authentication keys from the KMS, and provides the storage nodes  15 A and  15 B with the UUID of the corresponding authentication key via a management interface protected by TLS or the like between the storage controller  13  and the storage nodes  15 A and  15 B. The storage nodes  15 A and  15 B then specify a UUID (Universally Unique Identifier) and acquire the authentication key through communications with the KMS protected by TLS (Transport Layer Security) or the like. Thus, the authentication key can be shared between the storage controller  13  and the storage nodes  15 A and  15 B. 
     The storage controller  13  determines that the authentication key of data written in the logical volumes L 1  and L 2  of the storage node  15 A is AK 1  with reference to the authentication-key correspondence table  23 , creates the authentication code using AK 1 , and writes the data in the volumes D 1  and D 2  of the storage node  15 A. The storage node  15 A verifies the authentication code using AK 1  that is stored in advance. When the authentication code is successfully verified, the data written in the logical volumes L 1  and L 2  can be stored in the volumes D 1  and D 2 . 
     It is not always necessary to allocate an authentication key in units of the storage nodes  15 A and  15 B as indicated in  FIG. 4 . Authentication keys can be set in various units. For example, an authentication key can be set in units of devices of the storage nodes  15 A and  15 B. 
       FIG. 5  indicates another example of the authentication-key correspondence table used for the storage controller of  FIG. 1 .  FIG. 5  indicates an example in which an authentication key is allocated in units of devices of the storage nodes. 
     In  FIG. 5 , in the authentication-key correspondence table  24 , the entries of #, Storage Node#, Storage Node Dev#, and Authentication Key are stored. # denotes an entry number. Storage Node# denotes identification information on the storage nodes. Storage Node Dev# denotes identification information on volumes provided from the storage nodes. Authentication Key denotes identification information on authentication keys. 
     The storage controller  13  determines that the authentication key of data written in the logical volume L 1  of the storage node  15 A is AK 1  with reference to the authentication-key correspondence table  24 , creates the authentication code using AK 1 , and writes the data in the volume D 1  of the storage node  15 A. The storage node  15 A verifies the authentication code using AK 1  that is stored in advance and is allocated to the volume D 1 . When the authentication code is successfully verified, the data written in the logical volume L 1  can be stored in the volume D 1 . 
       FIG. 6  indicates an example of an authentication code table used for the storage controller of  FIG. 1 . 
     In  FIG. 6 , an authentication code table  25  manages the latest authentication codes of data. 
     In the authentication code table  25 , the entries of #, Storage Controller Dev#, Storage Node#, and Storage Node Dev#, and authentication codes LBA 1  to LBA 4  are stored. # denotes an entry number. Storage Controller Dev# denotes identification information on logical volumes provided from the storage controller. Storage Node# denotes identification information on the storage nodes. Storage Node Dev# denotes identification information on volumes provided from the storage nodes. The authentication codes LBA 1  to LBA 4  indicate the LBA (Logical Block Addressing) of the latest authentication codes of data. 
     By keeping the authentication code table  25 , the storage controller  13  can confirm that data read from the storage nodes  15 A and  15 B is latest data. Without re-forming the authentication code during data reading in the storage controller  13 , data can be protected from replay attacks by a comparison with an authentication code registered for the authentication code. In the case of multiple storage controllers having redundant configurations, information on the authentication code table  25  is also shared among the storage controllers. 
       FIG. 7  is a flowchart indicating the writing of the storage controller of  FIG. 1 . 
     In  FIG. 7 , when receiving data written from the host  11  (C 11 ), the storage controller  13  encrypts the data using the data encryption key allocated to the storage controller  13  (C 12 ). 
     Subsequently, the authentication code is created using the authentication key shared among the storage controller  13  and the storage nodes  15 A and  15 B (C 13 ), and then the encrypted data and the authentication code are written in the storage nodes  15 A and  15 B (C 14 ). The data is encrypted by using, for example, schemes such as AES-XTS 256 defined by IEEE P1619. The authentication code includes information that enables verification that the writing source of the encrypted data is the storage controller  13 . 
       FIG. 8  is a flowchart indicating the writing of the storage nodes of  FIG. 1 . 
     In  FIG. 8 , when receiving the encrypted data and the authentication code that are written from the storage controller  13  (N 11 ), the storage nodes  15 A and  15 B verify the authentication code (N 12 ). 
     In the verification of the authentication code, the storage nodes  15 A and  15 B generate authentication codes using the authentication key shared with the storage controller  13  and based on the encrypted data that is received from the storage controller  13 . The storage nodes  15 A and  15 B then confirm whether the authentication code received from the storage controller  13  agrees with the authentication codes generated by the storage nodes  15 A and  15 B. 
     As a result of the verification of the authentication code, if a proper writing source cannot be verified from information included in the authentication code, the storage nodes  15 A and  15 B unsuccessfully verify the authentication code (No at N 13 ) and fail to write the data (N 14 ), so that the encrypted data is not stored. As a result of the verification of the authentication code, if a correct writing source is successfully verified (Yes at N 13 ), the storage nodes  15 A and  15 B store the encrypted data and the authentication code (N 15 ). 
       FIG. 9  is a flowchart indicating the reading of the storage controller of  FIG. 1 . 
     In  FIG. 9 , when receiving a reading request from the host  11  (C 21 ), the storage controller  13  reads the encrypted data and the authentication codes from the storage nodes  15 A and  15 B (C 22 ) and verifies the authentication codes (C 23 ). 
     In the verification of the authentication codes, the storage controller  13  generates an authentication code using the authentication key shared with the storage nodes  15 A and  15 B and based on the encrypted data that is received from the storage nodes  15 A and  15 B. The storage controller  13  then confirms whether the authentication codes received from the storage nodes  15 A and  15 B agree with the authentication code generated by the storage controller  13 . 
     If the authentication codes are unsuccessfully verified (No at C 24 ), the storage controller  13  fails to read the data (C 25 ). If the authentication codes are successfully verified (Yes at C 24 ), the storage controller  13  decrypts the encrypted data that is received from the storage nodes  15 A and  15 B (C 26 ) and sends the decrypted data to the host  11  (C 27 ). 
       FIG. 10  is a flowchart indicating the reading of the storage nodes of  FIG. 1 . 
     In  FIG. 10 , when receiving a request for reading of the encrypted data and the authentication codes from the storage controller  13  (N 21 ), the storage nodes  15 A and  15 B send the encrypted data and the authentication codes to the storage controller  13  (N 22 ). 
     At this point, the data is encrypted and thus the data can be protected during data communications between the storage controller  13  and the storage nodes  15 A and  15 B. The data stored in the storage nodes  15 A and  15 B is encrypted and thus can be prevented from being leaked by unauthorized reading. 
     The assignment of the authentication codes can prevent writing in the storage nodes  15 A and  15 B from a storage controller other than the correct storage controller  13 . Thus, the data stored in the storage nodes  15 A and  15 B can be prevented from being illegally corrupted. Moreover, the data read from the storage nodes  15 A and  15 B by the storage controller  13  can be checked for tampering. 
     Consequently, in data communications between the storage controller  13  and the storage nodes  15 A and  15 B, data can be protected from masquerade of a transmission source and data tampering without being encrypted by communication data encryption typified by FC-SP2 and TLS, thereby reducing a load for encryption. 
       FIG. 11  indicates an example of information exchanged between the storage controller and the storage nodes of  FIG. 1 . 
     In  FIG. 11 , for example, encrypted data in units of 512 bytes, the authentication code of 2 bytes, and a sequence number of 6 bytes can be simultaneously transmitted or received between the storage controller  13  and the storage nodes  15 A and  15 B. The sequence number is a serial number of transmission of encrypted data. 
     At this point, the data may be combined and stored in devices in the storage nodes  15 A and  15 B or the authentication code and the sequence number may be stored in different areas while being associated with LBA. 
     If the encrypted data, the authentication code, and the sequence number are combined and stored in the devices, the data may be stored in each of the devices. The data may be separately stored in a device for storing encrypted data and a device for storing meta-information including the authentication code and the sequence number. 
       FIG. 12  is a flowchart indicating the writing of a storage controller according to a second embodiment.  FIG. 12  indicates an example of the detailed processing of processing in  FIG. 7 . 
     In  FIG. 12 , when receiving data written from a host  11  (C 31 ), a storage controller  13  determines, from a writing address, a storage node for writing and an address of the storage node (C 32 ). The storage controller  13  can make the determination based on the mapping information of  FIG. 2 . 
     For example, in the configuration of  FIG. 1 , one logical device disclosed to the host  11  by the storage controller  13  is associated, on a one-to-one basis, with one device on storage nodes  15 A and  15 B for writing data written in the one logical device. Thus, referring to a mapping table  21  in  FIG. 2 , the storage controller  13  can determine the storage nodes  15 A and  15 B and the device for writing. By using LBA for which a writing instruction is provided by the host  11 , the storage controller  13  performs writing on LBA of the device of the storage nodes  15 A and  15 B. 
     The storage controller  13  then acquires DEK and AK for processing data in response to a writing request (C 33 ). The storage controller  13  can acquire DEK and AK by managing information in  FIG. 3  or  FIG. 4 . 
     The storage controller  13  then encrypts data using DEK (C 34 ). In this example, data is encrypted using AES-XTS. LBA is used as an input value in AES-XTS. Thus, if the same data has different addresses, different encrypted data segments are generated from the data. 
     Subsequently, the storage controller  13  advances a sequence number by one (C 35 ). The sequence number is used for preventing replay attacks. The sequence number may be set in several types of units, for example, by a method of incrementing the sequence number in units of storage controllers or a method of incrementing the sequence number in units of pairs of the logical device of the storage controller and the device of the storage node. In this case, it is assumed that the sequence number is incremented in units of pairs of the logical device of the storage controller and the device of the storage node unless otherwise specified. 
     Alternatively, a random number may be generated each time instead of the sequence number or a combination of time information or the like and the sequence number may be used instead of the sequence number. 
     Subsequently, data is generated by concatenating the encrypted data and the sequence number and then HMAC (Hash based Message Authentication Code) processing is performed using AK as a key and the concatenated data as a message (C 36 ). At this point, the first 2 bytes of the message can be used as an authentication code. 
     The storage controller  13  then stores the authentication code associated with LBA in the storage controller  13  (C 37 ). At this point, the latest authentication code of corresponding LBA is written over an authentication code table  25  of  FIG. 6 . 
     The storage controller  13  then writes the encrypted data with the authentication code and the sequence number in plain text in the storage nodes  15 A and  15 B (C 38 ). 
       FIG. 13  is a flowchart indicating the reading of the storage controller according to the second embodiment.  FIG. 13  indicates an example of the detailed processing of processing in  FIG. 9 . 
     In  FIG. 13 , when receiving a data reading request with LBA from the host  11  (C 41 ), the storage controller  13  reads the encrypted data, the authentication code associated with the encrypted data, and the sequence number from corresponding LBA of the storage nodes  15 A and  15 B (C 42 ) and acquires DEK and AK for processing corresponding data (C 43 ). 
     Subsequently, the storage controller  13  performs two verifications as verification of the authentication code in C 23  of  FIG. 9 . In the first verification, the storage controller  13  confirms whether the authentication codes read from the storage nodes  15 A and  15 B agree with the authentication code stored in corresponding LBA in  FIG. 6  (C 44 ). Thus, even data correctly written in the past in the storage nodes  15 A and  15 B by the storage controller  13  is prevented from being read because the data is not the latest data. 
     If the authentication codes do not agree with each other (No at C 45 ), the storage controller  13  fails to read the data and completes the process (C 46 ). If the authentication codes agree with each other (Yes at C 45 ), the storage controller  13  generates, as the second verification, an authentication code according to the same method of generating the authentication code in the processing of  FIG. 12  and compares the authentication code with the authentication codes acquired from the storage nodes  15 A and  15 B (C 47 ). If the authentication codes do not agree with each other (No at C 48 ), the storage controller  13  fails to read the data and completes the process (C 46 ). If the authentication codes agree with each other (Yes at C 48 ), the storage controller  13  decrypts the encrypted data that is received from the storage nodes  15 A and  15 B (C 49 ) and sends the data to the host  11  (C 50 ). 
       FIG. 14  is a flowchart indicating the writing of the storage nodes according to the second embodiment.  FIG. 14  indicates an example of the detailed processing of processing in  FIG. 8 . 
     In  FIG. 14 , when receiving the encrypted data with the authentication code and the sequence number in plain text from the storage controller  13  (N 31 ), the storage nodes  15 A and  15 B confirms whether the sequence number is a previously used number (N 32 ). In order to determine whether the sequence number is a previously used number, the storage nodes  15 A and  15 B store sequence numbers received in the past. If the sequence number is a previously used number (Yes at N 33 ) the storage nodes  15 A and  15 B fail to write the data and completes the process (N 38 ). 
     If the sequence number is not a previously used number (No at N 33 ) the storage nodes  15 A and  15 B refer to an authentication-key correspondence table  24  in  FIG. 5  and acquire AK for processing the data received in N 31  (N 34 ). 
     From the encrypted data and the sequence number, the storage nodes  15 A and  15 B then concatenate the data according to the same method as the processing of C 36  in  FIG. 12  and perform HMAC processing using AK as a key (N 35 ). Subsequently, the storage nodes  15 A and  15 B compare the first 2 bytes of information generated by the HMAC processing with the authentication code received from the storage controller  13  (N 36 ). If the authentication codes do not agree with each other (No at N 37 ), the storage nodes  15 A and  15 B fails to write the data and completes the process (N 38 ). If the authentication codes agree with each other (Yes at N 37 ), the storage nodes  15 A and  15 B store the encrypted data at a specified address and store the authentication codes and the sequence number at a predetermined address (N 39 ). 
       FIG. 15  indicates a method of confirming whether the sequence number is a previously used number. 
     In  FIG. 15 , in order to determine whether the sequence number is a previously used number, the storage nodes  15 A and  15 B manage received sequence number lists  131  to  133 . 
     In the received sequence number list  131 , if sequence numbers included in received data are regarded as being unreceived, the sequence numbers are added in ascending order. In this example, latest sequence numbers  101  to  103  are registered. NULL is described at the ends of the received sequence number lists  131  to  133 . NULL is used for determining the ends of the received sequence number lists  131  to  133 . 
     At this point, the three sequence numbers  101  to  103  are consecutive numbers. Thus, in order to confirm whether the sequence numbers are previously used numbers, only the sequence number  103  may be left and the sequence numbers  101  and  102  may be deleted. The storage nodes  15 A and  15 B can confirm that the sequence numbers equal to or smaller than the sequence number  103  have been received, from information on the sequence number  103 . 
     If communications are not lost and a receiver sequentially receives the sequence numbers as issued by a sender, the storage nodes  15 A and  15 B can determine whether the sequence numbers are previously used numbers only by holding the last sequence number. 
     The received sequence number list  132  indicates that sequence numbers  101  to  103 ,  105 , and  110  are received after the reception of sequence numbers up to  100 . At this point, the sequence numbers  101  to  103  are consecutive numbers and thus the sequence numbers  101  and  102  can be deleted from the received sequence number list  132  and only the sequence numbers  103 ,  105 , and  110  may be stored in the received sequence number list  133 . If an additionally received sequence number is at most the first sequence number  103  or agrees with other sequence numbers (in this case,  105  and  110 ), the sequence number is regarded as being received. Otherwise the sequence number is regarded as being unreceived. 
     Processing continued for a certain period of time may cause an overflow of a received sequence number and thus numbering from 0 may be necessary. In such a case, a sufficiently large number of digits is used to prevent unauthorized use of past sequence numbers as in the use of ordinary sequence numbers. Moreover, received sequence numbers may not be storable in memory after the processing is continued for a certain period of time. In this case, it is necessary to discard some of the received sequence numbers, determine the sequence numbers not larger than the maximum discarded sequence number are received sequence numbers, and reject the reception of the sequence numbers. 
     When writing the encrypted data that is received from the storage controller  13 , the storage nodes  15 A and  15 B may write the encrypted data, the authentication code, and the sequence number in different messages. For example, the storage nodes  15 A and  15 B may wait for writing until the authentication code and the sequence number reach multiples of 512 bytes, and then collectively write the authentication code and the sequence number that have reached multiples of 512 bytes. 
     In this case, the storage nodes  15 A and  15 B verify written data after the authentication code and the sequence number of the corresponding encrypted data are received. In this case, if the storage nodes  15 A and  15 B cannot receive the authentication code and the sequence number for a predetermined period of time, the storage nodes  15 A and  15 B send signals indicating the discontinuation of the processing to the storage controller  13 . When receiving the signals, the storage controller  13  discontinues the writing, thereby preventing a data loss. 
       FIG. 16  is a flowchart indicating the reading of the storage nodes according to the second embodiment.  FIG. 16  indicates an example of the detailed processing of processing in  FIG. 10 . 
     In  FIG. 16 , when receiving a reading request of the encrypted data with the authentication code and the sequence number from the storage controller  13  (N 41 ), the storage nodes  15 A and  15 B send the authentication code, the sequence number, and the encrypted data to the storage controller  13  (N 42 ). 
     In the example of  FIG. 16 , the reading request of the encrypted data is received with the authentication code and the sequence number from the storage controller  13 . The storage nodes  15 A and  15 B may manage the encrypted data and the authentication code and the sequence number that are associated with the encrypted data. When the storage controller  13  requests only reading of the encrypted data, the authentication code and the sequence number may be sent with the encrypted data to the storage controller  13 . 
     In the reading of the storage controller in  FIG. 13 , the method of performing two verifications was described as verification of the authentication code in C 23  of  FIG. 9 . However, it is assumed that illegal corruption and tampering of data on the storage nodes  15 A and  15 B can be prevented in the writing of the storage controller in  FIG. 12 . When data is read, a host application may be capable of detecting corruption and tampering of data. The data may be readable again. In this case, at least part of the two verifications in  FIG. 13  may be omitted. 
       FIG. 17  is a flowchart indicating the reading of a storage controller according to a third embodiment. In the example of  FIG. 17 , both of the two verifications in  FIG. 13  may be omitted. 
     In  FIG. 17 , when receiving a reading request from a host  11  (C 61 ), a storage controller  13  reads encrypted data from storage nodes  15 A and  15 B (C 62 ). 
     The storage controller  13  then acquires DEK for processing the encrypted data that is received from the storage nodes  15 A and  15 B (C 63 ), decrypts the encrypted data using DEK (C 64 ), and sends the data to the host  11  (C 65 ). 
       FIG. 18  is a flowchart indicating the reading of a storage controller according to a fourth embodiment. In the example of  FIG. 18 , the second verification of the two verifications in  FIG. 13  is omitted. 
     In  FIG. 18 , when receiving a data reading request from a host  11  (C 71 ), a storage controller  13  reads encrypted data (C 72 ) and authentication codes associated with the encrypted data from storage nodes  15 A and  15 B, and acquires DEK for processing corresponding data (C 73 ). 
     The storage controller  13  then confirms whether the authentication codes read from the storage nodes  15 A and  15 B agree with an authentication code held by the storage controller  13  (C 74 ). 
     If the authentication codes do not agree with each other (No at C 75 ), the storage controller  13  fails to read the data and completes the process (C 76 ). If the authentication codes agree with each other (Yes at C 75 ), the storage controller  13  decrypts the encrypted data that is received from the storage nodes  15 A and  15 B (C 77 ) and sends the data to the host  11  (C 78 ). 
       FIG. 19  is a flowchart indicating the reading of a storage controller according to a fifth embodiment. In the example of  FIG. 19 , the first verification of the two verifications in  FIG. 13  is omitted. 
     In  FIG. 19 , when receiving a data reading request from a host  11  (C 81 ), a storage controller  13  reads encrypted data, authentication codes associated with the encrypted data, and a sequence number from storage nodes  15 A and  15 B (C 82 ) and acquires DEK and AK for processing corresponding data (C 83 ). 
     The storage controller  13  then generates an authentication code by the same method as in the generation of the authentication code in the processing of  FIG. 12 , and compares the authentication code with the authentication codes acquired from the storage nodes  15 A and  15 B (C 84 ). If the authentication codes do not agree with each other (No at C 85 ), the storage controller  13  fails to read the data and completes the process (C 86 ). If the authentication codes agree with each other (Yes at C 85 ), the storage controller  13  decrypts the encrypted data that is received from the storage nodes  15 A and  15 B (C 87 ) and sends the data to the host  11  (C 88 ). 
     In the reading of  FIG. 13 , the storage controller  13  holds the authentication codes therein and verifies that read data is the latest data by comparing the authentication codes during reading, thereby preventing replay attacks using past data. 
     In order to prevent replay attacks using past data, the storage nodes  15 A and  15 B may generate new authentication codes according to a scheme similar to the method of  FIG. 12  using sequence numbers generated in the storage nodes  15 A and  15 B, and the storage controller  13  may verify the new authentication codes. 
       FIG. 20  is a flowchart indicating the reading of storage nodes according to a sixth embodiment.  FIG. 12  indicates the method of managing sequence numbers by the storage controller, whereas  FIG. 20  indicates a method of managing sequence numbers by storage nodes. 
     In  FIG. 20 , storage nodes  15 A and  15 B receive encrypted data read with an authentication code and a sequence number from a storage controller  13  (N 51 ). The storage nodes  15 A and  15 B then advance the sequence number by one (N 52 ). 
     Subsequently, the storage nodes  15 A and  15 B perform HMAC processing using AK as a key and data generated by concatenating the encrypted data and the sequence number as a message (N 53 ). The storage nodes  15 A and  15 B then use the first 2 bytes of the message as an authentication code and store the authentication code associated with a writing address in the storage nodes  15 A and  15 B (N 54 ). 
     Subsequently, the storage nodes  15 A and  15 B send the encrypted data with the authentication code and the sequence number to the storage controller  13  (N 55 ). 
       FIG. 21  is a flowchart indicating the reading of the storage controller according to the sixth embodiment.  FIG. 13  indicates the method of managing sequence numbers by the storage controller, whereas  FIG. 21  indicates the method of managing sequence numbers by the storage nodes. 
     In  FIG. 21 , when receiving a data reading request from a host  11  (C 91 ), the storage controller  13  reads the encrypted data with the authentication code and the sequence number from the storage nodes  15 A and  15 B (C 92 ). 
     The storage controller  13  then confirms whether sequence numbers read from the storage nodes  15 A and  15 B agree with a sequence number used in the past (C 93 ). In order to determine whether the sequence numbers are previously used numbers, the storage controller  13  stores sequence numbers received in the past. 
     If the sequence numbers read from the storage nodes  15 A and  15 B are previously used numbers (Yes at C 94 ), the storage controller  13  fails to read the data and completes the process (C 98 ). If the sequence numbers read from the storage nodes  15 A and  15 B are not previously used numbers (No at C 94 ), the storage controller  13  acquires DEK and AK for processing the data (C 95 ). 
     From the encrypted data and the sequence numbers, the storage controller  13  then concatenates the data according to the same method as the processing of C 36  in  FIG. 12  and performs HMAC processing using AK as a key. Subsequently, the storage controller  13  compares the first 2 bytes of information generated by the HMAC processing with the authentication codes received from the storage nodes  15 A and  15 B (N 96 ). 
     If the authentication codes do not agree with each other (No at C 97 ), the storage controller  13  fails to read the data and completes the process (C 98 ). If the authentication codes agree with each other (Yes at C 97 ), the storage controller  13  decrypts the encrypted data that is received from the storage nodes  15 A and  15 B (C 99 ) and sends the data to the host  11  (C 100 ). 
       FIG. 22  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to a seventh embodiment is applied. 
     In a storage system illustrated in  FIG. 22 , the storage controller  13  of  FIG. 1  is replaced with a storage controller  33 . 
     The storage controller  33  manages logical volumes L 1  to L 3  via a pool P 1 . The units of the data area of the pool P 1  are disposed in volumes D 1  to D 4  of at least one storage node  15 A or  15 B in a distributed manner. At this point, the storage controller  33  generates pool volumes V 1  to V 4  for the volumes D 1  to D 4 , respectively, and centralizes the pool volumes V 1  to V 4  at the pool P 1 . Furthermore, the storage controller  33  extracts the logical volumes L 1  to L 3  from the pool P 1  and provides the logical volumes for the host  11 . 
     Except for the method of managing the logical volumes L 1  to L 3  via the pool P 1 , the storage controller  33  performs encryption  16 A, decryption  16 B, and authentication code processing  17  like the storage controller  13 . 
       FIG. 23  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to an eighth embodiment is applied. 
     In  FIG. 23 , storage controllers  13 A to  13 C . . . are coupled to storage nodes  15 A to  15 C . . . via a network  14 . The storage controllers  13 A to  13 C perform encryption  16 A, decryption  16 B, and authentication code processing  17  like the storage controller  13  of  FIG. 1 . 
       FIG. 24  is a block diagram illustrating the configurations of hosts and storage nodes to which an encryption apparatus according to a ninth embodiment is applied. 
     In  FIG. 24 , a plurality of hosts  11 A to  11 C . . . are coupled to a plurality of storage nodes  15 A to  15 C . . . via a network  12 . The hosts  11 A to  11 C . . . perform processing identical or similar to the host  11  of  FIG. 1  and have functions identical or similar to the storage controller  13  so as to perform processing identical or similar to the storage controller  13 . 
     Thus, even if the hosts  11 A to  11 C . . . write or read data to or from the storage nodes  15 A to  15 C . . . without a storage controller, the safety of data storage and communications can be secured while reducing a load for encryption. 
       FIG. 25  is a block diagram illustrating the configurations of a storage controller and storage nodes to which an encryption apparatus according to a tenth embodiment is applied. 
     In  FIG. 25 , a host  11  is coupled to storage controllers  13 A to  13 C . . . via a network  12 . The storage controllers  13 A to  13 C . . . are coupled to storage nodes  15 A to  15 C via a network  14 B. 
     Moreover, the storage controllers  13 A to  13 C . . . and the storage nodes  15 A to  15 C . . . are coupled to a management interface  19  and a KMS  20  via a network  14 A. 
     The KMS  20  manages DEK and AK, provides DEK for the storage controllers  13 A to  13 C . . . , and provides AK for the storage controllers  13 A to  13 C . . . and the storage nodes  15 A to  15 C . . . via the network  14 A. The KMS  20  and the storage controllers  13 A to  13 C . . . are coupled to each other and the KMS  20  and the storage nodes  15 A to  15 C . . . are coupled to each other in accordance with, for example, a KMIP protocol by using communication security techniques such as TLS. The KMS  20  may be coupled on the network  14 A between the storage controllers  13 A to  13 C . . . and the storage nodes  15 A to  15 C . . . or another network that is different from a data network. 
     The management interface  19  provides an GUI (Graphical User Interface) or a CLI (Command Line Interface) for a user and manages, for example, the allocation of DEK and AK. In order to prevent fraud in the management interface  19 , the management interface  19  also performs management including a deletion of a volume from a network protected by communication security such as TLS. 
     The foregoing embodiments described the method of reading and writing data in the storage nodes  15 A and  15 B, in which the authentication code processing  18 A and  18 B are implemented, by the storage controller  13 . Also in the case of reading and writing of data in a storage having a single function, leakage of data can be prevented and tampering of data can be detected. 
       FIG. 26  is a block diagram illustrating the configurations of a storage controller and a storage to which an encryption apparatus according to an eleventh embodiment is applied. 
     In  FIG. 26 , a cloud  31  is coupled to a network  14  instead of the storage nodes  15 A and  15 B of  FIG. 1 . The cloud  31  provides volumes D 11  to D 14  for a storage controller  13 . 
     When receiving data written from a host  11 , the storage controller  13  encrypts the data using a data encryption key allocated to the storage controller  13 . The storage controller  13  then generates an authentication code using an authentication key allocated to the storage controller  13  and writes the encrypted data and the authentication code to the volumes D 11  to D 14 . The volumes D 11  to D 14  store the encrypted data and the authentication code, which are received from the storage controller  13 , without verifying the authentication code. 
     When receiving a reading request from a host  11 , the storage controller  13  reads the encrypted data and the authentication code from the volumes D 11  to D 14  and verifies the authentication code. If the authentication code is successfully verified, the storage controller  13  decrypts the encrypted data that is received from the volumes D 11  to D 14  and sends the decrypted data to the host  11 . Thus, even if data is written or read in the volumes D 11  to D 14 , each having a single function, the storage controller  13  can prevent leakage of data and tampering of data. 
     In the foregoing embodiments, the method of generating the authentication code using HMAC was described. Another algorithm may be used as long as the authentication code is generated. Moreover, in the foregoing embodiments, the 2-byte authentication code is generated. The number of bytes is not limited to 2. Alternatively, the authentication code may not be stored in N 15  of  FIG. 8  or may not be verified in C 23  of  FIG. 9  depending upon the risk of security. 
     In the foregoing embodiments, leakage of data in the storage nodes is prevented by separating DEK and AK. It is not necessary to separate DEK and AK as long as the storage nodes are operated in sufficiently reliable circumstances. In this case, hash functions not using keys or methods such as CRC (Cyclic Redundancy Check) are used instead of HMAC so as to generate a checksum for data concatenated with a sequence number before encryption. In this case, AK is not used. 
     The above-mentioned encryption, decryption, and authentication can be used for the authentication of a command as well as IO. 
       FIG. 27  is a block diagram illustrating a hardware configuration example of the storage controller of  FIG. 1 . 
     In  FIG. 27 , the storage controller  13  includes a processor  101 , a communication control device  102 , a communication interface  103 , a main storage device  104 , an auxiliary storage device  105 , and an input/output interface  107 . The processor  101 , the communication control device  102 , the communication interface  103 , the main storage device  104 , the auxiliary storage device  105 , and the input/output interface  107  are coupled to one another via an internal bus  106 . The main storage device  104  and the auxiliary storage device  105  are accessible from the processor  101 . 
     Moreover, an input apparatus  120  and an output apparatus  121  are provided outside the storage controller  13 . The input apparatus  120  and the output apparatus  121  are coupled to the internal bus  106  via the input/output interface  107 . The input apparatus  120  is, for example, a keyboard, a mouse, a touch panel, a card reader, or a voice input apparatus. The output apparatus  121  is, for example, a screen display (e.g., a liquid crystal monitor, an organic EL (Electro Luminescence) display, or a graphic card), an audio output apparatus (speaker or the like), or a printer. 
     The processor  101  is hardware that controls the operations of the overall storage controller  13 . The processor  101  may be a CPU (Central Processing Unit) or a GPU (Graphics Processing Unit). The processor  101  may be a single-core processor or a multi-core processor. The processor  101  may include a hardware circuit (e.g., an FPGA (Field-Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit)) that performs at least part of processing. The processor  101  may include a neural network. 
     The main storage device  104  may include a semiconductor memory, for example, SRAM or DRAM. In the main storage device  104 , a program being executed by the processor  101  may be stored or a work area for executing a program by the processor  101  may be provided. 
     The auxiliary storage device  105  is a storage device having a large storage capacity, for example, a hard disk apparatus or an SSD. The auxiliary storage device  105  can hold the executable files of various programs and data used for executing the programs. In the auxiliary storage device  105 , an encryption program  105 A can be stored. The encryption program  105 A may be software installable in the storage controller  13  or firmware installed in the storage controller  13 . 
     The communication control device  102  is hardware having the function of controlling communications with the outside. The communication control device  102  is coupled to a network  109  via the communication interface  103 . The network  109  may be a WAN (Wide Area Network), e.g., the Internet, a LAN (Local Area Network), e.g., WiFi or Ethernet (registered trademark), or a combination of a WAN and a LAN. 
     The input/output interface  107  converts data inputted from the input apparatus  120  into a data format processable to the processor  101 , or converts data outputted from the processor  101  into a data format processable to the output apparatus  121 . 
     The processor  101  reads the encryption program  105 A into the main storage device  104  and then the encryption program  105 A is executed, so that the encryption  16 A, the decryption  16 B, and the authentication code processing  17  in  FIG. 1  can be implemented. 
     The execution of the encryption program  105 A may be shared among a plurality of processors or computers. Alternatively, the processor  101  may instruct a cloud computer or the like via the network  109  to execute at least part of the encryption program  105 A, and receive the result of execution. 
     The present invention is not limited to the foregoing embodiments and includes various modifications. For example, the embodiments were specifically described to illustrate the present invention. All the described configurations are not necessary for the present invention. Moreover, the configuration of one of the embodiments can be partially replaced with the configuration of another embodiment or the configuration of one of the embodiments may further include the configuration of another embodiment. Alternatively, the configurations of the embodiments can partially include additional configurations, can be partially deleted, or can be partially replaced with other configurations. The configurations, functions, processing unit, and processing means may be partially or entirely implemented by hardware, for example, an integrated circuit design.