WO2014091535A1 - 計算機システム及び記憶部の暗号化方法 - Google Patents

計算機システム及び記憶部の暗号化方法 Download PDF

Info

Publication number
WO2014091535A1
WO2014091535A1 PCT/JP2012/081915 JP2012081915W WO2014091535A1 WO 2014091535 A1 WO2014091535 A1 WO 2014091535A1 JP 2012081915 W JP2012081915 W JP 2012081915W WO 2014091535 A1 WO2014091535 A1 WO 2014091535A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
recovery key
key
storage unit
management
Prior art date
Application number
PCT/JP2012/081915
Other languages
English (en)
French (fr)
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 株式会社日立製作所
Priority to PCT/JP2012/081915 priority Critical patent/WO2014091535A1/ja
Publication of WO2014091535A1 publication Critical patent/WO2014091535A1/ja

Links

Images

Classifications

    • 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/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/20—Manipulating the length of blocks of bits, e.g. padding or block truncation

Definitions

  • the present invention relates to a computer system having a drive encryption function for determining the integrity of hardware components when decrypting an encrypted system volume.
  • Patent Document 1 is known as a function for ensuring the confidentiality of a booting system in units of volumes.
  • TPM trusted platform module
  • Patent Document 1 describes a drive encryption function that ensures the integrity of hardware components during decryption.
  • this encryption function for example, BitLocker (registered trademark) is known.
  • BitLocker registered trademark
  • BitLocker is a drive encryption function characterized by encrypting the volume of the OS (Operating System) itself.
  • a drive encryption function that determines the consistency of hardware components at the time of decryption and encrypts the volume of the OS itself will be referred to as a drive encryption function.
  • the OS boot loader When the drive encryption function is enabled, the OS boot loader first decrypts the volume in which the OS is stored in order to start the OS. At that time, the OS boot loader uses an SRK (Storage Root Key) stored in a TPM (Trusted Platform Module).
  • SRK Storage Root Key
  • TPM Trusted Platform Module
  • UEFI Unified Extensible Firmware Interface
  • TPM Plate Configuration Register
  • the OS boot loader fails to acquire the SRK, so the startup process is suspended and the recovery key is returned to the user. Request to connect.
  • the recovery key is generated by the OS when the encryption function is enabled, and is stored in, for example, a USB memory.
  • the recovery key is information used as a key for booting the OS when the hardware is changed.
  • the user can connect the USB memory storing the recovery key to the computer and perform a predetermined operation to restart the OS boot.
  • the function of restarting the OS boot by the recovery key pauses startup when a hardware change is made, whether the change is an illegal hardware change or an expected hardware change. This is to allow the user to make a determination by interposing a user operation.
  • the present invention eliminates the need for user operation when the platform intentionally changes the hardware configuration in an environment in which a drive encryption function that determines the consistency of hardware components at the time of volume decryption is applied.
  • a computer system capable of automatically starting an OS is provided.
  • the present invention is a computer system including a computer including a processor, a memory, and a storage unit that stores an OS, and a management computer that manages one or more of the computers.
  • the computer includes the storage unit.
  • the key generated by the OS for encryption and the eigenvalue calculated from the information related to the hardware when the key was generated are held in the eigenvalue holding unit, and the computer calculates when the OS starts up When a unique value based on information related to hardware does not match the held unique value, a recovery key for decrypting the storage unit is generated instead of the key, and the key is notified to the management computer
  • the storage unit storing the OS using the key is encrypted, and the management computer accepts the recovery key and associates the recovery key with the identifier of the computer that generated the recovery key.
  • the management computer after stopping the computer, selects a second computer that takes over the stopped computer, and uses the selected second computer to generate a recovery key generated by the stopped computer.
  • the second computer is started, and the second computer calculates an eigenvalue from information related to hardware, and determines whether or not it matches the eigenvalue previously held in the eigenvalue holding unit. If the calculated eigenvalue does not match the eigenvalue stored in advance, the recovery key notified from the management computer is used to decrypt the OS of the storage unit and start the OS.
  • a computer system that calculates an eigenvalue from information related to hardware at the time of decoding of a storage unit of the OS and determines hardware consistency based on whether or not the eigenvalue matches a previously held eigenvalue, Even when the hardware configuration is changed, it is possible to automatically apply the recovery key and start the OS without any user operation.
  • FIG. 1 is a block diagram illustrating an example of a computer system according to a first embodiment of this invention.
  • FIG. It is a figure which shows the 1st Example of this invention and shows the initial state of a recovery key management table. It is a figure which shows the 1st Example of this invention and shows the use time of a recovery key management table. It is a figure which shows the 1st Example of this invention and shows the time of preservation
  • FIG. 6 is a flowchart illustrating an example of processing performed when generating a recovery key according to the first embodiment of this invention, and illustrates the first half of a subroutine.
  • FIG. 7 is a flowchart illustrating an example of processing performed when generating a recovery key according to the first embodiment of this invention, and shows the latter half of the subroutine.
  • FIG. 1 is a block diagram of a computer system illustrating an example of switching a server module when a failure occurs according to a first embodiment of this invention.
  • the 1st Example of this invention is shown, the flowchart shows an example of the process which switches a server module at the time of failure occurrence, and shows the first half.
  • the middle part is shown in the flowchart which shows a 1st Example of this invention and shows an example of the process which switches a server module at the time of failure occurrence.
  • FIG. 6 is a flowchart illustrating an example of processing for switching a server module when a failure occurs according to the first exemplary embodiment of the present invention, and shows the latter half.
  • It is a block diagram which shows a 1st Example of this invention and shows an example of encryption of OS volume.
  • FIG. 10 is a flowchart illustrating an example of processing for degenerating an I / O device in which a failure has occurred according to the second embodiment of this invention, and shows the first half.
  • the second embodiment of the present invention is a flowchart showing an example of a process for degenerating an I / O device in which a failure has occurred, and shows the middle part.
  • FIG. 10 is a flowchart illustrating an example of processing for degenerating an I / O device in which a failure has occurred according to the second embodiment of this invention, and shows the latter half.
  • a computer system to which BitLocker (registered trademark) is applied as a drive encryption function for determining the consistency of hardware components when decrypting an encrypted computer system volume is used.
  • BitLocker registered trademark
  • This computer system will be described with reference to an example of a computer system that automatically starts without any user operation even when the platform intentionally changes the hardware configuration by the cold standby function.
  • the system configuration diagram will be described first, then the processing at the time of saving the recovery key, and finally the processing at the time of switching to the standby server.
  • FIG. 1 is a block diagram illustrating an example of a computer system.
  • 2A to 2F are diagrams showing state transitions in the recovery key management table.
  • the present embodiment has a cold standby configuration in which the server module B120 is the active system and the server module N140 is the standby system.
  • the blade server chassis 100 includes one or more server modules (server blades) 110 to 140, an SVP (Service Processor) module 150, a fiber channel switch 170, and a storage device 180.
  • server modules server blades 110 to 140
  • SVP Service Processor
  • the server module B 120 includes a CPU 124, a memory 127, a chip set 125, a network interface 128, fiber channel adapters (or host bus adapters) 121 and 122, and a UEFI (Unified Extended Firmware Interface) 161 that are general elements as a computer.
  • a BMC Baseboard Management Controller
  • TPM Trusted Platform Module
  • the TPM 126 includes a PCR (Platform Configuration Register).
  • the OS 190 is loaded into the memory 127 and executed by the CPU 124.
  • the fiber channel adapters 121 and 122 as I / O devices conform to the PCI express standard having a degeneration function.
  • the BMC module 129 is a server management module that provides a state management function for the server module B 120 and a virtual media function (USB memory emulation or the like).
  • the status management function of the BMC module 129 includes a fault detection function of the server module B120, a power supply control function, a PCIe degeneration control function (a function to degenerate a failed PCI Express device), and a fault report function to the SVP module 150
  • the virtual media function of the BMC module 129 has a function (USB memory emulation module 1291 (see FIG. 6)) of emulating a USB memory by mounting an image file on the BMC module 129 or a network.
  • the BMC module 129 operates in a state where power is always supplied even when the power supply to the server module B120 which is the main body of the computer is cut off, and can perform power control independently from the server module B120.
  • the server module N140 is a server module having the same components as the server module B120. Note that the generic names of the server modules A (110) to N (140) are represented by unsigned server modules. Further, the configurations of the server modules A (110) to N (140) are the same as the block diagram shown in FIG.
  • the SVP module 150 is a computer that manages each server module in the blade server chassis 100.
  • the SVP module 150 is a module including an SVP microcomputer 152 including a processor and a memory (not shown), a network switch 151, and an in-chassis storage 154 that can store a recovery key.
  • the intra-chassis storage 154 stores a recovery key management table 153 and one or more recovery keys 155 and 156.
  • the recovery key management table 153 and the recovery keys 155 and 156 are read into the memory of the SVP microcomputer 152 as necessary.
  • the network switch 151 forms a management network that connects each server module, the fiber channel switch 170, and the SVP module 150 in the blade server chassis 100.
  • Each server module is connected to a business network (not shown) and receives access from a client computer or the like. Note that the generic names of the recovery keys 155 and 156 are described below without a symbol.
  • the SVP module 150 is connected to the fiber channel switch 170 via a management network (not shown), and can switch the LU 181 read by the server module. Thereby, it is possible to switch the OS that each server module starts.
  • the SVP microcomputer 152 is connected to the BMC module 129 via the network switch 151.
  • the BMC module 129 can store a recovery key in the intra-chassis storage 154 by mounting a predetermined area on the intra-chassis storage 154 via the network and performing USB memory emulation, for example.
  • FIGS. 2A to 2F Examples of the recovery key management table 153 are shown in FIGS. 2A to 2F. Note that the recovery key management table 153 shown in FIGS. 2A to 2F shows transition of information included in the recovery key management table 153.
  • FIG. 2A is a diagram showing an initial state of the recovery key management table 153.
  • FIG. 2B is a diagram illustrating the start of use of the recovery key management table 153.
  • FIG. 2C is a diagram when the recovery key is stored in the recovery key management table 153.
  • FIG. 2D is a diagram when the recovery key management table 153 is used by the server module N.
  • FIG. 2E is a diagram showing a state in which the use of the recovery key management table 153 is finished in the server module N.
  • FIG. 2F is a diagram showing a state in which the recovery key management table 153 is used in the server module B.
  • the recovery key management table 153 includes, for example, rows having a recovery key generation source computer ID 201, a current recovery key connection destination 202, whether or not the recovery key is stored 203, and a storage location 204 of the recovery key.
  • the number of rows is a table corresponding to the number of mountable server modules.
  • the recovery key generation source computer ID 201 is a field for storing a value indicating the server module that generated the recovery key. In this embodiment, it is assumed that information indicating a slot number of a server module configured by a blade server is set in advance as the value of the recovery key generation source computer ID 201.
  • the recovery key storage presence / absence 203 is a field for storing a value indicating whether or not the recovery key is stored. The initial value of this field is “unsaved”, and the SVP module 150 sets “saved” when the recovery key is saved, and “unsaved” when the recovery key is deleted.
  • the recovery key storage location 204 is a field for storing a value indicating the storage location of the recovery key corresponding to the recovery key generation source computer ID 201.
  • This value is a file path indicating an area on the in-chassis storage 154 in this embodiment. In this embodiment, it is assumed that a file path corresponding to the recovery key generation source computer ID 201 is assigned in advance.
  • the current recovery key connection destination 202 is a field for storing a value indicating the connection destination (server module) of the area indicated by the storage position 204 of the recovery key of the corresponding row.
  • the initial value of this field is “not connected”, and the area indicated by the storage location 204 of the recovery key 204 is an ID indicating the corresponding server module when mounted by the BMC module 129, and when the area is unmounted by the BMC module 129.
  • the SVP module 150 sets a value of “not connected”. A value of “not connected” indicates that the server module is not mounted.
  • the present embodiment is a blade server
  • the number of rows, the recovery key generation source computer ID 201, and the storage location 204 of the recovery key are allocated in advance, but they may be allocated dynamically.
  • the presence / absence of storage of the recovery key is managed in the table, but for example, the presence / absence of the storage file of the recovery key may be identified.
  • the recovery key management table 153 in FIG. 2A indicates that the recovery key generated by the server module B is / conf / p2 / RecoveryKey. It is stored in an area called bin, indicating that it is not currently mounted from anywhere.
  • the storage apparatus 180 is a module having a plurality of LUs (Logical Units) 181.
  • the storage apparatus 180 and each server module are connected via the fiber channel switch 170, and the connection between the server module and the LU 181 can be logically switched.
  • the OS 190 is stored in the LU 181.
  • the OS 190 booted from the LU 181 is activated on the server module B120.
  • the OS 190 has the above-described BitLocker (registered trademark) function.
  • the OS 190 receives an instruction to activate the BitLocker (registered trademark) function from the user (step 300 in FIG. 3A).
  • the server module B120 receives the instruction from a console or terminal input device (not shown).
  • the OS 190 requests the TPM 126 to generate an SRK (Storage Root Key) (step 301), and the TPM 126 generates an SRK based on the current PCR value (step 302).
  • the PCR value is a value calculated by the TPM 126 based on hardware configuration information, boot record information, and UEFI 161 setting information, and is a unique value of the server module B120. Note that hardware configuration information, boot record information, and UEFI 161 setting information can be handled as information related to hardware (hardware related information).
  • the OS 190 requests the TPM 126 to create a snapshot of the current PCR (step 303), and the TPM 126 acquires the current PCR snapshot and stores it in the TPM 126 (step 304).
  • the OS 190 generates a VMK (Volume Master Key) (step 305) and a recovery key (step 306) based on the SRK.
  • VMK Volume Master Key
  • the OS 190 displays, for example, a dialog on the screen in order to allow the user to select the storage location for the recovery key (step 307).
  • This screen is output by the server module B120 to a console or terminal output device (not shown).
  • step 308 is storage in the chassis
  • the process proceeds to step 309 in FIG. 3B.
  • the BMC module 129 requests the SVP module 150 for the recovery key storage position (step 309).
  • the SVP module 150 refers to the recovery key management table 153 and selects a row in which the recovery key generation source computer ID 201 matches the request source computer ID (step 310 and the second row in FIG. 2A).
  • the SVP module 150 sets the computer ID that requested storage of the recovery key in the current recovery key connection destination 202 of the selected row (step 311 and the current recovery key connection destination 202 in FIG. 2B).
  • the recovery key management table 153 of FIG. 2B is different from FIG. 2A in which the current recovery key connection destination 202 corresponding to the recovery key generation source computer ID 201 corresponding to “server module B” is in an unconnected state. It has changed to the state connected to.
  • the current recovery key connection destination 202 in the second row is updated from “not connected” to “server module B”.
  • the SVP module 150 notifies the BMC module 129 of each server module of the storage location 204 (24 “/conf/p2/RecoveryKey.bin” in the present embodiment) of the recovery key to be mounted (step 312 and 204 of FIG. 2B).
  • the BMC module 129 mounts the recovery key image file at the recovery key storage location notified from the SVP module 150 (step 313), and starts emulation of the USB memory (step 314). At this time, the OS 190 recognizes that the USB memory is connected to the BMC module 129.
  • the OS 190 when the OS 190 receives a recovery key save operation (step 315) from the user, the OS 190 writes the recovery key in the USB memory emulated by the BMC module 129 (step 316 in FIG. 3C). Since the BMC module 129 mounts the intra-chassis storage 154 of the SVP module 150 and performs USB memory emulation, the recovery key 156 is written in an area on the intra-chassis storage 154 (step 317).
  • the BMC module 129 ends the USB memory emulation (step 318), unmounts the recovery key image file in the intra-chassis storage 154 (step 319), and notifies the SVP module 150 of the completion of saving the recovery key. Perform (step 320).
  • the SVP module 150 Upon receiving the notification in step 320, the SVP module 150 sets the current recovery key connection destination 202 of the recovery key management table 153 to unconnected (see FIG. 2C), and sets the recovery key storage presence / absence 203 to “saved” (FIG. 2). 2C (203) (step 321).
  • FIG. 2C shows a state in which the current recovery key connection destination 202 corresponding to the server module B with the recovery key generation source computer ID 201 is “server module B” and the recovery key storage presence / absence 203 is “unsaved”.
  • the current recovery key connection destination 202 is changed to “not connected”, and the recovery key storage status 203 is changed to “saved”.
  • the OS 190 generates FVEK (Full Volume Encryption Key) based on the VMK (step 322) and encrypts the OS volume (step 323), and the encryption function is enabled.
  • FVEK Full Volume Encryption Key
  • the LU 181 shows an example of two volumes: a system volume (SYS VOLUME in the figure) 1810 for storing the blade manager and VMK, and an OS volume 1811 for storing FVEK and OS 190. .
  • the processing when the USB memory is selected in step 308 of FIG. 3A is an example of a conventional BitLocker system.
  • the OS 190 when the user attaches a USB memory to the server module B (step 350) and the OS 190 accepts a recovery key storage operation (step 351) from the user, the OS 190 attaches the recovery key in step 350. Write to memory (step 352).
  • the recovery key is stored in the USB memory.
  • the SVP module 150 detects the failure (step 501 in FIG. 5A), and the active server module B120 is forced to turn off and inhibit power-on (step 502) is notified to the server module B120, and the standby server module N140 is turned on (step 503).
  • the BMC module 129 of the standby server module N140 is always supplied with power and can control the power to the CPU 124 and the memory 127.
  • FIG. 4 is a block diagram of the server module B120 and the server module N140 that perform system switching.
  • the server module N140 is added to FIG.
  • the other configuration is the same as that of the first embodiment, and a duplicate description is omitted.
  • the BMC module 129 of the standby server module N140 requests the recovery key storage location from the SVP module 150 (step 505).
  • the recovery key management computer 153 indicates that the “recovery key generation source computer ID 201” is the active computer.
  • the line that matches the ID 201 is selected (step 507, FIG. 2C).
  • the selected row is not the computer ID 201 corresponding to the server module N140 of the request source (system takeover destination) but the row of the computer ID 201 corresponding to the server module B 120 of the switching source.
  • FIG. 2C shows that row # 2 has been selected for illustration.
  • the SVP module 150 determines from the recovery key management table 153 that the recovery key storage presence / absence 203 of the selected row is “saved”. In this embodiment, since the recovery key is stored (there is step 509), an ID indicating the request source server module N140 is set in the current recovery key connection destination 202 of the selected row (step 510, FIG. 2D).
  • FIG. 2D shows a state in which the recovery key generation source computer ID 201 corresponds to the server module B120 and the current recovery key connection destination 202 is not connected.
  • FIG. 2C is changed to a state connected to the server module N140. Is.
  • the SVP module 150 then stores the value of the recovery key storage position 204 to be mounted on the BMC module 129 of the switching destination server module N140 (FIG. 2D, “/conf/p2/RecoveryKey.bin in this embodiment). ]) Is notified (step 510).
  • step 509 if it is determined in step 509 that the current recovery key storage presence / absence 203 of the selected row is “unsaved” or the recovery key storage location 204 has no value, the process proceeds to step 511 to return to the recovery key storage location.
  • the BMC module 129 is notified that there is no data or the recovery key is not stored.
  • the BMC module 129 of the server module N140 that is the takeover destination image of the recovery key 156 stored in the location notified in step 511
  • the file is mounted (step 513), and emulation of the USB memory 401 (see FIG. 4) is started (514).
  • the server module N140 can recognize that the USB memory 401 storing the recovery key 156 is added on the BMC module 129 side.
  • the BMC module 129 notifies the SVP module 150 of completion of system switchover preparation (step 515).
  • the SVP module 150 cancels the power-on inhibition of the standby server module N140 and instructs to turn on the power (step 516), and the standby server module N140 is turned on (step 516). 517).
  • the hardware configuration information, the setting of the UEFI 161, and the boot record value are acquired (step 519), and the PCR value of the TPM 126 is updated (step 520).
  • the SVP module 150 changes the path of the fiber channel switch 170 to change the boot device of the server module N140. This is a state in which (change of hardware configuration information) has been performed. Therefore, the comparison result between the PCR snapshot held in the TPM 126 of the server module N140 and the PCR calculated this time does not match, and the SRK lock is not released (NO in step 521).
  • the OS 190 starts booting by the boot manager shown in FIG. 6, but fails to acquire the SRK of the TPM 126 (NO in step 524), so is the USB memory 401 storing a valid recovery key connected? It is determined whether or not (step 525).
  • step 514 by the USB memory emulation in step 514, the OS 190 recognizes that the USB memory 401 storing the recovery key 156 generated by the active server module B120 is connected. As a result, step 525 becomes YES, and the OS 190 decrypts and acquires the VMK using the recovery key 156 (step 526), decrypts and acquires the FVEK using the VMK (step 527), and decrypts the OS 190 using FVEK. And boot (steps 528A and 528B).
  • the BMC module 129 finishes the USB memory emulation (step 529), unmounts the recovery key 156 image file in the intra-chassis storage 154 (step 530), and recovers the recovery key 156 image to the SVP module 150.
  • a file unmount notification is made (step 531).
  • the SVP module 150 sets the current recovery key connection destination 202 in the recovery key management table 153 to “not connected” (step 532, FIG. 2E).
  • FIG. 2E shows a state where the current recovery key connection destination 202 corresponding to the server module B with the recovery key generation source computer ID 201 is set to “server module N”. It has changed.
  • step 525 is NO. Therefore, the user needs to manually connect the USB memory 401 storing the recovery key to the server module and restart it according to the instruction on the screen of the OS 190 (step 550).
  • step 512 determines whether the determination in step 512 is NO, emulation of the USB memory 401 is not performed. Therefore, the determination in step 525 is NO and the process proceeds to step 550 to manually connect the USB memory 401 to the server module as described above. Will be connected and restarted.
  • the BMC module 129 performs USB memory emulation using the image file of the active recovery key 156 stored in the intra-chassis storage 154. With this emulation, the takeover destination server module can recognize that the USB memory 401 storing the recovery key 156 generated by the active server module is connected, so that the OS 190 can be decrypted and started without any user operation. I can do it.
  • FIG. 6 is a block diagram showing a procedure for starting the encrypted OS 190 in the server module B120 using BitLocker (registered trademark).
  • the UEFI 161 When the power of the server module B120 is turned on, the UEFI 161 is first activated. The UEFI 161 is activated by the initial boot program, and acquires the hardware configuration information, the setting of the UEFI 161, and the value of the boot record (S2). Next, the UEFI 161 updates the PCR value of the TPM 126 based on the hardware related information, the setting of the UEFI 161, and the value of the boot record (S3). Next, the TPM 126 determines hardware consistency based on whether or not a previously stored PCR snapshot matches the current PCR.
  • the hardware configuration is the same as when the PCR snapshot was acquired. More specifically, it is determined whether or not hardware-related information such as hardware configuration, UEFI and BIOS settings, or boot record information (storage information) is the same as when the PCR snapshot was acquired. judge.
  • the TPM 126 determines that the information related to the hardware matches, and releases the SRK lock (S3). Here, if the information related to the hardware does not match, the TPM 126 determines that the hardware is not consistent and locks the SRK.
  • the UEFI 161 starts the boot manager of the system volume 1810 of the LU 181 as a boot disk (S4).
  • the boot manager decrypts the VMK (Volume Master Key) of the system volume 1810 using the unlocked SRK (S6). Next, the boot manager unlocks the FVEK (Full Volume Encryption Key) of the OS volume 1811 using the decrypted VMK. Then, the boot manager decrypts and activates the OS 190 of the OS volume 1811 encrypted using FVEK.
  • VMK Volume Master Key
  • FVEK Full Volume Encryption Key
  • the server module when the server module is changed due to failover or the like, the hardware configuration information does not change.
  • the boot device in the takeover destination server module N140, the boot device is changed to LU181, so the boot record information is changed. Therefore, the PCR snapshot held in the TPM 126 of the server module N140 does not match the PCR value calculated at the time of activation. For this reason, the SRK lock is not released and the VMK cannot be decrypted, so the recovery key stored in the USB memory 401 is requested.
  • the recovery key stored in the USB memory 401 when the recovery key stored in the USB memory 401 is requested, the recovery key corresponding to the PCR snapshot of the currently activated server module B 120 is selected from the recovery keys stored in the SVP module 150. . Then, after mounting the selected recovery key file on the BMC module 129, the USB memory emulation module 1291 of the BMC module 129 executes USB memory emulation.
  • the VMK can be decrypted without using the USB memory 401 storing the recovery key (S6), and the OS 190 encrypted automatically as described above can be started.
  • the recovery key is stored in the USB memory 401.
  • the storage medium for storing the recovery key is not limited to this, and a nonvolatile storage medium such as a semiconductor, an optical disk, or a magnetic disk is used. be able to.
  • fiber channel adapters 121 and 122 are illustrated as I / O devices conforming to the PCI express standard having a degeneration function, a network interface or a CNA (Converged Network Adapter) may be employed.
  • a network interface or a CNA Converged Network Adapter
  • the server module N120 takes over the processing of the server module B120 when a failure occurs.
  • the server module N140 may take over the processing of the server module B120 for maintenance.
  • the SVP module 150 instead of step 501 in FIG. 5A, the SVP module 150 receives a standby system switching instruction from the active system from a console or the like (not shown). And the process after step 502 of FIG. 5A is implemented.
  • the platform in an environment where a drive encryption function for determining the integrity of hardware components at the time of decryption is applied, the platform is intentionally provided by a degenerate function of an I / O device compliant with PCI express (hereinafter, PCIe).
  • PCIe PCI express
  • FIG. 7 is a block diagram of a computer system showing an example of degenerating an I / O device in which a failure has occurred.
  • the computer system of FIG. 7 has the same configuration as that of the computer system shown in FIG. 1 of the first embodiment.
  • a failure occurs in the fiber channel adapter 121 as an I / O device, and the fiber channel adapter 122 takes over the processing. This is the difference from the first embodiment. Since the system configuration and the processing at the time of saving the recovery key are the same as those in the first embodiment, a duplicate description is omitted.
  • FIG. 8A is a flowchart showing an example of processing for degenerating an I / O device in which a failure has occurred, and shows the first half.
  • FIG. 8B and FIG. 8C are flowcharts showing an example of a process for degenerating an I / O device in which a failure has occurred.
  • the BMC module 129 detects a failure (step 701), performs forced power OFF (step 702), and degenerates the PCIe (step 703).
  • the recovery key management table 153 is in the state shown in FIG. 2E.
  • the BMC module 129 requests the recovery key storage position to the SVP module 150 (step 704).
  • FIG. 2F shows a state in which the recovery key generation source computer ID 201 is changed to a state where it is connected to the server module B with respect to FIG. 2E which shows a state where the current recovery key connection destination corresponding to the server module B is not connected. It is.
  • the SVP module 150 notifies the BMC module 129 of the value of the storage location 204 of the recovery key to be mounted (FIG. 2F, “/conf/p2/RecoveryKey.bin” in this embodiment) (step 709). .
  • step 708 if it is determined in step 708 that the current recovery key storage presence / absence 203 of the selected row is “unsaved” or the recovery key storage position 204 has no value, the process proceeds to step 710 to return to the recovery key storage position.
  • the BMC module 129 is notified that there is no data or that the recovery key has not been saved.
  • step 711 when the recovery key storage location 204 is notified from the SVP module 150 (step 711 is YES), the BMC module 129 is the image file of the recovery key 156 held in the recovery key storage location 204 notified in step 710. Is mounted (step 712), and USB memory emulation is started (step 713). Then, the server module B 120 is instructed to be turned on (step 715), and the server module B is turned on.
  • the UEFI 161 When the UEFI 161 starts booting (step 717), it acquires hardware configuration information, UEFI settings, and boot record values (step 718), and updates the PCR values of the TPM 126 with reference to these values (step 719). .
  • step 723 the OS 190 starts booting (step 723 in FIG. 8C), but the TPM 126 fails to acquire the SRK (step 723 is NO), so whether or not a valid recovery key is connected to the USB memory 401. Determination is made (step 724).
  • the USB memory emulation in step 713 recognizes from the OS 190 that the USB memory 401 storing the recovery key generated by the active server module is connected, the determination result in step 724 Is YES, and the OS 190 uses the recovery key 156 to decrypt and acquire the VMK (step 725). Then, the OS 190 performs decryption and FVEK acquisition (step 726) using the acquired VMK, and decrypts and boots the OS 190 (steps 727A and 727B).
  • the BMC module 129 finishes the USB memory emulation (step 728), unmounts the recovery key 156 image file in the intra-chassis storage 154 (step 729), and restores the image of the recovery key 156 to the SVP module 150.
  • a file unmount notification is made (step 730).
  • the SVP module 150 changes the current recovery key connection destination 202 in the recovery key management table 153 to “not connected” (step 731).
  • FIG. 2E shows a state in which the recovery key generation source computer ID 201 corresponds to the server module B and the current recovery key connection destination 202 is in the state of the server module B.
  • FIG. 2E shows a state in which the recovery key generation source computer ID 201 corresponds to the server module B and the current recovery key connection destination 202 is in the state of the server module B.
  • step 724 is NO. Therefore, the user needs to manually connect the USB memory storing the recovery key to the server module and restart the computer according to the instruction on the screen of the OS 190 (step 750).
  • the chassis The BMC module 129 performs USB memory emulation using the recovery key image file stored before the PCIe degeneration stored in the internal storage, so that the OS 190 stores the recovery key stored before the PCIe degeneration. Since it is recognized that a USB memory is connected, a computer system capable of starting up the OS 190 without any user operation is provided.
  • this invention is not limited to each above-mentioned Example, Various modifications are included.
  • the above-described embodiments have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • each of the above-described configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • Each of the above-described configurations, functions, and the like may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files for realizing each function is stored in memory, a hard disk, a recording device such as an SSD (Solid State Drive), or non-volatile non-temporary storage such as an IC card, an SD card, or a DVD. It can be stored on a medium.
  • control lines and information lines indicate what is considered necessary for the explanation, and not all the control lines and information lines on the product are necessarily shown. Actually, it may be considered that almost all the components are connected to each other.
  • BitLocker registered trademark
  • security such as invalidating a key for decrypting an encrypted volume of OS 190 or an OS image, or locking a key for reading OS 190
  • security such as invalidating a key for decrypting an encrypted volume of OS 190 or an OS image, or locking a key for reading OS 190
  • the OS 190 when the OS 190 is encrypted or locked with a key generated from the unique value of the hardware, a copy of the unique value of the hardware when the key is generated is retained, and the integrity of the hardware is not maintained A recovery key for validating the key is generated and held. Then, a hardware eigenvalue is calculated at the time of starting the computer, and if this eigenvalue matches a duplicate of the hardware eigenvalue when the key is generated, it is determined that hardware consistency is secured, and the OS 190 uses the key. Decrypt or unlock. On the other hand, when the unique value of the hardware calculated at the start does not match the duplicate of the unique value of the hardware when the key is generated, the stored recovery key is used to decrypt the OS 190 or release the lock. I do.
  • the recovery key is stored in the SVP module 150 outside the server module (computer), and when the recovery key is used, the BMC module 129 that manages the server module performs device emulation so that the OS 190 to be started up can execute.
  • a recovery key may be provided.
  • the recovery key management table 153 that manages the recovery key in association with the identifier of the server module that generated the recovery key is used.
  • the recovery key is provided to the operating OS 190 by mounting the recovery key with the BMC module 129 provided for each server module and emulating a predetermined device. It can be done.
  • the recovery key management table 153 exclusively controls one recovery key to prohibit the use of the recovery key in use for starting other server modules, so that the same OS 190 can be used by a plurality of server modules. It can prevent starting.
  • the present invention is not limited to this, and the recovery key management table 153 and a plurality of recovery keys are stored. Any computer that can store the key in the storage unit, select the requested recovery key, and notify the BMC module 129 can be used.

