Encrypted disk management method and device, equipment and program product

Abstract

The invention discloses an encrypted disk management method and device, equipment and a program product, and the method comprises the steps that a disk array drive program calls a first drive program to obtain disk configuration data and key management server configuration data, and the first drive program is an interface program between an encrypted disk and an operating system; the first driving program establishes network connection with the secret key management server based on the secret key management server configuration data; the first driving program calls a second driving program to send the disk configuration data to the secret key management server by using the network connection, so as to obtain a secret key of the encrypted disk from the secret key management server, the second drive program is a client drive program created based on a key management interoperability protocol.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of electronic technology, and relate to, but are not limited to, an encrypted disk management method, apparatus, device, and program product. Background Art

[0002] In the key management design for Redundant Arrays of Independent Disks (RAID) to obtain keys stored on an external key management (EKM) server, the RAID driver must communicate with the system's Unified Extensible Firmware Interface (UEFI), and then with the Baseboard Management Controller (BMC) to obtain keys managed by the EKM server. This results in a reliance on both UEFI and BMC to support RAID's external key management functionality. This leads to the following technical issues: Complex design: The design includes multiple components and interfaces, which limits usage scenarios; Deployment difficulty: UEFI and BMC code must be modified to support EKM; Poor scalability: If new Key Management Interoperability Protocol (KMIP) commands are required, new commands must be designed for all interfaces; Security risks: The large number of interfaces involved increases the security risk of attacks through these interfaces; Poor adaptability: The BMC and KMIP server must be installed and configured for each machine. If the RAID adapter and Self-Encrypting Drive (SED) are moved to a new machine, all authentication and configuration will need to be done again.

[0003] How to improve the efficiency of disk array acquisition of external key management has become a technical problem that needs to be solved urgently. Summary of the Invention

[0004] In view of this, embodiments of the present application provide an encrypted disk management method, apparatus, device, and program product.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides an encrypted disk management method, comprising:

[0007] The disk array driver calls the first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encryption disk and the operating system;

[0008] The first driver establishes a network connection with the key management server based on the key management server configuration data;

[0009] The first driver calls the second driver to use the network connection to send disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0010] In a second aspect, an embodiment of the present application provides an encrypted disk management device, comprising:

[0011] An acquisition module, utilizing a disk array driver to call a first driver to acquire disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encryption disk and the operating system;

[0012] a connection module, utilizing the first driver to establish a network connection with the key management server based on the key management server configuration data;

[0013] The sending module uses the first driver to call the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0014] In a third aspect, an embodiment of the present application provides an electronic device comprising a memory, a processor and an encrypted disk, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, it uses a disk array driver to call a first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encrypted disk and the operating system; the first driver establishes a network connection with the key management server based on the key management server configuration data; the first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0015] In a fourth aspect, an embodiment of the present application provides a storage medium storing executable instructions, which, when executed by a processor, enables a disk array driver to call a first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encrypted disk and the operating system; the first driver establishes a network connection with the key management server based on the key management server configuration data; the first driver calls a second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0016] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by a processor, the disk array driver calls a first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encrypted disk and the operating system; the first driver establishes a network connection with the key management server based on the key management server configuration data; the first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A schematic diagram of an implementation flow of an encrypted disk management method provided in an embodiment of the present application;

[0018] Figure 2 A schematic diagram of a method for establishing a network connection according to an embodiment of the present invention;

[0019] Figure 3 A schematic diagram of an implementation flow of a method for sending disk configuration data provided in an embodiment of the present application;

[0020] Figure 4A A schematic diagram of an interaction for obtaining a key from a key management server provided in an embodiment of the present application;

[0021] Figure 4B A schematic diagram of a driver component and process for managing a disk array using UEFI provided in an embodiment of the present application;

[0022] Figure 5 A schematic diagram of the structure of an encrypted disk management device provided in an embodiment of the present application;

[0023] Figure 6 A schematic diagram of a hardware entity of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] To make the purpose, technical solutions and advantages of the embodiments of the present application more clear, the specific technical solutions of the embodiments of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application but are not intended to limit the scope of the present application.

[0025] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0028] The present application embodiment provides an encrypted disk management method, such as Figure 1 As shown, the method includes:

[0029] Step S110: The disk array driver calls a first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encrypted disk and the operating system;

