System for testing tamper verification during startup of software executed in storage controller

The system enhances storage system reliability by allowing users to test and verify the integrity of software during startup through a management system that detects tampering and presents results.

JP2025154584APending Publication Date: 2025-10-10HITACHI LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
JP2024057671
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-03-29
Publication Date
2025-10-10

AI Technical Summary

Technical Problem

Users cannot verify whether the authenticity verification function in storage systems is functioning properly during startup, which undermines trust in the system's integrity.

Method used

A system for testing tampering verification during startup of software executed in a storage controller, comprising a management system and a storage controller, where the management system stores verification software that detects tampering and presents the results to the user.

Benefits of technology

Improves the reliability of the storage system by enabling users to confirm the proper functioning of the secure boot function.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025154584000001_ABST
    Figure 2025154584000001_ABST
Patent Text Reader

Abstract

To increase the reliability of a storage system.SOLUTION: A system obtains verification software that runs on a storage controller. The verification software includes a program that detects tampering within the verification software. The system tampers with part of the verification software in response to instructions from a user. The system installs the partially tampered verification software in the storage controller and starts the verification software. The system presents to the user the results of the tampering verification performed by the verification software received from the storage controller.SELECTED DRAWING: Figure 12
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to testing verification functions of software executed by a storage system. [Background technology]

[0002] Data storage is a basic function of computer systems. In many computer systems, when large amounts of data are handled, they are stored in storage devices. Storage systems store data in built-in storage media (storage drives) such as HDDs (Hard Disk Drives) and SSDs (Solid State Drives), and write and read data in response to external commands.

[0003] Storage system software can be tampered with along the supply chain from the time it leaves the factory until it is delivered to the customer. There is a function called secure boot that verifies that the updated software has not been tampered with when the software is updated, for example, when the system is started up after the software update. The secure boot function verifies the software to be started up using a digital signature when the storage system is started up.

