CN115118413B

CN115118413B - TDS validity testing method and device, electronic equipment and storage medium

Info

Publication number: CN115118413B
Application number: CN202211036625.4A
Authority: CN
Inventors: 陈云飞; 刘勤学; 杨爱军; 杨平; 何玉元
Original assignee: LCFC Hefei Electronics Technology Co Ltd
Current assignee: LCFC Hefei Electronics Technology Co Ltd
Priority date: 2022-08-29
Filing date: 2022-08-29
Publication date: 2022-11-08
Anticipated expiration: 2042-08-29
Also published as: CN115118413A

Abstract

The present disclosure provides a method and an apparatus for testing validity of TDS, an electronic device, and a storage medium, which are applied to a tester, and the method includes: starting and acquiring first test data; shutting down; restarting and loading the trusted device setting TDS; acquiring the first test data and the second test data through the TDS; the second test data is the first test data updated after the test case is executed on the first test data; comparing the first test data and the second test data by the TDS to determine an intrusion result; and comparing the intrusion result with an expected result corresponding to the test case, and determining that the TDS is effective if the intrusion result is consistent with the expected result.

Description

TDS validity testing method and device, electronic equipment and storage medium

Technical Field

The disclosure relates to the technical field of computers, and in particular to a method and a device for testing validity of TDS, an electronic device and a storage medium.

Background

In recent years, customized orders (CTO) have appeared To meet special software requirements of different customers, and for example, X rite, L3, TDS (Trusted Device Setup), glance, etc. are common special software items in customized orders. Some of the software is bound with the bottom hardware of the computer, for example, the TDS software is bound with the Intel vpro CPU chip, and provides a software interface for TDS on the CPU chip. The TDS software provides a trusted security platform for protecting computer security data, and can determine whether the computer is tampered by detecting case intrusion, changes made to firmware or BIOS configuration, storage drive replacement, starting or destroying encrypted data in the transmission process and other changes, so as to ensure that the configuration data of the whole process from factory shipment to a user is completely protected.

Taking a customized order added to a TDS software project as an example, the flow from order creation to shipment is as follows: firstly, a plan is created according to the special requirements of a customer, feasibility research is carried out, software projects are issued after evaluation is passed, then software is added into a bill of materials and a special order number is generated, and finally, shipment is carried out by a shipment system.

However, in the entire customized order creation and automated shipment process, there is no compatibility or compatibility test for hardware and software of the TDS, such as the basic input/output system, the solid state disk, the management engine, the CPU, and the like, and therefore, the effectiveness of the TDS of the customized computer on data protection and intrusion identification functions cannot be proved, and a situation of "equipment intrusion" (indicating that the equipment is not an original genuine product) still occurs in the shipped customized computer without contact.

Disclosure of Invention

The disclosure provides a method and a device for testing validity of TDS, an electronic device and a storage medium, which are used for at least solving the technical problems in the prior art.

According to a first aspect of the present disclosure, there is provided a method for testing validity of TDS, which is applied to a tester, the method including: starting and acquiring first test data; shutting down; restarting and loading the trusted device setting TDS; acquiring the first test data and the second test data through the TDS; the second test data is updated first test data after the test case is executed on the first test data; comparing the first test data and the second test data by the TDS to determine an intrusion result; and comparing the intrusion result with an expected result corresponding to the test case, and determining that the TDS is effective if the intrusion result is consistent with the expected result.

In an embodiment, the test case is used to update specific data in the first test data.

In one embodiment, the first test data includes the following for the tester: CPU voltage data, solid state disk data, BIOS version information and basic setting data; the acquiring of the first test data includes: and loading a management engine, and acquiring the first test data through the management engine.

In an embodiment, after acquiring the first test data, the method further includes: saving, by the management engine, the first test data; the acquiring the first test data and the second test data through the TDS comprises: loading the management engine, and acquiring the second test data through the management engine; obtaining the first test data and the second test data from the manageability engine through the TDS.

In one embodiment, the first test data includes: the serial number, the HASH value and the public key of the test machine; the acquiring of the first test data includes: loading a management engine, and acquiring software data and hardware data of the tester through the management engine, wherein the hardware data comprises a serial number of the tester; loading a TDS (total synchronous data base), acquiring software data and hardware data of the tester from the management engine through the TDS, and encrypting to generate the HASH value; and acquiring the hardware data of the mainboard of the tester through a Trusted Platform Module (TPM) and encrypting the hardware data to generate the public key.