[0030] RAID (Redundant Array of Independent Disks) is a technology that combines multiple independent physical disks into a single logical unit to improve data storage performance, reliability, and fault tolerance. RAID optimizes storage systems through data distribution, striping, mirroring, and parity checking.

[0031] A RAID driver is a software component that manages and controls a redundant array of independent disks system. It provides an abstraction layer between the operating system and the physical disks, enabling multiple disks to work as a single logical unit.

[0032] The first driver can be an OPAL driver for disk array encryption, namely the RAID SED OPAL driver, which is an interface program between the encrypted disk and the operating system. It is used to handle the encryption and decryption operations of the SED, as well as the security policies related to the management of the SED. Among them, the self-encrypting drive (Self-Encrypting Drive, SED) is a storage device with built-in encryption function. It uses hardware-level encryption technology to encrypt and decrypt data stored in the hard drive in real time. The OPAL Storage Specification (TCG Opal Storage Specification) is a standardized specification for self-encrypting hard drives developed by the Trusted Computing Group (TCG). It defines the management interface and security protocol, strengthens data protection through hardware-level encryption technology, and reduces the impact on the host system performance.

[0033] During implementation, when the system boots up (either during device self-test or during device operation), the disk array driver first initializes the disk array. Upon detecting that the disk array is an encrypted disk device, the first driver is triggered to load, which uses the first driver to retrieve disk configuration data and key management server configuration data. The disk configuration data includes encryption-related parameters (hardware information, security configuration information, key management information) and status information of the disk array device; the key management server configuration data includes data such as the server address, port number, authentication method, and key management policy.

[0034] Step S120: The first driver establishes a network connection with the key management server based on the key management server configuration data;

[0035] During implementation, the first driver is used to connect to the key management server based on the server address (IP address), port number, and authentication method of the key management server to ensure network accessibility.

[0036] In some embodiments, using username / password authentication, the first driver may send an authentication request to the key management server.

[0037] In some embodiments, using certificate authentication, the first driver may use a client certificate to perform bidirectional Transport Layer Security version (TLS) authentication with a key management server.

[0038] Step S130: The first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0039] Here, the second driver, the Key Management Interoperability Protocol (KMIP) client driver, is a client driver based on the KMIP, which is used to handle communication, authentication, and key negotiation with the Key Management Service (KMS). The KMS is used to store and manage encryption keys and support key lifecycle management (generation, distribution, rotation, and destruction). The KMIP defines a standard interface for key management operations, including key creation, acquisition, and destruction. It supports multiple encryption algorithms (such as AES and RSA) and key encapsulation formats.

[0040] During implementation, the first driver, through collaboration with the second driver, sends disk configuration data to the key management server. The key management server then retrieves the key corresponding to the disk array based on the disk configuration data and returns it to the second driver. This allows the second driver to securely interact with the key management server to obtain and manage the keys for encrypted disks. It supports a variety of encryption algorithms and key formats to meet the needs of diverse scenarios. It provides high availability and fault tolerance, ensuring the stability of the key management service.

[0041] In this embodiment of the present application, the disk array driver calls a first driver to obtain disk configuration data and key management server configuration data; the first driver establishes a network connection with the key management server based on the key management server configuration data; and the first driver calls a second driver using the network connection to send the disk configuration data to the key management server, thereby obtaining the encryption key for the encrypted disk from the key management server. This provides an independent disk array driver that supports external key management by the KMIP server, independent of the Unified Extensible Firmware Interface (UEFI) and baseboard management controller (BMC) firmware. This achieves secure encryption management across the entire chain, from the disk array driver to the encrypted disk device. This ensures secure key generation, storage, and usage, meeting the data protection requirements of enterprise-class storage systems. The solution architecture is simple: only changes to the disk array driver are required, involving only the network interface. This solution is easy to deploy: supporting external key management requires no code changes to the UEFI or BMC. Scalability: Updates to the KMIP specification require only changes to the disk array driver. Low security risk: Only the network interface is involved, resulting in a low risk of attack. A good user experience: The adapter only requires a single configuration and authentication installation, and can be moved from one machine to another.

[0042] In some embodiments, the above step S110 "the disk array driver calls the first driver to obtain disk configuration data and key management server configuration data" can be implemented by the following process:

[0043] The disk array driver calls the first driver so that the first driver obtains the disk configuration data and the key management server configuration data from the cache corresponding to the encryption disk through a third driver, wherein the third driver is an interface program between the first driver and the cache corresponding to the disk.