[0004] Background art of the present application is Patent Document 1. Patent Document 1 discloses that "an electronic control unit 10 includes a ROM having a rewritable area and a non-rewritable area for storing a control program, a control unit 60, and a test execution unit 90. The control unit executes the control program using acquired input data and calculates a control value. The non-rewritable area stores test data corresponding to the input data and expected test results. When the control program is rewritten, the test execution unit executes the control program using the test data and compares the test results, which are calculations using the test data, with the expected test results, to determine whether the rewritten control program is normal. The test execution unit allows the start of a rewritten control program that is determined to be normal, and restricts the start of a rewritten control program that is determined to be abnormal." [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2023-88706 [Patent Document 2] U.S. Patent Application Publication No. 2022 / 0413981 Summary of the Invention [Problem to be solved by the invention]

[0006] Secure boot (authenticity verification) can guarantee the authenticity and integrity of the software in a storage system. However, users (including system administrators) cannot tell whether authenticity verification is working properly when the system boots, which can undermine users' trust in the storage system. [Means for solving the problem]

[0007] One aspect of the present disclosure is a system for testing tampering verification during startup of software executed in a storage controller, the system including a management system and a storage controller, wherein the management system stores verification software executed by the storage controller, the verification software includes a program for detecting tampering within the verification software, and the management system tampers with a portion of the verification software in response to an instruction from a user, and detects the tampered portion of the verification software. is installed in the storage controller, the storage controller starts the verification software, and the management system presents the results of the verification of tampering by the verification software received from the storage controller to the user. [Effects of the Invention]

[0008] According to one aspect of the present disclosure, the reliability of a storage system can be improved. [Brief explanation of the drawings]

[0009] [Figure 1] 1 shows an example of the hardware configuration of a storage system and its related devices. [Figure 2] 10 shows an example of the configuration of software stored in the management controller. [Figure 3] 1 shows an example of the configuration of software stored in a disk controller. [Figure 4] 10 is a block diagram for explaining an overview of the processing executed by the management controller and disk controller programs when the storage controller is started up. FIG. [Figure 5] 1 shows an example of the configuration of a management device. [Figure 6] This section describes the preparations for testing the secure boot function. [Figure 7] An example of an administrator authentication screen for tampering with the verification software is shown below. [Figure 8] An example of a verification software selection screen is shown. [Figure 9] 10 shows examples of the tampering input screen and tampering result screen of the verification software. [Figure 10] 10 shows examples of the tampering input screen and tampering result screen of the verification software. [Figure 11] FIG. 10 is a diagram illustrating a method for installing tampered verification software into a storage controller. [Figure 12] 10 shows a flowchart of a startup process by a storage controller. [Figure 13] An example of a tampering detection message is shown below. [Figure 14] An example of a verification status screen is shown. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments will be described with reference to the drawings. For convenience, when necessary, the description will be divided into multiple sections or embodiments. However, unless otherwise specified, these are not unrelated to one another, and one is related to the other as a partial or complete modification, detail, supplementary explanation, etc. Furthermore, hereinafter, when the number of elements (including the number, numerical value, amount, range, etc.) is mentioned, it is not limited to the specific number, and may be more or less than the specific number, unless otherwise specified or when it is clearly limited to a specific number in principle.

[0011] A processor or arithmetic device realizes a predetermined function by executing a program stored in a main memory device. The main memory device stores the program executed by the arithmetic device and data necessary for the execution of the program. The program includes an operating system (OS) (not shown) as well as other programs. The arithmetic device may include multiple chips and multiple packages.

[0012] A program is executed by a computing device to perform a predetermined process using a storage device and a communication port (communication device). Therefore, in this embodiment, a description using the program as the subject may also be a description using the computing device as the subject. Alternatively, the process executed by a program is a process performed by the computer and computer system on which the program runs.

[0013] The computing device operates as a functional unit (means) that realizes a predetermined function by operating according to a program. Furthermore, the computing device also operates as a functional unit (means) that realizes each of the multiple processes executed by each program. A computer and a computer system are devices and systems that include these functional units (means).

[0014] In one embodiment of the present specification, a user may This provides a tool for tampering with part of the software, thereby enabling users to test the secure boot function of the software. By enabling users to confirm that the secure boot function of the software is functioning properly, users can increase their trust in the storage system.

[0015] An example of the hardware configuration of a storage system 100 and its related devices according to an embodiment of this specification will be described using Figure 1. One or more hosts (not shown) are connected to the storage system 100 via a network (not shown). In order to manage host data, each host makes various requests to the storage system 100 via the network, such as read requests or write requests (I / O requests). The network can use protocols such as FC (Fibre Channel) or Ethernet, for example.

[0016] The management device 102 is connected to the storage system 100 via a network 101. A system administrator manages the storage system 100 by operating the management device 102. The network 101 may be, for example, a local area network (LAN). When software tampering is detected in the storage system 100, information about this is sent to the management device 102. The management device 102 presents this information to the administrator on a display device not shown in FIG. 1.

[0017] The storage system 100 is equipped with two storage controllers (STGC) 110A and 110B having the same functions to increase the reliability of the system. The storage system 100 may be equipped with one or more storage drives (not shown) as storage media for holding data from the host (called host data). The storage drives may be, for example, HDDs (Hard Disk Drives) or SSDs (Solid State Drives).

[0018] The following describes an example of two storage controllers 110A and 110B in the storage system 100, but the number of storage controllers is not particularly limited. The storage system can include only one storage controller or three or more storage controllers, and the storage controllers may be installed in multiple nodes that communicate via a network.

[0019] The storage controller 110A includes a management controller (MGC) 120A and a disk controller (DKC) 130A. These are different hardware devices. The disk controller is also called an input / output controller. The storage controller 110A further includes a management port 151A, a host port 153A, and an internal communication interface 155A.

[0020] The management port 151A is an interface through which the storage controller 110A communicates with the management device 102, and the host port 153A is an interface through which the storage controller 110A sends and receives host data to and from the host. The internal communication interface 155A is an interface through which the storage controller 110A communicates with another storage controller 110B. The internal communication interface 155A stores environmental information and environmental settings within the system, and enables communication between devices.

[0021] The management controller 120A follows instructions from an administrator to manage the storage system 100. For example, the management controller 120A executes the configuration of the storage system 100, including the creation and configuration of volumes.

[0022] The management controller 120A includes a CPU (Central Processing Unit) 121A, which is a computing device that executes management processing, a flash memory 123A, and an SSD 125A. There is no limit to the number of each. The management controller 120A also includes a DRAM 126A, which is used as a primary storage device. DRAM is a memory that includes a volatile storage medium.

[0023] The CPU 121A executes a program stored in the DRAM 126A to realize a predetermined management function. The processing executed by the CPU 121A is the processing executed by the management controller 120A. The CPU 121A communicates with the management device 102 via the management port 151A.

[0024] The CPU 121A verifies and starts the software that it stores and executes, as well as verifies and starts a portion of the software stored in the disk controller 130A. Verification determines whether the software has been tampered with. For example, known techniques using digital signatures can be used to verify the authenticity of the software.

[0025] For example, a digital signature is generated from the hash value and private key of software (binary image) that executes processing in the storage system. A media image including the digital signature and the software is installed in the storage system 100. The CPU 121A generates a verification digital signature from the hash value and public key of the installed software. The authenticity of the software (binary image) can be verified by comparing the pre-stored digital signature with the verification digital certificate.

[0026] Verification of the authenticity of the software can improve the reliability of the storage system 100. Note that the verification performed by the disk controller 130A may also be performed by the management controller 120, and at least part of the verification of the software of the disk controller 130A is performed by the management controller 120A.

[0027] The flash memory 123A and the SSD 125A are storage devices with different interface protocols. For example, the flash memory 123A may use SPI (Serial Peripheral Interface), and the SSD 125 may use NVMe (Non-Volatile Memory Express). Note that all software may be stored in a single type of storage device.

[0028] When starting up the management controller 120A, the CPU 121A first accesses the flash memory 123A and starts up the stored software (program). Thereafter, the CPU 121A accesses the SSD 125A and starts up the software of the SSD 125A. The CPU 121A verifies the software of the SSD 125A and determines whether it has been tampered with. The CPU 121A also verifies the software of the disk controller 130A. This improves the security reliability of the storage system 100.

[0029] The disk controller 130A processes the input and output of host data. The disk controller 130A stores host data received from the host in a storage drive in response to a write request from the host, and reads specified data from the storage drive in response to a read request from the host and transfers it to the host. Host data is logically stored in a volume. A volume is associated with a storage area of ​​a storage drive.

[0030] The disk controller 130A includes a CPU 131A, which is an arithmetic unit that executes input / output processing of host data, a flash memory 133A, and an SSD 135A. These are different hardware devices. The disk controller 130A further includes a main memory device The DRAM 136A is used as a memory device.

[0031] The CPU 131A executes programs stored in the primary storage device to realize predetermined management functions. The processing executed by the CPU 131A is the processing executed by the disk controller 130A. The CPU 131A communicates with the host via the host port 153A.

[0032] The CPU 131A verifies and starts the software that it itself stores and executes. Verification determines whether the software has been tampered with. The verification method is as described above. This makes it possible to improve the reliability of the storage system 100.

[0033] The flash memory 133A and the SSD 135A are storage devices with different interface protocols. For example, the flash memory 133A may use SPI, and the SSD 135A may use NVMe. Note that all software may be stored in one type of storage device.

[0034] The disk controller 130A starts up in response to a notification from the management controller 120A. Before the disk controller 130A starts up, part of the software of the disk controller 130A is verified by the management controller 120A. If no tampering is detected, the disk controller 130A starts up.

[0035] In one embodiment of the present specification, the management controller 120A verifies the software stored in the flash memory 133A. The management controller 120A can access the flash memory 123A via the internal communication interface 155A without going through the CPU 131A.

[0036] After verification by management controller 120A, disk controller 130A accesses flash memory 133A, launches the verified software, and then verifies the remaining portion of the software to determine whether it has been tampered with. In one embodiment of this specification, the remaining portion is software stored on SSD 135A.

[0037] In one embodiment of this specification, the storage controller 110B has a similar configuration to the storage controller 110A and includes the same types of components. Specifically, the storage controller 110B includes a management controller 120B and a disk controller 130B. The storage controller 110B further includes a management port 151B, a host port 153B, and an internal communication interface 155B. Communication between the storage controllers 110A and 110B is performed via the internal communication interfaces 155A and 155B.

[0038] Like the management controller 120A, the management controller 120B includes a CPU 121B, a flash memory 123B, and an SSD 125B. The management controller 120A further includes a DRAM 126B, which is used as a primary storage device. Like the disk controller 130A, the disk controller 130B includes a CPU 131B, a flash memory 133B, and an SSD 135B. The disk controller 130B further includes a DRAM 136B, which is used as a primary storage device.

[0039] The management controller 120B and the disk controller 130B respectively perform the operations of the management controller 120A and the disk controller 130A. Note that the management controllers 120A and 120B may have different configurations, and the disk controllers 130A and 130B may have different configurations.

[0040] 2 shows an example of the configuration of software (programs) stored in the management controller 120A. The management controller 120B of the storage controller 110B stores the same software as the management controller 120A. The flash memory 123A of the management controller 120A stores first MGC firmware 210. The first MGC firmware 210 includes an MGC startup program 211 and a first MGC verification program 212.

[0041] The SSD 125A of the management controller 120A stores second MGC firmware 220, and an OS (Operating System) and management software 230. The management software runs on the OS. The second MGC firmware 220 includes a second MGC startup program 221 and a second MGC verification program 222. The OS and management software 230 includes a first DKC verification program 231 and a DKC startup instruction program 232.

[0042] 3 shows an example of the configuration of software (programs) stored in the disk controller 130 A. The disk controller 130 B of the storage controller 110 B stores the same software as the disk controller 130 A.

[0043] The flash memory 133A of the disk controller 130A stores first DKC firmware 250. The first DKC firmware 250 includes a DKC initial phase startup program 251 and a second DKC verification program 252. The SSD 135A of the disk controller 130A stores second DKC firmware 260. The second DKC firmware 260 includes a DKC later phase startup program 261.

[0044] 4 is a block diagram for explaining an overview of the processing that the programs of the management controller 120A and disk controller 130A execute when starting up the storage controller 110A. Note that the management controller 120B and disk controller 130B also execute similar processing.

[0045] When the startup of the storage controller 110A begins, the CPU 121A of the management controller 120A starts the first MGC startup program 211 of the first MGC firmware 210 stored in the flash memory 123A. The first MGC startup program 211 starts other programs of the first MGC firmware 210, including the first MGC verification program 212.

[0046] The first MGC verification program 212 executes verification of the second MGC firmware 220 stored in the SSD 125A. When the verification of the second MGC firmware 220 is completed and it is determined that there is no tampering, the first MGC startup program 211 starts the second MGC startup program 221 of the second MGC firmware 220 stored in the SSD 125A. The second MGC startup program 221 starts other programs in the second MGC firmware 220, including the second MGC verification program 222.

[0047] The second MGC verification program 222 executes verification of the OS and management software 230 stored in the SSD 125A. When the verification of the OS and management software 230 is completed and it is determined that there is no tampering, the second MGC startup program 221 starts up the programs of the OS and management software 230.

[0048] The OS and management software 230 includes a first DKC verification program 231 and a DKC startup instruction program 232. The first DKC verification program 231 is The flash memory 133A of the controller 130A is accessed via the internal communication interfaces 155A and 155B, and the verification of the first DKC firmware 250 is executed.

[0049] When verification of the first DKC firmware 250 is completed and it is determined to be normal, the DKC startup instruction program 232 instructs the CPU 131A of the disk controller 130A to start up. The CPU 131A executes the DKC initial phase startup program 251 included in the first DKC firmware 250 in the flash memory 133A.

[0050] The DKC initial phase startup program 251 starts the second DKC verification program 252 included in the verified DKC firmware 250. The second DKC verification program 252 accesses the SSD 135A of the disk controller 130A and executes verification of the second DKC firmware 260 stored therein. The DKC initial phase startup program 251 executes startup of other programs of the first DKC firmware 250 in parallel with the verification of the second DKC firmware 260.

[0051] When verification of the second DKC firmware 260 is completed and it is determined to be normal, a DKC later phase startup program 261 in the second DKC firmware 260 is executed. The DKC later phase startup program 261 starts other programs in the DKC firmware 260. The DKC firmware 260 is the main firmware that defines the input and output of host data by the disk controller 130A.

[0052] 5 shows an example configuration of the management device 102. The management device 102 may have, for example, a computer configuration. The management device 102 includes a CPU (computing unit) 301 that executes various programs, a memory (main storage device) 302 that stores the various programs, and an auxiliary storage device 303 that stores various data. The CPU 301 may include one or more cores, and the memory 302 may be, for example, a DRAM that includes a volatile storage area. The auxiliary storage device 303 may be, for example, an HDD (hard disk drive) or flash memory, and may provide a non-volatile storage area.

[0053] The management device 102 further includes an output device 304 for presenting information to the user of the device, an input device 305 for inputting instructions, images, etc. from the user, and a communication device 306 for communicating with other devices. These are interconnected by a bus 307.

[0054] The output device 304 is composed of devices such as a display, a printer, and a speaker. The input device 305 is composed of devices such as a keyboard, a mouse, and a microphone. The output device 304 presents the results of input from the user and also presents the results of processing by the management device 102. Instructions from the user are input to the management device 102 by the input device 305.

[0055] The communication device 306 receives data transmitted from other devices connected via a network, including user terminals, and transmits processing results by the management device 102 to other devices. The CPU 301 executes programs stored in the memory 302 to realize predetermined functions, and these programs are loaded into the memory 302 from, for example, the auxiliary storage device 303. There are no particular limitations on the configuration of the management device 102; some devices may be omitted, and at least some functions may be implemented by logic circuits.

[0056] The auxiliary storage device 303 stores the verification software 21. The verification software 21 is software for testing secure boot, and basically performs only secure boot. In the verification software 21, some functions of the normal software installed in the storage system 100 are omitted. This makes it possible to prevent the system 100 from performing erroneous operations on host data during a tampering test. In the verification software 21, functions such as volume configuration changes, host settings, and host IO processing are omitted.

[0057] The memory 302 stores software executed by the CPU 301, including an OS and application programs. Fig. 5 shows an example of a software tampering test tool 10 for the storage system 100. The tampering test tool 10 includes multiple programs for testing the secure boot of the storage system 100. Specifically, the tampering test tool 10 includes multiple programs, including a tampering unit 11, an input / output unit 12, and an authentication unit 13.

[0058] The tampering unit 11 tampers with the verification software 21 in accordance with instructions from an administrator. The input / output unit 12 accepts information input for testing the secure boot function of the storage system 100 and provides the administrator with a GUI for presenting the test results. The authentication unit 13 authenticates logins by the administrator.

[0059] In one embodiment of the present specification, users, including administrators of the storage system 100, can test the secure boot implemented in the storage system 100. This can increase the reliability of the storage system 100 for users.

[0060] Fig. 6 shows the preparations for testing the secure boot function. As shown in Fig. 6, the administrator uses the tampering test tool 10 of the management device 102 to tamper with the verification software 21 (S1), and copies (installs) the tampered verification software into the storage system 100 (S2).

[0061] The administrator can manually tamper with the verification software 21 stored in the management device 102 using the input device 305 and the output device 304. The administrator may also access the management device 102 from his / her user terminal and use the tampering test tool 10.

[0062] The management device 102 and the combination of the management device 102 and the user terminal each constitute a management system. The processing performed by the management device 102 may be distributed among multiple devices. In this way, the management system that tests the secure boot function of software together with the storage controller includes one or more computing devices and one or more storage devices.

[0063] 7 shows an example of an administrator authentication screen 41 for tampering with verification software. The input / output unit 12 of the tampering test tool 10 displays the authentication screen shown in FIG. 7 on the output device 304, and prompts the administrator to input a user name and password using the input device 305. The authentication unit 13 sends an authentication request together with the input user name and password to the storage system 100. Normal software is running in the storage system 100, and for example, the OS and management software 230 can perform user authentication.

[0064] This allows only trusted users who are registered in the storage system to be permitted to use the tamper test tool. Reference information for user authentication may be stored in the management device 102. The authentication unit 13 can execute user authentication by referring to authentication information that associates a user name with a password, which is stored in the auxiliary storage device 303.

[0065] When the authentication unit 13 receives a successful result of the user authentication from the storage system 100, The tampering unit 11 is notified of this. The tampering unit 11 uses the input / output unit 12 to display a selection screen for the verification software to be tampered with. FIG. 8 shows an example of the verification software selection screen 42. On the verification software selection screen 42, the administrator can select one verification software to perform a tampering test from multiple verification software. For example, multiple different versions of verification software 21 are stored in the auxiliary storage device 303 of the management device 102. The verification software 21 may be downloadable from a server in the management system via a network.

[0066] When the verification software to be tampered with is selected, the tampering unit 11 uses the input / output unit 12 to display a screen for accepting details of the tampering of the verification software 21. Figures 9 and 10 show examples of a verification software tampering input screen 43 and a tampering result screen 44, respectively.

[0067] The tampering input screen 43 displays a pull-down menu of components to be selected in section 431. The pull-down menu displays, for example, second MGC firmware, MGC OS, MGC management software, first DKC firmware, and second DKC firmware. The components indicated by the pull-down menu correspond to the components shown in FIGS. 2 and 3. The second MGC firmware is second MGC firmware 220, and the MGC OS and MGC management software are each included in OS and management software 230. The MGC OS and MGC management software may be selected collectively as the OS and management software. The first DKC firmware is first DKC firmware 250. The second DKC firmware is second DKC firmware 260.

[0068] By allowing the user to select the program to be tampered with, the verification function can be tested with higher accuracy. Also, the pull-down menu can limit the information about the internal structure of the software that is given to the user.

[0069] The tampering input screen 43 displays a hash value corresponding to the selected portion in section 432. The selected portion includes the binary portion (program portion) and the signature portion. This allows for even more accurate testing. The hash value is the hash value of the binary portion. The signature portion is generated using the hash value of the binary portion and a private key.

[0070] The two radio buttons 433A, 433B accept the selection of the portion to be tampered with from the binary portion and the signature portion in the selected portion. The signature portion is generated from the hash value of the corresponding binary portion. In the example shown in FIG. 9, the binary portion of the first DKC firmware 250 is selected as the portion to be tampered with. In the example shown in FIG. 10, the signature portion of the first DKC firmware 250 is selected as the portion to be tampered with. In this example, one hash value and signature are generated from the OS and management software 230.

[0071] When the cancel button 434 is selected, the input information is canceled. When the OK button 435 is selected, the tampering unit 11 tampers with the specified portion in the verification software 21 in accordance with the input information. Furthermore, the tampering unit 11 uses the input / output unit 12 to display a tampering result screen 44.

[0072] 9 and 10, the tampering result screen 44 shows the hash value and actual binary of the verification software after tampering. In the example shown in Figures 9 and 10, the tampering result screen 44 shows the tampered part of the verification software 21 in section 441, and the hash value after tampering in section 442. Section 443 shows the value of the part before tampering, and section 444 shows the value of the part after tampering.

[0073] The tampering result screen 44 displays a copy button 445 for copying the tampered verification software 21 to the storage system 100. The user can copy the tampered verification software 21 to the storage system 100 by selecting the copy button 445 on the tampering result screen 44.

[0074] When the copy button 445 is selected, the tampering unit 11 transmits the verification software 21, with the specified portion tampered with, to the storage system 100. The tampered verification software 21 is stored in a predetermined memory area of ​​the management controller 120A or 120B and the disk controller 130A or 130B. In the following, it is assumed that the verification software 21 is stored in the storage controller 110A.

[0075] FIG. 11 is a diagram illustrating a method for installing (copying or storing) tampered verification software 21 into the storage controller 110A. In this embodiment, the storage controller 110A stores two pieces of software and executes one of them. The software that is executed is called the A-side software, and the other is called the B-side software. In a normal software update, the B-side software is updated, and then the designation of the B-side software and the A-side software is switched. As a result, the updated software becomes the A-side software and is executed by the storage controller 110A.

[0076] For example, before the tampered verification software is copied (installed) into the storage controller 110A, the A-side software and B-side software are normal software executed by the storage controller 110A.

[0077] When the management controller 120A receives the verification software from the management device 102, it updates the A-side software with the verification software (S5). The A-side software may be updated directly, or the B-side software may be updated with the verification software and the designation of the A-side software and the B-side software may be switched. In either case, the A-side software that is executed becomes the verification software 21, and the B-side software remains the normal software.

[0078] Thereafter, the management controller 120A starts up the verification software 21 on side A (S6), thereby starting the secure boot of the verification software 21. The management controller 120A executes an update program different from the update programs for the side A software and the side B software, thereby updating the side A software or the side B software.

[0079] Next, the startup process by the storage controller 110A will be explained. Figure 12 shows a flowchart of the startup process by the storage controller 110A. As described above, the A-side software of the storage controller 110A is the tampered verification software 21, and the B-side software is normal software.

[0080] First, the management controller 120A starts booting up. The CPU 121A of the management controller 120A executes the A-side software and determines whether the A-side software is verification software or normal software (S11).

[0081] For example, a boot loader (not shown) refers to a verification software determination bit in the software on side A. For example, if the verification software determination bit is 1, the software is verification software, and if it is 0, the software is normal software.

[0082] If the started software is normal software (S11: NO), the start-up process of the normal software is started (S12). If it is 1 (S11: YES), the start-up process of the verification software 21 is started (S13).

[0083] Specifically, the first MGC startup program 211 of the first MGC firmware 210 is started. The first MGC startup program 211 starts the first MGC verification program 212 in the first MGC firmware 210, verifies the second MGC firmware 220, and determines whether or not tampering has occurred (S14). If no tampering is detected (S14: NO), the next target program is started (S15). Here, the second MGC firmware 220 is started. If the startup of all programs has been completed (S16: YES), this flow ends.

[0084] If there are any programs that have not been started (S16: NO), verification of the next program is started (S17). Here, the second MGC verification program 222 executes verification of the OS and management software 230. The flow returns to step S14.

[0085] 4, the software of the storage controller 110A repeatedly verifies and starts up the program in stages. Specifically, if there is no tampering with the OS and management software 230 (S14: NO), the second MGC startup program 221 starts up the OS and management software 230.

[0086] The first DKC verification program 231 in the OS and management software 230 is executed to verify the first DKC firmware 250. If the first DKC firmware 250 has not been tampered with, the DKC startup instruction program 232 starts the first DKC firmware 250.

[0087] The second DKC verification program 252 of the first DKC firmware 250 is executed to verify the second DKC firmware 260. If the second DKC firmware 260 has not been tampered with, the DKC initial phase startup program 251 starts the second DKC firmware 260.

[0088] Any part of the verification software has been tampered with. Therefore, if the secure boot of the verification software is functioning properly, tampering will be detected in any part of the step-by-step verification and startup.

[0089] If any tampering is detected (S14: YES), the program that detected the tampering stops its subsequent startup process. The management controller 120A uses a software side management program (not shown) to rewrite the verification software 21 on side A with the normal software on side B (S18). After the program starts up, the normal software on side A updates the verification software on side B using a software update program. As a result, both the software on side A and the software on side B become normal software.

[0090] The program that detects the tampering stores the verification result in the log management information in the management controller 120, and also transmits a message indicating the verification result to the management device 102. The input / output unit 12 of the management device 102 displays the message on the output device 304 (S19). The message indicates that the test of the secure boot function was successful.

[0091] 13 shows an example of a tampering detection message. The tampering detection message can include multiple items. In the example shown in FIG. 13, the tampering detection message includes the following items: software type 61, tampered part 62, alert ID 63, date and time 64, reference 65, level 66, controller (CTL) ID 67, and message text 68.

[0092] The software type 61 indicates whether the software in which tampering was detected is verification software or normal software. The tampered part 62 indicates the part of the software that has been tampered with. The alert ID 63 is the message ID, and the date and time is the date and time when tampering was detected. The reference 65 indicates the information resource that should be referenced for the detected tampering.

[0093] The level 66 indicates the risk of tampering, and the controller ID 67 indicates the ID of the controller (management controller or disk controller) in which the software for which tampering was detected is stored. The message text 68 indicates the message text presented to the administrator. The information in the reference 65, the level 66, and the message text 68 are preset for the tampered portion. The tampering detection message allows the administrator to obtain information about the tampering.

[0094] In one embodiment of the present specification, the tampering test tool 10 presents the progress of the verification of the verification software to the administrator. This visualizes the verification status of the verification software, thereby improving convenience for the administrator.

[0095] FIG. 14 shows an example of a verification status screen. The verification status screen clearly shows the program configuration of the verification software and the program (portion) currently being verified. Each rectangle represents a program, and the arrows indicate the program startup order. Rectangle 71 represents a program in the management controller 120A, and rectangle 72 represents a program in the disk controller 130A. In the example shown in FIG. 14, tampering with the second MGC firmware is currently being verified, as indicated by circle 75.

[0096] When each program of the verification software is started, it sends that information to the management device 102. The input / output unit 12 updates the verification status screen in response to the start notification of each program received from the storage controller 110A.

[0097] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0098] Furthermore, the above-mentioned components, functions, processing units, etc. may be realized in part or in whole by hardware, for example, by designing them as integrated circuits. Furthermore, the above-mentioned components, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as the programs, tables, and files that realize each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card or SD card.