In an implementation manner, after acquiring the first test data, the method further includes: and sending the first test data to a first server so that a data processing device acquires the first test data from the first server, executes the test case on the first test data to obtain second test data, and stores the second test data in a second server.

In an embodiment, the acquiring the first test data and the second test data by the TDS includes: the first test data is acquired from the first server through the TDS, and the second test data is acquired from the second server.

In an implementation manner, if the intrusion result is inconsistent with the expected result corresponding to the test case, the method further includes: determining that the TDS is invalid; and outputting the fault code of the intrusion result, and inquiring a fault reason in a code base according to the fault code.

According to a second aspect of the present disclosure, there is provided a TDS validity testing apparatus, applied to a testing machine, the apparatus including: the starting module is used for starting the testing machine; the acquisition module is used for acquiring first test data after the test machine is started; a shutdown module, configured to shut down the test machine after the first test data is obtained; the starting module is also used for restarting the tester; the TDS module is used for loading a trusted device setting TDS after the test machine is restarted; the acquiring module is further configured to acquire the first test data and the second test data through the TDS; the second test data is the first test data updated after the test case is executed on the first test data; a determining module, configured to determine an intrusion result by comparing the first test data and the second test data through the TDS; and the judging module is used for comparing the intrusion result with the expected result corresponding to the test case, and if the intrusion result is consistent with the expected result, determining that the TDS is effective.

According to a third aspect of the present disclosure, there is provided an electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the first and the second end of the pipe are connected with each other,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of validity testing of the TDS of the present disclosure.

According to a fourth aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform a method of validity testing of a TDS of the present disclosure.

The invention discloses a TDS validity testing method and device, electronic equipment and a storage medium, which are applied to a testing machine. Firstly, a testing machine is started, first testing data is obtained, and then the testing machine is shut down. Loading the TDS after restarting the tester, and acquiring first test data and second test data through the TDS, wherein the second test data is the first test data updated after executing the test case. And comparing whether the first test data and the second test data are consistent or not by using the TDS to obtain an intrusion result. Thus, if the intrusion result is consistent with the expected result of the test case, the TDS in the tester is proved to be effective. Therefore, the testing method can prove the effectiveness of the data protection and intrusion identification functions of the TDS in the customized computer and the collocation and compatibility of the TDS with software and hardware of the computer, so as to ensure that the TDS in the computer can safely and effectively run when the TDS reaches the hands of a user.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other objects, features and advantages of exemplary embodiments of the present disclosure will become readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings. Several embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which:

in the drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

Fig. 1 shows a schematic flow chart of an implementation of a validity testing method of TDS according to an embodiment of the present disclosure;

FIG. 2 is a schematic diagram illustrating an implementation flow of a method for obtaining first test data and second test data according to an embodiment of the present disclosure;

FIG. 3 is a flow chart illustrating an implementation of a method for obtaining first test data according to an embodiment of the present disclosure;

FIG. 4 is a flow chart illustrating an implementation of an embodiment of the present disclosure in determining a cause of a TDS fault;

fig. 5 shows a schematic diagram of a TDS validity testing arrangement of an embodiment of the present disclosure;

fig. 6 shows a schematic diagram of a TDS validity testing arrangement of another embodiment of the present disclosure;

fig. 7 shows a schematic diagram of a TDS validity testing arrangement of a further embodiment of the present disclosure;

fig. 8 shows a schematic structural diagram of a component of an electronic device implementing the TDS validity testing method according to an embodiment of the present disclosure.

Detailed Description

In order to make the objects, features and advantages of the present disclosure more obvious and understandable, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure. All other embodiments, which can be derived by a person skilled in the art from the embodiments disclosed herein without making any creative effort, shall fall within the protection scope of the present disclosure.

The present disclosure provides a TDS validity testing method applied to a tester, as shown in fig. 1, the method includes:

step 101: and starting and acquiring first test data.

In this example, when the tester is started for the first time, the tester needs to run a virtual machine and load a preinstalled environment of the operating system in the virtual machine.

Since all software or hardware needs to run in the pre-installation environment of the operating system, such as TDS, during the initialization phase of the computer, the pre-installation environment of the virtual machine loading operating system needs to be run. A Virtual Machine (Virtual Machine) refers to a Virtual computer system having complete hardware system functionality, operating in a completely isolated environment, emulated by software.

