Flash key data protection method for an ont product

Abstract

This invention relates to data protection technology for communication products, and discloses a method for protecting critical flash data in ONT products. This method effectively protects critical data in flash memory and solves the problem of being unable to analyze and locate the source of attacks after flash data has been tampered with. The method includes: S1, a user process initiates flash operations; S2, the operation partition name is encrypted based on a random number and key parameters to generate flash operation ciphertext; S3, the flash operation application process initiates the operation command interface (CLI); S4, it is determined whether the current OTN product is in production mode; if so, proceed to step S7; otherwise, proceed to step S5; S5, it is determined whether the user operation involves data in a critical flash partition; if so, proceed to step S6; otherwise, proceed to step S7; S6, the operation ciphertext is parsed, and the operation partition name is checked for a match; if so, proceed to step S7; otherwise, the user's flash operation is rejected, an alarm is generated, and the process proceeds to step S8; S7, the corresponding flash operation is allowed, and the process proceeds to step S8; S8, the operation log is recorded, and the result is returned to the flash operation application process.

Description

Technical Field

[0001] This invention relates to data protection technology for communication products, specifically to a method for protecting critical flash data in ONT (Optical Networking Equipment) products. Background Technology

[0002] With the further promotion and development of FTTH networks in overseas markets, many small and medium-sized operators have also begun to implement them. However, due to cost constraints, they cannot deploy the TR069 management system, thus failing to manage the home gateway services of the ONT. To facilitate ONT management, they often require opening the corresponding web and telnet ports on the WAN side to manage the home gateway services from the WAN side, which also introduces security vulnerabilities. Some attack programs exploit vulnerabilities in these ports to gain root privileges and maliciously erase and rewrite data stored in flash memory, causing ONT malfunctions. The maliciously modified data may include boot, kernel, file system, configuration, calibration, and other data.

[0003] Because the data in the flash memory had been tampered with, even if the device manufacturer received the attacked ONT, they were unable to analyze the attack. Besides storing system programs, the flash memory also contained BOSA, Wi-Fi calibration data, and production data, with each ONT having unique data. Calibration data requires specialized equipment, which is very expensive. Therefore, after-sales service centers cannot repair these devices; they must be returned to the factory for reprogramming and recalibration, significantly increasing after-sales repair costs. Summary of the Invention

[0004] The technical problem to be solved by this invention is to propose a method for protecting critical data in the flash memory of ONT products, which effectively protects the critical data in the flash memory and solves the problem of being unable to analyze and locate the source of the attack after the flash data has been tampered with.

[0005] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows:

[0006] A method for protecting critical flash data in an ONT product includes the following steps:

[0007] S1. The user process initiates operations on the flash memory;

[0008] S2. Based on random numbers and key parameters, encrypt the operation partition name to generate flash operation ciphertext;

[0009] S3, Flash operation application process startup command interface CLI;

[0010] S4. Determine whether the current OTN product is in production mode. If yes, proceed to step S7; otherwise, proceed to step S5.

[0011] S5. Determine whether the user is operating on data in the critical flash partition. If yes, proceed to step S6; otherwise, proceed to step S7.

[0012] S6. Parse the operation ciphertext and determine whether the operation partition name matches. If yes, proceed to step S7; otherwise, reject the user's current flash operation, generate an alarm, and proceed to step S8.

[0013] S7. Allow the corresponding flash operation and proceed to step S8;

[0014] S8. Record the operation log and return the result to the flash operation application process.

[0015] Furthermore, in step S2, the step of encrypting the operation partition name based on random numbers and key parameters to generate flash operation ciphertext specifically includes:

[0016] Generate a random number Ramdom, with a length of 64 bits (8 bytes).

[0017] Generate the key parameter KeyParm, using the minimum 8 digits of the product serial number, and force-cast it to an 8-byte long integer;

[0018] Generate the Partition field, which represents the partition name in the flash memory.

[0019] Generate ciphertext CodeA = EnCode(Ramdom + KeyParm + 64-bit all-zero data, Partition), where EnCode is the 3DES symmetric encryption algorithm.

[0020] Furthermore, in step S3, after the flash operation application process starts the operation command interface CLI, it passes in relevant data, including: the random number Ramdom, the operation flash partition name field Partition, the key parameter KeyParm, and the ciphertext CodeA.

[0021] Furthermore, in step S5, the key flash partitions include: boot, kernel, file system, Wi-Fi calibration data, BOSA calibration data, and partitions corresponding to production write data.

[0022] Furthermore, in step S6, the parsing of the ciphertext and the determination of whether the operation partition name matches specifically include:

[0023] CodeB = DeCode(Ramdom + KeyParm + 64-bit all-zero data, Partition), where DeCode is the 3DES symmetric decryption algorithm;