Abstract

　プロセッサとメモリとＯＳを格納する記憶部とを備えた計算機で、記憶部を暗号化する暗号化方法であって、計算機のＯＳで記憶部を暗号化するための鍵を生成し、計算機は鍵を生成したときのハードウェア関連情報から固有値を演算して保持し、ＯＳの起動時に演算する固有値が保持された固有値と一致しない場合に用いる回復鍵を生成し、計算機に接続された管理計算機は、回復鍵を生成した計算機の識別子と対応付けて回復鍵を保持し、計算機は生成した鍵で記憶部を暗号化し、管理計算機は、計算機を停止させた後に、停止した計算機を引き継ぐ第２の計算機を選択し、停止した計算機で生成した回復鍵を、第２の計算機に通知してから、第２の計算機を起動させ、第２の計算機は、ハードウェア関連情報が同一でないと判定したときには、通知された回復鍵を用いて記憶部のＯＳを復号する。

Description

計算機システム及び記憶部の暗号化方法
　本発明は、暗号化されたシステムボリュームの復号時に、ハードウェアコンポーネントの整合性を判定するドライブ暗号化機能を備えた計算機システムに関する。
　ブートするシステムの機密性をボリューム単位で確保する機能として、特許文献１が知られている。この特許文献１には、「信頼できるプラットフォーム・モジュール（ＴＰＭ）を有するコンピュータにおいて、ブート・コンポーネントの予想されるハッシュ値を、プラットフォーム構成レジスタ（ＰＣＲ＝Ｐｌａｔｆｏｒｍ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｒｅｇｉｓｔｅｒ）内に置くことができ、それによりＴＰＭが秘密鍵を開示することが可能になる。次に、秘密鍵を用いてブート・コンポーネントを解読し、そのハッシュ値を計算し、ＰＣＲ内に置く。次いで、ＰＣＲを比較することができる。ＰＣＲを比較しない場合には、システムのための重要な秘密鍵へのアクセスを無効にすることができる。また、第１の秘密鍵は、第１の複数のＰＣＲ値が現存しているときにのみアクセス可能であり、第２の秘密鍵は、該第１の複数のＰＣＲ値の１つまたは複数が新しい値と置き換えられた後にのみアクセス可能となる。」と記載されている。
特開２００６－３２３８１４号公報
　特許文献１には、復号時にハードウェアコンポーネントの整合性を確保するドライブ暗号化機能が記載されている。この暗号化機能の代表的な実施例として、例えばＢｉｔＬｏｃｋｅｒ（登録商標）が知られている。ＢｉｔＬｏｃｋｅｒ（登録商標）はＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）自体のボリュームを暗号化することを特徴としたドライブ暗号化機能である。以降、復号時にハードウェアコンポーネントの整合性を判定し、ＯＳ自体のボリュームを暗号化することを特徴としたドライブ暗号化機能をドライブ暗号化機能と述べる。
　ドライブ暗号化機能が有効になっている場合、ＯＳのブートローダは、ＯＳを起動するために、まず、ＯＳが格納されているボリュームの復号化を行う。その際、ＯＳのブートローダはＴＰＭ（Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ）に格納されているＳＲＫ（Ｓｔｏｒａｇｅ　Ｒｏｏｔ　Ｋｅｙ）を用いる。
　ＵＥＦＩ（Ｕｎｉｆｉｅｄ　Ｅｘｔｅｎｓｉｂｌｅ　Ｆｉｒｍｗａｒｅ　Ｉｎｔｅｒｆａｃｅ）は、ブート時に、計算機の構成情報をＴＰＭのＰＣＲ（Ｐｌａｔｆｏｒｍ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｒｅｇｉｓｔｅｒ）に書き込む。そして、ドライブ暗号化機能を有効にしたときには、ＰＣＲの値がＴＰＭ内部に保存されたＰＣＲのスナップショットの値と一致した場合にのみ、ＴＰＭのロックが解除されるので、ブートローダは、ＴＰＭからＳＲＫを取り出すことが出来る。
　一方、計算機の構成情報が変わっていた場合、ＰＣＲの値とＰＣＲのスナップショットの値が一致しないため、ＯＳのブートローダはＳＲＫの取得に失敗するため、起動プロセスを一時停止し、ユーザに回復Ｋｅｙを接続するように要求する。
　回復Ｋｅｙは、暗号化機能を有効にする際にＯＳによって生成され、例えばＵＳＢメモリ等に保存される。ここで、回復Ｋｅｙとは、ハードウェアの変更があった際に、ＯＳをブートさせるためのＫｅｙとして用いられる情報である。
　ＯＳのブートローダに回復Ｋｅｙを要求された場合、ユーザが回復Ｋｅｙの保存されたＵＳＢメモリを計算機に接続して所定の操作を行うことで、ＯＳのブートが再開する。
　回復ＫｅｙによるＯＳブートの再開の機能は、ハードウェアの変更が行われた場合に、当該変更が不正なハードウェア変更と、期待したハードウェア変更のどちらであったのかを、起動を一時停止してユーザ操作を介在させることにより、ユーザに判断させるためのものである。
　さて、主にハイエンドクラスのサーバの場合、障害発生時に故障部位の縮退や待機系サーバへの切り換え等を自動的に行うことで、障害が発生した場合でも無人での業務継続を行う機能を持っている。
　しかし、ドライブ暗号化機能が有効な場合、デバイスの縮退や待機系サーバへの切り替えはハードウェアの変更と認識されるため、ＯＳの自動的な起動が出来ない、という問題があった。
　そこで本発明は、ボリュームの復号時にハードウェアコンポーネントの整合性を判定するドライブ暗号化機能を適用している環境で、プラットフォームが意図的にハードウェア構成を変更した場合に、ユーザ操作の介在なしに、ＯＳの起動が自動的に可能な計算機システムを提供する。
　本発明は、プロセッサとメモリとＯＳを格納する記憶部とを備えた計算機と、１以上の前記計算機を管理する管理計算機と、を備えた計算機システムであって、前記計算機は、前記記憶部を暗号化するために前記ＯＳが生成した鍵と、前記鍵を生成したときのハードウェアに関連する情報から演算した固有値と、を固有値保持部に保持し、前記計算機は、前記ＯＳの起動時に演算するハードウェアに関連する情報に基づく固有値が、前記保持された固有値と一致しない場合に、前記鍵に代わって前記記憶部を復号するための回復鍵を生成し、該鍵を前記管理計算機に通知し、前記鍵を用いて前記ＯＳを格納する記憶部を暗号化し、前記管理計算機が、前記回復鍵を受け付けて、前記回復鍵を生成した計算機の識別子と対応付けて前記回復鍵を保持し、前記管理計算機が、前記計算機を停止させた後、前記停止させた計算機を引き継ぐ第２の計算機を選択し、前記停止させた計算機で生成した回復鍵を、前記選択した第２の計算機に通知してから前記第２の計算機を起動し、前記第２の計算機が、ハードウェアに関連する情報から固有値を演算し、前記固有値保持部に予め保持された固有値に一致するか否かを判定し、前記演算した固有値と、予め保持された前記固有値が一致しないときには、前記管理計算機から通知された回復鍵を用いて、前記記憶部のＯＳを復号して、当該ＯＳを起動する。
　本発明によれば、ＯＳの記憶部の復号時にハードウェアに関連する情報から固有値を演算し、予め保持された固有値に一致するか否かによりハードウェアの整合性を判定する計算機システムで、計算機のハードウェア構成を変更した場合であっても、ユーザ操作の介在なしに、自動的に回復鍵を適用してＯＳを起動することが可能となる。
　上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。
本発明の第１の実施例を示し、計算機システムの一例を示すブロック図である。 本発明の第１の実施例を示し、回復Ｋｅｙ管理テーブルの初期状態を示す図である。 本発明の第１の実施例を示し、回復Ｋｅｙ管理テーブルの使用開始時を示す図である。 本発明の第１の実施例を示し、回復Ｋｅｙ管理テーブルの回復Ｋｅｙの保存時を示す図である。 本発明の第１の実施例を示し、回復Ｋｅｙ管理テーブルをサーバモジュールＮで利用する際の図である。 本発明の第１の実施例を示し、サーバモジュールＮで回復Ｋｅｙ管理テーブルの利用を終了した状態を示す図である。 本発明の第１の実施例を示し、サーバモジュールＢで回復Ｋｅｙ管理テーブルを利用する状態を示す図である。 本発明の第１の実施例を示し、回復Ｋｅｙの生成時に行われる処理の一例を示すフローチャートで、メインルーチンを示す。 本発明の第１の実施例を示し、回復Ｋｅｙの生成時に行われる処理の一例を示すフローチャートで、サブルーチンの前半部を示す。 本発明の第１の実施例を示し、回復Ｋｅｙの生成時に行われる処理の一例を示すフローチャートで、サブルーチンの後半部を示す。 本発明の第１の実施例を示し、障害発生時にサーバモジュールを切替える例を示す計算機システムのブロック図である。 本発明の第１の実施例を示し、障害発生時にサーバモジュールを切替える処理の一例を示すフローチャートで、前半部を示す。 本発明の第１の実施例を示し、障害発生時にサーバモジュールを切替える処理の一例を示すフローチャートで、中盤部を示す。 本発明の第１の実施例を示し、障害発生時にサーバモジュールを切替える処理の一例を示すフローチャートで、後半部を示す。 本発明の第１の実施例を示し、ＯＳボリュームの暗号化の一例を示すブロック図である。 本発明の第２の実施例を示し、障害が発生したＩ／Ｏデバイスを縮退する例を示す計算機システムのブロック図である。 本発明の第２の実施例を示し、障害が発生したＩ／Ｏデバイスを縮退する処理の一例を示すフローチャートで、前半部を示す。 本発明の第２の実施例を示し、障害が発生したＩ／Ｏデバイスを縮退する処理の一例を示すフローチャートで、中盤部を示す。 本発明の第２の実施例を示し、障害が発生したＩ／Ｏデバイスを縮退する処理の一例を示すフローチャートで、後半部を示す。
　以下、本発明の一実施形態について添付図面を用いて説明する。
　本実施例１では、暗号化された計算機システムボリュームの復号時に、ハードウェアコンポーネントの整合性を判定するドライブ暗号化機能としてＢｉｔＬｏｃｋｅｒ（登録商標）が適用されている計算機システムを用いる。この計算機システムは、コールドスタンバイ機能によってプラットフォームが意図的にハードウェアの構成を変更した場合であっても、ユーザ操作の介在なしに、自動的に起動する計算機システムの例について説明する。ここでは、最初にシステム構成図、次に回復Ｋｅｙ保存時の処理、最後に待機系サーバへの切り替え時の処理の順に説明する。
　まず、図１と図２を用いて本発明によるシステムの構成の一例である、ブレードサーバのコールドスタンバイ構成について説明する。図１は、計算機システムの一例を示すブロック図である。図２Ａ～図２Ｆは、回復Ｋｅｙ管理テーブルの状態遷移を示す図である。
　本実施例は、サーバモジュールＢ１２０を現用系、サーバモジュールＮ１４０を予備系としたコールドスタンバイの構成である。
　ブレードサーバシャーシ１００は１つ以上のサーバモジュール（サーバブレード）１１０～１４０と、ＳＶＰ（ＳｅｒＶｉｃｅ　Ｐｒｏｃｅｓｓｏｒ）モジュール１５０と、ファイバチャネルスイッチ１７０と、ストレージ装置１８０を有する。
　サーバモジュールＢ１２０は、コンピュータとしての一般的な要素であるＣＰＵ１２４、メモリ１２７、チップセット１２５、ネットワークインターフェース１２８、ファイバチャネルアダプタ（または、ホストバスアダプタ）１２１、１２２、ＵＥＦＩ（Ｕｎｉｆｉｅｄ　Ｅｘｔｅｎｓｉｂｌｅ　Ｆｉｒｍｗａｒｅ　Ｉｎｔｅｒｆａｃｅ）１６１に加えて、ＢＭＣ（Ｂａｓｅｂｏａｒｄ　Ｍａｎａｇｅｍｅｎｔ　Ｃｏｎｔｒｏｌｌｅｒ）モジュール１２９と、ＴＰＭ（Ｔｒｕｓｔｅｄ　Ｐｌａｔｆｏｒｍ　Ｍｏｄｕｌｅ）１２６を備える。なお、ＴＰＭ１２６は、ＰＣＲ（Ｐｌａｔｆｏｒｍ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｒｅｇｉｓｔｅｒ）を含む。また、メモリ１２７にはＯＳ１９０がロードされて、ＣＰＵ１２４によって実行される。また、Ｉ／Ｏデバイスとしてのファイバチャネルアダプタ１２１、１２２は、縮退機能を備えたＰＣＩ　ｅｘｐｒｅｓｓの規格に準拠する。
　ＢＭＣモジュール１２９は、サーバモジュールＢ１２０に対する状態管理機能と、仮想メディア機能（ＵＳＢメモリエミュレーション等）を提供するサーバ管理モジュールである。
　ＢＭＣモジュール１２９の状態管理機能は、サーバモジュールＢ１２０の障害検出機能と、電源制御機能と、ＰＣＩｅ縮退制御機能（障害が発生したＰＣＩ　Ｅｘｐｒｅｓｓデバイスを縮退させる機能）と、ＳＶＰモジュール１５０への障害報告機能を有する。また、ＢＭＣモジュール１２９の仮想メディア機能は、ＢＭＣモジュール１２９上あるいはネットワーク上のイメージファイルをマウントして、ＵＳＢメモリのエミュレーションを行う機能（ＵＳＢメモリエミュレーションモジュール１２９１（図６参照））を有する。また、ＢＭＣモジュール１２９は計算機の本体であるサーバモジュールＢ１２０の給電を遮断した状態でも、常時通電した状態で稼働しており、サーバモジュールＢ１２０から独立して電源制御を行うことができる。
　サーバモジュールＮ１４０はサーバモジュールＢ１２０と同等の構成要素を持つサーバモジュールである。なお、サーバモジュールＡ（１１０）～Ｎ（１４０）の総称は、符号のないサーバモジュールで表す。また、サーバモジュールＡ（１１０）～Ｎ（１４０）の構成は、図１に示したブロック図と同等であるので、重複した説明を省略する。
　ＳＶＰモジュール１５０は、ブレードサーバシャーシ１００内の各サーバモジュールの管理を行う計算機である。ＳＶＰモジュール１５０は、図示しないプロセッサやメモリを含むＳＶＰマイコン１５２と、ネットワークスイッチ１５１と、回復Ｋｅｙを格納することが可能なシャーシ内ストレージ１５４と、を備えるモジュールである。シャーシ内ストレージ１５４には、回復Ｋｅｙ管理テーブル１５３と１以上の回復Ｋｅｙ１５５、１５６が格納される。回復Ｋｅｙ管理テーブル１５３と回復Ｋｅｙ１５５、１５６は、必要に応じてＳＶＰマイコン１５２のメモリに読み込まれる。なお、ネットワークスイッチ１５１はブレードサーバシャーシ１００内で、各サーバモジュールと及びファイバチャネルスイッチ１７０とＳＶＰモジュール１５０を接続する管理ネットワークを構成する。また、各サーバモジュールは、図示しない業務用ネットワークに接続されて、クライアント計算機等からのアクセスを受け付ける。なお、回復Ｋｅｙ１５５、１５６の総称については、以下、符号無しで記載する。また、ＳＶＰモジュール１５０は、図示しない管理ネットワークを介してファイバチャネルスイッチ１７０に接続され、サーバモジュールが読み込むＬＵ１８１を切替えることができる。これにより、各サーバモジュールが起動するＯＳを切替えることができる。
　ＳＶＰマイコン１５２はＢＭＣモジュール１２９にネットワークスイッチ１５１を介して接続されている。ＢＭＣモジュール１２９はネットワークを介してシャーシ内ストレージ１５４上の所定の領域をマウントしてＵＳＢメモリエミュレーションを行うことで、例えば、回復Ｋｅｙをシャーシ内ストレージ１５４に格納することができる。
　回復Ｋｅｙ管理テーブル１５３の例を、図２Ａ～図２Ｆに示す。なお、図２Ａ～図２Ｆに示される回復Ｋｅｙ管理テーブル１５３は、回復Ｋｅｙ管理テーブル１５３に含まれる情報の遷移を、示している。
　図２Ａは、回復Ｋｅｙ管理テーブル１５３の初期状態を示す図である。図２Ｂは、回復Ｋｅｙ管理テーブル１５３の使用開始時を示す図である。図２Ｃは、回復Ｋｅｙ管理テーブル１５３に回復Ｋｅｙを保存する際の図である。図２Ｄは、回復Ｋｅｙ管理テーブル１５３をサーバモジュールＮで利用する際の図である。図２Ｅは、サーバモジュールＮで回復Ｋｅｙ管理テーブル１５３の利用を終了した状態を示す図である。図２Ｆは、サーバモジュールＢで回復Ｋｅｙ管理テーブル１５３を利用する状態を示す図である。
　回復Ｋｅｙ管理テーブル１５３は、例えば、回復Ｋｅｙ生成元計算機ＩＤ２０１と、現在の回復Ｋｅｙ接続先２０２と、回復Ｋｅｙの保存有無２０３と、回復Ｋｅｙの格納位置２０４を有する行で構成される。行の数は、搭載可能なサーバモジュールの数に対応するテーブルとなる。
　回復Ｋｅｙ生成元計算機ＩＤ２０１は、回復Ｋｅｙを生成したサーバモジュールを示す値を格納するフィールドである。本実施例において、回復Ｋｅｙ生成元計算機ＩＤ２０１の値にはブレードサーバで構成されるサーバモジュールのスロット番号を示す情報が予め設定されているものとする。回復Ｋｅｙの保存有無２０３は、回復Ｋｅｙが保存されている状態であるか否かを示す値を格納するフィールドである。このフィールドの初期値は「未保存」で、回復Ｋｅｙの保存操作を行った際に「保存済」、回復Ｋｅｙの削除操作で「未保存」の値をＳＶＰモジュール１５０が設定する。
　回復Ｋｅｙの格納位置２０４は、回復Ｋｅｙ生成元計算機ＩＤ２０１に対応する回復Ｋｅｙの格納位置を示す値を格納するフィールドである。この値は本実施例ではシャーシ内ストレージ１５４上の領域を指すファイルパスである。本実施例においては、回復Ｋｅｙ生成元計算機ＩＤ２０１に対応したファイルパスが予め割り当てられているものとする。
　現在の回復Ｋｅｙ接続先２０２は、該当する行の回復Ｋｅｙの格納位置２０４が示す領域の接続先（サーバモジュール）を示す値を格納するフィールドである。
　これはひとつの回復Ｋｅｙの格納位置２０４を、複数のサーバモジュールが同時にマウントする事を防ぐために用いる。このフィールドの初期値は「未接続」で、回復Ｋｅｙの格納位置２０４が示す領域が、ＢＭＣモジュール１２９によってマウントされるときに該当するサーバモジュールを示すＩＤ、ＢＭＣモジュール１２９によってアンマウントされたときに「未接続」の値をＳＶＰモジュール１５０が設定する。「未接続」という値はいずれのサーバモジュールにもマウントされていない状態を示す。
　本実施例はブレードサーバであるため、行数と回復Ｋｅｙ生成元計算機ＩＤ２０１と回復Ｋｅｙの格納位置２０４を予め割り当てているが、動的に割り当てるようにしても良い。また、本実施例では回復Ｋｅｙの保存の有無をテーブルで管理しているが、例えば回復Ｋｅｙの格納ファイルの有無を識別するようにしても良い。
　例えば、図２Ａの回復Ｋｅｙ管理テーブル１５３は、サーバモジュールＢで生成した回復Ｋｅｙがシャーシ内ストレージ上の／ｃｏｎｆ／ｐ２／ＲｅｃｏｖｅｒｙＫｅｙ．ｂｉｎという領域に格納されており、現在どこからもマウントされていない状態であることを示している。
　ストレージ装置１８０は複数のＬＵ（Ｌｏｇｉｃａｌ　Ｕｎｉｔ）１８１を有するモジュールである。ストレージ装置１８０とそれぞれのサーバモジュールはファイバチャネルスイッチ１７０を介して接続されており、サーバモジュールとＬＵ１８１の接続を論理的に切り替えることが出来る。本実施例ではＬＵ１８１にＯＳ１９０が格納されているものとする。
　次にサーバモジュールＢ１２０に対応する回復Ｋｅｙ１５６を、シャーシ内ストレージ１５４に格納する処理の一例を、図３Ａ～図３Ｃのフローチャートを用いて説明する。
　サーバモジュールＢ１２０上ではＬＵ１８１からブートしたＯＳ１９０が起動しているものとする。ＯＳ１９０は、上述のＢｉｔＬｏｃｋｅｒ（登録商標）機能を有する。この状態でＯＳ１９０がユーザからのＢｉｔＬｏｃｋｅｒ（登録商標）機能の有効化の指示を受け付ける（図３Ａのステップ３００）。なお、サーバモジュールＢ１２０は、図示しないコンソールや端末の入力装置から上記指示を受け付けるものとする。
　次に、ＯＳ１９０は、ＴＰＭ１２６にＳＲＫ（Ｓｔｏｒａｇｅ　Ｒｏｏｔ　Ｋｅｙ）の生成を依頼し（ステップ３０１）、ＴＰＭ１２６が現在のＰＣＲの値を元に、ＳＲＫを生成する（ステップ３０２）。なお、ＰＣＲの値は、ハードウェアの構成情報と、ブートレコードの情報と、ＵＥＦＩ１６１の設定情報からＴＰＭ１２６で演算した値であり、サーバモジュールＢ１２０の固有値である。なお、ハードウェアの構成情報と、ブートレコードの情報と、ＵＥＦＩ１６１の設定情報は、ハードウェアに関連する情報（ハードウェア関連情報）として扱うことができる。
　次にＯＳ１９０は、現在のＰＣＲのスナップショットの作成をＴＰＭ１２６に依頼し（ステップ３０３）、ＴＰＭ１２６が現在のＰＣＲのスナップショットを取得して、ＴＰＭ１２６内に保存する（ステップ３０４）。
　次にＯＳ１９０は、ＳＲＫを元にＶＭＫ（Ｖｏｌｕｍｅ　Ｍａｓｔｅｒ　Ｋｅｙ）の生成（ステップ３０５）と回復Ｋｅｙの生成（ステップ３０６）を行う。
　そして、ＯＳ１９０はユーザに対して回復Ｋｅｙの保存先を選択させるために、例えば画面にダイアログを表示する（ステップ３０７）。この画面は、図示しないコンソールや端末の出力装置に対して、サーバモジュールＢ１２０が所定の画面を出力する。
　ＯＳ１９０がユーザから保存先としてシャーシ内ストレージ１５４を指示された場合（ステップ３０８がシャーシ内ストレージ）は、図３Ｂのステップ３０９へ進む。そして、ＢＭＣモジュール１２９は、ＳＶＰモジュール１５０に対して回復Ｋｅｙ格納位置の要求を行う（ステップ３０９）。
　ＳＶＰモジュール１５０は、回復Ｋｅｙ管理テーブル１５３を参照して、回復Ｋｅｙ生成元計算機ＩＤ２０１と要求元の計算機ＩＤが一致した行を選択する（ステップ３１０及び図２Ａの２行目）。
　次に、ＳＶＰモジュール１５０は選択中の行の、現在の回復Ｋｅｙ接続先２０２に、回復Ｋｅｙの格納を要求した計算機ＩＤを設定する（ステップ３１１及び図２Ｂの現在の回復Ｋｅｙ接続先２０２）。図２Ｂの回復Ｋｅｙ管理テーブル１５３は、回復Ｋｅｙ生成元計算機ＩＤ２０１が「サーバモジュールＢ」に対応する現在の回復Ｋｅｙ接続先２０２が未接続な状態のときを示す図２Ａに対して、サーバモジュールＢに接続した状態に変化したものである。
　すなわち、図２Ｂの回復Ｋｅｙ管理テーブル１５３では、第２行目の現在の回復Ｋｅｙ接続先２０２は、「未接続」から「サーバモジュールＢ」へ更新される。
　そして、ＳＶＰモジュール１５０は各サーバモジュールのＢＭＣモジュール１２９に対してマウントすべき回復Ｋｅｙの格納位置２０４（本実施例においては２４「／ｃｏｎｆ／ｐ２／ＲｅｃｏｖｅｒｙＫｅｙ．ｂｉｎ」）を通知する（ステップ３１２及び図２Ｂの２０４）。
　ＢＭＣモジュール１２９は、ＳＶＰモジュール１５０から通知された回復Ｋｅｙ格納位置にある回復Ｋｅｙのイメージファイルをマウントし（ステップ３１３）、ＵＳＢメモリのエミュレーションを開始する（ステップ３１４）。この時、ＯＳ１９０は、ＢＭＣモジュール１２９にＵＳＢメモリが接続されたように認識する。
　次に、ＯＳ１９０がユーザから回復Ｋｅｙの保存操作（ステップ３１５）を受け付けると、ＯＳ１９０は回復ＫｅｙをＢＭＣモジュール１２９がエミュレーションしているＵＳＢメモリに書き込む（図３Ｃのステップ３１６）。ＢＭＣモジュール１２９は、ＳＶＰモジュール１５０のシャーシ内ストレージ１５４をマウントしてＵＳＢメモリエミュレーションを行っているので、回復Ｋｅｙ１５６はシャーシ内ストレージ１５４上の領域に書き込まれる事になる（ステップ３１７）。
　回復Ｋｅｙの保存が完了すると、ＢＭＣモジュール１２９はＵＳＢメモリエミュレーションを終了（ステップ３１８）、シャーシ内ストレージ１５４の回復Ｋｅｙイメージファイルをアンマウント（ステップ３１９）、ＳＶＰモジュール１５０に対して回復Ｋｅｙ保存完了通知を行う（ステップ３２０）。
　ＳＶＰモジュール１５０はステップ３２０の通知を受けて、回復Ｋｅｙ管理テーブル１５３の現在の回復Ｋｅｙ接続先２０２を未接続に設定し（図２Ｃ参照）、回復Ｋｅｙの保存有無２０３を「保存済」（図２Ｃの２０３）に設定する（ステップ３２１）。
　図２Ｃは、回復Ｋｅｙ生成元計算機ＩＤ２０１がサーバモジュールＢに対応する現在の回復Ｋｅｙ接続先２０２が「サーバモジュールＢ」、回復Ｋｅｙの保存有無２０３が「未保存」な状態のときを示す図２Ｂに対して、現在の回復Ｋｅｙ接続先２０２が「未接続」、回復Ｋｅｙの保存有無２０３が「保存済」の状態に変化したものである。
　そして、ＯＳ１９０がＶＭＫを基にＦＶＥＫ（Ｆｕｌｌ　Ｖｏｌｕｍｅ　Ｅｎｃｒｙｐｔｉｏｎ　Ｋｅｙ）の生成（ステップ３２２）とＯＳボリュームの暗号化を行い（ステップ３２３）暗号化機能が有効な状態となる。なお、ＬＵ１８１は、図６で示すように、ブレードマネージャ及びＶＭＫを格納するシステムボリューム（図中ＳＹＳ　ＶＯＬＵＭＥ）１８１０と、ＦＶＥＫとＯＳ１９０を格納したＯＳボリューム１８１１の２つのボリュームから構成された例を示す。
　なお、図３Ａのステップ３０８で、ＵＳＢメモリを選択した場合の処理は、従来のＢｉｔＬｏｃｋｅｒシステムの例である。従来のＢｉｔＬｏｃｋｅｒシステムでは、ユーザがサーバモジュールＢにＵＳＢメモリを取り付けて（ステップ３５０）、ＯＳ１９０がユーザから回復Ｋｅｙの保存操作（ステップ３５１）を受け付けると、ＯＳ１９０は回復Ｋｅｙをステップ３５０で取り付けたＵＳＢメモリに書き込む（ステップ３５２）。上記の処理によって、回復ＫｅｙをＵＳＢメモリに記憶する。
　次に本実施例におけるコールドスタンバイによる待機系（サーバモジュールＮ１４０）への切り替えを、図２Ｃ～図２Ｅ、図４、図５Ａ～図５Ｃを参照しながら以下に説明する。
　現用系のサーバモジュールＢ１２０でサーバモジュール切り替えの必要な障害が発生した場合、ＳＶＰモジュール１５０が障害を検出し（図５Ａのステップ５０１）、現用系サーバモジュールＢ１２０の強制電源ＯＦＦと電源投入抑止（ステップ５０２）をサーバモジュールＢ１２０に通知してから、予備系サーバモジュールＮ１４０の電源投入抑止を行う（ステップ５０３）。ただし、予備系のサーバモジュールＮ１４０のＢＭＣモジュール１２９は、常時電力が供給され、ＣＰＵ１２４やメモリ１２７への電源を制御することができる。
　次に、サーバモジュールＢ１２０からサーバモジュールＮ１４０へコールドスタンバイの切り替え処理を実施する（Ｍ＋Ｎ切替え処理）。この処理の中でＳＶＰモジュール１５０はサーバモジュールとＬＵ１８１の接続経路を、図４に示す経路４００から経路４０１に変更する指令をファイバチャネルスイッチ１７０に送信する。これにより、サーバモジュールＮ１４０がＬＵ１８１からＯＳ１９０を読み込んで起動するように設定が変更される（ステップ５０４）。このとき、回復Ｋｅｙ管理テーブル１５３は、図２Ｃの状態である。なお、図４は、系切替えを行うサーバモジュールＢ１２０とサーバモジュールＮ１４０のブロック図で、図１にサーバモジュールＮ１４０を加えたものである。その他の構成は、前記実施例１と同様であるので、重複した説明は省略する。
　次に、予備系サーバモジュールＮ１４０のＢＭＣモジュール１２９は、ＳＶＰモジュール１５０に対して回復Ｋｅｙ格納位置の要求を行う（ステップ５０５）。
　ＳＶＰモジュール１５０は、ステップ５０５の要求をコールドスタンバイ切り替えの予備系のサーバモジュールＮ１４０から受信した場合（ステップ５０６がＹＥＳ）、回復Ｋｅｙ管理テーブル１５３から「回復Ｋｅｙ生成元計算機ＩＤ２０１」が現用系の計算機ＩＤ２０１と一致する行を選択する（ステップ５０７、図２Ｃ）。
　本実施例の場合、選択される行は要求元（系の引き継ぎ先）のサーバモジュールＮ１４０に対応する計算機ＩＤ２０１ではなく、切替え元のサーバモジュールＢ１２０に対応する計算機ＩＤ２０１の行である。図２Ｃは、説明のために行＃２が選択されたことを示すものである。
　ＳＶＰモジュール１５０は、回復Ｋｅｙ管理テーブル１５３より、選択中の行の回復Ｋｅｙの保存有無２０３が「保存済」であることを判定する。本実施例では回復Ｋｅｙが保存されているので（ステップ５０９が有り）、選択中の行の現在の回復Ｋｅｙ接続先２０２に、要求元のサーバモジュールＮ１４０を示すＩＤを設定する（ステップ５１０、図２Ｄ）。
　図２Ｄは、回復Ｋｅｙ生成元計算機ＩＤ２０１がサーバモジュールＢ１２０に対応し、現在の回復Ｋｅｙ接続先２０２が未接続な状態のときを示す図２Ｃに対して、サーバモジュールＮ１４０に接続した状態に変化したものである。
　そして、ＳＶＰモジュール１５０は、切り替え先のサーバモジュールＮ１４０のＢＭＣモジュール１２９に対して、マウントすべき回復Ｋｅｙの格納位置２０４の値（図２Ｄ、本実施例においては「／ｃｏｎｆ／ｐ２／ＲｅｃｏｖｅｒｙＫｅｙ．ｂｉｎ」）を通知する（ステップ５１０）。
　一方、ステップ５０９の判定で、選択中の行の現在の回復Ｋｅｙの保存有無２０３が「未保存」あるいは回復Ｋｅｙ格納位置２０４に値がない場合には、ステップ５１１へ進んで、回復Ｋｅｙ格納位置がないこと、または回復Ｋｅｙが格納されていないことをＢＭＣモジュール１２９に通知する。
　引き継ぎ先のサーバモジュールＮ１４０のＢＭＣモジュール１２９は、ＳＶＰモジュール１５０から回復Ｋｅｙの格納位置２０４が通知された場合（ステップ５１２がＹＥＳ）、ステップ５１１で通知された位置に格納されている回復Ｋｅｙ１５６のイメージファイルをマウントし（ステップ５１３）、ＵＳＢメモリ４０１（図４参照）のエミュレーションを開始する（５１４）。この処理により、サーバモジュールＮ１４０は、ＢＭＣモジュール１２９側で回復Ｋｅｙ１５６を格納したＵＳＢメモリ４０１が追加されたことを認識することができる。
　次に、ＢＭＣモジュール１２９は、ＳＶＰモジュール１５０に対して系切り替え準備完了を通知する（ステップ５１５）。ＳＶＰモジュール１５０は、ステップ５１５の通知を受けて予備系のサーバモジュールＮ１４０の電源投入抑止の解除と電源ＯＮの指示を行い（ステップ５１６）、予備系のサーバモジュールＮ１４０の電源がＯＮとなる（ステップ５１７）。
　ＵＥＦＩ１６１はブートを開始すると（ステップ５１８）、ハードウェア構成情報とＵＥＦＩ１６１の設定とブートレコードの値を取得し（ステップ５１９）、ＴＰＭ１２６のＰＣＲの値を更新する（ステップ５２０）。
　ここで、本実施例では現用系のサーバモジュールＢ１２０と待機系サーバモジュールＮ１４０の切り替えを行っているため、ＳＶＰモジュール１５０がファイバチャネルスイッチ１７０のパスを変更して、サーバモジュールＮ１４０のブートデバイスの変更（ハードウェア構成情報の変更）が行われた状態である。そのため、サーバモジュールＮ１４０のＴＰＭ１２６に保持しているＰＣＲスナップショットと、今回演算したＰＣＲの比較結果は不一致となり、ＳＲＫのロックは解除されない（ステップ５２１がＮＯ）。
　この状態でＯＳ１９０は図６に示すブートマネージャにより、ブートを開始するが、ＴＰＭ１２６のＳＲＫの取得に失敗するため（ステップ５２４がＮＯ）、有効な回復Ｋｅｙを格納したＵＳＢメモリ４０１が接続されているか否かを判定する（ステップ５２５）。
　本実施例では、ステップ５１４のＵＳＢメモリエミュレーションによって、ＯＳ１９０からは現用系のサーバモジュールＢ１２０で生成した回復Ｋｅｙ１５６が保存されたＵＳＢメモリ４０１が接続されたように認識されている。これにより、ステップ５２５はＹＥＳとなり、ＯＳ１９０は回復Ｋｅｙ１５６を使ってＶＭＫの復号と取得（ステップ５２６）を行い、ＶＭＫを使ってＦＶＥＫの復号と取得（ステップ５２７）を行い、ＦＶＥＫによりＯＳ１９０を復号してブートする（ステップ５２８Ａ、５２８Ｂ）。
　ＯＳ１９０のブートが完了すると、ＢＭＣモジュール１２９はＵＳＢメモリエミュレーションを終了し（ステップ５２９）、シャーシ内ストレージ１５４の回復Ｋｅｙ１５６のイメージファイルをアンマウントし（ステップ５３０）、ＳＶＰモジュール１５０に対して回復Ｋｅｙ１５６のイメージファイルのアンマウント通知を行う（ステップ５３１）。
　ＳＶＰモジュール１５０は、ステップ５３１の通知を受けて、回復Ｋｅｙ管理テーブル１５３の現在の回復Ｋｅｙ接続先２０２を「未接続」に設定する（ステップ５３２、　図２Ｅ）。
　図２Ｅは、回復Ｋｅｙ生成元計算機ＩＤ２０１がサーバモジュールＢに対応する現在の回復Ｋｅｙ接続先２０２が「サーバモジュールＮ」に設定された状態を示す図２Ｄに対して、「未接続」の状態に変化したものである。
　参考までに従来のＢｉｔＬｏｃｋｅｒを用いた計算機システムは、ステップ５２５がＮＯとなる。そのため、ユーザはＯＳ１９０の画面による指示に従い、回復Ｋｅｙの保存されたＵＳＢメモリ４０１を手動でサーバモジュールに接続して再起動を行う必要がある（ステップ５５０）。
　なお、ステップ５１２の判定がＮＯとなった場合は、ＵＳＢメモリ４０１のエミュレーションを行わないので、ステップ５２５の判定でＮＯとなり、ステップ５５０に進んで、上述のようにＵＳＢメモリ４０１を手動でサーバモジュールに接続して再起動を行うことになる。
　上記した処理により、復号時にハードウェアコンポーネントの整合性を判定するドライブ暗号化機能を適用している環境で、コールドスタンバイによる待機系への切り替えによってプラットフォームが意図的にハードウェア構成などを変更した場合であっても、シャーシ内ストレージ１５４に格納した現用系の回復Ｋｅｙ１５６のイメージファイルを使ってＢＭＣモジュール１２９がＵＳＢメモリエミュレーションを行う。このエミュレーションによって、引き継ぎ先のサーバモジュールでは現用系サーバモジュールで生成した回復Ｋｅｙ１５６を格納したＵＳＢメモリ４０１が接続されたように認識できるため、ユーザ操作の介在なしにＯＳ１９０を復号して起動することが出来る。
　図６は、ＢｉｔＬｏｃｋｅｒ（登録商標）を用いたサーバモジュールＢ１２０における暗号化されたＯＳ１９０の起動の手順を示すブロック図である。サーバモジュールＢ１２０の電源をＯＮにすると、まず、ＵＥＦＩ１６１が起動する。ＵＥＦＩ１６１は初期ブートプログラムが起動して、ハードウェア構成情報とＵＥＦＩ１６１の設定と、ブートレコードの値を取得する（Ｓ２）。次に、ＵＥＦＩ１６１は、ハードウェア関連情報とＵＥＦＩ１６１の設定と、ブートレコードの値をもとに、ＴＰＭ１２６のＰＣＲの値を更新する（Ｓ３）。次に、ＴＰＭ１２６では、予め格納したＰＣＲのスナップショットと、現在のＰＣＲが一致するか否かにより、ハードウェアの整合性を判定する。つまり、ＰＣＲのスナップショットを取得した時点と同一のハードウェア構成であるか否かを判定する。より詳しくは、ハードウェアの構成やＵＥＦＩやＢＩＯＳの設定またはブートレコードの情報（ストレージの情報）などのハードウェアに関連する情報が、ＰＣＲのスナップショットを取得した時点と同一であるか否かを判定する。
　ＰＣＲのスナップショットと、現在のＰＣＲが一致する場合、ＴＰＭ１２６は、ハードウェアに関連する情報が一致すると判定してＳＲＫのロックを解除する（Ｓ３）。ここで、ＴＰＭ１２６は、ハードウェアに関連する情報が一致しない場合には、ハードウェアの整合性がとれないと判定してＳＲＫをロックする。
　次に、ＵＥＦＩ１６１は、ブートディスクであるＬＵ１８１のシステムボリューム１８１０のブートマネージャを起動する（Ｓ４）。
　ブートマネージャは、ロックを解除されたＳＲＫを用いて、システムボリューム１８１０のＶＭＫ（Ｖｏｌｕｍｅ　Ｍａｓｔｅｒ　Ｋｅｙ）を復号する（Ｓ６）。次に、ブートマネージャは、復号したＶＭＫを用いてＯＳボリューム１８１１のＦＶＥＫ（Ｆｕｌｌ　Ｖｏｌｕｍｅ　Ｅｎｃｒｙｐｔｉｏｎ　Ｋｅｙ）のロックを解除する。そして、ブートマネージャは、ＦＶＥＫを用いて暗号化されたＯＳボリューム１８１１のＯＳ１９０を復号して起動する。
　上記の手順で、ＴＰＭ１２６で演算したＰＣＲと、ＰＣＲのスナップショットが一致しない場合には、ＳＲＫがロックされるので、ＶＭＫを復号できず、ＵＳＢメモリ４０１に格納した回復Ｋｅｙが要求される。
　また、フェイルオーバなどでサーバモジュールを変更した場合には、ハードウェア構成情報には変化がないが、引き継ぎ先のサーバモジュールＮ１４０では、ブートデバイスがＬＵ１８１に変更されるため、ブートレコード情報が変更されるため、サーバモジュールＮ１４０のＴＰＭ１２６に保持されていたＰＣＲのスナップショットと、起動時に演算したＰＣＲの値は一致しない。このため、ＳＲＫのロックは解除されず、ＶＭＫを復号できないので、ＵＳＢメモリ４０１に格納した回復Ｋｅｙが要求される。
　ここで、本発明では、ＵＳＢメモリ４０１に格納した回復Ｋｅｙが要求されたときには、ＳＶＰモジュール１５０に保持した回復Ｋｅｙから、現在起動中のサーバモジュールＢ１２０のＰＣＲスナップショットに対応する回復Ｋｅｙを選択する。そして、選択した回復ＫｅｙのファイルをＢＭＣモジュール１２９にマウントしてから、ＢＭＣモジュール１２９のＵＳＢメモリエミュレーションモジュール１２９１で、ＵＳＢメモリのエミュレーションを実行する。
　これにより、回復Ｋｅｙを格納したＵＳＢメモリ４０１を用いることなく、ＶＭＫを復号することが可能となり（Ｓ６）、上述のように自動的に暗号化されたＯＳ１９０を起動することができるのである。
　なお、上記では回復ＫｅｙをＵＳＢメモリ４０１に格納する例を示したが、回復Ｋｅｙを格納する記憶媒体はこれに限定されるものではなく、半導体や光ディスクあるいは磁気ディスク等の不揮発性記憶媒体を用いることができる。
　また、縮退機能を備えたＰＣＩ　ｅｘｐｒｅｓｓの規格に準拠するＩ／Ｏデバイスとしてファイバチャネルアダプタ１２１、１２２を例示したが、ネットワークインターフェースやＣＮＡ（Ｃｏｎｖｅｒｇｅｄ　Ｎｅｔｗｏｒｋ　Ａｄａｐｔｅｒ）を採用してもよい。
　また、上記では、障害が発生したときに、サーバモジュールＢ１２０の処理をサーバモジュールＮ１４０で引き継ぐ例を示したが、メインテナンスのためにサーバモジュールＢ１２０の処理をサーバモジュールＮ１４０で引き継いでもよい。この場合、図５Ａのステップ５０１に代わって、ＳＶＰモジュール１５０は現用系から待機系の切替え指示を図示しないコンソールなどから受信する。そして、図５Ａのステップ５０２以降の処理を実施する。
　本実施例２では、復号時にハードウェアコンポーネントの整合性を判定するドライブ暗号化機能が適用されている環境で、ＰＣＩｅｘｐｒｅｓｓ（以下、ＰＣＩｅ）に準拠したＩ／Ｏデバイスの縮退機能によってプラットフォームが意図的にハードウェア構成を変更した場合に、ユーザ操作の介在なしに起動できる計算機システムの例について以下に説明する。
　図７は、障害が発生したＩ／Ｏデバイスを縮退する例を示す計算機システムのブロック図である。図７の計算機システムは、前記実施例１の図１に示した計算機システムと同様の構成であり、Ｉ／Ｏデバイスとしてのファイバチャネルアダプタ１２１に障害が発生し、ファイバチャネルアダプタ１２２が処理を引き継いだ状態が前記実施例１と異なる点である。システム構成と回復Ｋｅｙ保存時の処理は実施例１と同一であるため、重複する説明は省略する。
　図８Ａは、障害が発生したＩ／Ｏデバイスを縮退する処理の一例を示すフローチャートで、前半部を示す。図８Ｂ、図８Ｃは、同じく障害が発生したＩ／Ｏデバイスを縮退する処理の一例を示すフローチャートで、中盤部、後半部をそれぞれ示す。
　サーバモジュールＢ１２０でＰＣＩｅデバイスとしてのファイバチャネルアダプタ１２１に障害が発生した場合、ＢＭＣモジュール１２９が障害検出し（ステップ７０１）、強制電源ＯＦＦ（ステップ７０２）とＰＣＩｅの縮退を行う（ステップ７０３）。このとき、回復Ｋｅｙ管理テーブル１５３は図２Ｅの状態である。
　次に、ＢＭＣモジュール１２９はＳＶＰモジュール１５０に対して回復Ｋｅｙ格納位置の要求を行う（ステップ７０４）。
　ＳＶＰモジュール１５０は、前記要求をコールドスタンバイ切り替えの予備系サーバモジュール以外から受けた場合（ステップ７０５がＮＯ）、回復Ｋｅｙ管理テーブル１５３から回復Ｋｅｙ生成元計算機ＩＤ２０１が、要求を行ったサーバモジュールのＩＤと一致する行を選択する（ステップ７０７、図２Ｅ）。本実施例の場合、このとき選択される行は、要求の送信元のサーバモジュールＢ１２０に対応する図２Ｆの＃＝２の行である。なお、系切替え中の場合には、前記実施例１と同様にステップ７０６で、回復Ｋｅｙ管理テーブル１５３から回復Ｋｅｙ生成元計算機ＩＤ２０１が、現用系の計算機ＩＤと一致する行を選択する。
　図２Ｅは、説明のために行＝＃２が選択されたことを示すもので、図２Ｃと同じ状態の図である。
　ＳＶＰモジュール１５０は、回復Ｋｅｙ管理テーブル１５３より、選択中の行の回復Ｋｅｙの保存有無２０３が「保存済」であることを判定する。本実施例では回復Ｋｅｙ１５６が保存されているので（ステップ７０８がＹＥＳ）、選択中の行の現在の回復Ｋｅｙ接続先２０２に要求元のサーバモジュールのＩＤ＝Ｂを設定する（ステップ７０９、図２Ｆ）。
　図２Ｆは、回復Ｋｅｙ生成元計算機ＩＤ２０１が、サーバモジュールＢに対応する現在の回復Ｋｅｙ接続先が未接続な状態のときを示す図２Ｅに対して、サーバモジュールＢに接続した状態に変化したものである。
　そして、ＳＶＰモジュール１５０はＢＭＣモジュール１２９に対してマウントすべき回復Ｋｅｙの格納位置２０４の値（図２Ｆ、本実施例においては「／ｃｏｎｆ／ｐ２／ＲｅｃｏｖｅｒｙＫｅｙ．ｂｉｎ」）を通知する（ステップ７０９）。
　一方、ステップ７０８の判定で、選択中の行の現在の回復Ｋｅｙの保存有無２０３が「未保存」あるいは回復Ｋｅｙ格納位置２０４に値がない場合には、ステップ７１０へ進んで、回復Ｋｅｙ格納位置がないこと、または回復Ｋｅｙが未保存であることをＢＭＣモジュール１２９に通知する。
　図８Ｂにおいて、ＢＭＣモジュール１２９はＳＶＰモジュール１５０から回復Ｋｅｙの格納位置２０４が通知された場合（ステップ７１１がＹＥＳ）、ステップ７１０で通知された回復Ｋｅｙ格納位置２０４に保持された回復Ｋｅｙ１５６のイメージファイルをマウントし（ステップ７１２）、ＵＳＢメモリのエミュレーションを開始した後（ステップ７１３）、サーバモジュールＢ１２０の電源ＯＮの指示を行い（ステップ７１５）、サーバモジュールＢの電源がＯＮとなる。
　ＵＥＦＩ１６１はブートを開始すると（ステップ７１７）、ハードウェア構成情報とＵＥＦＩ設定とブートレコードの値を取得し（ステップ７１８）、これらの値を参照してＴＰＭ１２６のＰＣＲの値を更新する（ステップ７１９）。
　しかし、本実施例２ではステップ７０３でＰＣＩｅデバイスの縮退を行っているため、ハードウェア変更が行われた状態である。そのため、ＴＰＭ１２６上のＰＣＲと、過去に取得したスナップショットの比較結果は不一致となり、ＳＲＫのロックは解除されない（ステップ７２０がＮＯ）。
　この状態でＯＳ１９０はブートを開始するが（図８Ｃのステップ７２３）、ＴＰＭ１２６ではＳＲＫの取得に失敗するため（ステップ７２３がＮＯ）、ＵＳＢメモリ４０１に有効な回復Ｋｅｙが接続されているか否かを判定する（ステップ７２４）。
　本実施例２では、ステップ７１３のＵＳＢメモリエミュレーションによって、ＯＳ１９０からは現用系サーバモジュールで生成した回復Ｋｅｙの保存されたＵＳＢメモリ４０１が接続されたように認識されているため、ステップ７２４の判定結果はＹＥＳとなり、ＯＳ１９０は回復Ｋｅｙ１５６を使ってＶＭＫの復号と取得（ステップ７２５）を行う。そして、ＯＳ１９０は取得したＶＭＫを使って復号とＦＶＥＫの取得（ステップ７２６）を行い、ＯＳ１９０を復号してブートする（ステップ７２７Ａ、７２７Ｂ）。
　ＯＳ１９０のブートが完了すると、ＢＭＣモジュール１２９はＵＳＢメモリエミュレーションを終了し（ステップ７２８）、シャーシ内ストレージ１５４の回復Ｋｅｙ１５６のイメージファイルをアンマウントし（ステップ７２９）、ＳＶＰモジュール１５０に対して回復Ｋｅｙ１５６のイメージファイルのアンマウント通知を行う（ステップ７３０）。
　ＳＶＰモジュール１５０はステップ７３０の通知を受けて、回復Ｋｅｙ管理テーブル１５３の現在の回復Ｋｅｙ接続先２０２を「未接続」に変更する（ステップ７３１）。
　図２Ｅは、回復Ｋｅｙ生成元計算機ＩＤ２０１がサーバモジュールＢに対応する現在の回復Ｋｅｙ接続先２０２がサーバモジュールＢの状態のときを示す図２Ｆに対して、未接続の状態に変化したものである。
　参考までに従来のシステムは、ステップ７２４がＮＯとなる。そのため、ユーザはＯＳ１９０の画面による指示に従い、回復Ｋｅｙの保存されたＵＳＢメモリを手動でサーバモジュールに接続して再起動を行う必要がある（ステップ７５０）。
　上記した実施例により、復号時にハードウェアコンポーネントの整合性を判定するドライブ暗号化機能を適用している環境で、ＰＣＩｅ縮退によってプラットフォームが意図的にハードウェア構成を変更した場合であっても、シャーシ内ストレージに格納したＰＣＩｅ縮退を行う前に保存した回復Ｋｅｙのイメージファイルを使ってＢＭＣモジュール１２９がＵＳＢメモリエミュレーションを行うことで、ＯＳ１９０からはＰＣＩｅ縮退を行う前に保存した回復Ｋｅｙの保存されたＵＳＢメモリが接続されたように認識されているため、ユーザ操作の介在なしにＯＳ１９０の起動が出来る計算機システムを提供する。
　なお、本発明は上記した各実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の不揮発性の非一時的な記憶媒体に格納することができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
　以上では、ハードウェアコンポーネントの整合性が保たれていない場合には、ＯＳ１９０の復号を阻止する機能として、ＢｉｔＬｏｃｋｅｒ（登録商標）を採用する例を示したが、これに限定されるものではない。
　例えば、ハードウェアコンポーネントの整合性が保たれていない場合には、暗号化されたＯＳ１９０のボリュームまたはＯＳイメージを復号する鍵を無効化したり、あるいは、ＯＳ１９０を読み込むための鍵をロックするなどのセキュリティを備えた計算機システムであればよい。
　特に、ハードウェアの固有値から生成した鍵でＯＳ１９０の暗号化またはロックを行い、鍵を生成したときのハードウェアの固有値の複製を保持し、また、ハードウェアの整合性が保たれていない場合に前記鍵を有効化するための回復Ｋｅｙを生成して保持しておく。そして、計算機の起動時にハードウェアの固有値を演算し、この固有値が、鍵を生成したときのハードウェアの固有値の複製と一致すればハードウェアの整合性が確保されたと判定し、前記鍵でＯＳ１９０の復号化またはロックの解除を行う。一方、起動時に演算したハードウェアの固有値が、鍵を生成したときのハードウェアの固有値の複製と一致しない場合には、保持しておいた回復Ｋｅｙを用いることで、ＯＳ１９０の復号またはロックの解除を行う。このとき、回復Ｋｅｙをサーバモジュール（計算機）の外部のＳＶＰモジュール１５０に格納しておき、回復Ｋｅｙを用いるときにはサーバモジュールを管理するＢＭＣモジュール１２９がデバイスのエミュレーションを実施することで、起動するＯＳ１９０に回復Ｋｅｙを提供すればよい。
　そして、ＳＶＰモジュール１５０で複数のサーバモジュールの回復Ｋｅｙを管理する際には、回復Ｋｅｙを生成したサーバモジュールの識別子に対応付けて回復Ｋｅｙを管理する回復Ｋｅｙ管理テーブル１５３を用いる。そして、各回復Ｋｅｙを使用する際には、各サーバモジュール毎に設けられたＢＭＣモジュール１２９で回復Ｋｅｙをマウントし、所定のデバイスのエミュレーションを実施することで、起動中のＯＳ１９０に回復Ｋｅｙを提供することができるのである。
　さらに、回復Ｋｅｙ管理テーブル１５３は、ひとつの回復Ｋｅｙを排他制御することで、使用中の回復Ｋｅｙを他のサーバモジュールの起動に使用することを禁止して、同一のＯＳ１９０が複数のサーバモジュールで起動するのを防ぐことができる。
　また、上記実施例では、ＢＭＣモジュール１２９でデバイスのエミュレーションを行う例を示したが、サーバモジュール毎にデバイスのエミュレーションを行う管理モジュールであれば良い。
　また、上記実施例では、複数のサーバモジュールに接続されたＳＶＰモジュール１５０に複数の回復Ｋｅｙを格納する例を示したが、これに限定されるものではなく、回復Ｋｅｙ管理テーブル１５３と複数の回復Ｋｅｙを記憶部に格納し、要求された回復Ｋｅｙを選択してＢＭＣモジュール１２９へ通知可能な計管理算機であればよい。