[0099] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0100] 11 tampering unit, 12 input / output unit, 13 authentication unit, 102 management device, 21 verification software, 110A, 110B storage controller, 120A, 120B management controller controller, 121A, 121B CPU, 123A, 123B flash memory, 125A, 125B SSD, 130A, 130B disk controller, 131A, 131B CPU, 133A, 133B flash memory, 135A, 135B SSD, 210 1st MGC firmware, 220 2nd MGC firmware, 230 OS and management software, 250 1st DKC firmware, 260 2nd DKC firmware

Claims

1. A system for testing tamper verification during startup of software executed in a storage controller, comprising: A management system; a storage controller, the management system stores verification software that is executed by the storage controller; the verification software includes a program that detects tampering within the verification software; The management system includes: tampering with a part of the verification software in response to instructions from a user; installing the partially tampered verification software in the storage controller; The storage controller starts the verification software, The management system presents to the user the results of the verification of tampering performed by the verification software received from the storage controller.

2. 10. The system of claim 1, the verification software includes a plurality of programs; In the plurality of programs, a preceding program verifies a subsequent program, and if no tampering has been found, starts the subsequent program; The management system receives from the user a designation of a program to be tampered with in the verification software.

3. 3. The system of claim 2, The management system accepts a selection of the digital signature portion or the binary portion to be tampered with.

4. 10. The system of claim 1, A system in which some functions of normal software executed by the storage controller are omitted from the verification software.

5. 10. The system of claim 1, the storage controller stores A-side software and B-side software; The storage controller launches the A-side software; the verification software is installed as the A-side software; The system, wherein the B-side software is regular software.

6. 6. The system of claim 5, The storage controller updates the verification software for which the tampering has been detected with the normal software of the B-side software.

7. 3. The system of claim 2, The management system includes: receiving information on a current verification status of the verification software from the storage controller; The system presents the current verification status information to the user.

8. Tamper verification during startup of software executed in a storage controller 1. A method of conducting a test, comprising: a system obtains verification software to be executed by the storage controller, the verification software including a program for detecting tampering within the verification software; The system tampers with a part of the verification software in response to an instruction from a user, the system installs the partially tampered verification software into the storage controller and starts the verification software; The method wherein the system presents to the user a result of the tampering verification performed by the verification software, the result being received from the storage controller.

Citation Information

Patent Citations

  • Electronic control device

    JP2023088706A

  • Storage system

    US20220413981A1