[0044] Here, the third driver is the disk array encryption HII driver. The HII driver is an infrastructure for managing user input and interface display. It can be used with firmware using the Unified Extensible Firmware Interface (UEFI) or other types of drivers to provide configuration and management interfaces.

[0045] The third driver acts as an interface between the first driver and the cache corresponding to the disk. During implementation, the third driver can read disk configuration data and key management server configuration data stored in the cache corresponding to the encrypted disk. The third driver can also access system configuration data and support user interface interaction.

[0046] Disk configuration data can be stored in specific areas of the disk, such as the firmware area or a dedicated configuration partition. This data can include physical disk parameters (such as the number of cylinders, tracks, and sectors), logical partition information, and encryption status. In the case of encrypted disks, disk configuration data can also include encryption-related information, such as the encryption algorithm, encryption mode, and key index.

[0047] Disk configuration data can be written into the firmware or the dedicated partition of the disk by the disk manufacturer during the production process. In certain embodiments, the user or system administrator can also modify or update the disk configuration data through a specific tool or interface.

[0048] The key management server configuration data can be stored in the key management server's own storage system, such as a database, file system, or a dedicated key storage device.

[0049] The key management server configuration data may be KMIP server configuration data, including the server's uniform resource locator (URL), port, authentication information, etc. The data may be stored in at least one of the following locations: SED firmware, system BIOS / UEFI settings, a separate configuration file, or a database.

[0050] In some embodiments, the KMIP configuration is stored in the SED or UEFI, and the HII driver can read this data directly.

[0051] In some embodiments, the KMIP configuration is stored elsewhere, and the HII driver may need to call other system services or drivers to obtain the data.

[0052] In this embodiment of the present application, the first driver retrieves the disk configuration data and the key management server configuration data from the cache corresponding to the encrypted disk via a third driver. Thus, while the third driver itself does not directly retrieve the SED or KMIP server configuration data, it can serve as a user interface to interact with these configurations. The third driver can be used to view and modify SED and KMIP server configuration information.

[0053] In some embodiments, the above step S120 "the first driver establishes a network connection with the key management server based on the key management server configuration data" is as follows: Figure 2 As shown, this can be achieved by following the steps below:

[0054] Step S210: The first driver determines the key management server based on the key management server configuration data;

[0055] During implementation, the first driver may determine the key management server to be connected based on the KMS server address, port, authentication information, etc.

[0056] Step S220: The first driver establishes a network connection with the key management server through the system unified extensible firmware interface.

[0057] During implementation, the first driver can work in conjunction with the network stack in the system UEFI firmware to enable communication with the key management server. The first driver calls the UEFI network protocol stack (e.g., TCP / IP) to establish a connection with the key management server. Communication is performed using the key management server's port number (e.g., 1688). Data (e.g., key requests, activation requests) is exchanged with the key management server via HTTP / HTTPS or a custom protocol.

[0058] In an embodiment of the present application, first, the first driver determines the key management server based on the key management server configuration data; then the first driver establishes a network connection with the key management server through the system unified extensible firmware interface. The driver dynamically determines the key management server address based on the configuration data without hard coding or manual intervention. Direct access to network hardware through the system unified extensible firmware interface reduces the operating system overhead. No additional middleware or agent program needs to be installed, reducing third-party dependence. The connection with the key management server is completed safely and efficiently during the startup phase, laying the foundation for subsequent security operations (such as disk encryption and identity authentication).

[0059] In some embodiments, the above step S220 "the first driver establishes a network connection with the key management server through the system unified extensible firmware interface" can be implemented by the following steps:

[0060] Step 221: Establishing a transmission connection between the first driver and the system unified extensible firmware interface based on the network layer;

[0061] The network layer between the system UEFI and the first driver is the third layer of the TCP / IP protocol stack, responsible for routing and forwarding data packets, enabling data transmission across different networks. The first driver will request a network connection for TCP / IP configuration data to establish a transmission connection with the system UEFI interface.

[0062] Step 222: A security protocol data transmission connection is established between the system unified extensible firmware interface and the key management server based on the transport layer, so as to utilize the security protocol to authenticate, encrypt or integrity protect the data transmitted based on the transport layer.

[0063] Here, the Transport Layer Security (TLS) protocol, based on the TLS1.2 / 1.3 protocol, negotiates the encryption suite and key exchange algorithm through the handshake protocol to achieve two-way authentication and key negotiation.

[0064] In some embodiments, during the UEFI boot phase, a TLS driver is loaded, an encryption context is initialized, and a secure channel is established with a key management server. UEFI can ensure the legitimacy of the connection by verifying the key management server's digital certificate (issued by a trusted CA). UEFI can also obtain a signature key database from the key management server via TLS to verify the digital signature of the boot image and prevent malicious code injection.

[0065] In this embodiment of the present application, a transmission connection is established between the first driver and the system unified extensible firmware interface at the network layer; and a secure protocol data transmission connection is established between the system unified extensible firmware interface and the key management server at the transport layer. This allows the use of a secure protocol to authenticate, encrypt, or integrity-protect data transmitted at the transport layer, thereby protecting the encrypted disk key obtained from the key management server.

[0066] In some embodiments, establishing the network connection further includes the following steps:

[0067] Step 223: Deploy the key management interoperability protocol to the security protocol of the transport layer to perform data transmission based on the key management interoperability protocol.

[0068] Here, the Key Management Interoperability Protocol (KMIP) is deployed on top of transport layer security protocols (such as TLS / SSL). KMIP enables standardized management of keys and cryptographic objects, while leveraging transport layer security protocols to ensure confidentiality, integrity, and authentication of communications. KMIP provides a cross-platform key management standard that supports multiple encryption algorithms (such as AES and RSA) and key types (symmetric, asymmetric, and certificates). TLS, as a standard transport layer protocol, ensures secure communication between devices and key management servers from different manufacturers.

[0069] KMIP uses XML or JSON-based message formats to define key lifecycle management operations (such as creation, destruction, and query). KMIP messages are encrypted via TLS before transmission to prevent middleman attacks and eavesdropping.

[0070] The client and server negotiate encryption parameters (such as cipher suites and keys) through a TLS handshake and verify each other's identities (based on digital certificates).

[0071] After the TLS handshake is completed, the generated session key is used to encrypt KMIP messages, ensuring the security of key management operations.

[0072] During implementation, KMIP messages can be encapsulated in a TLS session and transmitted encrypted via TLS.

[0073] In this embodiment, the Key Management Interoperability Protocol (KMIP) is deployed within the transport layer security protocol, enabling data transmission based on the KMIP. Deploying KMIP over the transport layer security protocol combines the advantages of both to achieve standardized, secure, and efficient key management. TLS encrypts KMIP messages, preventing the leakage of key management instructions and data. TLS's MAC mechanism ensures that KMIP messages are not tampered with during transmission. TLS certificate verification ensures the authenticity of KMIP clients and servers, preventing impersonation attacks.

[0074] In some embodiments, in step S130 above, "the first driver calls the second driver to send the disk configuration data to the key management server using the network connection" Figure 3 As shown, this can be achieved by following the steps below:

[0075] Step S310: The first driver calls the second driver to send a key creation instruction for creating a key to the key management server using the network connection, wherein the key creation instruction is created based on the key management interoperability protocol and includes the disk configuration data;

[0076] Here, the first driver invokes the second driver, leveraging the established network connection to send a key creation instruction to the key management server. This instruction is built on KMIP to ensure cross-platform or cross-system compatibility. The instruction includes disk configuration data, including disk identification, capacity, and partition information, which guides the key management server in generating a key associated with the encrypted hard disk.

[0077] The KMIP protocol is an internationally standardized key management protocol that supports operations such as key generation, storage, distribution, and destruction, and is widely used in enterprise-level encryption solutions.

[0078] Disk configuration data, which can include the disk's unique identifier (such as UUID), physical / logical path, partition table information, etc., is used to ensure the accurate binding of the secret key to the target disk.

[0079] Step S320: Utilize the second driver to return the encryption key of the encrypted disk obtained from the key management server to the first driver.

[0080] During implementation, the second driver encapsulates the KMIP request (key creation instruction) and sends it to the key management server through a preconfigured network connection (such as TCP / IP or named pipes). During the forwarding process, the second driver can add additional security layers (such as TLS encryption and message signing) to ensure the integrity and confidentiality of the request. The key management server parses the KMIP request and searches for the corresponding key based on the disk identifier. If the key exists, the server encapsulates it as a KMIP response message; if the key does not exist, an error code is returned. The second driver receives the response from the key management server, parses the KMIP message and extracts the key data. The response is checked for integrity (such as HMAC verification) to ensure that the key has not been tampered with. The second driver returns the decrypted key data to the first driver by calling a callback function or event notification. During the return process, it is necessary to avoid the key from residing in memory for a long time to reduce the risk of leakage.

[0081] In this embodiment of the present application, the first driver first calls the second driver to use the network connection to send a key creation instruction to the key management server. The second driver then returns the encrypted disk key obtained from the key management server to the first driver. This enables secure key exchange between the first driver and the key management server. A standardized protocol (KMIP) ensures compatibility; a layered driver architecture improves modularity; and strict security measures prevent key leakage. This system achieves efficient and secure key management.

[0082] In some embodiments, the above method for managing encrypted disks further includes the following steps:

[0083] Step S140: The first driver generates a trusted computing organization secure storage instruction based on the secret key of the encrypted hard disk;

[0084] The Trusted Computing Group (TCG) protocol defines the security policies and command sets for SED devices. TCG Security Storage commands can be used to implement at least the following operations:

[0085] Provisioning: Initialize the SED device, set the administrator password and lock range.

[0086] Lock: Locks the SED device to prevent data access.

[0087] Unlock: Unlock the device using the administrator password or key.

[0088] During implementation, the first driver can first verify the legitimacy of the key (such as length and format) to ensure that the key matches the target hard drive. Then, based on the secret key, it generates a TCG secure storage instruction, which encapsulates the key data and the hard drive identifier into an instruction.

[0089] Step S150: The first driver executes the Trusted Computing Organization secure storage instruction to implement at least one of the following management of the encrypted hard disk: configuration, locking, and unlocking.

[0090] During implementation, when a new hard drive is inserted into an electronic device, the first driver can configure the encrypted hard drive based on the configuration instructions generated by the secret key. If a sensitive data range on the hard drive is locked, the first driver executes the locking instructions, causing the hard drive to mark the range as read-only or completely locked. Once locked, any attempt to access the range is denied, entering an encrypted protection state. If the correct password is obtained, the first driver verifies the password on the hard drive and marks the range as read-write. Users can then access the data normally.

[0091] In this embodiment, the first driver first generates a Trusted Computing Group secure storage instruction based on the encrypted hard drive's secret key; then, the first driver executes the Trusted Computing Group secure storage instruction. This allows for at least one of the following management aspects of the encrypted hard drive: configuration, locking, and unlocking. Using the TCG secure storage instruction, the first driver can efficiently manage the configuration, locking, and unlocking of the encrypted hard drive.

[0092] Figure 4A This is a schematic diagram of an interaction for obtaining a key from a key management server provided in an embodiment of the present application, such as Figure 4A As shown, the schematic diagram includes a disk array 41, a UEFI disk array driver 42, a system UEFI 43 and a key management server 43, wherein:

[0093] The UEFI disk array driver 42 manages the disk array 41 through TCGStorage commands. TCGStorage is a series of standards developed by the Trusted Computing Group (TCG) to provide security protection for storage devices, especially to ensure data security through hardware-level encryption technology.

[0094] During implementation, the user interface may be set based on the UEFI disk array driver 42 to enable or disable SED and select Enterprise Key Management (EKM) or Local Key Management (LKM).

[0095] Enabling / disabling SEDs: TCGStorage commands are sent through a specific management interface (such as UEFI or a dedicated management tool) to control the enabling or disabling status of SEDs. For example, a button for "Enable SED" or "Disable SED" may be provided in the user interface. The UEFI disk array driver 42 communicates with the disk array 41 via the TCGStorage protocol.

[0096] Enterprise Key Management (EKM) and Local Key Management (LKM) are two different key management solutions. EKM, where encryption keys are centrally managed by an enterprise-level key management system, is suitable for large organizations that require unified management and auditing. LKM, where keys are stored on local devices, is suitable for small businesses or scenarios with strict requirements for data sovereignty. For example, a radio button or drop-down menu can be set in the user interface. Provide options for EKM and LKM, and briefly explain the difference between the two. In the corresponding setting configuration wizard, if the user selects EKM, the user is guided to enter the address and authentication information of the key management server; if LKM is selected, the user is prompted to back up the local key. In some embodiments, a suitable key management solution can also be recommended by default based on the usage scenario of the device (such as enterprise edition or personal edition).