Claims (10)

  1. 　プロセッサとメモリとＯＳを格納する記憶部とを備えた計算機と、
    　１以上の前記計算機を管理する管理計算機と、を備えた計算機システムであって、
    　前記計算機は、前記記憶部を暗号化するために前記ＯＳが生成した鍵と、前記鍵を生成したときのハードウェアに関連する情報から演算した固有値と、を固有値保持部に保持し、
    　前記計算機は、前記ＯＳの起動時に演算するハードウェアに関連する情報に基づく固有値が、前記保持された固有値と一致しない場合に、前記鍵に代わって前記記憶部を復号するための回復鍵を生成し、当該鍵を前記管理計算機に通知し、前記鍵を用いて前記ＯＳを格納する記憶部を暗号化し、
    　前記管理計算機が、前記回復鍵を受け付けて、前記回復鍵を生成した計算機の識別子と対応付けて前記回復鍵を保持し、
    　前記管理計算機が、前記計算機を停止させた後、前記停止させた計算機を引き継ぐ第２の計算機を選択し、前記停止させた計算機で生成した回復鍵を、前記選択した第２の計算機に通知してから前記第２の計算機を起動し、
    　前記第２の計算機が、ハードウェアに関連する情報から固有値を演算し、前記固有値保持部に予め保持された固有値に一致するか否かを判定し、前記演算した固有値と、予め保持された前記固有値が一致しないときには、前記管理計算機から通知された回復鍵を用いて、前記記憶部のＯＳを復号して、当該ＯＳを起動することを特徴とする計算機システム。
  2. 　請求項１に記載の計算機システムであって、
    　前記第２の計算機は、
    　当該第２の計算機の電源を制御する管理モジュールを有し、
    　前記管理モジュールは、
    　前記管理計算機が通知した回復鍵を受け付けて、当該回復鍵を格納したデバイスとして前記第２の計算機に認識させるエミュレーション部を有することを特徴とする計算機システム。
  3. 　請求項１に記載の計算機システムであって、
    　前記管理計算機は、
    　前記計算機に障害が発生したことを検知したときには前記計算機を停止させた後、前記停止させた計算機を引き継ぐ第２の計算機を選択し、前記停止させた計算機で生成した回復鍵を、前記選択した第２の計算機に通知してから前記第２の計算機を起動することを特徴とする計算機システム。
  4. 　請求項２に記載の計算機システムであって、
    　前記管理モジュールは、
    　前記計算機のデバイスが縮退したことを検知したときには前記計算機を停止させ、前記管理計算機に前記回復鍵を要求し、
    　前記管理計算機は、
    　前記停止させた計算機を引き継ぐ第２の計算機として、前記デバイスを縮退した当該計算機を選択することを特徴とする計算機システム。
  5. 　請求項２に記載の計算機システムであって、
    　前記エミュレーション部は、ＵＳＢメモリのエミュレーションを実行し、
    　前記第２の計算機は、前記ＵＳＢメモリに格納された回復鍵を認識し、当該回復鍵を取得することを特徴とする計算機システム。
  6. 　プロセッサとメモリとＯＳを格納する記憶部とを備えた計算機で、前記記憶部を暗号化する暗号化方法であって、
    　前記計算機が、前記ＯＳで前記記憶部を暗号化するための鍵を生成する第１のステップと、
    　前記計算機が、前記鍵を生成したときのハードウェアに関連する情報から固有値を演算し、当該固有値を保持する第２のステップと、
    　前記計算機が、前記ＯＳの起動時に演算するハードウェアに関連する情報に基づく固有値が、前記保持された固有値と一致しない場合に、前記鍵に代わって前記記憶部を復号するための回復鍵を生成する第３のステップと、
    　前記計算機に接続された管理計算機が、前記回復鍵を受け付けて、前記回復鍵を生成した計算機の識別子と対応付けて前記回復鍵を保持する第４のステップと、
    　前記計算機が、前記鍵を用いて前記ＯＳを格納する記憶部を暗号化する第５のステップと、
    　前記計算機を停止させる第６のステップと、
    　前記管理計算機が、前記停止させた計算機を引き継ぐ第２の計算機を選択する第７のステップと、
    　前記管理計算機が、前記停止させた計算機で生成した回復鍵を、前記第２の計算機に通知する第８のステップと、
    　前記管理計算機が、前記第２の計算機を起動させる第９のステップと、
    　前記第２の計算機が、ハードウェアに関連する情報から固有値を演算し、予め保持された固有値に一致するか否かを判定する第１０のステップと、
    　前記第２の計算機が、前記演算した固有値と、予め保持された前記固有値が一致しないと判定したときには、前記管理計算機から通知された回復鍵を用いて、前記記憶部のＯＳを復号して、当該ＯＳを起動する第１１のステップと、
    を含むことを特徴とする記憶部の暗号化方法。
  7. 　請求項６に記載の記憶部の暗号化方法であって、
    　前記第２の計算機は、
    　当該第２の計算機の電源を制御する管理モジュールを有し、
    　前記第１１のステップは、
    　前記管理モジュールが、管理計算機から通知された前記回復鍵を受け付けて、当該回復鍵を格納したデバイスとして前記第２の計算機に認識させるエミュレーションを実行することを特徴とする記憶部の暗号化方法。
  8. 　請求項６に記載の記憶部の暗号化方法であって、
    　前記第７のステップは、
    　前記管理計算機が、前記計算機で障害の発生を検知したときには前記計算機を停止させた後、前記停止させた計算機を引き継ぐ第２の計算機を選択することを特徴とする記憶部の暗号化方法。
  9. 　請求項７に記載の記憶部の暗号化方法であって、
    　前記第７のステップは、
    　前記管理モジュールが、前記計算機のデバイスが縮退したことを検知したときには前記計算機を停止させ、前記管理計算機に前記回復鍵を要求し、
    　前記管理計算機は、
    　前記停止させた計算機を引き継ぐ第２の計算機として、前記デバイスを縮退した当該計算機を選択することを特徴とする記憶部の暗号化方法。
  10. 　請求項７に記載の記憶部の暗号化方法であって、
    　前記第１１のステップは、
    　ＵＳＢメモリのエミュレーションを実行し、前記第２の計算機は、前記ＵＳＢメモリに格納された回復鍵を認識し、当該回復鍵を取得することを特徴とする記憶部の暗号化方法。