[0024] Determine if CodeB and CodeA are equal. If they are, then the partition names match; otherwise, they do not match.

[0025] Furthermore, in step S8, the operation log includes the time, partition, whether it is a critical partition, operation type, operation result, and operation application process information.

[0026] Furthermore, the method also includes the following steps:

[0027] S9. The system periodically starts operation log statistical analysis to determine if there are any abnormal operation records in the log. If so, an alarm is generated and displayed on the web; otherwise, the timer is restarted and the current processing flow is terminated.

[0028] Furthermore, the abnormal operation records include: attempts to modify calibration, production write numbers, boot partition data, abnormal operations on critical parameter partitions, or multiple operations on critical data partitions within a certain week.

[0029] Furthermore, step S9 also includes: before the system performs log statistical analysis, determining whether the current ONT product is in production mode; if so, restarting the timer and ending the current processing flow.

[0030] The beneficial effects of this invention are:

[0031] During flash operations, the operation partition is encrypted to generate operation ciphertext. Only after the operation ciphertext is symmetrically decrypted and successfully matched can the operation permission of the critical partition be obtained, thereby ensuring that the data in the critical partition is not maliciously tampered with. In addition, by recording operation logs, alarms are triggered when abnormal operations occur, and operation log statistical analysis is initiated regularly, which helps to locate the source of attacks and reduce maintenance costs. Attached Figure Description

[0032] Figure 1 This is a flowchart illustrating the operation of flash data in an embodiment of the present invention;

[0033] Figure 2 This is a flowchart of the operation log analysis and alarm process in an embodiment of the present invention. Detailed Implementation

[0034] This invention aims to propose a method for protecting critical data in the flash memory of ONT products, effectively protecting critical data in the flash memory and solving the problem of being unable to analyze and locate the source of attacks after flash data has been tampered with. The core idea is that for a user to normally erase or write critical partition data, they must first generate an operation ciphertext. Only after successfully decrypting and matching the ciphertext using the CLI can the operation be performed. Therefore, even if an attacker gains root privileges through a system vulnerability, they cannot provide the correct ciphertext because they do not know the ciphertext generation algorithm, thus preventing them from manipulating the critical partition data. When the system detects abnormal operations, it logs and generates an alarm, allowing the attack source to be investigated by analyzing the log content.

[0035] Example:

[0036] In this embodiment, the user's operation process for flash data is as follows: Figure 1 As shown, it includes the following steps:

[0037] S1. User process initiates flash operations:

[0038] In this step, user operations include legitimate operations such as using normal remote management tools (web, tr069, etc.) and calling general Linux command interfaces, as well as illegitimate operations such as network attacks to obtain root privileges and use Linux command interfaces.

[0039] S2. Random numbers and key parameters are used to generate ciphertext for flash operations:

[0040] Generate a random number Ramdom, which is 64 bits long (8 bytes).

[0041] Generate the key parameter KeyParm, using the minimum 8 digits of the product serial number, and force-cast it to an 8-byte long integer.

[0042] Generate the Partition field, which represents the partition name in the flash memory.

[0043] Generate ciphertext CodeA = EnCode(Ramdom + KeyParm + 64Bit, Partition). EnCode is the 3DES symmetric encryption algorithm, with a key consisting of a 64-bit Ramdom, a 64-bit KeyParm, and 64 bits of all-zero data, totaling 192 bits. Partition is the partition name field to be encrypted.

[0044] S3, Start flash operation command CLI:

[0045] The flash operation application process starts the operation command interface (CLI) and passes in the random number Ramdom, the operation partition name Partition, the key parameter KeyParm, the ciphertext CodeA, and other necessary parameters (such as which part of the partition to operate on, whether to write or erase, etc.).

[0046] The CLI determines whether the ONT is in production mode by directly entering S4. In production mode, writing the serial number and programming calibration parameters are required. To reduce the workload of developing production testing tools and avoid impacting production line efficiency, production mode allows direct manipulation of the flash memory. The data in the serial number partition has a corresponding flag indicating whether it is in production mode.

[0047] If the ONT is not in production mode, it continues to determine whether the operation involves critical partition data. If it is not critical partition data, it proceeds directly to S5; if it is critical partition data, it proceeds to S4.

[0048] The critical partitions include the boot, kernel, file system, Wi-Fi calibration data, BOSA calibration data, and production write data partitions.

[0049] S4. Parse the ciphertext to generate the partition name:

[0050] Based on the input parameters Ramdom, Partition, KeyParm, and ciphertext CodeA, the partition name corresponding algorithm CodeB = DeCode(Ramdom + KeyParm + 64Bit, Partition) is used, where DeCode is the 3DES symmetric decryption algorithm.

[0051] If CodeA and CodeB are not equal, there is no corresponding flash operation permission, proceed to S6 and generate an alarm. If they are equal, it indicates that operation permission is available, proceed to S5.