[0097] When a key management system based on the Key Management Interoperability Protocol (KMIP) is constructed between the system UEFI 43 and the UEFI disk array driver 42, an encrypted channel is established through the Transport Layer Security version 1.2 (TLS1.2) to ensure communication security. The Key Management Interoperability Protocol is a standardized protocol for managing and operating encryption keys that can achieve interoperability between different key management servers (KMS) and encryption devices. TLS1.2 is a version of the Transport Layer Security protocol that can provide a secure communication channel to prevent data from being eavesdropped, tampered with, or forged.

[0098] Here, the system UEFI 43 can provide a standard network connection. The UEFI disk array driver 42 can directly manage the network connection through the system UEFI 43 and realize communication with the key management server 44.

[0099] The network layer between the system UEFI 43 and the UEFI disk array driver 42 is the third layer in the TCP / IP protocol stack. It is responsible for routing and forwarding data packets, enabling data to be transmitted across different networks. The UEFI disk array driver 42 will request a network connection for TCP / IP configuration data.

[0100] The key management server 44 and the system UEFI 43 establish an encrypted channel through the Transport Layer Security Protocol 1.2 to ensure communication security.

[0101] During implementation, the UEFI disk array driver 42 sends / receives authentication to the key management server 44. Specifically, the UEFI disk array driver 42 can exchange certificates with the key management server 44 to establish secure communication. The UEFI disk array driver 42 sends KMIP commands to the key management server 44 on the trusted network. The UEFI disk array driver 42 can send storage security commands to the encrypted drive (disk array) to lock / unlock the drive.

[0102] Figure 4B A UEFI driver component and flow chart for managing a disk array provided in an embodiment of the present application is as follows: Figure 4B As shown, the UEFI disk array driver 42 includes the following driver components: a disk array driver (RAIDDriver) 421, a disk array encryption OPAL (RAID SED OPAL) driver 422, a disk array encryption human-machine interface infrastructure (HII) driver 423, a disk array cache (RAID NVRAM) 424, and a KMIP client driver (KMIP Client Driver) 425. The following steps can be used to implement the key management of the disk array:

[0103] Step 1, the disk array driver 421 drives and triggers the disk array encryption OPAL driver 422;

[0104] During implementation, when the system is started, the disk array driver 421 initializes the disk array. When it is detected that the disk array is an encrypted disk device, the disk array encryption OPAL driver 422 is triggered to load.

[0105] Step 2: The disk array encryption OPAL driver 422 obtains configuration information through the disk array encryption HII driver 423;

[0106] During implementation, the disk array encryption OPAL driver 422 calls the disk array encryption HII driver 423 to read the configuration information of the disk array from the disk array cache 424. The HII driver 423 can be used to access system configuration data and support user interface interaction.

[0107] During implementation, the disk array encryption OPAL driver 422 obtains SED configuration data and KMIP server configuration data through the disk array encryption HII driver 423. For example, the disk array encryption HII driver 423 can obtain a digital certificate (CERT) and other variables. The digital certificate is used to identify the binding relationship between the public key and the entity identity in network communication. Other variables may include fields, parameters, or policies in the certificate.

[0108] Step 3: The disk array encryption OPAL driver 422 drives the establishment of a secure network connection;

[0109] During implementation, the disk array encryption OPAL driver 422 may establish a connection to the key management compliance server 44 using the UEFI network protocol stack (eg, TCP / IP).

[0110] In some embodiments, TLS / SSL encryption can be enabled for network connections to ensure secure key transmission. The disk array encryption OPAL driver 422 establishes a TCP / IP connection and calls the TLS configuration protocol to configure encryption parameters. After network communication is established, the KMIP server certificate can be verified. The KMIP protocol is a standardized key management interface that supports key creation, storage, and retrieval.

[0111] Step 4: The disk array encryption OPAL driver 422 interacts with the KMIP client driver 425;

[0112] During implementation, the disk array encryption OPAL driver 422 may construct a KMIP request message (eg, CreateKeyRequest), and call the KMIP client driver 425 to communicate with the key management compliance server to obtain the disk array's key.

[0113] Step 5: The KMIP client driver 425 communicates with the key management compliance server 44;

[0114] During implementation, the KMIP client driver 425 sends a key request to the key management compliance server 44 via a TCP / IP socket.