PCT/JP2012/081915 2012-12-10 2012-12-10 計算機システム及び記憶部の暗号化方法 WO2014091535A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/081915 WO2014091535A1 (ja) 2012-12-10 2012-12-10 計算機システム及び記憶部の暗号化方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/081915 WO2014091535A1 (ja) 2012-12-10 2012-12-10 計算機システム及び記憶部の暗号化方法

Publications (1)

Publication Number Publication Date
WO2014091535A1 true WO2014091535A1 (ja) 2014-06-19

Family

ID=50933864

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/081915 WO2014091535A1 (ja) 2012-12-10 2012-12-10 計算機システム及び記憶部の暗号化方法

Country Status (1)

Country Link
WO (1) WO2014091535A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6261065B1 (ja) * 2017-06-12 2018-01-17 Quadrac株式会社 中継装置及びシステム
JP2019003600A (ja) * 2017-11-17 2019-01-10 Quadrac株式会社 中継装置及びシステム
JP2021510871A (ja) * 2018-01-12 2021-04-30 ギャリソン テクノロジー リミテッドＧａｒｒｉｓｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｌｔｄ ストレージリソースの安全な共用
US11151255B2 (en) * 2018-10-26 2021-10-19 Dell Products L.P. Method to securely allow a customer to install and boot their own firmware, without compromising secure boot

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090169020A1 (en) * 2007-12-28 2009-07-02 Palsamy Sakthikumar Migration of full-disk encrypted virtualized storage between blade servers
US20090210456A1 (en) * 2008-02-18 2009-08-20 Dell Products L.P. Methods, Systems and Media for TPM Recovery Key Backup and Restoration
JP2010067042A (ja) * 2008-09-11 2010-03-25 Hitachi Ltd 計算機切り替え方法、計算機切り替えプログラム及び計算機システム
JP2011034161A (ja) * 2009-07-30 2011-02-17 Nec Corp サーバシステム及びサーバシステムの管理方法
JP2011517205A (ja) * 2008-04-02 2011-05-26 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． ディスクドライブデータの暗号化

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090169020A1 (en) * 2007-12-28 2009-07-02 Palsamy Sakthikumar Migration of full-disk encrypted virtualized storage between blade servers
US20090210456A1 (en) * 2008-02-18 2009-08-20 Dell Products L.P. Methods, Systems and Media for TPM Recovery Key Backup and Restoration
JP2011517205A (ja) * 2008-04-02 2011-05-26 ヒューレット−パッカード デベロップメント カンパニー エル．ピー． ディスクドライブデータの暗号化
JP2010067042A (ja) * 2008-09-11 2010-03-25 Hitachi Ltd 計算機切り替え方法、計算機切り替えプログラム及び計算機システム
JP2011034161A (ja) * 2009-07-30 2011-02-17 Nec Corp サーバシステム及びサーバシステムの管理方法

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6261065B1 (ja) * 2017-06-12 2018-01-17 Quadrac株式会社 中継装置及びシステム
WO2018229818A1 (ja) * 2017-06-12 2018-12-20 Quadrac株式会社 中継装置及びシステム
JP2019003600A (ja) * 2017-11-17 2019-01-10 Quadrac株式会社 中継装置及びシステム
JP2021510871A (ja) * 2018-01-12 2021-04-30 ギャリソン テクノロジー リミテッドＧａｒｒｉｓｏｎ Ｔｅｃｈｎｏｌｏｇｙ Ｌｔｄ ストレージリソースの安全な共用
JP7244527B2 (ja) 2018-01-12 2023-03-22 ギャリソン テクノロジー リミテッド ストレージリソースの安全な共用
US11151255B2 (en) * 2018-10-26 2021-10-19 Dell Products L.P. Method to securely allow a customer to install and boot their own firmware, without compromising secure boot