Step 102: and (5) shutting down the machine.

Step 103: the trusted device setting TDS is restarted and loaded.

In this example, it is necessary to detect whether the TDS is in an enabled state by the BIOS chip before loading the TDS after restarting the tester.

The Basic Input Output System (BIOS) chip stores the most important Basic Input and Output programs of the computer, a self-test program after power-on, and a System self-start program. After the computer is started up, the BIOS runs a Self-Test program to perform Power On Self-Test (POST) On all the hardware such as the restarted CPU, the motherboard, and the keyboard, thereby ensuring that the computer system is in a normal operating state. When the self-checking program of the BIOS detects that the TDS in the CPU is in the state of being disabled, the TDS state is automatically adjusted to be enabled, and then the TDS can be loaded.

Step 104: acquiring first test data and second test data through TDS; the second test data is the first test data updated after the test case is executed on the first test data.

A test case refers to a particular set of input data, test operations, or various environmental settings and expected results provided to a test system for conducting a test.

Step 105: and comparing the first test data and the second test data through the TDS to determine an intrusion result.

When the first test data and the corresponding second test data are compared and analyzed through TDS, if the test data are consistent before and after updating, the test machine is indicated to be not invaded, and otherwise, the test machine is indicated to be invaded. And finally, recording the intrusion result in a health report in a code form, and displaying the health report in a user interface form through a software interface of the TDS.

Step 106: and comparing the intrusion result with the expected result corresponding to the test case, and determining that the TDS is effective if the intrusion result is consistent with the expected result corresponding to the test case.

The disclosure provides a TDS validity testing method which is applied to a testing machine. Firstly, a testing machine is started, first testing data is obtained, and then the testing machine is shut down. Loading the TDS after restarting the tester, and acquiring first test data and second test data through the TDS, wherein the second test data is the first test data updated after executing the test case. And comparing whether the first test data and the second test data are consistent or not by using the TDS to obtain an intrusion result. Thus, if the intrusion result is consistent with the expected result of the test case, the TDS in the tester is proved to be effective. Therefore, the testing method can prove the effectiveness of the data protection and intrusion identification functions of the TDS in the customized computer and the collocation and compatibility of the TDS with software and hardware of the computer, so as to ensure that the TDS in the computer can safely and effectively run when the TDS reaches the hands of a user.

In one example, the test case is used to update specific data in the first test data.

And executing a corresponding test case to update one specific data in the first test data, namely, only one test case can be executed in each TDS validity test, and using the updated first test data as the second test data.

In one example, the first test data includes the following data for the tester: CPU voltage data, solid state disk data, BIOS version information and basic setting data.

In this example, the step 101, which is an implementation process of acquiring the first test data, includes: and loading the management engine, and acquiring the first test data through the management engine.

A Management Engine (ME) is an embedded microprocessor independent of a CPU, a BIOS, and an operating system, and can interact with the BIOS, underlying firmware, the operating system, the CPU, and the like to achieve the highest performance and the most coordinated utility of a computer system. A Management Engine Interface Driver (Management Engine Interface Driver) is a special program that makes the operating system and hardware communicate with each other to control the other hardware in the computer to start and work, such as TDS, management Engine.

In the stage of computer system initialization, after the preinstalled environment of the operating system is loaded, the management engine is driven and controlled by the management engine interface to load the code of the operating system from the flash memory of the computer system, so that the management engine can be started before the main operating system is started. The started management engine collects first test data from a BIOS chip, a solid state disk, a CPU and the like, wherein the first test data comprises CPU voltage data, solid state disk data, BIOS version information, basic setting data and the like.

In one example, when the first test data is: under the conditions of CPU voltage data, solid state disk data, BIOS version information and basic setting data, after the first test data is obtained, the test method further comprises the following steps: the first test data is saved by the management engine.

In this example, the management engine saves the first test data in a snapshot in a flash memory of the computer system. The flash Memory is an Electrically Erasable Programmable Read Only Memory (EEPROM), has characteristics of non-volatility, allowing multiple erasing or writing, and the like, is convenient for writing, erasing and storing the first test data, and can not lose the data stored even if the power is cut off.

In one example, the implementation process of acquiring the first test data and the second test data through the TDS in step 104 includes, as shown in fig. 2:

step 201: and loading the management engine, and acquiring the second test data through the management engine.

In this example, the second test data is the first test data updated after the test case is executed on the first test data, where the test case that can be used to update the first test data includes the following:

taking updating of the voltage data of the CPU as an example, the rear cover of the testing machine is provided with a tact switch connected with the pins of the mainboard, when the rear cover of the testing machine is detached, the tact switch is turned on to change the voltage on the pins of the mainboard connected with the tact switch, and the CPU captures and records the voltage change data.

In addition, the data of the solid state disk can be updated in a mode of replacing the solid state disk; or burning BIOS chip on the main board of the tester to update BIOS version information; or inserting a U disk into the tester, and running a code for modifying the basic setting information in the BIOS chip in the U disk to update the basic setting information.

Step 202: the first test data and the second test data are obtained from a management engine through the TDS.

Because the first test data is stored in the flash memory and does not disappear even if the flash memory is powered off, the first test data and the second test data can be acquired from the management engine through the TDS after the restart.

In one example, the first test data includes: the serial number, HASH value, and public key of the tester. The implementation process of obtaining the first test data in step 101, as shown in fig. 3, includes:

step 301: and loading the management engine, and acquiring software data and hardware data of the tester through the management engine, wherein the hardware data comprises a serial number of the tester.

It should be noted that the management engine obtains all the software data and hardware data in the entire tester.

Serial Number (Serial Number) is a globally unique identification code for electronic products or software, and is commonly used for anti-counterfeiting. In the present disclosure, however, the serial number of the tester is used for validity testing of TDS.

Step 302: and loading the TDS, and acquiring software data and hardware data of the tester from the management engine through the TDS and encrypting to generate a HASH value.

HASH value refers to a HASH function (also called HASH function) that transforms an input of arbitrary length into an output of fixed length, which is a HASH value (also called HASH value). In the present disclosure, the HASH function used by the TDS encryption tool is SHA-256, and the software data and the hardware data are encrypted by the HASH function to generate a HASH value.

In addition, the management engine saves the software data and the hardware data of the tester in a snapshot manner, so that the software data also records snapshot saving time. The HASH value generated by TDS encryption is different even if the same software data and hardware data are different due to the difference in snapshot retention time before and after. Therefore, the TDS uses the uniqueness and irreversibility of the HASH value to cryptographically protect the software data and hardware data of the computer. The present disclosure utilizes the HASH values generated by TDS to perform TDS validation tests.

It should be noted that the TDS merely encrypts and stores the software and hardware data of the tester that is obtained from the management engine, so that all data in the TDS is automatically cleared (including the HASH value) after power down and shutdown, and therefore needs to be re-obtained after loading the TDS is restarted.

Step 303: and acquiring the hardware data of the mainboard of the tester through a trusted platform module TPM and encrypting the hardware data to generate a public key.

A Trusted Platform Module (TPM) is a secure and Trusted hardware Platform integrated on the bottom layer of a computer system, and is a device capable of independently performing key generation and encryption and decryption, and has an independent processor and a storage unit inside, so as to provide encryption and security authentication services for a computer.

It should be noted that, since the TPM chip is disposed on the computer motherboard, unlike the above step 301 of acquiring all hardware data in the whole tester, the TPM chip only acquires data of the hardware on the motherboard for encryption. The hardware on the mainboard mainly comprises a CPU, a north bridge, a south bridge, a hard disk, a BIOS chip and the like. The CPU is connected with a north bridge, the north bridge is directly connected with a south bridge, the south bridge is respectively and directly connected with a BIOS chip and a TPM chip through an LPC (Low Pin Count Bus) Bus, the TPM chip acquires data of hardware (not including TPM) on a mainboard, a pair of Public Key (Public Key for short) and Private Key (Private Key for short) is generated by adopting an asymmetric encryption algorithm, and the Key specification referred by the asymmetric encryption algorithm is ECC _ NIST _ P256. Normally, the private key is stored in the storage unit of the TPM chip, and the public key is made public to the outside, so that the public key and the private key can be used to implement the TPM authentication function, and the encrypted data of the hardware on the motherboard is unpacked. In the disclosure, the validity test of TDS is performed by using a public key generated by TPM.

In this example, step 301 is performed to obtain the serial number of the tester through the management engine, and then step 302 is performed to obtain the HASH value through the TDS. But the step 303 of obtaining the public key through the TPM can be performed simultaneously with the

steps

301 and 302; step 303 may be performed first, and then step 301 and step 302 may be performed; it is also possible to perform step 301 and step 302 first, and then perform step 303, which is not limited by the present disclosure.

In one example, in a case where the first test data is a serial number, a HASH value, and a public key of the tester, after the first test data is obtained, the test method further includes: and sending the first test data to the first server so that the data processing device acquires the first test data from the first server, executes the test case on the first test data to obtain second test data, and stores the second test data in the second server.

In this example, the HASH value and the serial number of the tester can be directly transmitted to the first server for saving through the TDS, while the public key is generated by the TPM and cannot be transmitted and saved through the TDS, so that the public key needs to be transmitted and saved in the first server through the USB data line. And the second test data is the first test data updated after the test case is executed on the first test data, and the second test data is stored in the second server. The updating mode of the first test data can be writing a test script according to the test case, after the data processing device obtains the first test data from the first server, the data processing device executes the test script on the first test data to modify the first test data to obtain second test data, and then the second test data is stored in the second server.

In this example, the test script for each test can only modify any specified data among the HASH value, the serial number of the tester, and the public key. For example, a test script run by the data processing device can only update the serial number of the test machine, the updated serial number of the test machine, the HASH value and the public key are used as second test data, and then the data processing device is connected to the network to access the second server and transmit the second test data to the second server for storage.

The first server is used for storing the first test data. Preferably, the first server may be a CPP2 (Common Preload Process 2) server. The second server is a server dedicated to holding the second test data. Preferably, the second server may be a HAS (Health attachment Services) server.

In an example, in step 105, the implementation process of acquiring the first test data and the second test data through the TDS includes: first test data is acquired from a first server through the TDS, and second test data is acquired from a second server.

The tester can directly access the first server to obtain the first test data through the TDS, but needs to be connected with the network when accessing the second server, so that the tester needs to start the operating system and be connected to the second server within a set time before the TDS obtains the second test data from the second server.

When the running of the self-checking program of the BIOS is finished, the BIOS can continuously run the system self-starting program to start the operating system. In the operating system, the test machine can be connected with a Virtual Private Network (VPN) to access a second server according to the account and the password of the VPN, and after the test machine is successfully connected with the second server, the test machine can verify data security and unseal encrypted data, and then second test data can be acquired through TDS. However, if the requirement of connecting to the VPN within the set time is not met, an abnormal error is displayed during the test process. Preferably, the set time is one hour.

In one example, if the intrusion result is not consistent with the expected result corresponding to the test case, as shown in fig. 4, the method further includes:

step 401: TDS was determined to be invalid.

Step 402: and outputting fault codes of the intrusion results, and inquiring fault reasons in the code base according to the fault codes.

And inquiring the fault reason corresponding to the fault code in the code base, and testing again after analyzing and solving the fault problem until the test proves that the TDS is effective.

Specifically, the case where the test results are TDS valid and TDS invalid is exemplified by the following example:

in one example, if the test case being executed is to modify a HASH value generated by the TDS, the expected outcome should be that the first HASH value and the second HASH value do not match, i.e., the tester is "invaded", and if the code in the statement of health corresponding to the invaded outcome indicates that the first HASH value and the second HASH value corresponding to the TDS do not match, i.e., the tester is "invaded", then the invaded outcome is consistent with the expected outcome, thereby proving that the TDS is valid.

In one example, if the test case being executed is a sequence number of a modifying tester, the expected outcome should be that the sequence number of the first tester is inconsistent with the sequence number of the second tester, i.e., the tester is "invaded", and if the code of the invaded outcome in the health report indicates that the sequence number of the first tester is consistent with the sequence number of the second tester, i.e., the tester is "not invaded", then the invaded outcome is inconsistent with the expected outcome, thereby proving that the TDS is invalid.

In one example, if the executed test case is to re-burn the BIOS chip, then the version of the BIOS is updated, and the expected result should be that the first version information and the second version information of the BIOS are inconsistent, i.e., the tester is "invaded", and if the code of the invaded result in the health report indicates that the first version information and the second version information of the BIOS are consistent, but the first public key and the second public key are inconsistent, i.e., the tester is still "invaded", then the invaded result and the expected result are still inconsistent, thereby proving that the TDS is invalid.