[0115] After the key management compliance server 44 responds, the KMIP client driver 425 parses the response message obtained from the key management compliance server 44 and returns the message including the key to the disk array encryption OPAL driver 422 .

[0116] Step 6: The disk array encryption OPAL driver 422 executes the TCG secure storage command;

[0117] The Trusted Computing Group (TCG) protocol defines the security policies and command sets for SED devices. TCG Security Storage commands can be used to implement at least the following operations:

[0118] Provisioning: Initialize the SED device, set the administrator password and lock range.

[0119] Lock: Locks the SED device to prevent data access.

[0120] Unlock: Unlock the device using the administrator password or key.

[0121] During implementation, the disk array encryption OPAL driver 422 communicates with the disk array via ATA Security Command Set or SCSI TCG commands.

[0122] In the embodiment of the present application, an independent RAID driver is provided to support external key management of the KMIP server, which is independent of UEFI and BMC firmware. Full-link secure encryption management is implemented from the disk array driver to the SED device, and the secure generation, storage and use of keys are ensured through the UEFI protocol stack and standardized interfaces (such as TCG OPAL, KMIP), which is suitable for the data protection needs of enterprise-level storage systems. The solution architecture is simple in design: only the UEFI RAID driver needs to be changed, and only the network interface is involved. Easy to deploy: external key management can be supported without code changes on BMC and UEFI. Scalability: If the KMIP specification is updated, only the UEFI RAID driver needs to be changed. Low security risk: only the network interface is involved, and the security risk of being attacked is low. Good user experience: the adapter only needs to be configured and authenticated once for installation, and then it can be moved from one machine to another.

[0123] Based on the foregoing embodiments, an embodiment of the present application provides an encrypted disk management device, which includes various modules, each module includes various sub-modules, each sub-module includes a unit, and can be implemented by a processor in an electronic device; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0124] Figure 5 A schematic diagram of the structure of the encrypted disk management device provided in the embodiment of the present application is shown as follows: Figure 5 As shown, the apparatus 500 includes:

[0125] An acquisition module 510 uses a disk array driver to call a first driver to acquire disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encryption disk and the operating system;

[0126] A connection module 520 uses the first driver to establish a network connection with the key management server based on the key management server configuration data;

[0127] The sending module 530 uses the first driver to call the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

[0128] In some embodiments, the acquisition module uses the disk array driver to call the first driver, so that the first driver obtains the disk configuration data and the key management server configuration data from the cache corresponding to the encryption disk through a third driver, wherein the third driver is an interface program between the first driver and the cache corresponding to the disk.

[0129] In some embodiments, the connection module 520 includes a determination submodule and a connection submodule, wherein the determination submodule uses the first driver to determine the key management server based on the key management server configuration data; the connection submodule uses the first driver to establish a network connection with the key management server through the system unified extensible firmware interface.

[0130] In some embodiments, the connection submodule includes a first connection unit and a second connection unit, wherein the first connection unit uses the first driver to establish a transmission connection based on the network layer between the system unified extensible firmware interface; the second connection unit is used to establish a security protocol data transmission connection based on the transport layer between the system unified extensible firmware interface and the key management server, so as to use the security protocol to authenticate, encrypt or integrity protect the data transmitted based on the transport layer.

[0131] In some embodiments, the connection submodule further includes a deployment unit configured to deploy a key management interoperability protocol to the security protocol of the transport layer, so as to perform data transmission based on the key management interoperability protocol.

[0132] In some embodiments, the sending module includes a sending submodule and a returning submodule, wherein the sending submodule uses the first driver to call the second driver to use the network connection to send a key creation instruction for creating a key to the key management server, wherein the key creation instruction is created based on the key management interoperability protocol, and the key creation instruction includes the disk configuration data; the returning submodule uses the second driver to return the key of the encrypted disk obtained from the key management server to the first driver.

[0133] In some embodiments, the encrypted disk management device also includes a generation module and an execution module, wherein the generation module uses the first driver to generate a trusted computing organization secure storage instruction based on the secret key of the encrypted hard disk; the execution module uses the first driver to execute the trusted computing organization secure storage instruction to achieve at least one of the following management of the encrypted hard disk: configuration, locking and unlocking.

[0134] The description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0135] It should be noted that, in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable an electronic device (which can be a mobile phone, tablet computer, laptop computer, desktop computer, etc.) to execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program code, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0136] Correspondingly, an embodiment of the present application provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps in the encrypted disk management method provided in the above embodiment are implemented.