[0052] S5. Perform the corresponding flash operation:

[0053] In this step, for flash operations in production mode or operations with flash operation permissions, it is allowed to perform operations on the corresponding flash partition data.

[0054] S6. Record operation log:

[0055] If the ONT is in production mode or is operating on a non-critical partition, no logs are recorded; otherwise, operation logs must be recorded.

[0056] The operation log includes information such as time, partition, whether it is a critical partition, operation type, operation result, and operation application process.

[0057] S7. Return the result to the flash operation application process and end the process.

[0058] Furthermore, in this embodiment, the statistical analysis of the operation logs is initiated by the system at regular intervals, with the timing period being configurable. Its implementation is as follows: Figure 2 As shown, it includes the following steps:

[0059] T1, flash operation log statistics, analysis and maintenance:

[0060] Determine if ONT is in production mode. If it is, proceed directly to T3; otherwise, continue execution.

[0061] Log analysis and statistics are performed to determine if there are any abnormalities such as attempts to modify calibration, production write numbers, boot partition data, abnormal operations on critical parameter partitions, or multiple operations on critical data partitions within a certain week. If so, proceed to T2; otherwise, proceed to T3.

[0062] For log maintenance, ensure that the number of log entries does not exceed the specified number.

[0063] T2. Generate a system alarm:

[0064] An alarm is generated based on the information provided in step T1, and the alarm is displayed on the web.

[0065] T3. Restart the timer to end this process.

[0066] Finally, it should be noted that the above embodiments are merely preferred embodiments and are not intended to limit the present invention. It should be pointed out that those skilled in the art can make various modifications, equivalent substitutions, and improvements without departing from the spirit and scope of the claims, and all such modifications, substitutions, and improvements should be included within the scope of protection of the present invention.

Claims

1. A flash key data protection method for an ONT product, characterized in that, Includes the following steps: S1. The user process initiates operations on the flash memory; S2. Generate flash operation ciphertext by encrypting the operation partition name based on random numbers and key parameters: Generate a random number Ramdom, with a length of 64 bits (8 bytes). Generate the key parameter KeyParm, using the minimum 8 digits of the product serial number, and force-cast it to an 8-byte long integer; Generate the Partition field, which represents the partition name in the flash memory. Generate ciphertext CodeA = EnCode(Ramdom+KeyParm+64Bit all-zero data, Partition), where EnCode is the 3DES symmetric encryption algorithm; S3, the flash operation application process startup command interface CLI, passes in relevant data, including: random number Ramdom, operation flash partition name field Partition, key parameter KeyParm and ciphertext CodeA; S4. Determine whether the current OTN product is in production mode. If yes, proceed to step S7; otherwise, proceed to step S5. S5. Determine whether the user is operating on data in the critical flash partition. If yes, proceed to step S6; otherwise, proceed to step S7. S6. Parse the operation ciphertext and determine whether the operation partition name matches. If yes, proceed to step S7; otherwise, reject the user's current flash operation, generate an alarm, and proceed to step S8. S7. Allow the corresponding flash operation and proceed to step S8; S8. Record the operation log and return the result to the flash operation application process.

2. The method for protecting critical flash data in an ONT product as described in claim 1, characterized in that, In step S5, the key flash partitions include: boot, kernel, file system, Wi-Fi calibration data, BOSA calibration data, and partitions corresponding to production write data.

3. The method for protecting critical flash data in an ONT product as described in claim 1, characterized in that, In step S6, parsing the ciphertext and determining whether the operation partition name matches specifically includes: CodeB = DeCode (Ramdom + KeyParm + 64-bit all-zero data, Partition), where DeCode is the 3DES symmetric decryption algorithm; Determine if CodeB and CodeA are equal. If they are, then the partition names match; otherwise, they do not match.

4. The flash key data protection method of an ONT product according to any one of claims 1-3, characterized in that, In step S8, the operation log includes the time, partition, whether it is a critical partition, operation type, operation result, and operation application process information.

5. A method for protecting critical flash data in an ONT product as described in claim 1, characterized in that, The method also includes the following steps: S9. The system periodically starts operation log statistical analysis to determine if there are any abnormal operation records in the log. If so, an alarm is generated and displayed on the web; otherwise, the timer is restarted and the current processing flow is terminated.

6. The method for protecting critical flash data in an ONT product as described in claim 5, characterized in that, The abnormal operation records include: attempts to modify calibration, production write numbers, boot partition data, abnormal operations on critical parameter partitions, or multiple operations on critical data partitions within a certain week.

7. A method for protecting critical flash data in an ONT product as described in claim 5, characterized in that, Step S9 also includes: before the system performs log statistical analysis, determining whether the current ONT product is in production mode. If so, the timer is restarted to end the current processing flow.

Images