In one example, if the test case executed does not corrupt any data, then the expected outcome is that the tester is "not invaded". If the test machine is invaded in the health report output by the TDS after the actual test, the displayed invasion result is that the test machine is invaded, and the code of the invasion result in the health report indicates that the first CPU voltage data is inconsistent with the second CPU voltage data, so that the invasion result is inconsistent with the expected result, thereby proving that the TDS is invalid.

After one TDS effectiveness test is passed, the next test case is tested until all tests are passed, thereby proving that the TDS is effective. And adding each tested software and hardware item into the bill of materials to generate a special order number of the customized order, so that normal automatic delivery can be carried out.

In one example, in order to implement the above TDS validity testing method, the present disclosure further provides a TDS validity testing apparatus applied to a testing machine, as shown in fig. 5, the apparatus including:

a starting module 501, configured to start a test machine;

an obtaining module 502, configured to obtain first test data after starting the test machine;

a shutdown module 503, configured to shut down the test machine after the first test data is acquired;

the starting module 501 is further configured to restart the tester;

a TDS module 504, configured to load a trusted device setting TDS after the tester is restarted;

an obtaining module 502, further configured to obtain the first test data and the second test data through the TDS; the second test data is the first test data updated after the test case is executed on the first test data;

a determining module 505, configured to determine an intrusion result by comparing the first test data and the second test data through the TDS;

and a judging module 506, configured to compare the intrusion result with an expected result corresponding to the test case, and determine that the TDS is valid if the intrusion result is consistent with the expected result.

In one example, as shown in fig. 6, the testing apparatus further includes a management engine 507, and when the acquired first test data includes the following data of the testing machine: the obtaining module 502 obtains the first test data from the management engine 507 when the CPU voltage data, the solid state disk data, the BIOS version information, and the basic setting data are received. Wherein, the management engine 507 is loaded, and the first test data is obtained through the management engine 507.

In one example, after obtaining the first test data, manageability engine 507 is further configured to save the first test data.

In this example, when the first test data and the second test data are acquired through the TDS, the management engine 507 is loaded, and the second test data is acquired through the management engine 507; the obtaining module 502 is further configured to obtain the first test data and the second test data from the management engine 507 through the TDS.

In one example, as shown in FIG. 7, a TPM module 508 is also included in the test apparatus. When the acquired first test data is the serial number, HASH value, and public key of the tester, the acquiring module 502 collects and acquires the first test data from the management engine 507, the TDS module 504, and the TPM module 508. The loading management engine 507 obtains software data and hardware data of the tester through the loading management engine 507, wherein the hardware data comprises a serial number of the tester; the TDS module 504 is configured to load a TDS, acquire software data and hardware data of the tester from the management engine 507 through the TDS, and encrypt the software data and the hardware data to generate a HASH value; and the TPM module 508 is configured to acquire motherboard hardware data of the tester through the trusted platform module TPM and encrypt the motherboard hardware data to generate a public key.

In an example, as shown in fig. 7, the testing apparatus further includes a data transmission module 509, configured to send the first test data to the first server, so that the data processing apparatus obtains the first test data from the first server, obtains the second test data after executing the test case on the first test data, and stores the second test data in the second server.

In one example, when the first test data and the second test data are obtained through the TDS, the obtaining module 502 is further configured to obtain the first test data from the first server and the second test data from the second server through the TDS.

In one example, as shown in fig. 6 and 7, the apparatus further includes a fault query module 510. If the intrusion result is inconsistent with the expected result corresponding to the test case, the determining module 506 is further configured to determine that the TDS is invalid; meanwhile, the fault query module 510 is configured to output a fault code of the intrusion result, and query a fault cause in the code base according to the fault code.

The utility model discloses a validity testing arrangement of TDS is applied to in the test machine. Firstly, a testing machine is started, first testing data is obtained, and then the testing machine is shut down. Loading the TDS after restarting the tester, and acquiring first test data and second test data through the TDS, wherein the second test data is the first test data updated after executing the test case. And comparing whether the first test data and the second test data are consistent or not by using the TDS to obtain an intrusion result. Thus, if the intrusion result is consistent with the expected result of the test case, the TDS in the tester is proved to be effective. Therefore, the testing device can prove the effectiveness of the data protection and intrusion identification functions of the TDS in the customized computer and the collocation and compatibility with computer software and hardware, so as to ensure that the TDS in the computer can safely and effectively run when reaching the hands of a user.

According to an embodiment of the present disclosure, the present disclosure also provides an electronic device and a readable storage medium.

FIG. 8 illustrates a schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 8, the apparatus 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 602 or a computer program loaded from a storage unit 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the device 600 can also be stored. The calculation unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

A number of components in the device 600 are connected to the I/O interface 605, including: an input unit 606 such as a keyboard, a mouse, and the like; an output unit 607 such as various types of displays, speakers, and the like; a storage unit 608, such as a magnetic disk, optical disk, or the like; and a communication unit 609 such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.

The computing unit 601 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The calculation unit 601 performs the various methods and processes described above, such as the validity test method of TDS. For example, in some embodiments, the method for testing the effectiveness of the TDS may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 600 via the ROM 602 and/or the communication unit 609. When the computer program is loaded into the RAM 603 and executed by the computing unit 601, one or more steps of the above described validity testing method of TDS may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the validity testing method of TDS by any other suitable means (e.g. by means of firmware).

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user can provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server combining a blockchain.

It should be understood that various forms of the flows shown above, reordering, adding or deleting steps, may be used. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present disclosure, "a plurality" means two or more unless specifically limited otherwise.

The above description is only for the specific embodiments of the present disclosure, but the scope of the present disclosure is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present disclosure, and all the changes or substitutions should be covered within the scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A TDS effectiveness testing method is applied to a testing machine and comprises the following steps:

starting and acquiring first test data;

shutting down;

restarting and loading the trusted device setting TDS;

acquiring the first test data and the second test data through the TDS; the second test data is the first test data updated after the test case is executed on the first test data;

comparing the first test data and the second test data by the TDS to determine an intrusion result;

and comparing the intrusion result with an expected result corresponding to the test case, and determining that the TDS is effective if the intrusion result is consistent with the expected result.

2. The method of claim 1, wherein the test case is used to update specific data in the first test data.

3. The method of claim 1, wherein the first test data comprises the following data for the tester: CPU voltage data, solid state disk data, BIOS version information and basic setting data;

the acquiring of the first test data includes: and loading a management engine, and acquiring the first test data through the management engine.

4. The method of claim 3, wherein after acquiring the first test data, the method further comprises: saving, by the management engine, the first test data;

the acquiring the first test data and the second test data through the TDS includes:

loading the management engine, and acquiring the second test data through the management engine;

obtaining the first test data and the second test data from the manageability engine through the TDS.

5. The method of claim 1, wherein the first test data comprises: the serial number, the HASH value and the public key of the tester;

the acquiring of the first test data includes:

loading a management engine, and acquiring software data and hardware data of the tester through the management engine, wherein the hardware data comprises a serial number of the tester;

loading a TDS (total synchronous data base), acquiring software data and hardware data of the tester from the management engine through the TDS, and encrypting to generate the HASH value;

and acquiring the hardware data of the mainboard of the tester through a Trusted Platform Module (TPM) and encrypting the hardware data to generate the public key.

6. The method of claim 5, wherein after acquiring the first test data, further comprising: and sending the first test data to a first server so that a data processing device acquires the first test data from the first server, executes the test case on the first test data to obtain second test data, and stores the second test data in a second server.

7. The method of claim 6, wherein the acquiring the first and second test data via the TDS comprises:

the first test data is obtained from the first server through the TDS and the second test data is obtained from the second server.

8. The method of claim 1, wherein if the intrusion result is inconsistent with an expected result corresponding to the test case, the method further comprises:

determining that the TDS is invalid;

and outputting the fault code of the intrusion result, and inquiring a fault reason in a code base according to the fault code.

9. A TDS validity testing apparatus for use with a testing machine, the apparatus comprising:

the starting module is used for starting the testing machine;

the acquisition module is used for acquiring first test data after the test machine is started;

a shutdown module, configured to shut down the test machine after the first test data is obtained;

the starting module is also used for restarting the tester;

the TDS module is used for loading a trusted device setting TDS after the test machine is restarted;

the acquiring module is further configured to acquire the first test data and the second test data through the TDS; the second test data is the first test data updated after the test case is executed on the first test data;

a determining module, configured to determine an intrusion result by comparing the first test data and the second test data through the TDS;

and the judging module is used for comparing the intrusion result with the expected result corresponding to the test case, and if the intrusion result is consistent with the expected result, determining that the TDS is effective.

10. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-8.