[0137] Correspondingly, an embodiment of the present application provides an electronic device, Figure 6 A hardware entity diagram of an electronic device provided in an embodiment of the present application, such as Figure 6 As shown, the hardware entity of the device 600 includes: a memory 601 and a processor 602, the memory 601 stores a computer program that can be run on the processor 602, and the processor 602 implements the steps of the encrypted disk management method provided in the above embodiment when executing the program.

[0138] The memory 601 is configured to store instructions and applications executable by the processor 602, and can also cache data to be processed or processed by the processor 602 and various modules in the electronic device 600 (for example, image data, audio data, voice communication data and video communication data), which can be implemented through flash memory (FLASH) or random access memory (RAM).

[0139] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0140] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments.

[0141] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0143] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the scheme of this embodiment.

[0144] In addition, all functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the above-mentioned integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0145] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0146] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can essentially or in other words be embodied in the form of a software product that contributes to the relevant technology. The computer software product is stored in a storage medium and includes several instructions for enabling an electronic device (which can be a mobile phone, tablet computer, laptop computer, desktop computer, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0147] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0148] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0149] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0150] The above is merely an embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A method for managing an encrypted disk, the method comprising: The disk array driver calls the first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encryption disk and the operating system; The first driver establishes a network connection with the key management server based on the key management server configuration data; The first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

2. The method according to claim 1, wherein the disk array driver calls the first driver to obtain disk configuration data and key management server configuration data, comprising: The disk array driver calls the first driver so that the first driver obtains the disk configuration data and the key management server configuration data from the cache corresponding to the encryption disk through a third driver, wherein the third driver is an interface program between the first driver and the cache corresponding to the disk.

3. The method of claim 1 , wherein the first driver establishes a network connection with the key management server based on the key management server configuration data, comprising: The first driver determines the key management server based on the key management server configuration data; The first driver establishes a network connection with the key management server through a system unified extensible firmware interface.

4. The method according to claim 3, wherein the first driver establishes a network connection with the key management server through a system unified extensible firmware interface, comprising: Establishing a transmission connection between the first driver and the system unified extensible firmware interface based on the network layer; A security protocol data transmission connection is established between the system unified extensible firmware interface and the key management server based on the transport layer, so as to utilize the security protocol to authenticate, encrypt or integrity protect the data transmitted based on the transport layer.

5. The method of claim 4, further comprising: A key management interoperability protocol is deployed on the security protocol of the transport layer to perform data transmission based on the key management interoperability protocol.

6. The method according to claim 1, wherein the first driver calls the second driver to send the disk configuration data to the key management server using the network connection, comprising: The first driver calls the second driver to send a key creation instruction for creating a key to the key management server by using the network connection, wherein the key creation instruction is created based on a key management interoperability protocol and includes the disk configuration data; The second driver program is used to return the encryption key of the encrypted disk obtained from the key management server to the first driver program.

7. The method according to any one of claims 1 to 6, further comprising: The first driver generates a trusted computing organization secure storage instruction based on the secret key of the encrypted hard disk; The first driver executes the Trusted Computing Organization secure storage instruction to implement at least one of the following management of the encrypted hard disk: configuration, locking, and unlocking.

8. An encrypted hard disk management device, comprising: an acquisition module, utilizing a disk array driver to call a first driver to acquire disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encryption disk and the operating system; a connection module, utilizing the first driver to establish a network connection with the key management server based on the key management server configuration data; A sending module utilizes the first driver to call a second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

9. An electronic device comprising a memory, a processor, and an encryption disk, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, it uses a disk array driver to call a first driver to obtain disk configuration data and key management server configuration data, wherein: The first driver is an interface program between the encrypted disk and the operating system; the first driver establishes a network connection with the key management server based on the key management server configuration data; the first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

10. A computer program product comprising at least a disk array driver, a first driver, and a second driver, wherein: The disk array driver calls the first driver to obtain disk configuration data and key management server configuration data, wherein the first driver is an interface program between the encrypted disk and the operating system; the first driver establishes a network connection with the key management server based on the key management server configuration data; the first driver calls the second driver to use the network connection to send the disk configuration data to the key management server to obtain the key of the encrypted disk from the key management server, wherein the second driver is a client driver created based on the key management interoperability protocol.

Images