Similar Documents

Publication Publication Date Title
CN111052118B (zh) 硬件实施的固件安全
AU2010340222B2 (en) Protected device management
US9594698B2 (en) Local keying for self-encrypting drives (SED)
US8127128B2 (en) Synchronization of swappable module in modular system
US10032029B2 (en) Verifying integrity of backup file in a multiple operating system environment
US20160087986A1 (en) Storage device security system
US20090210456A1 (en) Methods, Systems and Media for TPM Recovery Key Backup and Restoration
US8082434B2 (en) System and method for providing a secure computing environment
KR20100087336A (ko) 판독전용 영역과 판독/기록 영역, 분리형 매체 구성부품, 시스템 관리 인터페이스, 네트워크 인터페이스를 가진 컴퓨터 기억장치
JP5689429B2 (ja) 認証装置、および、認証方法
US20130103934A1 (en) Computer system and method for taking over module therein
US10482278B2 (en) Remote provisioning and authenticated writes to secure storage devices
US20080215767A1 (en) Storage usage exclusive method
AU2005248713A1 (en) Isolated multiplexed multi-dimensional processing in a virtual processing space having virus, spyware, and hacker protection features
WO2014091535A1 (ja) 計算機システム及び記憶部の暗号化方法
US20230140209A1 (en) System and method for secure access to a distributed virtual firmware network drive
US20220398320A1 (en) Data sharing system and method for a multi-boot baseboard management controller (bmc)
US11354259B1 (en) Computer system configurations based on accessing data elements presented by baseboard management controllers
CN112912848B (zh) 一种丛集作业过程中的电源请求管理方法
US11863691B2 (en) Lockable device validation for information handling systems
US20230009355A1 (en) Method and Apparatus for Securely Backing Up and Restoring a Computer System
US20220413981A1 (en) Storage system
KR20060135757A (ko) 바이러스, 스파이웨어, 및 해커 보호 특성을 갖는 가상처리 공간에서의 분리된 멀티플렉싱 다차원 처리
RU2571724C2 (ru) Система и способ полнодискового шифрования с проверкой совместимости загрузочного диска
OR et al. Copyright 2009 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, USA and FUJITSU LIMITED, 1-1, Kamikodanaka 4-chome, Nakahara-ku, Kawasaki-shi, Kanagawa-ken 211-8588, Japan. All rights reserved. Sun Microsystems, Inc. and Fujitsu Limited each own or control intellectual property rights relating to products and technology described in this document, and such products, technology and this document are protected by copyright laws, patents and other intellectual property laws and international treaties. The intellectual property rights of Sun Microsystems, Inc. and Fujitsu Limited in such products, technology and this

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: 12890124

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: 12890124

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP